Open WebUI with Active Directory: sign-in and per-person permissions

Acutis Gate · guides for IT directors · updated October 2026

Short answer: Open WebUI can sign people in with Active Directory over LDAP, which tells it who is chatting. It does not make the model's tools respect that person's rights: a tool server still reaches HR, finance or your file shares with whatever single account it was given. To make every AI action run with the asking person's own permissions, put an identity-aware tool server between Open WebUI and your systems.

Step 1: sign people in with Active Directory

Open WebUI has built-in LDAP sign-in:

1. In Open WebUI, open Admin Panel → Settings → General and turn on LDAP.
2. Host: your domain controller (dc1.corp.example), port 636, TLS on.
3. Application DN and password: a read-only service account that may search the directory.
4. Search base: the OU your staff live in. Username attribute: sAMAccountName.
5. Save, sign out, and sign in as a staff member with their Windows username and password.

The same settings as environment variables on the container (names can shift between releases, so check the Open WebUI docs for yours):

Command line

docker run -d -p 3000:8080 --name open-webui \
  -e ENABLE_LDAP=true \
  -e LDAP_SERVER_HOST=dc1.corp.example \
  -e LDAP_SERVER_PORT=636 \
  -e LDAP_USE_TLS=true \
  -e LDAP_APP_DN="CN=svc-openwebui,OU=Service Accounts,DC=corp,DC=example" \
  -e LDAP_APP_PASSWORD='use-a-secret-store' \
  -e LDAP_SEARCH_BASE="OU=Staff,DC=corp,DC=example" \
  -e LDAP_ATTRIBUTE_FOR_USERNAME=sAMAccountName \
  -v open-webui:/app/backend/data ghcr.io/open-webui/open-webui:main

Before you rely on it, check what AD actually says about a person, because that is what every later decision should follow: in Active Directory Users and Computers, open the person and look at the Member Of tab.

Command line

# PowerShell (RSAT): the groups that should decide what msmith's AI may touch
Get-ADPrincipalGroupMembership msmith | Select-Object name

# Linux: the same answer over LDAPS
ldapsearch -H ldaps://dc1.corp.example -D "svc-openwebui@corp.example" -W \
  -b "DC=corp,DC=example" "(sAMAccountName=msmith)" memberOf

Step 2: the gap LDAP sign-in leaves open

Sign-in is only the front door. When the model calls a tool (read the HR system, search a file share, look up an invoice), that tool server connects with its own credential. If that credential can read the whole Finance share, every person's AI can too, whatever their groups say. This is the "god account" problem, and it is why many AI policies ban tools outright.

Two questions show whether you have it:

• Ask the AI the same question as an HR partner and as someone in Finance. Do they get different answers?
• Open the tool server's logs. Does each call name the real person, or one service account?

Step 3: make every tool call run as the person

Acutis Gate is a tool server (MCP) that Open WebUI connects to instead of connecting to each app directly. It knows who is chatting, because Open WebUI either uses each person's own Gate token or vouches for the signed-in person as a trusted client. Then for every call Gate:

1. shows the model only the tools that person may use,
2. checks your rules (deny by default; explicit deny always wins; some actions can wait for an approver),
3. runs the call with that person's own key, token or Windows ticket, so the app's own permissions decide,
4. records the call, its arguments and result in a hash-chained audit trail that streams to your SIEM.

Connecting them takes two screens:

1. In the Gate console, open Connect an AI and create a personal token (or set Open WebUI up once as a trusted client for everyone).
2. In Open WebUI, open Admin Panel → Settings → External Tools → +, choose MCP (Streamable HTTP), URL https://gate.corp.example/api/v1/gate/mcp, and paste the token as the bearer.
3. In a chat, turn the tool server on and ask something only one group should be able to answer.

On the on-prem editions Gate also syncs Active Directory itself (people, nested groups, leavers disabled) and opens file shares as the person, only on the drives Group Policy maps for them. See how to stop AI from seeing files a user can't open.

Frequently asked questions