Skip navigation
All Places > CA Security > CA Privileged Access Management > Blog

Please review this useful information and links to help you be successful with your CA PAM implementation

 

1. Where to download the product?
Note – CA PAM is distributed as Virtual Appliance On Premise, AWS and MS Azure, as well as HW Appliance – for the Virtual Appliance On Premise (OVA):

  • https://support.ca.com/us/download-center.html  
    select:
    - CA Privileged Access Manager (PAM)
    - CA Privileged Access Credential Manager DEBIAN
    - select the latest version available
        (as of this writing it is 3.2)
    - download the OVA file
        (as of this writing it is “PRIVILEGED ACCESS MANAGER R3.2 - ESD ONLY DVD500000000001333.ova”)

 

 2. How to deploy the OVA?

 

 3. Where to find the full Product Documentation?

select “CA Privileged Access Manager” and the latest version

 

 4. How to Login to PAM, how to find out the Serial number, how to request a License and how to apply the License?

 

 5. How to find the available Training Courses to use the product?

(select “CA Privileged Access Manager”)

 

 6. Where to go to first if questions arise?

 

 7. What ports are required for PAM to function properly?

 

 8. How do I configure certificates into PAM?

 

 9. My users don’t have access to the internet and thus cannot download the CA PAM Client from the link in PAM login page. How can I make this work without opening access to the internet?

 

 10. We would like to use the Internet Explorer instead of the PAM Client but the Access Page does not load.

 

 11. Reopening the PAM Client or opening another instance is presenting a "Bind Failure" error.

12. for upgrade information, here is the link the PAM upgrade community page 

We want to hear from you about a CA Threat Analytics as a Service for PAM solution.   

 

Please take 2 minutes to answer 6 (brief) questions about a potential offering. 

 

CA Threat Analytics as a Service for PAM Survey 

 

 

Issue

After disabling the "TLS v1.0/1.1 Connection Allowed" option on the Configuration > Security > Access page, our Linux A2A clients no longer work. It looks like they are not using TLS 1.2 when connecting to the PAM server by default.

 

Cause

The Linux A2A version 4.13 for PAM 3.0.1 comes with a JRE 7 version that by default uses TLS 1.0 to connect to secure web servers. The A2A client does not overwrite the default.

 

Resolution

The problem will not be observed after upgrading PAM and the A2A client to version 3.1.1 or higher. The 3.1.1 A2A client includes a JRE 8 version that uses TLS 1.2 by default. If you have to remain at 3.0.X, you can resolve the problem by adding option "-Dhttps.protocols=TLSv1.2" to the java options in the cspmclient/bin/cspmclientd script on line 64. The difference between modified and original script should look like this:

[root@prira01-U163106 bin]# diff cspmclientd cspmclientd.orig
64c64
<       -Djava.net.preferIPv4Stack=true -Dsun.net.inetaddr.ttl=0 -Dsun.net.inetaddr.negative.ttl=0 -Dhttps.protocols=TLSv1.2 \
---
>       -Djava.net.preferIPv4Stack=true -Dsun.net.inetaddr.ttl=0 -Dsun.net.inetaddr.negative.ttl=0 \

Issue

We used an S3 bucket with name x.y for session recording with PAM 2.8. After upgrade to PAM 3.X the bucket is not mounted successfully.

 

Resolution

PAM uses s3fs to mount an S3 bucket. PAM 3.x includes a newer version with tighter certificate checking. Per information at https://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html please avoid using bucket names with dots when creating buckets for PAM session recordings or database backups:

"When you use virtual hosted–style buckets with Secure Sockets Layer (SSL), the SSL wildcard certificate only matches buckets that don't contain periods. To work around this, use HTTP or write your own certificate verification logic. We recommend that you do not use periods (".") in bucket names when using virtual hosted–style buckets."

Issue

After installing the PAM 3.1.1 remote CLI on a Windows host and preparing the keystore file following instructions at https://docops.ca.com/ca-privileged-access-manager/3-2/EN/programming/credential-manager-remote-cli-and-java-api/install-and-set-up-the-remote-cli-and-java-api, running the capam_command.bat script results in error "Couldn't find the keystore file capam.keystore". The keystore file does exist in the folder from where the command is run.

 

Resolution

This problem will be observed if the remote CLI is copied to a folder that has a space character in its path, such as "C:\CA PAM\Remote CLI". The bat script does not quote file paths. Renaming the parent folders or moving the files to a different folder that has no space characters in its path resolves the problem.

Question:

How do we manage target accounts that are sitting in containers in an Oracle multitenant architecture?  Oracle RAC.

 

Answer:

Oracle 11g release 2 introduced a feature:  SCAN.  Single Client Access Node.  

The Target Application is set up the same way, as if it were a single database, but on the customer side, they replace the Node Name with the SCAN name.

Single Client Access Name (SCAN) is an Oracle Real Application Clusters (Oracle RAC) feature that provides a single name for clients to access Oracle Databases running in a cluster.

More information from Oracle:

Single Client Access Name 

Question

What Cipher Suites are supported by the Active Directory Target Application in PAM 3.1.1?

Answer

The AD target application only connects to the secure 636 port of AD domain controllers. A good way to see which Cipher Suites a secure client supports is to run a network trace somewhere along the network route, or on the AD controller itself, and inspect the "Client Hello" packet. An example is given below for a PAM 3.1.1 AD target application connecting to a domain controller using TLS 1.2:

 

Transmission Control Protocol, Src Port: 51577, Dst Port: 636, Seq: 1, Ack: 1, Len: 252

Secure Sockets Layer

    TLSv1.2 Record Layer: Handshake Protocol: Client Hello

        Content Type: Handshake (22)

        Version: TLS 1.2 (0x0303)

        Length: 247

        Handshake Protocol: Client Hello

            Handshake Type: Client Hello (1)

            Length: 243

            Version: TLS 1.2 (0x0303)

            Random: 5ab9029fceced8d64a24f35f13bfb9e02bdd8c57bdcb7318...

            Session ID Length: 0

            Cipher Suites Length: 100

            Cipher Suites (50 suites)

                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)

                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)

                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)

                Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 (0xc026)

                Cipher Suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 (0xc02a)

                Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)

                Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a)

                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)

                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)

                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)

                Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005)

                Cipher Suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f)

                Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)

                Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)

                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)

                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)

                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)

                Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (0xc025)

                Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (0xc029)

                Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)

                Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040)

                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)

                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)

                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)

                Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004)

                Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e)

                Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)

                Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)

                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)

                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)

                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)

                Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)

                Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02e)

                Cipher Suite: TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 (0xc032)

                Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)

                Cipher Suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (0x00a3)

                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)

                Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)

                Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02d)

                Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 (0xc031)

                Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)

                Cipher Suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (0x00a2)

                Cipher Suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008)

                Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)

                Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

                Cipher Suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc003)

                Cipher Suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA (0xc00d)

                Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)

                Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)

                Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)

            Compression Methods Length: 1

            Compression Methods (1 method)

            Extensions Length: 102

            Extension: supported_groups (len=22)

            Extension: ec_point_formats (len=2)

            Extension: signature_algorithms (len=28)

            Extension: server_name (len=34)

Question

 

Is PAM affected by the recently reported Apache Struts and Jackson-databind vulnerabilities, CVE-2018-1347 and CVE-2018-7489?

 

Answer

CA PAM is not affected by either vulnerability.

Issue

After upgrading PAM from 2.8.3 to 3.0.2, when I click on the Analytics icon on the PAM dashboard a browser session is launched but the page remains empty. When we check recent IdP log entries using the Configuration > Diagnostics > Diagnostic Logs -> Download page, we find some exceptions and a message "Metadata file '/opt/shibboleth-idp/metadata/xcdSPMetadata.xml' does not exist". There are no new entries when we try to launch thread analytics from the dashboard, not event after raising the IdP log level to Verbose.

 

Resolution

This files can be recreated by saving the TCP service created for TAP and restarting the Identify Provider service.

- Go to Services > Manage TCP/UDP services. Find the service with name "TAP-SAML-Server" and edit it, then click "OK" to save it. There is no need to make a change.

- Go to Configuration > Security > SAML, select IdP Configuration and click on UPDATE IDP CONFIGURATION. Again there is no need to make a change. Note that this action will log you out. It should not affect active sessions from other users. After you log on again, the problem should be resolved.

Applying PAM 2.8.3 or 2.8.4 patches to an appliance that is integrated with Thales HSM may cause problems for the Password Management side of the product. This is because either of these two patches may overwrite configuration changes made for the HSM integration. A PAM administrator would find on the dashboard under "Elements Under Management" that the count for target accounts is missing.

This problem cannot be fixed by applying another patch. It can be corrected in a remote session with technical support right after the upgrade.

If you have PAM integrated with Thales HSM at a release lower than 2.8.3, or at 2.8.3 and you want to upgrade to 2.8.4, please open a support case prior to the upgrade to 2.8.3 or 2.8.4, and mention this post in the problem description.

Reference for support is DE331292.

Issue

On UNIX or Linux a privileged account can change the password of any other account by running a "sudo passwd <user>" command, assuming the privileged account is allowed to run "sudo passwd" per configuration in the /etc/sudoers file. The default Update Credentials Script for a target applications of type UNIX is written with that use case in mind.

The root account can run the passwd command without using sudo. However, the default script unconditionally uses the sudo command, or in general the Privilege Elevation Command configured in the target application, when the password change process for a target account is configured with the "Use the following account to change the password" flag. If the root account is configured in PAM as the account to update the password and there is no entry for the root user in the /etc/sudoers file to allow it to run a "sudo passwd" command, the password update attempt will fail. The tomcat log, which can be accessed from the Config > Diagnostics page, will show an exception similar to the following:

com.cloakware.cspm.server.plugin.ClientChannelTimeoutException: Failed to find regular expression pattern(s) while reading from the communications channel: [(?si)(.*?password(\sfor|:).*?)]"

 

Workaround/Solution

There are several ways to avoid this problem. The most obvious one is to allow root to run a "sudo passwd" command. An alternative is to configure a privileged account other than root and allow that account to run the "sudo passwd" command. If the sudo configuration cannot be changed, another option would be to modify the UNIX target application by changing the Privilege Elevation Command setting in the Script Processor section. A dummy "echo ;" command like shown below would allow the update script to work, although it would then work only for the root account and not for accounts that would need elevated privileges to change another account's password. This change would not impact the ability of any account to change its own password.

 

It is also possible to configure a custom Update Credentials script for a given UNIX target application, but that would have to be done by engaging CA support or services and should be considered as a last resort only.

###### [Issue Summary] ######
We have tested the non root accounts in PAM, where we created a user in Linux and tried to integrate it with PAM. After saving the password in PAM, we found that the PAM is not able to change the password neither it can verify the credentials. The GUI is also different since it is the local account in Linux system.

But at the same time, if we map the access of this machine to the user, it is able to give the authenticated session with successful SSO.

 

###### [Troubleshooting] ######

Set the Tomcat logs to INFO. Remember to click on Submit to take effect the change.
Reproduce the error by doing a verify and download the tomcat logs (catalina.out).
Open the catalina.out file and search for the account.  Does it shows a log similar like the one below?:

INFO: received data 'echo 5806851173112548163-$?-5765463665594853060


$ echo 5806851173112548163-$?-5765463665594853060
5806851173112548163-1-5765463665594853060
$ ' does NOT CONTAIN the case-sensitive string '5806851173112548163-0-5765463665594853060'

 

###### [Root Cause] ######

When PAM communicates to the target device to verify the account, it sends an echo $? and expects a 0 as result. If the server returns 1, then it means for PAM that something is not well.

 

You can easily validate this by connecting to the target device and type "echo $?" . What value returns?

 

$? is the return code of the last executed command.

This means that there's an action that didn't end properly in the system or that is on hold.

 

$? is a variable holding the return value of the last command you ran.

The background process pid is available as $!, and $? only reports whether the background command was correctly started.

 

###### [Resolution] ######
If you consider thatre is no risk to skip this status, then you can modify the Verify script and remove this verification status step.
You can modify it and then paste it in the target application settings.

OR
If you consider that PAM should validate the Target device status, then you will have to check from your end what are the process that are taking so long or that are getting on hold.

 

Note: To get the Default scripts, you need to ask to support. Modifying the script is under your responsability. Support can help you if required but is not a Service team.

Symptom
After upgrading to 3.0.1, the appliance is not reacheable via WebGUI.
However the appliance is up and available via VMWare console. The network cards are enabled, but I can't communicate to those appliances anymore.
This only for Virtual Machines.

Cause:
During the upgrade to 3.0.1 all the NICs configured in the virtual machine are connected.
So if there are more NICs connected than the ones enabled in PAM, the system blocks the communications.

Resolution:
Compare the Network Interfaces cards enabled in the server settings and in the Interface Network Settings in PAM console.
The number of Network Interfaces enable has to match.
If there are more NICs connected, then proceed to disconect them and restart the machine.


If issue persist, please contact Support.

Question:

 

Customer is using sesudo on a shell script created by their support team. Sesudo receives some large parameters and when we tried to execute the command, the following error appeared:
"sesudo: Parameter is too long."
Is it possible to increase the parameter length that sesudo accepts?

 

Answer:

 

sesudo has a limit of 255 characters on its command line, and it is not configurable. Looking at their script, a good workaround would be a wrapper script - an intermediate script containing the parameters (${ARGXSU[1]} ${ARGXSU[2]} ${ARGXSU[3]} ${ARGXSU[4]} ${ARGXSU[5]} ${ARGXSU[6]} ${ARGXSU[7]} ${ARGXSU[8]} ${ARGXSU[9]}) that would be called by sesudo, making it a shorter command line without losing functionality.