A topic that has come up many times is the use of certificates with UAG. As it happens, using certificates has several aspects, as pertaining to UAG, so here’s a summary of the various uses we have for certificates.
1) Client Certificate Authentication
2) UAG Certified Endpoint
3) Computer Certificate inspection
4) Privileged Endpoint
Here is some more detail about these:
1) Client Certificate Authentication is an optional replacement for UAG’s default Forms-Based Authentication (FBA) with Certificate Authentication. When this is configured, UAG inspects the User’s certificate and the values in it are compared to AD (or the configured authentication repository). If the values returned match the values found in the user’s certificate, the user is authenticated. This way, a username or password are not entered by the user. Only Client Certificates can be used for authentication because IE is not able to access the Computer Certificate store. Configuring client certificate authentication is described here:
Note, however, that the actual certificate and directory infrastructure in the organization dictate the configuration. This means that with most companies, the documented procedure may not apply, or may require customization to work.
2) UAG Certified Endpoint is a supplement to FBA authentication. A user is first prompted and required to login with a regular set of username & password. Once they have successfully authenticated, all users are then prompted for a User Certificate. This prompt is not to force Client Certificate Authentication, but to collect a property for the client similar to client detection, but done in such a way (using SCHANNEL) to ensure that the certificate is authentic and really from the client machine in question. To enable this, you need to enable "use certified endpoint" in the UAG Session tab of the trunk’s advanced configuration. It’s also possible to select verify username in the same Config screen, which set UAG to compare the primary username obtained from FBA to the User Certificate that has been presented. In this scenario as well, only Client Certificates can be used because IE is not able to access the Computer Certificate store and so it can not send Computer Certificates.
The user has the option of declining to select a certificate, which is equivalent to him not having one. He will still gain access to the portal, but will only be allowed access to applications which have been specifically permitted. To permit applications, the administrator needs to create an endpoint policy that evaluates the “Certified Endpoint” parameter, and assign it to applications he wants to limit access to.
If a client does not have a certificate, or declines to present it (by clicking on cancel on the certificate selection prompt), applications which have been configured with the certified endpoint policy will be grayed out:
3) Computer Certificate inspection is problematic, as stated above, because of security restrictions. It is possible to do to some degree, but only on XP x86 SP2+ and Vista x86 OSs. It is related to endpoint detection (such as is done for AntiVirus or Personal Firewall). The check for certificate is done via UAG Client components that are able to query the, user, system, or Computer Certificate stores for the existence and CRL validation of certificates. The very important difference here is that the certificates are never sent to UAG – they are only queried on the local machine by the client components. To implement this, a custom client detection script must be written and custom policies must be created so that the results of this detection can be used in the validation of a UAG endpoint policy. This procedure is not documented.
4) Privileged Endpoint is not directly related to certificates, but it’s often confused, so I’m discussing it here as well. Privileged Endpoint is not a pre-defined level of access or permission. Privileged Endpoint is determined by the results of a UAG Endpoint Policy. By default this policy is set to use the "Privileged Endpoint" expression, which is set to "False". This means that on an out of the box installation of UAG there is no such thing as a Privileged Endpoint. This policy can be configured with any of the built in policy components, or expressions, or with extended objects using custom detection scripts on Windows. The purpose of this concept is to allow the use of two classes of users, one with some level of timeouts and behaviors and a second set with a different set (which could be stricter or laxer, usually). The options for both can be seen on the Session Tab in the Advanced Trunk Configuration:
The Privileged Endpoint policy can also be used as an application access policy for applications on the portal. To use this policy, one must edit the default Windows Expression “Certified_Endpoint”, and put the required conditions into it. For example, “Any WMI Anti Virus” and “Any WMI Anti Spyware”:
Once the default expression has been configured, it can be used as part of a policy, and once that policy is assigned to the trunk, the appropriate settings will apply to it. If it’s assigned to an application, then access to that application will be permitted or denied based on the client meeting the policy condition that were selected by the administrator, as described above. Naturally, the "Certified Endpoint" policy expression can be used as a property in the creation of a "Privileged Endpoint" policy as well.