Skip to content

How to integrate with an LDAP server

LDAP server or Active Directory can be used to enable users to log in to TeskaLabs LogMan.io seamlessly.

Specify LDAP connection by configuration of TeskaLabs SeaCat Auth (authorization server within TeskaLabs LogMan.io) in the model.

Find seacat-auth service in the model and follow this example.

Important

Before you apply changes in the model, upload the secret (in this case LDAP_USER_PASSWORD) securely to the Vault. Only then, the secret is available when changes are being applied to the SeaCat Auth configuration.

/Site/model.yaml
define:
  type: rc/model

services:
  ...
  seacat-auth:
    instances:
      - node1  #(1)
    asab:
      config:
        "seacatauth:credentials:ldap:external":
          uri: ldap://ad.company.cz  #(2)
          username: "CN=user,OU=Users_System,DC=company,DC=cz"  #(3)
          attrusername: sAMAccountName
          password: "{{LDAP_USER_PASSWORD}}"
          base: DC=company,DC=cz
          filter: "(&(objectClass=user)(|(sAMAccountName=novakjan)(sAMAccountName=novotnypavel)))"
          attributes: "mail mobile"

secrets:
  LDAP_USER_PASSWORD: {}
  1. List of nodes with seacat-auth instance.
  2. URI to your LDAP server.
  3. Full user name in the Active Directory.

To save the secret to the Vault, use this command on the LogMan.io host server. Make sure you replace the key and the password value according to your needs.

curl -X PUT localhost:8891/vault/LDAP_USER_PASSWORD  --data 'supersecret'

Hit Apply button accessible in the /Site folder of the Library or use command-line option.

On the host server, in the /opt/site directory, use the command:

./gov.sh up

Secure LDAP connection (LDAPS)

To enable secure connection, simply specify the LDAP uri with ldaps:// scheme.

Supplying certificate and key files

Depending on your policy, you may want to specify the server CA file and/or the client certificate and key files.

First, make sure you have the files you need ready on the server. Then proceed to securely uploading them to the Vault:

cd /opt/site
./gov.sh curl -X PUT $NODE_ID:8891/vault/ldap_tls_cafile --data-binary '@/absolute/path/to/cafile.crt'
./gov.sh curl -X PUT $NODE_ID:8891/vault/ldap_tls_certfile --data-binary '@/absolute/path/to/certfile.crt'
./gov.sh curl -X PUT $NODE_ID:8891/vault/ldap_tls_keyfile --data-binary '@/absolute/path/to/keyfile.pem'

Be sure to replace $NODE_ID with the server name.

Now update the /Site/model.yaml file in the Library:

/Site/model.yaml
services:
  ...
  seacat-auth:
    ...
    asab:
      config:
        "seacatauth:credentials:ldap:external":
          ...
          tls_cafile: /conf/tls_cafile.crt  #(3)
          tls_certfile: /conf/tls_certfile.crt
          tls_keyfile: /conf/tls_keyfile.pem
          tls_require_cert: allow  #(4)
    files:  #(2)
      - "/conf/tls_cafile.crt": "{{LDAP_TLS_CAFILE}}"
      - "/conf/tls_certfile.crt": "{{LDAP_TLS_CERTFILE}}"
      - "/conf/tls_keyfile.pem": "{{LDAP_TLS_KEYFILE}}"

secrets:  #(1)
  ...
  LDAP_TLS_CAFILE: {}
  LDAP_TLS_CERTFILE: {}
  LDAP_TLS_KEYFILE: {}
  1. Expose the certs/keys from the Vault in the secrets section.
  2. Convert the secrets to files available to SeaCat Auth service.
  3. Link the cert/key files in SeaCat Auth LDAP configuration.
  4. Server TLS certificate policy. Possible options: never, allow, demand, hard

Finally, Save the changes and apply them using the Apply button in the Library UI or by running the /opt/site/gov.sh up command on the server.

Using LDAP groups for access control

You can grant LogMan.io tenants and roles automatically based on LDAP (or Active Directory) group membership. A sync script inside the SeaCat Auth container reads each user's memberOf groups, looks them up in a group map you define, and keeps the corresponding tenant and role assignments up to date.

This is useful when you already manage access in LDAP and want LogMan.io permissions to follow the same groups—without assigning tenants and roles by hand for every user.

Note

LDAP login must already work (see the sections above). The sync only assigns tenants and roles; it does not create LogMan.io accounts. Users still authenticate through the LDAP credentials provider.

How it works

  1. The script connects to LDAP using the same SeaCat Auth LDAP configuration (uri, bind user, base, filter, TLS options, and so on).
  2. It searches for users that match the LDAP filter from your configuration.
  3. For each user, it reads the memberOf attribute and matches group distinguished names (DNs) against your group map.
  4. It assigns the mapped tenants and roles in SeaCat Auth, and removes previously synced assignments that no longer apply.

Assignments created by the sync are tagged as managed by lmio-access-sync. The script only adds or removes those managed assignments. Tenants and roles you assign manually (or through another process) are left unchanged.

If a user belongs to several mapped groups, their tenants and roles are the union of all matching entries.

Prepare the group map

Create a YAML file that maps each LDAP group DN to the LogMan.io tenants and roles its members should receive.

Use the full distinguished name of each group, exactly as stored in LDAP (for example as shown in Active Directory Users and Computers, or in the group's distinguishedName attribute). Matching is case-insensitive.

ldap-group-map.yaml
"CN=System Administrators,CN=Builtin,DC=EXAMPLE,DC=com":
  tenants:
    - system
    - mycompany
  roles:
    - "*/admin"
"CN=Analysts,CN=Users,DC=EXAMPLE,DC=com":
  tenants:
    - mycompany
  roles:
    - "*/analyst"
"CN=Operators,CN=Users,DC=EXAMPLE,DC=com":
  tenants:
    - mycompany
  roles:
    - "*/operator"
Field Description
Key (group DN) Full LDAP distinguished name of the group.
tenants List of LogMan.io tenant IDs to grant.
roles List of LogMan.io role IDs to grant. Use global roles such as */admin, */analyst, */operator, or */reader. You can also use tenant-scoped roles such as mycompany/analyst.

See User Roles and Responsibilities for the built-in roles and what they allow.

Tip

Start with a small map (one or two groups) and verify the sync before mapping your full directory structure.

Deploy the group map via the model

Add the group map as a file on the seacat-auth service in /Site/model.yaml. After you apply the model, the file is available inside the container at /conf/ldap-group-map.yaml (the path the sync script uses by default).

/Site/model.yaml
services:
  ...
  seacat-auth:
    ...
    files:
      - "conf/ldap-group-map.yaml": |
        "CN=System Administrators,CN=Builtin,DC=EXAMPLE,DC=com":
          tenants:
            - system
            - mycompany
          roles:
            - "*/admin"
        "CN=Analysts,CN=Users,DC=EXAMPLE,DC=com":
          tenants:
            - mycompany
          roles:
            - "*/analyst"

If seacat-auth already has a files: section (for example for LDAPS certificates), add the group map entry to that same list—do not create a second files: key.

Save the model and apply the changes with the Apply button in the Library, or on the host:

cd /opt/site
./gov.sh up

Run the sync manually

On the LogMan.io host, find the SeaCat Auth container:

docker ps | grep seacat-auth

The name looks like seacat-auth-1 (the number is the instance ID).

Run the sync once:

docker exec seacat-auth-1 python3 /app/seacat-auth/scripts/ldap-access-sync.py

By default the script reads:

  • SeaCat Auth configuration from /conf/seacatauth.conf
  • Group map from /conf/ldap-group-map.yaml

You normally do not need to pass extra arguments inside the container.

What successful output looks like

When the script assigns or removes access, it prints one line per change:

Assigned tenant 'mycompany' to credentials 'ldap:external:Q049am5vdmFrLE9VPVVzZXJzLERDPWV4YW1wbGUsREM9Y29t'
Assigned role '*/analyst' to credentials 'ldap:external:Q049am5vdmFrLE9VPVVzZXJzLERDPWV4YW1wbGUsREM9Y29t'
Unassigned role '*/operator' from credentials 'ldap:external:Q049am5vdmFrLE9VPVVzZXJzLERDPWV4YW1wbGUsREM9Y29t'
Unassigned tenant 'oldtenant' from credentials 'ldap:external:Q049am5vdmFrLE9VPVVzZXJzLERDPWV4YW1wbGUsREM9Y29t'

If nothing needs changing, the script may produce little or no output. That is normal on later runs when LDAP membership is unchanged.

Warnings you may see:

LDAP query returned no users
Group from group map not found in any user: 'CN=Analysts,CN=Users,DC=EXAMPLE,DC=com'
  • No users — check the LDAP filter, base, and connectivity in the SeaCat Auth LDAP configuration. Only users matching the filter are synced.
  • Group not found — no synced user currently has that group in memberOf. Confirm the DN spelling, that users are members of the group, and that those users are included by the LDAP filter.

Schedule the sync with cron

Access changes in LDAP are not applied to LogMan.io until the script runs again. Schedule it on the host so tenant and role assignments stay current.

Create a cron file, for example /etc/cron.d/lmio-ldap-access-sync:

*/10 * * * * root docker exec seacat-auth-1 python3 /app/seacat-auth/scripts/ldap-access-sync.py

This runs the sync every 10 minutes. Adjust the schedule and the container name (seacat-auth-1) to match your environment.

After installing the cron entry, wait for the next run or trigger a manual sync, then confirm in LogMan.io that a test user received the expected tenants and roles.

Operational notes

  • LDAP filter — The sync processes only users returned by the filter in your LDAP credentials configuration. Keep that filter aligned with the accounts that should receive synced access.
  • memberOf — The script always requests the memberOf attribute. This is standard on Active Directory. If you use another LDAP server, ensure group membership is exposed via memberOf (or an equivalent that populates that attribute).
  • Manual overrides — You can still assign tenants and roles manually. The sync will not remove those. To let LDAP fully control a user's access, avoid mixing manual and synced assignments for the same user where they could conflict.
  • After changing the map — Update /Site/model.yaml, apply the model, then run the script (or wait for cron). Removing a group from the map causes the next sync to revoke the tenants and roles that group had granted (for managed assignments only).
  • LDAPS — If SeaCat Auth uses ldaps:// and TLS files, the sync reuses that configuration automatically. No extra sync-specific TLS setup is required.