Signing in with your own Active Directory

The problem

An organisation that runs Active Directory already knows who works there and what each person may do. A new platform that hands everyone another username and password throws that knowledge away. Two lists of people start to drift, leavers keep access to one of them, and the help desk resets passwords in two places.

How it fits together

In the estates we build, Authentik is the one place people sign in, for every app. When there is an Active Directory, it joins Authentik as an LDAP source.

A service account with read-only access to the directory lets Authentik page through its users and groups. Each entry passes through a set of mappings that turn directory fields, such as the account name, the display name and the email address, into Authentik users and groups.

Passwords are not copied. At each login, Authentik asks the directory to check the password, so no directory password hash is ever stored in Authentik. People sign in with the username and password they already have.

Groups become roles

Apps sign people in through Authentik over OpenID Connect. When a person signs in, the app receives the names of their groups and grants its roles by matching a group name. Making someone an administrator of an app becomes a change in Active Directory, where your IT team already works.

Authentik does not send a person’s groups by default, so a small mapping adds them to the sign-in. We make sure they are sent once, not twice, because a duplicated list confuses the apps that read it.

What took real time

Each of these cost us time once, and each is now a check in the playbook:

• The account that reads the directory must be named in its full form. The short account name alone is refused.
• The sync runs in Authentik’s worker, not its server. If the worker sits only on an internal Docker network, it cannot reach the directory, and the sync does nothing without saying so.
• A directory group whose name matches an existing local group is skipped, with no error anywhere. So we confirm the specific groups that grant roles, not just the totals.
• Group memberships complete on the second sync, once every member exists in Authentik.

Joiners and leavers

A new person, or a new group membership, appears at the next sync. Authentik sets no sync schedule by default, so one is set in the source, or the sync is run when the directory changes.

A person who leaves is disabled or deleted in Active Directory. Their next sign-in fails, because the password check goes to the directory. Their old record in Authentik stays, because the sync is set not to delete what it no longer finds, but that record no longer passes the check.

Photos, if you have them

Active Directory can hold a small photo for each person. With one extra mapping, that photo becomes their avatar in Authentik, with initials for everyone else. Most directories hold few photos, so most people start on initials until someone adds them.

Running today

This runs in two organisations today. A rollout counts as done only when a real directory user signs in and lands with the right role, not when the numbers look right.

What it means for you

One list of people, kept where it already is. No new password to issue or reset. Roles that follow group membership. Leavers stopped at their next sign-in, by the same directory that already decides who works for you.

What we don’t claim

Each app’s sign-in client is set up today through Authentik’s API, by a script. Moving that into declarative blueprints, kept in version control and applied by Authentik itself, is a direction we have written down, not something we run. The sync does not remove departed people’s records from Authentik on its own, and it does not run on a schedule unless one is set. None of this is a compliance certification. It is how the sign-in is built.