Forum Discussion
Hybrid Azure AD Join (with ADFS present) question about SCP
Regarding Seamless SSO, I know that hybrid Azure AD joined devices still do in fact honor Internet Options' Automatic Logon to Intranet sites if that option is enabled and the Azure AD fqdn is added into the Intranet zone. So it's again, sort of like a partial statement with some validity but without being a better document is just plain confusing and not making any sense, at least not fully.
They say you can choose either ADFS or azure ad
But when choosing Azure Ad remember to add the OU of requires computers
Karim Zaki Thanks for reminding me to update this thread. Yes they did answer me in my GitHub issue, which is here.
But the explanation is a little more detailed than just that we need to sync the OU where the devices sit if/when we choose Azure AD as the Authentication Service.
The answer is that when we have ADFS in use / domains are federated in our O365 tenant, then we can pick either option in AAD Connect for the Authentication Service. Both will work. BUT, when you choose Azure AD, A) you have to make sure you sync the OU where the devices are, and B) you should expect a delay for Hybrid Azure AD Join process to be fully complete and reflect in Azure AD, and this is due to having to wait for the AAD Connect sync interval to take place.
When you choose ADFS instead, the syncing of the OU where the devices are isn't required, because the registered devices will be registered in ADFS/on-premises AD, and so there is no sync delay before the Hybrid Azure AD Join state can be satisfied.
Quoted directly from the GitHub issue, here was my final confirmed explanation, which they confirmed as correct:
to confirm I understand this correctly, customers with federated identity can set the SCP to either ADFS or AAD, but the ADFS option is the one that circumvents the AAD Connect sync delay. If the sync delay is not a concern, those federated customers can instead set the SCP to AAD.
Sound correct? And thanks for coming back to this issue.
It's still a little fuzzy for me as to what would be smarter/smartest to advise a customer to go with, but I will say, I would advise against ADFS in favor of federating directly with Azure AD (i.e., setup single sign-on for Azure AD apps). This opinion is based on the simplicity of Azure AD alone vs Azure AD + ADFS, which continually gets more and more complicated as new things get invented.
JeremyTBradshaw Hey Jeremy, so glad to see this response. Would this explain why hybrid domain join devices (with ADFS) will not sync to Azure AD? Meaning if you disable an OnPrem AD computer, it will not be disabled in Azure AD. I'm wondering how to manage stale computer objects when you have a hybrid domain join with ADFS.
AD FS has nothing to do with syncing attribute values. That's the sole purview of AAD Connect.
If you jump onto the AAD Connect box - and assuming you have the necessary rights to run it - you can launch the sync engine console (miisclient.exe) to check out any synchronisation errors, or even just to get some insight as to what is synchronising from your on-premise forest to Azure Active Directory.
You'd also want to check the AAD Connect configuration wizard to ensure nobody's either discontinued device synchronisation or perhaps even scoped out the on-premise organisational unit you're currently focusing on checking.
You can also break out to a number of different PowerShell modules that cover everything from AD, to AAD Connect, and then AAD itself, but that's not a great place to start. Check your sync configuration and any errors first as mentioned above.
Cheers,
Lain
Edited: Spelling correction.
- I like your explanation very much
