Employing LDAP Directory Services

This chapter provides an overview of the PeopleSoft Lightweight Directory Access Protocol (LDAP) solution and discusses how to:

• Configure the LDAP directory.

• Cache the directory schema.

• Create authentication maps.

• Create user profile maps.

• Create role membership rules.

• Delete directory configurations.

• Enable Signon PeopleCode for LDAP authentication.

• Use LDAP over SSL (LDAPS).

• View SSL/TLS for LDAP transaction setup examples.

Note. PeopleTools uses JNDI libraries only. JNDI requires no added installation as it is part of the standard PeopleTools installation.

This chapter assumes you have a working knowledge of LDAP-enabled directory servers.

Understanding the PeopleSoft LDAP Solution

Three PeopleSoft-delivered technologies enable you to:

• Authenticate against an LDAP V3 compliant directory server.

• Reuse your existing user profiles stored within LDAP.

The three technologies are:

• Directory Business Interlink, which exposes the LDAP to PeopleCode.

  The system uses it for all communication with the LDAP server process running on a directory server.

• User Profile Component Interface, which exposes the User Profiles component to PeopleCode.

  The system uses it to programmatically manage a local cache of user profiles.

• Signon PeopleCode, which runs when a user signs in to the system—similar to the login scripting of most network systems.

  Signon PeopleCode uses the Directory Business Interlink and the User Profile Component Interface to verify directory-based credentials and programmatically create a local User Profiles cache.

The combination of these three technologies provides a flexible way to configure PeopleSoft for integration with your directory server. No set schema is required in the directory. Instead, you can configure and extend the Signon PeopleCode to work with any schema implemented in your directory server.

The topics in this chapter describe setting up the LDAP integration technology on your site. The tasks assume that an LDAP V3 compliant directory service is already installed, and that you intend to import LDAP group values and apply them to PeopleSoft roles.

Note. When you enable LDAP authentication, the password column on the PSOPRDEFN record is no longer used. Directory-level users are not authenticated against the PSOPRDEFN table; they are authenticated by Signon PeopleCode. Because Signon PeopleCode only runs on the application server, LDAP authentication requires an application server. That is, LDAP authentication does not work for a two-tier signon.

Configuring the LDAP Directory

This section provides an overview of LDAP directory configuration and discusses how to:

• Specify network information for LDAP.

• Specify additional connect DNs.

• Install selected PeopleSoft-specific schema extensions.

• Test connectivity.

Understanding LDAP Directory Configuration

The Configure Directory component (PSDSSETUP) contains four pages that you use for specifying connection information and testing directory server connections.

To enable your PeopleSoft system to successfully connect to your directory server, you must enter the appropriate connection information. This information includes the server name (DNS or IP address) and the listening port number. You also must enter the user distinguished name (User DN) and associated password.

The PeopleSoft application server uses the User DN and password to connect to the LDAP server to retrieve user profile information about the specific user signing in to the system. The User DN must reflect a user with the appropriate LDAP browse rights.

Pages Used to Configure the Directory

Specifying Network Information for LDAP

Access the Directory Setup page (PeopleTools, Security, Directory, Configure Directory. Click the Directory Setup tab).

Directory ID	Displays the directory connection that you are creating. The directory ID that you enter can identify a specific LDAP server or a collection of LDAP servers, depending on how many servers you add in the Server Name section.
Description	Enter a description of the directory connection.
Directory Product	Select your directory product from the list of options.
Default Connect DN (default connect distinguished name)	Displays the default connect DN associated with the directory ID that you entered or selected on the initial search page. The connect DN is the ID that you can use to connect to the directory server. You can enter an alternative connect DN.
Password	Enter the password associated with the directory-based account that appears in the Default Connect DN field. Note. The password is stored in encrypted form in the database; not even individuals with administration access to the database can view the password.
Server Name	Add LDAP directory servers to a connection list. You can add multiple servers for failover purposes using the plus button. All servers you add must participate in the same directory service.
LDAP Server	Identify a specific LDAP server. You can use the DNS name or you can use IP address dotted notation. For example, either of the following formats is acceptable: ldap12.yourcompany.com or 192.201.185.90.
Port	Enter the port number on which the LDAP server is configured to receive search requests. The standard LDAP port is 389. If you do not specify the correct port, PeopleSoft Directory Interface cannot exchange data with your LDAP server.
SSL Port	If you are implementing SSL, enter the SSL port on the LDAP server.

Specifying Additional Connect DNs

Access the Additional Connect DN’s page (select PeopleTools, Directory, Configure Directory and click the Additional Connect DN's tab).

The PeopleSoft application server uses the User DN and password specified on this page to connect to the LDAP server to retrieve user profile information about the specific user signing in to the system. The User DN must reflect a user with the appropriate LDAP browse rights.

Note. You will not see any available schema extensions unless you have installed the PeopleSoft Directory Interface.

Installing Selected PeopleSoft-Specific Schema Extensions

Access the Schema Management page (select PeopleTools, Security, Directory, Configure Directory and click the Schema Management tab).

Note. Unless you have installed the PeopleSoft Directory Interface product, you might not have any PeopleSoft schema extensions available to you.

Note. The Schema Management page enables you to add PeopleSoft-delivered object classes and attribute types to your directory. If you add attributes and object classes using the Schema Management page, you must also delete them using this page.

Details

When you click a schema extension Details button, the system displays the details of that extension. In addition to the object identifier and name, you may also be interested in the Superiors detail, which indicates which extensions, if any, are above this one in the hierarchy. Also of interest is the Type detail, which indicates whether the schema extension is a mandatory, optional, or auxiliary extension.

Schema Cache Information

For convenience, you can use the Schema Cache Process link to transfer you to the Schema Cache page so that you can invoke the Schema Cache process. Last Update Date/Time and Last Update User ID enable you to monitor the frequency of updates as well as the last administrator to run the process.

Testing Connectivity

Access the Test Connectivity page (select PeopleTools, Security, Directory, Configure Directory and click the Test Connectivity tab).

The page displays the results (SUCCESS or FAIL) of the connectivity test. If connectivity fails, modify the connect information on the Directory Setup and Additional Connect DN’s pages.

Caching the Directory Schema

You use the Cache Schema page to specify a directory server and invoke an Application Engine program designed to create a cache in the PeopleSoft database of the directory schema. This cache enables you to select names of object classes and attribute types when you create security maps.

This section discusses how to create a cache of the directory schema.

Page Used to Cache the Directory Schema

Creating a Cache of the Directory Schema

Access the Cache Schema page (PeopleTools, Security, Directory, Cache Directory Schema).

Directory ID	Select the directory ID to identify the directory that the system should connect to and retrieve schema information from.
Server Name	Search for the Process Scheduler server on which the Cache Schema process should run.
Cache Schema Now	Click this button to cache the LDAP schema data to tables within the PeopleSoft database. Typically, you use this option during initial setup and any time that the schema has changed.
Process Monitor	After invoking the process, you can monitor the progress by clicking this link.

Creating Authentication Maps

Use the Authentication page only if you are implementing directory authentication as opposed to storing authentication information in the PeopleSoft database. You create authentication maps to define mappings to one or more directories that the PeopleSoft system relies on for authenticating users. You can activate multiple authentication maps. Your PeopleSoft LDAP system authenticates users against all active authentication maps.

Authentication maps are used to specify the following information for LDAP authentication:

• The identity of all the LDAP servers to be searched and their credentials.

• The locations where the search has to be performed inside the LDAP.

• The attribute of the entries that must be matched with the signon user ID.

This section discusses how to:

• Defining an authentication map.

• Use the Search Attribute field in authentication maps.

Page Used to Create Authentication Maps

Defining an Authentication Map

Access the Authentication page (PeopleTools, Security, Directory, Authentication Map).

Status

Activate the authentication map by selecting Active. To disable an authentication map, select Inactive.

Directory Information

User Search Information

List of Servers

Using the Search Attribute Field in Authentication Maps

The purpose of the Search Attribute prompt on the authentication maps page is to map a value that is used for the User ID on the login page. For example, if you want users to log in with their mailID, then mail attribute should be given in the prompt.

Example

Consider an entry corresponding to the user sramdass in the LDAP directory.

dn: uid=sramdass, dc=peoplesoft, dc=com
cn: sramdass
uid: sramdass123
description: peoplesoft user
mail: sramdass@oracle.com
telephone: 12345678
objectclass: person
password: PASSWORD

If the user is to log in with sramdass/PASSWORD, then the Search Attribute prompt value should be cn. If the user wants to log in with sramdass@oracle.com/PASSWORD, then the Search Attribute prompt value should be mail.

Creating User Profile Maps

This section provides an overview of user profile options and discusses how to:

• Specify mandatory user properties.

• Specify optional user properties.

• Associate user IDs and user profile maps.

Understanding User Profile Options

If you are going to authenticate users with the directory server, a PeopleSoft user profile is still required. That is, a row is still required in the table in which PeopleSoft user information is stored (PSOPRDEFN). In this context, you cache LDAP user information inside your PeopleSoft system. The properties that you specify on the Mandatory and Optional User Properties pages are the columns in PSOPRDEFN that the system populates with values from your directory server. These values comprise your user profile options.

PeopleSoft applications use this cache of user information, not your directory server. Whenever a transaction requires user information, the application refers to the local PSOPRDEFN table as opposed to querying the directory server. This improves performance.

After a user signs in to the system and the Signon PeopleCode is carried out, PeopleSoft creates a row for that user in the user definition table by retrieving the LDAP information and creating a local cache. Signon PeopleCode maintains this row automatically; manual updates are not necessary. Any changes made in the directory server are reproduced in the local cache.

Some properties are required when creating a PeopleSoft User Profile; these properties appear on the Mandatory User Properties page. Other properties are optional; these properties appear on the Optional User Properties page.

Note. You must supply user properties to Signon PeopleCode only if you intend to authenticate users with your LDAP directory.

Pages Used to Create User Profile Maps

Specifying Mandatory User Properties

Access the Mandatory User Properties page (select PeopleTools, Security, Directory, User Profile Map and click the Mandatory User Properties tab).

Authentication Map	Select the authentication map to associate with this user profile mapping. The server and connection information are taken from the authentication map.
Status	Displays the status of the selected user profile map. Note. Only one user profile map should be active at any time.
Directory ID	Displays the directory ID associated with the authentication mapping.
User ID Attribute	Specify the LDAP attribute used to populate the OPRID (user ID) field on PSOPRDEFN. Important! If you specify a different value here than the Search Attribute value that you specified on the Authentication page, then users will not be able to switch to another application from the Go menu in PeopleSoft Windows clients such as Application Designer. The second application expects to automatically authenticate a user with the value of %SignonUserId, the system variable that contains the user ID that was used to sign in. However, because the value of OPRID is different from the value of %SignonUserId, the authentication fails with an error message. Users can still access any PeopleSoft Windows client by launching it directly and signing in using the same Search Attribute value for the user ID.

ID Type

Default Role

You can enable your application to automatically apply a role for the user. When signing in to the application, the user provides a value for the search attribute you specified in the authentication map. The system uses that attribute value to search for the user's entry in the LDAP directory, and then imports the groups containing the entry to the PSOPRDEFN table as the user's role.

To enable this automatic role import feature:

1. Define LDAP groups with names that exactly match the roles defined for your application and assign the user to groups.

2. Deselect the Use Default Role check box on this page.

3. Leave the Role Name and Role Attribute fields on this page blank.

Language

Specifying Optional User Properties

Access the Optional User Properties page (PeopleTools, Security, Directory, User Profile Map, Optional User Properties).

User Profile Property	Select the user profile property that you want to add to the local cache. These properties are described in the following table.
Use Constant Value	To supply a constant value for each user, select this option.
Attribute Name	Add the name of the attribute as it is represented in your LDAP schema.
Constant Value	Appears only if you selected Use Constant Value.
Always Update	Select this option if you always want the system to update the local user cache to reflect the data stored in the directory server every time the user signs in. If Always Update is not selected, the data will be taken from the directory only when the profile is first created.

Click the User Profile Property search button to select one of the following optional user profile properties:

Associating User IDs and User Profile Maps

When a user is authenticated, a user profile must be created in the PeopleSoft database without a password. Every user profile map will be associated with an authentication map. When a user is logged in through a authentication map, the profile is updated with the values in the corresponding user profile map. All the information that populates the user profile comes from the user profile map. You can specify the role, languageCD, description, and so on in the user profile map.

The user ID of the profile that the systems creates corresponds to the User Profile Map - User ID Attribute field, which contains an LDAP attribute name.

Consider an entry corresponding to the user sramdass in LDAP:

dn: uid=sramdass, dc=peoplesoft, dc=com
cn: sramdass
uid: sramdass123
description: peoplesoft user
mail: sramdass@oracle.com
telephone: 12345678
objectclass: person
password: PASSWORD

Example 1

Authentication Map Search Attribute: cn

User Profile Map User ID Attribute:mail

You must log in as sramdass/PASSWORD, while the system creates the user profile with the name sramdass@oracle.com.

Example 2

Authentication Map Search Attribute: uid

User Profile Map User ID Attribute:telephone

You must log in as sramdass123/PASSWORD while the system creates the user profile with the name 12345678.

Note.

The Search Attribute value in the authentication map and the User ID Attribute value in the user profile map need not be the same.

Creating Role Membership Rules

Use the Role Policy page to define the rules that are read by Dynamic Role Rule PeopleCode and populate PeopleSoft roles with members. The rules return the DNs of "people" directory entries, which supply the system with the user IDs specified on the user profile mapping.

This section provides an overview of role membership rules and discusses how to define role membership rules.

Understanding Role Membership Rules

PeopleSoft security roles are comparable to LDAP directory groups. Roles enable you to group user IDs in logical sets that share the same security privileges. PeopleSoft enables you to keep your external directory groups synchronized with the data stored within the PeopleSoft database.

Important! You must keep the data within PeopleSoft consistent with any changes made to the structure or content of the external directory server, especially when you are dealing with security data. The Role Membership Rules page enables you to modify a PeopleSoft role based on directory criteria.

Page Used to Create Role Membership Rules

Defining Role Membership Rules

Access the Role Policy page (PeopleTools, Security, Directory, Role Membership Rules).

Rule Name	Displays the directory search name that you entered on the search page.
Description	Enter a short description of the rule.
User Profile Map	Select the user profile map to associate with the rule.
Directory ID	Displays the directory associated with the user profile map that you select.
Assign to Role	Click this link to automatically start the Dynamic Members page in the Roles component of the Security menu. On that page, select Directory Rule Enabled and specify the server on which to carry out the rule.

Directory Search Parameters

Build Filter

Search Attributes

Note. You can also write PeopleCode to determine group membership using any arbitrary LDAP search criteria.

Deleting Directory Configurations

You can delete the entire directory configuration or just parts of it.

This section discusses how to:

• Delete the directory configuration.

• Work with the workflow address book.

Page Used to Delete Directory Configurations

Deleting the Directory Configuration

Access the Delete Directory page (PeopleTools, Security, Directory, Delete Directory Configuration).

Delete Associated Maps	Deletes the authentication and user profile maps from the configuration.
Delete Associated Searches	Deletes any searches related to the directory configuration.
Delete Associated Role Rules	Deletes any role rules that you have specified for a configuration.
Delete Associated Entry Rules	Applies to the PeopleSoft Directory Interface product only.
Delete Directory Configuration	After you have made the appropriate choices, click this button to perform the delete process. If you click this button with nothing selected, the system deletes only the directory ID and leaves all of the other configuration information intact.

Working with the Workflow Address Book

Access the Address Book page (PeopleTools, Security, Directory, Workflow Address Book).

Use the Address Book page for configuring LDAP address lookups for use with user-initiated notifications in PeopleSoft Workflow. This page contains the controls needed to retrieve the necessary addresses from the directory. This page applies only if you store user information in a directory.

Connect & Search Info

Attribute Info

See Also

Adding Events and Routings

Enabling Signon PeopleCode for LDAP Authentication

Access the Signon PeopleCode page (PeopleTools, Security, Security Objects, Signon PeopleCode).

LDAP Authentication runs as Signon PeopleCode that must be enabled and configured to be carried out with proper permissions.

To enable Signon PeopleCode:

1. Click the Invoke As option that applies to your configuration.

   Do you want to use a default user ID, or do you want the Signon PeopleCode to be invoked by the user ID of the user who happens to be signing on to the system? Either way, the value for the user ID and password must be a valid PeopleSoft User ID and password. For LDAP authentication, you need to use Invoke As, because the user signing in (most likely) does not exist in the local system until Signon PeopleCode runs and updates the local cache of user profiles.

   Note. The user ID entered, whether it is Invoke As user signing in or a default user, must be able to access the User Profiles component in a permission list.

2. Locate the row for the LDAP_Authentication function on the Record FUNCLIB_LDAP.

3. Select the Enabled check box (if it is not already selected by default).

4. Ensure that the Exec Auth Fail check box is selected; if PeopleSoft authorization fails, then Signon PeopleCode is carried out.

   PeopleSoft authorization always fails if you are using LDAP authentication.

5. Click Save at the bottom of the page.

6. Reboot any application servers running against the local database.

Note. If you intend to use the User Profile Map, you also need to enable LDAP_PROFILESYNCH. The same options apply.

Using LDAP Over SSL (LDAPS)

This section provides an overview of SSL and discusses SSL between PeopleSoft and LDAP.

Understanding SSL

SSL is a protocol developed by Netscape that defines an interface for data encryption between network nodes. To establish an SSL-encrypted connection, the nodes must complete the SSL handshake. These are the simplified steps of the SSL handshake:

1. Client sends a request to connect.

2. Server responds to the connect request and sends a signed certificate.

3. Client verifies that the certificate signer is in its acceptable certificate authority (CA) list.

4. Client generates a session key to be used for encryption and sends it to the server encrypted with the server’s public key (from the certificate received in Step 2).

5. Server uses its private key to decrypt the client generated session key.

Establishing an SSL connection requires two certificates: one containing the public key of the server (server certificate or public key certificate) and another to verify the CA that issued the server certificate (trusted root certificate). The server needs to be configured to issue the server certificate when a client requests an SSL connection, and the client needs to be configured with the trusted root certificate of the CA that issued the server certificate.

The nature of those configurations depends on both the protocol being used and the client and server platforms. In most cases, you replace HTTP with LDAP. SSL is a lower level protocol than the application protocol, such as HTTP or LDAP. SSL works the same regardless of the application protocol. To connect to a directory server over LDAPS from a PeopleSoft application, SSL has to be configured in the directory server and PeopleSoft application.

Note. Establishing LDAPS is not related to web server certificates or certificates used with PeopleSoft integration.

SSL Between PeopleSoft and LDAP

You can use LDAP Business Interlink to establish a secure LDAP connection between the application server and the LDAP server. To establish the secure connection between the PeopleSoft application server and the LDAP server you will need the following certificates:

• A server certificate for the LDAP server.

• The trusted root certificate from the CA that issues the server certificate.

Installing and Removing Root CA Certificates in PeopleSoft Databases

To install Root CA Certificates into PeopleSoft databases:

1. Select PeopleTools, Security, Digital Certificates.

   The list of installed certificates appears.

2. Click the insert row button (+) in the last row of the displayed certificates.

   A blank row appears.

3. Select Root CA from the Type drop-down list box.

4. Enter a meaningful name as the alias of this certificate in the Alias field.

5. Click the Issuer Alias field prompt button.

   The name of the Alias automatically populates the Issuer Alias field.

6. Click the Add Root link.

   The Add Root Certificate page appears. Minimize the browser window.

7. Open the root CA certificate with a text editor and copy the contents.

8. Maximize the browser and paste the contents into the text box.

9. Click the OK button to see the new digital certificate.

10. Reboot the application server.

To remove Root CA Certificates from PeopleSoft databases:

1. Select PeopleTools, Security, Digital Certificates.

   The list of installed certificates appears.

2. Click the delete row (–) button in the row of the certificate you want to remove.

   A Delete Confirmation message box appears.

3. Click the OK button to confirm the deletion.

4. Reboot the application server.

Enabling LDAP Authentication Over SSL in PeopleSoft Applications

To enable LDAP authentication over SSL in PeopleSoft applications:

1. Follow the documentation for your directory server to add the Server Certificate to your directory server.

2. Install the Root CA certificate into the PeopleSoft database.

3. Select PeopleTools, Security, Directory, Configure Directory, Directory Setup to access the Directory Setup page.

   The SSL Port field must reflect the correct LDAPS port for the directory server.

4. Click the Test Connectivity tab.

   You must see SUCCESS for the SSL transactions to work. If you see FAILURE here, the LDAP authentication will not succeed over SSL.

5. Select PeopleTools, Security, Directory, Authentication Map to access the Authentication Map page, and select the Use Secure Sockets Layer check box.

6. Enable the LDAP_AUTHENTICATION Signon PeopleCode.

   See Enabling Signon PeopleCode.

7. Reboot the application server.

Viewing SSL for LDAP Transactions Setup Examples

For the LDAP transactions between PeopleSoft and a directory server, SSL must be configured in both PeopleSoft and the directory server. This section provides a sample SSL configuration between directory servers such as Oracle Internet Directory, Active Directory Server, Sunone, and PeopleSoft applications.

Important! The procedures outlined in this section are provided as examples. They may not necessarily apply to all situations. Verify the appropriate documentation for further details.

Setting Up SSL for Oracle Internet Directory (OID)

To set up SSL for OID:

1. Create certificate request in the wallet.

2. Create a new configuration set for SSL in Oracle Directory Manager.

3. Configure OID with the newly created configuration set.

Creating the Certificate Request in the Wallet

To create the certificate request:

1. Open Oracle Wallet Manager and select Operations, Add Certificate Request.

2. Fill in the fields and click the OK button.

3. Select Wallet, Save. (By default, it is stored in C:\Wallets.)

Creating a New Configuration Set for SSL in Oracle Directory Manager

To create a new configuration set for SSL in Oracle Directory Manager:

1. Open the Oracle Directory Manager and log in as an admin.

2. From the Server management section on the left pane, select the Default Configuration Set.

   The Default Configuration Set properties appear in the right pane.

3. From the tool bar, click the Create Like icon.

   A new configuration set will be created.

4. In this new configuration set, change these properties:

   Number of Child Processes = 4

   Non SSL Port = <Any number other than 389>. For example, 399.

5. Click the SSL Settings tab and enter the following values:

   SSL Authentication = SSL Server Authentication.

   SSL Enable = Both SSL and Non SSL.

   SSL Wallet = <path of the Wallet>. For example, file:C:\wallets.

   SSL Port = <any number other than 636>. For example, 646.

Note. The port numbers for both SSL and non-SSL can be changed to any values other than the default configuration set port values.

Configuring OID with the Newly Created Configuration Set

To configure OID with the newly created configuration set:

1. Restart the oidldapd server by navigating to <Oracle_Home>\ldap\admin and running the following commands in the command prompt:

   oidctl connect=<database SID> server=<OID server type value> instance=<instance⇒
    number value> stop

   Example: oidctl connect=orcl server=oidldapd instance=1 stop

2. Start the OID with the new configuration set (configset=1). The default configuration set is demoted (configset=0).

   oidctl connect=<database SID> server=<OID server type value> instance=<instance⇒
    number value> configset=<new configset value> start
   

   Example: oidctl connect=orcl server=oidldapd instance=1 configset=1 start

3. Close the Oracle Directory Manager and log in through SSL.

   Enter the wallet path and the wallet password in the login dialog.

   Note. If the SSL is incorrectly configured, you will not be able to log in.
   
   The wallet path should be given as file:C:\wallets. The path of the wallet is sufficient; the wallet name is unnecessary.

Setting up SSL for Active Directory Server

Any utility or application that creates a valid PKCS #10 request can be used to form the SSL certificate request. The following example uses certreq.exe to form the request.

To set up SSL for Active Directory Server (ADS):

1. Find the Fully Qualified Domain Name (FQDN).

2. Request a server authentication certificate.

3. Verify an LDAPS connection.

To create certificate request, the Fully Qualified Domain Name (FQDN) of the Domain Controller (DC) is needed.

Finding the FQDN

To find the FQDN:

1. Select Start, Programs, Administrative Tools, DNS.

   The dnsmgmt window opens.

2. Double-click the host name of your machine, and you will see the FQDN.

Requesting a Server Authentication Certificate

To request a server authentication certificate:

1. Copy and paste the following text into a new text file and save it as request.inf:

   ; ----------------- request.inf ----------------- 
   
   [Version] 
   
   Signature="$Windows NT$"
   
   [NewRequest]
   
   Subject = "CN = LAB-SUMAHADE-WF.adserver.coretools”
   ; replace with the FQDN of the DC 
   KeySpec = 1 
   KeyLength = 1024 
   ; Can be 1024, 2048, 4096, 8192, or 16384. 
   ; Larger key sizes are more secure, but have 
   ; a greater impact on performance. 
   Exportable = TRUE 
   MachineKeySet = TRUE 
   SMIME = False 
   PrivateKeyArchive = FALSE 
   UserProtected = FALSE 
   UseExistingKeySet = FALSE 
   ProviderName = "Microsoft RSA SChannel Cryptographic Provider" 
   ProviderType = 12
   RequestType = PKCS10 
   KeyUsage = 0xa0 
   	
   [EnhancedKeyUsageExtension] 
   
   OID=1.3.6.1.5.5.7.3.1 ; this is for Server Authentication 
   
   ;-----------------------------------------------
   
   

2. Provide the fully qualified DNS name of the domain controller in the request. The semicolon (;) is used to indicate that the following text through the end of the line is a comment.

3. Create the request file and then, in a command prompt, navigate to the path where the request is and type the following command:

   certreq -new <Name of the inf file> <name of the request file>

   Example: certreq -new request.inf request.req

   A new request.req is created in the current directory. This is the base64-encoded request file.

4. Submit the request to a CA for a server certificate. Save the server certificate, servercert.cer, on your machine. The saved certificate must be base64–encoded.

5. Accept the issued certificate by opening a command prompt, navigating to the path where the server certificate is stored, and executing the following command:

   certreq -accept <Name of the server certificate>

   Example: certreq -accept servercert.cer

6. Now the certificate is installed in your personal store. A private key is associated with this certificate. Verify this key by referring to the ADS documentation.

7. Restart the domain controller by restarting the server.

Verifying an LDAPS Connection

To verify an LDAPS connection:

1. Start the Active Directory Administration Tool (ldp.exe) by selecting Start, Run, ldp.exe.

2. On the Connection menu, click Connect.

3. When prompted, enter the name of the domain controller (enter the FQDN) to which you want to connect and the SSL port number.

4. Click OK.

   The RootDSE information should appear in the right pane, indicating a successful connection.

Setting up SSL for Sunone Directory Server (iPlanet)

1. Open the Sunone Directory Server console and select Manage Certificates from the Tasks tab.

2. Select Request and then Next.

3. Enter your computer name (or server name) and other organizational details.

4. Enter a password and click Next.

   The system creates a certificate request.

5. Click the Copy to Clipboard button to copy this request to the clipboard, or save the request to a file.

6. Submit the Certificate Request to a trusted CA and download the server certificate, for example, servercert.cer.

7. In the directory server, open the Manage Certificates page.

8. On the Server Certs tab, click the Install button.

9. Select this local file. Click the Browse button and select the server certificate, servercert.cer. Click Next on each of the following two pages.

10. Enter a name and a password and then click Done.

Setting Up SSL in PeopleSoft Applications

This section discusses how to configure the LDAP business interlink to establish SSL encrypted LDAP connections. The LDAP business interlink uses a root CA certificate that you install in the PeopleSoft database through the Digital Certificates page.

To enable SSL, the SSL parameter in the LDAP business interlink should be set to YES either:

• Manually in Application Designer.

• Programmatically through PeopleCode.

Setting the Business Interlink SSL Parameter in Application Designer

To set the SSL parameter in Application Designer:

1. Open an existing instance of the LDAP business interlink, or create a new instance.

2. Select the Settings tab.

3. Set the SSL parameter to YES.

4. Save the business interlink.

This example shows the correct setting of the SSL parameter for the LDAP_ADD business interlink:

Note. This example shows the LDAP_ADD business interlink transaction, but it applies to all LDAP business interlink transactions.

Setting the Business Interlink SSL Parameter Programmatically

To set the business interlink SSL parameter programmatically:

1. Drag the business interlink definition into the PeopleCode editor. The following code is created:

   /* ===>
   This is a dynamically generated PeopleCode template to be used only as a helper
   to the application developer.
   You need to replace all references to ’<*>’ OR default values with references to
   PeopleCode variables and/or a Rec.Fields.*/
   /* ===> Declare and instantiate: */
   Local Interlink &LDAP_SEARCH_1;
   Local BIDocs &inDoc;
   Local BIDocs &outDoc;
   Local boolean &RSLT;
   Local number &EXECRSLT;
   &LDAP_SEARCH_1 = GetInterlink(INTERLINK.LDAP_SEARCH);
   
   
   /* ===> You can use the following assignments to set the configuration parameters.
   */
   &LDAP_SEARCH_1.SSL = "NO";
   &LDAP_SEARCH_1.SSL_DB = "cert7.db";
   &LDAP_SEARCH_1.URL = file://psio_dir.dll";
   &LDAP_SEARCH_1.BIDocValidating = "Off";
   ...
   

   Note. This example uses the search transaction, but the principle applies to any transaction.

2. Change the SSL parameter setting to indicate that SSL should be used. For example: &LDAP_SEARCH_1.SSL = "YES";

Note these points:

• The SSL parameter setting in PeopleCode takes priority over the setting in Application Designer. For example, setting YES in Application Designer and NO in PeopleCode will result in a non-SSL transaction.

• The application server binds as a client to the LDAP server as part of the authentication, so it is only necessary to have access to the root certificates. The LDAP administrator at your site should have already installed a server (Node) certificate on the LDAP Server.

• Whenever you enable or disable Signon PeopleCode, reboot the application server domain.

• Whenever you install or uninstall a certificate, reboot the application server.