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 Symantec Encryption Management 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.
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 Symantec Encryption Management Server. However, the same concepts can be applied to other LDAP Directories as well.
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 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:
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 wanted 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.
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 - 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:
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 completes or Gateway placement users send email through the Symantec Encryption Management Server.