WHFB Hello change farm

Question

Hello,

I have an ADLDS farm on Win2016 adfs.domain.com, I installed a new one on Win2019 fs.domain.com. I would like now to make sure my new farm act as the registration authority when configuring MS Hello internally in the enterprise. But I have no idea how my computer knows which farm it need to point to.

In other words, currently when I try to setup Hello, my computer contact adfs.domain.com instead of the new farm.

Would you help with this? Thank you.

Yann

---

Answer 1

If you are planning to use an Hybrid deployment, the ADFS service used by the clients is the one federated with Azure AD.

Answer 2

Okay that's a good beginning. At that stage, I don't want to use an hybrid deployment. I federated my domains for O365.

With Get-MsolDomainFederationSettings I can see that my computer's domain is federated with fs.domain.com. (Many others domains are still federated with the previous adfs.domain.com).

My computer/client dNSHostName is ComputerName.domain.local and my username is name.surname@keyman .com.

With all this, is it possible to help to clarify the situation? Yes I'm beginner with all of this.

Thank you.
Yann

Answer 3

Well, if you have Office 365, you have Azure AD. And unless you don't synchronize your on-premises identities to Azure AD, you already have an hybrid situation going on :)

In order to do Windows Hello for Business when your identities are both in the cloud and on-premises, you'll need to decide what type of trust you want to use. The type of trust determines how the user will authenticate against the on-premises DCs when they used Windows Hello for Business at logon time. WH4B is a sort of certificate based authentication from the DCs point of view. So if order to do certificate authentication, you'll need either actual certificates, or something that looks like certificates for Kerberos authentication. And that's where you have two possible trust deployment:

• Certificate trust - you use actual certificates, so you'll need a certificate authority to issue those certificate, and you need ADFS to distribute them.
• Key trust - you use keys instead of certificates, it still looks like a certificate based authentication for the DCs, but in really you don't need a certificate authority to make it work. For this model to work, DCs have to be Windows Server 2016. Only 2016 and higher understand what to do when a user shows up with a key instead of a cert.

You should use the key trust if you can (meaning if you have the right version of DCs) because it has the less dependencies on infrastructure components. There are some slight differences on supported features, but that is usually not a big deal. Troubleshooting is also easier.

WH4B also requires the devices to be "trusted". And for domain joined devices, you can have them hybrid-AD joined. The dnshostname of the machine is irrelevant in this process.

I'd start here: Planning a Windows Hello for Business Deployment.

Answer 4

Hi Piaudonn,

thanks a lot for the time you spent for that answer.

Actually I have been following the guide you linked to your previous post. As we have a CA, I thought it would be better choice to select the "Certificate trust" but we also have a 2016 domain functional level...

My guess was, as we don't want to allow users to login with WH4B outside the company and we don't use applications hosted in Azure Active Directory, the deployment model to follow is "On-premises".
Do you agree with this?

Your help save me much time.

Yann