Using the certificate on a smartcard, a user can now enroll by only entering the PIN of the smartcard. This allows users to enroll with the certificates on the smartcard and the user does not need to know the Active Directory (AD) password to enroll. The AD still needs to be present and configured on the Symantec Encryption Management Server in order to authenticate and match the certificate for the user that is on the smartcard and in AD.
PGP Desktop 10.2 and PGP Universal Server 3.2 or above, or Symantec Encryption Desktop and Symantec Encryption Management Server(SEMS)
Need AD to be configured and properly integrated into SEMS.
The smartcard middleware must be installed on the machine previous to user enrollment in order use certificate based enrollment.
Windows should be setup properly so that the user logs in using smartcard certificates and not Windows credentials.
The Root certificate that was used to create the user certificate on the smartcards must be added to the Trusted Keys section of SEMS .
Responsibilities of the Universal Server:
Establishes TLS session using the client certificate.
Retrieves the client certificate from Apache and passes it on to the backend of SEMS.
Authenticates the user using the public data in AD.
Backend creates all the consumer mapping and enrolls the user.
In the Directory Synchronization settings of PGP Universal Server, the following settings are allowed:
Force: Forces the use of smartcards to enroll and if certificate enrollment fails, the enrollment process halts. Deny: Forces using either LDAP or email enrollment and cannot use smartcards to enroll. Allow: Tries to enroll with smartcards first, then if smartcard enrollment fails, it will fall back to LDAP enrollment.
When the user enters the PIN of the smartcard, SEMS tries to obtain the certificate. Once the certificate is obtained, it will be cached within its connection. When later a call is made from client, the Symantec Encryption Management Server will get the certificate and then forwards the call and queries to the AD for that particular user. When the user is found, it attempts to match the certificate on the smartcard with the certificate in the AD for the user. If it matches, then a new user is created on the SEMS.
It is required to configure the Root Certificate that was used to create the user certificate on the smartcard. If the certificate on the smartcard was not signed by any Root CA in the Trusted Keys section on Symantec Encryption Management Server, then the enrollment will fail. The Admin must upload the Root CA into the Trusted Certificates on SEMS. Once the Root CA is uploaded to the Trusted Keys section, Symantec Encryption Management Server will then match the user certificate with the signer key and allow enrollment.
PGP Desktop Client Behavior: *Client checks if a smartcard is present and cert enrollment is allowed. *If the above conditions are met a dialog will appear asking for the user's PIN of the smartcard. *After the user enters the PIN, it unlocks the smartcard and uses the X .509 on the smartcard to authenticate the user with the SEMS. *After enrollment proceeds, the user will see the PGP Setup Assistant. *If Certificate enrollment fails, the client will try alternative ways to enroll if allowed by policy.
Troubleshooting: If the smartcard has issues, trusted keys, etc., we'll fall back for the other enrollment methods if the settings have been set.
If certificate enrollment does not start (you see LDAP dialogue instead of asking for PIN): *Make sure middleware for smartcard is installed and configured properly. *Make sure smartcard is inserted and can see keys from middleware UI. *Make sure the certificate enrollment is allowed or forced. *Make sure the Root CA is uploaded into the Trusted Keys section of Symantec Encryption Management Server and trusted.
Scenario: There are users who don't use windows passwords to login to Windows, but rather use a smartcard for authentication. The PIN for a smartcard is what is actually used to login to Windows, or to otherwise authenticate where login credentials would normally be used.
All that is needed is the smartcard, the user's certificate as it appears in AD and the PIN.
Imported Document ID: TECH173970
Subscribing will provide email updates when this Article is updated. Login is required.