HOW TO: Obtain the Base DN or Bind DN Attributes for LDAP Directory Synchronization

Article:HOWTO41996  |  Created: 2006-12-14  |  Updated: 2011-04-12  |  Article URL
Article Type
How To

Enrollment issues or issues related to Directory Synchronization can be impossible to solve if the LDAP syntax is incorrect. This document describes some basic steps in obtaining Base DN, Bind DN and Attributes or Values for correct usage for enrollment or PGP policies.

Section 1-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 Universal Server. However, the same concepts can be applied to other ldap directories as well.

Starting from the basics of Active Directory.

Below is a screenshot of a basic tree in Active Directory. This is a basic configuration, but the Bind DN is derived by using ldap syntax and going up the tree starting at the user.

For example, the user user1 is contained in Users, under The corresponding Bind DN is going to be 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 Universal Server can be performed by querying the Active Directory of a Windows 2003 Server. The query is performed at the command prompt of the Windows 2003 Server.

In the following example, the domain is in finding the Distinguished Name (Bind DN field for the PGP Universal Server) for user1. After obtaining the correct Distinguished Name, Softerra can be utilized to find users, attributes or values. The query is detailed below and can be used with Active Directory 2003 only.

Type the following command and press Enter

dsquery user dc=example,dc=com,-name user1*

If your user has a long name, the * will do a wildcard match for that user.


dsquery user dc=example,dc=com -name "user1"

These commands will return the correct Bind DN for Directory Synchronization on the PGP Universal Server.


Unless Active Directory 2003 is being used, it will be necessary to find the Bind DN manually. Using an ldap browser such as Softerra (below), 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 PGP Universal Server, it will let you know immediately if the ldap syntax is incorrect as stated below 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 an example of the properties for the user user1 and how the Distinguished Name corresponds to the Bind DN in Directory Synchronization.

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.Therfore, the Bind DN is CN=user1,CN=Users,DC=example,DC=com.

If the domain was, the syntax would be DC=example,DC=net. DC is used for the domain credentials. CN is used for the User credentials.

Compare what is in Softerra as in the screenshots in previous examples and what is in PGP Universal Server-the credentials should match exactly. A copy and paste will ensure no typos are made.

When browsing to the user as in the previous screenshot, the Distinguished Name is what defines the Bind DN inside of Directory Synchronization.

Once you have defined the Bind DN inside of PGP Universal 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:

B. Multiple PGP Desktop policies are going to be used. Configuring attributes and values can help assign users into groups dynamically instead of creating many custom preset policies.

Section 2 - Defining Attributes and Values for Desktop policies on the PGP Universal Server.

Defining Attributes would only be used in the following scenarios:

A. PGP Universal Server in Gateway deployment where all user's emails will be processed by the PGP Universal 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.

B. Multiple PGP Desktop 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 entered into Directory Synchronization correctly, the next step is to define Attributes for the Users. Specifying Attributes and Values in the individual PGP Desktop policies will allow PGP Universal Server to assign individual users into separate policies that have been created.

For the example below, a 'memberOf' Attribute is specified for the user in the 'israel_team' group. These Attributes and Values are also specified on the PGP Universal Server. PGP Universal Server will then query AD to assign users into specific PGP Desktop Policies . The Name in the example below is the Attribute within PGP Universal Server and the Value is in fact, the Value inside of PGP Universal Server:

Again, compare what is in Softerra and what is in PGP Universal 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 PGP policies once enrollment completes or in Gateway placement when users send email through the Universal server.


Legacy ID


Article URL

Terms of use for this information are found in Legal Notices