locked
"No registered protocol handlers" error following installation of ADFS 3.0 on Server 2012 R2 RRS feed

  • Question

  • I am trying to install ADFS 3.0 on a Server 2012 R2 VM that I've created from the Server 2012 R2 Datacenter VM template on Azure. The server has no other roles on it (and no IIS because ADFS 3.0 does not use IIS), but has ASP.NET 4.5 installed and .NET 4.5. It is fully Windows Updated including the latest 2012 R2 Update that was just released. It is joined to a Server 2012 R2 DC (also an Azure VM running 2012 R2). I've created a self-signed SSL certificate via the domain controller called adfs.azure.xxx.net and installed the root CA and the certificate on the server. I have followed the instructions at http://goodworkaround.com/node/53.

    Following successful installation and configuration (using the Wizard) of the ADFS role, I can go to the page https://adfs.azure.xxx.net/federationmetadata/2007-06/federationmetadata.xml and that works fine, and it brings back a load of xml.

    However, when I test the signin page at https://adfs.azure.xxx.net/adfs/ls/ldpinitiatedsignon.aspx on the server, I get a web page come up with the messgae "An error occurred. Contact your administrator for more information." The ADFS Admin log reports the following error:

    Encountered error during federation passive request. 

    Additional Data 

    Protocol Name: 

    Relying Party: 
     
    Exception details: 
    Microsoft.IdentityServer.RequestFailedException: MSIS7065: There are no registered protocol handlers on path /adfs/ls/ldpinitiatedsignon.aspx to process the incoming request.
       at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)

    I have searched all over for this error ('no registered protocol handlers') but cannot find any mention of it anywhere. I've tried this a number of times by creating a new Azure VM server and installing the role after joining the server to the domain, but no success.

    I am completely stumped. Can anyone offer any advice?

    • Moved by Awinish Monday, April 14, 2014 2:19 AM
    Friday, April 11, 2014 12:51 PM

All replies

  • I'm getting the exact same thing myself.
    Friday, April 11, 2014 2:32 PM
  • I just went through this error myself after installing ADFS 3.0, and fixed it by going to the ADFS Management Console and clicking on the Authentication Policies folder on the tree view on the left.  Then, under Actions on the right, click on Edit Global Primary Authentication Policy.  Set the Intranet Authentication Method to Forms Authentication (by default it is set to Windows Authentication).   

     
    Friday, April 11, 2014 3:53 PM
  • I tried that myself, but it did not resolve the error.
    Friday, April 11, 2014 4:50 PM
  • I am seeing the same thing... Did a recent patch break something? I can't seem to find any threads on this topic prior to this week.
    Friday, April 11, 2014 5:06 PM
  • Also, Piccolo_hat's fix doesn't seem to work for me.

    - Brandon

    Friday, April 11, 2014 5:07 PM
  • One more thing to note... it seems Server 2012 R2 Update 1 was rolled out (http://www.microsoft.com/en-us/download/details.aspx?id=42334) which includes some new bits for ADFS:


    "
    The only change to Server 2012 R2 server capability is around Active Directory Federation Services (AD FS). These changes are meant to improve compatibility with Azure Active Directory and Office 365, which allows signing in with an alternate login ID that's an attribute of the user in the on-premises Active Directory Domain Services environment."

    I'm going to deploy a new VM from the RTM ISO and see if I have the issue.

    Friday, April 11, 2014 6:44 PM
  • I also tried piccolo_hat's suggestion and it did not work, but thanks for offering that advice.

    Out of desperation I created a new 2012 R2 Datacenter VM, fully patched it including the latest 'Update 1' just released by Microsoft and even installed asp.net just in case before installing the ADFS role, but none of that made any difference.

    I finally got Microsoft Support involved and they've come up trumps. It took a couple of hours of troubleshooting, and the solution they found is apparently an undocumented 'feature' that they have come across before.

    The cause of the problem (for me at least) was the value of the attribute servicePrincipalName in the Attribute Editor tab of the properties of the domain account I'd created and used to run the ADFS service. I'd created the account fine, but during ADFS installation the value of servicePrincipalName was set to hosts/adfs.azure.xxx.net . After manually changing it to http/adfs.azure.xxx.net and restarting the ADFS service the signon page correctly appeared.

    Of course that then makes sense of the error message, as hosts would not be a registered protocol hander, whereas http of course is. Note that I had originally tried using a group managed service account, as recommended by Microsoft, but that had also produced the same error.

    Perhaps Microsoft could make this potential solution available via the 'Event Log Online Help' link on the event 364 information, as currently that link doesn't provide any information at all.

    Please try this solution and see if it works for you.

    Sunday, April 13, 2014 9:58 AM
  • Thanks Julian!

    So I tried your suggestion on my original ADFS box as it was configured, uninstall/reinstall the role, reboot, etc with no dice.

    Moved on to a fresh VM, fresh service account and fully updated to the R2 Update 1 and still, no dice. I uninstalled the role once more, turned off the firewall on my DC and ADFS box, rebooted, reinstalled it. Now the SPN on the user account reads:

    host/fs.domain.com

    http/fs.domain.com

    Voila, it works. 

    So I'm not sure if the HTTP change for the SPN, turning off the firewall, or just reinstalling it wound up being the fix. Definitely seems like something that needs fixed regardless...

    Hopefully some others can chime in with their experience and we can narrow down the cause/fix.

    Cheers,

    Brandon

    Monday, April 14, 2014 7:41 AM
  • I have tried Julian's suggestion as well and added the SPN to the Service Account running the ADFS 3.0 service, but am still receiving the MSIS7065 error when connecting to only 1 of our Relying Party Trusts(ServiceNow).

    ServiceNow works fine in 2.0

    Tuesday, April 29, 2014 2:39 PM
  • Hi #TheJulianW and others reading this post.

    I had the exact same "error" as you. Which by the way was my own fault!

    First I received the error, then I searched the web and end up here.
    I of course do the "smart" thing of copying the URL you posted and I sh** you not, you have made the same mistake as I had ;)

    I tried debugging, then re-installed everything and at last opened a ticket with Microsoft.
    After many days of writing back and forth with MS, they found the error just a couple of hours after I did myself :)

    Just to be clear. This was my error:
    Wrong URL: https://adfs.azure.xxx.net/adfs/ls/ldpinitiatedsignon.aspx
    Correct URL: https://adfs.azure.xxx.net/adfs/ls/idpinitiatedsignon.aspx
    See a difference? Well, I didn’t ether, until I copied it into notepad and compared the two.
    I was writing an lowercase “L” instead of a “I”.

    Btw, I followed this great blog post to create my AD Managed service account:
    Installing Windows 2012 R2 Server ADFS Service

    My SPN(servicePrincipalName):
    HOST/sts.domain.com
    HTTP/sts
    HTTP/sts.domain.com

    I hope someone can save a lot of time reading this post, if they run into the same error.

    Good luck.

    //Brandur

    • Proposed as answer by MARCEL MEDINA Sunday, May 25, 2014 1:25 AM
    • Unproposed as answer by MARCEL MEDINA Sunday, May 25, 2014 1:25 AM
    • Proposed as answer by MARCEL MEDINA Sunday, May 25, 2014 1:26 AM
    Thursday, May 1, 2014 3:24 PM
  • Hey all,

    found this thread looking at the same error in my ADFS lab..

    i have ADFS with 2012 R2 as well, and using gMSA. spn settings are fine.. but were having this error.

    only after i realized that i forwarded the traffic from WWW to the ADFS server and not to the Web Application Proxy server the errors stopped.

    So once the traffic hits the WAP first no more errors on the ADFS server itself.

    Hope this helps anyone...

    ilantz

    Monday, May 5, 2014 9:17 AM
  • Beware the URLs, if you pur the wrong URL you don't get : a sensible message like site does not exist, you get this: The correct URL is  /adfs/ls/idpinitiatedsignon.aspx

    Encountered error during federation passive request.

    Additional Data

    Protocol Name:

    Relying Party:

    Exception details:

    Microsoft.IdentityServer.RequestFailedException: MSIS7065: There are no registered protocol handlers on path /adfs/ls/idpinitiatedlogon.aspx to process the incoming request.

       at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)




    CarolChi

    Tuesday, July 22, 2014 2:51 PM
  • Hi,

    I use the following URL w/o issues:

    https://adfs.domain.com/adfs/ls/idpinitiatedsignon

    Also make sure that your service account has the proper SPNs.

    domain\serviceaccount

    HOST/adfs.domain.com
    HTTP/adfs.domain.com
    HTTP/adfs

    I hope that helps!  


    Ricardo Fuentes

    • Proposed as answer by Kaspars_ Friday, March 18, 2016 6:58 AM
    Thursday, July 31, 2014 6:02 PM
  • This saved me a LOT of work.  I left out the "p" in the URL, so my mistake but would have liked a better error message.  Anyway, now I'm up and running - thanks....

    Bob


    • Edited by BCond Thursday, November 20, 2014 11:03 PM
    Thursday, November 20, 2014 11:02 PM
  • I've encountered the exact same problem but the path "sounded" strange: /adfs/ls

    Log Name:      AD FS/Admin
    Source:        AD FS
    Date:          05-03-2015 16:45:13
    Event ID:      364
    Task Category: None
    Level:         Error
    Keywords:      AD FS
    User:          DEVSCOPE\adfssvc
    Computer:      xxx.domain.local
    Description:
    Encountered error during federation passive request. 
    
    Additional Data 
    
    Protocol Name: 
     
    
    Relying Party: 
     
    
    Exception details: 
    Microsoft.IdentityServer.RequestFailedException: MSIS7065: There are no registered protocol handlers on path /adfs/ls to process the incoming request.
       at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)
    
    
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="AD FS" Guid="{2FFB687A-1571-4ACE-8550-47AB5CCAE2BC}" />
        <EventID>364</EventID>
        <Version>0</Version>
        <Level>2</Level>
        <Task>0</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8000000000000001</Keywords>
        <TimeCreated SystemTime="2015-03-05T16:45:13.438743500Z" />
        <EventRecordID>283257</EventRecordID>
        <Correlation ActivityID="{00000000-0000-0000-7400-0080010000EC}" />
        <Execution ProcessID="5624" ThreadID="920" />
        <Channel>AD FS/Admin</Channel>
        <Computer>xxx.domain.local</Computer>
        <Security UserID="" />
      </System>
      <UserData>
        <Event xmlns="http://schemas.microsoft.com/ActiveDirectoryFederationServices/2.0/Events">
          <EventData>
            <Data>
            </Data>
            <Data>
            </Data>
            <Data>Microsoft.IdentityServer.RequestFailedException: MSIS7065: There are no registered protocol handlers on path /adfs/ls to process the incoming request.
       at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)
    
    </Data>
          </EventData>
        </Event>
      </UserData>
    </Event>

    After some digging around with ADFS Trace Logs, I found that the problem resided on our Forefront TMG 2010 and the Connectivity Verifier of the ADFS Farm. When configuring the Farm server, there's an option to set the Connectivity Verifier URL; which by definition allows for wildcards. So, when we've setup our's we used an URL like https://*/adfs/ls/*

    That was our mistake and the source of the error. The Verifier was not replacing the wildcard with the correct URL and was sending all those wrong requests to the ADFS servers. After correcting the URL with the idpInitiatedSignon.aspx full URL, the problem was solved.

    Thursday, March 5, 2015 5:34 PM
  • Thanks for the help Julian! Really did the trick for me!

    Regards,

    Diego Zanette.

    Tuesday, November 24, 2015 11:56 AM
  • Very helpful hint, Carol. I was puzzled getting the same error even after following the steps provided by @TheJulianW.

    Thanks!

    Tuesday, November 24, 2015 12:00 PM
  • Folks

    Mine is a slightly different issue - all worked fine for 24 hrs then this issue appeared from nowhere with no other changes.

    I have set my UPNs correctly - else it would not have worked during the first 24 hrs.

    It was working fine from the proxy box as well as locally inside the domain - now I get this error apparently from nowhere - no changes were made apart from 20 hours elapsing!

    Any assistance would be truly appreciated.

    Thursday, March 31, 2016 11:45 AM
  • My Man !!!! you saved the freaking day.......

    Wrong URL was my problem.

    Thank you for sharing.

    Anderson Arlotta

    • Proposed as answer by AndersonA Friday, April 1, 2016 3:18 AM
    • Unproposed as answer by AndersonA Friday, April 1, 2016 3:18 AM
    Friday, April 1, 2016 3:17 AM
  • #AndersonA

    That's great. I'm really happy that it has helped you out
    Please remember to up-vote my original post, so others find it quickly and it can help others :)



    • Edited by BrandurKHP Friday, April 1, 2016 7:21 AM spelling2
    Friday, April 1, 2016 7:20 AM
  • Hey. Interesting.

    I have exactly the same issue only with Service-Now.

    All my other third party relays work fine but Service-Now, once you log out and try logging back in you keep getting the logout page.

    Has anyone run into this or have a fix??

    Thursday, May 19, 2016 6:49 PM