On-prem access from an aad joined device with Windows Hello for Business

[Stefan Ringler]

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:

https://blogs.technet.microsoft.com/chadcox/2018/03/19/my-notes-on-setting-up-a-poc-windows-hello-fo...

https://blogs.technet.microsoft.com/microscott/setting-up-windows-hello-for-business-with-intune/

https://gallery.technet.microsoft.com/Windows-Server-2016-Active-165e88d1/file/182710/1/W2K16%20Acti...

My client however was a little bit scared as Michael Niehaus wrote on his blog the following:

Afraid of Windows 10 with Azure AD join? Try it out (part 2)

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!

[#2]

Hi Stefan,

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? 

[#3]

curious myself, I don't plan on doing Hybrid Join, can using PIN in Azure AD Joined devices only work with access onprem File shares? Thanks!

[#4]

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... 

[#5]

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.

[#6]

Yeah I got everything setup and working, it's the same issue with PIN not working, but I finally found a good explination and how to fix it in the same guide here: https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybri...

Basically with like you said the CRL which I was confused by publishing to internet in your original statement, but it makes sense now that you can't get the default CRL because you cannot query active directory because your not authenticated yet and it requires that CRL so you publish it to internal http endpoint so it can pass that check. At least that's what it looks like, I'm working on setting that up now. Then hopefully PIN will work!

[#7]

Do you happen to know if renewing and rekeying ath Domain controller certificate as one of those steps adding the new CDP etc. will have any effects on current client machines etc?

[#8]

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.

[#9]

@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!

Thanks,

Tim

[#10]

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!