Using the certificate on a smartcard, an user can enroll by simply 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.

Requirements:

• Need AD to be configured and properly integrated into the PGP Server.
  If regular LDAP enrollment is working, this step is done.

• The Smartcard middleware must be installed on the machine previous to user enrollment in order use certificate based enrollment.
  If the Smartcard is working in general within Windows, then this step is done.
  
  
• Windows should be setup properly so that the user logs in using Smartcard certificates and not Windows credentials.
  If the Smartcard can be used to login to Windows, then this step is done.
  
  
• The Root certificate that was used to create the user certificate on the Smartcards must be added to the Trusted Keys section of PGP Server.
  This is particularly important if the Root/Intermediate Certificate is an internal CA. 
  
  To add this, locate the applicable Root/Intermediate, click on Keys, Trusted Keys, and Add the key.  Be sure to check all the boxes as you are adding these.
  For more information on Trusted Keys, review the following article:
  
  180143 - HOW TO: Work with Trusted Keys and Certificates on Symantec Encryption Management Server (PGP Server)

Responsibilities of the PGP Server:

• Establishes TLS session using the client certificate.
• Retrieves the client certificate from Apache and passes it on to the backend of the PGP Server.
• 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 the PGP  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.

Note: If you do not want to use a certificate to enroll, select "Deny".

If you are wanting to disable all Certificate Harvesting associated with users, please reach out to Symantec Encryption Support for further Guidance.
EPG-23238

When the user enters the PIN  of the smartcard, the PGP Server tries to obtain the certificate for verification.  Once the certificate is obtained, it will be cached within its connection.  When the client communicates with the PGP Server, the certificate will be used as validation and then sends all application information to AD for that particular user.  When the user is found, the enrollment process then attempts to match the certificate on the smartcard with the certificate in AD for the user.  If it matches, then a new user is created on the PGP server.

As mentioned above in the requirements section, 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 PGP Server, then the enrollment will fail. The PGP 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 PGP Server.
*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., the fall back for the other enrollment methods will take place as per the configured settings.

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 the PGP Server and trusted.

Applies To

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.