Using Google as IDP for O365

[Jon Mann]

Hi All,

I am attempting to utilize SSO into O365 via our Google IDP and am running into some snags. When the user attempts to authenticate, they are properly redirected to the Google sign-in page, however after successful authentication the user is returned to the Microsoft O365 sign-in page. I have had Google support confirm that they flow looks correct on their end. I'm having trouble seeing where the failure is on the Microsoft end. My suspicion is that it's bc our AD domain is corp.company.com rather than company.com as our email is. However, I did change the UPN from AzureAD to reflect the email attribute as the primary. (since that value is the same as the Google email address. Anyone have any insight into this configuration?

Thank you and have a happy new year.

-Jon

[#2]

Do you have any error message to share?

[#3]

Thank you for your response. Unfortunately no error message is generated. Unless I should be looking somewhere else for failure messages.

Best,

Jon

[#4]

Well, how do you know it doesn't work if there is no error message ;) If it fails at the Azure AD page, you should see a short message at the bottom in the "Additional information" section. Do you have anything there?

Maybe a fiddler trace might help... If you are willing to share one, ensure you remove sensitive information from it (like passwords or usernames).

[#5]

Hi Pierre,

I've attached my Fiddler capture. I removed any entry that mentioned my user/domain/password. Hopefully you don't miss any of the interaction with this. 

I do not see an additional information page. When logging in from portal.office.com I am returned to the login page with no status update. When logging in from portal.azure.com I get the following message:

Both do not seem to show any additional information.

Best,

Jon

[#6]

Your error message is on the frame 90:

AADSTS51004: To sign into this application the account must be added to the 123abc89-abcd-1234-1234-abcdabcd directory.
Trace ID: d8f05825-16fa-4ea6-924b-63fdf34e0c00
Correlation ID: a58ee092-b0ee-40f2-902f-4863b19d6240
Timestamp: 2018-01-08 22:41:56Z

You don't have access with the account you specified in the NameID:

  <saml2:Subject>
    <saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">azure.test@contoso.com</saml2:NameID>
...
  </saml2:Subject>

It seems that the NameID should have the immutable ID of the user you have provisionned in Azure AD. So what immutable ID did you use for the representation of that user? There is a bit more information here: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-federati...

[#7]

Hi Pierre,

Thank you for that insight! I am using AzureAD connect to synchronize these users from my on-premise AD so the ImmutableID is being set automatically. I took steps to consciously set the UPN to the email attribute so that there is a match there on the Google side. I think I incorrectly assumed this would take care of the ImmutableID as well.

What steps can I take in order to control the ImmutableID if I am using this sync method instead of creating users via PowerShell?

Best,

Jon

[#8]

There are some explanations there: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-design-c... tell us if that helps!

[#9]

Hi Pierre,

Thank you for helping clear this up. I'm still unsure of the difference and usage between userPrincipleName & sourceAnchor. Our IDP will be identifying the user via email address since Google is our email provider and knows each user's email address.

We are not using samAccountName to identify users as our windows domain is corp.company.com rather than company.com

What would you recommend the userPrincipleName & sourceAnchor values be set as in order to make this functional (I noticed in that article that '@' may not be supported for sourceAnchor)?

Best,

Jon