Siebel Security Guide > Security Adapter Authentication > Requirements for the LDAP Directory or Active Directory >

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.