Introduction
It is possible to use Active Directory (AD) Group membership as a mechanism to perform permission validation checks during credential issuance to ensure that an operator and/or a user are members of configured AD group(s) before issuance is allowed to be performed.
For example, in a geographically distributed organization where there are many different office locations and each office location needs to administer their end users credentials. In this setup, it may be required to use AD Group membership, for example, each office has at least one operator that is a member of a Credential Group. Employees at that same office are also a member of the same Credential Group. Employees are traveling between offices and are then given temporary membership to the Credential Group of the office being visited. The operators of that office are then, based on the group membership, able to administer those user’s credentials.
Windows AD Group Permissions Configuration
Currently there are 2 mechanisms to perform AD group permission checks:
- AD Groups
- AD Group Pairs
AD Groups
You can use this mechanism whereby an operator (when issuing on behalf-of) and/or an end user (when the end user is performing self-service issuance) need to be the same members of at least one AD group for the permission check to pass.
Below we will describe how an example configuration could be set up in vSEC:CMS. A simple example will be used to better describe how this can be configured and used.
Below we will describe how the Windows Group permissions could be configured to use this mechanism. It is expected that the reader has experience in using Windows AD and Windows Groups.
Nested groups are supported. The below query is run against AD: szQueryStr.Format(_TC("(&(member:1.2.840.113556.1.4.1941:=%s)(member:1.2.840.113556.1.4.1941:=%s))"), pszUserDN1, pszUserDN2);
Therefore the limitation will be from AD with regard to the depth that the query can navigate through groups.
Example company XYZ has 2 different office locations, one office in the UK and one in the USA. It is required that vSEC:CMS operators located in the UK office can only manage users located in the UK office and similarly vSEC:CMS operators located in the USA office can only manage users located in the USA office. Additionally, end users in either location will be allowed to perform self-service operations using the vSEC:CMS User application.
In AD 2 groups are created, UKOffice and USAOffice. All vSEC:CMS operators located in the UK office will be a member of the UKOffice group and all vSEC:CMS operators located in the USA office will be a member of the USAOffice group. Let's say we have operator named Tommy Ryan who is located in USA, then it would look something like below for the AD record:
And in the UK we have operator named Mike Murphy:
Similarly, all credential users located in the UK office will be a member of the UKOffice group and all credential users located in the USA office will be a member of the USAOffice. Let’s say we have user Alice Smith located in USA office, then the AD record would look like:
And in the UK we have user named James Doe:
Configure vSEC:CMS Templates
2 templates will be created, one for the USAOffice and one for the UKOffice.
USAOffice Template
1. From Templates - Card Templates click the Add button.
Click the Edit link beside General. Enter a template name. Presuming that you are using one of the minidriver credentials that is supported by vSEC:CMS select Minidriver (Generic minidriver card) for Card type.
In the Permissions section click the Manage button beside Check external permission. Click Add and enter a template name. Select AD groups (Verify AD group memberships) from the drop-down list and click Add.
If your organization has many groups the search mechanism can take a long time to complete. From version 6.11.3.2 it is possible to hit Esc button and enter the CN for the AD group and click Get.
Select the group (USAGroup as in this sample setup) that will be used from the available list and click Ok.
From version 6.11.3.2 a drop-down list is available. 3 options are available from here:
- Precomputed: Read from AD (Global and Universal groups only) - It will read the AD attribute: tokenGroupsGlobalAndUniversal from both users and determine the shared groups configured in vSEC:CMS.
- Search: Group membership of single user (nested groups) - It will run a query on AD: (member:1.2.840.113556.1.4.1941:=%UserDN%) for each user and determine the shared groups configured in vSEC:CMS.
- Search: Shared groups of both users (nested groups) - It will run a query on AD: (&(member:1.2.840.113556.1.4.1941:=%UserDN1%)(member:1.2.840.113556.1.4.1941:=%UserDN2%)) which returns the list of shared groups which both users are members of.
For optimal performance, and especially in organizations that have large number of AD groups, option 1 is recommended.
If you are going to allow self-service issuance with the template then you need to enter a valid DN into the field Operator DN for User Application. The DN entered here needs to be in the same AD group as the user who is performing self-service issuance.
It is recommended to use the Windows service account that vSEC:CMS is running under when setting Operator DN for User Application as it would be expected that this user does not change overtime when using vSEC:CMS.
You can perform a test at this stage to ensure that the configuration is correct. Click the Test button and for the first Get DN button select an Operator that is a member of the USAGroup and the second Get DN button select a user that is a member of the USAGroup and click Test. If the group permissions are valid a success dialog will appear.
Click Save to close and save.
Similarly do the same for the UKOffce group template.
Ensure to enable the checkbox Check external permission and select the group permission for this card template from the drop-down list.
Click Ok to save the settings.
2. Click the Edit link beside Issue Card. In the User ID Options section enable Assign user ID and select the AD connection in the drop-down list.
In the Enroll Certificate Options section enable Enroll certificate(s) checkbox and click the Add button. Select the Windows logon certificate template created earlier and click Ok.
Leave all other settings as is. You will notice that at the bottom of the dialog in the Permissions section that the Check external permissions is enabled with the group permission selected.
Click Ok to save and close.
3. Click Ok to save and close the template.
UKOffice Template
For the UKOffice configuration it will be the same as above but in this case we will use the UKOffice Windows group.
Test Permissions
Once the templates are configured as described above log onto the vSEC:CMS console with 2 different operators. Operator1 is a member of USAGroup and Operator2 is a member of UKGroup.
Operator1 will only be able to perform lifecycle operations for users who are members of USAGroup and likewise Operator2 will only be able to perform lifecycle operations for users who are members of UKGroup.
AD Group Pairs
With this mechanism it is possible to configure a list of AD group pairs (lets say GroupA and GroupB) where
- GroupA is an AD group where the vSEC:CMS operator who is performing the operation will be a member of and
- GroupB is an AD group where the user whose credential will be managed will be a member of.
When the external permission check is performed during an issuance, the AD group(s) where the operator is member of, will be retrieved. The same will be done for the user who the credential is being issued to.
The list of configured group pairs (GroupA+GroupB) will be checked to see if one of the retrieved AD groups is configured on the list for the operator and the user in the same pair.
The permission check will be passed successful if at least one pair in the configured list matches (meaning all pairs are handled as OR).
The permission check cannot be combined with the other available external permission check: AD groups (Verify AD group memberships).
Below we will describe how the Windows Group permissions could be configured to use this mechanism. It is expected that the reader has experience in using Windows AD and Windows Groups.
Nested groups are supported. The below query is run against AD: szQueryStr.Format(_TC("(&(member:1.2.840.113556.1.4.1941:=%s)(member:1.2.840.113556.1.4.1941:=%s))"), pszUserDN1, pszUserDN2);
Therefore the limitation will be from AD with regard to the depth that the query can navigate through groups.
To best describe how this mechanism could be used we will use an example use case. For example, you have different types of operators. One group of operators are consider elevated and another group are consider normal. Similarly you have users that are considered elevated and another group are consider normal.
The elevated operators can perform operations on all groups, namely elevated operators, normal operators, elevated users and normal users.
The normal operators can only perform operations on normal users.
In this case elevated operators are members of the Elevated Operators group and of the Normal Operators group. Normal operators are members only of the Normal Operators group.
Elevated users are members only of Elevated Users group. Normal users are members only of Normal Users group.
Configure vSEC:CMS Template
We will use one template to demonstrate how this could be configured.
1. From Templates - Card Templates click the Add button.
Click the Edit link beside General. Enter a template name. Presuming that you are using one of the minidriver credentials that is supported by vSEC:CMS select Minidriver (Generic minidriver card) for Card type.
In the Permissions section click the Manage button beside Check external permission. Click Add and enter a template name. Select AD group pairs (Verify AD group pairs memberships) from the drop-down list and click Add.
If your organization has many groups the search mechanism can take a long time to complete. From version 6.11.3.2 it is possible to hit Esc button and enter the CN for the AD group and click Get.
Select the group (USAGroup as in this sample setup) that will be used from the available list and click Ok.
From version 6.11.3.2 a drop-down list is available. 3 options are available from here:
- Precomputed: Read from AD (Global and Universal groups only) - It will read the AD attribute: tokenGroupsGlobalAndUniversal from both users and determine the shared groups configured in vSEC:CMS.
- Search: Group membership of single user (nested groups) - It will run a query on AD: (member:1.2.840.113556.1.4.1941:=%UserDN%) for each user and determine the shared groups configured in vSEC:CMS.
- Search: Shared groups of both users (nested groups) - It will run a query on AD: (&(member:1.2.840.113556.1.4.1941:=%UserDN1%)(member:1.2.840.113556.1.4.1941:=%UserDN2%)) which returns the list of shared groups which both users are members of.
For optimal performance, and especially in organizations that have large number of AD groups, option 1 is recommended.
The field Operator DN for User Application can be left blank. This field is for self-service issuance use cases which this mechanism is not appropriate for.
Click Add and select the AD group for Elevated Operators. Click the area under Group(s) - User as highlighted in the example below which will give you an option to click a Set button.
Click the Set button and select the Elevated Users group. Continue this until all the applicable pair combinations are added.
You can test the permission checks by clicking the Test button and try all combinations. For example, click the first Get DN button and select an operator that is a member of the Elevated Group. Then click the second Get DN button and select a user that is member of the Normal Users group. Click Test button. The test should be performed successfully.
Click the Report button to get more details on what is checked. Depending how you configured in your environment you should see something similar to below. Checks will be performed and if a pair is found that satisfies the criteria then the permission will be granted.
Click Save to close and save.
Ensure to enable the checkbox Check external permission and select the group permission for this card template from the drop-down list.
Click Ok to save the settings.
2. Click the Edit link beside Issue Card. In the User ID Options section enable Assign user ID and select the AD connection in the drop-down list.
In the Enroll Certificate Options section enable Enroll certificate(s) checkbox and click the Add button. Select the Windows logon certificate template created earlier and click Ok.
Leave all other settings as is. You will notice that at the bottom of the dialog in the Permissions section that the Check external permissions is enabled with the group permission selected.
Click Ok to save and close.
3. Click Ok to save and close the template.
Test Permissions
Once the template is configured as described above you can test the different scenarios with different operator types against the different user types.