Password Safe Discovery & Auto-Onboarding: — Smart Rules That Find Every Account

① Why discovery comes first — you cannot vault what you cannot see

Meera, an L2 engineer at Flipkart, gets a one-line audit question: “How many accounts can log in as an administrator on these 300 servers?” Honest answer: nobody knows. There is the local Administrator cloned onto 60 VMs from one golden image (same password everywhere), a service account created by an engineer who left in 2023, and a Jenkins box at 192.168.7.23 that never made it into the CMDB. PAM projects fail at this step — not at vaulting. You cannot rotate, broker or audit a credential you have never seen.

BeyondTrust’s answer is the Discovery Scanner — the docs call it “the engine that performs all discovery scans”. Think of it as a census enumerator going door-to-door: it visits every house (IP) in its area (address group), lists residents (accounts) and house details (services, software), and only then can the government issue ration cards (onboarding). One more thing the docs are strict about — the setup steps “must be completed in the order presented”: functional account → password policy → discover/add assets → managed systems → managed accounts → Smart Rules. You cannot onboard accounts until you have onboarded systems, and you cannot onboard accounts at all without a functional account for that platform.

A scan needs three ingredients. (1) A scan credential — created at Configuration > Discovery Management > Credentials → Create New Credential (fields: Credential Name, Type), stored AES-256 and pushed to the scanner. On Windows targets this account must be a true local admin: the scanner mounts the IPC$ admin share, makes remote WMI and registry calls, and drops a small discovery-agent service. (2) An address group — the IP ranges to sweep. Keep them segment-sized (one /24 at a time, like 10.20.8.0/24), not “the whole 10.0.0.0/8”. (3) A schedule — off-hours, repeating, because discovery is a heartbeat, not a one-off. In Password Safe Cloud the scanner ships inside every Resource Broker; on-prem it runs from the U-Series appliance.

Reading results without drowning: open the Assets grid and resist the urge to onboard everything. First, leave the Software collection checkbox OFF unless you need it — BeyondInsight 24.3 made that the default because software collection “often slows scans or causes failures”. Then hunt three red flags: the same-named local admin on many boxes (golden-image twins), service accounts with multi-year-old passwords, and assets nobody can name an owner for. Those three lists are your first onboarding waves — everything else can wait.

The four nouns of onboarding

Tap each card — every sentence in this lesson stands on these four.

② From found to managed — the Smart Rule onboarding pipeline

Found is not managed. Discovery fills the Assets grid; the conversion to vaulted, rotating credentials is done by Smart Rules — Password Safe’s auto-sorting office. Mumbai dabbawala logic: every tiffin (account) carries a code (its attributes), and the sorter (rule) reads the code and routes it to the right train (Smart Group) — automatically, every day, including tiffins that appear next month. With a Password Safe license there are four rule types: Asset, Managed Account, Managed System, Policy User. The classic chain is an Asset Smart Rule that turns discovered assets into managed systems, then a Managed Account Smart Rule that onboards the accounts on them.

Anatomy of any rule, from the left menu Smart Rules → + Create Smart Rule: Selection Criteria (the IF) and Actions (the THEN), with a Reprocessing Limit in the Details section. For Managed Account rules the criteria menu includes Directory Query, Dedicated Account, Microsoft Entra ID Query and Directory Attribute Match. The action strings you will use daily: “Manage Account Settings” (the onboarding workhorse), “Show managed account as Smart Group”, “Link domain accounts to Managed Systems” and “Map Dedicated Accounts to” a user group.

Build the rule: Server-OU local Administrators, step by step

1. Name it for ownership — Onboard – Server OU local Administrators. One rule = one account population; the name should say which.
2. Type: Managed Account.
3. Selection Criteria (IF): asset belongs to the Smart Group for the Servers OU, AND account name equals Administrator.
4. Action 1 — Manage Account Settings: onboard the account, link functional account FA-win-rotate, apply password policy Tier1-30day, enable automatic password management.
5. Action 2 — Show managed account as Smart Group: this is what you will assign access policies and permissions against later.
6. Details → Reprocessing Limit: once a day is plenty for a stable OU. Hit Create Smart Rule — and remember the docs: a Smart Rule is always processed when first saved or updated, so it runs right now.

The processing model explains 90% of “why did that happen” tickets. A rule processes when it is created or edited and saved, when its timer expires, when asset changes are detected, or when you click Process on the Smart Rules grid. Directory-backed rules come with a documented patience warning: “There can be delays when a Smart Rule depends on external data source, such as LDAP.” Also: built-in rules carry a lock icon and cannot be deleted, and a rule referenced by another rule cannot be deleted or deactivated.

# 128-char API key comes from your BeyondInsight API registration
export PS_KEY=$(cat ~/.ps_api_key)

curl -sk -X POST -c ps.cookies \
  -H "Authorization: PS-Auth key=$PS_KEY; runas=FLIPKARTLAB\svc-psapi;" \
  https://10.20.5.40/BeyondTrust/api/public/v3/Auth/SignAppIn

curl -sk -b ps.cookies \
  https://10.20.5.40/BeyondTrust/api/public/v3/ManagedSystems

{"UserId":12,"UserName":"svc-psapi","Name":"PS API service user"}
[{"ManagedSystemID":54,"SystemName":"WIN-APP-114","WorkgroupID":1},
 {"ManagedSystemID":55,"SystemName":"LIN-DB-07","WorkgroupID":1}, ...]

③ Onboarding patterns per platform — and the dependency trap

One pipeline, five flavours. A managed system can be “a computer or device where one or more account passwords are to be maintained” — Windows, Unix/Linux, network devices, databases, firewalls, routers, even LDAP/AD domains. What changes per platform is (a) what the functional account needs (set via its required Entity Type and Platform fields at Configuration > Privileged Access Management > Functional Accounts) and (b) which criteria select the accounts.

Windows local admins are the classic first wave: criteria = asset Smart Group + account name Administrator, functional account = a domain account holding local-admin rights via GPO (or a local FA per box on standalone systems). Remember the golden-image trap: 60 clones share a name and a password, but each is a separate local account on a separate system — onboarding makes each one unique on the next rotation, which is exactly the win. AD domain accounts ride a Directory Query, and the FA needs only delegated password-reset plus lockout-attribute read/write rights — not Domain Admin. One nuance: members of protected groups (think Domain Admins) have delegated rights stripped by AD itself, so vaulting those needs extra AD-side steps.

Linux root and service accounts: the FA logs in over SSH as a normal user and needs root privilege or sudo elevation configured in the platform settings; criteria are usually account-name patterns (root, svc-*). And tattoo this on your wrist: never onboard the functional account itself as a managed account — BeyondTrust’s own guidance says passwords “could fail to synchronize”, which means every rotation on that platform dies at once. Network devices (routers, firewalls) onboard by platform + address group; the field gotcha is prompt-matching on custom platforms — one wrong prompt regex and an F5 BIG-IP rotation fails with “Thread was interrupted from a waiting state”. Databases: the FA is a DB login with password-change rights, but plan hands-on time — practitioners on PeerSpot report database onboarding stays largely manual (“no Smart Rules for databases”, as one reviewer put it).

Dependent systems — the propagation preview

Here is the trap that separates L1 from L2. svc-backup is an AD service account — and it is also the logon identity of Windows services on 14 servers, two IIS app pools and a scheduled task. Rotate it in AD alone and nothing breaks immediately… until each service restarts, tries the cached old password, and dies with logon failures (and enough failures can lock the account domain-wide). Password Safe models this with linked accounts — the Smart Rule action “Link domain accounts to Managed Systems” ties the domain account to every system that uses it, so rotation can propagate the new secret to each dependent service. The full propagation mechanics are lesson 6; your onboarding job is to capture the map now.

Get-CimInstance Win32_Service |
  Where-Object { $_.StartName -like "*svc-backup*" } |
  Select-Object Name, StartName, State

Name          StartName               State
----          ---------               -----
VeeamAgent    FLIPKARTLAB\svc-backup  Running
SQLAgent$BK   FLIPKARTLAB\svc-backup  Running
ArchiveTask   FLIPKARTLAB\svc-backup  Stopped

④ Scaling + hygiene — crown jewels first, no rotation storms

Aditya at ICICI has 6,000 discovered accounts and a project manager asking “why aren’t they all vaulted yet?”. The senior answer is phasing. Wave 0: a 20-system pilot to prove scan → rule → rotation end-to-end. Wave 1: crown jewels — domain admin accounts, the AD functional accounts’ home platforms, Tier-0 infrastructure — because that is where breach impact lives. Wave 2: server local admins and mapped service accounts. Wave 3: the long tail (workstations, lab boxes). Risk drops fastest per hour of work, and every wave teaches you something the next one needs.

Now the storm warning. With automatic password management enabled, an account’s password is set on onboarding and changed at the next scheduled rotation — default ChangeTime 23:30 UTC. Onboard 6,000 accounts on Friday evening with auto-management on, and that night Password Safe attempts thousands of changes at once: unmapped service accounts break, the Password Change Agent retry queue (“Retry failed changes after (minutes)”, “Maximum retries”) silently swells, and Monday’s helpdesk melts. The fix is boring and beautiful: onboard in waves, map dependencies first (section ③), stagger change times across waves, and watch the failed-changes queue like a hawk after each one.

Exclusions are a design feature, not an afterthought. Three things stay out of your auto-onboarding rules: (1) break-glass accounts — the sealed emergency admin is the fire-alarm glass box: it must work when Password Safe itself is down, so it is vaulted and alerted-on but kept OUT of auto-rotation, and rotated manually after every use; (2) the functional accounts (you know why by now); (3) any population another rule already owns — overlapping rules with different actions is the documented endless-overwrite loop. Build the exclusion into the rule criteria itself (name patterns, OU exceptions) so a future teammate cannot “accidentally fix” it.

curl -sk -b ps.cookies \
  "https://10.20.5.40/BeyondTrust/api/public/v3/ManagedAccounts?type=domainlinked"

[{"ManagedAccountID":301,"AccountName":"svc-backup","DomainName":"FLIPKARTLAB","ManagedSystemID":54},
 {"ManagedAccountID":302,"AccountName":"svc-report","DomainName":"FLIPKARTLAB","ManagedSystemID":61}]
# Empty list but the accounts exist? Check "Enable for API Access" on each
# account and that your runas user holds a Requestor or ISA role on them.