As a security administrator, you want to audit the actual user of your server, not the shared local privileged user name. CA Privileged Access Manager Server Control Login Integration allows CA Privileged Access Manager to integrate the login process and information with CA Privileged Access Manager Server Control. When activated, it allows the use of the actual CA Privileged Access Manager user name for auditing in CA Privileged Access Manager Server Control.
Make sure you download the latest hotfix for CA PAM (3.1.1.07) which can be found under the Solutions & Patches page. We found out that in releases before 3.1.1.07 that the public_addr object has a NULL value inside which is why sewhoami -a was not showing the correct user because there was a disconnect.
PAM Required Configuration
1. PAM configured and verified to PAMSC under (PAM) Configuration > CA Modules > CA PAM Server Control
2. Target Account, Device, and Application configured and working without Login Integration checked under CA PAM Server Control for the policy in PAM. Note, for this test we need to make sure the target account is a local user on the box.
PAM Server Control Endpoint
1. SSH loginappl setup for PAMLOGIN. Example Below:
AC> sr loginappl SSH
Data for LOGINAPPL 'SSH'
Defaccess : X
Audit mode : Failure
Update time : 08-Mar-2017 11:25
Updated by : root (USER )
Comment : Predefined rule for Login application.
Login flags : PAM login
2. Login with a local user (not root) and run sehwoami -a. Does this show the correct user that logged into the server? If not (as the latest in the support case 00971144) the integration is not going to work.
3. The local user you will login with from PAM needs to have the pupm_flags(use_original_identity)
AC> su Bob
Data for USER 'Bob'
Audit mode : Login-Success, Failure, Login-Failure
Owner : root (USER )
Gracelogins : 1
Admin Pwd change : 06-Apr-2018 15:06
Pwd changed by : root (USER )
Create time : 06-Apr-2018 15:06
Update time : 06-Apr-2018 15:06
Updated by : root (USER )
Pupm flags : Use original identity
4. General Endpoint configuration
Set Configuration Tokens (these should be set already and can be verified)
seini -s seoswd.agent_manager_check_enabled yes
seini -s daemons.AgentManager "yes, /opt/CA/AccessControlShared/lbin/agent_manager.sh start"
seini -s PUPMAgent.OperationMode 1
seini -s AgentManager.Plugins PupmAgent /opt/CA/AccessControlShared/accommon.ini
seini -s PupmAgent.OperationMode 1 /opt/CA/AccessControlShared/accommon.ini
Debug Flag On (these should be set already and can be verified)
seini -s PUPMAgent.OperationMode 2
seini -s AgentManager.TraceEnabled 1 /opt/CA/AccessControlShared/accommon.ini
Distribution Server Set :
# cat /etc/accommon.ini | grep Distribution_Server
Distribution_Server = ssl://SERVERNAME:61616
If you continue to experience issues, there are two sides to check to see where the bottleneck is occuring. First, we need to make sure PAM is dropping the right message inside the ActiveMQ.
On the PAMSC endpoint, shutdown the CAPAMSC endpoint and ensure all AgentManager services are killed. If they are not after running 'secons -S' then a 'kill -9 PID' would suffice too:
# /opt/CA/AccessControl/bin/secons -S
Ensure all daemons are down:
Reproduce the issue inside the CA PAM console. You should expect the terminal to hang. Once that is done, go to your ActiveMQ server (i.e., https://ActiveMQ_server_here:8161/) and login with your credentials used you set during the PAMSC Management Server or ActiveMQ installation. The communication key is what is needed for the password. Once you login to the ActiveMQ, you want to click "Manage ActiveMQ broker" -> "Queues" -> "ac_server_to_endpoint" -> "View Consumers" and you should see a message like this:
So we can confirm that CA PAM is dropping a message inside the ActiveMQ for the AgentManager service. Now we need to check the PAMSC endpoint to ensure we are reading the right data inside that specific queue.
# vi /opt/CA/AccessControl/data/PUPMAgent/PUPMAgent_Trace.log:
23-Mar-2018 12:40:38: _ProcessPreLogonNotification> Received prelogon integration message. ACID="PAM_ENDP_INTEGR"
23-Mar-2018 12:40:38: _ProcessPreLogonNotification> Integration message correlation ID = "LINGO:5"
23-Mar-2018 12:40:38: _ProcessPreLogonNotification> ACCOUNT_NAME --> "Bob" was received.
23-Mar-2018 12:40:38: _ProcessPreLogonNotification> ORIG_ACCOUNT_NAME --> "super" was received.
23-Mar-2018 12:40:38: _ProcessPreLogonNotification> CHECKOUT_HOST_NAME --> "22.214.171.124" was received.
23-Mar-2018 12:40:38: _ProcessPreLogonNotification> ORIG_ACCOUNT_REPOSITORY --> "RDB" was received.
23-Mar-2018 12:40:38: _ProcessPreLogonNotification> IS_ORIG_ACCOUNT_NATIVE_USER --> "YES" was received.
You should be able to see a PreLoginNotification event inside the PUPMAgent_Trace.log.
If you don't see this, then perform a seosd.trace and we need to see if there are any PAMLOGIN events happening. PAM needs to be setup correctly in order for this integration to be successful.
# /opt/CA/AccessControl/bin/secons -tc -t+
(clears and then starts the trace)
2. Reproduce the warning or denial message.
# /opt/CA/AccessControl/bin/secons -t-
(stops the trace)
# cat /opt/CA/AccessControl/log | grep -i pamlogin
You should see 'PAMLOGIN' events here.