locked
HTTP 400 error on redirection to https://federation.company.com/adfs/ls/wia RRS feed

  • Question

  • The title is the error I receive after selecting my relaying partner's webpage with the sso button.

    It seems to be problematic for many so I will attempt to document my environment:

    I have a 3 server ADFS 3.0 farm located behind a load-balancer & federation.company.com has the IP of the front-end of the load-balancer.

    The token-signing cert located on all ADFS servers is from Entrust and is in the name of federation.company.com.

    The ADFS services on all three machines run with a managed service account, svc-adfs-prod. This MSA has the following SPN: http/federation.company.com,host/federation.company.com, and svc-adfs-prod/federation.dir.vertivco.com.  NOTE: The names of the servers are ADFS1,ADFS2,and ADFS3 are are NOT in the SPN of the MSA.  ( I will toy with adding the server names FQDN to the MSA per https://samlman.wordpress.com/2015/03/02/400-bad-request-error-with-adfs/ )

    The Windows 2012 R2 domain where the ADFS servers are members and which the above service account is located in is dir.company.com.

    The MSA has all three servers listed in "PrincipalsAllowedToRetrieveManagedPassword" along with a group that contains all three ADFS computers.

    Right now, my testing is restricted to my internal IE 11.0.9600.18499IS in which I have added https://federation.company.com as a trusted site.

    Externally, federation.compnay.com resolves to the load-balancer in front of my ADFS PROXY servers.  Internally, I have setup only a hosts file pointing to the load-balancer that is fronting my internal 3 ADFS servers.  This host file is the workstation I am working on doing my tests.

    Primary Authentication, global settings have Extranet to Forms Authentication and Intranet to Windows Authentication.

    On my client machine, I can see my ADFS metadata at https://federation.company.com/FederationMetadata/2007-06/FederationMetadata.xml

    On my client machine, I get a HTTP 400 error trying to access https://federation.company.com/adfs/ls/IdpInitiatedSignon.aspx with IE but I can access it with Mozilla and get a page asking for my credentials but it does not seem to accept them.  It asks me to sign on to this site or Sign onto the relaying partner.  I was able to sign into my site.  It told me I was signed in and then offered to sign into my relaying partner site but fails.  Below are the error details.

    • Activity ID:  00000000-0000-0000-fdfa-0280010000fe        
      • Relying party: DocuSign
                 
    • Error time: Mon, 28 Nov 2016 22:13:45 GMT
    • Cookie: enabled
    • User agent string: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0

    Any tips or suggestions are welcome. Thanks.

    Monday, November 28, 2016 10:23 PM

All replies

  • One more item...when I try to analyze via a fiddler trace, I see the url /adfs/ls/wia and NTLM is mentioned under WWW-Authenticate:NTLM. It should be noted that the Windows 2012 R2 domain is set to accept NTLMv2 responses only.
    Monday, November 28, 2016 10:36 PM
  • Can you reach that authentication prompt FROM one of your proxy servers when pointing at one of your internal ADFS servers directly? I always start with tests from each proxy to each internal server.

    Additionally, make sure you have a host file on each of the ADFS proxys that resolves the name to the internal IP of the server, and that your DNS servers listed on those proxies point to DNS servers that resolve your namespace to the external (public) IP.

    You say IE can reach the URL.. is this on a domain joined workstation? Is your workstation on domain?

    Monday, November 28, 2016 10:38 PM
  • and an error under fiddler about request being too long,

    HTTP/1.1 400 Bad Request

    Content-Type: text/html; charset=us-ascii

    Server: Microsoft-HTTPAPI/2.0

    Date: Mon, 28 Nov 2016 22:50:03 GMT

    Connection: close

    Content-Length: 346

     

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">

    <HTML><HEAD><TITLE>Bad Request</TITLE>

    <META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>

    <BODY><h2>Bad Request - Request Too Long</h2>

    <hr><p>HTTP Error 400. The size of the request headers is too long.</p>

    </BODY></HTML>

    Monday, November 28, 2016 10:55 PM
  • Yes, each proxy also has a hosts file pointing company.federation.com to the load-balancer of the internal ADFS farm. Right now, the proxy dns settings point to my internal DNS which can resolve ultimately to the outside. This will be a problem once I have the company.com domain hosted internally but for now, this configuration should be OK. Only the subdomain, dir.company.com domain is authoritative on the inside.

    Yes, from the proxy server, I can go to https://federation.company.com/adfs/ls/IdpInitiatedSignOn.aspx and sign in initially but then try to go to the relaying partner site I receive a similar error as to my internal client.

    My internal client workstation is a member of dir.company.com Windows 2012 R2 domain.

    Monday, November 28, 2016 11:12 PM
  • Using another test user account (in same domain both user and workstation), I see an event 365 error with the following:

    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)

     

    Tuesday, November 29, 2016 8:48 PM
  • Could you share a (sanitized) fiddler trace?

    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 30, 2016 4:21 PM
  • Upon further testing, I see this error. I looked at the cert...it is valid and I even checked the CRL...it is not there. Now, it should have been able to reach the CRL...I looked at it from one of the ADFS servers. How can I tell it not to check the CRL?

    Log Name:      AD FS/Admin
    Source:        AD FS
    Date:          11/30/2016 2:15:25 PM
    Event ID:      316
    Task Category: None
    Level:         Error
    Keywords:      AD FS
    User:          DIR\svc-adfs-prod$
    Computer:      ADFSAMER-P02.dir.domain.com
    Description:
    An error occurred during an attempt to build the certificate chain for the relying party trust 'https://account-d.docusign.com/organizations/977b8629-36e0-4f3b-8542-7d3e66414ec0/saml2' certificate identified by thumbprint '019E89A013F412F8915436AD90B81802CE3A8ED1'. Possible causes are that the certificate has been revoked, the certificate chain could not be verified as specified by the relying party trust's signing certificate revocation settings or certificate is not within its validity period.

    You can use Windows PowerShell commands for AD FS to configure the revocation settings for the relying party signing certificate.
    Relying party trust's signing certificate revocation settings: CheckChainExcludeRoot
    The following errors occurred while building the certificate chain: 
    A certificate chain could not be built to a trusted root authority.

    The revocation function was unable to check revocation for the certificate.

    The revocation function was unable to check revocation because the revocation server was offline.

     

    User Action:
    Ensure that the relying party trust's signing certificate is valid and has not been revoked.
    Ensure that AD FS can access the certificate revocation list if the revocation setting does not specify "none" or a "cache only" setting.
    Verify your proxy server setting. For more information about how to verify your proxy server setting, see the AD FS Troubleshooting Guide (http://go.microsoft.com/fwlink/?LinkId=182180).
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="AD FS" Guid="{3CFB687A-1571-4ACE-8660-47AB5CDAE2BC}" />
        <EventID>316</EventID>
        <Version>0</Version>
        <Level>2</Level>
        <Task>0</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8000000000000001</Keywords>
        <TimeCreated SystemTime="2016-11-30T19:15:25.145987000Z" />
        <EventRecordID>129</EventRecordID>
        <Correlation ActivityID="{00000000-0000-0000-B2A7-0080000000FB}" />
        <Execution ProcessID="2192" ThreadID="2384" />
        <Channel>AD FS/Admin</Channel>
        <Computer>ADFSAMER-P02.DIR.domain.com</Computer>
        <Security UserID="S-1-5-21-3553630761-160724244-2317416032-1206" />
      </System>
      <UserData>
        <Event xmlns="http://schemas.microsoft.com/ActiveDirectoryFederationServices/2.0/Events">
          <EventData>
            <Data>https://account-d.docusign.com/organizations/977b8629-36e0-4f3b-8542-7d3e66414ec0/saml2</Data>
            <Data>019E89A013F412F8915436AD90B81802CE3A8ED1</Data>
            <Data>CheckChainExcludeRoot</Data>
            <Data>A certificate chain could not be built to a trusted root authority.

    The revocation function was unable to check revocation for the certificate.

    The revocation function was unable to check revocation because the revocation server was offline.

    </Data>
          </EventData>
        </Event>
      </UserData>
    </Event>

    Wednesday, November 30, 2016 8:19 PM
  • I think I may have found the problem but now how to solve it.  The errors I received were:

    Microsoft.IdentityServer.Service.SecurityTokenService.RevocationValidationException: MSIS3015: The signing certificate of the claims provider trust 'https://account-d.docusign.com/organizations/977b8629-36e0-4f3b-8542-7d3e66414ec0/saml2' identified by thumbprint '019E89A013F412F8915436AD90B81802CE3A8ED1' is not valid. It might indicate that the certificate has been revoked, has expired, or that the certificate chain is not trusted.

    Error 12/2/2016 8:31:52 AM AD FS 316 None "An error occurred during an attempt to build the certificate chain for the relying party trust 'https://account-d.docusign.com/organizations/977b8629-36e0-4f3b-8542-7d3e66414ec0/saml2' certificate identified by thumbprint '019E89A013F412F8915436AD90B81802CE3A8ED1'. Possible causes are that the certificate has been revoked, the certificate chain could not be verified as specified by the relying party trust's signing certificate revocation settings or certificate is not within its validity period.

    Up to now, my focus was on the relaying partners cert but it seems the problem is with the certs loaded on my proxy servers.  While the main SSL Cert ( I believed referred to as the service communications cert ) from my third party is still valid on my internal ADFS farm and Proxy Servers (uses the same cert), the ADFS Proxy Trust Certs on my Proxy servers expired last month!

    Why did these expire and how do I renew them?  It claims to be issued by my internal ADFS servers.  Lastly, how can I configure these to auto-renew?

    Note: I tried to upgrade my Windows Management Framework to 5.0 and 5.1 but could not. It kept telling me the version was incompatible with my OS (running Win 2012 R2).  I have no idea why it was refusing it as the download said it was valid for that version.

    Monday, December 5, 2016 2:15 PM
  • After attempting to re-establish the trusts and obtain valid ADFS Proxy Trust client authentication certificates via Install-WebApplicationProxy, I completely host the trust relationship with one of the proxies.  I chose the same thumbprint and federation service name for both proxies.  Now, on the bad proxy, I am getting a slew of eventID 393 and 422 errors.  On the backend, I now have eventid 276 errors.

     It has gone from bad to worse. I would opt to re-install but not sure I won't encounter the same issue. Any ideas would be appreciated.

    Monday, December 5, 2016 10:14 PM