website: latest migration to new structure (#11522)
* first pass
* dependency shenanigans
* move blueprints
* few broken links
* change config the throw errors
* internal file edits
* fighting links
* remove sidebarDev
* fix subdomain
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* fix relative URL
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* fix mismatched package versions
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* fix api reference build
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* test tweak
* links hell
* more links hell
* links hell2
* yep last of the links
* last broken link fixed
* re-add cves
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* add devdocs redirects
* add dir
* tweak netlify.toml
* move latest 2 CVES into dir
* fix links to moved cves
* typoed title fix
* fix link
* remove banner
* remove committed api docs
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
* integrations: remove version dropdown
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
* Update Makefile
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
* change doc links in web as well
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
* fix some more docs paths
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
* fix more docs paths
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
* ci: require ci-web.build for merging
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
* Revert "ci: require ci-web.build for merging"
This reverts commit b99a4842a9.
* remove sluf for Application
* put slug back in
* minor fix to trigger deploy
---------
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
Co-authored-by: Tana M Berry <tana@goauthentik.com>
Co-authored-by: Jens Langhammer <jens@goauthentik.io>
Co-authored-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
This commit is contained in:
Tana M Berry
Binary file not shown.
|
Before Width: | Height: | Size: 49 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 39 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 39 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 27 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 40 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 40 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 106 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 41 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 33 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 52 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 42 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 52 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 32 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 52 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 32 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 39 KiB |
@ -1,95 +0,0 @@
|
||||
---
|
||||
title: Create an LDAP provider
|
||||
---
|
||||
|
||||
### Create Service account
|
||||
|
||||
1. Create a new user account to bind with under _Directory_ -> _Users_ -> _Create_, in this example called `ldapservice`.
|
||||
|
||||
Note the DN of this user will be `cn=ldapservice,ou=users,dc=ldap,dc=goauthentik,dc=io`
|
||||
|
||||
:::info
|
||||
Note: The `default-authentication-flow` validates MFA by default, and currently everything but SMS-based devices and WebAuthn devices are supported by LDAP. If you plan to use only dedicated service accounts to bind to LDAP, or don't use SMS-based authenticators, then you can use the default flow and skip the extra steps below and continue at [Create LDAP Application & Provider](#create-ldap-application--provider)
|
||||
:::
|
||||
|
||||
### LDAP Flow
|
||||
|
||||
#### Create Custom Stages
|
||||
|
||||
1. Create a new identification stage. _Flows & Stage_ -> _Stages_ -> _Create_
|
||||
|
||||
2. Name it `ldap-identification-stage`. Select User fields Username and Email (and UPN if it is relevant to your setup).
|
||||
|
||||
3. Create a new password stage. _Flows & Stage_ -> _Stages_ -> _Create_
|
||||
|
||||
4. Name it `ldap-authentication-password`. Leave the defaults for Backends.
|
||||
|
||||
5. Create a new user login stage. _Flows & Stage_ -> _Stages_ -> _Create_
|
||||
|
||||
6. Name it `ldap-authentication-login`.
|
||||
|
||||
|
||||
#### Create Custom Flow
|
||||
|
||||
1. Create a new authentication flow under _Flows & Stage_ -> _Flows_ -> _Create_, and name it `ldap-authentication-flow`
|
||||
|
||||
2. Click the newly created flow and choose _Stage Bindings_.
|
||||
|
||||
3. Click `Bind Stage` choose `ldap-identification-stage` and set the order to `10`.
|
||||
|
||||
4. Click `Bind Stage` choose `ldap-authentication-login` and set the order to `30`.
|
||||
|
||||
5. Edit the `ldap-identification-stage`.
|
||||
|
||||
6. Change the Password stage to `ldap-authentication-password`.
|
||||
|
||||
|
||||
### Create LDAP Application & Provider
|
||||
|
||||
1. Create the LDAP Application under _Applications_ -> _Applications_ -> _Create With Wizard_ and name it `LDAP`.
|
||||
|
||||
|
||||
|
||||
### Assign LDAP permissions
|
||||
|
||||
1. Navigate to the LDAP Provider under _Applications_ -> _Providers_ -> `Provider for LDAP`.
|
||||
2. Switch to the _Permissions_ tab.
|
||||
3. Click the _Assign to new user_ button to select a user to assign the full directory search permission to.
|
||||
4. Select the `ldapservice` user in the modal by typing in its username. Select the _Search full LDAP directory_ permission and click _Assign_
|
||||
|
||||
### Create LDAP Outpost
|
||||
|
||||
1. Create (or update) the LDAP Outpost under _Applications_ -> _Outposts_ -> _Create_. Set the Type to `LDAP` and choose the `LDAP` application created in the previous step.
|
||||
|
||||
|
||||
:::info
|
||||
The LDAP Outpost selects different providers based on their Base DN. Adding multiple providers with the same Base DN will result in inconsistent access
|
||||
:::
|
||||
|
||||
### ldapsearch Test
|
||||
|
||||
Test connectivity by using ldapsearch.
|
||||
|
||||
:::info
|
||||
ldapsearch can be installed on Linux system with these commands
|
||||
|
||||
```shell
|
||||
sudo apt-get install ldap-utils -y # Debian-based systems
|
||||
sudo yum install openldap-clients -y # CentOS-based systems
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
```shell
|
||||
ldapsearch \
|
||||
-x \
|
||||
-H ldap://<LDAP Outpost IP address>:<Port number 389> \ # In production it is recommended to use SSL, which also requires `ldaps://` as the protocol and the SSL port
|
||||
-D 'cn=ldapservice,ou=users,DC=ldap,DC=goauthentik,DC=io' \
|
||||
-w '<ldapuserpassword>' \
|
||||
-b 'DC=ldap,DC=goauthentik,DC=io' \
|
||||
'(objectClass=user)'
|
||||
```
|
||||
|
||||
:::info
|
||||
This query will log the first successful attempt in an event in the _Events_ -> _Logs_ area, further successful logins from the same user are not logged as they are cached in the outpost.
|
||||
:::
|
||||
@ -1,121 +0,0 @@
|
||||
---
|
||||
title: LDAP Provider
|
||||
---
|
||||
|
||||
You can configure an LDAP Provider for applications that don't support any newer protocols or require LDAP.
|
||||
|
||||
:::info
|
||||
Note: This provider requires the deployment of the [LDAP Outpost](../../outposts/)
|
||||
:::
|
||||
|
||||
All users and groups in authentik's database are searchable. Currently, there is limited support for filters (you can only search for objectClass), but this will be expanded in further releases.
|
||||
|
||||
Binding against the LDAP Server uses a flow in the background. This allows you to use the same policies and flows as you do for web-based logins. For more info, see [Bind modes](#binding--bind-modes).
|
||||
|
||||
You can configure under which base DN the information should be available. For this documentation we'll use the default of `DC=ldap,DC=goauthentik,DC=io`.
|
||||
|
||||
Users are available under `ou=users,<base DN>` and groups under `ou=groups,<base DN>`. To aid compatibility, each user belongs to its own "virtual" group, as is standard on most Unix-like systems. This group does not exist in the authentik database, and is generated on the fly. These virtual groups are under the `ou=virtual-groups,<base DN>` DN.
|
||||
|
||||
:::info
|
||||
Note: Every LDAP provider needs to have a unique base DN. You can achieve this by prepending an application-specific OU or DC. e.g. `OU=appname,DC=ldap,DC=goauthentik,DC=io`
|
||||
:::
|
||||
|
||||
The following fields are currently sent for users:
|
||||
|
||||
- `cn`: User's username
|
||||
- `uid`: Unique user identifier
|
||||
- `uidNumber`: A unique numeric identifier for the user
|
||||
- `name`: User's name
|
||||
- `displayName`: User's name
|
||||
- `mail`: User's email address
|
||||
- `objectClass`: A list of these strings:
|
||||
- "user"
|
||||
- "organizationalPerson"
|
||||
- "goauthentik.io/ldap/user"
|
||||
- `memberOf`: A list of all DNs that the user is a member of
|
||||
- `homeDirectory`: A default home directory path for the user, by default `/home/$username`. Can be overwritten by setting `homeDirectory` as an attribute on users or groups.
|
||||
- `ak-active`: "true" if the account is active, otherwise "false"
|
||||
- `ak-superuser`: "true" if the account is part of a group with superuser permissions, otherwise "false"
|
||||
|
||||
The following fields are current set for groups:
|
||||
|
||||
- `cn`: The group's name
|
||||
- `uid`: Unique group identifier
|
||||
- `gidNumber`: A unique numeric identifier for the group
|
||||
- `member`: A list of all DNs of the groups members
|
||||
- `objectClass`: A list of these strings:
|
||||
- "group"
|
||||
- "goauthentik.io/ldap/group"
|
||||
|
||||
A virtual group is also created for each user, they have the same fields as groups but have an additional objectClass: `goauthentik.io/ldap/virtual-group`.
|
||||
The virtual groups gidNumber is equal to the uidNumber of the user.
|
||||
|
||||
**Additionally**, for both users and (non-virtual) groups, any attributes you set are also present as LDAP Attributes.
|
||||
|
||||
:::info
|
||||
Starting with 2021.9.1, custom attributes will override the inbuilt attributes.
|
||||
:::
|
||||
|
||||
:::info
|
||||
Starting with 2023.3, periods and slashes in custom attributes will be sanitized.
|
||||
:::
|
||||
|
||||
## SSL / StartTLS
|
||||
|
||||
You can also configure SSL for your LDAP Providers by selecting a certificate and a server name in the provider settings.
|
||||
|
||||
Starting with authentik 2023.6, StartTLS is supported, and the provider will pick the correct certificate based on the configured _TLS Server name_ field. The certificate is not picked based on the Bind DN, as the StartTLS operation should happen be the bind request to ensure bind credentials are transmitted over TLS.
|
||||
|
||||
This enables you to bind on port 636 using LDAPS.
|
||||
|
||||
## Integrations
|
||||
|
||||
See the integration guide for [sssd](../../../integrations/services/sssd/) for an example guide.
|
||||
|
||||
## Binding & Bind Modes
|
||||
|
||||
All bind modes rely on flows.
|
||||
|
||||
The following stages are supported:
|
||||
|
||||
- [Identification](../../flow/stages/identification/index.md)
|
||||
- [Password](../../flow/stages/password/index.md)
|
||||
- [Authenticator validation](../../flow/stages/authenticator_validate/index.md)
|
||||
|
||||
Note: Authenticator validation currently only supports DUO, TOTP and static authenticators.
|
||||
|
||||
Starting with authentik 2023.6, code-based authenticators are only supported when _Code-based MFA Support_ is enabled in the provider. When enabled, all users that will bind to the LDAP provider should have a TOTP device configured, as otherwise a password might be incorrectly rejected when semicolons are used in the password.
|
||||
|
||||
For code-based authenticators, the code must be given as part of the bind password, separated by a semicolon. For example for the password `example-password` and the code `123456`, the input must be `example-password;123456`.
|
||||
|
||||
SMS-based authenticators are not supported as they require a code to be sent from authentik, which is not possible during the bind.
|
||||
|
||||
- [User Logout](../../flow/stages/user_logout.md)
|
||||
- [User Login](../../flow/stages/user_login/index.md)
|
||||
- [Deny](../../flow/stages/deny.md)
|
||||
|
||||
#### Direct bind
|
||||
|
||||
In this mode, the outpost will always execute the configured flow when a new bind request is received.
|
||||
|
||||
#### Cached bind
|
||||
|
||||
This mode uses the same logic as direct bind, however the result is cached for the entered credentials, and saved in memory for the standard session duration. Sessions are saved independently, meaning that revoking sessions does _not_ remove them from the outpost, and neither will changing a users credentials.
|
||||
|
||||
## Searching & Search Modes
|
||||
|
||||
Any user that is authorized to access the LDAP provider's application can execute search the LDAP directory. Without explicit permissions to do broader searches, a user's search request will return information about themselves, including user info, group info, and group membership.
|
||||
|
||||
[Users](../../user-group-role/user/index.mdx) and [roles](../../user-group-role/roles/index.mdx) can be assigned the permission "Search full LDAP directory" to allow them to search the full LDAP directory and retrieve information about all users in the authentik instance.
|
||||
|
||||
:::info
|
||||
Up to authentik version 2024.8 this was managed using the "Search group" attribute in the LDAP Provider, where users could be added to a group to grant them this permission. With authentik 2024.8 this is automatically migrated to the "Search full LDAP directory" permission, which can be assigned more flexibly.
|
||||
:::
|
||||
|
||||
#### Direct search
|
||||
|
||||
Every LDAP search request will trigger one or more requests to the authentik core API. This will always return the latest data, however also has a performance hit due all the layers the backend requests have to go through, etc.
|
||||
|
||||
#### Cached search
|
||||
|
||||
In this mode, the outpost will periodically fetch all users and groups from the backend, hold them in memory, and respond to search queries directly. This means greatly improved performance but potentially returning old/invalid data.
|
||||
Reference in New Issue
Block a user