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.
I love the Out of Box Experience (OOBE) combined with Azure AD (AAD) on Windows 10. It gives you AAD join from anywhere and automatically enrolls the device into MDM (in my case AirWatch WorkspaceONE). This is what modern management is all about - cloud, cloud, cloud. However, most organizations still have a lot of on-prem resources that they will need to access from that client such as web sites, CIFS File Shares, printers, LDAP applications, and others. Windows Hello for Business enables this by using a certificate deployed to the client via an on-prem Microsoft CA. Without this cert, your on-prem AD has no way to validate your identity on the client.
There are two ways to implement this. One is "key-trust" and the other is "cert-trust". Key trust uses a certificate deployed directly from Azure and syncs in back to your on-prem AD as a user attribute (ms-DS-KeyCredentialLink) and your domain controllers are able to use this for kerberos validation. This is a much simpler process to setup, but it requires your devices to be "hybrid" meaning on-prem AD joined + Azure AD registered. Here's a decent article on setting up key-trust. For "cloud only" AAD joined machines (like ones that have gone through OOBE), you must use cert-trust method. This is the method I'm using. In part 1, I will be detailing how to setup:
I will also not be using ADFS, but instead use WorkspaceONE for identify and federation. WS1 will also be used to deploy the certificate to client.
The full list of pre-reqs are here. We'll be using the "hybrid deployment" even though the client itself is cloud only joined. The hybrid term refers to the architecture setup, meaning you are syncing your on-prem AD data into information into Azure AD.
In my setup, I'm using 2016 versions of everything to make it unified across the board.
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.