Skip navigation
All Places > CA Security > CA Single Sign-On > Blog > 2016 > August


How to enable debug logging for custom authentication scheme?


Policy Server Version : R12.0SP3 and above


There are couple of ways to enable debug logging for Java based custom authentication scheme.


Option 1: Write the debug log into Policy Server Trace logs

For this, you can simply call SmAuthenticationContext.getAPIContext().trace() API from your Custom Authentication scheme as below :


void logInPSTrace(SmAuthenticationContext context, String msg) {
//Log message into Policy Server Trace Log
context.getAPIContext().trace(getClass().getSimpleName(), "AuthApiSample:: ['" + msg +"']");


and use Policy server trace profiler something like this :

components: AgentFunc, Server, IsProtected, Login_Logout, IsAuthorized,

Tunnel_Service, JavaAPI, Directory_Access, ODBC, LDAP, IdentityMinder, TXM, Fed_Server


data: Date, PreciseTime, Realm, Rule, Policy, AuthStatus, AuthReason, User,

Action, Resource, Directory, ErrorValue, ErrorString, AgentName, Message,

Data, SrcFile, Pid, Tid, PreciseTime, Function, ReturnValue, Group, Domain,

AgentType, TransactionID, ObjectClass, DomainOID, SearchKey, ObjectOID,

Property, IPAddr, IPPort, AuthScheme, CertSerial, SubjectDN, IssuerDN,

SessionSpec, SessionID, CertDistPt, UserDN, RealmOID, State, ClusterID,

HandleCount, FreeHandleCount, BusyHandleCount, ResponseTime, Throughput,

MaxThroughput, MinThroughput, Threshold, TransactionName, HexadecimalData,

Query, ActiveExpr, CallDetail


Sample Policy Server trace log :


[08/25/2016][15:48:50.300][15:48:50][3420][3232][SmAuthUser.cpp:700][ServerTrace][][][][][][][][][][][][][][][][][][][][AuthApiSample:: ['Authenticating User']][AuthApiSample: AuthApiSample:: ['Authenticating User']][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]
[08/25/2016][15:48:50.300][15:48:50][3420][3232][SmAuthUser.cpp:700][ServerTrace][][][][][][][][][][][][][][][][][][][][AuthApiSample:: ['User Successfully Authenticated']][AuthApiSample: AuthApiSample:: ['User Successfully Authenticated']][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]



Option 2 : Write the debug log into a separate log file using java.util.logging.Logger. 


Step 1: Configure java util logging using file located at  : <PS_Install_directory>/config/properties as below:

handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler

.level= ALL


# default file output is in user's home directory.
java.util.logging.FileHandler.pattern = C:/Program Files (x86)/CA/siteminder/log/javafile.log
java.util.logging.FileHandler.limit = 50000
java.util.logging.FileHandler.count = 1
java.util.logging.FileHandler.formatter = java.util.logging.SimpleFormatter


Step 2 : Initialize java util logging and invoke the log method from the custom authentication scheme as below :

//Initialize logger

private static Logger theLogger =


//Logger method to log the debug message

void logInJavaUtilLogger(String msg) {
//Log message into JavaUtil Logger
theLogger.fine("AuthApiSample::FileLogger::"+ msg);


//Invoke Logger Log method

 logInJavaUtilLogger("User Successfully Authenticated :"+context.getUserCredentialsContext().getUserName());


Sample log using java.util.logging.logger:


Aug 25, 2016 3:48:50 PM com.netegrity.sdk.javaauthapi.AuthApiSample log
FINE: AuthApiSample::FileLogger::Authenticating User
Aug 25, 2016 3:48:50 PM com.netegrity.sdk.javaauthapi.AuthApiSample log
FINE: AuthApiSample::FileLogger::User Successfully Authenticated



  • Sample
  • Sample Custom Authentication scheme utilizing both the above option to log debug message. 


Additional Information:


CA Single Sign-On Tech Tip by Sau Lai Wong, Principal Support Engineer for 25th August 2016



Running into following exception when admin attempts to run Policy Server configuration wizard:

This Application has Unexpectedly Quit: Invocation of this Java Application has caused an InvocationTargetException. This application will now exit. (LAX)

Exception running install action:
    at java.lang.StringBuffer.append(Unknown Source)
    at com.zerog.ia.installer.util.VariableManager.stripDELIM(Unknown Source)
    at com.zerog.ia.installer.util.VariableManager.aa(Unknown Source)
    at com.zerog.ia.installer.util.VariableManager.getVariable(Unknown Source)
    at com.zerog.ia.installer.util.VariableManager.getValueOfVariable(Unknown Source)
    at com.zerog.ia.installer.util.IAVariableStringResolver.getValueOfVariable(Unknown Source)
    at com.zerog.ia.installer.util.VariableManager.substitute(Unknown Source)



Policy Server: R12.52  SP1 CR2 on RHEL 6



Variables in file are not resolving to values accordingly, resulting the configuration wizard to fail. The values should be picked up during the Policy Server installation.



Update file - enter value for respective field accordingly.


Customer wants to disable SSL protocol and enable TLSv1.1/ TLSv1.2 for Policy server connection with LDAP Policy store/User Store.


Does Policy server supports TLSv1.1/ TLSv1.2 protocol for LDAP connectivity with Policy Store/User Store?


Policy Server Version : R12.0SP3 and above



What determines the Policy Server supportability to various SSL/TLS protocols with respect to LDAP connection?

The Policy Server uses a Mozilla LDAP SDK to communicate with LDAP directories (Policy store/User Store etc.)

These libraries are deployed under Policy server bin folder. The main library being Network Security Services Base Library : nss3.dll (windows)/ (Unix)

So,  support for different security protocol SSL/TLS 1.0/1.1/1.2 etc primarily depends on whether the bundled NSS library support it or not.

Support for TLS v 1.1  (RFC 4346) is available from NSS 3.14

Support for TLS v 1.2 (RFC 5246) is available from NSS 3.15.1


Does Policy server supports TLSv1.2 protocol for LDAP connectivity with Policy Store/User Store?

As seen above , this depends on the version of the NSS libraries shipped. Now let’s look at the NSS libraries version shipped with different Policy server version

  • R12.SP3CR12  = NSS
  • R12.51CR6 onwards until CR10 = NSS
  • R12.52SP1 CR7 onwards = NSS 3.28.1
  • R12.52SP2 until CR1  = NSS
  • R12.6 = NSS 3.20




  • R12.0SP3CR12 doesn’t have support for TLS protocol. It supports only SSL.
  • R12.51CR6 onwards , we have support for TLS but only upto TLSv1.0 ( due to some internal limitation we don't support TLSv1.1). However, you can request a NIN for this as we have already certified NSS 3.30.2 libraries for this release (CA only refer: DE300577)
  • R12.52SP1 CR7 onwards we have support for both TLS v1.1 & TLS v1.2
  • R12.52SP2 until CR1 doesn't have support for TLSv 1.1 & TLSV v1.2 (Open support ticket if you need a NIN for this release)
  • R12.6 onwards we have support for both TLS v1.1 & TLS v1.2




CA Single Sign-On Tech Tip by Sau Lai Wong, Principal Support Engineer for 23rd August 2016



Following error is logged in smps.log:

“Timestamp parameters with a scale, must have a scale less than ten and a precision equal to 20 plus the scale. You specified a precision of 32 and scale of 12. Error in parameter 1."



Policy Store: IBM DB2 10.x

Policy Server: R12.52 SP1 CR1



This is a known issue with Data Direct driver v07.12 against IBM DB2 10.x. R12.52 SP1 CR1 Policy Server is using Data Direct driver v07.12.0056 (B0067, U0042).


The connection option "WorkArounds2=2" is not functioning properly against DB2 LUW 10.x with the ODBC 7.1 DB2 driver.  This option causes the driver to ignore the ColumnSize and DecimalDigits specified in SQLBindParameter.  When executing a parameterized UPDATE statement against a timestamp, an error occurs due to the option "WorkArounds2=2" is not functioning correctly.  This only occurs against DB2 LUW 10.x.

Timestamps for DB2 10.x have a precision and scale of 32 and 12. The connection option "WorkArounds2=2" was not handling the precision of greater than 30 correctly.


The issue is addressed with Data Direct driver v07.13.0105 (B0111, U0073).

R12.52 SP1 CR2 Policy Server uses Data Direct driver v07.15.


Additional Information:


What information is stored in the SMSESSION Cookie ?


Policy Server Version : ANY

Web Agent Version : ANY


SMSESSION Contains following :

  • ATTR_USERDN. The user's distinguished name.
  • ATTR_SESSIONSPEC. The session specification returned from the login call.
  • ATTR_SESSIONID. The session ID returned from the login call.
  • ATTR_USERNAME. The user's name.
  • ATTR_CLIENTIP. The IP address of the machine where the user initiated a request for a protected resource.
  • ATTR_DEVICENAME. The name of the agent that is decoding the token.
  • ATTR_IDLESESSIONTIMEOUT. Maximum idle time for a session.
  • ATTR_MAXSESSIONTIMEOUT. Maximum time a session can be active.
  • ATTR_STARTSESSIONTIME. The time the session started after a successful login.
  • ATTR_LASTSESSIONTIME. The time the current session was last accessed.


SESSIONSPEC can only be decrypted by Policy server. It contains following information :

  • SessionVersion
  • SessionStartTime
  • SessionLastTime
  • SessionMaxTimeout
  • SessionIdleTimeout
  • SessionLevel
  • SessionId
  • SessionIp
  • SessionDn
  • SessionDirOid
  • SessionDirName
  • SessionUnivId
  • SessionType
  • SessionAnonymous
  • SessionImpersonatorName
  • SessionLoginName
  • SessionPersistent
  • SessionDrift
  • SessionImpersonatorDirName
  • SessionAuthContext

Additional Information:



How to encrypt the Database Administrator Password in the Sm.registry file without using the Policy Server Management Console (SmConsole) in Unix based systems.


The Policy server management is GUI based utility and will need X11 forwarding to be able to work with it in Unix systems.

Most of the configuration available in SmConsole can also be performed directly by modifying the Sm.registry file located at <PolicyServer_Install_Directory>/registry directory.

However, the challenge is when we need to modify an encrypted value like Database Administrator password or Policy store Administrator password etc without using the SmConsole.


Policy Server : R12.5+,

OS : Unix


An workaround for this use case, is to use the “smldapsetup” utility bundled with the Policy server as follows:

smldapsetup reg -d”LDAP User” -wMyPassword123

Where, “MyPassword123” needs to be replaced with the actual password that you would like to encrypt.

Note : Running the above command modifies the LDAP Policy store connection details, so if you are using LDAP Policy store, do NOT use this workaround.


Then, copy the value of the encrypted password from the following registry key to the relevant section in the Sm.registry file:



For e.g for the Database Administrator password for “Policy store” , you will need to copy the encrypted password value to the key :



Additional Information:

Enhancement Request for command line option for SmConsole :

CA Single Sign-On Tech Tip by Sau Lai Wong, Senior Support Engineer for 11th August 2016



Administrative UI/ application server is installed with an embedded certificate database.


To configure external administrator store connection over SSL, we have to add the Root Certificate Authority to the Administrative UI/ application server’s certificate database.

With the bundled JBOSS, the trust store resides under <adminui>\server\default\conf\ directory. Run the following command to add the Root Certificate Authority to Administrative UI certificate database:

keytool.exe -importcert -trustcacerts -alias <alias> -file <CACertificate> -keystore trustStore.jks -storepass <truststore_password> -v



After the external administrator store connection over SSL is configured successfully, following error is constantly getting logged in the Policy Server log:

[ERROR]SmDsLdapConnMgr Bind. Server : 636. Error 81-Can't contact LDAPserver



Policy Server R12.52 SP1 release onward.



Following policy objects are created automatically once external administrator store configuration is completed successfully:

  • AdvAuthExternalRDBDir /AdvAuthExternalLDAPDir – depending if the external admin store is on LDAP or ODBC repository
  • AdvAuthNAuthZDomain
  • AdvAuthNAuthZRealm – protected resource = “/sampleresource.html
  • AdvAuthNAuthZAgent
  • AdvAuthNAuthZQueryScheme


‘AdvAuthExternalLDAPDir’ user directory is created with details gathered during the external administrator store configuration. When SSL is enabled for the external admin store, we need to manually import the Root Certificate Authority and Server certificates to Policy Server’s certificate database, after 'AdvAuthExternalLDAPDir' user directory is created. If this manual step is not done, Policy Server will not be able to connect to the backed LDAP user directory over SSL and log the LDAP error.


Additional Information:

Details in adding the certificates, please refer to the following link:


How to configure X.509 cert authentication with CA Single-On Web Agent on Apache web server


  • Policy Server : R12.52 SP1 and above
  • User Store : ANY LDAP
  • Web Server : Apache 2.4 on Windows


You have already obtained following three required certificates:

  • Trusted CA root certificate.
  • Server Certificate from a trusted CA.
  • Client Certificate from a trusted CA.

(Refer : Tech Tip : How to create self signed RootCA/Server/User Certificates using OpenSSL )



Changes on the Apache Web Server

Changes to httpd.conf

1. Ensure mod_ssl is uncommented. 

    LoadModule ssl_module modules/

2. Ensure either httpd-ssl.conf or httpd-ahssl.conf is configured.

<IfModule ssl_module>

#Include conf/extra/httpd-ssl.conf

Include conf/extra/httpd-ahssl.conf

SSLRandomSeed startup builtin

SSLRandomSeed connect builtin


Changes to httpd-ssl.conf/httpd-ahssl.conf

1. Ensure Listen port is specified for HTTPS

    Listen 443 https

2. Configure virtual host for SSL with following highlighted option set

<VirtualHost _default_:443>

ServerName localhost:443

SSLEngine on

SSLCertificateFile "${SRVROOT}/conf/ssl/server.crt"

SSLCertificateKeyFile "${SRVROOT}/conf/ssl/server.key"

SSLCACertificateFile "${SRVROOT}/conf/ssl/ca.crt"

SSLVerifyClient require

SSLVerifyDepth 10

DocumentRoot "${SRVROOT}/htdocs"

# DocumentRoot access handled globally in httpd.conf

CustomLog "${SRVROOT}/logs/ssl_request.log" \  "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

<Directory "${SRVROOT}/htdocs">

Options Indexes Includes FollowSymLinks

AllowOverride AuthConfig Limit FileInfo

Require all granted




Note : If Apache is run as windows service, it will need the server key unencrypted.

You can use following command to change the encrypted server key to unencrypted:

>openssl rsa –in server.key -out server.key

Enter pass phrase for server.key:      -> Enter passphrase and hit return

writing RSA key


Changes on the Policy Server


1. Create X.509 certificate authentication scheme as below :

2. Create Domain, Realm, Rule (get/post), Policy . Protect the realm with the X.509 authentication scheme.

3. Click Certificate Mapings under Directory and create mapping as below.

Note :

  • Ensure that the Issuer DN matches exactly as in the user certificate.
  • Choose the mapping attribute as per the Active Directory LDAP User DN lookup configuration



Changes on the client machine

1. Open MMC console and import the client certificate and CA root certificate. Import them to the Current User account.


How to Test

1. From the client machine access the resource protected with X.509 authentication scheme.

2. It will prompt you to select the client/user certificate. Choose the appropriate user certificate and click Ok.


Additional Information:


Policy Store Directory Server log shows a search for "CA.SM::$AgentConnectionMaxLifetime" in the Policy Store at regular interval.

After setting "KeepAgentConnections=0x2" in the CA SiteMinder registry, the policy server trace log started showing following :

[No such object][Handle='0xb293a28', Root='xpsParameter=CA.SM::$AgentConnectionMaxLifetime,ou=XPS,ou=policysvr4,ou=siteminder,ou=netegrity,', Scope=0, Filter='(xpsValue=*)', attrsonly=0]




  • Policy Server : R12.51CR6 and below, R12.52 SP1 CR1 and below
  • Policy Store : ANY LDAP


This is a known defect. This has been fixed in following policy server versions:

  • R12.51 CR7 and above.
  • R12.52SP1 CR02 and above

Policy server code has been now fixed to read this parameter only once during the policy server startup.

If the value for AgentConnectionMaxLifetime is changed via XPSConfig tool, this will need Policy server restart to reflect the changes.


Apply R12.52SP1 CR02  or R12.51 CR7  patch (or above) as applicable.


An workaround could be to manually set a local value for AgentConnectionMaxLifetime parameter via XPSConfig tool in all the Policy server.

To configure the maximum Agent connection lifetime

  • Open a command line on the Policy Server, and enter the following command:


The tool starts and displays the name of the log file for this session, and a menu of choices opens.

  • Enter the following command:


A list of options appears.

  • Enter the numeric value corresponding to the AgentConnectionMaxLifetime parameter: For example, 4.The AgentConnectionMaxLifetime parameter menu appears.
  • Type c to change the parameter value.

The tool prompts you whether to apply the change locally or globally.

  • Enter one of the following values:

l—The parameter value is changed for the local Policy Server only, overriding the global value.

g—The parameter value is changed globally for all Policy Servers (that do not have a local value override set) using the same policy store.

  • Enter the new maximum Agent connection lifetime, in minutes, for example:


  • The AgentConnectionMaxLifetime parameter menu reappears, showing the new value. If a local override value is set, both the global and local values are shown.
  • Enter Q three end your XPSConfig session.

Your changes are saved and the command prompt appears.

  • Restart the Policy Server.


Additional Information:

Configure Agent to Policy Server Communication Using a Hardware Load Balancer - CA Single Sign-On - 12.52 SP1 - CA Techn…

Initial version of R12.52SP1CR5 Policy server has an issue where JVM would not initialize on custom java invocation (related to saml asserter, active expression, custom authentication scheme etc.) and eventually policy server crashed.


Snippet of smps log prior to policy server crash

[SmJVMSupport.cpp:255][INFO][sm-JavaApi-01030] SmJVMSupport: Using the following JRE: <JRE_path>[SmJVMSupport.cpp:260][INFO][sm-JavaApi-01040] SmJVMSupport: Loaded the following JVM library: <JRE_path>/lib/i386/server/


This is known issue as per following KB.



This has been addressed in updated policy server binary


The updated policy server binary is for Unix version that it come with build number 2113 (ie Version: 12.52; Update: 01.05; Build: 2113; CR: 05;) while the initial version is build number 2112 (Windows version remain 2112 as the fix not applicable to Windows environment).


The Advanced Authentication Flow Application installed on the CA Access Gateway (CA Secure Proxy Server) might fail to startup/initialize for number of reasons. In this blog, we will discuss way to troubleshoot these kind of issues with few samples.


  • CA Access Gateway (formerly CA Secure Proxy Server ) : R12.52SP1 and above
  • Policy Server : R12.52SP1 and above



The Advanced authentication components on the CA Access gateway comprises of multiple component which generate following logs at the <ARCOT_HOME>/logs directory.

  • arcotuds.log—the log file for the UDS services
  • CAWebFlowLog.txt—the log file for the authentication flow application
  • UIApplog.txt—the log for the UIApp (part of the authentication flow application execution process)


Configuration Files

  • arcotcommon.ini (available in <ARCOT_HOME>/conf directory)

The arcotcommon.ini file contains the parameters for database and instance settings for UDS (User Data Service) of Advanced Authentiction server.

For e.g. the primary database








The password corresponding to Username.<N> needs to be securely  stored in securestore.enc with value of Datasource.<N> as the key. The dbutil utility is used to achieve this.

Note : This datasource must be exists in the odbc.ini file.

  • udsserver.ini  (available in <ARCOT_HOME>/conf directory)

The udsserver.ini file contains the parameters to set the User Data Service (UDS) log information. The following table lists the log file information of UDS

  • odbc.ini  (available in <ARCOT_HOME>/odbc directory)

The odbc.ini file contains a list of Data Sources and any properties for each of them. If configured properly it should look like below :


[ODBC Data Sources]

CAAdvancedAuthDSN=SiteMinder Policy Server Wire Protocol














Note : The odbc.ini file exists only in case of Unix platform. The corresponding settings is available in Windows in the 32 bit DSN :



  • <placeholder>



The UDS Service (User Data Service) is the core Advanced Authentication component.

The parameters that control logging in this file can be configured by using the udsserver.ini file, which is available in the <ARCOT_HOME>/conf directory.


For troubleshooting any issue related to Session Assurance component on the CA Access Gateway , it is best to start with this  UDS log (arcotuds.log) and also it is better to increase the logging level as below in the udsserver.ini file:


Change From:


log4j.rootCategory=ERROR, debuglog




log4j.rootCategory=DEBUG, debuglog


Issue 1:  Error on arcotuds.log :

[localhost-startStop-1] : WARN  : core.pool.PoolableSocketFactory : Unable to connect to RemoteHost [<PolicyServer_Hostname/FQDN/IP>:7680] Connection refused at Method)



This indicates either the "CA RiskMinder" service is down at the Policy server or the port 7680 is not opened between Policy server and CA Access Gateway machines.

Ensure that CA RiskMinder service is up and you can telnet to Policy server on 7680 port from CA Access Gateway server.


Issue 2: Error on arcotuds.log:

2016-08-04 00:08:50,969 PDT : [localhost-startStop-1] : DEBUG : database.ibatis.ArcotiBatisDataSourceFactory : Datasource[1] added successfully to the datasource list

2016-08-04 00:08:50,981 PDT : [localhost-startStop-1] : ERROR : cache.db.CacheRefreshService : Internal error: Unable to read cache refresh state table

org.apache.commons.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory (SiteMinder Agent API initialization failure)


The Advanced Authentication component on the CA Access Gateway communicates with the Policy server on the JDBC/ODBC bridge. The above error usually indicates that the DSN is not fully configured for this purpose.

Check if the SmHostFlow.conf file exists on the <ARCOT_HOME>/conf directory exists.

If it does not exists, re-running  the configuration wizard for CA Access Gateway would fix this issue.


Issue 3 : Same error as Symptom 2 but followed by following error in smps.log:

[2332/2396][Thu Aug 04 2016 17:18:58][CServer.cpp:2017][ERROR][sm-Tunnel-00050] Handshake error: Shared secret incorrect for this client

[2332/2396][Thu Aug 04 2016 17:18:58][CServer.cpp:2178][ERROR][sm-Server-01070] Failed handshake with <CA_ACCESS_GATEWAY_IP>:<PORT>


This happens when the SmHostFlow.conf file exists but the shared secret defined within it is no more valid.

To solve, this , you can either copy the SmHost.conf file from <SPS_Install_Directory>/proxy-engine/conf/defaultagent/SmHost.conf to the <ARCOT_HOME>/conf directory and rename to SmHostFlow.conf file (provided the defaultagent is able to initialize without any error)


Alternatively, you can also register a new trusted using following command :

./smreghost -i <PolicyServer_IP>:44441 -u "siteminder" -p <super user password> -hn <trustedhostname> -hc <host_config_object> -cf COMPAT -f <ARCOT_HOME>/conf/SmHostFlow.conf

You can find the smreghost script in <CA_Acess_Gateway_Install_Directory>/agentframework/bin directory


Issue 4 :

Error on arcotuds.log:

2016-08-04 16:18:57,726 PDT : [localhost-startStop-1] : ERROR : cache.db.CacheRefreshService : Internal error: Unable to read cache refresh state table

org.apache.commons.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory ([DataDirect][ODBC lib] Data source name not found and no default driver specified)

  at org.apache.commons.dbcp.BasicDataSource.createPoolableConnectionFactory(


Error on CAWebFlowLog.txt

### Cause: org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is java.sql.SQLException: Invalid Oracle URL specified



This error indicates that the "CAAdvancedAuthDSN" data source does NOT exists in the <ARCOT_HOME>/odbc/odbc.ini file.

The entry is created if the CA Access Gateway configuration wizard is run successfully.

Alternatively, it can be configured manually as indicated in the sample above. Ensure that all the path are valid.

If the SmHostFlow.conf does not exist in the <ARCOT_HOME>/conf directory , you can apply the resolution from Issue 3 (above).


Issue 5 :

Error on CAWebFlowLog.txt

2016-08-18 17:12:31,208 [FlowExecutor,ajp-bio-9009-exec-3] ERROR  - TID[-1] 807259999: Unexpected exception in flow {0}(ID={1}); destroying session

java.lang.RuntimeException: com.arcot.corejsvr.ExceptionWithNC: 808068044: Token ID missing from request.


This error indicates that the cookie is not submitted to the Session Assurance End Point.

This could happen if -

1) Cookie domain of the protected resource and that of Session Assurance End Point do not match.

2) Host only cookie is being used.


To fix this error, ensure that both the protected resource and the Session Assurance End point are using the same cookie domain and also that they are not using Host ONLY cookies.


This document will provide step by step guide to configure Enhanced Session Assurance with DeviceDNA™ functionality.


  • CA Access Gateway (formerly CA Secure Proxy Server ) : R12.52SP1 and above
  • Policy Server : R12.52SP1 and above


Policy Server

  • Ensure "CA RiskMinder" ( Advanced Authentication ) service is up and running on the Policy Server.


Check Service Console.

Check <PolicyServer_Install_Directory>\CA\aas\logs\cariskminderstartup.log

The log should say:

"CA RiskMinder Service READY"

  • Ensure that you have installed and configured Session Store.


CA Access Gateway Server (formerly CA Secure Proxy Server)

  • Ensure that you have configured CA Access Gateway server to use SSL (Only front end Apache is sufficient)
  • Ensure that you can telnet from CA Access Gateway server to Policy server on port 7680
  • Ensure that JCE ( Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files ) patch is applied on the JRE used by CA Access Gateway server.
  • Ensure "CA Advanced Authentication Flow Application" ( Advanced Authentication ) service is up and running on the CA Single Sign-On CA Access Gateway Server.

This could be verified by accessing following URL :


You should get a page similar to below. (Ignore the error, as it is just indicating that the required parameter is not being passed)



  • Create Enhanced Session Assurance end points

    From Administrative UI, click Policies-->Global-->Session Assurance Endpoints.

  • Add Session Assurance End Point to your realm

     Note : For Session Assurance to work it is NOT necessary to enable Persistent Session on the realm.

  • Ensure that the ACO used by your CA Access Gateway server has ".sac" extension included in the IgnoreExt ACO parameter

  • Ensure that ACO used by your CA Access Gateway has the SACExt parameter set to ".sac" as below :


Sample working fiddler trace is attached - SessionAssurance_Working.saz


Additional Information:


  • As the FLOW App on the CA Access Gateway is a local app deployed as web app on the Tomcat server, you do not need to configure any proxy rules in the Proxyrules.xml pertaining to the session assurance.
  • How to configure SSL on CA Access Gateway

Configuring SSL for CA SiteMinder® SPS

  • CA Single Sign-On Bookshelf intro on Session Assurance Configuration…

This is a common question in Single Sign-On space.

I would highly recommend setting up the use case and test it yourself because nothing is better than seeing the behavior in your familiar setup.


In my case, I am using AD as userstore.

It has the following users which the CN is the same.

Yes, if you have AD as userstore, it would be advisable to use samaccountname to search the user.

But for demonstration purpose, I will be searching "CN" value so it can return 2 UserDN as below.


UserStore is configured as below.


I created a generic realm/rule/policy to protect /MultipleUserDN/ resource.


Above is a "CN=user1,OU=People,DC=sso,DC=lab" being authenticated.


Above is for "CN=user1,CN=Users,DC=sso,DC=lab".


So, depending on which user's password you enter, that maching user will be authenticated.


Next question is... what happens if user1 enters wrong password that does not match either of the users.



The user is not authenticated. It doesn't look too bad, right?



Let's move into the complicated and problematic use case.

What if you have password policies to lock out the user if they submit wrong password for 3 consecutive times?


Now that I have your attention, let's look at the smps.log before we go further.

#1. Initially I logged in as "CN=user1,OU=People,DC=sso,DC=lab"

#2. Then login as "CN=user1,OU=Users,DC=sso,DC=lab"

#3. Lastly, I logged in with wrong password that does not match either users.



[6340/4144][Wed Aug 03 2016 16:20:27][SmAuthServer.cpp:361][INFO][sm-Server-02760] Initialized authentication scheme Basic


[6340/1128][Wed Aug 03 2016 16:22:17][plugin_AD.cpp:1689][ERROR][sm-Ldap-00770] (AuthenticateUser) DN: 'CN=user1,OU=People,DC=sso,DC=lab' . Status: Error 49 . 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1


[6340/4140][Wed Aug 03 2016 16:24:40][plugin_AD.cpp:1689][ERROR][sm-Ldap-00770] (AuthenticateUser) DN: 'CN=user1,OU=People,DC=sso,DC=lab' . Status: Error 49 . 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1

[6340/4140][Wed Aug 03 2016 16:24:40][plugin_AD.cpp:1689][ERROR][sm-Ldap-00770] (AuthenticateUser) DN: 'CN=user1,CN=Users,DC=sso,DC=lab' . Status: Error 49 . 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1


For #1, although 2 UserDNs were returned, because the first userDN("CN=user1,OU=People,DC=sso,DC=lab") was able to successfully BIND with the password, the next userDN was not tried.

As a result, in the smps.log you do not see "Error 49" for any user.


** The order of which UserDN returns first cannot be expected. It may be different on every request.


For #2, this time the first UserDN(This time it was "CN=user1,OU=People,DC=sso,DC=lab") did not successfully BIND using the password so it logs "Error 49" and continue to try with the next UserDN.

As a result, in the smps.log, you will see "Error 49" for "CN=user1,OU=People,DC=sso,DC=lab"


For #3, regardless of in which order the 2 UserDNs were returned, they all failed to BIND.

As a result, you will see "Error 49" for both users.


Let's see what happens when you have password policy.


Following password policy is created.

As you can see that this only applies to "CN=User1"

AD has its native password policy but SiteMinder password policy will trigger first because AD is not configured to lock out users due to incorrect passwords.


I will perform the same test above.


#1. First UserDN("CN=User1,OU=People,DC=sso,DC=lab") was able to BIND successfully so there was no "Error 49".

As a result, password policy does not update any failed login attempt.


#2. First UserDN("CN=User1,OU=People,DC=sso,DC=lab") fails to BIND so "Error 49" is logged.

Next UserDN("CN=user1,CN=Users,DC=sso,DC=lab") was able to BIND.

As a result, "CN=User1,OU=People,DC=sso,DC=lab" will have invalid login count raised.


You can see from above smtracedefault.log (using authentication_trace.template) that both users get "Have 1 Password Policies to apply" message.


But only the first UserDN gets "Incrementing Failed Login Attempts Counter" message.


Now you can imaging what will happen when the "CN=user1,CN=Users,DC=sso,DC=lab" successfully authenticates several times exceeding the password policy.


As you can see from above, "CN=user1,OU=People,DC=sso,DC=lab" got locked out.


This is not a desired outcome but this is a special condition that customers should avoid in the first place.

It is not recommended to have multiple users returned during user search.


So, (CN=%s) user search in the userstore configuration is not a good thing.

If you configured the userstore to query (samaccountname=%s) then it would have returned just 1 user so this condition could have been avoided.


(You can also imagine more troublesome use cases, what if both users have SAME password??? Well, don't go there! Avoid it where you can.)

(What if both users forgot their password? Don't go there )


It is by design but even without testing this, you would be able to guess that there would be no way Policy Server can determine which user to update for failed password.


For #3, both users would have their "Failed Login Attempts Counter" increased.

As you can see from above, "CN=user1,OU=People,DC=sso,DC=lab" is already disabled.

"CN=user1,CN=Users,DC=sso,DC=lab" had "Failed Login Attempts Counter" increased.


There are some ways to avoid having multiple users being returned in case if you cannot avoid this situation.

You can use additional attributes to Authenticate in addition to the userID and Pwd.


Please refer to my previous post below.

Configuring an ALL-IN-ONE VM Image - Part 4

It has a section for "HTML using UID and EMAIL".


Instead of having users to enter the additional attribute, you can actually make it a dropdown menu.

So, instead of using "email" attribute, you can use "Department" attribute and can select their department such as "Finance" or "Sales".


That way, you should be able to search for a user and get only 1 userDN in return.


Hope this helps!

CA Single Sign-On Tech Tip by Sau Lai Wong, Senior Support Engineer for 3rd August 2016



Customer observes following errors in Webagent log, every now and then:

== Webagent log ==
[15951/3267352320][Tue May 10 2016 11:03:34][CSmResponseManager.cpp:222][ERROR][sm-AgentFramework-00460] HLA: Analyzer from module 'SM_WAF_HTTP_PLUGIN' returned unknown response code '-1' for component 'Response Manager'.

[15951/3267352320][Tue May 10 2016 11:03:34][CSmHighLevelAgent.cpp:1244][ERROR][sm-AgentFramework-00420] HLA: Component reported fatal error: 'Authentication Manager'.



What invokes the above HLA/LLA error and how to resolve it?



Apply to all R12.x webagents that protect resources with form authentication.



Following are the log snippets corresponding to the HLA/LLA error in Webagent log:


== Webagent Trace ==

[05/10/2016][11:03:34][15951][3267352320][CSmHighLevelAgent.cpp:960][ProcessAdvancedAuthentication][c2bfd700-149d60cceda2][][][][][][Start new request.]
[05/10/2016][11:03:34][15951][3267352320][CSmResourceManager.cpp:180][CSmResourceManager::ProcessAdvancedAuthResource][c2bfd700-149d60cceda2][][][][][][Calling SM_WAF_HTTP_PLUGIN->ProcessAdvancedAuthResource.]
[05/10/2016][11:03:34][15951][3267352320][CSmHttpPlugin.cpp:8554][CSmHttpPlugin::ProcessAdvancedAuthResource][c2bfd700-149d60cceda2][][][][][][Resolved HTTP_HOST: ''.]
[05/10/2016][11:03:34][15951][3267352320][CSmHttpPlugin.cpp:5165][Entered CSmHttpPlugin::ResolveFQServerName sHost: ][][][][][][][]
[05/10/2016][11:03:34][15951][3267352320][CSmHttpPlugin.cpp:5509][CSmHttpPlugin::ResolveClientIp][c2bfd700-149d60cceda2][][][][][][Resolved Client IP address '' from header 'X-Forwarded-For'.]
[05/10/2016][11:03:34][15951][3267352320][SmFCC.cpp:2915][SmFcc::getLocalePath][c2bfd700-149d60cceda2][*][][][][][Localized Path = /opt/CA/webagent/siteminderagent/login.fcc, working locale = default]
[05/10/2016][11:03:34][15951][3267352320][CSmFormTemplateCache.cpp:196][CSmFormTemplateCache::GetForm][][][][][][][Serving form template '/opt/CA/webagent/siteminderagent/login.fcc' from cache.]
[05/10/2016][11:03:34][15951][3267352320][SmAdvancedAuthCore.cpp:632][SmAdvancedAuthCore::parseTargetUrl][c2bfd700-149d60cceda2][*][][][/nikko/app?action][][Resolved cookie domain ''.]
[05/10/2016][11:03:34][15951][3267352320][CSmResourceManager.cpp:218][CSmResourceManager::ProcessAdvancedAuthResource][c2bfd700-149d60cceda2][*][][agent.apache][/nikko/app?action][][SM_WAF_HTTP_PLUGIN->ProcessAdvancedAuthResource returned SmSuccess.]
[05/10/2016][11:03:34][15951][3267352320][CSmLowLevelAgent.cpp:499][IsResourceProtected][c2bfd700-149d60cceda2][*][][agent.apache][/nikko/app?action][][Resource is protected from cache.]
[05/10/2016][11:03:34][15951][3267352320][CSmResponseManager.cpp:193][ProcessResponses][c2bfd700-149d60cceda2][*][][agent.apache][/nikko/app?action][][Calling SM_WAF_HTTP_PLUGIN->ProcessResponses.]
[05/10/2016][11:03:34][15951][3267352320][CSmHttpPlugin.cpp:2777][CSmHttpPlugin::ProcessResponses][c2bfd700-149d60cceda2][*][][agent.apache][/nikko/app?action][][Processing IsProtected responses.]
[05/10/2016][11:03:34][15951][3267352320][CSmResponseManager.cpp:231][ProcessResponses][c2bfd700-149d60cceda2][*][][agent.apache][/nikko/app?action][][SM_WAF_HTTP_PLUGIN->ProcessResponses returned SmSuccess.]
[05/10/2016][11:03:34][15951][3267352320][CSmCredentialManager.cpp:222][CSmCredentialManager::GatherAdvancedAuthCredentials][c2bfd700-149d60cceda2][*][][agent.apache][/nikko/app?action][][Calling SM_WAF_HTTP_PLUGIN->ProcessAdvancedAuthCredentials.]
[05/10/2016][11:03:34][15951][3267352320][SmFCC.cpp:703][SmFcc::getCredentials][c2bfd700-149d60cceda2][*][][agent.apache][/nikko/app?action][][Success in collecting credentials.]
[05/10/2016][11:03:34][15951][3267352320][SmPluginUtilities.cpp:481][HandleCredCollectorReturn][c2bfd700-149d60cceda2][*][][agent.apache][/nikko/app?action][][POST preservation, handling return from credential collector.]
[05/10/2016][11:03:34][15951][3267352320][SmPluginUtilities.cpp:618][HandleCredCollectorReturn][c2bfd700-149d60cceda2][*][][agent.apache][/nikko/app?action][][http response
[05/10/2016][11:03:34][15951][3267352320][CSmCredentialManager.cpp:260][CSmCredentialManager::GatherAdvancedAuthCredentials][c2bfd700-149d60cceda2][*][][agent.apache][/nikko/app?action][][SM_WAF_HTTP_PLUGIN->ProcessAdvancedAuthCredentials returned SmSuccess.]
[05/10/2016][11:03:34][15951][3267352320][CSmLowLevelAgent.cpp:1332][AuthenticateUser][c2bfd700-149d60cceda2][*][][agent.apache][/nikko/app?action][][User 'wonsa03' is not authenticated by Policy Server.]
[05/10/2016][11:03:34][15951][3267352320][CSmResponseManager.cpp:193][ProcessResponses][c2bfd700-149d60cceda2][*][][agent.apache][/nikko/app?action][][Calling SM_WAF_HTTP_PLUGIN->ProcessResponses.]
[05/10/2016][11:03:34][15951][3267352320][CSmHttpPlugin.cpp:2942][CSmHttpPlugin::ProcessResponses][c2bfd700-149d60cceda2][*][][agent.apache][/nikko/app?action][][Processing Authentication responses.]
[05/10/2016][11:03:34][15951][3267352320][SmFCC.cpp:2915][SmFcc::getLocalePath][c2bfd700-149d60cceda2][*][][agent.apache][/nikko/app?action][][Localized Path = /opt/CA/webagent/siteminderagent/login.fcc, working locale = default]
[05/10/2016][11:03:34][15951][3267352320][SmFCC.cpp:2409][SmFcc::doUnauthorized][c2bfd700-149d60cceda2][*][][agent.apache][/nikko/app?action][][Displaying error page: '/opt/CA/webagent/siteminderagent/login.unauth'.]
[05/10/2016][11:03:34][15951][3267352320][CSmFormTemplateCache.cpp:196][CSmFormTemplateCache::GetForm][][][][][][][Serving form template '/var/www/html/login/login.unauth' from cache.]
[05/10/2016][11:03:34][15951][3267352320][CSmHttpPlugin.cpp:3025][CSmHttpPlugin::ProcessResponses][c2bfd700-149d60cceda2][*][][agent.apache][/nikko/app?action][][Unable to verify tryno count, exiting with SmFailure.]
[05/10/2016][11:03:34][15951][3267352320][SmPluginUtilities.cpp:166][DeleteCookie][c2bfd700-149d60cceda2][*][][agent.apache][/nikko/app?action][][Deleted cookie 'SMTRYNO'.]
[05/10/2016][11:03:34][15951][3267352320][CSmResponseManager.cpp:223][ProcessResponses][c2bfd700-149d60cceda2][*][][agent.apache][/nikko/app?action][][SM_WAF_HTTP_PLUGIN->ProcessResponses returned SmFailure.]
[05/10/2016][11:03:34][15951][3267352320][CSmAuthenticationManager.cpp:207][CSmAuthenticationManager::AuthenticateUser][c2bfd700-149d60cceda2][*][][agent.apache][/nikko/app?action][][ResponseManager ProcessResponses returned SmFailure.]
[05/10/2016][11:03:34][15951][3267352320][CSmHighLevelAgent.cpp:1246][ProcessAdvancedAuthentication][c2bfd700-149d60cceda2][*][][agent.apache][/nikko/app?action][][AuthenticationManager returned SmFailure, end new request.]
[05/10/2016][11:03:34][15951][3267352320][CSmLowLevelAgent.cpp:3466][ReportHealthData][][][][][][][Accumulating HealthMonitorCtxt.]


== Policy Server log ==
[1853/4086664048][Tue May 10 2016 11:03:34][SmDsLdapFunctionImpl.cpp:494][ERROR][sm-Ldap-00770] (AuthenticateUser) DN: 'uid=wonsa03,dc=support, dc=com' . Status: Error 49 . Invalid credentials


By design, the error is logged when the failed login attempt count tracked by the SMTRYNO cookie >= to the limit defined with smretries directive in the login form.


In customer case, the smretries was set to 1. Hence, whenever user failed to be authenticated, the error is invoked. Hence, the error is expected and it does not impact the web agent operations.


To avoid the error, set smretries to 0, meaning to say user has unlimited login attempts unless limited by password policy.

CA Single Sign-On Tech Tip by Sau Lai Wong, Senior Support Engineer for 3rd August 2016



The Name ID attribute, a required assertion attribute, identifies a user in a unique way. The Name ID format indicates the identifier type that the federated partners support. The Name ID type specifies the user profile attribute that is associated with the name ID format. The user profile attributes come from a user store or the session store.

At the relying party, the partner must be able to locate a user in the local user directory. Locating the user in the user directory is the process of disambiguation. Configure the identity attribute for user disambiguation in the User Identification dialog.

The Policy Server can use one of the following methods for the disambiguation process:

  • Extract the Name ID value from the assertion.
  • Use the value of a specific attribute from the assertion.
  • Use the value that the Xpath query obtains.The Xpath query locates and extracts an attribute other than the Name ID from the assertion.

After you determine which attribute is extracted from the assertion, include this attribute in a search specification. After a successful disambiguation process, the Policy Server generates a session for the user.


How to nominate preferred attribute as Name Identifier/Name ID in the assertion?


Applies to all Federation Gateway : Webagent Option Pack, Secure Proxy Server and Federation Manager.


For Partnership Federation, Identity Provider can specify their preferred attribute as Name Identifier. Partnerships >> Assertion ConfigurationPartnershipFor Legacy Federation, Name Identifier is fixated:

  • ODBC user store -- Name attribute
  • LDAP user store -- User DN attribute

The additional attribute is included under <SM: SMprofile> tag. Use XPath query to locate and extract an attribute other than the Name ID from the assertion for disambiguation process.


CA Single Sign-On Tech Tip by Sau Lai Wong, Principal Support Engineer for 2nd August 2016



Federation login is failing at Service Provider's signature verification stage:

[03/06/2016][12:49:16.935][12:49:16][26708][4065954672][][verifyXML][1a6f01f9-66967cfe-40e2fce5-b49f63cc-ed28766f-e7][Could not get certificate from trusted key database (IssuerName:, CN=CA Certificate Authority - CA, OU="(c) CA, Inc.", is incorporated by reference, L="CA, Inc.", S=PA, C=US US Serial Number: 12345) ]

[03/06/2016][12:49:16.936][12:49:16][26708][4065954672][][verifySignature][1a6f01f9-66967cfe-40e2fce5-b49f63cc-ed28766f-e7][Exception while verifying signature: Could not get the certificate from the trusted key database.


Validated that the highlighted certificate (with CertificateEnntry type) exists in the smkeydatabase and Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction patches  are applied.



R12.52 SP1 Federation Manager or Policy Server release



Policy Server failed to locate the certificate due to the special character or ASCII character in the issuer DN.



Fix is incorporated with R12.52 SP1 CR6 Policy Server and Federation Manager releases.

There are couple of reasons on Unable to startup apache server with error.

Following KB outline some common issue and further troubleshooting step if suggested resolution didn't help.

Unable to run Web agent uninstaller due to some dependency to the JDK. Following KB outline manual steps to uninstall IIS web agent.