Authentication Methods
| Method | How it works | Available |
|---|---|---|
| Email + Password | Standard Django credential check against the local SecBoard database. | Built-in |
| Active Directory / LDAP | Credentials are validated against your organisation's AD/LDAP server via the ldap3 library. Configured per company. First successful login auto-creates the SecBoard account. |
Built-in |
| Magic Link (First Login) | User enters email + company "cabinet password" and receives a one-time login link by email. Designed for first-time onboarding. | Built-in |
| TOTP Two-Factor Auth | Optional second factor using any TOTP authenticator app (Google Authenticator, Microsoft Authenticator, Authy). Works with both email/password and AD logins. | Built-in |
| OAuth / OIDC / SAML | Google, Microsoft, GitHub, Keycloak, or other SSO providers. | Not available |
Login Form — One Form for All Methods
The SecBoard login page (/login/) shows a single form with email
and password fields. There is no separate "AD login" button or domain
selector. The system tries each authentication backend in order automatically:
1. ModelBackend — checks email + password against the SecBoard database
2. CabinetADBackend — checks the same credentials against all active AD connectionsIf the local database check fails (e.g. the user was provisioned from AD and has no local password), the AD backend is tried next. From the user's perspective, they simply enter their domain credentials and click Sign In.
Active Directory / LDAP Integration
Configuration location
Each company gets its own independent AD/LDAP connection, configured in the Django admin panel under App Cabinet → Cabinet AD connections → Add. Only one connection per company is supported.
Connection parameters
| Parameter | Default | Description |
|---|---|---|
| Company | — | The company this connection belongs to (one per company) |
| Name | — | Display name for the connection (e.g. Acme Corp AD) |
| Active | Yes | Disable to pause AD auth without deleting the config |
| Server URL | — | Hostname or IP of the domain controller (e.g. dc.company.com) |
| Port | 389 | Use 389 for LDAP, 636 for LDAPS |
| Use SSL (LDAPS) | No | Enables encrypted LDAP over TLS; self-signed certificates are accepted |
| Bind DN | — | Distinguished Name of the service account used for directory search (e.g. CN=svc-secboard,OU=Service Accounts,DC=company,DC=com) |
| Bind Password | — | Password for the service account; stored encrypted in the database |
| Base DN | — | Root DN for user search (e.g. DC=company,DC=com) |
| User Search OU | — | Optional: restrict search to a specific OU (e.g. OU=Employees,DC=company,DC=com) |
| User Object Filter | (objectClass=user) | LDAP filter to match user objects; can be customised (e.g. add (!(userAccountControl:1.2.840.113556.1.4.803:=2)) to skip disabled accounts) |
Attribute mapping
| SecBoard field | AD attribute | Default |
|---|---|---|
| Login / Username | attr_username | sAMAccountName |
attr_email | mail | |
| First Name | attr_first_name | givenName |
| Last Name | attr_last_name | sn |
| Phone | attr_phone | telephoneNumber |
| Start Date | attr_start_date | (optional) |
| End Date | attr_end_date | (optional) |
The search matches against all three of sAMAccountName, userPrincipalName,
and mail simultaneously — users can sign in with their short login, full UPN, or email address.
First login auto-provisioning
When a user authenticates via AD for the first time, SecBoard automatically creates
their auth.User and CabinetUser records for the matching company.
No manual account creation is needed. Subsequent logins refresh the profile attributes
from the directory.
Profile sync on every login
On each successful AD login, the following are refreshed from the directory:
- First name, last name, email
- Phone number
- Employment start and end dates (if the attributes are mapped)
- Account active status — if the AD account has the
ACCOUNTDISABLEflag set,is_activeis set toFalsein SecBoard automatically - Extended attributes: display name, office, title, department, mobile, fax, address, and others — stored as a JSON blob accessible to administrators
AD Group Synchronisation
When Sync AD Groups to Cabinet Groups is enabled on a connection, SecBoard automatically assigns the user to matching SecBoard Access Groups on every login.
How matching works
-
SecBoard reads the user's AD group membership from both the
memberOfattribute andtokenGroups(Windows SIDs, which resolve nested group membership not visible inmemberOf). -
Each SecBoard
CabinetGroupwhose name matches an AD group name (case-sensitive, exact string match against the group's CN) is added to the user's group memberships. - The sync is additive only — groups are added but never removed. If you need to remove a user from a group, do it manually in SecBoard or disable their AD account.
-
Both company-scoped and global (no company set)
CabinetGroupobjects are considered.
CabinetGroup name must exactly match the AD group CN.
For example, if the AD group is SecBoard-Risk-Managers,
the SecBoard group must also be named SecBoard-Risk-Managers.
Testing the Connection
After saving an AD connection, a Test Connection button appears in the admin list view. Clicking it makes a service-account bind to the LDAP server and returns a success or error message immediately. Use this to verify connectivity and credentials before enabling the connection for users.
Common issues and fixes:
| Error | Likely cause | Fix |
|---|---|---|
| Connection refused / timeout | Wrong host/port or firewall blocking | Verify the server URL, port, and that the SecBoard server can reach port 389/636 on the DC |
| Invalid credentials (bind fails) | Wrong Bind DN or password | Check the service account DN format and password; test it with an LDAP browser (e.g. ldp.exe, Apache Directory Studio) |
| No such object | Incorrect Base DN | Verify the Base DN matches the actual domain root (e.g. DC=company,DC=com) |
| Users can bind to AD but fail SecBoard login | Email attribute missing or user filter too restrictive | Check attr_email is set to the correct attribute and the user object has a value for it |
| Users auto-disabled on login | userAccountControl has ACCOUNTDISABLE flag in AD |
Re-enable the AD account; SecBoard mirrors the AD disabled state automatically |
Step-by-Step Setup
-
Create a service account in Active Directory (e.g.
svc-secboard) with read-only access to the relevant OU. The account only needs permission to search and read user attributes — write access is not required. -
Open the Django admin panel at
/secboard_admin/. - Navigate to App Cabinet → Cabinet AD connections → Add cabinet AD connection.
- Fill in Company, Server URL, Port, and optionally enable Use SSL.
- Enter the Bind DN and Bind Password of the service account.
- Set the Base DN (and optionally the User Search OU).
- Review and adjust the attribute mapping if your AD schema uses non-standard attribute names.
- If you want SecBoard groups to be assigned from AD groups automatically, tick Sync AD Groups to Cabinet Groups and ensure SecBoard group names match the relevant AD group CNs exactly.
- Save. Click Test Connection in the list view to confirm the service account can bind successfully.
-
Ask a test AD user to log in at
/login/with their domain credentials. A SecBoard account is created automatically on first login.
Two-Factor Authentication with AD Accounts
TOTP 2FA works alongside AD authentication. After AD credentials are verified, if the user has 2FA enabled (or if the administrator has enforced it), they are prompted for their one-time code before being granted access. The 2FA setup and backup codes are stored in SecBoard, independently of the directory.
Manual Profile Refresh
An administrator can force an immediate profile refresh from AD for any AD-synced user without waiting for their next login. Open the user's record in Users → Users, click Edit, and use the Refresh from AD button in the Active Directory panel at the bottom of the dialog.
SSO, SAML, and OAuth
SecBoard does not currently include built-in support for SAML 2.0, OpenID Connect (OIDC), or social login providers (Google, Microsoft Azure AD, GitHub, Keycloak, Okta, etc.). If your organisation requires one of these authentication methods, contact your SecBoard vendor to discuss available integration options.
Next Steps
User Account Management
Learn how to create accounts, give first access, and manage user profiles.
Roles & Permissions
Configure Access Groups so that AD-synced groups automatically grant the right module permissions.