1. Download and Install OpenLDAP
This article does not cover the specific details on how to build and install OpenLDAP. The details for this can be found on the OpenLDAP site. A quick start guide is located there as well.

2. Download the OpenLDAP Schema Files for SiteMinder
OpenLDAP is considered a “Tier 2″ directory for SiteMinder. As such, the ability to configure the directory as a Policy Store is not automated. In order to obtain the needed schema files for the Policy Store, the “CA SiteMinder Tier 2 Directories- ESD Only” package must be downloaded. To download this file (current as of 10/12/2011):

1. Log in to the Technical Support Site
2. Click “Download Center” in the lefthand navigation
3. Type siteminder into the “Select a Product” field
4. Select the listed SiteMinder product
5. Select 12.0 in the “Select a Release” drop-down
6. Select SP3 in the “Select a Gen level” drop-down
7. Click the [GO] button
8. Scroll down to the bottom of the list of returned downloads
9. Download and unzip the “CA SiteMinder Tier 2 Directories- ESD Only” download to the Policy Server

3. Configure OpenLDAP To Support the SiteMinder Policy Store
The OpenLDAP server requires manual configuration to support its use as a SiteMinder Policy Store. The following steps are required:

3a. Copy the Policy Store schema files into the OpenLDAP schema directory
3b. Include the SiteMinder Policy Store schema files in the OpenLDAP configuration
3c. Ensure that SiteMinder can detect it is an OpenLDAP Policy Store
3d. Create the base Policy Store structure
3e. Restart OpenLDAP

Note that these instructions assume that the install location for OpenLDAP is under the /usr/local path and the default directories are used. For this example, the root of the directory is “dc=company,dc=com” for the location of the Policy Store. These steps will need to be modified if a different path or directory structure is used.

3a. Copy the Policy Store schema files into the OpenLDAP schema directory
The OpenLDAP schema needs to be extended to support the SiteMinder Policy Store objects. This is done by copying the schema files to the server and adding them into the slapd.conf configuration file. To copy the schema files:

1. If not already done, unzip the Tier 2 directory support zip file to a known location (I used “/home/installers” for these steps)
2. Copy the following files to the “/usr/local/etc/openldap/schema” directory by running the following commands:

cp /home/installers/Tier2DirSupport/openldap/openldap_attribute.schema /usr/local/etc/openldap/schema
cp /home/installers/Tier2DirSupport/openldap/openldap_object.schema /usr/local/etc/openldap/schema
cp /home/installers/Tier2DirSupport/xps/openldap/openldap_attribute_XPS.schema /usr/local/etc/openldap/schema
cp /home/installers/Tier2DirSupport/xps/openldap/openldap_object_XPS.schema /usr/local/etc/openldap/schema

The schema files now need to be added into the OpenLDAP configuration.

3b. Include the SiteMinder Policy Store schema files in the OpenLDAP configuration
Once the Policy Store schema files are copied into the correct location, they need to be added to the OpenLDAP configuration. This is done by adding them to the slapd.conf file. In this example, the slapd.conf file is located in the “/usr/local/etc/openldap” directory. To include the files:

1. Edit the slapd.conf file with your favorite editor (e.g. vi slapd.conf)
2. Add the following lines to the file under the “include /usr/local/etc/openldap/schema/core.schema” line and then save the configuration (note that other changes to this file will be made in later steps):

include         /usr/local/etc/openldap/schema/openldap_attribute.schema
include         /usr/local/etc/openldap/schema/openldap_object.schema
include         /usr/local/etc/openldap/schema/openldap_attribute_XPS.schema
include         /usr/local/etc/openldap/schema/openldap_object_XPS.schema

OpenLDAP can now reference the appropriate schema files for the Policy Store objects.

3c. Ensure that SiteMinder can detect it is an OpenLDAP Policy Store
Since OpenLDAP does not support server-side sorting SiteMinder must instead handle sorting on the client side. To accomplish this, all XPS objects are retrieved at start-up using server-side paging.

To support client-side sorting, OpenLDAP must be configure with the following settings in the slapd.conf file:

• Allow SiteMinder to read the Root DSE so that it can determine the directory is of type OpenLDAP
• Set the maximum number of entries returned in a search operation to at least 500 so that the XPS objects are retrieved in increments of 500 or more objects
• Allow v2 LDAP binds so that the SiteMinder Admin Console (smconsole) to test the LDAP connection to the Policy Store

To allow SiteMinder to read the Root DSE, uncomment the following 2 lines in the slapd.conf file:

access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read

By default the sizelimit setting for OpenLDAP is 500. Ensure that this is the minimum value in the slapd.conf file. If the value is less than 500, increase it to 500 by adding the following line above the “BDB database definitions” section in the slapd.conf file:

sizelimit 500

To allow v2 binds, add the following line above the “BDB database definitions” section in the slapd.conf file:

allow bind_v2

SiteMinder should now be able to correctly identify the Policy Store as an OpenLDAP server and validate that it can connect to the server.

3d. Create the base Policy Store structure
In order to import the Policy Store base objects, the proper directory structure must be in place prior to running the administration tools. This is done by creating an LDIF file with the correct DIT structure and importing it into the OpenLDAP server.

An LDIF file is a text file which represents the objects in an LDAP directory. In my example where my base DN is “dc=company,dc=com” I created the following LDIF file and saved it in the /home/installers directory. This LDIF file creates the base structure for SiteMinder to store its policy objects and also the Manager account which SiteMinder will use to bind (authenticate) to the directory:

# company.com
dn: dc=company,dc=com
objectclass: dcObject
objectclass: organization
o: Example Company
dc: company

# Manager, company.com
dn: cn=Manager,dc=company,dc=com
objectclass: organizationalRole
cn: Manager

# Netegrity, company.com
dn: ou=Netegrity,dc=company,dc=com
ou: Netegrity
objectClass: organizationalUnit
objectClass: top

# SiteMinder, Netegrity, company.com
dn: ou=SiteMinder,ou=Netegrity,dc=company,dc=com
ou: SiteMinder
objectClass: organizationalUnit
objectClass: top

# PolicySvr4, SiteMinder, Netegrity, company.com
dn: ou=PolicySvr4,ou=SiteMinder,ou=Netegrity,dc=company,dc=com
ou: PolicySvr4
objectClass: organizationalUnit
objectClass: top

# XPS, policysvr4, siteminder, netegrity, company.com
dn: ou=XPS,ou=policysvr4,ou=siteminder,ou=netegrity,dc=company,dc=com
ou: XPS
objectClass: organizationalUnit
objectClass: top

Once this file is created, you can import it using the following command (I called the file base.ldif):

/usr/local/bin/ldapadd -x -D “cn=Manager,dc=company,dc=com” -W -f /home/installers/base.ldif

3e. Restart OpenLDAP
To pick up the slapd.conf file changes, the OpenLDAP server must be restarted. Use the following command to stop OpenLDAP:

kill -INT `cat /usr/local/var/run/slapd.pid`

Use the following command to start OpenLDAP:

/usr/local/libexec/slapd

The OpenLDAP server should now be set to go for the next set of steps to load SiteMinder base policy objects.

4. Configure SiteMinder to Use OpenLDAP as the Policy Store
Once OpenLDAP is set up with the proper schema and other settings from section 3, the next step is to point SiteMinder at the OpenLDAP directory and create the base objects used by the policy server. The following steps are required:

4a. Point SiteMinder at the OpenLDAP instance
4b. Load the base objects into the Policy Store

These instructions assume that you have already installed the Policy Server binaries. For details on how to do this follow the instructions in the SiteMinder documentation. You do not need to configure the Policy Store during the installation of the Policy Server (that’s what we are doing here).

4a. Point SiteMinder at the OpenLDAP instance
You can point the Policy Server at the OpenLDAP directory either in the Policy Server Management Console (smconsole) or through the command line. The following section contains the command line based steps:

1. Run the following command to validate that the Policy Server can communicate with the OpenLDAP directory:

smldapsetup status -hhost -pport -dAdminDN -wAdminPW -rroot -ssl1/0 -ccert

Where:

-hhost Specifies the IP Address of the LDAP server host system.-pport Specifies the port on which the LDAP server is listening
-dAdminDN Specifies the name of an LDAP user with privileges to create LDAP schema in the LDAP directory server
-wAdminPW Specifies the password for an LDAP user with privileges to create LDAP schema in the LDAP directory server
-rroot Specifies the DN location of the SiteMinder data in the LDAP directory
-ssl1|0 Specifies an SSL connection. Limits: 0=no | 1=yes Default: 0
-ccert (Only required if the ssl value is 1) Specifies the path to the directory where the SSL client certificate database file, cert7.db, exists

Since I have OpenLDAP installed locally, the following command was used:

smldapsetup status -h127.0.0.1 -p389 -d"cn=Manager,dc=company,dc=com" -wpassword -r"dc=company,dc=com" -ssl0

2. Run the following command to configure the Policy Server to use the OpenLDAP Policy Store:

smldapsetup reg -hhost -pport -dAdminDN -wAdminPW -rroot -ssl1/0 -ccert

Where:

-hhost Specifies the IP Address of the LDAP server host system.-pport Specifies the port on which the LDAP server is listening
-dAdminDN Specifies the name of an LDAP user with privileges to create LDAP schema in the LDAP directory server
-wAdminPW Specifies the password for an LDAP user with privileges to create LDAP schema in the LDAP directory server
-rroot Specifies the DN location of the SiteMinder data in the LDAP directory
-ssl1|0 Specifies an SSL connection. Limits: 0=no | 1=yes Default: 0
-ccert (Only required if the ssl value is 1) Specifies the path to the directory where the SSL client certificate database file, cert7.db, exists

So, for this install the following command was used:

smldapsetup reg -h127.0.0.1 -p389 -d"cn=Manager,dc=company,dc=com" -wpassw0rd -r"dc=company,dc=com" -ssl0

4b. Load the base objects into the Policy Store
The next step is to load the base objects into the Policy Store. To load the Policy Store objects the following steps are required:

• Register the SiteMinder admin user
• Load the base policy objects
• Load the base federation objects
• Import the XPS data definitions

To register the SiteMinder admin account, smreg is required. You may need to copy smreg from the SiteMinder Policy Server installation media to the <Policy Server Home>/bin directory where <Policy Server Home> is the installation path for the Policy Server.

1. Run the following command in the terminal to register the SiteMinder administrator account (switch to the <Policy Server Home>/bin directory is necessary):

smreg -su adminPW

Where:

adminPW is the administrator password for the “SiteMinder” account

2. Run the following command to import the base policy store objects:

smobjimport -i<Policy Server Home>/db/smdif/smpolicy.smdif -dsiteminder_super_user_name -wsiteminder_super_user_password -f -v -c

Where:

<Policy Server Home> is the installation path for the Policy Server
-i<Policy Server Home>/db/smdif/smpolicy.smdif Specifies the path and name of the import file
-dsiteminder_super_user_name Specifies the name of the SiteMinder administrator account
-wsiteminder_super_user_password Specifies the password for the SiteMinder administrator account
-f Overrides duplicate objects
-v Turns on tracing and outputs error, warning, and comment messages in verbose format so that you can monitor the status of the import
-c Indicates that the smdif input file contains unencrypted data

So, for this install the following command was used:

smobjimport -i/home/smuser/CA/siteminder/db/smdif/smpolicy.smdif -dsiteminder -wpassword -f -v -c

3. Run the following command to import the base federation objects:

smobjimport -i<Policy Server Home>/db/smdif/ampolicy.smdif -dsiteminder_super_user_name -wsiteminder_super_user_password -f -v -c

Where:

<Policy Server Home> is the installation path for the Policy Server
-i<Policy Server Home>/db/smdif/smpolicy.smdif Specifies the path and name of the import file
-dsiteminder_super_user_name Specifies the name of the SiteMinder administrator account
-wsiteminder_super_user_password Specifies the password for the SiteMinder administrator account
-f Overrides duplicate objects
-v Turns on tracing and outputs error, warning, and comment messages in verbose format so that you can monitor the status of the import
-c Indicates that the smdif input file contains unencrypted data

So, for this install the following command was used:

smobjimport -i/home/smuser/CA/siteminder/db/smdif/ampolicy.smdif -dsiteminder -wpassword -f -v -c

4. Importing the policy store data definitions is required to use the policy store with the Administrative UI. The base definitions describe the policy store data. Run the following commands to import the XPS data definitions (note that these commands must be run in the order below or the imports fail):

1. Switch to the <Policy Server Home>/xps/dd directory where <Policy Server Home> is the installation path for the Policy Server
2. Run the following command: XPSDDInstall SmObjects.xdd
3. Run the following command: XPSDDInstall EPMObjects.xdd
4. Run the following command: XPSDDInstall SecCat.xdd
5. Run the following command: XPSDDInstall FssSmObjects.xdd

The Policy Server is now fully configured to use OpenLDAP for the Policy Store.

5. Prepare the Policy Store for registration of the Administrative UI
The default SiteMinder super user account (siteminder) is used to log into the Administrative UI for the first time in order to register the Administrative UI. This creates a trusted relationship between both components. The XPSRegClient utility is used 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. Keep in mind that the time from which you supply the credentials to when the initial Administrative UI login occurs is limited to 24 hours. If you do not plan on installing the Administrative UI within one day, complete the following before installing the Administrative UI.

Run the following command to prepare the Policy Server 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

Where:

passphrase Specifies the password for the default SiteMinder super user account (if you do not specify the passphrase, XPSRegClient prompts you to enter and confirm one).
-adminui–setup Specifies that the Administrative UI is being registered with a Policy Server for the first–time.
-t timeout (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: 1
Maximum Limit: 1440 (24 hours)

-r retries (Optional) Specifies how many failed attempts are allowed when you are registering the Administrative UI. A failed attempt can result from submitting incorrect SiteMinder administrator credentials when logging into the Administrative UI for the first–time

Default: 1
Maximum Limit: 5

-c comment (Optional) Inserts the specified comments into the registration log file for informational purposes. Surround the comments with quotes.
-cp (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. Surround the comments with quotes.
-l log path (Optional) Specifies where the registration log file must be exported.

Default: <Policy Server Home>/log where <Policy Server Home> is the installation path for the Policy Server.

-e error_path (Optional) Sends exceptions to the specified path.

Default: stderr

-vT (Optional) Sets the verbosity level to TRACE.
-vI (Optional) Sets the verbosity level to INFO.
-vW (Optional) Sets the verbosity level to WARNING.
-vE (Optional) Sets the verbosity level to ERROR.
-vF (Optional) Sets the verbosity level to FATAL.

XPSRegClient supplies the Policy Server with the administrator credentials the Policy Server uses to verify the registration request when you log into the Administrative UI for the first–time.

Overview:
In a Windows network, a security context defines a user’s identity and authentication information. Web applications such as Microsoft Exchange Server or SQL Server need a user’s security context to provide native security in the form of Microsoft’s access control lists (ACLs) or other access control tools. The SiteMinder Web Agent can provide a Windows user security context for accessing Web resources on IIS Web servers. By establishing a user’s security context, the server can use this identity to enforce access control mechanisms. This approach can be used to supply the security context to applications that call native .NET (or other) methods to get the user and associate security information.

There are several requirements to use SiteMinder’s native mechanism to establish the security context in IIS:

• Active Directory must be used as the user store with the “Use authenticated user’s security context” option checked.
• The SiteMinder Session Server must be configured and enabled on all the Policy Servers. The Session Server requires a relational database (e.g. MS SQL) in which to store session information.
• The realm protecting the applications requiring the user’s security context must have Persistent Session enabled.

The session server stores a user’s encrypted credentials and associates the user with a session ID. When a SiteMinder session is established between a client and a Web Agent, the Windows user account is established and linked to the session.

Considerations:
There are several considerations to keep in mind when using SiteMinder to establish the Windows Security Context. These items may impact the ability to leverage SiteMinder functionality for this purpose.

The following items should be considered:

• The user must initially authenticate to a realm with Persistent Session enabled. This is required to establish the initial session for the user in the session server and to capture the user’s credentials. In an environment where a user can authenticate to multiple realms, each of those realms must have Persistent Session enabled. A user may be re-challenged when entering a realm with Persistent Session enabled if the initial authentication was to a non-persistent realm. However, it looks like SiteMinder is instead throwing an error in that scenario.
• The user must authenticate to Active Directory for the necessary information to be captured in the session store. When domains have a combination of multiple user directories of different types listed, the Active Directory user directory may need to be listed first to ensure that a user’s credentials do not match another directory prior to being authenticated to Active Directory. If that occurs SiteMinder will not be able to establish the user’s security context.
• Persistent Sessions introduce performance implications since the session must be validated against the session server. This can be minimized by setting the validation period on the session to a high value to reduce the number of times the session is checked. The validation period should be set less than the idle timeout value. Once a persistent session is established for a user, the users session is always validated against the session server regardless of if the realm being accessed has persistent session enabled. Using security zones for the Web Agents protecting applications requiring persistent sessions constrains the session validation to that zone only. This eliminates the need for other agents to validate the session with the session server.
• Environments with global implementations require either the session database to be replicated in real-time to each data center or for the Policy Servers to point back to a common session store across the network. If the Policy Server does not have the session server enabled or is pointed to a database that does not contain the user’s session, the user will be re-prompted for authentication. Pointing at a database across the network to a common session store eliminates that issue, but due to the latency and frequency of the calls to the session server this is not recommended.
• Only authentication schemes that leverage an ID and password can be used with SiteMinder’s capability to establish the Windows Security Context. The following authentication schemes are supported:
  • Basic Authentication Schemes
  • Basic Over SSL Authentication Schemes
  • HTML Forms Authentication Schemes
  • X.509 Client Certificate and Basic Authentication Schemes
  • X.509 Client Certificate and HTML Forms Authentication Schemes

Other Options:
Since third-party Web Access Management (WAM) systems are fairly prevalent, modern applications should support the capability to integrate with this type of system. This is usually done by trusting a header or token created by WAM system that contains the user’s identity. For SiteMinder the application should read the SM_USER header or allow the option to specify a header that contains the user’s identity. SiteMinder can then set the appropriate header using a response that ties the header to the specific identity attribute in the underlying user store.

In cases where that is not possible and the SiteMinder native capabilities to establish the security context do not meet the specified requirements, CA has a solution module called the “User Context Gateway” that can establish the security context for the user. The User Context Gateway (UCG) is used for three purposes:

• Establishing a Windows Security Context under IIS.
• Capturing a user’s sign-on password for later use.
• Maintaining and verifying a Windows password independent of the user’s sign-in (also known as “directory”) password.

UCG differs from SiteMinder native security in the following ways:

• All user directories that are writable to SiteMinder can be used by UCG. SiteMinder natively requires Active Directory as the user store.
• The session server is not required for UCG.
• All authentication schemes are supported by UCG. SiteMinder natively requires authentication schemes that leverage an ID and password.
• The user’s credentials are stored persistently in the user directory instead of being stored in the session store.
• While not recommended a user’s credentials can be made available to third-party applications. SiteMinder natively can only supply the user’s password to the first resource requested after authentication.

Since the User Context Gateway is a solutions module, there may be additional costs for this solution. Compatibility with the deployed version of SiteMinder should also be validated.

Configuring SiteMinder to Establish the Windows Security Context:

The following steps outline what is required to configure SiteMinder to establish the Windows Security Context for the user:

1. Create the session server database and run the relevant SQL scripts to create the tables, etc.
2. Define the ODBC data source for the session database.
3. Configure the session database on the Data tab of the Policy Server Management Console and enable the session server.
4. Enable the user directory containing the Windows users to run the security context by checking the “Use Authenticated User’s Security Context” check box on the Directory Setup group box on the User Directory pane.
5. Associate one of the authentication schemes defined in the Considerations section with each realm where a user can authentication in the resource group box of the Realm pane.
6. Enable persistent sessions for each realm and set a high Validation Enabled period with each realm where a user authenticates or the Windows Security Context is required in the session group box of the Realm pane.

Refer to the relevant SiteMinder documentation for details on how to perform these steps.

Overview:
SiteMinder provides federation capabilities for SAML (and other protocols). SiteMinder’s federation capabilities are accessed through a set of web services installed with the Web Agent Option Pack. The federation web service throws a 500 error instead of automatically redirecting the user for re-authentication like a standard SiteMinder Web Agent when the user has a valid SiteMinder session, but is not authorized to access the configured SAML Service Provider. This can be worked around in a couple of ways, but one way to handle this is to leverage the federation 500 error redirect to automatically redirect the user to a page which logs the user out and then redirects back to the federation URL.

The following is required for this configuration:

1. Custom redirect page that takes the federation POST variables and redirects the user back to the sent SPID. This page should be placed on a web server with an installed SiteMinder Web Agent.
2. Configure the redirect page as the logoff URI within the agent’s configuration object (ACO).
3. Set the custom error page as the Server Error URL in the Additional URL Configuration section on the Advanced tab of the SAML service provider configuration dialog.

Custom Redirect Page:
The custom redirect page can be an ASP, ASP.NET, JSP or any other dynamic page that can take POST parameters, parse them and redirect the user back to a URL. The following ASP code is an example of a page that takes the information from SiteMinder and redirects the user back to the federation URL:

<%
Dim relaystate, spid, fedurl, redirecturl
relaystate=Request.Form("RelayState")
spid=Request.Form("SPID")
fedurl="https://saml.company.com/affwebservices/public/saml2sso"

if relaystate = "" Then
 redirecturl=fedurl+"?SPID="+spid
Else
 redirecturl=fedurl+"?SPID="+spid+"&RelayState="+Server.URLEncode(relaystate)
End If
%>

<html>
<head>
<title>Redirect Page</title>
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Expires" CONTENT="-1">
</head>
<body>
<% Response.Redirect(redirecturl) %>
</body>
</html>

To use this code, set the fedurl variable to the base federation URL for the environment. The page should then be dropped on a server with a SiteMinder Web Agent in an unprotected folder. For example in a folder like:

<WWW root>\redirect\logoffredirect.asp  (is the file was an ASP named logoffredirect.asp)

where <WWW root> is the base document folder for the web server site.

Configure the Page as the LogoffUri Agent Parameter:
Setting the custom redirect page as the logoffUri for SiteMinder ensures that the SiteMinder session is ended so that when the user is redirected page to the federation URL they will then be prompted to log in again. In the example above, the URI for the page is /redirect/logoffredirect.asp. To add this:

1. Open the Agent Config Oject (ACO) for the Web Agent  installed on the server with the custom redirect page.
2. Uncomment the LogoffUri parameter and add the URI (not URL) for the custom redirect page.
3. Save the ACO.

The configuration change will be automatically picked up be the agent. In this example, the ACO looks like the following image:

Set the Server Error URL:
Once the custom error page is deployed and configured as the LogoffUri, the next steps is to tell SiteMinder to redirect to this page when the user would normally receive a 500 error from the federation web service. While we are using to redirect the 500 error thrown when a user is not authorized, this has the side effect of sending all 500 errors to the redirect page. This may or may not be an issue in your environment. To configure the Server Error URL:

1. Open the SiteMinder FSS Administrative UI.
2. Click on the Domains tab.
3. Open the federation domain.
4. Click on the SAML Service Providers left-nav item.
5. Open the Service Provider configuration.
6. Click on the Advanced tab.
7. Click the [Custom Error URL Config] button.
8. Check the Enable Server Error URL checkbox.
9. Enter the URL for the custom redirect page (e.g. https://saml.com.com/redirect/logoffredirect.asp).
10. Change the drop-down to Http Post.
11. Save the configuration.

Setting the drop-down to Http Post is required so that the necessary information is sent to the redirect page. This allows the redirect page to redirect the user back to the correct Service Provider configuration. Making the redirect page dynamic ensures that a common redirect page can be used for multiple Service Provider configurations.

• smpolicysrv -publish <name of XML file>
• smpolicysrv -stats

where <name of XML file> is the file where you want to export the Policy Server statistics.

The publish command kicks out the following data:

• Policy Servers
• Policy/Key Stores
• User Directories
• Agents
• Custom Modules

while the stats command exports a subset of that data into the smps.log file.

The Policy Server Administration Guide contains the following details:

Note: On Windows systems, do not run the smpolicysrv command from a remote desktop or Terminal Services window. The smpolicysrv command depends on inter-process communications that do not work if you run the smpolicysrv process from a remote desktop or Terminal Services window

Important! Before running a SiteMinder utility or executable on Windows Server 2008, open the command line window with administrator permissions. Open the command line window this way, even if your account has administrator privileges. For more information, see the release notes for your SiteMinder component.

However, this does not seem to work.  Since the Policy Server service by default is running as System, you get the message “The specified server is not currently running” when trying to run the command.  You can start the service as a different user, but that was not the direction I wanted to take.  So, the next step was to try and get a CMD window which was running as System so that I could execute the command.  After trying various methods (runas, using “at” to launch a CMD window, etc.) those failed to produce the result I need.  Changes in Windows 2008 prevented some of the hacks that worked in previous versions of the OS.

The answer was to use psexec from Sysinternals (now Microsoft) which allows you to run things from the command line as system. The tool is part of the PsTools suite at the following URL:

http://technet.microsoft.com/en-us/sysinternals/bb896649

Once psexec was installed in a directory in the Windows PATH, I completed the following steps to publish the Policy Server statistics:

1. Open regedit and set the HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\SiteMinder\CurrentVersion\Publish key to the file location and name for the XML file
2. Open a CMD prompt (I used the one is C:\Windows\SysWOW64\cmd.exe (right-click and select Run as administrator)
3. Enter the following command: psexec -s “<SiteMinder Home>\bin\smpolicysrv” “-publish”

where <SiteMinder Home> is the install location of the Policy Server.  You will now get the published XML file at the location and name specified in step 1 above.

Need one good reason to join the CoreBlox team? How about these polo shirts?!

You may have already noticed the shiny new updates to our Jobs page, but just in case you missed it: we’re hiring! We’re finding that the number of project opportunities in the Identity & Access Management space continues to grow at a rapid pace, and we’d like to be able to staff more of these engagements while continuing to provide excellent service to clients we’ve already worked with. CoreBlox has primarily focused on SiteMinder and Radiant Logic since we launched the company in 2005, but we’re looking to diversify our product knowledge base by finding folks with experience in CA Identity Manager, CA Role & Compliance Manager, CA Access Control, and other related technologies. We need folks who can handle responsibilities ranging from architecture and scoping all the way through to deployment and support.

Our standards are high but the work and rewards are compelling. If you’re interested, please contact us and tell us why you think you’re a good fit!

The key to determining the best approach to migrate policies is to have a plan from the start. This way you can set up the proper path to move policies through the environment without having to (mostly) manipulate the policies.  There are probably another 20 ways to do this that people have thought through, but this works for me.  If you know a better way, enlighten me in the comments section below (seriously, I want to know).

Migrating SiteMinder policies in r12 has a few limitations that should be kept in mind:

• Many of the new objects in r12 (e.g. EPM applications) cannot be migrated the way you did things in SiteMinder 6 (smobjexport, Perl CLI, Java API, etc.). They’re not exposed to those tools.
• You need to have a user with the correct rights set up in SiteMinder.
• Certain items (e.g. redirect URLs) may still need to be updated either manually or by modifying the import file.
• Global policies/rules/responses don’t seem easy to move using this approach. So, unless you can figure it out, it may be easier not to use them.

So, what are the tools to make this happen?  There are three:

• XPSExplorer: Interactive command-line utility that allows an administrator or application developer to view the data in a policy store.
• XPSExport: Tool for extracting policy data from SiteMinder in an XML-based format.
• XPSImport: Tool for taking a file extracted by XPSExport and importing it into another policy store.

You are also going to need to become familiar with the term, “XCart,” which is how you specifically define which objects you want to move between the tiers.  In this example I’m going to leave out the complexities around import modes, etc., because the approach is what I think is most important here.

So, how do you get this process going? First, some terminology:

• Source: The system where you develop all policies and are trying to take those policies and move them into another tier
• Target: The system(s) where you are trying to take polices from another tier and move thing into the local policy store.

So, in my example, Dev is the source and QA is the target.

The key is to always migrate from the source environment into the target tiers and to never manually create objects in those targets. That way your objects will be correctly linked based upon the unique ID of the object being migrated. This is the key because once you don’t have that link, you’re stuck trying to manually manipulate the files to fix the relationships between the objects. You can modify them, though, since the ID of the object stays the same. So, once the objects have be migrated, go in and adjust the URL’s, etc., as needed.

Here is the approach:

1. Create your base objects your Dev environment. These objects would be things like: Agents; Agent Groups; User Directories; Authentication Schemes; SQL Query Schemes; Auth/Az Mappings; AuthValidate; Mappings and Certificate Mappings.  Hosts, Agent Config Objects and Host Config Objects don’t need to be migrated since those are not linked directly to policies.
2. Export the objects created in step #1. This gives you all the objects that you are going to link to when you migrate policies to these targets. You can keep this file in case you create new target systems down the road.
3. Import the base objects into each target tier. Don’t forget that system level objects like ODBC configurations will not be migrated and need to be created manually.
4. Modify the migrated objects so that they are relevant for that tier. So, this includes things like: User Directory IP address and credentials and Authentication Scheme URL’s.
5. Create your new policies and be sure to use the objects from step #1 when you need to associate the objects in step #1 with the policy. If a new base object is required, go ahead and create it and just follow the same steps to migrate it to the target tiers.
6. Export the policies created in step #5.

Now you can import these policies into any target system since all of the base objects are present and all of the links are there.

Here is a simple example that highlights the steps above. In this example I’m going to migrate my base objects (an Agent, User Directory and Authentication scheme) to QA. Then, I’m going to take a policy I created and migrate that as well.  So, let’s give this a shot.  First lets create the XCart for the base objects:

1. Log into the source policy server and open a command prompt.
2. Type: XPSExplorer
3. The XPSExplorer tool opens with its plethora of options
4. Enter 15 to export an agent
5. The Agent menu appears
6. Enter S to search the objects
7. This list of Agents appears
8. Enter the number of the Agent you want to export (I chose testagent).
9. The Agent details appear
10. Enter X to add it to the XCart
11. It’s hard to see that it actually did anything, but the X setting has now turned to remove from XCart instead of Add.
12. Enter Q three times
13. Enter 57 for User Directory
14. Enter S to search the list of directories
15. Enter the number of the User Directory (I chose RadiantOne)
16. Enter X to add it to the XCart
17. Enter Q three times
18. Enter 22 for Auth Schemes
19. Enter S to display the list of Auth Schemes (this includes all the defaults so you may want to filter this list)
20. Enter the number of the Auth Schem (I chose Form Scheme)
21. Enter X to add it to the XCart
22. Enter Q three times
23. Now that we have the objects, we need to save the XCart
24. Enter X to enter XCart Management
25. Enter N to save cart file as new name
26. At the “Path to load” prompt (huh?) enter the name of XCart you want to use – I chose baseobjects.cart (In case you missed it, there was a message at the top of the screen that says the file was saved)
27. Enter Q to leave the XCart Management tool and Q again to exit XPSExplorer

Now we need to export those objects:

1. Type: XPSExport <the name of the file you want to create> -xf <name of the XCart> (so, I entered: XPSExport baseobjects.xml –xf bassobjects.cart)
2. Enter a passphrase if prompted.  The passphrase must contain 1 uppercase letter, 1 lowercase letter and 1 number and must be 8 characters long.
3. The tool spits out the ID’s of the objects it exported

You now have the base objects to move into the target tier.  So, copy the file over and then we’ll run XPSImport to create them.  Here are the steps.

1. Log into the target Policy Server and open a command prompt (you’ve already copied over the file, right?)
2. Enter the command: XPSImport <file name> (so, I entered: XPSImport baseobjects.xml)
3. Enter your passphrase if prompted
4. The tool exits

Now go about creating your Applications and/or Domains.  For this, I have created an Application called “Test App.” Select the base objects created above when creating this application.

Once that is done, we can walk through the same steps we used to export the base objects. However, now select the new application when you use XPSExport from the source system.  You can create a new XCart or since in this case I am just exporting a single Application and an Application is an object that can be granularly exported, I’m just going to export it directly.  You still use XPSExplorer to get the ID of the object.  So, I entered the following command to export my Application:

XPSExport testapp.xml -xo CA.SM::Domain@03-66822cfa-b8c5-4620-9834-e3e45edf162d

Once you copy over the file, now run XPSImport to import the new Application into the QA tier:

XPSImport testapp.xml

That’s it. You now have everything you need to set up a clean migration path between SiteMinder tiers. You can use this approach as the basis for migrating other objects. To move multiple Applications and/or Domains (or any other objects), use XPSExplorer to create a new cart of the objects and use that as the cart for the export file. Since the base objects are all there, everything will link up and import as planned.

Overview
This post cover details on how to configure SiteMinder’s SNMP services on Red Hat 5.  The SiteMinder SNMP module enables many operational aspects of the SiteMinder environment to be monitored by SNMP-compliant network management applications. The SiteMinder SNMP module provides SNMP request handling and configurable event trapping for the SiteMinder environment. It does this by collecting operational data from the SiteMinder OneView Monitor and making it available in a MIB to third-party Network Management Systems applications (NMS) that support the SNMP protocol.

The SiteMinder SNMP module consists of:

• SiteMinder SNMP MIB is the database of SiteMinder objects that can be monitored by an SNMP-compliant network management system.
• A SiteMinder SNMP Subagent responds to SNMP requests (GET and GETNEXT only) passed to it from an SNMP master agent.
• SiteMinder Event Manager captures Policy Server events and, if configured to do so, generates SNMP traps (unsolicited messages sent by an SNMP agent to a SNMP NMS indicating that some event has occurred).

The SNMP support is dependent on OneView monitor being installed and configured on the Policy Server and also requires a Master SNMP Agent at the Operating System level.

The following figure illustrates SNMP module dataflow:

SiteMinder SNMP Dataflow:

1. The SNMP Master Agent receives SNMP requests from a management application.
2. The SNMP Master Agent forwards the SNMP request to the SNMP Subagent.
3. The SiteMinder SNMP Subagent retrieves the requested information from OneView Monitor.
4. The SiteMinder SNMP Subagent passes the retrieved information back to the SNMP Master Agent.
5. The SNMP Master Agent generates an SNMP response and sends it back to the requesting management application.

The SiteMinder MIB provides an SNMPv2-compliant data representation of all monitored components in the SiteMinder environment.  The SiteMinder MIB is supplied in an ASCII text file and should be sent to the monitoring team for interpreting the SNMP information from the Policy Server.  The MIB is located at:

<SiteMinder Home Directory>/mibs/NetegritySNMP.mib

Refer to the Policy Server Administration Guide for details on all the SNMP information provided by SiteMinder.

SNMP Base Configuration

While SNMP support can be configured manually, the Policy Server Configuration Wizard will be used to enable SNMP support.  By default port 161 and 8001 must be open on the box for the SNMP Master and Sub-agent.  This post assumes that you can the ability to become root on the server.

To configure SNMP:

1. Log in to the Policy Server using ssh
2. Become root: >sudo su – root
3. Source the ca_ps_env: >source <SiteMinder Home Directory>/ca_ps_env.ksh
4. Run the Policy Server Configuration Wizard: ><SiteMinder Home Directory>/ca-ps-config.sh -i console
5. When the wizard loads select 3 to configure SNMP support
6. Review the Pre-Configuration Summary and Press <Enter> to continue (I have installed to /opt/SiteMinder)
7. The wizard configures SNMP support for the Policy Server
8. At the SNMP Configured message press <Enter> to accept the message
9. At the Installation Complete message press <Enter> to exit the installers

The base components for SNMP support have now been configured.  The SNMP Master Agent, SNMP Sub-Agent and Policy Server must be restarted after the configuration is completed.  See below for details on stopping and starting the SNMP Master and Sub-Agent.  The Master SNMP Agent must be restarted as root.  The Sub-Agent can also be started as root.  The Policy Server should be stopped/started as the SiteMinder user.

SNMP Agent Configuration

Once the Policy Server Configuration Wizard completes the SNMP configuration, the server should be set up with the values specific to your implementation.  The wizard configured the SiteMinder SNMP files at <SiteMinder Home Directory>/etc/snmp/conf and modified the snmpd.conf system file at /etc/snmp to include the line:

proxy -c public -v 1 localhost:8001 .1.3.6.1.4.1.2552

To change the SNMP community string to something besides public:

1. Log into the Policy Server through ssh
2. Become root: sudo su – root
3. Edit the snmpd.conf file: vi /etc/snmp/snmpd.conf
4. Go to the end of the file
5. Edit the “-c” parameter to change the value from “public” to the desired community string
6. Save the file

The SNMP sub-agent uses port 8001 to listen for SNMP requests.  To change the local port that the SiteMinder SNMP sub-agent is using:

1. Log into the Policy Server through ssh
2. Become root: sudo su – root
3. Edit the SiteMinder RunSubagent.sh file at: >vi <SiteMinder Home Directory>/etc/snmp/conf/RunSubagent.sh
4. Change the following line to the desired port: AGENTPORT=8001
5. Save the file
6. Edit the snmpd.conf file: >vi /etc/snmp/snmpd.conf
7. Go to the end of the file
8. Edit the “localhost:8001” parameter to the port specified in step 4 above
9. Save the file

The SNMP Master and Sub-Agent must be restarted for these changes to take effect.

SNMP Trap Configuration
SiteMinder can send SNMP Traps (alerts) when certain events happen on the Policy Server. These traps are received by the configured NMS and processed according to the rules configured within that system. The following traps can be generated:

Event Name

• serverInit
• serverUp
• serverDown
• serverInitFail
• dbConnectionFailed
• ldapConnection-Failed
• logFileOpenFail
• agentConnection-Failed
• authReject
• validateReject
• azReject
• adminReject
• objectLoginReject
• objectFailedLogin AttemptsCount
• emsLoginFailed
• emsAuthFailed

Enabling SNMP Traps is broken down into three steps:

1. Enable SNMP event trapping
2. Configure the SNMP Trap Config file
3. Restart the Policy Server

Enable SNMP Event Trapping
The XPSConfig utility is used to enable the SNMP trap event handler.  The library, libeventsnmp.so, is used to generate SNMP traps.  The library is located at:

<SiteMinder Home Directory>/lib

The library needs to be added to the XPSAudit list. Use the following steps to add the event handler:

1. Log into the Policy Server through ssh
2. Become the SiteMinder user
3. Enter the following command: >XPSConfig
4. The XPS Configuration utility starts
5. At the Products menu enter: XPS
6. Press <Enter>
7. Enter 5 for the AuditSMHandlers option and press <Enter>
8. The Audit Handler option menu appears
9. Enter the following option to add the SNMP Trap library: C
10. Press <Enter>
11. Enter the following path to the SNMP Trap library (if there is an existing value keep, enter the existing value again and enter a comma before adding the SNMP Trap library): <SiteMinder Home Directory>/lib/libeventsnmp.so
12. Press <Enter>
13. The settings for the event handler libraries appear. The value you added is shown at the bottom of the settings as a “pending value.”
14. Enter the Option: Q
15. Enter the Option: Q
16. Quit XPSConfig by entering: Q

Your changes are saved and the command prompt appears.

Configure the SNMP Trap Config File
You configure the SiteMinder SNMP Trap Event Manager by defining the event in the Event Configuration File, <SiteMinder Home Directory>/config/snmptrap.conf, which defines what events are to be processed and the addresses of the Network Management System to which the traps should be sent.

The snmptrap.conf is an editable ASCII file, with a simple one line per event syntax:

Event Name               Destination Address             Community String

Event_Name: The name of a MIB event object (or a comma-separated group of names of event objects).

Destination_Address: The address of the Network Management System (or a comma-separated group of the addresses) to which generated traps should be sent. Each address should be of the form:

HostID:port

HostID (mandatory): Either a hostname or IP address

Port (optional): IP port number (default is 162)

Community String (optional): An SNMP community. Note that if community is specified, Port must also be specified.  The default value is public.

To configure the snmptrap.conf file:

1. Log in to the Policy Server using ssh
2. Switch to the SiteMinder user
3. Edit the SNMP Trap Config file: >vi <SiteMinder Home Directory>/config/snmptrap.conf
4. Uncomment the lines for any desired traps
5. Specify the IP Address, port number, and community for where you want the trap to be sent
6. Save the snmptrap.conf file
7. Restart the Policy Server

Stopping and Starting the SNMP Master and Sub-Agent
In order for the SNMP configurations changes to take effect, you need to stop and restart the Policy Server using the Status tab of the Policy Server Management Console.  Additionally, the SNMP Master and Sub-Agents should be restarted when there are changes to the SNMP configuration.  The server start-up scripts should be modified to automatically start the Master and Sub-Agent.

Stopping and Starting the SNMP Master Agent
To stop the SNMP Master Agent:

1. Log in to the Policy Server using ssh
2. Switch to root:  sudo su – root
3. Go to the /etc/init.d directory: >cd /etc/init.d
4. Type the command: >./snmpd stop
5. The following message is resturn: Stopping snmpd:                                            [  OK  ]

The Master Agent stops.

To start the SNMP Master Agent:

1. Log in to the Policy Server using ssh
2. Switch to root:  sudo su – root
3. Go to the /etc/init.d directory: >cd /etc/init.d
4. Type the command: >./snmpd start
5. The following message is resturn: Starting snmpd:                                            [  OK  ]

The Master Agent starts.

Stopping and Starting the SiteMinder SNMP Sub-Agent
To stop the SiteMinder SNMP Sub-Agent:

1. Log in to the Policy Server using ssh
2. Become root: >sudo su – root
3. Source the ca_ps_env: >source <SiteMinder Home Directory>/ca_ps_env.ksh
4. Change to the SiteMinder snmp directory: >cd <SiteMinder Home Directory>/etc/snmp/conf
5. Type the following command: >./StopSubagent.sh

The SiteMinder SNMP Sub-Agent stops.

To start the SiteMinder SNMP Sub-Agent:

1. Log in to the Policy Server using ssh
2. Become root: >sudo su – root
3. Source the ca_ps_env: >source <SiteMinder Home Directory>/ca_ps_env.ksh
4. Change to the SiteMinder snmp directory: >cd <SiteMinder Home Directory>/etc/snmp/conf
5. Type the following command: >./RunSubagent.sh &

The SiteMinder SNMP Sub-Agent starts

Crown Point, IN (PRWEB) June 30, 2011

IdentityLogix and CoreBlox today announce a partnership to provide on-premise and cloud based continuous security monitoring and real-time actualization for Radiant Logic and CA SiteMinder sites. CoreBlox will provide private and public entities who utilize CA SiteMinder R6 & R12, along with SiteMinder enabled applications, such as CA Federation Security Services, SOA Manager, and Federation Manager and/or Radiant Logic RadiantOne Virtual Directory (VDS) and Identity Correlation and Synchronization Server (ICS) technologies, the visibility to proactively perform security analysis and rapid troubleshooting. The combination of CoreBlox expertise and SpyLogix™ software platform will allow organizations to enhance information security while reducing costs and support complexity.

“We are excited to partner with CoreBlox, a trusted service provider for CA and Radiant Logic identity and access technologies, as we work to provide a level of real-time access and visibility that was not previously available,” says V. Michael Hrobat, Vice-President of Sales and Marketing for IdentityLogix. “We believe that CoreBlox providing both on-premise and cloud based solutions will give organizations business flexibility, while at the same time raising the quality level within corporations as plans are formulated to have continuous analytical monitoring of identity security and activity across the enterprise.”

“The SpyLogix™ software platform is an exceptional fit for any CA or Radiant Logic customer that seeks to discover and resolve security infrastructure issues before they become a larger problem for the user base,” says Chad Northrup, Vice President of Client Services for CoreBlox. “This technology offering is a natural extension of our services capabilities, and it provides the real-time intelligence we need to scale our support offerings in the cloud.”

CoreBlox provides Identity & Access management consulting services and dedicated support offerings for CA SiteMinder, Radiant Logic VDS/ICS, and a number of related products. The SpyLogix security middleware software now provides users of SiteMinder and RadiantONE VDS/ICS an efficient conduit for finding that “needle in the haystack” for issue resolution, proactive identity analysis and access to security data on demand for IT GRC enablement.

The end result is that SpyLogix middleware technology combined with CoreBlox’ technical expertise will enhance the efficiency and effectiveness for information security governance, risk control, and administrative troubleshooting being conducted within an organization. Organizations achieve business outcomes of enhanced security and reduced staff burden, which results in improved productivity and cost savings.

About IdentityLogix
IdentityLogix is an innovator in providing software for information security intelligence, data actualization, identity assurance, enablement of information technology governance, risk, and compliance (IT GRC) initiatives for both public and private entities. SpyLogix Enterprise software protects business information assets from multi-faceted cyber threats by continuously monitoring end-users, networks, identity systems, and multi-platform application systems in real-time. Identity assurance solutions leverage biometrics for verifying users strongly to enhance self-service password reset and identity verification. For more information please visit http://www.identitylogix.com.

About CoreBlox
CoreBlox is a leading provider of enterprise security services. Headquartered in Framingham, MA, the CoreBlox team specializes in single sign-on (SSO) and web access management solutions, SAML and identity federation services, and LDAP Directory Virtualization, with broad experience managing, executing and supporting Identity Management deployments. CoreBlox’ commitment to service excellence has won successful clients across the Fortune 500 and in a number of key verticals including Banking, Information Technology, Insurance, Telecommunications, and the Public Sector. For more information, please visit http://www.coreblox.com.

• The SAML 2.0 Debugger lets you decode a SAML message encoded with the HTTP-POST or HTTP-REDIRECT encoding
• The Base64 Decoder allows you to decode Base64-encoded text strings
• The URL Encoder/Decoder let you take strings and either URL encode or decode them
• The Online XML Digital Signature Verifier allows you to verify the signature on SAML assertions

Update - This was also brought to my attention: SAML Tracer for Firefox

Since this also comes up, here are the steps I use to create a self-signed certificate with OpenSSL for use with SiteMinder for Federation. The certificate can be used to sign SAML assertions during testing (or I cheat sometimes and using it in production since I can create a certificate with an extended expiration date). I am not an OpenSSL expert, but these steps seem to do the trick (be sure to substitute your desired values):

Generate Private Key and Cert:

> openssl req -x509 -days 3650 -newkey rsa:1024 -keyout saml_key.pem -out saml_cert.pem

Enter PEM Passphrase:  password
Verify Passphrase:  password
Country:  US
State:  Massachusetts
Locality:  Framingham
Organization Name: CoreBlox
Organizational Unit Name: SiteMinder Team
Common Name: ps.coreblox.com
Email Address: siteminder@coreblox.com

Convert Private Key PCKS8 DER Encoding:

> openssl pkcs8 -topk8 -inform PEM -outform DER -in saml_key.pem -out saml_key.pkcs8

Enter Passphrase:  password
Enter Encryption Password:  password
Verify Encryption Password: password

Create SiteMinder Key Database (if you haven’t done this already):

> smkeytool.bat -createDB -password password -importDefaultCACerts

Import Certs into Key Database:

> smkeytool.bat -addPrivKey -alias defaultEnterprisePrivateKey  -certfile saml_cert.pem -keyfile saml_key.pkcs8 -password password

Validate certs imported correcly:

> smkeytool.bat -listCerts -alias defaultEnterprisePrivateKey

I hope this is helpful.  If you have any tricks or sites you use, please post them in the comments.

• CA Solutions for Secure Web Business Enablement
• Jim Thorstad Covers the New SiteMinder Agent for IIS
• Radiant Logic Webinar – Evolve Your SiteMinder Portal Through Virtualization (Note: contains shameless self-promotion)
• Using ArcotOTP

Have you come across any other useful videos?  If so, post the links in the comments below.