04-04-2018 04:16 AM
04-04-2018 04:16 AM
Recently one of my clients asked me to setup Windows Hello for Business as part of our Modern IT Management PoC. So currently they are using convenience pin and the use case was that on their Modern IT managed AAD joined devices the users should be able leverage Windows Hello for Business being able to also access on-prem resources when on corpnet.
As the client wants to benefit from Azure Identity Protection feature to detect leaked credentials and automatically take action on it (force pw change and MFA) he’s using AAD Connect with Password hash sync enabled. So he’s not using ADFS and already had some Server 2016 DCs inplace. Based on this great Decision Matrix:
we decided to go for Windows Hello for Business Hybrid Key Trust.
So there are already a couple of great guides on how to set that up here so I won’t to that again:
My client however was a little bit scared as Michael Niehaus wrote on his blog the following:
Ok so we decided to do a quick lab repro to check if we also experience any issues regarding the CRL and guess what…sure we did – so let’s have a look if we can beat Michael working on it for several days ;)
If the user was logging in on his aad joined with his “legacy credentials” (username/pw) he could access on-prem resources and everything was ok, if he was logging in with Windows Hello for Business then the user was not able to connect to the on-prem share and the following error message appeared:
So looking at the CAPI2 log in the eventviewer we saw that the client was not able to do the revocation check as the CRL was not reachable. Hmm strange as the CRL was published already externally via Azure Application Proxy (you can find a cool step by step guide over here https://blogs.technet.microsoft.com/microscott/how-to-set-up-azure-ad-certificate-based-authenticati... ).
At this point I was involving my PKI colleague Dagmar Heidecker who is an PKI expert as I didn’t want to spend several days :smiling_face_with_smiling_eyes:
We added the CRL via certutil directly to the client but somehow the client still always tried to access LDAP and internal web server and ran in a timeout.
So we changed the CDP/AIP extension on the root and sub ca and removed the LDAP path.
Next step was to request and install a new subca certificate and publish the crls.
After that I checked that the DC already had the new certificate without the CDP pointing to LDAP. Then I restarted the KDC service on the DC, cleared the cryptocache (C:\Windows\System32\config\systemprofile\AppData\LocalLow\Microsoft\CryptnetUrlCache\Content and Metadata) on the client and…..whoohoo.
On-prem access was working successfully when signed in via Windows Hello for Business!
Kudos to my colleague Dagmar Heidecker!
08-30-2018 02:11 AM - edited 08-30-2018 02:39 AM
Can you explain a bit what you did on the hybrid key trust part?
The documentation follows a Hybrid Azure AD joined deployment, while you (and I) are Azure AD joined only, if I understood your post correctly.
Or is the solution to actually enable Hybrid Azure AD Join?
12-14-2018 07:14 AM
12-14-2018 07:53 AM
Your devices don't have to be hybrid joined, AAD joined only works fine if everything is setup correctly. See requirements for each scenario in the following link https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-ident...
12-14-2018 08:00 AM
The goal of this solution is to have your AAD joined devices accessing On-prem resources when in corp lan and using WHfB Pin/Biometrics. So I just wanted to outline some of the pitfalls I came across to get that working because at my first attempt I was able to access On-prem resources with username/pw but not with using PIN.
12-14-2018 08:16 AM
12-14-2018 08:18 AM
03-05-2019 09:57 PM
Great discussion! One thing to point out that is not clearly mentioned for the Key Trust model is that you need to deploy a new certificate template to your domain controllers: the Kerberos Authentication template instead of the default Domain Controller Authentication template. It's not enough to add KDC Authentication in Intended Purposes on the old default template since this template does not have the FQDN of the domain in the certificate.