Requirements for the LDAP Directory or Active Directory

If you implement LDAP or ADSI security adapter authentication with Siebel Business Applications, then you must provide a directory product that meets the requirements outlined in this topic. The directory product you provide can be one of the directory servers supported by the security adapters provided with Siebel Business Applications, or another directory server of your choice. The following options are available:

• If you provide one of the directory servers supported by Siebel Business Applications (that is, a supported LDAP directory or Microsoft Active Directory), then you can use a security adapter provided by Siebel Business Applications, or you can create your own security adapter that complies with Siebel Business Applications.

• If you provide a directory other than those supported by the security adapters provided with Siebel Business Applications, then you are responsible for implementing a security adapter that supports this directory.

For specific information about directory server products supported by Siebel Business Applications, see the Certifications tab on My Oracle Support.

LDAP Security Adapter Requirements

If you are using LDAP authentication, then you must install the Oracle LDAP Client software that is provided with Siebel Business Applications. Your Siebel application uses DLL files provided by the Oracle LDAP Client to communicate with the supported LDAP directory server product you have chosen to use. For information about installing Oracle LDAP Client, see "About Installing Oracle LDAP Client Software".

ADSI Security Adapter Requirements

If you are running the Siebel Server on supported Microsoft Windows operating systems and you are using ADSI authentication, then you must meet the requirements described in this topic. For more information about some of these requirements, refer to your Microsoft Active Directory documentation.

The ADSI security adapter requirements are:

• To allow users to set or change passwords, the Active Directory client software must be able to establish a secure connection to the Active Directory server. This requirement can be met in multiple ways:

  • Including all systems as part of a single Microsoft Windows domain forest

    It is recommended that all Siebel Servers and Active Directory servers be located in the same domain forest.

  • Configuring trust relationships

  • Configuring Transport Layer Security (TLS)

    To perform user management in the Active Directory through the Siebel client, you must configure the Active Directory server at the server level for TLS communications between the Active Directory client and server. This is different from TLS communications between the security adapter and the directory, which is configured through Siebel Business Applications.

• Specify a specific user for the Siebel service owner account and define this Siebel service user:

  • On each Siebel Server computer in the Siebel Enterprise

  • In the Siebel Server Active Directory domain

  • In the Active Directory server domain, that is, the domain the ADSI security adapter connects to in order to retrieve Siebel user credentials

• DNS servers on your network must be properly configured with DNS entries for Active Directory. Client computers using the ADSI security adapter must be configured to be able to retrieve these entries from the appropriate DNS servers.

• If you require ADSI security adapter functionality for Siebel Developer Web Client deployments, then you must install the ADSI client software on each such client computer, where applicable.

  
  

  Note: For more information about Active Directory client issues, search Microsoft's Web site for information about Active Directory Client Extensions.

  
  

About Setting Up the LDAP Directory or Active Directory

To provide user access to a Siebel application implementing an LDAP or ADSI security adapter, the Siebel application must be able to retrieve credentials to access the database and the user's Siebel user ID. Therefore you must set up a directory from which a database account and a Siebel user ID can be retrieved for each user.

Your LDAP directory or Active Directory must store, at a minimum, the following data for each user. Each piece of data is contained in an attribute of the directory:

• Siebel user ID. This attribute value must match the value in the user ID field for the user's Person record in the Siebel database. It is used to identify the user's database record for access-control purposes.

• Database account. This attribute value must be of the form username=U password=P, where U and P are credentials for a database account. You can have any amount of white space between the two key-value pairs, but you cannot have any space within each pair. The keywords, username and password, must be lowercase.

  If you choose, you can configure a designated directory entry to contain credentials of a database account that is shared by many users; this is the shared database account. If you implement a shared database account, then you can specify the value for the shared database account user name and password in profile parameters for the LDAP Security Adapter profile or the ADSI Security Adapter profile instead of in an attribute value for the directory entry. For more information, see "Configuring the Shared Database Account".

  
  

  Note: Even if you use a shared database account with external directory authentication, you must create a separate database account for any user who requires administrator access to Siebel Business Applications functionality, for example, any user who has to perform Siebel Server management and configuration tasks. The database account user ID and password you create for the user must match the user ID and password specified for the user in the external directory.

  
  

• Username. This attribute value is the key passed to the directory that identifies the user. In a simple implementation, the user name might be the Siebel user ID, and so it might not have to be a separate attribute.

• Password. The storage of a user's login password differs between LDAP servers and Active Directory servers.

  • LDAP. Whether or not the password is stored in the directory depends on whether or not you are using Web SSO:

    • If the user authenticates through the LDAP directory using the LDAP security adapter, then the login password must be stored in the userPassword attribute of the LDAP directory.

    • If the user authenticates through Active Directory using the LDAP security adapter, then the login password must be stored in either the UserPassword or the unicodePWD attribute of the LDAP directory, depending on the code page used by the directory server.

    • If the user is authenticated by an authentication service, such as in a Web SSO implementation, then a password attribute is not required.

    The Password Attribute Type parameter is used to specify the attribute type under which the user's login password is stored in the directory. For additional information on the Password Attribute Type parameter, see "Siebel Gateway Name Server Parameters".

  • Active Directory. Active Directory does not store the password as an attribute. The password can be entered at the directory level as a function of the client, or the ADSI security adapter can use ADSI methods to create or modify a password:

    • If the user authenticates through Active Directory using the ADSI security adapter, then the login password must be provided.

    • If the user is authenticated by an authentication service, such as in a Web SSO implementation, then a password is not required.

It is recommended that you implement password hashing for both user passwords and database credentials stored in the directory. You can also define access control lists (ACLs) to restrict access to directory objects containing password information. For information on setting up directory ACLs, see your directory vendor documentation. For information on password hashing, see "About Password Hashing".

You can use additional user attributes to store data, for example, first and last name, as required by your authentication solution.

If you create a new attribute object for your directory to store Siebel attributes (for example, Siebel User ID), then you can use the Private Enterprise Number that Siebel Business Applications has registered with the Internet Assigned Numbers Authority (http://www.iana.org) to provide a unique X.500 Object ID. This number is 1.3.6.1.4.1.3856.*.

An additional type of data, roles, is supported, but is not required. Roles are an alternate means of associating Siebel responsibilities with users. Responsibilities are typically associated with users in the Siebel database, but they can instead be stored in the directory. Leave role values empty to administer responsibilities from within Siebel Business Applications. For more information, see "Configuring Roles Defined in the Directory".

About Creating the Application User in the Directory

Depending on your authentication and registration strategies, and the options that you implement for your deployment, you must define a user, called the application user, in the directory.

The application user is the only user who can read or write user information in the directory. Therefore, it is critical that the application user has appropriate search and write privileges to the directory. For information on creating the application user, see "Configuring the Application User".

For ADSI authentication, it is recommended that you use the Active Directory Delegation Control Wizard to define privileges for users in Active Directory.

Note: If you are configuring an ADSI security adapter, then the application user must either be a domain user or have access to the directory server. If the application user cannot access the directory server, then the authentication process fails.

Verifying the Active Directory Client Installation

The following procedure describes how to verify that the Active Directory client is successfully installed.

To verify an Active Directory client installation 

1. Navigate to the system32 subdirectory of the installation location for the Microsoft Windows operating system (for example, C:\WINDOWS\system32).

2. Verify that the correct versions of each DLL required for the Active Directory client are present in the subdirectory (for example, the files adsiis.dll and adsiisex.dll). For more information, refer to Microsoft's documentation.

3. For each DLL, right-click on the file and choose Properties.

4. Click the Version tab to see the version number.