Apr 04 2018
- last edited on
Jul 27 2020
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!
Aug 30 2018 02:11 AM - edited Aug 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?
Dec 14 2018 07:14 AM
Dec 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...
Dec 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.
Dec 14 2018 08:16 AM
Dec 14 2018 08:18 AM
Mar 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.
Oct 19 2020 11:04 AM
@Stefan Ringler Thanks for a great guide. I've fixed the CDP and AIA to remove LDAP, used app proxy to make the CRL and OCSP available externally, renewed the sub-CA cert and issued it to Azure-AD joined devices but I'm still getting auth prompts and access to on-prem file shares pops up saying "unable to locate a domain controller to service the request"
Any ideas please? I'm struggling with this one!
Feb 21 2021 10:29 AM
Thanks for a great guide @Stefan Ringler! I had spent some days searching for an answer when I found your blogpost. The redemptive in my situation was to delete the "CryptnetUrlCache" folders and reboot the clients. Thanks for sharing!