Creating a PMD tiered hierarchy to organize accounts based on environment

Products

CA Privileged Access Manager - Server Control (PAMSC)

Issue/Introduction

Currently all of our PMD subscribers point to a single master PMD . We need the ability to not share all accounts with all machines so we need a method to breakup the PMD into multiple but still share some admin accounts.

Resolution

The best way to accomplish this is to create a tiered hierarchy to maintain one general set of users and distribute their passwords to the endpoints based on individual policies (individual PMDs). Each PMD can maintain its own individual password database to distribute to all endpoints that subscribe to it. Each endpoint can subscribe to multiple PMDs to receive updates from several sources.

Implementing a Tiered PMD Hierarchy

Overview: This architecture uses a hierarchical approach to manage a general set of users while distributing passwords to endpoints via localized Policy Model Databases (PMDs). This allows for granular control while maintaining a central source of truth.

High-Level Workflow

Create the new Sub-Master PMD.
Configure the Sub-Master to start automatically on boot.
Subscribe the Sub-Master PMD to the Master PMD.
Reassign endpoints from the Master PMD to the new Sub-Master.

1. Creating the Sub-Master PMD

Use the sepmdadm utility to define the new PMD.

Command Syntax:

sepmdadm --pmdname <sub-master-PMD> --admin <User> --auditor <User> --desktop <hostname> --parentpmd "<MasterPMD@hostname>"

Example:

sepmdadm --pmdname dev --admin root --auditor user --desktop localhost --parentpmd "[email protected] "

2. Configuring Auto-Start for New PMDs

To ensure PMDs persist after a reboot, modify the seos.ini file.

Stop services: secons -s

Edit /etc/seos.ini: Under the [daemons] section, add a line for each PMD.

Example Configuration:

[daemons]
sepmd=/opt/CA/PAMSC/bin/sepmd -S master-pmd
sepmd=/opt/CA/PAMSC/bin/sepmd -S dev-sub-pmd
sepmd=/opt/CA/PAMSC/bin/sepmd -S prod-sub-pmd

Note: You must stop the seos service before manual file edits.

3. Establishing the Hierarchy (Subscriptions)

The Sub-Master needs to subscribe to the Master for updates.

Command Syntax:

sepmd -n <MasterPMD> <sub-master-pmd>@<hostname>

Example:

sepmd -n master [email protected]

Note: When running sepmd -L master, subscribers that are other PMDs are identified by the @ symbol (e.g., [email protected]), whereas standard endpoints appear as simple hostnames.

4. Transitioning Endpoints

If an endpoint is already connected to the master, you must unsubscribe it before moving it to the sub-master.

Remove from Master:

sepmd -u master endpoint1.example.com

Subscribe to Sub-Master:

sepmd -s dev endpoint1.example.com

5. Updating Endpoint Configuration

Endpoints need their internal configuration updated to recognize the new parent.

Setting	Description
parent_pmd	Defines the source of policy updates (supports comma-separated list).
passwd_pmd	Defines the source for password updates (defaults to `parent_pmd` if blank).

Methods to Update Settings:

Method A: While Services are Stopped (CLI)

seini -s seos.parent_pmd <sub-master-pmd>

Method B: While Services are Running (Selang Prompt)

selang
pamsc> env config
pamsc> er config seos.ini section(seos) token(parent_pmd) value('new-sub-pmd')

Method C: One-liner while Services are Running (Silent/Scripted)

selang -s -c "env config; er config seos.ini section(seos) token(parent_pmd) value('new-sub-pmd')"

Additional Considerations

UID Synchronization

Linux UIDs must remain consistent across the hierarchy.

Best Practice: Before creating users in the new Sub-Master, copy the password file from the Master:
cp /opt/CA/PAMSC/policies/<master-pmd>/passwd /opt/CA/PAMSC/policies/<sub-master-pmd>/passwd
Verification: Ensure sync-uid is set to yes in the /opt/CA/PAMSC/policies/<sub-master-pmd>/pmd.ini.

Multiple Parent Risks

While an endpoint can subscribe to multiple PMDs, avoid modifying the same account password in two different PMDs. This creates "race conditions" where the last update received wins, potentially causing login failures across your environment.To ensure all user UID's remain consistent all new users should be created on the top level. You can manage the passwords at the highest level policy to distribute the passwords only to the endpoints that require that user.

Additional Information

For additional details onthis topic see https://techdocs.broadcom.com/us/en/symantec-security-software/identity-security/privileged-access-manager-server-control/14-1/administrating/endpoint-administration-for-unix/policy-model-database-unix/configure-automatic-rule-based-policy-updates/how-you-can-set-up-a-hierarchy.html