Skip to content

Identity & sign-in

Gate never stores passwords. It trusts the directory you already run and turns its people and groups into the names your guardrails use. Set it up under Admin → Identity.

Active Directory

Active Directory, Windows sign-in and file shares need an on-prem edition (Windows Server, or the Linux or Mac appliance). Hosted Gate uses Google Workspace or its own accounts.

  1. Identity → Active Directory. Enter the AD domain, and optionally a domain controller.
  2. Service account and its password. The password is used once and never stored. (On the Windows Server edition this is already filled in with the managed service account; just press Connect.)
  3. Who gets Gate (optional): an AD group. Only its members can use Gate, and they are your seats.
  4. Gate admins (optional): an AD group whose members get the Admin pages.
  5. Press Connect, then Sync now.

People and their groups, nested ones included, now follow AD. Someone disabled in AD is disabled in Gate at the latest by their next sign-in.

Turn on AES for the service account

On the service account's Account tab in Active Directory Users and Computers, tick This account supports Kerberos AES 128 bit encryption and AES 256 bit. Without it, some PCs get older RC4 tickets that Gate refuses. The Health check flags it.

Windows sign-in (no login page)

People on domain-joined PCs open Gate and are already in, as themselves, by Kerberos. No password ever reaches Gate.

  1. Edge and Chrome only send a Windows sign-in to sites you allow. Identity → Browser setup has one script: run it once on a domain controller. It creates and links one Group Policy. (The Windows Server installer does this for you.)
  2. Open Gate by its DNS name, never an IP address.
  3. On a PC, check from a command prompt: klist get HTTP/gate.corp.example. A ticket means Kerberos is ready.
  4. In Gate, Health check → Test this browser shows who you would be signed in as, and whether it was Kerberos or NTLM.

Allow NTLM is off by default. Turn it on only for older PCs and apps that cannot do Kerberos, and keep Require relay protection on.

Google Workspace

Identity → Google Workspace: enter your Workspace domain and press Enable for my organization. People sign in with Sign in with Google; Google enforces their MFA. Tick Also allow local sign-in to keep Gate's own accounts working too.

Groups

Guardrails can name group:<name>. With AD connected, each person's AD groups appear under Admin → Groups and change when AD does, at the next sync or sign-in. Add a manual membership there for anything AD does not cover.

File shares, as the person

Gate opens Windows file shares as the person asking, with their own NTFS permissions. If they cannot open a folder in Explorer, their AI cannot either. Gate reads the drive maps you already publish in Group Policy.

What Active Directory needs:

  • Windows Server edition: the installer lets the server's computer account delegate to cifs/ on your mapped file servers and domain controllers. Nothing else to do.
  • Linux or Mac appliance: on the service account's Delegation tab, choose Trust this user for delegation to specified services only → Use any authentication protocol, and add cifs on each file server.

Then Health check → Test as a person shows, share by share, what the guardrails say and what Windows says.

Step by step

Windows sign-in (Kerberos) · NTLM · Google Workspace · People you add in Gate · File shares

Coming next

ADFS / SAML, Microsoft Entra ID, Okta and RADIUS are in build and show in Identity as they arrive.