Windows-itpro-docs: Prerequisites

[lightupdifire]

Hello,

About this "Network infrastructure in place to reach your on-premises domain controller. If the machines are external, this can be achieved using any VPN solution."

Please explain what for required network infrastructure?
To connect to servers to build this setup?
From end-user devices of Azure AD Joined PC's that don't have any connection to the on-premise network to use this setup after it will be deployed?
From domain-joined servers that run Azure AD to connect on-premise to the same domain-joined servers?
Or for what?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 43c175ce-52a4-8b46-716f-106b4d55106c
• Version Independent ID: 374a7e9d-6e4f-f188-328b-4ca2651a9481
• Content: Configure Azure AD joined devices for On-premises Single-Sign On using Windows Hello for Business - Microsoft 365 Security
• Content Source: windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base.md
• Product: w10
• Technology: windows
• GitHub Login: @mapalko
• Microsoft Alias: mapalko

[illfated]

Maybe I am missing something or not seeing the issue with that sentence, but I read it as simple as

"Make sure your devices can connect to your on-premises domain controller (if and when necessary), either through the local network, or via VPN if connecting from the outside."

[lightupdifire]

@illfated
This article says "Azure Active Directory joined devices and users on Azure Active Directory joined devices cannot read data from Active Directory", so this article plan is to support Azure AD Joined devices that don't have a connection to the on-premise Active Directory... Then what does this mean here "Network infrastructure in place to reach your on-premises domain controller. If the machines are external, this can be achieved using any VPN solution"? :)

[illfated]

Oh. I see what I misunderstood. Sorry, I took the issue too lightly and superficially.
We will need to wait for someone who knows this topic in depth to answer you.

[joinimran]

@lightupdifire - What I am understanding from the statement "Validate the following configurations to ensure they support Azure AD joined devices." means that this only applies for the users to ensure that their Network Infrastructure should be setup in a way that devices can communicate with Azure AD/Azure AD joined devices.

This is not applicable to everyone or those who have already set up the Network Infrastructure to communicate with Azure AD/Azure AD joined devices.

[lightupdifire]

@joinimran,
I guess this means that we must have the network connection between Azure AD Joined device and between the AD DS services...
Maybe handy to update doc with more detailed info?
Our setup is quite tricky, we like partly hybrid and we try to remove AD FS, still we have on-prem domain wtih AD Connect, but all devices only in Azure AD Join, not Hybrid Azure AD join and we don't have any connection between cloud AADJ devices and on-prem... therefore choosing the right setup quite complex... so would be nice to have more explanation in document, what exactly needed, from where to where etc.

[mapalko]

Illfated's original response on this is correct. The requirement is essentially that the device needs to be on the domain local network or have VPN access to your on-prem network. This guide establishes how an AADJ device can authenticate to an on-prem DC to get back a TGT for accessing AD resources. In order to communicate with a DC, it needs line of sight and this requirement is making sure that is established.

[lightupdifire]

@mapalko
So maybe can explain better in the document. At this moment after reading all docs about WHFB our setup cannot move forward with Passwordless using WHFB if we have: ADFS+ADConnect+IntuneMDM+AADJcloudDevices+WVD+No Network between AADJcloudDevices and on-prem AD... could save some time if would be explained more in detail ;)

[illfated]

@lightupdifire : Sorry for taking so long to review the issue here, but I would like to offer another view on this document.

This is about preparations, before deploying AADJ devices, to make sure that there is a functional connection between the old fleet and the on-premises AD DS. Only after that part has been verified will it be practical to move on to the part of the documentation where AADJ devices can be deployed or added.

Maybe this still does not make sense to you in your scenario, but I just had to make another try to explain my understanding of the document.

I also wonder if your issue could benefit from any feedback provided via your support tenant to Microsoft via other channels.

[lightupdifire]

@illfated No problem, I have completed the setup meanwhile :) But maybe, if a message in the document would be more explained, I even wouldn't start working on this.

In summary, we cannot use WHFB for the WVD solution without having network connectivity from client PC to on-prem.

Why I see it unclear, because this document/setup "Azure AD Join Single Sign-on Deployment" is talking about "Azure AD Joined" devices and it is talking about "Unlike hybrid Azure AD joined devices, Azure AD joined devices do not have a relationship with your Active Directory domain" and like "Certificate enrollment for Azure AD joined devices occurs over the Internet. As a result, the internal NDES URLs must be accessible externally. You can do this easily and securely using Azure Active Directory Application Proxy. Azure AD Application Proxy provides single sign-on and secure remote access for web applications hosted on-premises, such as Network Device Enrollment Services.", this give a message that there is No connectivity between on-premise network and client PC, but then there is a big BUT, you still need network connectivity :)

In general, now, for this document I can accept current sentence. But I think would be nice to explain more. Closing case.

[illfated]

Fair enough, thank you for taking the time to share your views in such detail.

@mapalko : I presume you are quite busy with work, as well as preparing for the upcoming seasonal holidays, but do you have any thoughts to share on the closing comment?

[mapalko]

I don't think the customer use case actually falls under the scenario that we are trying to address in the docs. The goal of this doc is to provide access to on-prem resources tied to AD DS that a user would access from an Azure AD Join device. If the customer has Azure AD Joined devices that do not have any network relationship with on-premises AD, then those devices would never have the ability to try to access AD resources, making this article not applicable.

If the customer is using ADFS as a way to federate these devices for on-prem resources, that is a separate scenario but one that could be enabled by deploying certs to the Azure AD Joined device.

[illfated]

Thank you for the feedback. Very well. I will leave this issue in peace, seeing as there is so much else to get done.

/sign-off

[illfated]

^{(ref. #8776 )}

[erottier]

Illfated's original response on this is correct. The requirement is essentially that the device needs to be on the domain local network or have VPN access to your on-prem network. This guide establishes how an AADJ device can authenticate to an on-prem DC to get back a TGT for accessing AD resources. In order to communicate with a DC, it needs line of sight and this requirement is making sure that is established.

Then how about my case when the AADJ device opens Outlook? Since the laptop only opens Outlook, this should be doable by TCP 443 instead of a whole tunnel.
Isn't the Exchange server doing the authentication for the user then? Kinda as a proxy?

Also, this whole document doesn't use any VPN access whatsoever. So, still, why the prerequisite?

As far as I'm concerned, very, very simplistically it says:

• Do some AAD Connect things
• Open up a CRL distro via IIS/fileshare
• Reissue DC certs
• Export the certs
• Import the certs into Azure _(so, online then, still disconnected from on-prem)_
• Enroll device with WhfB

Am I missing a VPN or another live connection anywhere...?

[mapalko]

If you are using Outlook with Microsoft 365 or Office 365, then Outlook authentication is generally done through Azure AD and this article is not applicable.

The device and AD configuration does not require VPN, but actual resource access generally does. The main scenario for this article is there is some resource hosted on-premises that requires Kerberos or NTLM authentication (like a local file share). In order to authenticate to the KDC and get back a TGT, you need to have network line of sight to the KDC. You would also need network line of sight to the resource you actually want to access.

[illfated]

Thank you. I was uncertain myself. Glad you had time to clarify. Thanks again. 👍🏻

[erottier]

If you are using Outlook with Microsoft 365 or Office 365, then Outlook authentication is generally done through Azure AD and this article is not applicable.

I'm guess I wasn't clear that Oulook is using Exhang on-prem. Also I think SharePoint accessable on-prem via intenet would have the same issue.

I'm talking about cloud only clients using on-prem resources accessable via internet before WhfB via authentication prompts.

So while you could use a VPN, it technically NOT a prerequisite.

As in, you don't need gas for a car if you only want to showmodel it.

Personally, especially because it's just plain confusing, I would put it in another 'informational' section that explains if you would like to reach on-prem resources you have to enable your own access, like a VPN. That would, very much, tell us what that sentence actually means and does. It's NOT a requirement, only a friendly warning?

[mapalko]

The scenario that you are describing where an on-prem resource is exposed to the internet is not the target scenario for this use case. We can more be more specific in the goal of the article and deployment model. I would probably want to make the changes on https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso page and leave this existing deployment page as is.