Deployment Architecture to Scale Job Engine
The article discusses different deployment architecture scenarios to scale Privileged Access Management (PAM) utilizing multiple job engine components.
PAM uses Job Engine components to automate scripts executed on managed servers and end-points.
Such scripts include password resets, removing accounts from local Administrator group on Windows computers or privileged account discovery.
PAM WEB Application manages policies and rules to define when and which scripts will be executed on certain servers.
Job engine component actually executes the script and passes the result back to PAM Vault.
Each job engine components is capable to execute multiple scripts in parallel on several different servers using several threads (configured on the Administration / Settings screen).
However, in some cases it is desirable to scale the script execution even more or to target servers in isolated networks.
Component Architecture
PAM contains several components.
When PAM is deployed on a single host all components are installed on the same server and they communicate between each other inside this server.
One of these components is Jobs Engine. Jobs engine connects to a central PAM Vault using the shared database or directly using HTTPS protocol – more about it later.
Job Engine executes jobs from the jobs queue on remote managed servers and updates the job queue with the results.
Job engine could be installed on a separate host than the main PAM WEB application to improve performance of the job execution or to target servers in the networks unreachable by PAM WEB application.
Job Engine should be instructed to use PAM WEB Application to access the job queue.
There are several scenarios connecting Job Engine to the PAM WEB Application each targeting slightly different use case and requiring a slightly different configuration.
Use Cases for Job Engine Deployment
1. Local Job Engines sharing database with the WEB Application
In this scenario, multiple job engines are installed on different computers connected to the same database shared with PAM WEB Application.
This setup helps to improve performance of the job execution with multiple job engines executing jobs from the same queue on servers simultaneously.
PAM balances job execution between several job engines but a job engine can execute any job from the queue.
Prerequisites
-
Working PAM installation.
-
External Database.
-
Server to be enrolled as a Job Engine.
-
Run PAM setup on a qualified computer, select only Worker process to install (do not select Database) and connect to a Database on the setup screen when prompted.
-
On the master node GUI, return to Administration > Settings, and refresh. The remote job engine should appear and will start processing jobs from the job queue reducing the load on other job engine nodes.
Directory Services is a required component of any PAM installation, including remote job engines. If the intended remote job engine does not have an external Directory Services server to connect to during installation, then the installer should also select the "Directory Services" component during the initial setup.
2 . Remote Job Engines operating in isolated networks
In this scenario Job Engine is installed inside the isolated network that cannot be reached from the PAM WEB Application directly.
In this setup Job Engine connects to the WEB Application using specially created service account using PAM API over standard HTTP(s) protocol.
In this case job engine processes only those records from the job queue the specified service account has access to.
This way system administrators can designate certain records for specific job engines to process.
Prerequisites
-
Working PAM installation.
-
Server to be enrolled as a Job Engine.
Configuration for the Remote Job Engine setup assumes that PAM server is installed and operating.
For PAM installations with Federated Sign In configured PRE-installation, the default self-signed certificate will throw an exception during the remote worker registration process because the FQDN is not specified in the common name field. This certificate will have to be replaced by a certificate that does specify the FQDN, which can be done by following these steps.
-
Add a service account in Administration / Local Users to identify new remote job engine.
-
Assign Service role to this account using Administration / Global Roles screen.
-
Under the Manage > Permissions page for the record(s) that should be served by this remote job engine, grant Record Control: Editor, Session Control: None and Task Control: Execute permissions to the service account.
-
On a qualified server in an isolated network, add a new Remote Job Engine by running PAM setup; select Database, Directory and Worker process to install.
-
From the $PAM_HOME directory of the newly installed job engine, import the SSL/TLS certificate of the web master node by running the SSLImport command.
-
If the web node installation has NOT enabled federated sign in OR is listening on standard port TCP/443, then execute the following command line command from the $PAM_HOME folder to successfully connect the newly installed remote job engine with the PAM Server (Command execution should be performed on the newly installed Remote Job Engine node). Otherwise, skip this step entirely and go to step 7.
-
Do not complete this step if you have already completed step 6. For installations with enabled Federated Sign In and port different than default https (tcp/443), generate Token for Service account and manually add on the master node in $PAM_HOME/web/conf/catalina.properties file of the Remote Job Engine Node:
-
go to Administration / Tokens as a user with Service Administrator global role;
-
generate tokens with the IP filter;
-
add in IP Filter IP address of the remote worker.
Make sure that PAM WEB Application is accessible from the remote job engine computer using WEB GUI.
Where:
{pam.server} is the hostname of the PAM WEB Application (such as pam.company.com)
{pam.port} is the port number the PAM WEB Application is running on (such as 443, 6443)
Where:
{pam.server} is the URL of the PAM WEB Application (such as https://pam.company.com/xtam).
{pam.user} is the service account designated for this remote job engine.
{pam.password} is the service account password (or dash to make command to prompt for the password).
This command should return an Ok response when it is executed successfully. If you receive an error message or anything other than Ok, correct the error and rerun the command.
After you receive this Ok response, restart the PAM service (PamManagement or pammanager) on this new remote node to complete the configuration.
After configuration the remote job engine will start monitoring the job queue and execute jobs designated to this remote job engine on the servers in the isolated network.
xtam.remote.enabled=true
xtam.remote.url=IpAdressOfMainNode
xtam.remote.token=<token_here>
#xtam.ad.members.search=false To generate Token:
3. Hybrid setup
It is possible to use multiple job engine nodes connected using different setups described above.
Remote Job Engine configuration could be used to limit the scope of jobs from the job queue even for the networks that could be reached from the central PAM WEB application.
It is also possible to grant a service account an access to all records in the vault so the remote job engine will be used to improve overall performance of the job queue execution.
