Symantec Access Management

<<TableOfContents>>

Policy Server Troubleshooting

NETE_PS_ALT_CONF_FILE Environment Variable on Solaris

After installing the Policy Server on Solaris, the nete_ps_env.ksh script may have the following entry:

export NETE_PS_ALT_CONF_FILE=/export/siteminder/config/.siteminder.conf

The NETE_PS_ALT_CONF_FILE environment variable is used by the stop-all and start-all scripts, which stop and start the Policy Server’s service. The .siteminder.conf file is a temporary, run-time file created by these scripts and has no affect on your SiteMinder configuration.

Do not modify the NETE_PS_ALT_CONF_FILE environment variable.

Policy Server Fails to Start After Installation

Valid on Windows and UNIX Systems

Symptom:
I have installed the Policy Server, but it is not starting.

Solution:
You may have the wrong JRE version installed. Make sure you have the correct JRE version. Note: For a list of supported CA and third-party components, refer to the SiteMinder R12.5 Platform Support Matrix on the Technical Support site.

Winsock error 10054 message

Valid on Windows

Symptom:
When I try to log into the Policy Server, I receive the "Unable to proceed, winsock error 10054" message.

Solution:
One of the following could be the cause of the problem:

• The policy store does not contain the proper SiteMinder schema. Make sure you imported the correct SiteMinder schema.
• The Policy Server is not running. To start this server, use the Status tab on the Policy Server Management Console.
• The Policy Server is not connected to the policy store properly. Using the Data tab on the Policy Server Management Console, click Test Connection to make sure the policy store connects successfully. If it does not, reenter the data source information values on the Data tab by pointing the Policy Server at the policy store.

Policy Store Troubleshooting

Importing the Policy Store data definitions fails

Symptom:
When importing the Policy Store data definitions, XPSDDInstall fails to import all SiteMinder objects and terminate with error message: CA-XPS:EDIT0050(ERROR) : Object #639 has parent #1, which does not exist. and CA-XPS:XPSIO040(ERROR) : Delete of Tombstones failed.
Solution:
The Policy Store has gotten corrupted. XPSSweeper is a tool used to synchronize the data within the store in order to fix it. You need to run XPSSweeper command each time you get the error then repeat the previous XPSDDInstall command.

C:\>XPSDDInstall "C:\Program Files\CA\siteminder\xps\dd\SmObjects.xdd" [XPSDDInstall - XPS Version 12.0.0200.186] Log output: XPSDDInstall.2010-01-22_161716.log Initializing database, please wait... CA-XPS:ODBC0017(WARN) : No policy data found Loading file SmObjects.xdd, please wait... Saving data from SmObjects.xdd, please wait... CA-XSave complete. Thank you for waiting. PS:EDIT0050(ERROR) : Object #639 has parent #1, which does not exist. C:\>XPSSweeper  C:\>XPSDDInstall "C:\Program Files\CA\siteminder\xps\dd\SmObjects.xdd" [XPSDDInstall - XPS Version 12.0.0200.186] Log output: XPSDDInstall.2010-01-22_162915.log Initializing database, please wait... Loading file SmObjects.xdd, please wait... Saving data from SmObjects.xdd, please wait... Save complete. Thank you for waiting.

Repeat the previous sequence for each .xdd files if you get the error message.

Policy Stores with Large Numbers of Objects

Valid on Windows and UNIX Systems
Symptom:
My Policy store has returned the exception java.lang.IndexOutOfBounds to the FSS Administrative UI.

Solution:
Policy Stores with large numbers of objects may return the exception java.lang.IndexOutOfBounds to the Administrative UI. Define the registry key \HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\SiteMinder\CurrentVersion\ObjectStore\MaxObjects to a value lower than 100 (such as 50).

SSL initialization failed: error -8174 (security library: bad database.)

Valid on Windows and UNIX Systems
Symptom:
When I run smldapsetup ldmod -fpstore -ssl1 -c/app/siteminder/ssl/cert7.db for policy stores that are using an SSL-encrypted connection to Sun Java System Directory Server, I receive the following error message: "SSL initialization failed: error -8174 (security library: bad database.)"

Solution:

1. Make sure the key3.db file exists in the same directory as cert7.db for the Netscape Web browser.
2. Rerun this smldapsetup command, and, for the -c option, specify the path of the directory where the SSL client certificate database file, cert7.db, exists. Example: if cert7.db exists in /app/siteminder/ssl, specify -c/app/siteminder/ssl/cert7.db

ODBC Policy Store Import Fails with UserDirectory Error

Symptom:
I receive an error message stating that the policy store failed operation "save" for object type "UserDirectory" when importing policy store data into an ODBC policy store.

Solution:
It is possible that the server name in the ODBC store's userDirectory object is longer than 512 characters, which by default, exceeds the limit allowed by the MS SQL Server and Oracle policy store schema scripts that are shipped with SiteMinder.
Do one of the following:
If you are trying to import policy data into a supported version of a MS SQL Server policy store:

• Open sm_mssql_ps.sql Note: This schema script is located in policy_server_home\db\SQL.
• Search for the following text: CREATE TABLE smuserdirectory5
• Modify "server smstringreq512N," to one of the following depending on your needs: server smstringreq1024,N server smstringreq4000,N
• Re-import the policy store schema into the policy store.
• Import the policy store data.

If you are trying to import policy data into a supported version of an Oracle policy store:

• Open sm_oracle_ps.sql Note: This schema script is located in policy_server_home\db\SQL.
• Search for the following text: CREATE TABLE smuserdirectory5
• Modify "server VARCHAR2(512) NOT NULL," to one of the following depending on your needs: server VARCHAR2(1024) NOT NULL, server VARCHAR2(4000) NOT NULL,
• Re-import the policy store schema into the policy store.
• Import the policy store data.

“Failed to decrypt persistent key" errors after upgrading the policy Server

Symptom:
After upgrading the SiteMinder Policy Server; The policy server starts giving - "Failed to decrypt persistent key" errors in Policy Server (SMPS) logs.

++++++++++Error from SMPS Log ++++++++++++++ [20369/10][Tue Nov 16 2010 14:50:33][SmObjKeyManagement.cpp:457][ERROR] Failed to decrypt persistent key +++++++++++++++++++++++++++++++++++++++++

Cause of this Error:
Encryption key on file (EncryptionKey.txt) in a policy server installation is used to generate the policy store key. With this key the Persistent Key is encrypted. Later, when the policy server needs the persistent key (to encrypt other data, like pwd blob or to do host registration) it uses the policy store Key to decrypt the encrypted Persistent Key which is the DB. In 6.x policy servers, when PS couldn't decrypt this persistent key using the Policy Store Key, it would continue and use an empty PersistentKey to encrypt the data. In r12.x Policy Servers, a test was added in the code to check if we succeeded to decrypt the PersistentKey, and return an error if we could not. Such a situation can occur if, for example, the EncryptionKey.txt file was changed or copied from another machine. There can be other scenarios that can cause this to fail. As a result, when a customer has this situation and doesn't know about it (that they use empty PersistentKey) and then upgrade to r12, they problem arises since in r12 the check is made to verify that the PersistentKey can be decrypted.
Solution:
IMPORTANT: This article contains information about modifying the registry. Before you modify the registry, make sure to create back up of the registry and ensure that you understand how to restore the registry if a problem may occur. For more information about how to back up, restore, and edit the registry, please review the relevant Microsoft Knowledge Base articles on support.microsoft.com.

This issue has been fixed in Policy Server version R12 SP2 and above.

A new Registry key (AllowEmptyEncKey) has been added for r12.x policy servers to prevent this error and work in the same way as 6.x policy server's work. If this registry key is set (AllowEmptyEncKey=1), then -
If policy server cannot decrypt the PersistentKey; it will not log the "Failed to Decrypt Persistent Key" error in SMPS logs and will continue to use empty Persistent Key to encrypt the data (i.e. R12.x PS will keep on working like the 6.x one)

Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\SiteMinder\CurrentVersion\ObjectStore DWORD key: AllowEmptyEncKey Value: 1 Note: By Default this key is not set.

OneView Monitor Troubleshooting

Fix Modified UNIX/Sun Java System Web Server Configuration Files

As mentioned in the procedure for installing the ServletExec/AS on a UNIX/Sun Java System, we advise not allowing ServletExec to modify the Sun Java System Web server's configuration files (obj.conf and magnus.conf). However, if ServletExec did modify these files during installation, the Web server instance fails after you configure the FSS Administrative UI and OneView Monitor GUI using the Policy Server installer/wizard. The ServletExec installer puts entries in these files that conflict with those from the Policy Server. To keep the Web server instance from failing, remove the conflicting entries from the Sun Java System Web Server instance's obj.conf and magnus.conf files.

• Open /<sunjavasystem_home>/servers/https-<web_server_instance_name>.domain.com/config/magnus.conf, and remove the first line:
• Init fn="ServletExecInit" <ServExec_instance_name>.instances="<IP_address>:<portnumber> "
  • ServExec_instance_name Specifies the name of your SerlvetExec instance.
  • IP_address Specifies the IP Address of the machine where ServletExec is installed.
  • portnumber Specifies the port number for the SerlvetExec instance. Note: The Policy Server Configuration Wizard added the correct entry at the end of the file.
• Open /<sunjavasystem_home>/servers/https-<web_server_instance_name>.domain.com/config/obj.conf, and remove lines four and five from the top of the file:
• NameTrans fn="assign-name" from="/servlet/*" name="<ServExec_instance_name>"
• NameTrans fn="assign-name" from="*.jsp*" name="<ServExec_instance_name>" Important! Do not remove the name="se-<ServExec_instance_name>" entries in lines two and three since these were added by the Policy Server Configuration Wizard.
• In the same obj.conf file, remove the second to the last <Object name="<ServExec_instance_name>"> section from the end of the file:
• <Object name="<ServExec_instance_name>">
• Service fn="ServletExecService" group="<ServExec_instance_name>"
• </Object> Important! Do not remove the <Object name="se-<ServExec_instance_name>"> entry since this one was added by the Policy Server Configuration Wizard.

1. After saving these files, you should be able to start the Web server instance from the Sun Java System Web Server Administration Server page.

Windows/IIS Virtual Path to /sitemindermonitor Does Not Exist

Valid on Windows
Symptom:
The virtual path to the /sitemindermonitor does not exist under Default Web Site in the IIS Microsoft Management Console.

Solution:
Create the virtual path.
To create the virtual path

• From the Start menu, go to: Programs, Administrative Tools, Internet Service Manager.
• Select Default Web Site.
• From the Action menu, select New, Virtual Directory. The Virtual Directory Wizard opens.
• Specify the name (alias) of the virtual directory. For example: sitemindermonitor Note: You can specify any name for the alias as sitemindermonitor is an example
• Click Next.
• Specify the path to <siteminder_installation>\monitor\.
• Click Next.
• Select the Allow Execute Access permission.
• Click Finish.

Administrative UI Troubleshooting

SiteMinder Administrative UI does not start

Symptom:
After installing the SiteMinder Administrative UI with success (no error is reported in the installation log file), connecting to the WAMUI fails and you get the following error message:

The SiteMinder Administrative UI did not start within the allocated time. Wait for the SiteMinder Administrative UI to start and click "Try Again".

Solution:
The SiteMinder Administrative UI service may not be started. By default and when using the pre-requisite installer, the installer creates a Windows service to automatically start the JBoss service. The installer fails to create this service in the following cases:

• The installation drive of the SiteMinder Administrative UI is not the C:\ drive (This issue has been fixed in R12 Sp2 CR1)
• The Windows user account used to install SiteMinder Administrative UI has its TEMP directory not located on the C:\ drive To create the service manually, browse to the <JBoss>/bin folder and type the command "service.bat install".

If the pre-requisite installer is not used, make sure that the JBoss is started using run_idm.bat.

Cannot Register a Policy Server Connection

Symptom:
The Administrative UI is registered to a Policy Server that is unavailable and I am trying to register another Policy Server connection. When I log into the Administrative UI with an administrator that has super user permissions, the Register Policy Server Connection task does not appear.

Solution:
A single user was delegated super user permissions when the connection to the external administrator store was configured. Log into the Administrative UI with this super user account. When a Policy Server connection becomes unavailable, this super user is the only user that can register a Policy Server connection.

API Error Appears

Symptom:
The Administrative UI registration fails with an Agent API failure message.

Solution:
The Policy Server is not started. Start the Policy Server using the Policy Server Management Console.

Registration Not on File Error Appears

Symptom:
Registering the Administrative UI with a Policy Server fails with a registration record not on file error message.

You can receive this message when:

• You have installed the Administrative UI and are trying to register the Administrative UI with a Policy Server for the first–time.
• You have registered the Administrative UI and are trying to register an additional Policy Server connection.
  Solution:
  Do one of the following:
  If you are registering the Administrative UI for the first–time
• Log into the Policy Server host system.
• Run the following command: XPSRegClient siteminder_administrator[:passphrase] -adminui–setup
  • siteminder_administrator
    Specifies a SiteMinder administrator. If you are installing the Administrative UI as part of:
    • A new r12.0 SP2 environment, specify the default SiteMinder administrator account (siteminder).
    • An upgrade, specify any SiteMinder administrator account with super user permissions in the policy store. Note: If you are upgrading from r12.0 SP1 and do not have a super user account, use the smreg utility to create the default SiteMinder administrator (siteminder). For more information about using the smreg utility, see the Policy Server Administration Guide.
  • passphrase Specifies the password for the SiteMinder administrator account. Limits:
    • The passphrase must contain at least six (6) characters.
    • The passphrase cannot include an ampersand (&) or an asterisk (*).
    • If the passphrase contains a space, enclose the passphrase with quotation marks.
• Log into the Administrative UI using the default SiteMinder administrator account to complete the registration.

If you are trying to register an additional Policy Server connection

• Log into the Policy Server host system.
• Run the following command: XPSRegClient client_name[:passphrase] -adminui
  • client_name Identifies the Administrative UI being registered. Limit: This value must be unique. For example, if you have previously used smui1 to register an Administrative UI, enter smui2.
  • passphrase Specifies the password required to complete the registration of the Administrative UI. Limits:
    • The passphrase must contain at least six (6) characters.
    • The passphrase cannot include an ampersand (&) or an asterisk (*).
    • If the passphrase contains a space, enclose the passphrase with quotation marks.
• Log into the Administrative UI to register the Policy Server connection.

Invalid Registration File Error Appears

Symptom:
I am trying to register an additional Policy Server connection. The registration fails with an invalid registration file error message.

Solution:
Verify that the passphrase you entered is identical to the passphrase you created using XPSRegClient. The value you created must match the value that you enter using the Administrative UI. If you do not have a passphrase:

• Log into the Policy Server host system.
• Run the following command:
• XPSRegClient client_name[:passphrase] -adminui
  • client_name Identifies the Administrative UI being registered. Limit: This value must be unique. For example, if you have previously used smui1 to register an Administrative UI, enter smui2.
  • passphrase Specifies the password required to complete the registration of the Administrative UI. Limits:
    • The passphrase must contain at least six (6) characters.
    • The passphrase cannot include an ampersand (&) or an asterisk (*).
    • If the passphrase contains a space, enclose the passphrase with quotation marks.
• Log into the Administrative UI to register the Policy Server connection.

Registration Fails without Timeout

Symptom:
The Administrative UI registration fails without timing out.

Solution:
Do the following:

• Ping the machine hosting the Policy Server to be sure it is available.
• Locate the following registration file in policy_server_home\bin:
• name.XPSReg
  • policy_server_home Specifies the Policy Server installation path
  • name Identifies the client name you specified when using the Administrative UI registration tool (XPSRegClient) to create a client name and passphrase. If the registration file does not exist, run XPSRegClient to create a client name and passphrase.
• Open the Policy Server log file (smps.log) and review it for errors that may have occurred around the time of the registration.

Cannot Find the Administrative UI Registration Log

Symptom:
I am trying to troubleshoot the Administrative UI registration and cannot find the log file.

Solution:
XPSRegClient creates and saves the log file in policy_server_home\log. The file name is XPSRegClient.date

• policy server home Specifies the Policy Server installation path.
• date Specifies the date on which XPSRegClient created the file. Example: XPSRegClient.2007-12-1.154002 Note: The last six digits are a unique identifier you can use if more than one file is created on the same day.

Search Fails with Timeout Error

Symptom:
I cannot complete a search for policy objects. The Administrative UI displays a connection timeout error instead of returning the search results.

Solution:
When searching on a large number of policy objects via the Administrative UI, the connection between the Administrative UI and the Policy Server may time out and/or the Policy Server tunnel buffer may become corrupt. This results in a connection timeout error. Adjusting the Administrative UI Policy Server connection timeout and creating a registry key for the Policy Server tunnel buffer size solves this problem.

To adjust the Policy Server connection timeout

• Log in to the Administrative UI.
• Click Administration, Admin UI, Policy Server Connections, Modify Policy Server Connection, Search to open the Policy Server connection object.
• Select the appropriate Policy Server and click Submit.
• Set the Timeout field in the Advanced section to a large value, such as 2,000 seconds. The Policy Server connection timeout is now increased. To create a registry key for the tunnel buffer size
• Create the following Policy Server registry key: HKLM\SOFTWARE\Netegrity\SiteMinder\CurrentVersion\PolicyServer\Max AdmComm Buffer Size
• Set this registry key to a slightly larger value, such as 512 KB (default is 256 KB)
• Save the changes and exit the registry. Note: If the problem persists after the connection timeout and buffer size changes, restart the Administrative UI

Cannot Find the Default Logging File

Symptom:
I am trying to troubleshoot a deployed Administrative UI instance and cannot find the default application server log file.

Solution:
If you used the stand–alone installation option, the name of the default log file is server.log. This log file is located at administrative_ui_home\CA\SiteMinder\adminui\server\default\log.

• administrative_ui_home Specifies the Administrative UI installation path. Note: If you installed the Administrative UI to an existing instance of JBoss, WebSphere, or WebLogic, see your vendor–specific documentation for more information about default logging.

Default Log File does not Provide Enough Information

Symptom:
I am trying to troubleshoot a deployed Administrative UI instance and the default application server log file does not provide enough information.

Solution:
Use the SiteMinder Log4j properties file to configure SiteMinder-specific logging settings. The file contains comments about configuring the logging settings. The location of the file depends on the installation option that was used to install the Administrative UI.

• Stand–alone installation If you used the stand–alone installation option, the properties file is located at administrative_ui_home\CA\SiteMinder\adminui\server\default\deploy\iam_siteminder.ear\user_console.war\META-INF.
  • administrative_ui_home Specifies the Administrative UI installation path.
• Existing application server infrastructure If you installed the Administrative UI to an existing application server infrastructure, the properties file is located at: deploy\iam_siteminder.ear\user_console.war/META-INF
  • deploy Specifies where your application server deploys applications. Note: If you upgraded the Administrative UI to r12.0 SP2, the properties file is located at deploy/IdentityMinder.ear/user_console.war/META-INF.

Unable to register the WAM UI for Siteminder on RHEL5

Symptom:
The default install of Red Hat Enterprise Linux 5 enabled the iptables firewall, this restricts traffic on ports 44441-44443, and will cause problems with registration of the WAM UI with Siteminder R12, and Siteminder R6 this will become noticable when trying to register webagents with the policy server.

As a temporary fix disabling the iptables service:

    /etc/init.d/iptables stop

will enable registration to proceed as normal.
Solution:
The default install of Red Hat Enterprise Linux 5 enabled the iptables firewall, this restricts traffic on ports 44441-44443. In a default Siteminder R12 install this will first cause a problem when trying to register the WAMUI with the policy server: The entry in the WAM UI log will look like this :

09:42:34,619 INFO [UIAgent] Bootstrap UIAgent is shutdown  09:42:34,636 ERROR [EventExecuteStateException] Execution of event: CreateUIConnectionEvent failed. Exception encountered: Agent API failure  09:42:34,637 ERROR [IMSEventController] Error during event execution [60dd2228-64dc45e0-00ff22ed-69cf726c] CreateUIConnectionEvent  09:42:34,809 WARN [eventlistener] EvtIMTaskEvent:d3dc62a4-bb78d9ed-4d80ad90-acf805d is invalid.  09:42:35,826 DEBUG [UIComponentTag] Entered encodeBegin for client-Id: headContents 

And there are no entries in the policy server log. A quick test using telnet to try and access the policy server via: $ telnet policyserver 44443

will timeout without making a connection, indicating there is a problem with establishing the connection. There are a number of other issues that can occur during registration, but in this case it was the iptables firewalling that was disabling connections on the standard siteminder ports 44441-44443. Disabling the iptables service temporarily on the policy server: /etc/init.d/iptables stop will then enable registration of the WAM UI to proceed. But as indicated, there are other reasons that your WAM UI registration may not succeed, for instance there is a timeout period for the registration credentials, so if this does not fix your problem you should look for other reasons the network connection cannot be made. For a more permanent solution you will need to disable the iptables service for the normal running levels of Linux which can be done as follows: $ chkconfig --levels 345 iptables off

or you can navigate the RedHat Gui firewall configuration tool to allow connections to the policy server on the ports 44441-44443. Note: If iptables is enabled in a Siteminder R6 Policy Server that will also causes problems, but for R6 the first problem encountered will be when trying to do a trusted host registration from the webagent to the policy server.

No Tabs appear in the Administrative UI

Symptom:
No tabs appear when I log into the Administrative UI for the first time to register it with a Policy Server.

Solution:
Although you have logged in using the credentials of a user in the administrator user store, this is not the individual you identified as the Super User when installing the Administrative UI. Log in using the credentials of the user you identified as the Super User when installing the Administrative UI.

Additional Tabs do not appear after Registration

Symptom:
I have successfully registered the Administrative UI with a Policy Server, but the Infrastructure and Policies tabs do not appear.

Solution:
It is possible that you did not use the -su argument when using the Administrative UI registration tool (XPSRegClient) to create the client name and passphrase.

• Re-run the Administrative UI registration tool with the -su argument. Note: Ensure that you specify a unique client name. For example, if you had previously specified smui1 as a client name, specify smui2.
• Configure the connection between the Administrative UI and PolicyServer.