UAG DirectAccess Test Lab Guide CRL Check Update

Article
05/20/2010

Jim Harrison recently pointed out to me that there’s a small problem with the UAG DirectAccess Test Lab Guide, which you can find over at https://technet.microsoft.com/en-us/library/ee861167.aspx If you haven’t seen the Test Lab Guide yet, or if you haven’t had a chance to run it, I highly recommend that you do. We recently updated it with new extensions that enable you to see how UAG specific scenarios such as “manage out”, array deployment, NLB configuration, and access to IPv4 only resources works.

However, back to the “small” problem. Part of the Test Lab Guide walks you through how to install and configure the Microsoft Certificate Server so that Certificate Revocation Checks won’t fail when the DirectAccess client tries to connect to the IP-HTTPS listener on the UAG DirectAccess server.

As I point out in the Test Lab Guide, this isn’t something that you would do in a production environment. If you use a commercial certificate for the IP-HTTPS listener, the certificate provider will make sure the CRL is reachable and highly available. If you create your own certificate for the IP-HTTPS listener, then you’ll have to publish your CRL and make sure it’s highly available – a lot of work for some people, not so much for others. The point is, you can do it either way.

If you go to https://technet.microsoft.com/en-us/library/ee861152.aspx#BKMK_O you’ll find that you’re in Section O – Remove CRL Distribution Settings on the Certificate Authority on DC1. In step 3, you’ll read the following:

“3. Click the Extensions tab. In Specify locations for which users can obtain a certificate revocation list, check all locations of the CRL Distribution Point (CDP) Authority Information Access (AIA) , and verify that Publish CRLs to this location or Publish Delta CRLs to this location is not selected.”

The problem with these instructions is that they are incomplete and won’t prevent CRL check failure when the DirectAccess client is later configured to connect to the UAG DirectAccess server using its IP-HTTPS adapter. You’ll know that you’re running into this problem when you run the command

netsh interface httpstunnel show interface

you’ll see a Last Error Code of 0x80092013. You might also see an error code of 0x274c on the way to the the interface finally failing. The 0x80092013 code indicates that the CRL check failed.

In the figure below you can see the Properties dialog box for the Certificate Authority we use in the Test Lab Guide. The problem you’re encounter with the Test Lab Guide is related to the ldap:// URI. When you select that option from the Specify location from which users can obtain a certificate revocation list (CRL) , you have to make sure that you deselect (uncheck) the option Include in the CDP extension of issued certificates. That step is not called out in the Test Lab Guide. I will add that as soon as I can, but until then, make sure you uncheck that option.

What if you already configured the Test Lab and everything worked except for the IP-HTTPS connection? What you can do is request a new certificate for the IP-HTTPS listener and run the UAG DirectAccess Wizard again so that the new certificate is bound to the IP-HTTPS listener. Here are the general steps

First, configure the Certificate Authority so that the ldap:// URI has the Include in the CDP extension of issued certificates option unchecked, as seen in the figure above. You will be asked to restart the CA in the process.
Disable the DirectAccess configuration at the UAG server. You can do that in the UAG management console. Click the Disable button and it will disable the UAG DirectAccess configuration while you’re making your updates.
After you disable the UAG DirectAccess configuration, the next step is to configure the TMG firewall located on the UAG server to allow you to request certificates from the Certificate Authority on the internal network. For instructions on how to do that, see Ben Bernstein’s post on the UAG Team Blog at https://blogs.technet.com/edgeaccessblog/archive/2010/04/22/deep-dive-into-uag-directaccess-certificate-enrollment.aspx
Open the Certificates MMC on the UAG server. Delete the previous IP-HTTPS certificate, which will show Issued To as uag1.contoso.com as seen in the figure below.
After configuring the TMG firewall to allow you to use the Certificate Request Wizard in the Certificates MMC and deleting the old IP-HTTPS certificate, request a new web site certificate for the IP-HTTPS listener. The common and DNS names should be the same as the previous certificate, uag1.contoso.com. You will use the same certificate template you used earlier in the lab, which was the Web Server 2003 template.
After the new certificate is installed, right click on the new certificate and click Properties. In the Friendly name text box, give it a new name so that you can find it easily in the UAG DirectAccess wizard. In this example, added the friendly name IP-HTTPS2 Cert.
Run the UAG DirectAccess Wizard again. When you get to the Authentication Options page of the UAG DirectAccess Server Configuration sub-wizard, click the Browse button in the Select the certificate that authenticates the UAG DirectAccess server to a client connecting using IP-HTTPS. You will see the new IP-HTTPS in the list – select that one.
Complete the UAG DirectAccess Wizard and deploy the new GPOs. Then click the Activate button to activate the UAG DirectAccess server configuration.
Restart the CLIENT1 virtual machine. When the virtual machine comes up, it will be able to connect using IP-HTTPS. If the Teredo client is still set to enterpriseclient, then run the command netsh interface teredo set state diable and wait for the OK response. At that point the IP-HTTPS connection will establish and you’ll see it when you run ipconfig /all