A single IBM DB2 database can function as a:
Note: Store CA SiteMinder® session information in a separate database. Do not use the policy store to store session information.
Using a single database simplifies administrative tasks. The following sections provide instruction on how to configure a single database server to store CA SiteMinder® data.
Configuring a single IBM DB2 database to function as a policy store or any other type of CA SiteMinder® data store requires specific database information.
Consider the following items:
Gather the following information before configuring the policy store or any other type of CA SiteMinder® data store. You can use the IBM DB2 Information Worksheet to record your values.
Note: Policy and data store worksheets are provided to help you gather and record information before configuring or upgrading a CA SiteMinder® data store. You can print the applicable worksheet and can use it to record required information before beginning.
Default wire protocol setting: Public
(U) Isolation level—Determine the method by which the system acquires and releases locks.
Default wire protocol setting: CURSOR_STABILTY
Default wire protocol setting: 100
Complete the following procedures to configure a single IBM DB2 database as a policy store, key store, and logging database.
Note: Be sure that you have gathered the required database information before beginning. Some of the following procedures require this information.
The default DB2 value for each setting is not sufficient for the CA SiteMinder® policy store schema.
The default DB2 value for each setting is not sufficient for the CA SiteMinder® policy store and audit store schema.
Follow these steps:
Specifies the Policy Server installation path.
Specifies the schema for a policy or key store in a DB2 database.
The policy and key store schema is created in the DB2 database.
Specifies the schema for an audit log store in a DB2 database. For 12.52 edit this script before creating an audit store.
Specifies the schema for sample users in a DB2 database and populates the database with the sample users.
The corresponding CA SiteMinder® schema is created in the DB2 database.
Note: Using the policy store to store key, audit, and sample users is optional. You can use separate databases to function as these types of CA SiteMinder® data stores individually.
siteminder_home\xps\db\DB2.sql
Specifies the Policy Server installation path.
db2 -td@ [-v] -f path\DB2.sql
Specifies the path to the DB2 schema file.
The policy store schema is created.
If you are using ODBC, configure a data source to let CA SiteMinder® communicate with the CA SiteMinder® data store.
Create a DB2 Data Source on Windows Systems
When using ODBC, you can create a DB2 data source for the DB2 wire protocol driver.
Follow these steps:
The ODBC Data Source Administrator appears.
Example:
SiteMinder DB2 Wire Data Source
The connection is tested.
The ODBC DB2 Wire Protocol Driver Setup dialog closes, the selections are saved, and the DB2 data source is created on a Windows System.
Note: You can now configure CA SiteMinder® to use the data source that you created.
Create a DB2 Data Source on UNIX Systems
The SiteMinder ODBC data sources are configured using a system_odbc.ini file, which you can create by renaming db2wire.ini, located in policy_server_home/db, to system_odbc.ini. This system_odbc.ini file contains all of the names of the available ODBC data sources as well as the attributes that are associated with these data sources. This file must be customized to work for each site. Also, you can add additional data sources to this file, such as defining additional ODBC user directories for SiteMinder.
The first section of the system_odbc.ini file, [ODBC Data Sources], contains a list of all of the currently available data sources. The name before the “=” refers to a subsequent section of the file describing each individual data source. After the “=” is a comment field.
Each data source has a section in the system_odbc.ini file describing its attributes. The first attribute is the ODBC driver to be loaded when this data source is used by SiteMinder. The remaining attributes are specific to the driver.
Adding a DB2 Data source involves adding a new data source name in the [ODBC Data Sources] section of the file, and adding a section that describes the data source using the same name as the data source. You need to change the system_odbc.ini file if you create a new service name or want to use a different driver. You should have entries for the DB2 driver under [SiteMinder Data Source].
Again, to configure a DB2 data source, you must first create a system_odbc.ini file in the policy_server_home/db directory. To do this, you need to rename db2wire.ini, located in policy_server_home/db, to system_odbc.ini.
Note: policy_server_home specifies the Policy Server installation path.
Configure the DB2 Wire Protocol Driver
The following table contains configuration parameters for DB2 data sources. You can edit these parameters to configure data sources for separate key, audit log, session, and sample users databases.
Parameter |
Description |
How to Edit |
Data Source Name |
Name of the data source. |
Enter the data source name inside the square brackets. |
Driver |
Full path to the SiteMinder DB2 Wire Protocol driver. |
Replace “nete_ps_root” with the SiteMinder installation directory. |
Description |
Description of the data source. |
Enter any desired description. |
Database |
Name of the DB2 UDB database. |
Replace “nete_database” with the name of the database configured on the DB2 UDB server. |
LogonID |
Username required for accessing the database. |
Replace “uid” with the username of the DB2 UDB administrator. |
Password |
Password required for accessing the database. |
Replace “pwd” with the password of the DB2 UDB administrator. |
IPAddress |
IP address or hostname of the DB2 UDB server. |
Replace “nete_server_ip” with the IP address or the hostname of the DB2 UDB server. |
TcpPort |
TCP port number of the DB2 UDB server. |
Replace the default value of 50000 with the actual TCP port number of the DB2 UDB server. |
Package |
The name of the package to process dynamic SQL. |
Replace “nete_package” with the name of the package you want to create. |
PackageOwner |
(Optional) The AuthID assigned to the package. |
Empty by default. This DB2 AuthID must have authority to execute all SQLs in the package. |
GrantAuthid |
The AuthID granted execute privileges for the package. |
“PUBLIC” by default. Specify the desired AuthID if you wish to restrict the execute privileges for the package. |
GrantExecute |
Specifies whether to grant execute privileges to the AuthID listed in GrantAuthid. |
Can be either 1 or 0. Set to 0 by default. |
IsolationLevel |
The method by which locks are acquired and released by the system. |
CURSOR_STABILITY by default. |
DynamicSections |
The number of statements that the DB2 Wire Protocol driver package can prepare for a single user. |
100 by default. Enter the desired number of statements. |
You point the Policy Server to the database so the Policy Server can access the CA SiteMinder® data in the policy store.
Follow these steps:
ODBC
Policy Store
Note: We recommend retaining the 25 connection default for best performance.
Key Store
ODBC
Use the Policy Store database
Audit Logs
ODBC
Use the Policy Store database
The Policy Server is configured to use the database as a policy store, key store, and logging database.
The default CA SiteMinder® administrator account is named:
siteminder
The account has maximum permissions.
We recommend that you do not use the default superuser for day–to–day operations. Use the default superuser to:
Follow these steps:
Specifies the Policy Server installation path.
Note: The utility is at the top level of the Policy Server installation kit.
smreg -su password
Specifies the password for the default CA SiteMinder® administrator.
Limits:
Note: If you are configuring an Oracle policy store, the password is case–sensitive. The password is not case–sensitive for all other policy stores.
The password for the default CA SiteMinder® administrator account is set.
Importing the policy store data definitions defines the types of objects that can be created and stored in the policy store.
Follow these steps:
Specifies the Policy Server installation path.
XPSDDInstall SmMaster.xdd
Imports the required data definitions.
Importing the default policy store objects configures the policy store for use with the Administrative UI and the Policy Server.
Consider the following items:
Specifies the Policy Server installation path.
Follow these steps:
XPSImport smpolicy.xml -npass
XPSImport smpolicy-secure.xml -npass
Specifies that no passphrase is required. The default policy store objects do not contain encrypted data.
Both files include the default policy store objects. These objects include the default security settings in the default Agent Configuration Object (ACO) templates. The smpolicy–secure file provides more restrictive security settings. For more information, see Default Policy Store Objects Consideration.
Note: Importing smpolicy.xml makes available legacy federation and Web Service Variables functionality that is separately licensed from CA SiteMinder®. If you intend on using the latter functionality, contact your CA account representative for licensing information.
Enable the advanced authentication server as part of configuring your Policy Server.
Follow these steps:
The master key screen appears.
Note: If you are installing another (nth) Policy Server, use the same encryption key for the Advanced Authentication server that you used previously.
The advanced authentication server is enabled.
You use the default CA SiteMinder® super user account (siteminder) to log into the Administrative UI for the first–time. The initial login requires that you to register the Administrative UI with a Policy Server, which creates a trusted relationship between both components.
You prepare for the registration by using the XPSRegClient utility to supply the super user account name and password. The Policy Server uses these credentials to verify that the registration request is valid and that the trusted relationship can be established.
Consider the following:
To prepare for the Administrative UI registration
XPSRegClient siteminder[:passphrase] -adminui-setup -t timeout -r retries -c comment -cp -l log_path -e error_path -vT -vI -vW -vE -vF
Specifies the password for the default CA SiteMinder® super user account (siteminder).
Note: If you do not specify the passphrase, XPSRegClient prompts you to enter and confirm one.
Specifies that the Administrative UI is being registered with a Policy Server for the first–time.
(Optional) Specifies the allotted time from when you to install the Administrative UI to the time you log in and create a trusted relationship with a Policy Server. The Policy Server denies the registration request when the timeout value is exceeded.
Unit of measurement: minutes
Default: 240 (4 hours)
Minimum Limit: 15
Maximum Limit: 1440 (24 hours)
(Optional) Specifies how many failed attempts are allowed when you are registering the Administrative UI. A failed attempt can result from submitting incorrect CA SiteMinder® administrator credentials when logging into the Administrative UI for the first–time
Default: 1
Maximum Limit: 5
(Optional) Inserts the specified comments into the registration log file for informational purposes.
Note: Surround comments with quotes.
(Optional) Specifies that registration log file can contain multiple lines of comments. The utility prompts for multiple lines of comments and inserts the specified comments into the registration log file for informational purposes.
Note: Surround comments with quotes.
(Optional) Specifies where the registration log file must be exported.
Default: siteminder_home\log
siteminder_home
Specifies the Policy Server installation path.
(Optional) Sends exceptions to the specified path.
Default: stderr
(Optional) Sets the verbosity level to TRACE.
(Optional) Sets the verbosity level to INFO.
(Optional) Sets the verbosity level to WARNING.
(Optional) Sets the verbosity level to ERROR.
(Optional) Sets the verbosity level to FATAL.
XPSRegClient supplies the Policy Server with the administrator credentials. The Policy Server uses these credentials to verify the registration request when you log into the Administrative UI for the first–time.
Copyright © 2013 CA.
All rights reserved.
|
|