PGP Desktop LDAP Enterprise Enrollment

This document provides a technical, experiential, and chronological overview of PGP Desktops LDAP enterprise enrollment process. Each step of the enrollment process is highlighted in bold, and includes a detailed explanation. If you just want an overview, you can simply read the bold statement that begins each step or sub-step.

All paths, filenames, and other special details are offset in a contrasting font with gray text, as in the following example: %APPDATA%\PGP Corporation\PGP

1. PGP Desktop is installed. Although the actual enrollment process does not technically begin when PGP Desktop is installed, the following install-time events (1a 1b) will facilitate various steps essential to the enrollment process, and are included for completeness: a. A shortcut to PGPtray.exe is placed in the All Users startup directory. This shortcut will cause the PGP Setup Assistant to be launched automatically after the next Windows logon. Following is the full path and name of this shortcut file: %ALLUSERSPROFILE%\Start Menu\Programs\Startup\PGPtray.exe.lnk

Following is the full path and name of the program that will be launched after the next Windows logon: %PROGRAMFILES%\PGP Corporation\PGP Desktop\PGPtray.exe

b. A null-terminated string called PGPSTAMP is created in the Windows registry. The value of PGPSTAMP comprises, among other things, the fully qualified domain name of the PGP Universal Server from which this PGP Desktop installation will request policy. This value is also known as PGP Desktops binding (i.e. PGP Desktop is bound to the PGP Universal Server specified in this string). Following is the full path and name of this null-terminated string in the registry: HKEY_LOCAL_MACHINE\SOFTWARE\PGP Corporation\PGP\PGPSTAMP

Following is an example PGPSTAMP value. Note that ovid is the name of the PGP Universal Server to which PGP Desktop is bound. So in this example, PGP Desktop is bound to the keys.example.com PGP Universal Server: ovid=keys.example.com&mail=mail-01&admin=1

2. The computer is rebooted. This is a necessary step because after installation PGP Desktop cannot be used until the computer is rebooted.

3. The user logs on to Windows and PGPtray.exe is executed. The following noteworthy events (3a 3c) occur during this step: a. PGP Desktop synchronizes with its PGP Universal Server. During this brief step, PGP Desktop announces its protocol version and asks PGP Universal Server for the enrollment type (email or LDAP) by sending a GetCapabilitiesRequest message. The server responds with the enrollment type and the connection is closed. This, and all other client-server communication during enrollment, occurs via SOAP over HTTPS on port 443. b. If configured, the PGP Desktop padlock appears in the system tray. This event depends on whether the option Show PGP Desktop in system tray/menu was enabled in the user policy for this PGP Desktop installer. Following is a screenshot of the padlock icon as it appears in the Windows system tray:

c.

The PGP Setup Assistant launches. When the enrollment type is LDAP, the user is first prompted for their domain authentication credentials (as in the following screenshot):

4. The user authenticates. This step consists of the user typing his or her domain user name and password in the appropriate fields and clicking the Next > button, after which the following noteworthy events (4a 4c) occur: a. PGP Desktop sends the users credentials to its PGP Universal Server. During this step, PGP Desktop also announces its version number (e.g. 9.5.3.5003) to PGP Universal Server, and displays the following dialog on top of the PGP Setup Assistant:

b. PGP Universal Server verifies the users credentials. To accomplish this task, PGP Universal Server authenticates to the LDAP directory as the enrolling user. This process is described in detail below. PGP Universal Server first binds to the LDAP directory using the credentials specified in its Directory Synchronization settings (Policy > Internal User Policy), then requests the value of the distinguished name attribute ( dn ) for the enrolling user. Depending on how Directory Synchronization is configured, this query is accompanied with a filter for either Active Directory or OpenLDAP (RFC 1274) directories. Following are examples of these filters, where pgpuser is the user name provided by the enrolling user:

Active Directory filter: (sAMAccountName=pgpuser) OpenLDAP (RFC 1274) filter: (uid=pgpuser)

The directory server then responds with the value of the users dn attribute, which typically looks something like this example:

CN=pgpuser,CN=Users,DC=example,DC=com

PGP Universal Server closes the connection to the LDAP directory, then initiates a new connection and binds with the distinguished name and password of the enrolling user. When this is successful, PGP Universal Server once again closes the connection to the LDAP directory and the user is considered authenticated.

c.

PGP Universal Server assigns the user to an internal user policy. In order to complete this step, PGP Universal Server must gather more information about the enrolling user from the LDAP directory. As a result, PGP Universal Server queries the LDAP directory for the values of the following attributes:

mail proxyAddresses (Active Directory only) cn samAccountName (Active Directory only)

After querying for the above attributes, PGP Universal Server will query for any custom attributes specified by the administrator in the internal user policies.

NOTE: If custom attributes have been specified, the user will be assigned to the first internal user policy for which they have a matching attribute/value. As a result, PGP Universal Server administrators should use unique attributes/values such that users cannot match more than one internal user policy.

Finally, PGP Universal Server queries for the following attribute:

userCertificate;binary

If a verified X.509 certificate is returned by this query, PGP Universal Server imports it as the users key. This will place the user in client key mode (CKM) because PGP Universal Server will only have a public key for the user.

At this point, PGP Universal Server updates the internal_user table in its database with the information gathered in this step. The user is now allowed to continue the PGP Setup Assistant. Note that, in its entirety, step four takes approximately two seconds.

5. The user is allowed to complete the PGP Setup Assistant. The remaining steps will vary based on the internal user policy settings configured by the PGP Universal Server administrator.

Below is a summarized list of the requirements for successful LDAP enrollment with PGP Desktop.

Required Attributes The following directory attributes must be defined, and have a value, in order for LDAP enrollment with PGP Desktop to be successful. Note that Microsoft Active Directory 2000/2003 with Exchange Server will have all required attributes, while other directory/mail server combinations may not. uid or samAccountName (interchangeable) dn (this will exist if the user exists) mail or proxyAddresses (interchangeable) cn (for the users display name in PGP Universal Server)

Optional Attributes Any custom attributes specified in internal user policies.

userCertificate;binary

Password Requirement The enrolling user cannot have a null password in the directory. This is a security feature of PGP Desktop, and allows PGP Universal Server to verify the users authentication credentials as a part of the enrollment process.