# password_held_by_directory

The user's password lives in their organization's directory, which the server only reads (409).

## Meaning

An administrator asked the server to set, reset by mail, or require a change of the
password of an account that signs in through an LDAP or Active Directory connection,
or to send it an invitation to choose one.
The server only reads a directory, so the account holds no password here and none can
be given to it: the directory's own tools set, reset and expire it. The account is
recognised by the link its first directory sign-in made, under the provider named in
the audit record.

## Impact

Nothing changed. The user keeps signing in with the directory password; a reset the
administrator meant to send has to happen in the directory. Not a fault.

## Diagnosis

1. Look the request id up on the Troubleshooting page. The refusal is recorded as
   `user.password.changed`, `user.password_reset.sent`,
   `user.password_change.required` or `user.invitation.sent` with reason `conflict`, cause
   `password_held_by_directory`; the problem's detail names the directory.
2. `GET /v1/admin/orgs/{slug}/users/{id}/identities` lists the link, under the
   provider `ldap/<slug>`.

## Mitigation

- As an administrator: change or reset the password in the directory; a disabled or
  locked account there is refused at the next sign-in here without any change on this
  side.
- As an admin-API developer: treat the answer as final for this account; do not retry.

## Escalation

Escalate when the account is not meant to sign in through a directory: the link was
made by a sign-in the directory accepted, so check the directory's entry and the
connection's user filter. Attach the request id, the directory slug and the server
version; never the bind password.

---

[Problem code runbooks](https://www.nauthera.io/docs/v1/runbooks/problems) · Generated from [`internal/runbook/problems.yaml`](https://github.com/nauthera/nauthera-server/blob/main/internal/runbook/problems.yaml) in nauthera-server.