Just finished migrating our password policy enforcement from an old, crusty in-house system to BeyondTrust Password Safe. The vendor docs and sales engineers make it sound like a five-minute job of clicking through a wizard. It's not. If you're coming from a custom or legacy system, the mapping of concepts is where you'll get burned.
Here's the step-by-step I actually followed, with the pitfalls. The core issue is that your old system probably defines policies as a block of logic (e.g., "if user is in group X, apply ruleset Y"). Password Safe uses a different model: you assign policies directly to *accounts* via templates, and the policy is evaluated based on the *managed system* credentials.
**Step 1: Extract the Actual Rules from Your Old System**
Don't look at the admin UI. Go to the source—whether it's a database table, a config file, or an API endpoint. You need the raw rule logic. My old system stored policy IDs in a user attribute. Yours might be different.
**Step 2: Map to Password Safe's Policy Components**
This is the critical part. Password Safe policies are built from:
* Password Requirements (character sets, length)
* Password Restrictions (history, age, etc.)
* A Policy Template that bundles them together.
You can't directly port your "if-then" logic. Instead, you must create a Policy Template for each *unique combination* of rules from your old system. In my case, that meant 12 templates, not the 3 I initially thought.
**Step 3: Script the Assignment**
You'll likely need to assign these new Policy Templates to your discovered accounts via the API. The web UI doesn't scale. Below is a simplified PowerShell snippet using the REST API to update an account's policy template.
```powershell
# Assume you've authenticated and have a $sessionToken
$accountId = "12345"
$policyTemplateId = "67890"
$body = @{
PolicyTemplateId = $policyTemplateId
} | ConvertTo-Json
Invoke-RestMethod -Uri "https://your-passwordsafe/api/v1/accounts/$accountId" -Method Put -Body $body -Headers @{"Authorization" = "Bearer $sessionToken"; "Content-Type" = "application/json"}
```
The real work is in building the mapping CSV: `OldSystemPolicyID, DiscoveredAccountID, PasswordSafePolicyTemplateID`.
**Step 4: Validate with Force Change**
After assignment, the policy isn't active until the next password change. To test, you must force a password change on a sample account and verify the new rules are enforced. Don't skip this. I found two of my templates had incorrect minimum length because I misread the old system's "total length" versus "number of numeric characters" rule.
Biggest gotcha? Password Safe's "Password Requirements" for complexity are global. If your old system had different complexity rules for different user tiers, you need to model that using multiple, slightly different Policy Templates, which is administratively heavy. This feels like an oversight.
If you're doing this migration, budget time for the mapping and validation. The actual tech migration is straightforward; the logic translation is where the pain lives.
-- bb
-- bb