locked
AD FS omitting SAML assertions from SAML Response when Assertions Encryption is enabled RRS feed

  • Question

  • I've been trying to configure AD FS to encrypt SAML assertions using the SP's public certificate.

    I provided the SP certificate manually in the "Encryption" window. Also tried configuring the Relying Party Trust directly with the SP metadata file, where AD FS correctly picked up the certificate.

    SSO works fine if I remove the Encryption option. However, after attempting SSO with Encryption enabled, AD FS is simply omitting the assertions (which include Name ID and other tokens the SP requires for authentication) from SAML Response and SSO is failing. Here's the sample SAML response captured by SAMLTracer:

    <samlp:Response ID="_2f8284be-4d9b-4b53-9bd2-729d6d9e5810"
                    Version="2.0"
                    IssueInstant="2015-10-29T13:17:50.847Z"
                    Destination="https://ninadcloud.drtst.org/wrsaml/consume"
                    Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
                    InResponseTo="_be3b446f85e8ecd4fe1b36eda0bb80787a49d85c"
                    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                    >
        <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://sso.testadfs.com/adfs/services/trust</Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
                <ds:Reference URI="#_2f8284be-4d9b-4b53-9bd2-729d6d9e5810">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
                        <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
                    <ds:DigestValue>YPEeVEzmQPDhVc6sZvgf9Z51VEEckw1nQa37zlw1OLw=</ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>PW1pTA/nqY4eWF4JbUBT1RgU9/ewmDa6UP6C/hq4mj5PbT9fYVkonZOfkOsqKhu19BKWHsb+91EseHI0+KKMcvsJBB74vUiJnxSf+9/qo3pvOwLb37xu95bWNNQ4z+NaK2JMGdbxqmi70i2gpCCmvAdqJROY3X0QYJEmFHfvsuQ2VoeHg3inCD1ZqQZFXH0Ip/Y5ZjZ17Jx6p2SW4J1twvNrZbQm6w/UNNsfmQe2+q6aHbvnpYK6emZpU2yYatHqZeuzVUsV97m0zktOUnBHfrCmhjB5bdSflV/xOHWKA4EHhqvbokebMkzn7UXn7dro7YfoNxGI8Zg0elPmn+rw/Q==</ds:SignatureValue>
            <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
                <ds:X509Data>
                    <ds:X509Certificate>MIIC3DCCAcSgAwIBAgIQUc0jsqDTdrlDqOsazPdFYTANBgkqhkiG9w0BAQsFADAqMSgwJgYDVQQDEx9BREZTIFNpZ25pbmcgLSBzc28udGVzdGFkZnMuY29tMB4XDTE1MDQxNzE2MDc1NFoXDTE2MDQxNjE2MDc1NFowKjEoMCYGA1UEAxMfQURGUyBTaWduaW5nIC0gc3NvLnRlc3RhZGZzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKAN9bv2ETwKs6ZKQ6gauC/rZppuuVP10WYHJgHcOayU4C/ztxf14mPYS3liP0qFK7eVzN/KjK7MSyODrbUfq4bPwCTkTgHrv/8fsKxmD/8DrCJ+Mem+xCqvzrOml2WrOagLKm0tGL8dHWBhMVmfupp1TNvAyEkKvach33gaaP5GpDoz1XaotilD5rKIpYwIBHr3N8/EdyBRDVgYhMoMFL5WHJ6It/Lf9VPrw7rpV/VzdC+yJwYBpEUcvyIU8/Y8eU9xdwNyXc5s79khXOLFxqU5Lemv7WFLeuu6ZlXGL0k158nUByScRVLqEZ3bTAW4BO3Xn1O0r5boYIkOZRqzYakCAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAaKH6K3GJl4+eXplkfH/J3Sbj5BsuV5F3TPW2XHiVc7SqlmmHNoDGu+zxn+jB8VWlG4WPEzhBwildIcBZUfvEol8CsTMNS9Zg9MKosXbrdnhHq+5tvRPOAO87TcjXloxtKS/zFYRJApskdJWLAbmJ7VSDSqVWTBBFmYsc93LE0VAJp1vuc1I3tfQ8QPrGst+fYHbrZbB/24oOsPSLeUNxZ+lCTO+/yvCbH80j+NSXULtsZUvamAMT0P7FnjWsyTkNYbSoKqv59ZaRJWn7jTuUsv3VBHYube2tKiuujH733l8+sN7vr7aQjYPwKs1S3rKb7XXZ2Y5IXdfXHCbPbqI4fw==</ds:X509Certificate>
                </ds:X509Data>
            </KeyInfo>
        </ds:Signature>
        <samlp:Status>
            <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder" />
        </samlp:Status>
    </samlp:Response>

    Looking at the event logs, looks like AD FS is rejecting the SP certificate (which is internally signed and corresponding CA has been added to local Trusted Root Certification Authorities).

    An error occurred during an attempt to build the certificate chain for the relying party trust 'xxxxx' certificate identified by thumbprint '7CDBxxxxx'. 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:  
    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).

    How can I make AD FS work when Assertion Encryption is enabled?

    Friday, November 20, 2015 8:41 AM

Answers

  • According to the error message, it looks like the certification revocation check is failing.

    Can you make sure you can access to the CRP and AIA mentioned in the extensions of the certificate you are using for token encryption? You can use the following command to test that from your ADFS server:

    certutil -f -urlfetch -verify YourCert.cer

    If your environment requires to use an HTTP proxy to fetch those URLs, you can use netsh to set it up. Here is an example:

    netsh winhttp set proxy YourProxy:8080

    Let us know how it goes.

    You can also try to disable the revocation check completely for testing purposes:

    Set-ADFSRelyingPartyTrust -Targetname "Your trust" -EncryptionCertificateRevocationCheck none
    It is not recommended to disable it though.


    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 20, 2015 11:04 PM

All replies

  • According to the error message, it looks like the certification revocation check is failing.

    Can you make sure you can access to the CRP and AIA mentioned in the extensions of the certificate you are using for token encryption? You can use the following command to test that from your ADFS server:

    certutil -f -urlfetch -verify YourCert.cer

    If your environment requires to use an HTTP proxy to fetch those URLs, you can use netsh to set it up. Here is an example:

    netsh winhttp set proxy YourProxy:8080

    Let us know how it goes.

    You can also try to disable the revocation check completely for testing purposes:

    Set-ADFSRelyingPartyTrust -Targetname "Your trust" -EncryptionCertificateRevocationCheck none
    It is not recommended to disable it though.


    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 20, 2015 11:04 PM
  • Any update on this?

    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 25, 2015 11:13 PM
  • Thank you Pierre.

    I replaced our internally signed certificate with a certificate signed by a Trusted CA. Which solved the problem for our AD FS 3.0 setup.

    However, SSO still wouldn't work with AD FS 2.0 and was failing with the same error (revocation check failing). Certutil, meanwhile, returned "Leaf certificate revocation check passed". SSO worked when I manually set EncryptionCertificateRevocationCheck to None as per your suggestion.

    And it's been working even when I turned the revocation check back on: set EncryptionCertificateRevocationCheck to CheckChainExcludeRoot, its previous value! One of above two actions seems to have permanently fixed the revocation check issue for the certificate, and I cannot figure out exactly how!

    Again, thanks for the pointers. It seems to be working now.

    Thursday, November 26, 2015 11:39 AM