Active Directory & LDAP

Stoa integrates with Active Directory or any LDAP-compatible identity provider so your users sign in with their existing credentials. New users are auto-provisioned on first login.

What integration gives you

• Single sign-on. Users use their existing AD or LDAP password. No second password to remember, no second account to manage.
• Auto-provisioning. The first time a user signs in, Stoa creates their account automatically using attributes from your directory.
• No parallel user database. When a user is removed from your directory, they can no longer sign in to Stoa.
• Directory search. Instead of waiting for someone's first login, an admin can search the connected directory directly and add a specific person to Stoa ahead of time.

What you need

• The hostname or IP of your domain controller or LDAP server, and the port (389 for plain, 636 for LDAPS).
• Whether you want to use an encrypted connection (SSL/TLS), strongly recommended.
• A bind DN and password for the service account Stoa will use to query the directory. This account only needs read permissions on the user objects you want to expose.
• The search base (the location in your directory tree Stoa should look under for users).
• The user filter (an LDAP filter expression identifying a valid user; defaults to (objectClass=user)).
• The attribute names Stoa should read for username, email, and display name (default to the standard Active Directory attributes: sAMAccountName, mail, and displayName).

Configuring it

In the admin UI, open the user menu, choose System, then Integrations, and select LDAP. Enter the values from the previous section, then save.

Once saved, run the built-in Test Connection action. It binds to your directory using the bind DN and password you entered and confirms the credentials and connection settings are valid. It doesn't run a search against your directory, so a wrong search base or user filter won't show up here: those are only confirmed the first time someone actually signs in (or when you use directory search, below).

If the test passes, sign out and try signing in with a directory user account. The first sign-in creates the user in Stoa automatically.

What a new directory user gets

Every user auto-provisioned from your directory is created with the standard user role. There's no group-to-role mapping today: directory group membership doesn't automatically decide a Stoa role. If someone needs elevated access (an admin, or a custom role you've defined), an admin reassigns their role manually from the Users screen after their account exists. This is usually a one-time step for the handful of people who need more than the default role.

When something doesn't work

The most common failures are:

• Bind DN credentials are wrong. Double-check the service account password and that it hasn't expired.
• The search base is wrong or empty. Since Test Connection doesn't search, this class of problem only shows up on an actual sign-in attempt or a directory search. Confirm the search base independently (for example with ldapsearch from a machine that can reach your directory).
• TLS / certificate issues. If your directory uses an internal CA, your delivery engineer needs to install the CA certificate on the Stoa host.
• The user filter is too restrictive. Try a simpler filter like (objectClass=user) first, then narrow.
• Network connectivity. Confirm the Stoa host can reach the directory server on the configured port. A firewall rule may be missing.

Disabling AD integration

You can run Stoa without an identity provider. In that case, you create users manually from the Users screen. Switching from manual to AD later is supported, and existing manual users continue to work alongside AD-provisioned users.

Next

• Roles & permissions for how to reassign a directory-provisioned user once they exist.
• Email (SMTP) for welcome emails on auto-provisioning.