# 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. Verify that Dex is configured as the OIDC provider in the `/var/lib/rancher/k3s/server/manifests/axoflow.yaml` file:

     * `chalco.oidc.enabled: true`
     * `chalco.oidc.provider: "dex"`

For example:
```
 oidc:
        enabled: true
        provider: "dex"
    
```

  2. Configure authentication by editing the `spec.dex.config` section of the `/var/lib/rancher/k3s/server/manifests/axoflow.yaml` file.

     1. (Optional) If you’ve used our [earlier example](../../../../docs/axoflow/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`.
```
 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.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.

     * `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.

     * `infrastructureViewer`: Similar to **infrastructure-manager** , but can only view the pages. Can tap into service logs.

     * `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.<role>.groups`. In the following example, the `managers` group gets administrator role, and the `readonly` group gets read-only access to AxoConsole.
```
 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:<groupname-retrieved-from-cognito>`, for example, `cognito:groups:ExampleGoogleSaml:Operator`.
       * If you’re using an on-prem AxoConsole deployment, specify the group in the following format: `groups:<groupname-retrieved-from-dex>` for example, `groups:operator`.
     * A specific session of an authenticated user, in the following format: `user:<oidc-response-subject>`, for example: `user:42c4e962-f077-705f-138f-f01ba1220c44`.

     * Every authenticated user: `axoflow:user`

For details on authorization settings, see [Authorization](../../../../docs/axoflow/deploy/onprem/authorization/index.md).

  4. Save the file.

  5. Restart the dex deployment after changing the connector:
```
 kubectl rollout restart deployment/dex -n axoflow
         
```

Expected output:
```
 deployment.apps/dex restarted
         
```




## Getting help

You can troubleshoot common errors by running `kubectl logs -n axoflow <dex-container-name>`

If you run into problems setting up the authentication or authorization, [contact our support team](<https://axoflow.com/contact?contact_form_subject=support_request>).