locked
MSIS7065: There are no registered protocol handlers on path /adfs/ls/ to process the incoming request. RRS feed

  • Question

  • On a newly installed Windows Server 2012 R2, I have installed the ADFS (v3.0) role and configured it as per various guides online. It is a different server to the Domain Controller and the ADFS Service name is a fully qualified URL and is NOT the fully qualified local machine name.

    I'm receiving a EventID 364 when trying to submit an AuthNRequest from my SP to ADFS on /adfs/ls/. The full logged exception is here:

    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)
    
    


    My RP is a custom web application that uses SAML 2.0 to sent AuthNRequests and receive Assertion messages back from the IdP (in this case ADFS).

    I have successfully authenticated using /adfs/ls/IdpInitiatedSignon.aspx so it is working for an IdP-initiated workflow.

    I have also successfully integrated my application into an Okta IdP, which was seamless. When using Okta both the IdP-initiated AND the SP-initiated is working.

    There is no obvious or significant differences when issueing an AuthNRequest to Okta versus ADFS.

    I have tried enabling the ADFS tracing event log but that did not give me any more information, other than an EventID of 87 and the message "Passive pipeline error".

    I have checked the spn and the urlacls against the service and/or managed service account that I'm using. All appears to be fine although there is not a great deal of literature on the default values.

    I have tried a signed and unsigned AuthNRequest, but both cause the same error.

    I've also discovered a bug in the metadata importer wizard but haven't been able to find ADFS as a product on connect to raise the bug with Microsoft.


    Wednesday, November 1, 2017 3:24 PM

Answers

  • I think you might have misinterpreted the meaning for escaped characters. The RFC is saying that ? is a reserved character and that if you need to use the character for a valid reason, it must be escaped.

    I'm using it as a component of the URI, so it shouldn't be interpreted by ADFS in this way.

    I'm updating this thread because I've actually solved the problem, finally.

    The form parameter I was using was:

    SamlRequest=PHNhbWxwOkF1dGhuUm......

    And it should have been this:

    SAMLRequest=PHNhbWxwOkF1dGhuUm.....


    The most frustrating part of all of this is the lack of good logging and debugging information in ADFS. I'd love for the community to have a way to contribute to ideas and improve products rather than it just be met with a brick wall. 

    Wednesday, November 8, 2017 11:34 AM

All replies

  • Can you share the full context of the request? Like the other headers sent as well as the query strings you had.

    Tell us more about the bug you found.


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Wednesday, November 1, 2017 3:40 PM
  • I can't post the full unaltered request information as it may contain sensitive information and URLs, but I have edited some values to work around this. If you need to see the full detail, it might be worth looking at a private conversation? Let me know if there's anything else you need to see.

    My Relying Party generates a HTML response for the client browser which contains the Base64 encoded SAMLRequest parameter. The Javascript fires onLoad and submits the form as a HTTP POST:

    HTTP/1.1 200 OK
    Cache-Control: private
    Content-Type: text/html; charset=utf-8
    Vary: Accept-Encoding
    X-Frame-Options: SameOrigin
    X-Content-Type-Options: nosniff
    X-Download-Options: noopen
    X-XSS-Protection: 1; mode=block
    Strict-Transport-Security: max-age=31536000; includeSubDomains
    Content-Security-Policy: REMOVED
    Set-Cookie: TempData=REMOVED; path=/; secure; HttpOnly
    Date: Wed, 01 Nov 2017 15:45:41 GMT
    Content-Length: 4370
    
    
    
    
    
    <!DOCTYPE html>
    
    <html>
    <head>
        <meta name="viewport" content="width=device-width" />
        <title></title>
    </head>
    <body onload="document.getElementById('samlform').submit()">
        <form id="samlform" action="https://adfs.domain.com/adfs/ls/" method="post" target="_self">
            
            <input type="hidden" name="SamlRequest" value="REMOVED VALUE" />
            
            <noscript>
                Your browser does not support Javascript. You'll need to press the Continue button to proceed.
                <div>
                    <input type="submit" value="Continue" />
                </div>
            </noscript>
        </form>
    </body>
    </html>
    

    The decoded AuthNRequest looks like this (again, values are edited):

    <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="_92e11dbf-825c-47e7-87ec-18e859feb9f5" Version="2.0" IssueInstant="2017-11-01T15:45:41.863Z" Destination="https://adfs.domain.com/adfs/ls/" ForceAuthn="false" IsPassive="false" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="https://local-sp.com/authentication/saml/AssertionConsumerService">
      <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://local-sp.com/authentication/saml/metadata/383c41f6-fff7-21b6-a6e9-387de4465611</saml:Issuer>
      <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true"/>
    </samlp:AuthnRequest>

    The POST request looks like this:

    POST https://adfs.domain.com/adfs/ls/ HTTP/1.1
    Host: adfs.domain.com
    Connection: keep-alive
    Content-Length: 1006
    Cache-Control: max-age=0
    Origin: https://local-sp.com
    Upgrade-Insecure-Requests: 1
    Content-Type: application/x-www-form-urlencoded
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
    Referer: https://local-sp.com/ExternalProvider/SAML/RequestLoginAtIdentityProvider?identityProviderKey=683c41c6-ff57-41b6-a649-3870044656e8
    Accept-Encoding: gzip, deflate, br
    Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
    Cookie: MSISAuth=REMOVED; SamlSession=REMOVED; MSISAuthenticated=REMOVED; MSISLoopDetectionCookie=REMOVED
    
    SamlRequest=REMOVED

    And the response from adfs/ls/...

    HTTP/1.1 200 OK
    Cache-Control: no-cache,no-store
    Pragma: no-cache
    Content-Length: 9299
    Content-Type: text/html; charset=utf-8
    Expires: -1
    Server: Microsoft-HTTPAPI/2.0
    x-frame-options: DENY
    X-MS-Forwarded-Status-Code: 500
    Date: Wed, 01 Nov 2017 15:45:43 GMT
    
     <!DOCTYPE html>
    ...
     </html>

    The Identifier and Endpoint set up in my RP Trust matches the Saml Issuer and the ACS URL, respectively.

    The bug I believe I've found is when importing SAML metadata using the "Add Relying Party Trust..." wizard. When you get to the end of the wizard there is a checkbox to launch the "Edit Claim Rules Wizard", which if you leave checked, it is impossible to add an Issuance Transform Rule. The "Add Rule" dialog (when picking "Send LDAP Attributes as Claims", the "Attribute store" dropdown is blank and therefore you can't add any mappings.

    Using the wizard from the list (right clicking on the RP and going to "Edit Claim Rules..." works fine, so I presume it's a bug.

    Wednesday, November 1, 2017 4:13 PM
  • You have a POST assertion consumer endpoint for this Relying Party if you look at the endpoints tab on it?

    If so, can you try to change the index? Change the order and put the POST first.


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Wednesday, November 1, 2017 6:49 PM
  • Yes, I've only got a POST entry in the endpoints, and so the index is not important. Although I've tried setting this as 0 and 1 (because I've seen examples for both).

    Here are screenshots of each of the parts of the RP configuration:

    https://cdn.pbrd.co/images/GRL2FPP.png
    https://cdn.pbrd.co/images/GRL2Sdg.png
    https://cdn.pbrd.co/images/GRL2WvP.png
    https://cdn.pbrd.co/images/GRL30pV.png
    https://cdn.pbrd.co/images/GRL35XAM.png
    https://cdn.pbrd.co/images/GRL3etB.png
    https://cdn.pbrd.co/images/GRL3ifQ.png

    Thursday, November 2, 2017 9:06 AM
  • Do you have the same result if you use the InPrivate mode of IE?

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Thursday, November 2, 2017 4:02 PM
  • Yes, same error in IE both in normal mode and InPrivate.
    Thursday, November 2, 2017 4:18 PM
  • Then I have no idea :)

    What enabling the AD FS/Tracing log, repro and disabling the log. What more does it give us?


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Thursday, November 2, 2017 4:20 PM
  • I think I mentioned the trace logging shows nothing useful, but here it is in all of it's verbose uselessness!

    https://pastebin.com/raw/d4s81KzL

    It's quite disappointing that the logging and verbose tracing is so weak in ADFS. For a mature product I'd expect that the system admin would be able to get something more useful than "An error occurred".

    I've got the opportunity to try my Service Provider with a 3rd party ADFS server in Azure which is known to be working, so I should be able to confirm if it's my SP or ADFS that's the issue and take it from there.

    Friday, November 3, 2017 9:27 AM
  • Indeed, my apologies. Did you also edit the issuer section in your AuthnRequest:

    https://local-sp.com/authentication/saml/metadata/383c41f6-fff7-21b6-a6e9-387de4465611

    It has to be the same as the RP ID. Well, with all that... I don't know :) The common cases I have seen are:

    - duplicate cookie name when publishing CRM
    - network appliances switching the POST to GET
    - incorrect endpoint configuration

    So here we are out of these :) Others? Any suggestions?


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Friday, November 3, 2017 1:19 PM
  • Well, as you say, we've ruled out all of the problems you tend to see.

    Is there any opportunity to raise bugs with connect or the product team for ADFS? Aside from the interface problem I mentioned earlier in this thread, I believe there's another more fundamental issue.

    According to the SAML spec. Entity IDs should be well-formatted URIs RFC 2396. It seems that ADFS does not like the query-string character "?" in the URI.

    During my experiments with another ADFS server (that seems to actually output useful errors), I saw the following error:

    A token request was received for a relying party identified by the key 'https://local-sp.com/authentication/saml/metadata', but the request could not be fulfilled because the key does not identify any known relying party trust.

    Key: https://local-sp.com/authentication/saml/metadata

    Yet, the Issuer we were actually including was formatted similar to this:

    https://local-sp.com/authentication/saml/metadata?id=383c41f6-fff7-21b6-a6e9-387de4465611

    Again, it looks like a bug, or a poor implementation of the URI standard because ADFS is truncating the URI at the "?" character.

    All of that is incidental though, as the original AuthNRequests do not include the query-string part, and the RP trust is set up as my original posts. I would appreciate any assistance as to what to try from here...

    Monday, November 6, 2017 10:34 AM
  • In case that help, I wrote something about URI format here. And the ?, although it is allowed, has to be escaped:

    https://social.technet.microsoft.com/Forums/windowsserver/en-US/6730575a-d6ea-4dd9-ad8e-f2922c61855f/adding-post-parameters-in-the-saml-response-header?forum=ADFS


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Tuesday, November 7, 2017 10:00 PM
  • I think you might have misinterpreted the meaning for escaped characters. The RFC is saying that ? is a reserved character and that if you need to use the character for a valid reason, it must be escaped.

    I'm using it as a component of the URI, so it shouldn't be interpreted by ADFS in this way.

    I'm updating this thread because I've actually solved the problem, finally.

    The form parameter I was using was:

    SamlRequest=PHNhbWxwOkF1dGhuUm......

    And it should have been this:

    SAMLRequest=PHNhbWxwOkF1dGhuUm.....


    The most frustrating part of all of this is the lack of good logging and debugging information in ADFS. I'd love for the community to have a way to contribute to ideas and improve products rather than it just be met with a brick wall. 

    Wednesday, November 8, 2017 11:34 AM
  • Thanks for sharing!

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Wednesday, November 8, 2017 5:16 PM