## TL;DR
Generate a compliant password, set the account to require a change at first sign-in, and create the account disabled until handover. Check the exact policy rejection in the provisioning log, confirm length, history, and complexity rules on the target organizational unit, then fix the generator or template that produced the weak or reused password instead of weakening domain policy for one hire.

```text
new hire account creation failed in Active Directory: password policy error
```

## Use this when
- The provisioning tool or script reports a password constraint violation when creating the AD account.
- The same automation succeeds for other organizational units or account types.
- Manual creation with a freshly typed password succeeds for the same hire.

## Not for this skill when
- Every account creation fails including manual ones. Investigate domain controller health first.
- The rejection names a duplicate account rather than a password. Use the duplicate-account workflow instead.

## Steps
1. Reproduce the failure and capture the full error from the provisioning log or the directory service event log on the domain controller, noting whether it names complexity, length, history, or minimum age. Each sub-type has a different fix, so the exact wording decides the next step. Verify: the failing password rule is named explicitly
2. Run the Group Policy results for the target organizational unit and read the effective password policy, including minimum length, complexity, history count, and any fine-grained password policy applied to the provisioning group. Compare it with the password template the automation uses. Verify: every policy value is listed beside the generator settings
3. Fix the generator to exceed the policy with margin: longer length than the minimum, all character classes the policy expects, and a uniqueness source that never reuses a recent hire password from a shared pattern. Remove any pattern based on names, start dates, or seasons that history and complexity checks reject. Verify: ten sample generated passwords all pass a policy check without manual edits
4. Set the account creation flags correctly: create the account disabled, set the must-change-at-next-sign-in flag, and do not set password-never-expires for standard hires. A flag combination that conflicts with policy, such as requiring change while also forbidding it, produces the same rejection family. Verify: the template flags match the standard hire account baseline
5. Create the test hire account again through the automation, confirm it lands in the correct organizational unit with the right group memberships, and have a second operator confirm the account enables cleanly at handover. Verify: the automated create succeeds and the account state matches the baseline
6. Update the onboarding runbook with the effective policy values and the generator rules, and add a pre-flight password check step to the provisioning job so a bad template fails in staging rather than on a live hire date. Verify: the runbook and the job both contain the pre-flight check

## Why it happens
Password policy rejections happen because the automation produces passwords from a static template while domain policy enforces history, complexity, and length rules the template never modeled. Shared patterns such as a company word plus the start month repeat across hires and collide with history or similarity checks, and fine-grained policies on some organizational units are stricter than the domain default the template was built against. The directory correctly refuses the weak credential. Aligning the generator to the strictest effective policy and proving it with samples removes the failure without lowering security for everyone.

## Variants and edge cases
### Fine-grained policy stricter than domain default
When one organizational unit keeps failing, check for a Password Settings Object applied to that unit or its groups. Build the generator to the strictest object in use rather than maintaining per-unit templates.

### Password history rejection on rehires
Rehires created fresh can inherit history checks tied to the service account that sets passwords at volume. Rotate the generator secret source and ensure each password is randomly unique per account.

### Complexity passes but length fails after a policy change
A recent policy raise silently breaks older templates. Subscribe the provisioning owner to Group Policy change notifications so template reviews follow policy edits.

Compatibility: Applies to on-premises Active Directory provisioning via scripts, HR connectors, and identity platforms with AD agents. Requires account operator rights for diagnosis.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_F_ic2sLLXMGlG6YqQVay_g