Example Setup
In this setup we are using [lldap](https://github.com/lldap/lldap). Install your server using docker or [as a service](https://github.com/lldap/lldap/blob/main/example_configs/lldap.service).
Minimal configuration requires 4 env variables, LDAP URI, base, user and password for querying data.
There's more variables, but all have defaults corresponding to lldap defaults. These might need to be changed if you have different LDAP provider.
```
docker run ...
AUTH_PROVIDERS="ldap"
AUTH_LDAP_URI="ldap://example.com:3890"
AUTH_LDAP_BASE="dc=example,dc=com" // Same as LLDAP_LDAP_BASE_DN
AUTH_LDAP_BIND_DN="uid=admin,ou=People,dc=example,dc=com"
AUTH_LDAP_BIND_PASSWORD="adminpass" // Same as LLDAP_LDAP_USER_PASS
```
```
#Docker compose
version: x
services:
homarr:
environment:
AUTH_PROVIDERS: ldap
AUTH_LDAP_URI: ldap://example.com:3890
AUTH_LDAP_BASE: dc=example,dc=com #Same as LLDAP_LDAP_BASE_DN
AUTH_LDAP_BIND_DN: uid=admin,ou=People,dc=example,dc=com
AUTH_LDAP_BIND_PASSWORD: adminpass #Same as LLDAP_LDAP_USER_PASS
```
In lldap, create a user and admin group, assign this user to the external admin group configured during onboarding. You can log in using this user and he will be in the group.
Here is another example for Active Directory:
```
AUTH_LDAP_URI="ldap://ldap.abc.xyz:389
AUTH_LDAP_BASE="DC=abc,DC=xyz"
AUTH_LDAP_BIND_DN="CN=Administrator,CN=Users,DC=abc,DC=xyz"
AUTH_LDAP_BIND_PASSWORD="YourAdministratorPassword"
AUTH_LDAP_USERNAME_ATTRIBUTE="sAMAccountName"
AUTH_LDAP_USER_MAIL_ATTRIBUTE="userPrincipalName"
AUTH_LDAP_GROUP_CLASS="group"
AUTH_LDAP_GROUP_MEMBER_ATTRIBUTE="member"
AUTH_LDAP_GROUP_MEMBER_USER_ATTRIBUTE="dn"
AUTH_LDAP_SEARCH_SCOPE="sub"
AUTH_LDAP_USERNAME_FILTER_EXTRA_ARG="(sAMAccountType=805306368)"
```
User mail attribute is set to userPrincipalName as it follows the right schema, but it is recommended to use real emails and the default 'mail' value.
### LDAP configuration [#ldap-configuration]
| Environment Variable | Description | Default value |
| --------------------------------------- | --------------------------------------------------------- | ------------------ |
| `AUTH_LDAP_URI` | URI of your LDAP server | --- |
| `AUTH_LDAP_BASE` | Base dn of your LDAP server | --- |
| `AUTH_LDAP_BIND_DN` | User used for finding users and groups | --- |
| `AUTH_LDAP_BIND_PASSWORD` | Password for bind user | --- |
| `AUTH_LDAP_USERNAME_ATTRIBUTE` | Attribute used for username | uid |
| `AUTH_LDAP_USER_MAIL_ATTRIBUTE` | Attribute used for mail field | mail |
| `AUTH_LDAP_GROUP_CLASS` | Class used for querying groups | groupOfUniqueNames |
| `AUTH_LDAP_GROUP_MEMBER_ATTRIBUTE` | Attribute used for querying group member | member |
| `AUTH_LDAP_GROUP_MEMBER_USER_ATTRIBUTE` | User attribute used for comparing with group member | dn |
| `AUTH_LDAP_SEARCH_SCOPE` | Serach scopes between base, one and sub | base |
| `AUTH_LDAP_USERNAME_FILTER_EXTRA_ARG` | Extra arguments for user search filter (& based) | --- |
| `AUTH_LDAP_GROUP_FILTER_EXTRA_ARG` | Extra arguments for user's groups search filter (& based) | --- |
## OIDC provider [#oidc-provider]
This provider authenticates using OIDC protocol.
Users signed in using OIDC are created in Homarr.
Roles are fetched from group claims. This can also be changed to roles for example added to a azure app registration by using the `AUTH_OIDC_GROUPS_ATTRIBUTE`.
If you'd rather manage group memberships for OIDC users locally (instead of via the IdP), set `AUTH_OIDC_GROUPS_LOCAL_MANAGEMENT=true`. While enabled, Homarr stops syncing OIDC users' group memberships from the groups claim, and admins can add/remove OIDC users on a group's members page. If you turn this back to `false`, the next login of each user resumes the regular sync and reconciles their groups with the IdP's claim again, which may remove memberships that were added manually while local management was enabled.
To let an existing credentials user also sign in with OIDC, set `AUTH_OIDC_ENABLE_DANGEROUS_CREDENTIALS_LINKING=true`. On the first OIDC sign-in, Homarr links a credentials user with the same email address instead of creating a second user. The user keeps their password login, local username and profile, groups, permissions, boards, settings, and API keys. OIDC profile and group claims do not overwrite the credentials-owned data. Homarr requires the OIDC profile to contain `email_verified: true` while this option is enabled. Only enable this when your OIDC provider verifies email addresses, because a matching email could otherwise be used to take over an existing account.