| Siebel CRM Siebel Security Guide Siebel Innovation Pack 2015 E24814-01 |
|
 Previous |
 Next |
View PDF |
| Siebel CRM Siebel Security Guide Siebel Innovation Pack 2015 E24814-01 |
|
Previous |
Next |
View PDF |
This topic describes the tasks involved in implementing LDAP or ADSI security adapter authentication. Implement your authentication architecture in a development environment before deploying it in a production environment.
The process outlined in this topic provides instructions for implementing and testing security adapter authentication for a single Siebel application using either an LDAP or ADSI security adapter with one of the supported directory servers. The security adapter authenticates a user's credentials against the directory and retrieves login credentials from the directory. A user is authenticated by the user's Siebel user ID and a password.
You can repeat the appropriate tasks listed in this topic to provide security adapter authentication for additional Siebel Business Applications. You can also implement components and options that are not included in this process. For additional information about security adapter authentication options, see "Security Adapter Deployment Options". For information about special considerations in implementing user authentication, see "Troubleshooting User Authentication Issues".
|
Note: If you use a security adapter that is not provided by Siebel Business Applications, then it must support the Siebel Security Adapter Software Developers Kit, which is described in "Security Adapter SDK". You must adapt the applicable parts of the following task instructions to your security adapter. |
You must perform the following tasks to set up and test a typical LDAP or ADSI security adapter authentication architecture:
Verify that all requirements are met. For information on the requirements, see "Requirements for Implementing an LDAP or ADSI Authentication Environment".
Review "About Creating a Database Login for Externally Authenticated Users".
Set up the attributes for users in the directory. See "Setting Up the LDAP Directory or Active Directory".
Create users in the directory: a regular user, the anonymous user, and the application user. See "Creating Users in the LDAP Directory or Active Directory".
Add user records in the Siebel database corresponding to the users in the directory. See "Adding User Records in the Siebel Database".
Edit security adapter parameters in the eapps.cfg file. See "Setting Security Adapter Parameters in the SWSE Configuration File (eapps.cfg)".
Select the security adapter you want to use (LDAP, ADSI, Custom), and configure parameters for the selected security adapter, using one of the following methods:
Using the Siebel Configuration Wizard
Configure values for the security adapter parameters by running the Siebel Configuration Wizard. Then select the security adapter you want to use (LDAP, ADSI, Custom) by specifying the appropriate values for the SecAdptName and SecAdptMode Siebel Gateway Name Server parameters using either Siebel Server Manager or by running the Siebel Configuration Wizard again. For information on running the Siebel Configuration Wizard, see "Configuring LDAP or ADSI Security Adapters Using the Siebel Configuration Wizard".
Editing Siebel Gateway Name Server parameters directly
You can select the security adapter you want to use, and configure Gateway Name Server parameters for the security adapter, by editing Siebel Gateway Name Server parameters directly using Siebel Server Manager. For further information, see "Configuring Security Adapter Gateway Name Server Parameters".
(Developer Web Clients only) Editing the application configuration file
For Developer Web Clients only, you configure parameters for the security adapter in the application configuration file. For additional information, see "Configuring Security Adapter Parameters for Developer Web Clients".
(Developer Web Clients only) "Setting a System Preference for Developer Web Clients".
This topic describes the requirements for implementing an LDAP or ADSI authentication environment. The Siebel default authentication method is database authentication; if you want to implement LDAP or ADSI authentication instead, verify that the requirements outlined in this topic are in place.
This task is a step in "Process of Implementing LDAP or ADSI Security Adapter Authentication".
You must complete the following tasks before you can configure an LDAP or ADSI security adapter for your environment:
Install the LDAP directory or Active Directory.
Install the Siebel Enterprise Server components (Gateway Name Server, Siebel Server, and Database Configuration Utilities).
For information on this task, see Siebel Installation Guide for the operating system you are using.
Review "Requirements for the LDAP Directory or Active Directory".
To implement LDAP or ADSI authentication, you must be experienced with administering the directory. That is, you must be able to perform tasks such as creating and modifying user storage subdirectories, creating attributes, creating users, and providing privileges to users.
(LDAP only) Install the LDAP or ADSI client software. For information on this task, see "Process of Installing and Configuring Oracle LDAP Client Software Without Using Siebel Enterprise Server Installer".
Have available a URL or hyperlink with which users can access the login form for the Siebel application you are configuring.
A database login must exist for all users who log in to Siebel Business Applications through an external authentication system. If you are implementing LDAP or ADSI security adapter authentication, then verify that this login name is present; if it does not exist, then create it. This database login must not be assigned to any individual user.
This task is a step in "Process of Implementing LDAP or ADSI Security Adapter Authentication".
A database login is created for externally authenticated users during the Siebel installation process. If you are using an Oracle or Microsoft SQL Server database, then the account is created when you run the grantusr.sql script. If you are using a DB2 database, then the database administrator manually creates this account. For additional information, see Siebel Installation Guide for the operating system you are using.
The default user ID of the database login account for externally authenticated users is LDAPUSER. A password is assigned to this database account when the account is created. A Siebel application user account corresponding to the LDAPUSER database account is not provided in the seed data and is not required.
When you implement LDAP or ADSI authentication, users are authenticated through a directory. This topic describes how to set up the directory to do the following:
Authenticate users through the directory.
Allow self-registration.
Use the Siebel user ID as the user name.
This task is a step in "Process of Implementing LDAP or ADSI Security Adapter Authentication".
The following procedure describes how to set up the LDAP directory or Active Directory. For more information about setting up the directory, review "About Setting Up the LDAP Directory or Active Directory".
To set up the LDAP directory or Active Directory
Determine the Base Distinguished Name, that is, the location in the directory in which to store users. For details, see the BaseDN parameter description in "Siebel Gateway Name Server Parameters".
You cannot distribute the users of a single Siebel application in more than one base DN. However, you can store multiple Siebel Business Applications' users in one base DN or in substructures such as organization units (OU), which are used for LDAP. For example, store users in the People base DN under the domain level for LDAP directories, or in the Users base DN under the domain level for ADSI directories.
Define the attributes to use for the following user data. Create new attributes if you do not want to use existing attributes. Suggested attributes to use are as follows:
Siebel user ID. Suggested attribute: uid for LDAP, or sAMAccountName for ADSI.
Database account. Suggested attribute: dbaccount.
Password. Suggested attribute (for LDAP only): userPassword. However, if you use the LDAP security adapter to authenticate against Microsoft Active Directory, then use either the unicodePWD or userPassword attribute, depending on the code page used by the directory server. ADSI directories do not use an attribute to store a user's password.
Optionally, use other attributes to represent first name, last name, or other user data.
This topic describes the users you must create in the LDAP directory or Active Directory to implement LDAP or ADSI security adapter authentication.
This task is a step in "Process of Implementing LDAP or ADSI Security Adapter Authentication".
When you use LDAP or ADSI authentication, you must create the following users in the directory:
Application user
Make sure the application user has write privileges to the directory because the security adapter uses application user credentials when using the self-registration component. The application user must also have search privileges for all user records. For additional information, see "Configuring the Application User".
Anonymous user
You must define an anonymous user even if your application does not allow access by unregistered users. For more information, see "Configuring the Anonymous User".
Records for each user of the Siebel application
Initially, create a test user to verify the authentication system.
(Optional) A shared credentials user account
You can also store credentials for the shared database account as profile parameters for the LDAP or ADSI security adapter profiles. For more information, see "Configuring the Shared Database Account".
Create users in the directory using values similar to those shown in Table 5-3. Store information for users in the directory attributes indicated in "Setting Up the LDAP Directory or Active Directory". Optionally, complete other attribute entries for each user.
Table 5-3 Records in the LDAP Directory or Active Directory
| Type of User | Siebel User ID | Password | Database Account |
|---|---|---|---|
|
Enter the user ID of the anonymous user record for the Siebel application you are implementing.
|
A database account is not required for the anonymous user if a shared database credentials account is implemented; the database credentials for the anonymous user are read from the shared database account user record or the relevant profile parameter of the LDAP or ADSI security adapter. |
||
|
A database account is not used for the application user. |
|||
|
Database account is not required for any user record, except the anonymous user or the shared credentials user account. |
|||
|
Shared database credentials account user |
The user name and password you specify for the shared database account must be a valid Siebel user name and password. |
|
For information about formatting requirements for the database account attribute entry, see "About Setting Up the LDAP Directory or Active Directory". |
The example directory entries in Table 5-3 implement a shared credential. The database account for all users is stored in one object in the directory. In this example, the shared database account is stored in the SharedDBUser record. The database account must match the database account you reserve for externally authenticated users which is described in "About Creating a Database Login for Externally Authenticated Users". The P symbol represents the password for that database account. For additional information, see "Configuring the Shared Database Account".
This topic describes how to create a record in the Siebel database that corresponds to the test user record you created in "Creating Users in the LDAP Directory or Active Directory".
This task is a step in "Process of Implementing LDAP or ADSI Security Adapter Authentication".
You must confirm that the seed data record exists for the anonymous user for your Siebel customer or partner application, as described in Appendix B, "Seed Data." This record must also match the anonymous user you created in "Creating Users in the LDAP Directory or Active Directory".
You can adapt a seed data anonymous user or create a new anonymous user for a Siebel employee application. To adapt a seed anonymous user for a Siebel employee application, add any views to the anonymous user's responsibility that would be required for the employee application, such as a home page view in which a login form is embedded.
For purposes of confirming connectivity to the database, you can use the following procedure to add the test user for any Siebel application. However, if you are configuring a Siebel employee or partner application, and you want the user to be an employee or partner user, complete with position, division, and organization, then see the instructions for adding such users in "Internal Administration of Users".
The following procedure describes how to add user records to the Siebel database.
To add user records to the database
Log in as an administrator to a Siebel employee application, such as Siebel Call Center.
Navigate to the Administration - User screen, then the Users view.
In the Users list, create a new record.
Complete the following fields for the test user using values similar to those shown in the following table, then save the record. You can complete other fields, but they are not required.
| Field | Guideline |
|---|---|
| Last Name | Required. Enter any name. |
| First Name | Required. Enter any name. |
| User ID
Example: TESTUSER |
Required. This entry must match the uid (LDAP) or sAMAccountName (ADSI) attribute value for the test user in the directory. If you used another attribute, then it must match that value. |
| Responsibility | Required. Enter the seed data responsibility provided for registered users of the Siebel application that you implement. For example, enter Web Registered User for eService. If an appropriate seed responsibility does not exist, such as for a Siebel employee application, then assign an appropriate responsibility that you create. |
| New Responsibility | Optional. Enter the seed data responsibility provided for registered users of the Siebel application that you implement. For example, enter Web Registered User for eService. This responsibility is automatically assigned to new users created by this test user. |
Verify that the seed data user record exists for anonymous users of the Siebel application you implement. If the record is not present, then create it using the field values in "Seed Users". You can complete other fields, but they are not required.
This topic describes the parameter values you must enter in the SWSE configuration file (eapps.cfg) when you implement LDAP or ADSI security adapter authentication. For information about editing eapps.cfg parameters and about the purposes of the parameters, see "About Parameters in the eapps.cfg File".
This task is a step in "Process of Implementing LDAP or ADSI Security Adapter Authentication".
Enter values for eapps.cfg file parameters using values similar to those shown in Table 5-4, "Parameter Values in eapps.cfg File". Specify values for AnonUserName and AnonPassword in the defaults section of the eapps.cfg file if you are configuring LDAP or ADSI authentication for all your Siebel Business Applications. If you are implementing LDAP or ADSI authentication for a single application, as in this example, then specify these parameters in the application-specific section of the eapps.cfg file.
Table 5-4 Parameter Values in eapps.cfg File
| Section | Parameter | Guideline |
|---|---|---|
|
[defaults] |
SingleSignOn |
If these parameters are present, then comment out each with a semicolon at the beginning of the line. Do the same if these parameters are present in any other sections. |
|
The section that is specific to your application, such as one of the following: [/eservice_enu] [/callcenter_enu] where _enu is the language code for U.S. English. |
Enter the user ID of the seed data user record provided for the application that you implement, or of the user record you create for the anonymous user. This entry also matches the uid (LDAP) or sAMAccountName (ADSI) entry for the anonymous user record in the directory. For example, enter |
|
|
Enter the password you created in the directory for the anonymous user. Whether or not you have to encrypt the password depends on the value specified for the EncryptedPassword parameter. For information on this parameter, see "Encrypted Passwords in the eapps.cfg File". Typically, password encryption applies to the eapps.cfg file. In this case, you must specify the encrypted password, unless you provide the password through the Siebel Configuration Wizard. |
||
|
If this parameter is present, then comment it out with a semicolon at the beginning of the line. |
This topic describes the security-related configuration parameters you use for configuring an LDAP or ADSI security adapter that are defined in the Siebel Gateway Name Server. You can modify Gateway Name Server configuration parameters using Siebel Server Manager, or you can do so using the Siebel Configuration Wizard.
For information on editing Gateway Name Server parameters using the Siebel Configuration Wizard, see "Configuring LDAP or ADSI Security Adapters Using the Siebel Configuration Wizard". For information on using Siebel Server Manager to edit Gateway Name Server parameters, see Siebel System Administration Guide.
This task is a step in "Process of Implementing LDAP or ADSI Security Adapter Authentication".
You can set Gateway Name Server security adapter parameters for the following:
Set security adapter parameters as described in each of these topics. For more information about these parameters, see "Siebel Gateway Name Server Parameters".
This topic lists security adapter parameters you can set at the Gateway Name Server level, at the Enterprise level, at the Siebel Server level, or at the component level. Applicable components for which you can set these parameters include all Application Object Manager components and the Synchronization Manager component (for Siebel Remote).
To implement LDAP or ADSI authentication for a single Siebel application, set the parameters for the applicable Application Object Manager component, such as for Siebel Call Center or Siebel eService, using values similar to those in Table 5-5.
Table 5-5 Siebel Gateway Name Server Parameters (for Enterprise, Server, or Component)
| Subsystem | Parameter | Guideline |
|---|---|---|
|
Security Manager |
Security Adapter Mode (SecAdptMode) |
The security adapter mode to operate in:
|
|
Security Adapter Name (SecAdptName) |
The name of the security adapter.
The name represents the alias for the enterprise profile (named subsystem) for the specified security adapter. |
This topic lists parameters you set for the Application Object Manager component when implementing LDAP or ADSI authentication for a single Siebel application.
To implement LDAP or ADSI authentication for a single Siebel application, set the parameters for the applicable Application Object Manager component, such as for Siebel Call Center or Siebel eService, using values similar to those shown in Table 5-6.
Table 5-6 Siebel Gateway Name Server Parameters (for Application Object Manager)
| Subsystem | Parameter | Guideline |
|---|---|---|
|
InfraUIFramework |
Enter Set this parameter to FALSE if your Siebel application does not use functionality that requires anonymous browsing, such as anonymous catalog browsing or user self-registration. |
|
|
Object Manager |
OM - Proxy Employee (ProxyName) |
Enter |
|
OM - Username BC Field (UsernameBCField) |
You can leave this parameter empty. |
This topic lists parameters you set for the enterprise profile (named subsystem) for the specific security adapter you are configuring.
To implement LDAP or ADSI authentication for a single Siebel application, configure parameters for one of the following (defined as enterprise profile or named subsystem):
LDAP Security Adapter. Typically, the alias for this adapter is LDAPSecAdpt.
ADSI Security Adapter. Typically, the alias for this adapter is ADSISecAdpt.
Set the security adapter parameters using values similar to those shown in Table 5-7, "Siebel Gateway Name Server Parameters (for Enterprise Profile/Named Subsystem)".
Table 5-7 Siebel Gateway Name Server Parameters (for Enterprise Profile/Named Subsystem)
| Parameter | Guideline |
|---|---|
Do not include the file extension (for example, do not specify sscforacleldap |
|
|
Enter the name of the computer on which the LDAP directory or Active Directory server runs. Do not specify the IP address of the Active Directory server for the Server Name parameter. |
|
|
|
|
The Base Distinguished Name is the root of the tree under which users are stored. Users can be added directly or indirectly below this directory. You cannot distribute the users of a single Siebel application in more than one base DN. However, you can distribute them in multiple subdirectories, such as organization units (OU), which are used for LDAP. LDAP example entry:
ou=people, o=domainname
In the example, " ADSI example entry:
ou=people, DC=domainname, DC=com
Domain Controller (DC) entries are the nested domains that locate this server. Therefore, adjust the number of DC entries to represent your architecture. |
|
|
LDAP example entry is ADSI example entry is If you use a different attribute in the directory for the Siebel user ID, then enter that attribute name. |
|
|
The LDAP entry must be userPassword. However, if you use the LDAP security adapter to authenticate against Microsoft Active Directory, then set the value of this parameter to unicodePWD. Active Directory does not store the password in an attribute so this parameter is not used by the ADSI security adapter. You must, however, specify a value for the Password Attribute Type parameter even if you are using the ADSI security adapter. Specify a value of unicodePWD. |
|
|
If you are using an LDAP security adapter, an example entry is If you are using an ADSI security adapter, an example entry is If you used a different attribute in the directory for the database account, then enter that attribute name. |
|
|
LDAP example entry:
uid=APPUSER, ou=people, o=domainname
ADSI example entry: CN=APPUSER, ou=people, DC=computername, DC=domainname, DC=com Adjust your entry if your implementation uses a different attribute for the user name, a different user name for the application user, or a different base DN. |
|
|
For LDAP and ADSI, enter |
|
|
LDAP example entry:
uid=shared database account user User ID, ou=people, o=domainname
For example: uid=SharedDBUser, ou=people, o=example.com ADSI example entry: CN=shared database account user User ID, ou=people, DC=computername, DC=domainname, DC=com For example: CN=SharedDBUser, ou=people, DC=qa1, DC=example, DC=com |
This topic describes the tasks you must perform if you want to implement LDAP or ADSI security adapter authentication for Developer Web Clients.
This task is a step in "Process of Implementing LDAP or ADSI Security Adapter Authentication".
To configure LDAP or ADSI authentication for Developer Web Clients, perform the following tasks:
For Developer Web Clients, security adapter parameters are configured in the configuration file of the application for which you are implementing LDAP or ADSI security adapter authentication rather than in the Gateway Name Server.
Parameters in sections of the application configuration file that directly pertain to security adapters apply, in this context, only to the Siebel Developer Web Client. These parameters are counterparts to the Siebel Gateway Name Server parameters listed in Table 5-5, Table 5-6, and Table 5-7.
To configure a security adapter for the Developer Web Client, provide parameter values, as indicated by the guidelines in Table 5-8, in the configuration file for the Siebel application for which you are implementing LDAP or ADSI security adapter authentication.
You can use a text editor to make changes to an application configuration file, or you can do so using the Siebel Configuration Wizard. For more information about editing an application's configuration file and about the purposes for the parameters, see "Siebel Application Configuration File Parameters". For a list of Siebel application configuration files, see Siebel System Administration Guide.
Table 5-8 Siebel Application Configuration File Parameters
| Section | Parameter |
|---|---|
|
[InfraUIFramework] |
For the AllowAnonUsers parameter, enter Note: Set this parameter to |
|
[InfraSecMgr] |
SecAdptMode For the SecAdptMode parameter:
|
|
SecAdptName For the SecAdptName parameter:
|
|
|
[LDAPSecAdpt] |
For parameters, see "Configuring Security Adapter Gateway Name Server Parameters" or Appendix A, "Configuration Parameters Related to Authentication." |
|
[ADSISecAdpt] |
For parameters, see "Configuring Security Adapter Gateway Name Server Parameters" or Appendix A, "Configuration Parameters Related to Authentication." |
If you are configuring LDAP or ADSI authentication for the Siebel Developer Web Client, then you must set the SecThickClientExtAuthent.system preference to True, as described in this topic.
Setting the SecThickClientExtAuthent. parameter to True allows security adapter authentication for users who log in through the Siebel Developer Web Client. System preferences are enterprise-wide settings, however, the SecThickClientExtAuthent. system preference has no effect on security adapter authentication for users who log in through the Siebel Web Client.
Use the following procedure to specify a value for the SecThickClientExtAuthent. parameter.
To set the SecThickClientExtAuthent parameter
Log in as an administrator to a Siebel employee application.
Navigate to the Administration - Application screen, then the System Preferences view.
In the System Preferences list, select the SecThickClientExtAuthent system preference.
In the System Preference Value column, enter TRUE.
Restart the Siebel Server.
This topic describes the Windows services on the Web server computer that you must restart to activate the changes you make during the process of configuring LDAP or ADSI security adapter authentication.
This task is a step in "Process of Implementing LDAP or ADSI Security Adapter Authentication".
Stop and restart the following services:
IIS Admin service and Worldwide Web Publishing service. Stop the IIS Admin service, and then restart the Worldwide Web Publishing service. The IIS Admin service also starts, because the Worldwide Web Publishing service is a subservice of the IIS Admin service.
Siebel Server system service. Stop and restart the Siebel Server. For details, see Siebel System Administration Guide.
Siebel Gateway Name Server system service. Stop and restart the Siebel Gateway Name Server. For details, see Siebel System Administration Guide.
After performing all the tasks required to implement LDAP or ADSI security adapter authentication, you can verify your implementation using the procedure in this topic.
This task is a step in "Process of Implementing LDAP or ADSI Security Adapter Authentication".
The tests outlined in this topic allow you to confirm that the security adapter provided with Siebel Business Applications, your LDAP directory or Active Directory, and the Siebel application you are implementing work together to:
Provide a Web page on which the user can log in.
Allow an authenticated user to log in.
Allow a user to browse anonymously, if applicable to your Siebel application.
Allow a user to self-register, if applicable to your Siebel application.
To test your LDAP or ADSI authentication implementation, perform the following procedure.
To test your LDAP or ADSI authentication system
In a Web browser, enter the URL to your Siebel application, for example:
http://www.example.com/eservice_enu
If the authentication system has been configured correctly, then a Web page with a login form appears, confirming that the anonymous user can successfully access the login page.
Various links provide access to views intended for anonymous browsing. Some other links will require you to log in first.
|
Note: Employee applications, such as Siebel Call Center, typically do not allow anonymous browsing, while customer applications such as Siebel eService do. |
Navigate back to the Web page that contains the login text boxes, and then log in with the user ID and password for the test user you created. Enter TESTUSER or the user ID you created, and TESTPW or the password you created.
More screen tabs or other application features might appear, indicating that the test user has authenticated successfully. The user record in the database provides views through the expanded responsibility of this registered user.
Click the Log Out link.
Repeat Step 1 to access the login page. If a New User button is present, then click it.
If a New User button is not present, then your Siebel application, without additional configuration, does not allow users to self-register.
In the Personal Information form, complete the required fields, as shown below, and then submit the form. You can complete other fields, but they are not required.
| Field | Description |
|---|---|
| Last Name | Required. Enter any name. |
| First Name | Required. Enter any name. |
| User ID | Required. Enter a simple contiguous user ID, which must be unique for each user. Typically, the user provides this user ID to log in.
Depending on how you configure authentication, the user might or might not log in with this identifier. |
| Password | Optional (required for some authentication implementations).
Enter a simple contiguous login password. The password must conform to the syntax requirements of your authentication system, but it is not checked for conformity in this form. For LDAP or ADSI security adapter authentication, the password is propagated to the user directory. For database authentication, the password is propagated to the database. |
| Verify Password | Required when Password is required. |
| Challenge Question | Required. Enter a phrase for which there is an "answer." If you later click Forgot Your Password?, then this phrase is displayed, and you must enter the correct answer to receive a new password. |
| Answer to Challenge Question | Required. Enter a word or phrase that is considered the correct answer to the challenge question. |
Navigate to the page containing the login text fields.
Login using the user ID and password you created in Step 6.
If the authentication system has been configured correctly, then you can log in successfully and can navigate in the screens provided for registered users.
