We get error code 409 from an A2A client request. Per online documentation, e.g. on page https://techdocs.broadcom.com/us/en/symantec-security-software/identity-security/privileged-access-manager/4-0/reference/messages-and-log-formats/credential-manager-client-return-codes.html, this error points to an unauthorized script name:
error.code.409=Unauthorized script name.
In the Account Requests report on the Credentials > Reports > Run page, the error description is "PAM-CM-0575: Unauthorized script name."
We think we have the correct script and mapping. How can we check what parameters the A2A client passes to the PAM server to see where the mismatch is?
Applies to any supported PAM release as of July 2021.
The following procedure should allow you to see the script name, execution and file path that the A2A client passes into PAM, which in turn should allow you to update your A2A Scripts and Mappings configurations accordingly:
- On the Configuration > Diagnostics > Diagnostic Logs page set Tomcat Log Level to Info and click on the SUBMIT button. There should be a message on top confirming the log level update.
- Wait 30 seconds for the log level change to kick in.
- Stop the A2A client. If possible, change the PAM server address in the cspmclient/config/cspm_client_config.xml file to point to the specific PAM server on which you changed the log level. If you have to use a site VIP, you'll have to change the log level on all PAM servers that the VIP could connect to.
- Remove the cspmclient/config/data/.cspmclient.dat cache file.
- Start the A2A client.
- Make the A2A request from the client to reproduce the problem.
- Go back to the configuration page and set the log level back to what it was, if applicable.
- On the same Diagnostic Logs page, click on the Download tab and download the tomcat log (first download button). If you used a VIP, do this for all nodes that the A2A client may have connected to.
- Edit the tomcat log file with a good text editor that allows backward search, such as Notepad++.
- Go to the end of the file and search backwards for string "GetScriptCredentialsCmd validateParameters". You will find a message similar to the following:
Jul 08, 2021 6:32:14 PM com.cloakware.cspm.server.app.impl.GetScriptCredentialsCmd validateParameters
INFO: hostname:myhostname.my.domain, IP:10.11.12.13, port:null, version:4.13.1, clientType:java osName:Windows Server 2012 R2, osVersion:6.3, osArch:x86 fipsEnabled:true, clientToken:{0}xxxxxxxx fingerprint:xxxxxxx nodeIdXML:<?xml version="1.0" encoding="utf-8" ?><nodeid><macaddr>xx:xx:xx:xx:xx:xx</macaddr><macaddr>xx:xx:xx:xx:xx:xx</macaddr><machineid>xxxxxxx</machineid><applicationtype>cspm</applicationtype></nodeid>, targetAliasName=cmdb, scriptName=cmd.exe, scriptFilePath=C:\Windows\System32, scriptExePath=D:\cspm\cloakware\cspmclient\bin, scriptHash=xxxxxxxxxxxxx, executionUID=xxxxxxx
In this example scriptName is cmd.exe. You may have run a script from a cmd Windows on a Windows host and entered that script as scriptName in PAM, but Windows in fact runs the cmd.exe process to execute the script, and so cmd.exe would have to be used as script name in the A2A Scripts configuration.
The 409 error generally means that no mapping is found. In cases where you don't define any specific scripts for your A2A clients and create all mappings with the "All" scripts option, message "Unauthorized script name" can be misleading. However, from a PAM perspective the workflow is that when an A2A request from a script/process running on an A2A client comes in, the PAM server checks if a mapping is defined for the script the A2A client sent with the request, either a specific mapping or one with the "All" scripts option. If neither one is found, the 409 error is returned. The PAM server only knows that this script is not authorized. It does not distinguish between the case where no mapping exists at all, and the case where one exists, but for a different script name/path. It returns the same code and message in both cases.