Directory sign-in (Active Directory / LDAP)

People can sign in to the console with their Active Directory account. The Lawliet server does not join the domain: it only needs to reach one or more domain controllers on LDAPS (636) or StartTLS (389), and to trust the certificate they present.

Local accounts keep working beside directory sign-in. While it is on, at least one active local super administrator must exist: Lawliet refuses to turn it on without one, and refuses to deactivate, demote or delete the last one. That account is your way back in if the directory is unreachable or its groups change.

How a sign-in works

1. The user picks Sign in with directory account on the sign-in page and enters DOMAIN\user or their account name. With a service account configured, any UPN works too.
2. With a service account, Lawliet first looks the name up and finds the one account it names. A name that matches no account is never bound.
3. Lawliet checks its per-account failed-bind cap (see Lockout safety).
4. Lawliet binds as the user, over TLS, with the user's own password. The certificate is verified against the uploaded CA and against the host name or IP address of the domain controller. Referrals are never followed, so a password is never sent to a host the directory points to.
5. Lawliet reads back exactly the account that bound. Disabled, locked, expired and password-expired accounts are refused.
6. The user's groups, nested ones included, are matched against the group-to-role rules. If no rule matches, the user has no access.
7. Two-factor authentication is always required for directory accounts. The first sign-in enrols an authenticator app; after that every sign-in asks for the code. Directory users cannot turn two-factor off; an administrator can reset it.

The person signing in sees one generic message for a wrong password, an unknown account, and a disabled, locked or expired account. The audit trail records the precise reason.

Account names

The reason is lockout safety: without a service account Lawliet cannot look anything up before binding, so it binds every name as DOMAIN\name and counts failures against the account name the domain controller checks. Different spellings of one account never get separate allowances.

Configure it

Settings > Authentication > Directory sign-in. You need the Manage users permission, and with dual control on, a change waits for a second signature.

Test connection reaches every listed server over TLS and verifies the certificate, reads the base DN and, with a service account, the lockout policy, and says whether the cap leaves the required margin. It never binds a user account.

On a domain controller, PowerShell gives the values: (Get-ADDomain).DNSRoot, (Get-ADDomain).NetBIOSName, (Get-ADDomain).DistinguishedName, and Get-ADDefaultDomainPasswordPolicy for the lockout threshold and window.

Groups to roles

Each rule pairs an AD group with a Lawliet role. Name the group by sAMAccountName (Lawliet Admins), distinguished name or SID; a CN alone is never matched, because CNs repeat across OUs. Nested membership counts. The first matching rule wins, so put the most privileged rule first. The role is recomputed at every sign-in.

Map dedicated groups, such as Lawliet Admins and Lawliet Analysts, rather than Domain Admins, so that domain administration and Lawliet administration stay separate decisions.

Lockout safety

Lawliet's own binds never take an account closer than 2 attempts to the domain's lockout threshold, under the Default Domain Policy.

• Lawliet records every bind before it sends it. Once an account has the cap's number of failures (default 3), Lawliet refuses without contacting the domain controller, even for the correct password. The person is told how long to wait.
• The cap is counted per account, however the name is spelt, and kept in the database across restarts.
• Failures are forgotten the way the domain forgets them: after a quiet period of one observation window, using the domain's window when it is longer than Lawliet's own 15 minutes.
• The domain's lockout policy is read before each sign-in with a service account, or at each successful sign-in without one. Until it is known, Lawliet allows 1 failed bind per account per hour.
• A domain whose threshold is 1 or 2 leaves no safe margin: directory sign-in then refuses without binding and says so.

Failures from the user's workstation, mail client or other systems count against the same threshold; Lawliet's margin of 2 is the room it leaves for them. Fine-grained password policies (PSOs) are not visible to an ordinary account, so if PSOs apply to console users, set the cap at least 2 below the lowest PSO threshold.

Sessions and revocation

• With a service account, every session refresh re-reads the user. A disabled, locked, expired or deleted account, or one no longer in a mapped group, loses all its sessions. If the directory cannot be reached, the refresh fails and nothing is revoked.
• Every directory session has an absolute lifetime (8 hours by default), enforced on every request.
• Turning directory sign-in off ends every directory session at once.
• A directory or SSO role change never demotes the last active super administrator, and never makes a change after which nobody could approve user management. The role is kept, the sign-in is refused with a pointer to the local break-glass account, and the audit entry says why.
• An administrator can still deactivate a directory user in Settings > Users; Lawliet then refuses that user even when the directory accepts the password.

Every attempt is in the audit trail with the account, the domain controller and the precise reason, such as invalid_credentials, account_locked, no_role_mapping or bind_cap_reached.

Troubleshooting

Passwords travel only inside TLS 1.2 or later, with certificate and name verification that cannot be switched off. The LDAP library ships in the backend image, so directory sign-in works on air-gapped installations.