password_held_by_directory

Docs version v1 (main) · Nauthera is pre-1.0, in a design-partner program

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 · Generated from internal/runbook/problems.yaml in nauthera-server.