Unofficial CA Single Sign-On Guide, Chapter 2: The Installation Debugger

(This is the second chapter in our new series, the Unofficial CA Single Sign-On Guide. You can find Chapter 1 here.)

I’m sure you’ve seen it! Whether it was on one of those tacky motivation posters or during a 3 a.m. Tony Robbins infomercial… the concept of "trust". It is usually demonstrated by somebody blindly falling backwards and trusting their partner or team to catch them. It looks convincing when you see it on television, but if you are like me you start wondering how many takes it took to make it look that easy. I believe it is part of human nature to want to ‘Trust’ but in the end we usually go with ‘Trust, but verify!’. That verification piece is especially important when it comes to your SSO solution!

If you have installed a CA security product in the past, you have no doubt seen one of the following conclusion messages: ‘Installation Successful’, ‘Installation Successful but with errors’ or ‘Installation Failed’.  Unfortunately, these messages are not always accurate. I have seen successful completions that were…. well…not successful. Other times it was successful with errors, but when you review the installation log there is little to no information in it.   So, what is one to do?

This brings us to the installation debugger. It is not in the manual, and often when I am on-site with a client they have no idea this function even exists but Yes, Virginia: there is a debugger!

Below are the methods for starting the debugger during Windows and Linux installations of CA Single Sign-On:


Running the debugger in Windows is very simple. Once you start the installer just hold down the [Ctrl] button during the initialization screen (see below) until you see a DOS box pop up in the background.  Once the DOS box has opened you can release the [Ctrl] button and continue with your install.   One important thing to note for Windows is that the DOS window will close once you have exited the installer so before you hit that final button to exit, be sure to select all the content of the DOS window and copy and paste to a text editor so that it can be saved for reference.   

Initialization Screen - Hold down the [Ctrl] button until you see the screen below then release the control button.

Initialization Screen - Hold down the [Ctrl] button until you see the screen below then release the control button.

You know the debugger has started once you see this DOS window pop-up in the background.

You know the debugger has started once you see this DOS window pop-up in the background.


Unlike Windows, running the debugger in Linux will automatically write the content to a log file. 

Before running the installation script, enter the following command (note this command could vary slightly depending on the shell in use)

export LAX_DEBUG=true

 Then start the installer script as you normally would.

Running the debugger during the installation will not ‘fix’ a potential problem, but it may provide some specific information (or errors if you are lucky) to assist you with finding the source of the problem so that you can resolve it.


Extend CA Single Sign-On with Axiomatics!

Two decades in the Identity & Access Management space has exposed us to our fair share of “where did we go wrong?” scenarios - organizations that thought they were following best practices and ended up creating problems for themselves over time.  One especially problematic area has to do with role management and traditional RBAC (role-based access control). Often, organizations start off with the best intentions and establish just a few roles:

  • Admin
  • Employee
  • Customer
  • Partner

The roles become more granular over time:

Admin Employee Customer Partner
SuperAdmin Employee - HR Customer - Platinum Support Partner - Support
RegularAdmin Employee - IT Customer - Gold Support Partner - Implementation
LightAdmin Employee - Sales Customer - Trial Partner - Temp
AdminTemp Employee - Support Customer - Temp Partner - Marketing

Before you know it, that “handful” of roles you started with has expanded into a tangled web, creating an administrative burden and taxing the systems whose rules rely upon them. CoreBlox has seen environments that have over 15,000 roles! In the IAM industry this is generally referred to as the dreaded “role proliferation” (cue Darth Vadar theme).

Fortunately, there is a great alternative to RBAC. Our partner, Axiomatics, has pioneered the concept of Attribute-Based Access Control, also known as “ABAC”. The thought process behind ABAC is easy to understand: why create new data attributes to manage (e.g. Roles) when you can let the user data speak for itself?

Organizations that already use CA Single Sign-On for web access control have a distinct advantage when it comes to implementing an ABAC approach. The Axiomatics Extension for CA Single Sign-On allows policy decisions to be made by Axiomatics’ ABAC-based engine. A simple yes/no response is returned to CA SSO based upon the user’s attributes. It just works, no coding necessary!

Are you interested in exploring the benefits of ABAC for your organization? Download this new white paper: Making a Business Case for Attribute Based Access Control

Unofficial CA Single Sign-On Guide, Chapter 1: Ports!

One of the most common questions that comes up during CA Single Sign-On Professional Services engagements is: “What ports do I need to open for CA Single Sign-On?". This is generally followed by: “What does each port do?”. These are great questions and we wanted to consolidate the answers in one place. And so, without further ado, CoreBlox proudly presents our first chapter in our Unofficial CA Single Sign-On Guide: Ports!

When CA Single Sign-On is configured correctly, it just works and it works well! Sometimes getting through that initial configuration can be a bit like playing a game of Tetris, especially in an organization that relies on firewalls to control access to specific ports.

Below is a list of the default ports that are commonly associated with CA Single Sign-On implementations. By no means is this definitive, as configurations will vary between organization based upon requirements and standards. However, this is a good starting point when working with security and network teams during the installation and configuration of CA Single Sign-On.

Port # Use Open Between Comment
44441 Web Agent Accounting Port Web Agent / Policy Server Accounting Port
44442 Web Agent Authentication Port Web Agent / Policy Server * Required - Peforms Authentication Requests to Policy Server
44443 Web Agent Authorization Port Web Agent / Policy Server * Required - Peforms Authorization Requests to Policy Server
44444 Web Agent Administration Port Policy Server Not used by the WebAgent , Used by Policy Server for AdminUI
8080 AdminUI HTTP Browser / AdminUI Service Used for non-secure connection to the WAMUI console
8443 AdminUI HTTPS Browser / AdminUI Service Used for secure connection to the WAMUI console
8180 JBOSS Service Ports Browser / JBOSS Not used in normal operation
389 LDAP Policy Server / User-Policy Store Used for non-secure connection to an LDAP Sever
636 LDAP (Secure) Policy Server / User-Policy Store Used for secure-connection to an LDAP Server
1433 SQL Policy Server / User-Policy Store Used for communication with an SQL data source
44449 OneView Agent OneView Agent/ OneView Montor Used for communication between the OneView Agent and Montitor
44450 OneView Monitor Browser / OneView Monitor Port used by the OneView Montior
7680 Enhanced Assurance/Device DNA Access Gateway / Policy Server Used for Session Assurance Functionality
8080 Access Gateway ProxyUI Browser / ProxyUI Should not be installed on same server as AdminUI
543 Access Gateway ProxyUI Browser / AdminUI Service SSL for port for ProxyUI
8001 SMNP Agent SMNP Agent / SMNP Monitor Used if SMNP has been configured
161 SMNP Port SMNP Service Used if SMNP has been configured
80 HTTP Browser / WebAgent Standard Communication Port
443 HTTPS Browser / WebAgent Standard Communication Port