Azure SSO connection not authenticating subset of users

[Craig Steel - F]

I have a client who is - due to a merger / acquisition - migrating from their local Azure install to a cloud-based one run by their new owners.

We have gone through the Azure SSO config to change Identity Providers, and everything appeared to be working correctly.  Their existing users are able to authenticate and access SN as normal, using the new ID provider.  Except for a small subset of users who have a different email address than the normal corporate standard.  Think "instead of user@NAMEOFORG.COM these users have an email address that is user@somethingelse.com".

I don't have visibility into their Azure data (I'm just trying to configure the SN side of things) but I have been told that the difference in email address is the only shared trait amongst these 10 users.  These 10 users COULD log in using the local Azure install ... which leads me to believe that there is something else configured on the Azure side that I am not aware of.

I've tried switching the NameId Policy between emailAddress & unspecified which hasn't changed anything.

Using standard scripting, pretty much a vanilla SSO identity provider, "email" as the User Field, etc.

Just looking at some directions I should be looking to try and sort this out short of switching back to the local provider - that's not a long term option.  Neither is getting them email addresses that align with the standard, there are business driver to why they are different.

Any help appreciated.  If there are screenshots that might provide more information, let me know and I'll post.

Thanks,

CrS

[Craig Steel - F · Accepted solution]

Going to reply to my own post and close it ... but leave this here for the next person who is faced with the same issue.

It DID in fact turn out to be a config on the Azure side.  Rather than the default email address as the login attribute on the Azure side, they were using UPN.  Changing it to the default setting solved the problem.

Wish I could provide further clarity than that, but my Azure knowledge isn't large enough to get into the details.

[TheJKNomad]

Troubleshooting checklist

Use the following checklist to troubleshoot Seamless SSO problems:

• Ensure that the Seamless SSO feature is enabled in Microsoft Entra Connect. If you can't enable the feature (for example, due to a blocked port), ensure that you have all the prerequisites in place.
• If you have enabled both Microsoft Entra join and Seamless SSO on your tenant, ensure that the issue is not with Microsoft Entra join. SSO from Microsoft Entra join takes precedence over Seamless SSO if the device is both registered with Microsoft Entra ID and domain-joined. With SSO from Microsoft Entra join the user sees a sign-in tile that says "Connected to Windows".
• Ensure that the Microsoft Entra URL (https://autologon.microsoftazuread-sso.com) is part of the user's Intranet zone settings.
• Ensure that the corporate device is joined to the Active Directory domain. The device doesn't need to be Microsoft Entra joined for Seamless SSO to work.
• Ensure that the user is logged on to the device through an Active Directory domain account.
• Ensure that the user's account is from an Active Directory forest where Seamless SSO has been set up.
• Ensure that the device is connected to the corporate network.
• Ensure that the device's time is synchronized with the time in both Active Directory and the domain controllers, and that they are within five minutes of each other.
• Ensure that the AZUREADSSOACC computer account is present and enabled in each AD forest that you want Seamless SSO enabled. If the computer account has been deleted or is missing, you can use PowerShell cmdlets to re-create them.
• List the existing Kerberos tickets on the device by using the klist command from a command prompt. Ensure that the tickets issued for the AZUREADSSOACC computer account are present. Users' Kerberos tickets are typically valid for 10 hours. You might have different settings in Active Directory.
• If you disabled and re-enabled Seamless SSO on your tenant, users won't get the single sign-on experience until their cached Kerberos tickets have expired.
• Purge existing Kerberos tickets from the device by using the klist purge command, and try again.
• To determine if there are JavaScript-related problems, review the console logs of the browser (under Developer Tools).
• Review the domain controller logs.
  
  Reference Link

[Craig Steel - F]

Not sure I ever want to become an Azure support guy, 😆 but thanks for the reply.  I'll reference back to this to hand over to my client's support team if this ever comes up again.