ToolBox Guide to
Now that we have completed the steps in part 1, let's continue with putting together the final pieces:
Setup CRL Distribution Point (CDP) accessible from the web
Because your AAD joined Windows 10 device is not joined to the on-prem domain, it will not have the ability to use LDAP to validate the CRL (Certificate Revocation List). The client must be able to validate the CRL for the cert to work. This is so that if you revoke the cert, it will see that and revoke it's use. LDAP is the default CRL distribution point on MS CAs. So we'll need to add (or even fully replace) that location with one that is HTTP. Also, it's best practice to put this externally facing on the web. You can also using OCSP (Online Certificate Status Protocol) for this too, but I won't get into detail on that particular method. I also want to give lots of credit to this blog and this blog for helping me setup the correct CRL distribution points. Check them out for the full background on certificate revocation list distribution points (CDPs)
I'm putting this CPD on the same server as my CA, but it's not required. I'll also show how to setup the basic IIS website for this, but any web server will do as long as the CA has write access to put the CRL files.
Setup Fileshare where CRL files will be store and accessible from web server
I've decided to put this share on my same web server, but it can be on another shared location. I created a folder called Certs on the root of C:\.
1. Right click the folder, then Properties, then Sharing tab, then Advanced Sharing.
2. Click Share this folder and name it. Add $ to the end if you want to make it hidden from normal file browsing.
3. Then click Permissions. Ensure Everyone has "Read" permissions. Then click on Add and we will need to add our MS CA computer object to this.
4. Click on Object Types and ensure "Computers" box is checked.
5. Click ok and then add the computer name of your MS CA.
6. It should resolve the computer name. Then click OK. Give this object full control.
7. Click ok to close out of the Advanced Sharing dialog box. Then go to the Security tab and repeat this same process giving full NTFS permissions on the folder to the computer object.
8. Click Ok to close this window.
9. Ensure you can get to this share going to \\servername\share
Configure IIS for HTTP CRL Location
1. Login to the web server and ensure you install the latest IIS. I'm using IIS 6.2 on Server 2012
2. Load IIS console
3. In navigation tree, expand it and browse to your Default Web Site. Right click it and click Add Virtual Directory.
4. Type and Alias for what you want your web URL to contain. I'm named it "CRL". Browse for and select the folder. Click OK to close.
5. Select the new "CRL" folder on the left hand side and the double-click on Directory Browsing.
6. Click Enable on the right hand side.
7. Go back one screen and then double-click on Configuration Editor icon.
8. In the drop down list, select system.webServer\security\requestFiltering
9. Change allowDoubleEscaping to be True. Then click Apply.
10. Load up a web browser and ensure you can get to your new website:
Configure CDP and AIA on the Microsoft Certificate Authority
1. On your CA, load certsrv.mmc, right click your CA name and click Properties.
2. Click on the extensions tab and select CRL Distribution Point (CDP) from the dropdown. You'll notice a bunch of locations already setup. Leave the first one alone (the one that has C:\Windows\System32\Certsrv... in the name), remove the ldap, http, and file locations.
3. First we'll setup the fileshare path so that the CA can publish the CRL files to that location. Click Add, then use this format:
Click OK when complete.
4. Ensure that you tick the following boxes:
- Publish CRLs to this location
- Publish Delta CRLs to this location
5. Now let's add the HTTP CRL. Click Add.
6. Using the format in the tooltip, add your http:// address here.
7. Click OK
8. Ensure that you tick the following boxes:
- Include in CRLs. Client use this to find Delta CRL locations
- Include in the CDP extension of issues certificates
Your CDP should look like this:
9. Click Apply to save changes.
10. Select Authority Information Access (AIA) from the dropdown.
11. Leave the first item, remove all other and then add your http location here.
Now when any cert gets issued from the CA, it will have this information included in it.
10. One final task. Don't forget to "publish" your CRL files. Do this by right clicking on Revoked Certificates, then All Tasks --> Publish.
11. Select New CRL and then click OK.
The files should then be created in the "File" location you configured on your CDP. (In my case C:\Certs)
Setup the MS Certificate Authority and WHFB Template in the Workspace ONE console
Now let's setup the MS CA into WorkspaceONE console as a certicate authority and create the WHFB template.
Configure MS CA as a Certificate Authority
1. Log into the Workspace ONE console and go to the same OG you setup the VMware Enterprise System Connector
2. Go to Settings --> System --> Enterprise Integrations --> Certificate Authorities
3. Click Add
4. Configure the certificate authority with the following settings (ensure you use your service account for the username/password).
5. Click Save. Go back into this by clicking Edit and then click on Test Connection to ensure you have a good connection to the CA.
6. Click Save and Add Template at the bottom.
7. Create template with the following settings:
8. Click Save
Setup WHFB Profile with Cert payload
Now we need to create a profile to deliver this cert template as a payload.
1. Click Add --> Profile from the top of the console.
2. Select Windows --> Windows Desktop --> User Profile
3. Fill out the General tab as desired and then click on Credentials from the left hand menu.
4. Click Configure and then select Defined Certificate Authority from the "Credential Source" and then select your WHFB template you just created. Store the key location in TPM If Present and the Personal for the certificate store.
You might be wondering why not sore the key in the Passport location? Well this does work, but we ran into a few issues:
TIP: This saves the private key to the TPM chip on the motherboard of the laptop and thus anythign happens to the TPM or the motherboard gets replace, a new cert will need to be manually pushed from the console.
5. Click Save & Publish when complete.
Import RootCA Cert to Console
1. Next we need to upload the Root (and intermediate if you use that) Certificate to the console. In case you don't know how to do that or don't already have it, here are the steps:
2. Launch MMC on your MS CA cert and click on File --> Add or Remove Snap-ins
3. Add the Certificates snap-in of the Local Computer. Click OK.
4. Expand Trusted Root Certification Authorities and click on Certificates. Find the Root certificate.
5. Right click it and the All Tasks --> Export.
6. Select the DER encoded binary X.509 (.CER) as format and then name the file. Click Next and then Finish.
7. Go back to console and create a Device Profile (not user) and click on "Credentials" payload.
8. Select Upload for the credentials source and the upload your root CA. Select Trusted Root as the "Certificate Store".
9. Save and deploy this as well as your other WHFB cert profile to a Smart Group. I'd recommend deploying this to an already existing client just to make sure the cert deployment works. It deploys fine to either Azure AD or domain joined systems.
Test and Validate
1. Go to your client in the console and ensure the the certs have been successfully deployed by making sure there is a green check mark next to them. Note that the user cert can take up to 5 min to deploy to the client.
2. On the client, load up certmgr.msc
Ensure that you are in the Current User context, NOT Local Computer context.
3. Look at the deployed certs:
- The first cert is the WHFB cert deployed by my CA
- The 2nd cert is an Airwatch SCEP cert that is deployed automatically
- The 3rd is another WHFB cert depoyed via Azure AD (since I'm AAD joined)
4. Double click on the first cert, the one deploy via the MS CA
5. Ensure the following are correct:
- The Subject has the correct user info
- The Enhanced Key Usage is set to the following:
- CRL Distribution Points has the correct web URL
6. Click on Certification Path and ensure it has your root cert there.
7. Go through OOBE and Azure join your windows 10 system and complete the Windows Hello For Business wizard.
8. After you login, load up event viewer and expand the Applications and Services Logs --> Microsoft --> Windows --> User Device Registration --> Admin log. Here are the importent events you sould see:
A. Event 358 - "Windows Hello for Business will be Launched"
B. Event 300 - Microsoft Passport Key successfully registered with Azure AD
9. Go to Applications and Services Logs --> Microsoft --> Windows --> HelloForBusiness --> Operational log. Here are the important events you sould see:
A. Event 8203 - Windows Hello for Business is enabled. You should also see a number of other events saying Windows Hello for Business prerequisites have passed.
10. Attempt to browse to on on-prem file share to validate you can access on-prem resources.
And that's it! This allows you to have a cloud AAD joined Windows 10 machine setup with BIometric/PIN login to still access on-prem AD resources. Super cool! (and secure too)
Note: Sometimes I have to reboot the machine for the client to actual "use" the cert when trying ot access resources, otherwise I get prompts to input PIN.
Here are some things that I found useful to help troubleshoot this whole process. For while I could get the certs to deploy, but they were still having issues getting trusted with my on-prem domain. It ended up being mostly around the CDP and how well the client could access it.
Validate CRL from Client
1. Open up elevated command prompt and type in the full web URL of your CRL file
certutil -url http://server/crl/nameofserverfile.crl
2. Hit Retrieve and it will tell you the status. If the client can't access it, then it will tell you.
A few reason why it might fail:
- Try from a web browser
- Make sure the URL is correct and that it matches what is configured on server
- Ensure your client can resolve the DNS of your server
- The share might not have the correct permission on it
Test CRL connection from the cert itself
1. Export your personal cert from MMC and save it as a .cer file. I saved mine as c:\cert.cer
2. Run this command from elevated command line:
certutil -urlfetch -verify c:\cert.cer
This will tell you a ton of information as well as validating the CDP
3. Also do the same thing from the system account using PSExec to make sure it works from there too.
psexec -s certutil -urlfetch -verify c:\cert.cer
Jairo Cadena has a great blog about Azure AD and Hello for Business on windows 10 if you really want to understand how all of the pieces are working under the hood.
Michael Niehaus on why you shouldn't be afraid of Azure AD on Windows 10
Setting up CDPs
Verify CRL Validity
Primary MS documentation on Hello for Business
I'm Brooks Peppin and I love God, my family, AirWatch, VMware, EUC products, all things systems management, Windows 10, Powershell, and operating system deployment.