Siebel Security Guide > Security Adapter Authentication >

Requirements for the LDAP or ADSI Directory

If you implement LDAP or ADSI security adapter authentication with Siebel Business Applications, 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 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 third-party products supported by Siebel Business Applications, see Siebel System Requirements and Supported Platforms on Oracle Technology Network.

About Setting Up the LDAP or ADSI 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 or ADSI 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. Specifies the attribute type that stores a 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 use an LDAP directory, you can specify the value for the username and password in a profile parameter for the LDAP Security Adapter profile (alias LDAPSecAdpt) instead of an attribute value for the directory entry. The profile parameters are SharedDBUsername and SharedDBPassword. For more information, see Configuring the Shared Database Account.

  NOTE:  When storing database credentials in a directory attribute, both the username and password must be stored as plain text. To avoid having to store database credentials as plain text, it is recommended that you use an LDAP security adapter, and store username and password values as profile parameters.

• Username. This attribute value is the key passed to the directory that identifies the user. In a simple implementation, the username 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 and ADSI directories.
  • LDAP. Whether the password is stored in the directory depends on whether 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 the ADSI 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, 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.

  • ADSI. ADSI directories do 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 the ADSI 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, a password is not required.

      For more information about how to store the user's password, see Configuring the Shared Database Account.

You can use other user attributes to store whatever data you want, such as first and last name. Authentication options that you choose might require that you commit additional attributes.

If you create a new attribute object for your directory to store Siebel attributes (for example, Siebel User ID), 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 the directory.

NOTE:  If you are configuring an ADSI security adapter, ensure that the application user is either a domain user or has access to the directory server. If the application user cannot access the directory server, the authentication process fails.

LDAP Security Adapter Requirements

If you are using LDAP authentication, you must install the IBM LDAP Client software that is provided by Siebel Business Applications. Siebel Business Applications uses DLL files provided by the IBM LDAP Client to communicate with the supported LDAP directory server product you have chosen to use. If the IBM LDAP Client is not yet installed, then you must manually install it.

For IBM LDAP Client installation instructions, see About Installing LDAP Client Software.

ADSI Security Adapter Requirements

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

NOTE:  Siebel Business Applications do not support Microsoft Global Catalog functionality.

These requirements are:

• To allow users to set or change passwords, the ADSI 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 are located in the same domain forest.

  • Configuring Secure Sockets Layer (SSL)

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

• DNS servers on your network must be properly configured with DNS entries for the 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, you must install the ADSI client software on each such client computer, where applicable.

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

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, see 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.