question

JosephSturtevant-5369 avatar image
0 Votes"
JosephSturtevant-5369 asked ·

Issue with SAML between GSuite (IdP) and Office 365 / Azure AD (SP) - Sign-in error code 5000811

I'm trying to set up SAML and user provisioning between GSuite (IdP) and Office 365 / Azure AD (SP). I've followed guides here, here, here, here, and here. I've got the domain federation set up and users provisioning but login attempts using SAML on the Office 365 site just redirect back to the login page and the Azure AD Sign-In log shows a failed login attempt with a sign-in error code of 5000811.

Here is a capture of one such SAML login attempt:

https://accounts.google.com/o/saml2/idp?idpid=C01e6b1qz

 <samlp:AuthnRequest ID="_25af60c7-9c62-49ed-a04e-52b4dc6d44f7"
     IssueInstant="2020-04-29T04:01:41.286Z" Version="2.0"
     xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
     <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:MicrosoftOnline</Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/></samlp:AuthnRequest>

https://login.microsoftonline.com/login.srf

 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
 <saml2p:Response Destination="https://login.microsoftonline.com/login.srf"
     ID="_3e5876c028b1bd3cb02f9e21bb8652cb" InResponseTo="_25af60c7-9c62-49ed-a04e-52b4dc6d44f7"
     IssueInstant="2020-04-29T04:01:45.172Z" Version="2.0"
     xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol">
     <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://accounts.google.com/o/saml2?idpid=C01e6b1qz</saml2: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="#_3e5876c028b1bd3cb02f9e21bb8652cb">
                 <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>hFv3c7wglEpUfAtC5tfAqwcmZ302JKyfB71rWU+U/PM=</ds:DigestValue>
             </ds:Reference>
         </ds:SignedInfo>
         <ds:SignatureValue>h9Zi2mm0vrrXPVy8LzgU6xshrhgQXABrXzLVc0cHu3B/EQe7lkJy00j6kKNJf0Fs8qslVPTDQXSy
             GCyQ0sjCgMFGxMCNp1vgtEhg+GQGVkTpoStGc/dEHzmRSvP/p8fD73/MFr54j47o46k0KbZbAtHV
             jYovZ15P7X4nSxvWegTa3B2Ke8/eI1RSOQOMQ4EQwBaDAnbc89/ipBH1V1GSg2MRkLSMRY8YvugE
             JZDuNhqDFkv0OiHhqSheQH6GPu9ad0q95u9aPIQT9kvGsVKEYr1QNXRYcWSp2iqhCALP8E3xtuB3
             F0mtDqTdGJgmTtR0cM6oKxBdH8fcLXDkz+c/5g==</ds:SignatureValue>
         <ds:KeyInfo>
             <ds:X509Data>
                 <ds:X509SubjectName>ST=California,C=US,OU=Google For Work,CN=Google,L=Mountain View,O=Google Inc.</ds:X509SubjectName>
                 <ds:X509Certificate>MIIDdDCCAlygAwIBAgIGAXHC4pumMA0GCSqGSIb3DQEBCwUAMHsxFDASBgNVBAoTC0dvb2dsZSBJ
                     ... redacted ...
                     ohOZMpoWRxM+I5kLLsfdTJUdtQR6qjm8Wr2/u/7YXqDU</ds:X509Certificate>
             </ds:X509Data>
         </ds:KeyInfo>
     </ds:Signature>
     <saml2p:Status><saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></saml2p:Status>
     <saml2:Assertion ID="_294703aa6483ebba7d0db50bd07fc32e" IssueInstant="2020-04-29T04:01:45.172Z"
         Version="2.0" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
         <saml2:Issuer>https://accounts.google.com/o/saml2?idpid=C01e6b1qz</saml2:Issuer>
         <saml2:Subject>
             <saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">joseph@maddoxtransformer.com</saml2:NameID>
             <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml2:SubjectConfirmationData InResponseTo="_25af60c7-9c62-49ed-a04e-52b4dc6d44f7"
                 NotOnOrAfter="2020-04-29T04:06:45.172Z" Recipient="https://login.microsoftonline.com/login.srf"/></saml2:SubjectConfirmation>
         </saml2:Subject>
         <saml2:Conditions NotBefore="2020-04-29T03:56:45.172Z" NotOnOrAfter="2020-04-29T04:06:45.172Z">
             <saml2:AudienceRestriction>
                 <saml2:Audience>urn:federation:MicrosoftOnline</saml2:Audience>
             </saml2:AudienceRestriction>
         </saml2:Conditions>
         <saml2:AttributeStatement>
             <saml2:Attribute Name="IDPEmail">
                 <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
                     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:anyType">joseph@maddoxtransformer.com</saml2:AttributeValue>
             </saml2:Attribute>
         </saml2:AttributeStatement>
         <saml2:AuthnStatement AuthnInstant="2020-04-22T14:02:32.000Z"
             SessionIndex="_294703aa6483ebba7d0db50bd07fc32e">
             <saml2:AuthnContext>
                 <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml2:AuthnContextClassRef>
             </saml2:AuthnContext>
         </saml2:AuthnStatement>
     </saml2:Assertion>
 </saml2p:Response>

How should I troubleshoot this?






azure-active-directory
10 |1000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

1 Answer

JosephSturtevant-5369 avatar image
1 Vote"
JosephSturtevant-5369 answered ·

The solution (for anyone who may come upon this in the future) turned out to have been a mismatch in the certificate between what was provided by the IdP (Google) and what was configured on the federated Azure AD domain via the Set-MsolDomainAuthentication cmdlet. That cmdlet appears to have an issue where in some circumstances it will not update the certificate. I only discovered this on close inspection of the response from the Get-MsolDomainFederationSettings cmdlet and confirmed that the certificate was not updating after the Set-MsolDomainAuthentication was run. (Possibly the command was failing silently?) I tried using the Set-MsolDomainFederationSettings cmdlet with the following command and that did successfully update the certificate at which point SAML authentication began to work properly.

 Set-MsolDomainFederationSettings `
   -DomainName $domainName `
   -SigningCertificate $signingCertificate `
   -PreferredAuthenticationProtocol "SAMLP"
· 1 ·
10 |1000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Thank you for sharing your findings with the community . Much appreciated.

0 Votes 0 ·