Complete Contents
About This Guide
PART 1: Netscape Certificate Management System
Chapter 1: Introduction to Certificate Management System
Chapter 2: Administration Tasks and Tool
Chapter 3: Configuration
PART 2: Managing Certificate Management System
Chapter 4: Installing and Uninstalling Instances
Chapter 5: Starting and Stopping Instances
PART 3: System-Level Configuration
Chapter 6: Configuring Ports, Database, and SMTP Settings
Chapter 7: Managing Privileged Users and Groups
Chapter 8: Keys and Certificates
PART 4: Authentication
Chapter 9: Introduction to Authentication
Chapter 10: Using the PIN Generator Tool
Chapter 11: Configuring Authentication for End Entities
Chapter 12: Developing Authentication Plug-ins
PART 5: Job Scheduling and Notification
Chapter 13: Introduction to Job Scheduling and Notifications
Chapter 14: Configuring Jobs
PART 6: Policies
Chapter 15: Introduction to Policies
Chapter 16: Configuring Policies
PART 7: LDAP Publishing
Chapter 17: Introduction to LDAP Publishing
Chapter 18: Configuring Subsystems for LDAP Publishing
Chapter 19: Publishing CRLs
PART 8: Agent and End-Entity Interfaces
Chapter 20: Introduction to End-Entity and Agent Interfaces
Chapter 21: Customizing End-Entity and Agent Interfaces
PART 9: Logs
Chapter 22: Introduction to Logs
Chapter 23: Managing Logs
PART 10: Issuance and Management of End-Entity Certificates
Chapter 24: Issuing and Managing End-Entity Certificates
Chapter 25: Recovering Encrypted Data
PART 11: Appendixes
Appendix A: Distinguished Names
Appendix B: Backing Up and Restoring Data
Appendix C: Command-Line Utilities
Appendix D: Certificate Database Tool
Appendix E: Key Database Tool
Appendix F: Netscape Signing Tool
Appendix G: SSL Strength Tool
Appendix H: SSL Debugging Tool
Previous Next Contents Index Bookshelf


Chapter 9 Introduction to Authentication

Authentication is the process of verifying the identity of a user that is requesting a service from Netscape Certificate Management System (CMS). More specifically, authentication involves acquiring and verifying the values of the configured attributes of the user. For example, the user might be prompted to log in with a user name and password, and then the server would look in a preconfigured database to verify that the user's password was correct.

Service requests to Certificate Management System come from any of the following users:

 This chapter explains how Certificate Management System identifies and authenticates these users, and it provides details about the various authentication mechanisms supported out of the box. After reading this chapter, you should be able to determine which of the authentication plug-in modules provided out of the box is suitable for your PKI deployment.

 This chapter has the following sections:
Privileged-User Authentication
For authenticating privileged users, such as administrators and agents, Certificate Management System uses built-in authentication mechanisms.

 Authentication of Administrators

When an administrator makes an administrative request to Certificate Management System (from the CMS window within Netscape Console or from any command-line tool), the server needs to authenticate the administrator before processing the request. To facilitate this, Certificate Management System supports an authentication mechanism that includes user ID- and password-based authentication from the client and SSL server authentication from the server.

Certificate Management System identifies and authenticates users with administrator privileges by checking their user IDs and passwords in its internal database. These are the user IDs and passwords you entered in the internal database when you created these user entries. For details, see "Setting Up Administrators".

Figure 9.1 illustrates the authentication process.

Figure 9.1 CMS authentication of a user with administrator privileges

These are the steps shown in Figure 9.1:

  1. An administrator opens Netscape Console and attempts to log in to the CMS window by entering the user ID and password at the login prompt. The server takes the administrator's user ID and password and binds them to privileged-user entries in its internal database.
    2.

  2. If the user ID and password bind successfully to a user entry, authentication succeeds; otherwise, it fails.

    3. If both authentication and authorization succeed, the server services the request. Otherwise, it rejects the request and logs the reason for the rejection.

Note Authentication for administrators is hardcoded; it is not configurable.

Authentication of Agents

When an agent makes a request to Certificate Management System from the appropriate Agent Services interface, the server needs to authenticate the agent before processing the request. To facilitate this, Certificate Management System supports a certificate-based authentication mechanism.

Certificate Management System identifies and authenticates a user with agent privileges by checking the user's SSL client certificate in its internal database. The certificates it checks are the ones you imported and stored in the internal database while creating or modifying the user entry. You create agent users for a CMS instance by adding their client certificates into the internal database and associating them with the corresponding users' login information; for details, see "Setting Up Agents".

When an agent makes a request to perform a privileged operation, the server requests SSL client authentication from the client that the agent has used to connect to the server. The server then uses the successfully SSL client-authenticated certificate to map to internal user entries for further checks. The server checks the certificate's subject name and issuer name against the list of privileged-user certificates stored in its internal database. If the certificate belongs to a privileged user who is authorized (based on group membership) to perform agent operations, the server allows the user to perform the requested operation. Otherwise, the server rejects the request and logs an appropriate message (for details, see "Logs").

Note Authentication for agents is hardcoded; it is not configurable.

Figure 9.2 shows how a Registration Manager authenticates and authorizes a Registration Manager agent.

Figure 9.2 Registration Manager authentication of a user with Registration Manager agent privileges

This example shows these steps:
  1. An agent opens a web browser and enters the URL to the Registration Manager Agent Services interface hosted by the Registration Manager. The server requests the client for SSL client authentication. The client in turn prompts the agent to specify the certificate that it should present to the server for authentication. The successfully SSL client authenticated certificate is presented to the Registration Manager.
    2.

  2. Upon receiving the certificate, the Registration Manager performs the following authentication and authorization process:

    3. If both authentication and authorization succeed, the Registration Manager services the request. Otherwise, it rejects the request and logs a reason for the rejection.


End-Entity Authentication During Certificate Enrollment
When an end entity submits a certificate request, a Certificate Manager or Registration Manager's first task is to identify and authenticate the end entity. The server must perform this task before it can register the end entity for certificate issuance. This process includes verifying the end entity's identity based on information the end entity provides and returning enough information about the end entity so that the subject name for the certificate can be constructed.

 To cater to a variety of end-entity enrollment scenarios, Certificate Management System supports both manual and automated certificate issuance. Manual issuance is dependent on human agents; it requires that all end-entity certificate requests be approved by agents before the server can process the requests. Automated certificate issuance is dependent on directories that have been populated with end-entity entries so that the server can use them for authentication.

 For automated certificate issuance, Certificate Management System supports the following authentication mechanisms out of the box:

 Because large corporations typically store corporatewide user, group, and network-resource data in LDAP-compliant directories, the directory-based authentication supported out of the box by Certificate Management System is based on LDAP-compliant directories, such as Netscape Directory Server. If you have an LDAP-compliant directory with end-entity data, you can make use of any of the directory-based authentication plug-in modules provided out of the box. In that case, the only information your end entities need to provide during certificate enrollment is their user ID and password for the directory.

 If you don't have an LDAP-compliant directory, you can customize end-entity authentication by using your own authentication modules. For details on writing custom modules and adding them to the CMS authentication framework, see "Developing Authentication Plug-ins".

Keep in mind that in an automated certificate management setup, Certificate Management System uses the directory-based authentication models only during certificate enrollment. During certificate renewal and revocation processes for end entities, the server relies solely on end entities' current certificates; that is, certificates are renewed or revoked only after successful SSL client authentication.

 Certificate Management System also provides HTML forms-based interfaces for all of the authentication mechanisms it supports out of the box. Your end entities can use these forms for certificate enrollment, renewal, and revocation. You can also customize these forms. For details on the HTML forms, see "Agent and End-Entity Interfaces".

Manual Authentication

The manual authentication mechanism is suitable for authenticating end entities during certificate enrollment, renewal, and revocation. Use this mechanism for authenticating unprivileged users.

Note The manual authentication mechanism is hardwired; you cannot configure it in any other way. This ensures that when the server receives requests that lack authentication credentials, it sends them to the request queue for agent approval. It also means that if you don't configure Certificate Management System for any other authentication mechanism, the server automatically sends all certificate-related requests to a queue where they await agent approval.

Figure 9.3 illustrates how the manual authentication mechanism works during certificate enrollment.

Figure 9.3 Manual authentication of end entities

These are the steps shown in Figure 9.3:

  1. In the manual enrollment form, the end entity enters the information required by Certificate Management System to issue a certificate and submits the request to the server.
    2.

  2. When the server receives the request, it automatically lists the request in a certificate request queue for an agent to process.

  3. An agent verifies the authenticity of the request.

  4. When the server receives the agent-approved request, it subjects it to policy processing; for details, see "Policies".

    5. The end entity gets the certificate, which is delivered to the email address provided in the certificate request form.

Directory-Based Authentication

Directory-based authentication is suitable for authenticating end entities during certificate enrollment. Use this mechanism for authenticating unprivileged users in the global LDAP domain.

In this authentication model, the end entities enroll for a certificate by entering their user IDs and passwords for the directory. As part of configuring Certificate Management System for authentication, you specify which directory Certificate Management System must use to authenticate end entities. Once the server successfully authenticates an end entity, it retrieves the rest of the information required to issue a certificate from the directory.

 Figure 9.4 illustrates how authentication based on a user ID and password works during certificate enrollment.

Figure 9.4 User ID- and password-based authentication of an end entity

These are the steps shown in Figure 9.4:

  1. In the directory-based certificate enrollment form, the end entity enters a user ID and password for the directory and submits the request to Certificate Management System.
    2.

  2. When the server receives the request, it looks up the directory that is configured for authenticating end entities. The server verifies the authenticity of the end entity by checking the directory entries.

    3. If, for some reason, the directory to which Certificate Management System binds for authenticating the user ID and password is unavailable, the server returns an LDAP error code.

  3. Next, the server subjects the certificate request to policy processing; for details, see "Policies".

    4. The end entity gets the certificate, which is delivered to the end entity's email address in the directory.

Plug-in Module for User ID- and Password-Based Authentication

The plug-in module provided for authenticating end entities based on their user IDs and passwords (for the directory) is identified as follows:

com.netscape.certsrv.authentication.UidPwdDirAuthentication

 Configurable Parameters

Figure 9.5 shows how configurable parameters pertaining to the UidPwdDirAuth plug-in implementation are displayed in the CMS window.

Figure 9.5 Parameters and values for the plug-in UidPwdDirAuth

Table 9.1 gives details about each of these parameters and their values.

Table 9.1 Configurable parameters for directory-based authentication and their values

Parameter name
Description
dnpattern
Specifies a string representing a subject name pattern to formulate from the directory attributes and entry DN. The syntax is illustrated in the following example:

E=$attr.mail.1, CN=$attr.cn, OU=$dn.ou.2, O=$dn.o, C=US

This sample configuration specifies that the subject name should be formulated as follows:

If this parameter value is empty or not set, the server uses E=$attr.mail, CN=$attr.cn, O=$dn.o, C=$dn.c as the DN pattern.

This default DN pattern works well with Communicator and other browsers. For Communicator, if you leave out E= in end-entity certificates, S/MIME may not work correctly (assuming lack of other extensions in the certificate). Also, if C= and O= are left out, certificate display looks strange in Communicator (when the Display Certificate button is clicked).

Permissible values: Any valid DN string composed from standard DN attributes, which must be separated by commas

Object type: String
ldapAttributes
Specifies the list of LDAP attributes that should be considered authentic for the end entity. If specified, the values corresponding to these attributes will be copied from the authentication directory into the authentication token--that is, values retrieved from this parameter can be used by policy modules to form subject names or to make other policy decision (see "Subject Alternate Name Extension Policy").

Entering values for this parameter is optional.

Example: mail, mailalternateaddress

This sample configuration specifies that mail and mailalternateaddress should be stored in the authentication token.

Permissible values: Any valid LDAP attributes, separated by commas

Object type: String

ldap.ldapconn.host

Specifies the host name of the authentication directory.

Example: auth_dir.netscape.com

Permissible values: The name must be in this form: <machine_name>.<your_domain>.<domain>

Object type: String

ldap.ldapconn.port
Specifies the TCP/IP port at which the authentication directory listens to requests from Certificate Management System.

Example: 389

Permissible values: Any valid port number

Object type: Integer

ldap.ldapconn.secureConn
Specifies the type--SSL or non-SSL--of the port at which the authentication directory listens to requests from Certificate Management System.

Example: false

Permissible values: Either of the following:

Object type: String

ldap.ldapconn.version
Specifies the LDAP protocol version.

If your authentication directory is based on Netscape Directory Server 1.x, choose LDAP version 2. For Directory Server versions 3.x and later, choose LDAP version 3.

Example: 2

Permissible values: Either of the following:

Object type: String

ldap.baseDN
Specifies the base DN for searching the authentication directory.

Example: o=airius.com

Permissible values: Any valid DN string of up to 255 characters

Object type: String

ldap.minConns
Specifies the minimum number of connections permitted to the authentication directory.

Example: 2

Permissible values: 1 to 3

Object type: Integer

ldap.maxConns
Specifies the maximum number of connections permitted to the authentication directory.

Example: 10

Permissible values: 3 to 10

Object type: Integer

Directory-Based Authentication with PINs

This authentication model is functionally very similar to the directory-based authentication model based on user ID and password, except that for stronger authentication you combine a PIN or one-time password with the end entity's user ID and password. Use this mechanism for authenticating unprivileged users in the global LDAP domain.

In the directory plus PIN-based authentication model, the end entities enroll for a certificate by entering their user IDs, passwords, and PINs for the authentication directory. As part of configuring Certificate Management System for authentication, you specify the directory that Certificate Management System must use to authenticate end entities. Once the server successfully authenticates an end entity, it retrieves the rest of the information required to issue a certificate from the directory.

In the authentication model based on user ID, password, and PIN, you have the following choices:

 Important End-entity entries in directories usually do not contain PINs. To be able to use the directory-based authentication with PINs, you must add PINs to the authentication directory first. To do this, follow the information provided in "Using the PIN Generator Tool".

Plug-in Module for User ID-, Password-, and PIN-Based Authentication

The plug-in module provided for authenticating end entities based on their user IDs, passwords, and PINs is identified as follows:

com.netscape.certsrv.authentication.UidPwdPinDirAuthentication

 Configurable Parameters

Figure 9.6 shows how configurable parameters pertaining to the UidPwdPinDirAuth plug-in module are displayed in the CMS window.

Figure 9.6 Parameters and values for the plug-in UidPwdPinDirAuth

Table 9.2 gives details about each of these parameters.

Table 9.2 Configurable parameters for directory-based authentication with PINs and their values

Parameter name
Description
removePin
Specifies whether to remove PINs from the authentication directory (after end entities successfully authenticate).

If you set the value of this parameter to true, you must also specify the values for the removePinBindDN and removePinBindPrompt parameters. Removing PINs from the directory restricts users from enrolling more than once, and thus prevents them from getting more than one certificate.

Example: true

Permissible values: Either of the following:

Object type: String

ldap.ldapauth.
bindDN

Specifies the user entry to bind as when removing PINs from the authentication directory. You need to specify this parameter only if you've set the value of the removePin to true. It is recommended that you create and use a separate user entry that has permission to modify only the PIN attribute in the directory. For example, don't use the directory manager's entry as it has privileges to modify the entire directory content.

Example: cn=remove_pin_user

Permissible values: A valid bind DN

Object type: String

ldap.ldapauth.
bindPWPrompt

Specifies the text used for constructing the password prompt for entering the password associated with the DN specified by the ldap.ldapauthbindDN parameter. You need to specify this parameter only if you've set the value of the removePin to true.

If you configure the authentication instance to remove PINs from the directory, you are required to restart the server from the command line. When you do that, you will be prompted to enter the password associated with the ldap.ldapauthbindDN parameter. The prompt is constructed using the value you enter in this field. For example, if you enter Remove PIN Bind DN
as the value, the resulting prompt would be "Enter password for Remove PIN Bind DN".

Note that the server prompts for this password when you restart the server the first time after you configure the PIN-based authentication instance. The server then stores the password in the single sign-on password cache and uses it for subsequent start ups (see "Required Start-up Information").

Permissible values: As applicable

Object type: String

pinAttr
Specifies the authentication directory attribute for PINs. If you used the PIN Generator, the attribute is specified by the value of the objectclass parameter; the default value for this parameter is pin. For details, see "Arguments".

Example: pin

Permissible values: Any valid attribute name

Object type: String

dnpattern
Specifies a string representing a subject name pattern to formulate from the directory attributes and entry DN. The syntax is illustrated in the following example:

E=$attr.mail.1, CN=$attr.cn, OU=$dn.ou.2, O=$dn.o, C=US

This sample configuration specifies that the subject name should be formulated as follows:

If this parameter value is empty or not set, the server uses E=$attr.mail, CN=$attr.cn, O=$dn.o, C=$dn.c as the DN pattern.

This default DN pattern works well with Communicator and other browsers. For Communicator, if you leave out E= in end-entity certificates, S/MIME may not work correctly (assuming lack of other extensions in the certificate). Also, if C= and O= are left out, certificate display looks strange in Communicator (when the Display Certificate button is clicked).

Permissible values: Any valid DN string composed from standard DN attributes, which must be separated by commas

Object type: String

ldapAttributes
Specifies the list of LDAP attributes that should be considered authentic for the end entity. If specified, the values corresponding to these attributes will be copied from the authentication directory into the authentication token--that is, values retrieved from this parameter can be used by policy modules to form subject names or to make other policy decisions.

Entering values for this parameter is optional.

Example: mail, mailalternateaddress

This sample configuration specifies that mail and mailalternateaddress should be stored in the authentication token.

Permissible values: Any valid LDAP attributes, separated by commas

Object type: String

ldap.ldapconn.host

Specifies the host name of the authentication directory.

Example: auth_dir.netscape.com

Permissible values: The name must be in this form: <machine_name>.<your_domain>.<domain>

Object type: String

ldap.ldapconn.port
Specifies the TCP/IP port at which the authentication directory listens to requests from Certificate Management System.

Example: 636

Permissible values: Any valid port number

Object type: Integer

ldap.ldapconn.secureConn
Specifies the type--SSL or non-SSL--of the port at which the authentication directory listens to requests from Certificate Management System.

Example: true

Permissible values: Either of the following:

Object type: String

ldap.ldapconn.version
Specifies the LDAP protocol version.

If your authentication directory is based on Netscape Directory Server 1.x, choose LDAP version 2. For Directory Server versions 3.x and later, choose LDAP version 3.

Example: 2

Permissible values: Either of the following:

Object type: Integer

ldap.baseDN
Specifies the base DN for searching the authentication directory.

Example: o=airius.com

Permissible values: Any valid DN string of up to 255 characters

Object type: String

ldap.minConns
Specifies the minimum number of connections permitted to the authentication directory.

Example: 3

Permissible values: 1 to 3


Object type: Integer

ldap.maxConns
Specifies the maximum number of connections permitted to the authentication directory.

Example: 9

Permissible values: 3 to 10

Object type: Integer


End-Entity Authentication During Certificate Renewal
When an end entity submits a certificate renewal request, the first step in the renewal process is for the Certificate Manager or Registration Manager to identify and authenticate the end entity. This includes verifying the status of the end entity's current certificate; either valid or expired is acceptable for renewal, but not revoked.

 Certificate Management System verifies the authenticity of a certificate renewal request by mapping the subject name in the certificate being presented for renewal to certificates in its internal database. The server renews the certificate only if the subject name maps successfully to a certificate in its internal database.

 Here are a few things to keep in mind about certificate renewal:
End-Entity Authentication During Certificate Revocation
When an end entity submits a certificate revocation request, the first step in the revocation process is for the Certificate Manager or Registration Manager to identify and authenticate the end entity.

 When an end user attempts to revoke a certificate, Certificate Management System verifies that the user is attempting to revoke his or her own certificate, not a certificate belonging to someone else. The server also makes sure that the user can revoke only certificates that contain the same subject name as the one in the certificate presented for authentication. After successful authentication, the server lists all certificates belonging to that user. The user can then select the certificate to be revoked or revoke all certificates in the list. The user can also specify additional details, such as the date of revocation and revocation reason for each certificate or for the list as a whole.

 Here are a few things to keep in mind about certificate revocation:
 

© Copyright 1999 Netscape Communications Corp., a subsidiary of America Online, Inc. All rights reserved.