Active Directory Sign-In
Signing users in against an on-premises Active Directory, using the accounts they already have.
Where to find it
Architect Panel → Security:
- Authentication Methods — which sign-in routes are enabled
Architect Panel → Security:
- Authentication Methods — the AD sign-in method
- Permissions — the groups directory membership can map to
When this is the right route
- Staff on a domain, with no cloud directory in play.
- An organisation not using Microsoft 365 or equivalent.
- Environments where sign-in should not depend on an internet service.
Azure AD is usually better where available
If your organisation has a cloud directory, that route is generally the better choice — no network path to maintain, works for people outside the office without a VPN, and brings the directory's own conditional access and second factor with it.
On-premises AD is the right answer when there is no cloud directory, or when there is a specific reason to keep authentication inside the network.
It needs a network path
The platform must be able to reach a domain controller. Where the platform is hosted outside your network, that means a VPN or an equivalent arrangement — and it means sign-in depends on that link being up.
Plan for the link being down, because it will be. A local administrative account matters more here than almost anywhere.
Use a dedicated service account
The connection needs an account to query the directory. Give it its own, with read access to what it needs and nothing more, and do not use a person's — it will break when they leave and their password change will take sign-in down for everybody.
Scope what is searchable
A directory contains far more than current staff — service accounts, disabled accounts, contacts, shared mailboxes. Restrict the connection to the parts of the tree containing people who should be signing in.
This also keeps sign-in fast, which matters on a large directory.
Group mapping applies here too
Where directory groups grant platform access, the same caution as SAML: keep the mapping small and explicit, and remember that somebody administering the directory can grant access here without realising.
Attributes still need mapping
Which attribute identifies the user, and which holds their e-mail address and name. As with SAML, prefer a stable identifier over one that changes when somebody's name or address does.
Test from where the platform runs
Not from a workstation. The connection is made by the server, so what matters is whether it can reach a domain controller and authenticate — a test from inside the office proves nothing about that.
Worked example
An organisation with no cloud directory connects to its on-premises AD over a site-to-site VPN, using a dedicated read-only service account scoped to the staff organisational unit. Two local administrator accounts are retained because the VPN occasionally drops overnight, and both are tested quarterly.
Recommendations
- Prefer the cloud directory where you have one.
- Dedicated service account, scoped narrowly.
- Keep local administrators — the network path will fail.
- Test from the server, not from a workstation.