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

Joseph Sturtevant 106 Reputation points
2020-04-29T04:24:52.813+00:00

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?

Microsoft Entra ID
Microsoft Entra ID
A Microsoft Entra identity service that provides identity management and access control capabilities. Replaces Azure Active Directory.
19,455 questions
0 comments No comments
{count} vote

Accepted answer
  1. Joseph Sturtevant 106 Reputation points
    2020-05-12T05:36:45.27+00:00

    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 person found this answer helpful.

0 additional answers

Sort by: Most helpful