Sign-in to Azure AD through 3rd Party Federation Service

[PyungraeCho]

Sometimes customers want to implement redirection for Azure AD authentication with their IDP already in use. This 3rd party solution has been around for a long time and the customer doesn't want to change the provisioning process at all. Also, this 3rd party federation does not provide a wizard for authentication connection with Azure AD like ADFS, Okta and Ping Identity. How can we configure authentication redirection in the customer environment below?

As you already know, it cannot be configured in the "User Sign-in" menu of Azure AD Connect. There are no options to choose from. Therefore, the "User Sign-in" method can only be "Do not Configure". After that, the federation connection can be set up manually using the powershell at the link below.

Set-MsolDomainAuthentication (MSOnline) | Microsoft Docs

When using this PowerShell, information such as the DomainName, Sign-in Certificate and the URL to be used must be checked in advance. For reference on which values can be used, you can check the configuration information by using Get-MsolDomainAuthentication powershell when connecting to ADFS.

If you have completed the 3rd party federation configuration with ‘Set-MsolDomainAuthentication’ powershell, you will be able to check that the logon page is redirected when you try to log on to Azure AD. However, if you try to log on from the federation logon page, you will check an error message as shown in the figure below. However, this user account will actually exist in Azure AD.

To solve this issue, we will still find the answer in ADFS. If you refer to the link below, you can find out what information is required when ADFS and Azure AD are connected.

Azure AD RPT Claim Rules | AD FS Help (microsoft.com)

Among the claims of ADFS, the two most important things will be ‘Sign-in’ and ‘ImmutableID(=SourceAnchor)’ information. In order for Azure AD to allow authentication, these two claims information in the ADFS token must match the information in Azure AD.

Azure AD Connect uses the 'objectGUID' (actually base64-encoded values are used) value among the properties of the AD user account to determine uniqueness between the AD account and the account synced to Azure AD. (Detail : Azure AD Connect: Design concepts | Microsoft Docs)

'objectGUID' is a value assigned when an AD user object is created. If you look at the configuration diagram at the beginning of this post, this 'objectGUID' value cannot exist in 3rd party LDAP (ID Store). So it is not possible to make a claim that can match the 'ImmutableID' of Azure AD.

As a result, in order to solve the logon failure issue, it is necessary to change the items that determine uniqueness. When configuring Azure AD Connect for the first time, it can be changed to a specific value other than the default value (objectGUID). In addition, in the federation service, it is also necessary to designate a claim with an LDAP attribute that can match this changed value.  

For example, it was defined as shown in the table below, and Azure AD logon through 3rd party federation succeeded normally.

Finally, the authentication uniqueness error between Azure AD and federation could also be found on the Okta website.

SSO from Okta to office365 shows error: AADSTS51004

[#2]

Thank you for sharing.
However we always recommend Azure AD because of its features and security benefits.

[#3]

Of course you are right. I think so too. It is right to be used when the customer really insists on such an environment. This is a only technical approach, not recommended for use. ^^.

[#4]

True, in case I am decision maker , I will fully relay on Azure and Microsoft Cloud because of its integrity and security. However, like you mentioned there are those who insist on third-party solutions and we must follow.