CA PAM Best Practice for Policy Creation

[Jorghy Misnan]

I need help to designing access policy under these circumstances:

1. There's around 1000 Linux servers with 12 local accounts that needs to managed by PAM.
2. Each account must have different password for each server. Simply put, for one local account, it will 1000 different passwords.
3. These 12 accounts are separated for 6 different purposes, each also separated into admin and read-only accounts.
4. These 12 accounts have their unique command filtering policy.
5. PAM user will have access to both admin and read-only accounts. Workflow approval will be applied for admin account.
6. Different case, i have 10 pair of primary-secondary Juniper devices that needs to managed by PAM. Every password change done on primary will be forwarded to secondary server. How should i make the policy for this, because i never know when these devices will change role.

Sorry if this seems too much. I already have my own initial design created but i need more input in case there's better one. Thank you.

Regards,
Jorghy

[Joseph Fry]

What you want to do is certainly possible.  I personally would not want to manually vault 12000 accounts and configure policies, so it may be time to learn the API and CLI?

That said, I would recommend that you look at using some sort of central authentication.  LDAP, Radius, TACACS, etc will reduce the number of accounts to manage to just 12 from 12000.  It would also simplify changes to your infrastructure since you will not need to vault 12 new accounts every time you add or replace a server.

On the Juniper, does the change always have to be made on the primary?  Does the cluster use a VIP IP always points to the primary?

[Jorghy Misnan]

I'd love to use central authentication, but this is existing production environment and nothing i can do about it. Do you have any documentation or better, a working application that can already integrated with PAM API? If you do, i'll really appreciate it if you can share it with me.

As for Juniper, password reset can be done on both primary and secondary. I'm thinking of using Compound Account for this. Do you happen to have the default Verify and Update script for Juniper Connector?

[Joseph Fry]

Jorghy,

If you must change the password on both Junipers (it doesn't replicate automatically), then, yes a compound account is the way to go.  That said, I have no experience updating passwords directly on Junipers... most places I have seen use TACACS to authenticate their networking folks.

I would probably have the discussion about centralizing their Linux accounts as well.  Who knows, it may be something they have been postponing and your recommendation will just get the ball rolling.

I have written a lot of scripts, but sadly one that vaults Linux local accounts isn't one of them.  However the example in the documentation covers just about everything you need, if you can read PHP.  It's fairly easy to adapt the important parts in Python, Perl, Powershell, or whatever language you prefer. https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/layer7-privileged-access-management/privileged-access-manager/3-3/programming/external-api-for-integrating-applications/use-the-external-api-programmers/external-api-example-implementation.html

[Jorghy Misnan]

I guess my only option is to learn how to use the API, or wait for Broadcom to implement some kind of csv import function for PAM target account. Anyway, thank you for your input.

[Joseph Fry]

Jorghy,

Unfortunately, the API is the only way to achieve what you want, I wouldn't count on us implementing an import function for target accounts.  You can import devices, users, and policies... but the credential management realm doesn't offer any sort of import functionality.

Here is a simple powershell script to get you started (if you like powershell).  It should be easy to adapt to whatever language your most comfortable with.

Excuse the line wrapping... you would be best served cutting and pasting into Powershell ISE or a decent text editor with syntax highlighting.

# This is a simple demo of the PAM API
#
# The script will prompt you for your api key, and will add a device named "scriptDevice", create a linux/unix target application
# named "scriptApp" for that device, and finally create a target account named "scriptAcct" for that target application.
#
# This is by no means a complete solution, however it will demonstrate the basics of creating a device, linux/unix target
# application, and target account.  From here, you could expand to loop over the lines in a xls/csv file adding many devices.
# Wherever possible, I left and commented out options that you could choose to use, but are not required.
#
# All of the properties set during the creation of the devices are easily obtained by creating a template device/app/acct and
# querying it using the API to determine the appropriate settings to use.  Most settings can be left unset unless you
# want to change the defaults.
#
# It is highly recommended that you become familiar with the integrated PAM "API Doc" on your PAM settings menu (will need to
# enable the api in the config first).  This "doc" is actually more of an interactive testing tool where you can run a single
# api query and view the results... it's invaluable to any PAM API development project.
#
# NOTE: The script below is not suitable for Windows devices.  Unfortunately the devices.json/$deviceId/targetApplications API
# only works with generic or Unix style target applications.  You would need to use the PAM Credential Management API (aka CLI)
# to add a windows target application; a more complex procedure.


#
# This is the only setting you NEED to change to make this script work... of course the resulting device/app/acct will be
# completely unusable for anything, but its good to see the script work if you want to run it after changing this line:
#

$pamServer = "your.Pam.url.here"  # either FQDN or IP address


#
# This section is to prevent errors when connecting to a PAM system that uses a self signed certificate. If your system
# uses a trusted certificate, then you may be able to delete this.
# NOTE: the line with just "@ on it cannot be indented
#
if (-not ([System.Management.Automation.PSTypeName]"TrustEverything").Type) {
    Add-Type -TypeDefinition  @"
    using System.Net.Security;
    using System.Security.Cryptography.X509Certificates;
    public static class TrustEverything
    {
        private static bool ValidationCallback(object sender, X509Certificate certificate, X509Chain chain,
            SslPolicyErrors sslPolicyErrors) { return true; }
        public static void SetCallback() { System.Net.ServicePointManager.ServerCertificateValidationCallback = ValidationCallback; }
        public static void UnsetCallback() { System.Net.ServicePointManager.ServerCertificateValidationCallback = null; }
    }
"@
} [TrustEverything]::SetCallback()


#
# prompt for an API key
#
if (-not $apikey) {$apikey = Get-Credential -Message "Enter your API key"}


#
# run an API call to add a device
#

# first create a hash table that contains all of the data about our new device 
$newDevice = @{
        description = 'This device was added by a script'
        deviceName = 'ScriptDevice'
        domainName = '192.168.168.168'
        location = 'Imaginary'
        os = 'Linux'
        typePassword = 't'
        typeAccess = 't'
        deviceAccessMethods = @{
            arbitraryLabel = @{
                type = 'SSH'
                port = '22'
                #taskProperty = 'x11Forwarding'
                #customName = null
            }
        }
        #tags = FOR SOME REASON THIS DOESNT WORK
        #deviceGroupMembershipIds = null
        #deviceMonitors = null
        #deviceServiceIds = null
        #deviceTerminalData = null
        #deviceVPNServiceIds = null
        #isHostNamePreserved = null
        #overrideAddress = null
        #requestServerActive = null
        #requestServerDescription1 = null
        #requestServerDescription2 = null
        #targetServerDescription1 = null
        #targetServerDescription2 = null
        #transparentLoginType = null
        #transparentPrompts = null
        #typeA2A = null
}

# then convert the hashtable to JSON format
$newDevice = ConvertTo-Json -InputObject $newDevice

# finally post the JSON data to the devices.json API to create the device and write our success message
$deviceId = Invoke-RestMethod -Uri "https://$pamServer/api.php/v1/devices.json" -Method Post -Body $newDevice -Credential $apikey -ContentType 'application/json'
write-host "device id $deviceId added"

#
# Run an API call to add a target application
# Note: Unfortunately at this time this only works for generic and UnixII (linux) target applications
# To add a windows or other type, you must use the credential management API (aka CLI).
#

# first create the hash table that describes the new target application
$newApp = @{
        applicationName = 'scriptApp'
        applicationType = 'unixII'
        attributes = @{
            #changePasswordCommand = null
            #useVerifyScriptType = 'DEFAULT'
            #sshUseDefaultCompressionAlgorithms = 't'
            #useUpdateScriptType = 'DEFAULT'
            #sshUseDefaultCiphers = 't'
            #sshUseDefaultServerHostKeyAlgorithms = 't'
            #sshUseDefaultHashes = 't'
            #unixVariant = 'GENERIC'
            #sshStrictHostKeyCheckingEnabled = 'f'
            #extensionType = 'unixII'
            #sshUseDefaultKeyExchangeAlgorithms = 't'
            #patternMatchingCommand = null
            #changeFilePermissionsCommand = null
        }
        #description1 = null
        #description2 = null
        #passwordCompositionPolicyId = null  #should really set one of these, use the API to get the Id.
}

# convert the hashtable to JSON format
$newApp = ConvertTo-Json -InputObject $newApp

# and call the devices.json/{id}/targetApplications api to create our target application
$appId = Invoke-RestMethod -Uri "https://$pamServer/api.php/v1/devices.json/$deviceId/targetApplications" -Method Post -Body $newApp -Credential $apikey -ContentType 'application/json'
write-host "Target Application id $appId added"


#
# Run an API call to add a target account
#

# first create a hashtable that describes our target account
$newAcct = @{
        accountName = 'scriptAcct'
        password = '_generate_pass_'  #Add the acct with a random pw... or replace it with a known pw
        #passwordViewPolicyId = null  #should really set one of these, use the API to get the ID
        privileged = 't'
        synchronize = 'f'  #Set this to true to have it update the password on the remote system
        useAliasNameParameter = 'f'
        attributes = @{
            discoveryAllowed = 'f'
            protocol = 'SSH2_PASSWORD_AUTH'
            discoveryGlobal = 'f'
            extensionType = 'unixII'
            #descriptor1 = 
            #descriptor2 = 
            #privateKey = null
            #keyOptions = null
            #useOtherAccountToChangePassword = 't'  #This is where you would use a master account to change this password
            #otherAccount = '1122'  # you would need to query the API for the master account id to use here
            #verifyThroughOtherAccount = 'false'
            #passwordChangeMethod = 'USE_SUDO' # this is the equivilent to "use elevated priviliges"
          }
        #aliasNames = null
        #cacheBehavior = null
        #cacheDuration = null
        #description1 = null
        #description2 = null
}

# convert the hashtable to JSON format
$newAcct = ConvertTo-Json -InputObject $newAcct

# then post the JSON data to the devices.json/{id}/targetApplications/{id}/targetAcccounts api.
$acctId = Invoke-RestMethod -Uri "https://$pamServer/api.php/v1/devices.json/$deviceId/targetApplications/$appId/targetAccounts" -Method Post -Body $newAcct -Credential $apikey -ContentType 'application/json'
write-host "Target Account id $acctId added"

[Jorghy Misnan]

Thanks for the script. I'll let you know if managed to use it.

[Ramakrishna Gondalappa]