Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community

Hybrid Azure AD Join (with ADFS present) question about SCP

Steel Contributor

Configure hybrid Azure Active Directory join for federated domains | Microsoft Docs

 

The article above has got me curious and I can't find an answer to my questions.  I've also opened an issue on GitHub, and have read as many blog articles as I can find, but all that I've found just repeat the info that is stated in the Docs article.

 

In the section Configure hybrid Azure AD join step 6.b states:

 

Select the authentication service. You must select AD FS server unless your organization has exclusively Windows 10 clients and you have configured computer/device sync, or your organization uses seamless SSO.

So then, let's say we have all Windows 10, the statement leaves two possibilities:

  1. We also have setup Seamless SSO (I assume this means Azure AD Connect's checkbox and related configuration via GPO)
  2. We have not setup Seamless SSO, and instead are taking advantage of Windows 10's Primary Refresh Token capability (link)

I can understand that if we fall into #1, then we need to select our ADFS for the Authentication Service. But why is that? SSSO involves automatic logon to an internet (Microsoft/Azure AD) URL; it doesn't involve ADFS. For ADFS' own SSO to work, the ADFS STS URL (or FQDN) needs to be added to the Local Intranet zone which needs to be configured for for automatic logon. So SSSO and ADFS SSO are two different things. Therefore, it's not clear why SSSO has any bearing on this choice for the SCP config's Authentication Service. What is the reason for this?

 

Next, if we fall into #2 (no SSSO configured in AAD Connect (and related additional config that goes with it)), why might we choose ADFS over Azure AD? Similarly, why might we choose Azure AD over ADFS?

 

There is one other part of the article that is also unclear to me, again related to the Authentication Service.  If we have the Authentication Service set to use Azure AD, do we still need to worry about this ADFS-based pre-requisite?:

 

A federated environment should have an identity provider that supports the following requirements. If you have a federated environment using Active Directory Federation Services (AD FS), then the below requirements are already supported.

WIAORMULTIAUTHN claim: This claim is required to do hybrid Azure AD join for Windows down-level devices.
WS-Trust protocol: This protocol is required to authenticate Windows current hybrid Azure AD joined devices with Azure AD. When you're using AD FS, you need to enable the following WS-Trust endpoints: /adfs/services/trust/2005/windowstransport /adfs/services/trust/13/windowstransport /adfs/services/trust/2005/usernamemixed /adfs/services/trust/13/usernamemixed /adfs/services/trust/2005/certificatemixed /adfs/services/trust/13/certificatemixed

Specifically the WS-Trust protocol.. If the SCP / Authentication Service is pointing to Azure AD, I'm unsure if this requirement is still relevant.  I assume the answer to this last part is yes, and the reason for that assumption is the Office 365 relying party trust claim rules that need to be added to support HAADJ.  Not sure though if I'm correct on this assumption or not.

 

Does anyone happen to have clarity around this that you can share with me?

 

Thanks in advance.

10 Replies
Bump... Also I'll simply ask - what exactly is "Authentication Service", and where does this chosen value from the AAD Connect config wizard translate to in actual configuration? I don't see any sign of the chose Authentication Service within the SCP object itself. I also see no mention of "Authentication Service" in any of the functions included with the various PS modules packaged with AAD Connect.

This topic that is the "Authentication Service" is truly mysterious.

@Jeremy Bradshaw 
I agree it's somewhat convoluted and I can't answer all of your questions but in terms of the authentication service, this is my understanding - think of how a user authenticates when logging into a laptop let's say - is it against a domain controller or Azure AD? Since we're talking about Hybrid Azure AD Join, Azure AD Connect, etc. I'm assuming in your case it's the first and you're dealing with a federated domain so the authentication service would be your ADFS server. Similarly, when you log into portal.office.com or portal.azure.com etc. and enter myname@mycompanysfederateddomain.xyz Microsoft will recognize the domain is federated and send you to your ADFS server to enter your credentials. If you were logging in as myname@mycompany.onmicrosoft.com, then authentication would happen on Microsoft's end in Azure AD and that would be your authentication service.
As to Seamless SSO in the context of Hybrid Azure AD Join and Windows 10, please note this bit from the docs:
"For Windows 10, Windows Server 2016 and later versions, it’s recommended to use SSO via primary refresh token (PRT).
Seamless SSO needs the user's device to be domain-joined, but it is not used on Windows 10 Azure AD joined devices or hybrid Azure AD joined devices. SSO on Azure AD joined, Hybrid Azure AD joined, and Azure AD registered devices works based on the Primary Refresh Token (PRT)"
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso

Thanks for the response. I guess I'm not getting any clarity still though about the docs article and the guidance on when vs when not to set the authentication service to adfs. By your description, and otherwise what makes sense, it seems if your O365 domains are federated then you should set it to adfs. The other points (in the article, same section/paragraph) are like misplaced noise adding nothing by confusion.

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.
Git hub answered your thread i saw it
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.

I like your explanation very much

@Jeremy Bradshaw 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.

@clicnam 

 

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

 

2022-06-24 08_13_39-How to manage stale devices in Azure AD - Microsoft Entra _ Microsoft Docs.png

 

If you have Hybrid Domain Join with ADFS, machines disabled onPrem will not be synced to Azure AD

 

 

@clicnam 

 

That's not correct.

 

What the boxed-in-red part is saying is that if you:

 

  1. Do not use AAD Connect; and
  2. 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.)

 

LainRobertson_0-1656027459499.png

 

Below, you can see from miisclient.exe (on the AAD Connect host) where and how this is being calculated from on-premise.

 

LainRobertson_1-1656027627303.png

 

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.