Forum Discussion

Stefan Ringler's avatar
Stefan Ringler
Brass Contributor
Apr 04, 2018

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

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-for-business-lab-using-hybrid-key-trust/

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%20Active%20Directory%20Certificate%20Services%20Lab%20Build.pdf

 

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-authentication-for-office-apps-on-mobile-devices-ios-and-android-part-1/ ).

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 😊

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!

 

 

 

 

 

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

  • timjohnson340's avatar
    timjohnson340
    Copper Contributor

    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

  • 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!
  • Nima Gharib's avatar
    Nima Gharib
    Copper Contributor

    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? 

    • Stefan Ringler's avatar
      Stefan Ringler
      Brass Contributor

      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.

      • ChrisWebbTech's avatar
        ChrisWebbTech
        MVP
        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-hybrid-aadj-sso-base

        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!

Resources