--- title: "LDAP" url: "https://axoflow.com/docs/axoflow/0.86/deploy/onprem/authentication/dex/ldap/" last_modified: "2026-06-18T14:41:23+02:00" --- > For the complete documentation index, see [llms.txt](https://axoflow.com/docs/axoflow/0.86/llms.txt). # LDAP This section shows you how to use LDAP as an authentication backend for AxoConsole. In the examples we used the public demo service of [FreeIPA](https://www.freeipa.org/) as an LDAP server. It is assumed that you already have an LDAP server in place. Complete the following steps. 1. Configure Dex as the OIDC provider in the `/var/lib/rancher/k3s/server/manifests/axoflow-config.yaml` file. For example: ```yaml chalco: oidc: enabled: true provider: "dex" axoidp: enabled: false dex: enabled: true ``` 2. Configure authentication by editing the `spec.dex.config` section of the `/var/lib/rancher/k3s/server/manifests/axoflow-config.yaml` file. 1. (Optional) If you’ve used our [earlier example](https://axoflow.com/docs/axoflow/0.86/deploy/onprem/deployment-guide/index.md), delete the `spec.dex.config.staticPasswords` section. 2. Add the `spec.dex.config.connectors` section to the file, like this: **CAUTION:** This example shows a simple configuration suitable for testing. In production environments, make sure to: - configure TLS encryption to access your LDAP server - retrieve the bind password from a vault or environment variable. Note that if the bind password contains the `$` character, you must set it in an environment variable and pass it like `bindPW: $LDAP_BINDPW`. ```yaml dex: enabled: true localIP: $VM_IP_ADDRESS config: create: true connectors: - type: ldap name: OpenLDAP id: ldap config: host: ipa.demo1.freeipa.org insecureNoSSL: true # This would normally be a read-only user. bindDN: uid=admin,cn=users,cn=accounts,dc=demo1,dc=freeipa,dc=org bindPW: Secret123 usernamePrompt: Email Address userSearch: baseDN: dc=demo1,dc=freeipa,dc=org filter: "(objectClass=person)" username: mail # "DN" (case sensitive) is a special attribute name. It indicates that # this value should be taken from the entity's DN not an attribute on # the entity. idAttr: uid emailAttr: mail nameAttr: cn groupSearch: baseDN: dc=demo1,dc=freeipa,dc=org filter: "(objectClass=groupOfNames)" userMatchers: # A user is a member of a group when their DN matches # the value of a "member" attribute on the group entity. - userAttr: DN groupAttr: member # The group name should be the "cn" value. nameAttr: cn ``` 3. Edit the following fields. For details on the configuration parameters, see the [Dex LDAP connector documentation](https://dexidp.io/docs/connectors/ldap/#configuration). - `connectors.config.host`: The hostname and optionally the port of the LDAP server in “host:port” format. - `connectors.config.bindDN` and `connectors.config.bindPW`: The DN and password for an application service account that the connector uses to search for users and groups. - `connectors.config.userSearch.bindDN` and `connectors.config.groupSearch.bindDN`: The base DN for the user and group search. 3. Configure authorization in the `kcp.rbac.roles` section of the `/var/lib/rancher/k3s/server/manifests/axoflow-config.yaml` file. The following roles are available in AxoConsole by default: - `IAMadmin`: Can manage the roles and permissions to access AxoConsole. Only this role can make changes on the **Settings > Roles** page. Can see the **Identity Provider Admin Panel** link, which points to the authentication and administration page of the identity provider used to authenticate on AxoConsole. (Every user can access their own profile page at the identity provider by selecting ** > Profile** in the top-left.) - `admin`: Has full access to AxoConsole, but has only read access to the **Settings > Roles** page. - `infrastructureManager`: Can manage the infrastructure (without the permissions to view or tap log contents, or to rehydrate data). Has full access to the following pages: **Activity Logs**, **Alerting**, **Routers**, **Sources**, **Flows**, **Provisioning**, **Search Logs**. Can tap into service logs which may contain event payload. - `infrastructureViewer`: Similar to **infrastructure-manager**, but can only view the pages. - `contentManager`: Can view log content and manage content related details like flows (without the permissions to manage infrastructure, but including access to view infrastructure details). - Has full access to the **Rehydration** page. - Can view and modify **Flows**, but can’t create or delete them. - Can view **Routers**, **Sources**, **Search Logs**, **Analytics**. - Can tap into logs. - `contentViewer`: Can view content like analytics, log search, log tapping (without the permissions to manage or view infrastructure details). - Can view **Search Logs**, **Analytics**. - Can tap into logs. If you need other roles, [contact the Axoflow support team](https://axoflow.com/contact?contact_form_subject=support_request). Composing other roles is possible as part of a custom integration. - Add the names of the LDAP groups to the related roles under `kcp.rbac.roles..groups`. In the following example, the `managers` group gets administrator role, and the `readonly` group gets read-only access to AxoConsole. ```yaml rbac: createRoles: true createRoleBindings: true roles: IAMadmin: groups: - groups:iamadmin admin: groups: - groups:managers contentViewer: groups: - groups:readonly ``` - A specific email address, for example, `email:username@example.com` > **Note:** > - The user must be able to authenticate to AxoConsole using this email address, so authentication must be properly set up. > - Multiple identity providers may allow authentication with the same email address, possibly with different level of ownership validation. - An entire email domain, for example, `emaildomain:example.com`. Any user who authenticates with an email address belonging to this email domain will have access to the role. - A user group. The format of the group depends on the OID provider. - If you’re using AxoConsole as a SaaS, specify the group in the following format: `cognito:groups:`, for example, `cognito:groups:ExampleGoogleSaml:Operator`. - If you’re using an on-prem AxoConsole deployment, specify the group in the following format: `groups:` for example, `groups:operator`. - A specific session of an authenticated user, in the following format: `user:`, for example: `user:42c4e962-f077-705f-138f-f01ba1220c44`. - Every authenticated user: `axoflow:user` For details on authorization settings, see [Authorization](https://axoflow.com/docs/axoflow/0.86/deploy/onprem/authorization/index.md). 4. Save the file. 5. Restart the dex deployment after changing the connector: ```shell kubectl rollout restart deployment/dex -n axoflow ``` Expected output: ```shell deployment.apps/dex restarted ``` ## Getting help You can troubleshoot common errors by running `kubectl logs -n axoflow ` If you run into problems setting up the authentication or authorization, [contact our support team](https://axoflow.com/contact?contact_form_subject=support_request).