Certificates on IAG 2007

  • Article

1. Introduction

 

The use of Digital Certificates with IAG 2007 is essential for several IAG authentication and access scenarios as well as for providing encryption of sensitive data. There are two main scenarios when using certificates; it is common to have misunderstandings about which scenarios each type of certificates are used. The first article of this series will give you an overview of the different types and usages of each certificate when you are using IAG 2007.

 

2. When does IAG use Certificates?

 

The diagram below shows the various scenarios where IAG uses certificates for authentication and/or data encryption:

 

Figure 1 – IAG SSL Communication

 

This diagram shows the two parts of the communication when IAG 2007 is used to allow external access to internal resources. The main purpose here is to define which type of certificates are involved when each communication happening, therefore let’s see the following table:

 

Communication Channel

Certificate Type

Certificate Usability

Where the Certificate is Installed

Client to Server

Client Authentication

· Client authentication

· Endpoint Detection

Client workstation

Server to Client

Server Authentication

· Regular Publishing Scenarios

· Network Connector

· IAG Portal

IAG Server

Server to Server

Server Authentication

· Encrypted connection to protocol transaction, such as LDAPs and HTTPs

Application Server (Web Server) or in the Authenticator (Domain Controller for instance)

 

3. Client Certificate Authentication with IAG

 

The previous table summarizes the scenarios where a certificate is used, but how really IAG authenticates the user when using client certificate? IAG certificate authentication works in four main phases:

 

1) Certificate is checked in IIS against CRL to make sure it is not revoked

2) Certificate validity is checked to make sure it’s not expired (cert.asp)

3) Two pieces of data are collected from the cert the “username” and the “email address” (cert.asp)

4) The directory service choose in the authentication repository is queried using the “username” and then if a match is found is that user is queried for the “email” parameter ([repositoryname].inc.) The email parameter retrieved from the directory is compared to the value retrieved from the certificate([trunkname]1validate.inc). If any of the 4 checks or subset of the checks fail or do not match the user is not authenticated.

 

It is important to remember that the IAG certificate authentication mechanisms are provided as samples. These samples are intended to be re-written or modified to match the requirements each particular customer has. Customer PKI schema vary so significantly customer to customer that it’s not possible to have a default configuration that knows how to deal with even most cases.

 

There were some cases where the DN used as the Certificate SubjectCN, in this case our sample would properly pick up that object and use it for authentication. However there are other cases the certificate does not contain DN or UPN but contains some other collection of objects we can use to write a custom ADSI query to AD to look up the user’s DN. The framework provided is very flexible and customizable and is designed to allow as many cases as possible.

 

4. What comes next?

 

This post gives you an overview of how IAG uses certificate and starts to introduce client certificate mechanism. The coming articles will cover:

· Certificate Authentication with and without Kerberos

· Implementing Client Certificate Authentication

· Understanding IAG’s “Certified Endpoint” feature

· Understanding Endpoint Detection of Client Certificates

 

Stay tuned.

 

 

Authors

Yuri Diogenes

Security Support Engineer – ISA/IAG Team

Microsoft – Texas

 

Dan Herzog

Security Support Engineer – IAG Team

Microsoft – Washington