Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

 

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 application. 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 “Installation guide to Microsoft Windows 2008 Server – CA, AD and CRL”.

If your company already has a Microsoft PKI infrastructure implemented please see the document “Guide to setup of templates – Buypass Certificate Templates in MS CA” for further configuration.


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

LRA v3.3 (.net version)

... her må det inn bilde av Configuration Application - tab for AD ........



We refer to CA installation document chapter 4.2 for more details and for the settings for LRA privilege hierarchy.

We also refer to the LRA system documentation for more information about the function of the various groups mentioned above.

Users must be registered in AD

In order to use the Buypass LRA all users must be registered in AD. AD is the primary userdatabase of all users/employees as the Buypass 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(*)

LRA v3.3 (.net version)

... her må det inn bilde av Configuration Application - tab for AD ........

 

Fields which the LRA client are reading from AD

The installation of 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. This will give only a specific group access to read the contents of this attribute, 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 (SSN) or D-number 1) - 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.

 

1) A D-number is a temporary number assigned to foreign citizens who must pay tax or national insurance in Norway. 

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=

LRA v3.3 (.net version)

... her må det inn bilde av Configuration Application - tab for AD ........

 

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

 

  


Innhold  

 

PDF macro for Løsningsbeskrivelsen (kommer)

Unable to render {include} The included page could not be found.

Unable to render {include} The included page could not be found.

 

Unable to render {include} The included page could not be found.
Unable to render {include} The included page could not be found.
 
Unable to render {include} The included page could not be found.
 

 

  • No labels