Obtain the Base DN or Bind DN Attributes for LDAP Directory Synchronization for PGP Encryption Server)

Products

Encryption Management Server Gateway Email Encryption Desktop Email Encryption Drive Encryption Endpoint Encryption File Share Encryption PGP Encryption Suite PGP Command Line PGP Key Management Server PGP Key Mgmt Client Access and CLI API PGP SDK

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 the 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

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 Symantec Encryption Management 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. There are a few methods for doing so:

Method 1: Powershell

The first method is to use Powershell, which requires the Active Directory Powershell Module part of the Administration tools.

Once you have this installed, from the command prompt, run the following:

get-aduser username-here -Properties *

The * denotes you want all attributes to be returned.

If you want to show the "proxyaddresses" attribute, put in the following command:

get-aduser username-here -Properties proxyaddresses

This will limit the results to only this attribute.

Method 2: DSQuery

In the following example, the domain example.com is used to find the Distinguished Name (Bind DN field for the Symantec Encryption Management 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 Symantec Encryption Management Server.

"CN=user1,CN=Users,DC=example,DC=com"

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 are:

The hostname of the LDAP Directory
The User DN (Distinguished Name)
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 4: Defining Attributes and Values for Consumer Desktop Policies on the Symantec Encryption Management Server

When multiple Symantec Encryption Desktop 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) instead of creating many static custom (preset) policies. Grouping logic is performed on each of the individual Groups in Symantec Encryption Management 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 Symantec Encryption Management Server for more details about Consumer Policies and Groups.

Defining Attributes would only be used in the following scenarios:

Symantec Encryption Management Server in Gateway deployment where all user's emails will be processed by the Symantec Encryption Management 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 Symantec Encryption Desktop 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 Symantec Encryption Management 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 is completed or Gateway placement users send email through the Symantec Encryption Management Server.

Section 3 of 4: Attribute Editor

If you enable the "Advanced Features" in Active Directory top-menu option, you can right-click any AD object, and go to the Properties, then click on the Attribute Editor.
In the Attribute Editor tab, you can view any of these above attributes and values in the UI.