3

I am trying to follow articles https://msdn.microsoft.com/en-us/library/azure/dn641269.aspx https://support.google.com/a/answer/6363817?hl=en

for domain school.edu

When I open a private browsing window and go to login.microsoftonline.com and specify a user at my domain, I am redirected as expected to Google for login & password. However, after entering valid credentials, I am redirected to a Microsoft login page with the error

I get error Additional technical information: Correlation ID: [redacted, not sure if this is a sensitive ID] Timestamp: 2017-05-11 19:15:31Z AADSTS50107: Requested federation realm object 'https://accounts.google.com/o/saml2?idpid=[id]' does not exist.

The URL listed there returns a 404 when accessed directly, but https://accounts.google.com/o/saml2/idp?idpid=[id] can be accessed directly (albeit with an error for a malformed SAML request). I specified the idp?idpid=[id] as the LogOnUri over powershell but it does not seem to be pulling from that value there.

I am unsure how to proceed from here, beyond opening a ticket with Microsoft (they were unable to help the last time we attempted SSO via different means, perhaps a year ago).

samh
  • 131
  • 3
  • Ultimately we have a subset of users that need access to Office365 *and* G Suite. I am trying to avoid having to provision two sets of users, with potentially non-matching passwords… currently we are able to tell these users they have on set of credentials for "everything" online and one set for local network resources and we would like to keep it that way. – samh May 12 '17 at 13:45

1 Answers1

0

Once the user is created in Office365, their Immutable IT will need to be set. It should match their Google user primary email address which should also be their MS Username.

Launch Powershell

Import-Module MSOnline
$Msolcred = Get-Credential
Connect-MsolService -Credential $MsolCred
set-msoluser -userprincipalname USERNAME -ImmutableId SAME USERNAME

Followed this process with some modifications.

This got it working for me. ImmutableID is the issue and is normally handled by the AzureAD Connect service which doesn't exist if you don't run local AD infrastructure.

Jason Bradford
  • 29
  • 2