Skip navigation
All Places > CA Security > CA Single Sign-On > Blog > 2018 > February
2018

Picture this: the next time you open your mobile banking app, someone is already logged in and it isn’t you. Or, in your IT environment, multiple users are logged into an app and they’re all using the same credentials. One may be a bad guy, but with concurrent logins and no accountability or attribution it’s not easy to figure out which one. When a worst-case scenario erupts, suddenly your company becomes the next security breach headline. One simple way to avoid that nightmare is by limiting concurrent logins.

 

There are many good reasons to limit the number of times a user can be logged in, but finding a good solution isn’t always easy. Look for options that can be configured to record the session ID immediately after a user authenticates, or that can be configured to capture the sessions during the authentication process itself. This provides a crucial layer of security to protect both your environment and your users.

 

Also look for a solution that has minimal impact on users, limiting concurrent logins should not prevent an authorized access – just because I forgot to log out in the office should not prevent me from accessing from home.

 

With CA SSO, we have an option called “Limit Concurrent Login.” In addition to recording session IDs immediately after authentication, or capturing sessions during the authentication process, it is flexible enough to allow multiple active sessions – up to a limit. Once a user reaches that limit, it prompts the user that the oldest active session will be terminated. If you don’t have this capability now, we can deploy a packaged work product (PWP) add-on that also delivers extra peace of mind.

 

The next time you wake up in a cold sweat from that dream where your users are sharing credentials, or you envision failing a compliance audit because access isn’t attributable to an individual user, don’t worry – there’s an app for that. The CA SSO Limit Concurrent Login PWP

 

Senior Services Architect Gary Figg figga01 hosted a complimentary live webcast on February 23.  During the webcast, Gary provided an in-depth look at the CA SSO Limit Concurrent Login PWP. View the replay.

 

What nightmares have you had with concurrent logins? Share your experiences in the comments below.

 

Click here to connect with a Services expert.  

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