Using AD and Entra ID Group Permissions

Introduction

You can use Active Directory (AD) and Entra ID group membership to control who can issue and manage credentials. This ensures that only authorized operators or users, who are members of specific groups, can perform these actions.

For instance, imagine a company with offices in different locations. Each office needs to manage its own employees' credentials. To achieve this, they can use AD or Entra ID groups.

• Each office has operators who are members of a specific "Credential Group."
• Employees at each office are also members of the same "Credential Group."
• When employees travel to other offices, they can be temporarily added to that office's "Credential Group."
• Because the visiting employees are now members of the local "Credential Group," the operators at that office can manage their credentials.

In essence, AD and Entra ID group membership acts as a gatekeeper, ensuring that only authorized individuals within a specific group can issue and manage credentials. This is particularly useful in distributed organizations where local administrators need to manage their local users.

Windows AD and Entra ID Group Permissions Configuration

Currently there are 2 mechanisms to perform AD and Entra ID group permission checks:

• Groups
• Group Pairs

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 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 (note that it would be the same if Entra ID is used) could be configured to use this mechanism. It is expected that the reader has experience in using Windows AD, Entra ID and Windows Groups.

Therefore the limitation will be from the directory 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 Directory groups (Verify Directory group memberships) from the drop-down list and click Add.

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:

1. 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. Important to note that this setting can only be used for AD environments and not with Entra ID environments.
2. Search: Group membership of single user (nested groups) - It will run a query: (member:1.2.840.113556.1.4.1941:=%UserDN%) for each user and determine the shared groups configured in vSEC:CMS.
3. Search: Shared groups of both users (nested groups) - It will run a query: (&(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.

If you are going to allow self-service issuance with the template then you need to enter a valid DN into the field Operator User ID for User Application. Click the Get User ID button and select a valid user. The selected user needs to be in the same group as the user who is performing self-service issuance.

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.

Group Pairs

With this mechanism it is possible to configure a list of group pairs (lets say GroupA and GroupB) where

• GroupA is an AD or Entra ID group where the vSEC:CMS operator who is performing the operation will be a member of and
• GroupB is an AD or Entra ID 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 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 groups is configured on the list for the operator and the user in the same pair.

Below we will describe how the Windows Group permissions (note that it would be the same if Entra ID is used) could be configured to use this mechanism. It is expected that the reader has experience in using Windows AD, Entra ID and Windows Groups.

Therefore the limitation will be from the directory 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 Directory group pairs (Verify Directory group pairs memberships) from the drop-down list and click Add.

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:

1. 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. Important to note that this setting can only be used for AD environments and not with Entra ID environments.
2. Read: Direct group membership only - It will run a query: (member:1.2.840.113556.1.4.1941:=%UserDN%) for each user and determine the shared groups configured in vSEC:CMS.
3. Search: Group membership (nested groups) - It will run a query: (&(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.

The field Operator User ID 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 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.