Change Auditor now supports Client Certificate Authentication

Change Auditor now supports Client Certificate Authentication. This is a welcome feature for administrator who prefer a more secure method of Authenticating users connecting with the web client. Introducing Client Certificate Authentication in the client server SSL handshake, allows the server to validate the client in addition to the client validating the server.

For Client Certificate Authentication to work correctly in Change Auditor the following conditions must be true.

Active Directory Client Certificate Authentication is enabled in IIS at the server level.

 

 

 A web site (or default) exists and is configured to use secure connections.

 

The web client must be installed and configured to use a Coordinator installed on the same server. The Coordinator being used can be verified in “AppSettings” node of the Web.config file for the web Client. This file is located in the web client install folder. The web client must be reinstalled if Forms Authentication was previously used.

 

Client Certificates:

A Client Certificate allows a user to authenticate without supplying a user name and password, it must support Smart Cards to work correctly with Change Auditor.

 

The Client Certificate must be issued or mapped to an Active Directory user account using Active Directory Users and Computers or the Certificate Snap-in Management console.

 

The Client Certificate should exist in the Personal Certificate store of the client and the clients must have the trusted root certificate for the target server in the Trusted Root Certificate Authorities store.

 

If there are multiple certificates a user is presented with a prompt to select the appropriate certificate.

Note: The “Issue to” user on the certificate must be a member of the appropriate Change Auditor group(s).

 

Smart Card Certificates:

Installing and configuring a Smart Card reader is outside the scope of this document.

Smart Cards stores personal identification and authentication/certificate data, a user inserts the card into a card reader and enters a PIN to gain access. A smart card must be enrolled before it can be used. Enrolment involves acquiring/generating a Certificate and exporting it to the smart card. An administrator may enroll a Smart Card Certificate on behalf of a user by first adding an Enrollment Request Agent Certificate.

 

Enrolling a Smart Card (Active Directory Certificate Services): 

Right click on the current user Personal Certificate store and select “All Task” | “Advanced Operations” | “Enroll On behalf Of” in the MMC Certificate Snap-in. Click "Next".

 

Browse for the Signing Certificate (the Enrollment Agent Certificate), it should display when the browse button is selected. Click "OK" and "Next".

  

Select the “Smart Card user” certificate and click “Next”.

  

Browse for the user account to "Enroll On Behalf Of" and click “Enroll”

 

Insert a blank Smart Card into the reader attached to the Enrollment station.

 

 

Enter the PIN for the Smart Card.

 

 

Conclusion:

Certificate Authentication is a more secure but simpler method of authenticating users. To reduce the problems and down time associated with this method of Authentication, a good understanding of the function and features of Certificates is vital.

  

Additional reading:

Map Client Certificates by Using Active Directory Mapping

Deploying Smart Cards

About the Author