Skip navigation
All Places > CA Security > CA Single Sign-On > Blog > Authors Ujwol Shrestha
1 2 3 Previous Next

CA Single Sign-On

112 Posts authored by: Ujwol Shrestha Employee
USE CASE

How can we save custom data into session store during user authentication and access it later during authorization

The custom data could be an additional user input captured during user login or via some external web service call during custom authentication.

CHALLENGE:

Data couldn’t be saved into a session store during the authentication process (say inside a custom authentication class ) because at this stage even if the Session ID is created for the user session an entry is not created in the session store.

Otherwise a simplistic solution would have been to invoke  com.netegrity.policyserver.smapi.SmSessionServer.setVariable() API from within the custom authentication class.

SOLUTION :
  • Temporarily save the custom data into the AppSpecificContext element of the APIContext from the custom authentication scheme.
  • Create an ActiveResponse to read the custom data from the AppSpecificContext.
  • Create a Response attribute of type “WebAgent-OnAuthAccept-Session-Variable”  and assign the value returned from an ActiveResponse above.
  • Create an OnAuthAccept rule and attach the Response attribute created above.
  • Create a Response to read the data from Session Store and attach it to OnAccessAccept rule to set it as HTTP header variable.
INSTRUCTION :
  • Modify the attached custom authentication scheme class (CustomAuthSetAppSpecificContextData.java) as required to the save the desired custom data into the AppSpecificContext element as below.
1
2
3
4
5
6
7
//Set AppSpecific Context Data here. This could be a data read from external web service call or user provided input variable
try
{
APIContext apiContext = context.getAPIContext();
AppSpecificContext appContext = apiContext.getAppSpecificContext();
appContext.setData(new String("Test App Sepcific Context Data").getBytes());
}
  • (Optional ) Modify the attached custom ActiveResponse class (ReadAppSpecificContextVar.java) for any additional logic (if needed). Here is the code snippet where it reads the data from AppSpecificContext and return to the caller :
1
2
3
4
5
6
7
8
9
10
11
12
// Check if the app specific data is set
try
{
APIContext apiContext = context.getAPIContext();
AppSpecificContext appContext = apiContext.getAppSpecificContext();
byte[] data = appContext.getData();
if (data != null)
{
logInPSTrace(apiContext, "Context Data : " + new String(data));
return new String(data);
}
}
  • Create a custom authentication scheme as below :
    • Library : smjavaapi
    • Secret : Any string value
    • Confirm secret : Any string value
    • Parameter : <Custom auth classname> <custom login page>

custom authentication scheme

  • Create a Response attribute of type “WebAgent-OnAuthAccept-Session-Variable”  and assign the value returned from an ActiveResponse as below. This will be triggered during OnAuthAccept event to set the custom data into the session store.

Set Session Var Response

  • Create a Response attribute of type “WebAgent-HTTP-Header-Variable”  and assign the value read from Session Store (set earlier) as below. This will be triggered during OnAcccess event.

Response to read session var

  • Change realm to persistent, change the Authentication scheme to custom & create OnAuthAccept, OnAccessAccept rules as below :

Realm

  • Link OnAuthAccept rule and the corresponding Response to create to set custom data in session store.OnAuthAccept_policy
  • Link OnAccessAccept  rule and the corresponding Response to read the data from session store and set it as HTTP header variable OnAccessAccept_Policy
  • Compile both the custom class and deploy them to <PS_Install_directory>siteminder\config\properties
  • Restart Policy server
TEST :

PrintHeaders

ATTACHMENT :
  • Custom Auth scheme.
  • Custom Active Response.
  • Sample index.asp to print all HTTP headers.
  • SetSessionVar
INSTRUCTIONS:
  • Create a Variable of type ResourceContext as below. This stores the last accessed resource URL.Variable-ResourceContext
  • Create Response with the following two attribute :

WebAgent-OnReject-Redirect = URL where you would like the user to be redirected after Authorization Reject.

WebAgent-OnReject-Text = Configure this to read the value of the Variable created earlier. This will create a SMTEXTcookie response which will have the value of the Resource URL.

OnAccesRejectRedirect_Response

OnRejectText

OnRejectRedirect_ResponseAttribute

  • Create OnAccessReject rule for the root resource.OnAccessReject_Rule
  • Associate the OnAccessReject rule with the Response created above. OnAccessRejectPolicy_UsersOnAccessRejectPolicy_Rule
  • Configure the AZ redirect page to read the value from SMTEXT cookie :

(Below sample use class ASP )

1
2
3
4
5
6
7
8
9
10
11
12
<table border="1">
<h1 style="color:red;"> You are not authorized to access resource : <%=Request.Cookies("SMTEXT")%> </h1>
 
<%
for each x in Request.ServerVariables
response.write(x & " = " & Request.ServerVariables(x) & "<br />")
next
%>
 
</table>
</body></p>
<p style="padding-left: 30px;">

TESTING:

  1. Access resource which the user is not authroized for.AzReject
  2. Sample fiddler : 
  3. Sample fiddler + accessdenied.asp : 
USE CASE :
  • If the value of the userattribute “businessCategory” is YES, redirect the user to “/home/manager.html ” after authentication.
  • If the value of the userattribute “buesinessCategory” is not YES, redirect the user to “/home/engineer.html” after authentication.
INSTRUCTIONS :
  • Create Realm for /home/ with the following three Rules :
    • OnAuthAccept_Manager
    • OnAuthAccept_Engineer
    • GetPostRealm_Home
  • Create a Variable “IsManager” of type UserContext and configure to read the user property “businessCategory”

Variable_IsManager

  • Create a Response  “ManagerHome” and add Response Attribute of type “WebAgent-OnAccept-Redirect” to redirect to static URL  “/home/manager.html”Response_ManagerHome
  • Create a Response  “EngineerHome” and add Response Attribute of type “WebAgent-OnAccept-Redirect” to redirect to static URL  “/home/engineer.html”Response_EngineerHome
  • Create a GetPost Policy to authorize all users access to “/home/*” GetPost_Home
  • Create an OnAuthAccept_Manager Policy which compares the value of the variable “IsManager” to be “Yes” and then redirects to the ManagerHome Response.OnAuthAccept_Manager_1OnAuthAccept_Manager_2
  • Create an OnAuthAccept_Engineer Policy which compares the value of the variable “IsManager” to be not equal to “Yes” and then redirects to the EngineerHome Response.OnAuthAccept_Engineer_1OnAuthAccept_Engineer_2

 

TESTING :
  • Login as a user with value of the userattribute businessCategory=YESManager_Fiddler
  • Login as a user with value of the userattribute businessCategory=NOEngineer_Fiddler

ISSUE:

 

Policy server crashes at startup after integrating with APM 13.1

ENVIRONMENT : 

  • CA SSO 12.7 SP2
  • CA AP SSO 13.1
  • OS : Linux

 

CAUSE:

The issue was due to incorrect order of static objects were allocated and released.

 

RESOLUTION:

This is a known defect. A hot fix is available for this . Please contact CA support.

CA Internal reference : DE353289 


Introduction

 

If you are using custom login page, you may want to restrict the user from acccessing the OOTB login.fcc URL

http://<FQDN>/siteminderagent/forms/login.fcc 

This blog will guide you on how to achieve this.

 

Environment

  • Policy Server : ANY
  • Web Agent : 12.5 and above

Instructions

It is not possible to completely restrict the access to login.fcc as it needs to be unprotected resource and also needed as the custom login page needs to post to this.


However, what you can do is modify the login.fcc such that it will have only the bare minimum required content enough for the POST request but not not enough for GET requests (direct access)

 

If you are using login.fcc ONLY for POST request then it is sufficient to have just the following content in it. (The error message is optional off-course)

<!-- SiteMinder Encoding=UTF-8; -->
@username=%USER%
@smretries=0

<b><font size="5" color="red">DO NOT USE THIS PAGE DIRECTLY !</font></b>

 

Please note : 

  • If ACO parameter localization=no, the default login.fcc used is : 

<webagent_install_directory>\samples\forms\login.fcc

  • If ACO parameter localization=yes, the default login.fcc used is : 

<webagent_install_directory>\samples\forms_<locale>\login_<locale>.fcc

e.g. for en-US locale it would be :

<webagent_install_directory>\samples\forms_en-US\login_en-US.fcc

 

TESTING:

1. Direct access : 

2. Custom login page still works :

Attached : Fiddler

 

Addtional References :

Custom Login Page 

Introduction

We often receive support cases about intermittent connectivity issues between web agent and policy servers.

Some of the symptoms of the connectivity issues between web agent and policy server are :

 

Web Agent log :

LLA: SiteMinder Agent Api function failed - 'Sm_AgentApi_AuthorizeEx' returned '-1'.

LLA: SiteMinder Agent Api function failed - 'Sm_AgentApi_AuthorizeEx' returned '-2'

LLA: SiteMinder Agent Api function failed - 'Sm_AgentApi_IsProtectedEx' returned '-1'.

 

As there could be multiple causes resulting in such connectivity issues , support needs comprehensive set of logs as discussed below to analyze such issues. 

Environment

  • Policy Server : ANY
  • Web Agent : ANY

Instructions

 

1) Web Agent

 

  • Enable Keep Alive (SM_ENABLE_TCP_KEEPALIVE=1)

How to verify if SM_ENABLE_TCP_KEEPALIVE is working? 

  • Enable Transport Layer Interface (TLI) Logging

When you want to examine the connections between the agent and the Policy Server, enable transport layer interface logging.

To enable TLI logging

Add the following environment variable to your web server.

Specify a directory and log file name for the value of the variable, as shown in the following example:

SM_TLI_LOG_FILE = directory_name/log_file_name.log

Verify that your agent is enabled.

Restart your web server.
TLI logging is enabled.

  • Enable network capture between webserver and Policy server.

Unix :

tcpdump -i <interface> -s 65535 - w <some-file>

Where "i" is the name of the active network interface
e.g
tcpdump -i eth0 -s 65535 -w networkacapture.pcap

Windows:

Capture network traffic using wireshark

Wireshark · Go Deep. 

 

  • Enable web agent trace log. Use following profiler 
components: WebAgent, AgentFramework, HTTPAgent, AgentFunc, Agent_Functions, Agent_Con_Manager, AgentAPI
data: Date, PreciseTime, Pid, Tid, TransactionID, AgentName, Resource, SrcFile, Function, User, Domain, Realm, DomainOID, IPAddr, IPPort, CertSerial, SubjectDN, IssuerDN, UserDN, SessionSpec, SessionID, Action, RealmOID, Message
  • Enable web agent logs.
  • Web server error and access logs
  • If windows , provide Event Viewer logs.

 

2) Policy Server

  • Enable Keep Alive (SM_ENABLE_TCP_KEEPALIVE=1)
  • Enable Policy server trace log using following profiler :
Login_Logout/Receive_Request, IsAuthorized, Tunnel_Service, JavaAPI, ODBC/Sql_Statement_Begin_End, ODBC/Connection_Management, ODBC/Sql_Errors, ODBC/Connection_Monitor, LDAP/Ldap_Call_Begin_End, LDAP/Connection_Management, LDAP/Ldap_Error_Messages
data: Date, PreciseTime, Time, Pid, Tid, SrcFile, Function, TransactionID, AgentName, Resource, User, Group, Realm, Domain, Directory, Policy, AgentType, Rule, ErrorValue, ReturnValue, ErrorString, IPAddr, IPPort, Result, Returns, CallDetail, Data, Message
version: 1.1
  • Enable network capture between Policy server and web server

Unix :

tcpdump -i <interface> -s 65535 - w <some-file>

Where "i" is the name of the active network interface
e.g 
tcpdump -i eth0 -s 65535 -w networkacapture.pcap

Windows:

Capture network traffic using wireshark

Wireshark · Go Deep. 

  • Configure to run following command at interval of 2-5 minutes using windows scheduler or chron job in unix. The stats are captured in smps.log :
    smpolicysrv -stats 

Issue

Mixed Policy servers environment where some agents points to r12.7(or any 64 bit version) Policy server, and other points to lower version of Policy server which are 32 bit (e.g. 12.52, 12.51 etc).

 

Observation:

  1. If the Agent Keys are rolled over from either 32 bit or 64 bit Policy server SSO fails betwen agents connected to 32 and 64 bit Policy server.
  2. If the Agent keys are rolled over from 64 bit Policy servers, 32 bit Policy server logs following error in smps.log 

 

(38855) [06/05/2017][14:55:24][5516][][DoManagement.cpp:288][][][][][][][][][][][][][LogMessage:ERROR:[sm-Server-04060] An agent change key command was received that contained a set of null keys]  

Environment

Mixed Policy servers environment where some agents points to r12.7(or any 64 bit version) Policy server, and other points to lower version of Policy server which are 32 bit (e.g. 12.52, 12.51 etc).

Cause

Whenever AgentKey rollover is done, all the keys are bundled into one array separated by sizeof(time_t) either 32 bit time_t or 64 bit time which depends on the bitness of the Policy server which rolls the agent keys. This information is stored in AgentCommand.

Now, while reading AgentCommand they need to be read using the matching time_t bit, or else the AgentCommand decryption will fail.

 

Workaround

  1. Specify the same matching static agent keys in both 64 & 32 bit Policy servers and restart Policy servers.
  2. Do not configure dynamic agent key or roll them manually while using mixed Policy server environment when the bitness of the Policy server being used are different.

 

Resolution

1.  Upgrade the 64 bit Policy server to at least Policy server version 12.7.01 or later.

2.  In 12.7.01 Policy server, perform one of the following steps:

Windows

Open regedit and navigate to the following location:

 

HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\SiteMinder\CurrentVersion\PolicyServer

UNIX

Navigate to the following location:

 

install_directory/siteminder/registry

Open the sm.registry file.

Add the following registry key:

 

BackwardCompatibleMode

Set the registry key value to 1.

Restart Policy Server.

3. Enable Dynamic Agent Key Generation or Perform Manual key rollover ONLY from 32 bit Policy server.

 

NOTE : If Policy Server 12.7.01 (or 64 bit Policy server) generates agent keys in a mixed environment, the agents connected to 32 bit Policy Servers cannot decrypt the new agent keys.

So, in such environment you must configure the 32 bit Policy servers to generate agent keys and enable backward compatibility for 64 bit policy server (the registry "BackwardCompatibleMode" is available only from 12.7.01

(This is a revised version of : Tech Tip : CA Single Sign-On :: Policy server :: STATS Command )

Question

Please clarify the information listed on running smpolicysrv -stats command.

Environment

Policy server : 12.52 SP1 CR6

Answer

Here is an example of the 'smpolicysrv -stats' which outputs the smps.log when run:

 

[3524/4640][Sun Sep 17 2017 23:49:55][CServer.cpp:4747][INFO][sm-Serveor-01990] ===================================================================================
[3524/4640][Sun Sep 17 2017 23:49:55][CServer.cpp:4748][INFO][sm-Server-02000] System Statistics
[3524/4640][Sun Sep 17 2017 23:49:55][CServer.cpp:4765][INFO][sm-Server-02020] Thread pool limit: 70
[3524/4640][Sun Sep 17 2017 23:49:55][CServer.cpp:4787][INFO][sm-Server-02030] Thread pool: Msgs=36630 Throughput=0.033/sec Response Time=209.441ms Wait Time In Queue=0.077ms Max HP Msg=2 Max NP Msg=1 Current Depth=0 Max Depth=2 Current High Depth=0 Current Norm Depth=0 Current Threads=8 Max Threads=8 Busy Threads=0
[3524/4640][Sun Sep 17 2017 23:49:55][CServer.cpp:4795][INFO][sm-Server-02040] Connections: Current=0 Max=23 Limit=256 Exceeded limit=0
[3524/4640][Sun Sep 17 2017 23:49:55][CServer.cpp:4798][INFO][sm-Server-01990] ===================================================================================

   

Note :

  • stats:  This switch produces current server runtime statistics such as thread pool limit, thread pool message, and the number of connections.
  • resetstats: This switch resets the current server runtime statistics without restarting the Policy Server. This switch resets the following counters

 

Stats Information

  • Msgs                       : This is the total number of requests that have been removed from the queue.
  • Throughput              : Average number of request processed per second (request/per second)
  • Response Time         : Average response times.
  • Wait Time In Queue  : Average time interval between Enqueue and Dequeue of the messages (request) from the queue
  • Max HP Msg             : Maximum number of High Priority messages on the queue since the last reset of stats
  • Max. NP Msg            : Maximum number of Normal Priority messages on the queue since the last reset of stats
  • Current Depth          : Number of messages in the queue at the time of executing -stats
  • Max Depth               : Maximum number of messages in the queue since the last rest of stats
  • Current High Depth   : Number of High Priority messages in the queue at the time of executing -stats
  • Current Norm Depth : Number of Normal Priority messages in the queue at the time of executing -stats
  • Current Threads       : Number of worker threads running at the time of executing -stats. This includes sum of busy and idle worker threads.
  • Max Threads            : Maximum number of worker thread at any time.
  • Busy Threads           : Number of worker threads actively processing request at the time of executing -stats

 

Deprecated stats information (available in older releases) : 

  • Waits: This is the number of times that a thread went to get a request from the queue to process, but had to wait for one to arrive.
  • Misses: This is the number of times that a thread went to get a request from the queue to process, had to wait for one to arrive, but none came in before the thread went back to sleep.

Connections

  • Current: current number of agent connections
  • Max: Maximum number of agent connections
  • Limit: Maximum allowable agent connections
  • Exceeded Limit: Number of times the connection limit was exceeded.

Exceeded limit notes if the maximum agent connection limit has been reached. If further agent connections are attempted (the connections attempted past the limit will be rejected.

 

Some relevant registry:

Some of these parameter can be configured by modifying the registry (windows registry or sm.registry file on unix)

32 bit : HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Netegrity\SiteMinder\CurrentVersion\PolicyServer\

64 bit : HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\SiteMinder\CurrentVersion\PolicyServer\

 

Thread Pool Initial Size

Specifies the minimum number of worker threads that Policy Server opens on startup.

Default: 8

 

Thread Pool Size

Specifies the maximum number of worker threads that can be opened.

Default: 20

 

Tcp Max Server Connections

Specifies the maximum number of allowable agent connections.

Default : 256

 

PriorityThreadCount

Number of High Priority Threads. (threads allocated to process high priority handshake messages)

Default : 5

Max : 20

A value less than five or greater than 20 disables the registry key.

  

Additional Information

Having a "Waits" value that is very close to the "Msgs" value coupled with a low  "Misses" value implies that there are enough threads to handle the incoming load, but there are not too many threads configured. A high "Misses" value would indicate that you may have too many threads configured.

 

A large "Msgs" value coupled with a low "Waits" value and a low "Misses" value would imply that you may need to increase the number of Worker Threads.

Summary:

In this guide, we will discuss about the steps performed during web agent initialization.

 

Then, we will also deep dive into some of the common agent initialization issues and discuss approaches to troubleshoot and resolve theses issues.

 

Environment:

  • Web Agent : 12.5 and above
  • OS : ANY 

 

For this tech tip , we will test on following platform :

  • Web agent version : 12.52 SP1 CR7
  • Web Server : Apache 2.2
  • Web Server OS : RHEL 6.5 64 bit

 

Web Agent Startup Process 

 

On the high level the web agent startup process happens in the following order :

 

  1. Read WebAgent.conf
  2. Locate the path to the SmHost.conf file from WebAgent.conf and read SmHost.conf
  3. Identify the following details from SmHost.conf :
    • Policy server IP ( this policy server is used only for the initial bootstrapping)
    • Shared Secret
    • Trusted Host Name (hostname)
    • Host configuration object (HCO)
      #agentname="<AgentName>, <IPAddress>"
      HostConfigFile="/opt/CA/webagent/config/SmHost.conf"
      AgentConfigObject="aco_rhel65"
      EnableWebAgent="YES"
      ServerPath="/etc/httpd/conf"
      #localconfigfile="/etc/httpd/conf/LocalConfig.conf"
      LoadPlugin="/opt/CA/webagent/bin/libHttpPlugin.so"
      #LoadPlugin="/opt/CA/webagent/bin/libSessionLinkerPlugin.so"
      #LoadPlugin="/opt/CA/webagent/bin/libAffiliate10Plugin.so"
      #LoadPlugin="/opt/CA/webagent/bin/libSAMLAffiliatePlugin.so"
      #LoadPlugin="/opt/CA/webagent/bin/libeTSSOPlugin.so"
      #LoadPlugin="/opt/CA/webagent/bin/libIntroscopePlugin.so"
      #LoadPlugin="/opt/CA/webagent/bin/libSAMLDataPlugin.so"
      #LoadPlugin="/opt/CA/webagent/bin/libOpenIDPlugin.so"
      #LoadPlugin="/opt/CA/webagent/bin/libDisambiguatePlugin.so"
      #LoadPlugin="/opt/CA/webagent/bin/libOAuthPlugin.so"
      #LoadPlugin="/opt/CA/webagent/bin/libCertSessionLinkerPlugin.so"
      AgentIdFile="/etc/httpd/conf/AgentId.dat"

      Figure : WebAgent.conf

      hostname="th-rhel65-4"
      sharedsecret="{RC2}ovOEr7teMKP9xpKisg157/t4T1tqGXwNT0SWGsfi1QnajkcDjumFEmF9kBbw1d2MZb8CGf2ueSfWkfKmZEWrYVeM3hZ/HRI1F2bh6v4lBQq9uqi0Lp2iIQJb0flOY2oUGLmDE/iZFDQt3ceo7aCij9YQY72YD2iLLtJTKJGlu6e2nJcMzGlf2roiNfd2MwMV"
      sharedsecrettime="0"
      enabledynamichco="NO"
      hostconfigobject="hco"
      #Add additional bootstrap policy servers here for fault tolerance.
      policyserver="shruj01-i1849.ca.com,44441,44441,44441"
      requesttimeout="60"
      cryptoprovider="ETPKI"
      fipsmode="COMPAT"

          Figure : SmHost.conf

  4. Establish Agent API connection with the Policy server listed in the SmHost.conf file. This includes 3 way handshake (more details below ).
  5. Read HCO (Host configuration object) from the policy server/policy store.
  6. Establish the Agent API connection with the primary policy server listed in the HCO ( this could be same or different from the bootstrap policy server as listed in SmHost.conf)
  7. Once the connection is established with the primary policy server listed in the HCO , read ACO (Agent configuration object as per the WebAgent.conf)
  8. Initialize agent log/trace file as per the ACO configuration.

 

Three way agent to policy server handshake

 

  1. Agent opens a TCP socket connection with the policy server.
  2. Agent sends a Hello message which includes following info among other details :
    • MD5 Hash of shared secret and trusted host name combined (stronger encryption is used if using FIPS only mode)
    • Trusted host name
  3. Policy server validates the shared secret based on the trusted host name passed. It may validate both current and previous shared secret from the policy store against the shared secret sent by agent. If the shared secret validation is successful , policy server sends Hello Reply message which consists of following info among other details :
    • Session Keys
    • New shared secret (optional - this is sent only if the agent currently doesn't have the current shared secret)
    • New shared secret generated time (optional)
  4. Agent sends Hello Confirm message encrypted with the Session Keys previously sent by Policy server.
  5. (Optional ) Agent updates the SmHost.conf file with the new shared secret.

 

                                             Figure : Three way agent to Policy server handshake

 

Web Agent Initialization Error Codes :

 

Code             Meaning                                   
00 00 00 00     Debug version of SiteMinder agent is running.                                   
01 00 00 00     Unable to determine SiteMinder agent configuration file path.                                   
02 00 00 00     Unable to open SiteMinder agent configuration file or file is corrupt.                                  
03 00 00 00     Unable to load SiteMinder host configuration object or host configuration file.                                  
04 00 00 00     Unable to load SiteMinder agent configuration object.                                  
05 00 00 00     Unable to load SiteMinder local agent configuration file or file is corrupt.(EG: Web Server user does not have permissions on the Web Agent repositories & files.)
06 00 00 00     SiteMinder agent has encountered initialization errors and is exiting.                                  
07 00 00 00     SiteMinder agent has encountered initialization errors and will not service requests.                                  
08 00 00 00     SiteMinder agent is not enabled.                                  
09 00 00 00     SiteMinder agent is enabled.                                  
10 00 00 00     DefaultUserName configured for agent cannot logon to the web server. Please provide a new user name or password through central agent configuration or in the local configuration file. The current user name configured is shown below.                                  
11 00 00 00     Secure credential cache has failed to start. The data is the error code. Please check the System events for problems with service startup.                                  
12 00 00 00     SiteMinder agent is running.                                  
13 00 00 00     There was an error allocating memory for the base configuration object.                                  
14 00 00 00     Sm_AgentApi_Init Failed.                                  
15 00 00 00     Failed to Start the LLAWP process.                                  
16 00 00 00     Resource cache failed to initialize.                                  
17 00 00 00     Session cache failed to initialize.                                  
18 00 00 00     Failed to send message to the LLAWP.                                  
19 00 00 00     Failed to initialize the message bus.                                  
20 00 00 00     Failed to initialize the log queue.                                  
21 00 00 00     Failed to initialize the configuration manager.                                  
22 00 00 00     Server already running.                                  
23 00 00 00     Unable to open file.                                  
24 00 00 00     Configuration file path:                                  
25 00 00 00     Failed to send close message to LLAWP.                                  
26 00 00 00     LogonUser failed for specified user shown below.                                  
27 00 00 00     Invalid character found in the server path variable. Make sure that alphanumeric values are used. the invalid character shown below.                                  
28 00 00 00     Message bus already initialized.                                  
29 00 00 00     PID Cache error.                                  
30 00 00 00     Resource cache re-initialized.                                  
31 00 00 00     Session cache re-initialized.                                  
32 00 00 00     Web-agent process is exiting...                                  
ff ff ff ff     unable to get the HostConfigurationObject from any Policy Server                                  

 

Basic troubleshooting:

 

  • On UNIX platform, ensure you have sourced the web agent environment script (ca_wa_env.sh) before starting the webserver.
    [root@rhl65 webagent]# pwd
    /opt/CA/webagent
    [root@rhl65 webagent]# source ./ca_wa_env.sh
    [root@rhl65 webagent]#

    On Windows, the web agent environment variable are set as system environment variable. Ensure that the user running the web server process has access to these system environment variables.

  • Ensure path to the host configuration file (HostConfigObject) is valid in WebAgent.conf. 
  • Ensure the name of the agent configuration object (AgentConfigObject) is valid in WebAgent.conf (This is case sensitive field and need to match against the name of the ACO in the policy store)
  • Ensure that the user under which web server process runs has write permission to SmHost.conf (This is optional requirement. This is required only if the shared secret rollover functionality is used. )
  • Ensure that either defaultagentname or the agentname ACO parameter must be set in the policy store.
  • Ensure that the policy server FQDN/IP is specified in SmHost.conf file. Also ensure that you can ping and resolve the DNS for the specified policy server from the web server host.
  • Ensure that a valid Policy server FQDN/IP is specified in Host configuration object in the policy store. Also ensure that you can ping and resolve the DNS for the specified policy server from the web server host.
  • If there are multiple policy server IP listed in SmHost.conf and HCO , it is usually best to start with just one policy server and comment the remaining servers out. This will help and ease the troubleshooting.
  • On Unix platform, if there are multiple web agent instance running on the same box, ensure that a unique ServerPath is specified for each instance. 
  • Ensure that you can telnet to the Policy server ports from web server
telnet <policyserverIP> <policy server ports>

Test connectivity to all the ports - accounting, authentication , authorization 

 

Advance troubleshooting:

 

Following logs will be required to be analyzed for advanced troubleshooting:

 

Linux :

  • web server error/startup log
  • policy server logs (smps.log) and trace log (smtracedefault.log)

At minimum use following profiler for policy server trace log :

components: AgentFunc, Server/Connection_Management, Server/Policy_Server_General, Tunnel_Service
data: Date, Time, Pid, Tid, TransactionID, SrcFile, Function, User, UserDN, Directory, SessionID, SessionSpec, ErrorValue, ErrorString, Realm, Resource, Action, Rule, Policy, Domain, Message, PreciseTime, ReturnValue, Group, AgentName, AgentType, ObjectClass, DomainOID, SearchKey, ObjectOID, Property, IPAddr, IPPort, AuthStatus, AuthReason, AuthScheme, CertSerial, SubjectDN, IssuerDN, CertDistPt, RealmOID, State, ClusterID, HandleCount, FreeHandleCount, BusyHandleCount, ResponseTime, Throughput, MaxThroughput, MinThroughput, Threshold, TransactionName, Data, HexadecimalData, Query, ActiveExpr, CallDetail, RequestIPAddr, Returns, Expression, Result, CacheHits, CacheSize, RefCount, ExecutionTime, Tenant
version: 1.1
  • strace log from the web server startup ( this will help to identify any issue related to file permission/library dependency/environment variable etc )

    strace -Ff -t -i -v -o strace.log -s 16384 <command to start web server>

    e.g.

strace -Ff -t -i -v -o strace.log -s 16384 apachectl start 
  • tcpdump from webserver

tcpdump -i <network interface> -s 65535 -w <some-file.pcap>
To find the available network interface, you can run following command : ifconfig

[root@rhel65_3 ~]# ifconfig
eth2      Link encap:Ethernet  HWaddr 00:50:56:21:B6:A8 
          inet addr:155.35.245.220  Bcast:155.35.245.255  Mask:255.255.255.0
          inet6 addr: fe80::250:56ff:fe21:b6a8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:432695 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3238 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:46333929 (44.1 MiB)  TX bytes:926017 (904.3 KiB)

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:31 errors:0 dropped:0 overruns:0 frame:0
          TX packets:31 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2012 (1.9 KiB)  TX bytes:2012 (1.9 KiB)

[root@rhel65_3 ~]#


then, run the tcpdump command as below :

[root@rhel65_1 Desktop]#  tcpdump -i eth2 -s 65535 -w watopsnetworkcapture.pcap
tcpdump: listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
^C244 packets captured
248 packets received by filter
0 packets dropped by kernel
[root@rhel65_1 Desktop]#
  • web agent logs & trace ( note : if there is an agent initialization issue, these logs will most likely not be created as they are created only at the end of init process, however it is good to get this configured just in case )At minimum enable following profiler for web agent trace :
    components:  AgentFramework, HTTPAgent, WebAgent, Agent_Con_Manager
    data: Date, Time, Pid, Tid, SrcFile, Function, ResponseTime, IPAddr, IPPort, AgentName, Resource, User, Threshold, Throughput, MinThroughput, MaxThroughput, HandleCount, BusyHandleCount, FreeHandleCount, State, ClusterID, Message

 

Solaris/AIX

All the logs from Linux except strace logs are applicable for Solaris/AIX based system.

The Linux's strace equivalent is truss in Solaris.

You can capture truss output from web server startup as below :

truss -a -e -f -D -l -o /tmp/truss.out -rall -wall <command to start webserver>

 

Windows:

  • For windows the equivalent of strace is process monitor logs (procmon.exe)

Process Monitor - Windows Sysinternals | Microsoft Docs 

  • TCPDump can also be replaced with the wireshark network capture.

Wireshark · Go Deep. 

  • Event Viewer would also be helpful.

 

Commons Issues :

Problem : Policy server smps.log shows following error :

[6512/7048][Tue Sep 05 2017 06:41:45][CServer.cpp:2035][ERROR][sm-Tunnel-00010] Bad security handshake attempt. Handshake error: 3154
[6512/7048][Tue Sep 05 2017 06:41:45][CServer.cpp:2046][ERROR][sm-Tunnel-00050] Handshake error: Shared secret incorrect for this client
[6512/7048][Tue Sep 05 2017 06:41:45][CServer.cpp:2207][ERROR][sm-Server-01070] Failed handshake with 155.35.245.220:50711

The web server log (Apache for our test) shows agent initialization errors:

[04/Sep/2017:23:41:45] [Error] SiteMinder Agent
Unable to load SiteMinder host configuration object or host configuration file.
/opt/CA/webagent/config/SmHost.conf
06 00 00 00
[04/Sep/2017:23:41:45] [Error] SiteMinder Agent
Failed to initialize the configuration manager.
LLAWP unable to get configuration, exiting.
nm: '/etc/httpd/bin/httpd': No such file

 

No Agent Log/Trace is created.

 

Cause :

If no changes has been done either in the policy server side or on the agent side since the last working state, then this error indicate a possible change in the hostid (for unix based system) on the web agent side.

 

On all non-Windows platforms, the agent code used to encrypt and decrypt the shared secret uses a key that is derived from a hard coded value (Web Agent Host Key) combined with the results of calling gethostid() on the platform in question. gethostid() is a standard C Library function that returns a 32-bit long value.

Different UNIX system implements this function differently. For e.g Linux, AIX and solaris , the system implementation for the gethostid() C library function is not the same.
As such, SiteMinder web agent might not be able to decrypt the shared secret generated in one UNIX system when moved to other system. Not only that, if the host ID of the same system changes (due to change in IP, hostname etc ) , the webagent will not be able to decrypt the shared secret which was originally generated on the same system.

 

Testing :

 

Set

  • hostname = rhel65_1.ca.com
  • IP =192.168.0.6 (in the hosts file)

hostid gives output as a8c00600

 

 

Agent initializes fine with the 3 way agent to PS handshake being successful

 

 

Now, change the IP address to 192.168.0.7 in the hosts file with everything else remaining the same.

This time hostid command gives a different result : a8c00700

 

 

3 way agent to PS handshake now fails with the following error in smps.log :

[6512/7048][Tue Sep 05 2017 06:41:45][CServer.cpp:2035][ERROR][sm-Tunnel-00010] Bad security handshake attempt. Handshake error: 3154
[6512/7048][Tue Sep 05 2017 06:41:45][CServer.cpp:2046][ERROR][sm-Tunnel-00050] Handshake error: Shared secret incorrect for this client
[6512/7048][Tue Sep 05 2017 06:41:45][CServer.cpp:2207][ERROR][sm-Server-01070] Failed handshake with 155.35.245.220:50711

 

 

Also, note in the network capture, the encrypted data in front of the trusted hostname is now different.

If the shared secret+trusted hostname+hostid combination is same, the encrypted data should remain same.

 

Resolution :

As we saw above, a simple change in the IP address resulted in the change in the hostid in RHEL system. This in turn invalidated the shared secret stored in SmHost.conf. There could be more factor contributing to the change in the hostid which is dependent on the platform being used.

 

The only way to fix this issue is by re-registering the trusted host or reverting to the previous hostid( reverting to previous IP address in this case).

 

smreghost -i <policyserver_ip>:44441,44442,44443 -u "siteminder" -p <siteminder super user password> -hn <trustedhost> -hc  <hco> -cf COMPAT -f <Path_To_SmHost.conf> -o

e.g

 

[root@rhl65 bin]# pwd
/opt/CA/webagent/bin
[root@rhl65 bin]# smreghost -i shruj01-i1849.ca.com:44441,44442,44443 -u "siteminder" -p "siteminder" -hn th-rhel65-5 -hc  hco -cf COMPAT -f /opt/CA/webagent/config/SmHost.conf -o
Host Registration written to '/opt/CA/webagent/config/SmHost.conf'.
[root@rhl65 bin]#

 

If it is expected to have frequent changes in the web server IP address (due to reboot/change in network interface/dns server etc.) , it is recommended to specify a static hostid.

 

In RHEL you can do this by running command : genhostid. The static hostid is then stored in /etc/hostid file.

(Please refer to your respective OS documentation on how to set static hostid)

 

 

 

To be continued....  

 

 

 

 

 

Issue

Changes made to login/passwords forms (login.fcc, smpwservices.fcc etc) are not reflected immediately in the browser.

Environment

Web Agent : r12.5 and above

Cause

There are many things that could go wrong here. 

For e.g

Resolution

  • FCC Forms are cached by default by web agent to improve the web agent performance. This can be disabled by setting ACO EnableFormCache=No.
  • Refer to web server documentation to disable any web server specific cache settings . For e.g in case of IIS you could consider disabling Output caching (UserCache/Kernel Cache). For IIS it is also recommended to set ACO IISCacheDisable=yes
  • Clear browser cache by deleting browsing history or alternatively you can append a random querystring to ensure that it doesn't serve the web page from it's local cache (e.g you can try accessing login.fcc?1=1 , login.fcc?2=2 etc. ) 
  • To ensure that you are modifying the correct FCC page, the best way is to the enable web agent trace log and check the location where it is loading the forms from . For e.g.Here we can see that the web agent loaded the localized fcc form from forms_en-US directory rather than the default forms directory 

 

[08/23/2017][10:12:03][5052][2620][CSmFormTemplateCache.cpp:196][CSmFormTemplateCache::GetForm][][][][][][][Serving form template 'C:\Program Files\CA\webagent\win64\samples/forms_en-US/login_en-US.fcc' from cache.]

 

The Policy Server and Agents utilizes various encryption keys to encrypt sensitive data stored & passed between CA SSO components in a CA Single Sign-On environment.

 

The following diagram gives an overview of the various encryption keys used in CA SSO environment :

What are the purpose of various encryption keys used by CA SSO ?

 

Policy Store Key

Policy store key is used to encrypt :

  • Sensitive data stored in policy store (e.g LDAP bind credential, trusted host shared secrets etc.)
  • Sensitive data stored in policy server management console ( e.g policy store/audit store/session store credential )
  • Key store data when policy store and key store are collocated.

 

Key Store Key

Key store key is used to encrypt the Agent Keys & Session Ticket Keys stored in Key Store when policy store and key store are not collocated. 

When separate key store is not configured, the Key store key is same as the Policy store key.

 

Agent Keys :

  • Agent keys are used to encrypt/decrypt CA Single Sign-On cookies sent to the browser
  • Agent keys are managed by the Policy Server, and distributed to agents periodically.

 

Session Keys

Session keys are used to encrypt :

  • Data sent to and from Policy server to web agent
  • Data sent to and from Policy server to Administrative UI

 

Session Ticket/Persistent Keys

  • Session ticket keys are used by the Policy Server to encrypt session tickets (specs). Session tickets contain

credentials and other information relating to a session (including user credentials). Agents embed session tickets in CA Single Sign-On cookies, but cannot access the contents since they do not have access to session ticket keys which never leave the Policy Server

  • CA SSO also provides the ability for user tracking so a site can remember that a user had a valid session with the site some time ago. If user tracking is enabled, the Identity Spec is generated every time a new Session Spec is generated. The Identity Spec is also encrypted with the Session Ticket Key known only to the Policy Server and passed back to the Web Agent. 
  • Session ticket keys are also used to encrypt the password services data (blob) stored in User Store.

 

More about Session Ticket Keys here :

https://communities.ca.com/community/ca-security/ca-single-sign-on/blog/2016/09/02/tech-tip-ca-single-sign-onpolicy-serverpersistent-keysession-ticket-key-introduced

 

What is the impact of resetting Persistent Key/ Session Ticket Key?

Resetting persistent Key has following impacts :

  • Existing logged in user sessions will not be valid anymore. User will have to re-login to establish a new session.
  • Existing password blob will be no more be valid, which means all the information related to password change, login tracking etc. is lost

 

Policy server Host Key

A built-in static (hard coded) key stored in Policy server binaries.

It is used to encrypt/decrypt data stored in EncryptionKey.txt.

 

Web agent Host Key

A built-in static (hard coded) key stored in Web agent binaries.

It is used to encrypt/decrypt shared secret stored in SmHost.conf along with the hostId of the machine.

 

Shared Secret

The shared secret is used to mutually authenticate the Agent and the Policy Server and to distribute the session keys from the Policy Server to the Agent.

 

What is stored in EncryptionKey.txt ?

Policy Store Key is stored as encrypted string in EncryptionKey.txt file.

 

Here is what happens during the policy server installation :

 

 

During Policy server startup :

 

Policy store key is stored in Policy server memory.

 

How is shared secret for Trusted Host created and stored ?

When registering a Trusted Host, a shared secret is auto generated. This auto generated shared secret is then encrypted using the combination of Web Agent Host Key and the HostId of the machine and stored in the SmHost.conf file on the web agent side.

 

On the policy server side also, the corresponding shared secret for the Trusted Host is encrypted with the Policy store key and stored in the policy store :

 

If these shared secret do not match, the agent to policy server handshake fails.

 

How is the communication channel between Policy server & Web Agent protected ?

CA SSO uses RC4 encryption with randomly-generated 128-bit session keys to encrypt data sent over a TCP connection between a Policy Server and an Agent. The shared secret is first used to mutually authenticate the Agent. Once the handshake (authentication) is complete Policy Server distributes the session keys to the Agent.

 

Encryption of CA SSO Cookies

There are three major types of cookies that may be sent with every request (there are other cookies that are used only during authentication, like FORMCRED cookies):

  • SMSESSION - contains session ticket, always present , encrypted with either static or dynamic agent keys depending upon configuration
  • SMIDENTITY - identity cookie. Present only if the "User Tracking" option is configured, always encrypted with static agent keys.
  • SMDATA - cookie that keeps user credentials. Present only if the "Allow Form Authentication Scheme to Save Credentials” option is configured, always encrypted with static agent keys. 

 

How and where is the Key store key stored while using separate key store ?

If a key store is configured as a separate store from the policy store, then the key store encryption key can be set manually from the Policy server management console --> Keys tab :

 

The provided value is then encrypted with the Policy store key and stored in the CA SSO registry as below :

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Netegrity\SiteMinder\CurrentVersion\ObjectStore]
"KeyStoreEncryptionKey"="{RC2}DgMpaQDh5tmGMBMnQD+AfA=="

 

What are the various FIPS mode supported by CA SSO ?

 

CA SSO can be configured to operate in three FIPS modes :

  • Compat Mode - read both FIPS/Non Fips always write non FIPS keys
  • Migration Mode - read both FIPS and non FIPS - always generate FIPS keys
  • FIPs Only Mode - only read/write FIPS keys

 
While operating in Compat Mode, it uses RC4-128 bit cipher (Session Keys) to encrypt traffic between Policy Server and Web Agent.
While operating in Migration Mode or FIPs Only Mode, it uses AES-128 bit cipher to encrypt traffic between Policy Server and Web Agent.
 
CA SSO embeds RSA 's Crypto-C ME v2.0 cryptographic library, which has been validated as meeting the FIPS 140-2 Security Requirements for Cryptographic Modules. The validation certificate number for this module is 608. CA SSO’ s Java-based APIs use a FIPS-compliant version of the Crypto-J cryptographic library.
 
In FIPS-only mode or Migration Mode, CA SSO uses the following algorithms:

  • AES Key Wrap for key encryption.
  • AES in OFB mode (HMAC-SHA 256) for channel encryption.
  • AES in CBC mode (HMAC-SHA 224) for encrypting tokens used to facilitate

 

Types of Agent Keys

The Policy Server provides the following two types of Agent keys:

  1. Dynamic
    Generated by Policy Server and distributed to connected Policy Servers and any associated Web Agents
    Can be rolled over at regular interval or manually by using the Key Management feature in the UI.

2. Static
Remain the same indefinitely
Can be generated or entered manually. When using a specified manual value , the static agent key will be derived based on the value provided. It won't be the exact same string.

Can be rolled over using the UI

 

There are in total 4 different agent keys , they are :

  • (Key Marker 1) An Old Key is a Dynamic key that contains the last value used for the Agent key before the current value.
  • (Key Marker 2) A Current Key is a Dynamic key that contains the value of the current Agent key.
  • (Key Marker 3) A Future Key is a Dynamic key that contains the next value that will be used as the Current key in an Agent key rollover.
  • (Key Marker 4) Static Key

 

Agent Keys can be exported by running following command :

smkeyexport -d<admin> -w<password> -okeys.txt

 

Sample Key export file :

 

#! SiteMinder Version 12.52
# Export Flags: Encrypted, Export Keys, Export Key store data.
objectclass: Root
Oid: 0a-00000000-0000-0000-0000-000000000000
AgentTypes:
Schemes:
Agents:
AgentGroups:
UserDirectories:
Domains:
Admins:
AuthAzMaps:
CertMaps:
SelfRegs:
ODBCQueries:
PasswordPolicies:
KeyManagement: 1a-fa347804-9d33-11d3-8025-006008aaae5b
AgentKeys: 1b-a0b79a43-eca3-4090-9082-4a30604fd108, 1b-912d25e3-26c0-4103-9c08-397733217fee, 1b-87336696-825f-4c71-b919-2bf2cb61578f, 1b-68860af4-01ff-4227-a034-795df2b93c99
RootConfig:
VariableTypes:
PropertyCollections:
TaggedStrings:
TrustedHosts:
IMSDirectories:
IMSEnvironments:
IMSOptionLists:
SharedSecretPolicy:
IMS6Directories:
IMS6Environments:
objectclass: KeyManagement
Oid: 1a-fa347804-9d33-11d3-8025-006008aaae5b
IsEnabled: true
ChangeFrequency: 2
ChangeValue: 0
NewKeyTime: 1502334000
OldKeyTime: 1502248172
FireHour: 3
PersistentKey: {RC2}VDPKLgZZDJ3mEjM3WzphnvBt2GCIQrNqa6TR174l279K6QLPC0dhZRlPNLvCp/A/
objectclass: AgentKey
Oid: 1b-a0b79a43-eca3-4090-9082-4a30604fd108
KeyMarker: 1
Key: {RC2}r0T7TDNWvPME3VOr6b+43YJjULngsqGsHcMBxsVnuk09Ijh7jsPe5+4xs/OccTvx
objectclass: AgentKey
Oid: 1b-912d25e3-26c0-4103-9c08-397733217fee
KeyMarker: 3
Key: {RC2}6XtDG3PqFgJ5t5JCXiy0S2Ohc6eIv5sNr6Pi06JfXR/hGfyJbvTUtnGfKcacX3kc
objectclass: AgentKey
Oid: 1b-87336696-825f-4c71-b919-2bf2cb61578f
KeyMarker: 2
Key: {RC2}ZDUJcusH5LBcutHqWdMNTxoL78LpXsRQ4OdLeZRIyXwJAzWZckh9H2uXxi9svAFX
objectclass: AgentKey
Oid: 1b-68860af4-01ff-4227-a034-795df2b93c99
KeyMarker: 4
Key: {RC2}5fIwrHQHpgb4ycaZcvYNmAQ2mY4PCgADZW3GMzlyxvUsF8F5nN1h0gEd9rOpNJmm

 

Note : 

  • If not using the clear text export option (-c) , the exported encrypted agent key values always comes as different. 
  • The leading {RC2} or {AES} string indicates the keys are encrypted.

 

How to configure Agent Keys & Session Ticket Key if using Multiple Policy store with Separate Key Store

 

If a network configuration is composed of multiple Policy Servers, policy stores, and master key stores, an administrator with appropriate privileges can specify the same static key and session ticket key for each policy store in order to facilitate one or more of the following:

  • Single sign-on across all Agents
  • Password Services with a common user directory

 

Common Issues with Key(s)

1. Duplicate Agent Keys

 

Symptoms:

SSO fails with the following error in the web agent trace log :

Unable to decode SMSESSION cookie

       

Identification:

 

To identify if your key store have duplicate set of agent keys, perform the key store export using the following     command :

smkeyexport -d<admin> -w<password> -okeys.txt

 

Then count the number of AgentKey in the export file. If there are more than 4 agent keys, then it means you have

duplicate set of agent keys.

If there are more than 4 agent keys, there will be no guarantee which set of keys an Agent will utilize if more than one set is delivered from the Key Store on Agent start up.
Consider a scenario, that there are two set of agent keys - set 1 & set 2. Now, if Web Agent 1 utilizes set 1 and Web Agent utilizes set 2, the SMSESSION cookie encrypted by one agent will not be decoded by another agent eventually breaking the SSO.

 

Common cause for duplicate agent keys :

When using dynamic agent keys, it is required that only ONE policy server is configured to generate agent keys. If multiple policy server generates agent keys , it will most likely end up with duplicate set of agent keys.

Key store could also end up with duplicate agent keys during agent key export and import

Refer : Tech Tip : CA Single Sign-On:: Policy Server : Best practice on importing Agent Keys  

   

Resolution :

    KB : Cleaning up duplicate agent keys How to Clean up a SiteMinder Key Store? 

 

2. "No Session" error in Administrative UI  and "Failed to decrypt persistent key error" in SMPS log.

 

Symptoms:

  • "No Session" error in Administrative UI while trying to access Key Management --> Agent Key /Session Key Management option.

  • Policy server log  (smps.log ) shows error : "Failed to decrypt persistent key"

[2088/972][Wed Aug 09 2017 04:26:41][SmObjKeyManagement.cpp:459][ERROR][sm-Server-03080] Failed to decrypt persistent key

 

Common Cause:

The persistent key (session ticket key ) is encrypted using Policy store key (or Key Store Key if using separate key store). The encrypted Policy store key is stored in EncryptionKey.txt file on the policy server bin directory. So, this error indicates that the current Policy store key (EncryptionKey.txt) is unable to decrypt the persistent key from the key store.

 

Such a situation can occur if, for example, the EncryptionKey.txt file was changed or copied from another machine or the persistent key was created by the policy server with the different Policy store Key (EncryptionKey.txt)

 

Resolution

1. (Preferred) If there is a backup of the original (valid) EncryptionKey.txt or the Persistent Key (in the key store) try reverting to it and see if that works.

2. If the prior solution does not work then proceed to do following steps which basically creates a new Persistent Key in the key store.

 

a) Stop Policy server

b) Stop Administrative UI

c) Set following registry :

HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\SiteMinder\CurrentVersion\ObjectStore

DWORD key:

AllowEmptyEncKey

Value: 1

(If not already existing, create this registry. What this registry does is, even if the Policy server is unable to decrypt the existing persistent key , it will use empty persistent key to encrypt the sensitive data in the policy store )

d) Start Policy server 

e) Start Administrative UI

f) Login to the Administrative UI and navigate to Key Management --> Session Key Management tab

  ( You won't get "No session" error after setting above registry )

   Either click Rollover Now under Generate Random Session Ticket Key or Specify a Session Ticket Key and click

   Rollover Now button under it.

g) Once the new persistent key is created, either delete the registry key (AllowEmptyEncKey) created above or set the value to 0. For security reason , it is strongly advised to do not leave the AllowEmptyEncKey=1 in the production server.

h) Restart Policy server

i)  Restart Administrative UI

 

3. Key store export shows error "Unable to decrypt agent key with policy store / key store key"

 

Symptoms:

While performing the key store export it shows following error :

 

C:\Users\Administrator>smkeyexport -dsiteminder -wsiteminder -oc:\keyenc3.txt
Unable to decrypt agent key with policy store / key store key
Unable to decrypt agent key with policy store / key store key
Unable to decrypt agent key with policy store / key store key
Unable to decrypt agent key with policy store / key store key

 

Common Cause:

This is similar to "Failed to decrypt persistent Key" error as discussed above.

Agent Keys are also encrypted with the Policy store key (Or Key store key if using separate key store) .

So if the Policy store key changes (change of EncryptionKey.txt) , the policy server will no longer be able to decrypt the Agent keys.

 

Resolution :

1. Stop policy server which is configured to generate agent keys.

2. Delete all existing agent keys directly from the key store

e.g 

For RDBS : delete from smagentkey4

For LDAP , you may use the ldapmodify command or your GUI interface to sequentially select and delete all keys.

Example command:

# ldapmodify -D "cn=directory manager" -w dirmanagerpassword -h localhost
dn: smAgentKeyOID4=1b-4a79595f-9a40-1000-a34a-830cefdf0cb3, ou=PolicySvr4,ou=SiteMinder,ou=Netegrity,o=ghost
changetype: delete

(Note: The example commands are for example only and will need to be modified for your environment.)

3. Start Policy server

During the startup, if the policy server configured to generate agent keys doesn't find any agent keys, it will create it.

By default Policy server creates all 4 agent keys with the identical values :

 

 

 

 

 

Introduction

CA SSO uses unique OID to represent various objects. They are of format : "XX-XXXXXXXX-XXXX-XXXX-XXXX-************" (where each X is a hexadecimal character.

The leading two hexadecimal characters signifies the type of the object

 

For e.g

06 signifies Realm, 03 signifies Domain , 0b signifies Rule and so on ..

 

CA.SM::Realm@06-f0352125-7284-4c76-97b4-90bd2c0d662c

CA.SM::Domain@03-4897ec92-d419-4a24-be20-1ff4be366b1

CA.SM::Rule@0b-e3d824b1-52f5-4161-908d-4800b1887214

 

Question

What is the full list of supported OID types ?

Environment

PS : 12.52 SP1

Answer

The full list of supported OID types are as below.

Please note these values are in DECIMAL :

 

         Null = 0

        ,Device = 1

        ,DeviceGroup = 2

        ,Domain = 3

        ,Policy = 4

        ,PolicyLink = 5

        ,Realm = 6

        ,Response = 7

        ,ResponseAttr = 8

        ,ResponseGroup = 9

        ,Root = 10

        ,Rule = 11

        ,RuleGroup = 12

        ,Scheme = 13

        ,UserDirectory = 14

        ,UserPolicy = 15

        ,Vendor = 16

        ,VendorAttr = 17

        ,Admin = 18

        ,ServerCommand = 19

        ,AgentCommand = 20

        ,AuthAzMap = 21

        ,CertMap = 22

        ,SelfReg = 23

        ,ODBCQuery = 24

        ,PasswordPolicy = 25

        ,KeyManagement = 26

        ,AgentKey = 27

        ,RootConfig = 28

        ,Variable = 29

        ,VariableType = 30

        ,ActiveExpr = 31

        ,PropertyCollection = 32

        ,PropertySection = 33

        ,Property = 34

        ,TaggedString = 35

        ,TrustedHost = 36

        ,IMSTask = 37

        ,IMSRole = 38

        ,IMSDirectory = 39

        ,IMSManagedObject = 40

        ,IMSManagedObjectAttr = 41

        ,IMSEnvironment = 42

        ,IMSTaskScreen = 43

        ,IMSTaskScreenField = 44

        ,IMSOrgRoleBinding = 45

        ,IMSOrgRoleBindingDelegatedUser = 46

        ,IMSOrgRoleBindingGrantor = 47

        ,IMSOptionList = 48

        ,SharedSecretPolicy = 49

        ,IMS6Directory = 50

        ,IMS6ManagedObject = 51

        ,IMS6ManagedObjectAttr = 52

        ,IMS6Environment = 53

        ,IMS6Task = 54

        ,IMS6Role = 55

        ,IMS6TabDefinition = 56

        ,IMS6ScreenDefinition = 57

        ,IMS6Tab = 58

        ,IMS6Screen = 59

        ,IMS6ScreenField = 60

        ,IMS6RoleChangePolicy = 61

        ,IMS6RoleAdminPolicy = 62

        ,IMS6RoleMemberPolicy = 63

        ,IMS6RoleOwnerPolicy = 64

        ,IMS6RoleScopeRule = 65

        ,IMS6RoleRule = 66

        ,IMS6ValidationRuleSet = 67

        ,IMS6ValidationRule = 68

        ,IMS6BLTH = 69

        ,IMS6IdentityPolicy = 70

        ,IMS6IdentityPolicySet = 71

        ,IMS6CertificationPolicy = 72

        ,IMSDirectory6 = 50

        ,IMSManagedObject6 = 51

        ,IMSManagedObjectAttr6 = 52

        ,IMSEnvironment6 = 53

        ,IMSTask6 = 54

        ,IMSRole6 = 55

        ,IMSTabDefinition6 = 56

        ,IMSScreenDefinition6 = 57

        ,IMSTab6 = 58

        ,IMSScreen6 = 59

        ,IMSScreenField6 = 60

        ,IMSRoleChangePolicy6 = 61

        ,IMSRoleAdminPolicy6 = 62

        ,IMSRoleMemberPolicy6 = 63

        ,IMSRoleOwnerPolicy6 = 64

        ,IMSRoleScopeRule6 = 65

        ,IMSRoleRule6 = 66

        ,IMSValidationRuleSet6 = 67

        ,IMSValidationRule6 = 68

        ,IMSBLTH6 = 69

        ,IMSIdentityPolicy6 = 70

        ,IMSIdentityPolicySet6 = 71

        ,IMSCertificationPolicy6 = 72

Introduction

The manual key rollover option for Dynamic Agent Key is disabled by default. 

This KB guides how to enable this feature.

 

Environment

Policy server : r12.5 and above

Instructions

1. Perform a full key store export by running following command :

smkeyexport -d<admin> -w<password> -okeys.txt

 

2. Once the key store is is exported, change the value for IsEnabled option under KeyManagement to true from false:

Old :

objectclass: KeyManagement
Oid: 1a-XXXXX
IsEnabled: false
ChangeFrequency: 0
ChangeValue: 0
NewKeyTime: 0
OldKeyTime: 1502258688
FireHour: 0
PersistentKey: {RC2}2SraPUoK8PLYItUrJFCeck7rlcWl77g+3vpJY07rso39+ojFmbn7zn0IdwGjWeCQ

 

New :

objectclass: KeyManagement

Oid: 1a-XXXXX
IsEnabled: true
ChangeFrequency: 0
ChangeValue: 0
NewKeyTime: 0
OldKeyTime: 1502258688
FireHour: 0
PersistentKey: {RC2}2SraPUoK8PLYItUrJFCeck7rlcWl77g+3vpJY07rso39+ojFmbn7zn0IdwGjWeCQ

Note : DO NOT MAKE ANY OTHER CHANGE

 

3. After making the above change, save the export file and import it by running following command :

smkeyimport -d<admin> -w<password> -ikeys.txt

4. You should now have the manual rollover option enabled for the dynamic agent key 

 

Summary

It is often required to access the default CA SSO generated response attributes in the custom active response/rules to evaluate custom logic.

Some sample CA SSO generated attributes are :

  • SM_USERSESSIONIP
  • SM_USERDN
  • SM_USERPASSWORD

The full list of default CA SSO generated attributes can be found by searching for keyword "CA SiteMinder®-Generated User Attributes" in CA SSO documentation

https://docops.ca.com/ca-single-sign-on/12-52-sp1/en/configuring/policy-server-configuration/responses-and-response-groups/ca-siteminder-generated-user-attributes

Environment

PS : r12.5 and above

Instructions

To default CA SSO generated user attributes can be accessed using the SmUserContext.getProp(java.lang.String propName) API call as below.

In the example below, we are accessing the default CA SSO response attribute : SM_USERIPADDRESS

 

 

    public String
    invoke(ActiveExpressionContext context,
           String param)
        throws Exception
    {

        if (context == null)
        {
           // should never happen
           throw new IllegalArgumentException("ActiveResponseSample invoked without context");
        }

        // the User Context is required to use the methods like getProp, setProp..
        UserContext theUserContext = context.getUserContext();

        if (theUserContext == null)
        {
            context.setErrorText("No User Context.");
            return null;
        }

     return theUserContext.getProp("SM_USERIPADDRESS");
    }

 

Step 1: Create an active response as shown below :

Step 2 : Configure the Active Response with either OnAuthAccept or OnAccessAccept rule.

Step 3 : Compile the attached sample ActiveResponseSample.java class by running java-build.bat (windows) /java-build.sh (unix).

Note: Prior to running you will need to update the path to the JDK install directory in the JAVA_HOME variable by editing the java-build.bat (windows) /java-build.sh (unix) files.

 

Step 4. Once compiled, copy the ActiveResponseSample.class and copy it to the <Policy server>/config/properties directory.

 

Note: This "properties" directory is by default in the classpath of Policy server so you don't need to modify JVMOptions.txt.

 

If you choose to deploy the class in any other directory, then you will need to add the path to that directory as a classpath in the JVMOptions.txt file.

 

Test:

 

Policy server Trace Log :

 

[08/07/2017][01:30:07][2908][1564][][SmAuthUser.cpp:700][ServerTrace][][][][][][][][][][][][][][ActiveResponseSample: ActiveResponseSample:: returning ClientIP= ['10.129.160.255']][01:30:07.792][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][ActiveResponseSample:: returning ClientIP= ['10.129.160.255']][][][][][][][][][][][][][] 

Additional Information

1) Not all response attributes are available at all events (OnAuthAccept, OnAuthReject, OnAccessAccept etc.) 

So before implementation please verify if the response attribute you are interested is available for the event that you require it in :

https://docops.ca.com/ca-single-sign-on/12-52-sp1/en/configuring/policy-server-configuration/responses-and-response-groups/ca-siteminder-generated-user-attributes

 

2) Active Response are by default cached. If you need the active response to evaluate every time on the Policy server , disable attribute caching for this active response.( In the active response creation screen in Administrative UI)

 

Question

Policy server cache flushing from the command line by running command : smpolicysrv -flushcache doesn't work.

While running this command , it gives following error in the smps.log :

 

[CServer.cpp:7668][INFO][sm-Server-04520] Server 'flushcache' command received. 

[CServer.cpp:7669][INFO][sm-Server-04750] Server 'flushcache' command is disabled.Please contact CA Technologies Customer Support for further information 

Note : 

 

  • Cache update is already enabled on the policy server by running command :smpolicysrv -enablecacheupdates.
  • Cache flushing from Administrative UI is working.

Environment

  • Policy server : r12.5, r12.51, r12.52, r12.6, r12.7 (inclusive of all SP & CR)
  • Policy server OS : Any

Answer

Policy server cache flushing functionality from the command line is deprecated.

The cache can now be flushed only from Administrative UI.