Forum Discussion
Hybrid Azure AD Join (with ADFS present) question about SCP
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.
LainRobertson hey Lain, thx for the reply...i understand that AAD connect is the one doing the syncing, not ADFS. What i wanted to clarify is this statement from Microsoft below regarding managing stale hybrid domain join devices
If you have Hybrid Domain Join with ADFS, machines disabled onPrem will not be synced to Azure AD
That's not correct.
What the boxed-in-red part is saying is that if you:
- Do not use AAD Connect; and
- You do not have Windows 10 or newer devices; then
You must manually manage the Azure AD device objects.
This is simply because AAD Connect will only manage Windows 10 or later device objects.
The reference to AD FS is simply acknowledging that it performs an authentication function in environments that have AD FS (even if you don't use AAD Connect), and for which the registered domain is classified as Federated and not Managed.
Here's an illustration of a disabled Windows 10 device in AAD (first command line result) and on-premise (second command line result.)
Below, you can see from miisclient.exe (on the AAD Connect host) where and how this is being calculated from on-premise.
Lastly, you can see via the official documentation that this is an intended attribute flow (i.e. not something we've customised.)
Attributes synchronized by Azure AD Connect - Microsoft Entra | Microsoft Docs
In short, if your domain is Federated, you operate AAD Connect and have Windows 10 devices, then enabled/disabled should certainly (subject to AAD Connect configuration, scoping, etc.) be synchronising.
Cheers,
Lain
Edited: Re-phrased fourth paragraph to be less ambiguous (hopefully) in it's interpretation, plus fixed a typo.
