To enable this feature, you simply have to check the option “Use certified endpoints” in the Advanced Trunk Configuration’s Session tab:
The remaining challenge is delivering the certificates themselves to the client computers. This would be easy for mobile users, as you can simply deploy the certificates with Active Directory Autoenrollment, or install the certificates manually while the computer is in the office. However, UAG is often used by home computers, and we can’t expect all users to bring their computers to the office…not to mention forcing the administrator to start installing certificates on everybody’s PC.
The solution is the Certified Endpoint Application. This is a special built-in web application that comes with UAG. Once it is added to the portal, it will be shown to users who do not have a certificate yet (at that point, other applications that are configured on the UAG portal will not be shown to these users). Users will then be able to launch it to request a certificate for their computers.
Hold on…that’s not so simple, actually. For this application to work, it has to have the CA server installed on the UAG itself. In fact, if you don’t have the CA server installed, the UAG application wizard will not even show you the application in the list of templates. To have the application available, install the Certificate Server role on UAG:
1. Close the UAG Console
2. From Computer Management, add “Active Directory Certificate Services”
3. Add the role service for Web Enrollment as well:
4. Open the UAG console again, and you should see a message notifying you it was detected:
5. Now, the enrollment app should be available on the application wizard:
Another option you might prefer is to have the CA on another server, instead of the UAG itself. We refer to this as a “remote CA”. Unfortunately, the enrollment application that UAG has does not support a remote CA, so you cannot add it. In this scenario, you will have to publish the Remote CA’s Web interface as a regular web application. Some people consider this option preferable anyway, because the default CA pages on a Windows Server CA are highly customizable. You can edit these pages, and build a set that’s particularly friendly. For example, you can take out some of the certificate options that may be confusing to non-technical users, or add guidance text to the pages.
If you do decide to go that route, use UAG’s “other web application” template to publish your internal CA’s web interface. Note that by default, IIS on the CA will enforce SSL on these pages, which means you’ll need to be careful with the hostname you use to refer to the server on the application template’s Web Servers tab. If the name doesn’t match the certificate that the server sends, you’ll get an error when launching the application from the UAG portal.
As you may have noticed from the message in step 4 above, the local CA option is not supported if you are using an Array. If an array is required, then a remote CA is your only option.
If you elected to go with the local CA option, instruct your users how to use the UAG portal to get the certificate they need. When they connect to UAG for the 1st time, they will only see the Certified Endpoint Enrollment application, and to gain access to the other applications, they need to follow these steps:
1. Upon logging in for the 1st time, the user should click on Certified Endpoints Enrollment icon in web portal:
2. The user needs to accept the prompt to allow the portal to carry out a digital certificate operation on his behalf:
3. The user needs to fill in his Email*, and click Submit to continue.
* Filling the Email address is not critical. It’s mostly to allow the administrator to keep track of everything in a nice and orderly manner.
4. The user needs to accept the warning to continue:
5. The user needs to click on the link to install the certificate:
6. This would fail, because the computer doesn’t trust the root CA, so the user should not install the root certificate for the CA that issued the endpoint certificate. This is done by clicking on the install this CA certificate link.
7. The user needs to click on Open to start the import process:
8. The user needs to click Install Certificate, and then click Next
9. The user needs to select the second option to choose the store in which to place the certificate
10. The user needs to click browse , and choose Trusted Certificate Authorities.
11. The user needs to continue with Ok -> Next -> Finish, which will also show a prompt to authorize the certificate installation:
12. Once complete, the import wizard should confirm that the import was successful:
13. The user should go back to the UAG certificate enrollment page, and click on Install this certificate again. This time, it should be able to install the certificate:
At this point, UAG should acknowledge that the certificate has been installed and in turn, immediately remove the certified endpoint application icon from the portal. However, the regular applications wouldn’t be displayed until the user logs off and logs back in. When accessing the UAG server the next time, the browser would prompt the user to select the certificate to use:
Once logged in, the other applications should show up on the portal. The user can also check their status from the information window, which should show their computer as a “Certified Device”:
Troubleshooting certified endpoints
An issue that might affect some Windows 7 clients is an error message by the certified endpoint applicationyou’re your users are receiving an error, follow these steps to work-around it:
1. On the UAG server, navigate to
C:\Program Files\Microsoft Forefront Unified Access Gateway\von\
2. Make a copy of the CertifiedEndpointEnrollment folder, for backup purposes
3. Open the file certnew.cer for editing with your favorite text editor (note that double-clicking it would open it with the certificate viewer, which isn’t what we need here)
4. Add the following lines as illustrated:
5. Save the file.
6. Open the file certsis.asp with a text editor, and change the text <%=nRenewals%> to 0, as illustrated below:
7. The change is effective immediately, with no need to activate the UAG configuration.
Another issue you might run into is the error “You have attempted to access a restricted URL. URL include the invalid path” when trying to access the certified endpoint application from a UAG client. This can happen if you have an existing portal, and you have added the application to it after existing applications are already configured. In that case, the access rules processing order causes UAG to misidentify the request for the app (https://uag.createhive.com/<HAT>/certifiedendpointenrollment/certeqbi.asp) and block it. This would typically be accompanied by this error in the web monitor:
“A request from source IP address <IP> user <user> on trunk <trunk>; secure=<1/0> for application Remote Desktop Services of type TerminalServicesGateway failed. The URL /certifiedendpointenrollment/certrqbi.asp?type=0&site=<site> contains an illegal path. The rule applied is Default rule. The method is GET.”
To fix this, select the application on the portal, and use the arrows on the right to move the application to be at the top of the list:
Once moved, activate the configuration, and that should be taken care of!
Blog post written by Ben Ari and Rainier Amara
Great Ben! Once more scenario to discuss: if we select to use "Verify user name with endpoint certificate", UAG will then validate the user logon name (e.g. sAMAaccount or AD username, which was entered to the portal login form) with the subject of the certificate that was presented to UAG post logon. The problem I see here is that subject name of the certificate, by default, will have the format of user's common name e.g. "Ben Ari", which will not match the user logon name e.g. BenA.
Is there anyway to address this scenario? I guess we need to modify the cert.asp but not sure how or should we do that.
Nice to see that Redrock use UAG...
I disagree with installing a CA on UAG.
Per Microsoft this is also not recommended.
It is a bit of a pain, but setting up UAG to point to an external subordinate CA on the domain seems best practice and works well.