Obtaining the Base DN or Bind DN Attributes for LDAP Directory Synchronization for the PGP Encryption Server (Symantec Encryption Management Server)
Article ID: 218617
Updated On:
Products
Issue/Introduction
The PGP Encryption Server (Symantec Encryption Management Server) can incorporate the feature of Directory Synchronization to automatically group users based on LDAP Attributes and values as well as authenticate users for Symantec Encryption Desktop client enrollment.
While this can help in grouping users logically to correct Group Policies and assist with enrollment to a PGP Encryption Server, proper LDAP syntax is required.
This document describes some basic steps in obtaining Base DN, Bind DN, and Attributes and Values for correct usage for enrollment and grouping.
Resolution
There are a few methods to obtain the syntax, one is in Active Directory itself, using the Advance Features.
Another method is is to use the Command Prompt on your AD Windows server with "dsquery".
There are also third-party applications, such as Softerra LDAP Browser that can be used to derive the syntax.
Table of Contents
Section 1 of 3: Defining Base DN and Bind DN for Directory Synchronization
This document is geared toward Microsoft Active Directory and the Softerra LDAP browser to obtain correct syntax for Directory Synchronization used in PGP Encryption Server.
These same concepts can be applied to other LDAP Directories as well such as OpenLDAP.
Basics of Active Directory
With LDAP syntax the Bind DN, or the user authenticating to the LDAP Directory, is derived by using LDAP syntax and going up the tree starting at the user component.
For example, the user user1 is contained in the Users container, under the example.com domain. The corresponding Bind DN will look like the following:
CN=user1,CN=Users,DC=example,DC=com, but this will be discussed in more detail in the following steps.
An easy way to find the Bind DN that is needed for the PGP Encryption Server can be performed by querying the Active Directory on a Windows Server which has connectivity to Active Directory.
The query is performed at the command prompt of the Windows Server.
In the following example, the domain example.com is used to find the Distinguished Name (Bind DN field for the PGP Server) for user1.
After obtaining the correct Distinguished Name, Softerra can be utilized to find users, attributes, and values.
The query is detailed below and can be used with Active Directory 2003 and above.
Type the following command and press Enter
dsquery user dc=example,dc=com -name username-here*
If your user has a long name, the * will do a wildcard match for that user. For the example below, we'll use a username of "user1"
Or
dsquery user dc=example,dc=com -name user1
Note: The bolded elements above in the example above are the only items that need to be modified. The name "user" in the example above is literally "user". The username "user1" is specified at the end of the command.
These commands will return the correct Bind DN for Directory Synchronization on the PGP Encryption Server.
"CN=user1,CN=Users,DC=example,DC=com"
Here is a screenshot of a result on a Windows Server 2019 command prompt with the output highlighted:
--
--
Unless Active Directory 2003 or above is being used, it will be necessary to find the Bind DN manually. Using an LDAP browser such as Softerra, can help out. When using Softerra, the credentials will need to be entered for the user binding to the LDAP Directory when you create a new profile:
Although Softerra will not tell you the exact Bind DN needed for Symantec Encryption Management Server, it will let you know immediately if the LDAP syntax is incorrect and help in your trial-and-error process. The fields necessary to find correct syntax is the hostname of the LDAP Directory, the User DN (Distinguished Name), and the password (don't use anonymous bind as this will not show you accurate query results).
Once the LDAP syntax is correct, a successful bind will show you the directory similar to how it appears in Active Directory.
Below is a break-down of how user credentials are translated within LDAP (very basic example). The Bind DN is comprised of the user and the location of the user in the LDAP directory tree.
Each element of the Distinguished Name is pointed out:
The first part is the user CN=user1.
The second part is the container CN=Users.
The third part is the domain DC=example and DC=com.
Therefore, the Bind DN is: CN=user1,CN=Users,DC=example,DC=com.
If the domain was example.net, the syntax would be DC=example,DC=net. DC is used for the domain portion, and CN is used for the User credentials.
After comparing what is in Softerra and what is in Symantec Encryption Management Server, the credentials should match exactly. A copy and paste will ensure no typos are made.
When browsing to the user, the Distinguished Name is what defines the Bind DN inside of Directory Synchronization.
Once you have defined the Bind DN inside of Symantec Encryption Management Server, you can also enter the Base DN, which is the latter part of the Bind DN. This will start the query from the top level down, but this can be configured to search lower in the tree.
Section 2 of 3: Defining Attributes and Values for Consumer Desktop policies on the PGP Encryption Server.
When multiple Consumer policies are going to be used, it is helpful to configure attributes and values to help assign users into these groups dynamically (auto-detect - Recommended) instead of creating many static custom (preset) policies.
Grouping logic is performed on each of the individual Groups in the PGP Encryption Server, and each Group has a Consumer Policy assigned.
In order to get the Consumer Policy desired, match into the Group, and ensure the Consumer Policy is linked to that Group.
See the Administrative Guide or Help file on PGP Encryption Server for more details about Consumer Policies and Groups.
Defining Attributes would only be used in the following scenarios:
- The PGP Encryption Server in Gateway deployment where all user's emails will be processed by the PGP Server, but only a certain amount of users should be encrypting.
Defining attributes can allow only certain users to be enabled or disabled so encryption will occur for some and not for others.
- Multiple PGP Encryption Consumer policies are going to be used.
Configuring attributes and values can help assign users into groups dynamically instead of creating many custom preset policies.
Once you have the Base and Bind DN values entered into Directory Synchronization correctly, the next step is to define Attributes for the Users. Specifying Attributes and Values in the individual Groups on the PGP Encryption Server will allow individual users into separate Groups that have been created, and corresponding Consumer Policies.
Again, compare what is in Softerra and what is in Symantec Encryption Management Server. The Attributes and Values should match exactly. A copy and paste will ensure no typos are made.
Once you have followed these basic guidelines, you should be able to get Users to be assigned to your specific Groups based on attributes and values once either enrollment completes or Gateway placement users send email through the Symantec Encryption Management Server.
Section 3 of 3: "Advanced Features" within Active Directory
Now that you are an expert with the general usage of LDAP syntax, probably the easiest way to find out the exact syntax is with the Active Directory Users and Computers application itself.
To use this, simply login to the aforementioned application, click on the View top menu, then click on Advanced Features.
You can now right-click any AD object, such as a user, security group, etc, then click "Properties".
You will now have a tab called "Attribute Editor" where you can view every attribute available to the user.
Use this to your advantage with Directory Synchronization Configuration, as well as matching users to groups (and its corresponding Consumer Policy).
Feedback
