MS AD - setup of Certificate Groups
This information is written in English only
This guide describes the additional changes that are needed to be done in Microsoft Active Directory (AD) in order to use Buypass Access Manager - the LRA client. Before implementation of new groups in AD the CA must be adjusted with templates.
For installation and configuration of CA, AD and CRL please see the document MicroSoft CA, AD and CRL - Installation and configuration on MS Win 2008 Server
If your organization already has a Microsoft PKI infrastructure implemented please see the document Guide to setup of Certificate Templates - Buypass Certificate Templates in MS CA for further definition of needed templates.
Buypass Certificate Groups in Microsoft AD
The groups which must be created in AD in order to use Buypass Access Manager - LRA are as follows:
Group for CA ADM G_CA_Admins *
Group for LRA ADM G_CA_LRA_Admins
Group for LRA Operators G_CA_LRA-Operators
Group of users that should have qualified certificates G_IDM_KvalifiserteSertifikater
Group for users who will have local certificates G_IDM_LokaleSertifikater
*) Optional. This group can be created to give LRA Operators access to the CA server without giving them domain admins permissions.
It may be considered if it is necessary to split in Global and Local Domain Groups. The names of the groups can be determined or changed by the organization. The important thing is that the names of the groups in Active Directory are the same configured in the LRA configuration.
LRA v2.5.3/v2.5.4 (Java-version)
(…\cfg\properties\cnl\cts\lra\subjectadconfig.properties)
#LRA groups
lra.client.adapter.subject.ad.lraadmin_group_prefix=CN=G_CA_LRA_Admins
lra.client.adapter.subject.ad.lraop_group_prefix=CN=G_CA_LRA_Operators
lra.client.adapter.subject.ad.install_qc_group_prefix=CN=G_IDM_KvalifiserteSertifikater
lra.client.adapter.subject.ad.install_lc_group_prefix=CN=G_IDM_LokaleSertifikater
Figure: A test setup from Buypass lab
Users must be registered in AD
In order to use Buypass Access manager - the LRA client, all users must be registered in AD. AD is the primary user database of all users/employees as the LRA issues and administrates the certificates for these users/employees. There is no update of data in the AD from the LRA client.
A service account must be created for use by the LRA client. The LRA client will use this service account [lrauser] to retrieve data from AD. The account must have enough privileges to read information that the LRA client needs through the issuance of certificates. The password for this user should have a minimum validity of 3 years and be correspondingly strong. The password must be entered in the config file to the LRA client. The password should be encrypted. This is done by using the LRA client after installation.
LRA v2.5.3/v2.5.4 (Java-version)
(…\cfg\properties\cnl\cts\lra\subjectadconfig.properties)
#AD configs
lra.client.adapter.subject.ad.host=192.168.1.21
lra.client.adapter.subject.ad.port=389
lra.client.adapter.subject.ad.basedn=DC=lab,DC=buypass,DC=no
lra.client.adapter.subject.ad.principal=lrauser
lra.client.adapter.subject.ad.credentials=secretpassword
lra.client.adapter.subject.ad.searchbase=OU=Brukere(*);OU=Admin(*);CN=Users(*)
Fields which the LRA client are reading from AD
The installation of Buypass Access Manager - the LRA client, does not require any AD schema extensions. It is sufficient to use an existing attribute that is not in use.
For Social Security Number (SSN) it is possible to use an unused attribute. This can be the "employeeNumber"-field in the User class. We have chosen to set this field as Confidential Attribute. Due to this it will only be possible for a particular group to read the contents of this field, for example the LRA Client and LRA Admins.
Information retrieved about the employee is among others:
- Username
- Name – first name and last name
- Social security number or D-number * (SSN) - 11 digits. SSN can be divided into two parts: Date of birth (6 first digits) and National identity number (5 last digits)
- IF you have employees who does not have SSN and therefore will only have local certificates or others who will only have local certificates - date of birth (6 digits) is enough
- Information about type of certificate – either the employee should have login and / or signing certificates (linked to the groups G_IDM_LokaleSertifikater and / or G_IDM_KvalifiserteSertifikater, respectively)
- Official email address
- Information document for foreign citizens
The fields the LRA client is reading from are fields that already exist in AD. If someone wants to add information in other attributes than those selected default, it will not be a problem, as long as the LRA has privileges to read when issuing certificates.
*) A D-number is a temporary number assigned to foreign citizens who need a national identity in order to communication with official authorities in Norway, as applying for a bank account, getting working permission, pay taxes or getting national insurance.
Note: There is no update of data in the AD from the LRA client.
Default does the LRA client read from these fields in AD:
.USERID=sAMAccountName
.SSN=uid
.SSN2=uid
.FIRSTNAME=givenName
.LASTNAME=sn
.BIRTHDATE=uid
.EMAIL=mail
.IDDOCUMENT=extensionattribute15
... and from these groups:
CN=G_IDM_LokaleSertifikater
CN=G_IDM_KvalifiserteSertifikater
CN=G_CA_LRA_Operators
CN=G_CA_LRA_Admin
In order to be able to retrieve the information there must be a mapping between the attributes in AD and the same information elements in the LRA client. The mapping is specified in a configuration file.
LRA v2.5.3/v2.5.4 (Java-version)
(…\cfg\properties\cnl\cts\lra\subjectadconfig.properties)
#AD fields
lra.client.adapter.subject.ad.mapping.USERID=sAMAccountName
lra.client.adapter.subject.ad.mapping.SSN=uid
lra.client.adapter.subject.ad.mapping.SSN2=uid
lra.client.adapter.subject.ad.mapping.FIRSTNAME=givenName
lra.client.adapter.subject.ad.mapping.LASTNAME=sn
lra.client.adapter.subject.ad.mapping.BIRTHDATE=uid
lra.client.adapter.subject.ad.mapping.EMAIL=
lra.client.adapter.subject.ad.mapping.IDDOCUMENT=
GPO - Group Policy
It is not necessary to set up the GPO for distribution of intermediate CA root certificate, it is distributed automatically. For those clients using stand alone Root CA the trusted root certificate must be distributed.
- Auto Roll Apartment Domain Controller certificates
- Auto Troll Apartment of LRA PC Enrollment certificates