What each setting does is described in Overview. This page gives, for every installation type, the place the setting is written in and the shape of its value.

Where the configuration lives

Linux package. The settings are keys of /etc/gitlab/gitlab.rb.

Omnibus Docker. The container reads the same gitlab.rb keys. They reach it from the GITLAB_OMNIBUS_CONFIG environment variable, which is evaluated on every start, and from /etc/gitlab/gitlab.rb on the configuration volume, which is read after the variable. A key written in the file overrides the same key in the variable. The variable is set when the container is created:

docker run -d --name code \
  --shm-size 256m \
  -p 80:80 -p 443:443 -p 22:22 \
  -e GITLAB_OMNIBUS_CONFIG="external_url 'https://<HOSTNAME>'; gitlab_rails['omniauth_enabled'] = true; gitlab_rails['omniauth_allow_single_sign_on'] = ['openid_connect']; gitlab_rails['omniauth_auto_link_ldap_user'] = true" \
  -v /srv/code/config:/etc/gitlab \
  -v /srv/code/logs:/var/log/gitlab \
  -v /srv/code/data:/var/opt/gitlab \
  <REGISTRY>/<FLAVOR>:<VERSION>

The variable is fixed when the container is created, so changing it means removing the container and creating a new one with the same volumes. The provider entries and the LDAP servers are multi-line values, and the configuration volume keeps them across container replacements. With the volumes from the quick start, /etc/gitlab/gitlab.rb inside the container is /srv/code/config/gitlab.rb on the host, and it is edited on the host:

sudo vi /srv/code/config/gitlab.rb

Helm Chart. The settings are chart values, written in the values.yaml file of the release.

Deckhouse Kubernetes Platform module. The settings are parameters of the CodeInstance resource, described on the OmniAuth and LDAP setup and Custom Resources pages of the module documentation.

OmniAuth general parameters

The parameters and their effect are described in General OmniAuth parameters.

  • Linux package
  • Omnibus Docker
  • Helm Chart
  • Deckhouse Kubernetes Platform module

Each general OmniAuth parameter has a gitlab.rb key of its own:

Parameter gitlab.rb key
enabled gitlab_rails['omniauth_enabled']
providers gitlab_rails['omniauth_providers']
allow_single_sign_on gitlab_rails['omniauth_allow_single_sign_on']
block_auto_created_users gitlab_rails['omniauth_block_auto_created_users']
auto_link_ldap_user gitlab_rails['omniauth_auto_link_ldap_user']
auto_link_user gitlab_rails['omniauth_auto_link_user']
auto_sign_in_with_provider gitlab_rails['omniauth_auto_sign_in_with_provider']
external_providers gitlab_rails['omniauth_external_providers']
allow_bypass_two_factor gitlab_rails['omniauth_allow_bypass_two_factor']
sync_profile_from_provider gitlab_rails['omniauth_sync_profile_from_provider']
sync_profile_attributes gitlab_rails['omniauth_sync_profile_attributes'] 
gitlab_rails['omniauth_enabled'] = true
gitlab_rails['omniauth_allow_single_sign_on'] = ['openid_connect']
gitlab_rails['omniauth_block_auto_created_users'] = true
gitlab_rails['omniauth_auto_link_ldap_user'] = true
gitlab_rails['omniauth_sync_profile_attributes'] = ['email']
The keys and their values are the ones of the Linux package tab. A single-line key fits into GITLAB_OMNIBUS_CONFIG, separated from the next one by ;, as in the docker run command above; a key whose value spans several lines is written in /srv/code/config/gitlab.rb.

The general parameters are values under global.appConfig.omniauth:

global:
  appConfig:
    omniauth:
      enabled: true
      allowSingleSignOn: ['openid_connect']
      blockAutoCreatedUsers: true
      autoLinkLdapUser: true
      syncProfileAttributes: ['email']

The general parameters are set in the spec.appConfig.omniauth section, and the providers are listed in its providers parameter:

enabled: true
allowSingleSignOn: ['openid_connect']
blockAutoCreatedUsers: true
autoLinkLdapUser: true
syncProfileAttributes: ['email']

OpenID Connect provider

The connection parameters of the provider and their effect are described in OpenID Connect (OIDC).

  • Linux package
  • Omnibus Docker
  • Helm Chart
  • Deckhouse Kubernetes Platform module

A provider is an entry of the gitlab_rails['omniauth_providers'] array. The allowed_groups, admin_groups, auditor_groups and groups_attribute keys sit next to name, at the top level of the entry; the connection parameters sit inside args:

gitlab_rails['omniauth_providers'] = [
  {
    name: 'openid_connect',   # Do not change this value.
    label: 'Keycloak',        # Sign-in button label.
    allowed_groups: ['gitlab'],
    admin_groups: ['admin'],
    auditor_groups: ['audit'],
    groups_attribute: 'gitlab_group',
    args: {
      name: 'openid_connect',
      scope: ['openid', 'profile', 'email'],
      response_type: 'code',
      issuer: 'https://keycloak.example.com/realms/example',
      discovery: true,
      client_auth_method: 'query',
      uid_field: 'preferred_username',
      send_scope_to_token_endpoint: false,
      pkce: true,
      client_options: {
        identifier: '<client_id>',
        secret: '<client_secret>',
        redirect_uri: 'https://code.example.com/users/auth/openid_connect/callback'
      }
    }
  }
]
The entry is the one of the Linux package tab. It spans several lines, so write it in /srv/code/config/gitlab.rb on the configuration volume.

A provider entry is stored in a Kubernetes Secret and referenced from the values, so the client secret stays out of values.yaml. Create the Secret with the provider block as its content:

d8 k -n code create secret generic code-omniauth-keycloak \
  --from-file=provider=keycloak.yaml

The file holds the same entry as on the other installation types:

name: 'openid_connect'
label: 'Keycloak'
allowed_groups:
  - 'gitlab'
admin_groups:
  - 'admin'
groups_attribute: 'gitlab_group'
args:
  name: 'openid_connect'
  scope:
    - 'openid'
    - 'profile'
    - 'email'
  response_type: 'code'
  issuer: 'https://keycloak.example.com/realms/example'
  discovery: true
  client_auth_method: 'query'
  uid_field: 'preferred_username'
  send_scope_to_token_endpoint: false
  pkce: true
  client_options:
    identifier: '<client_id>'
    secret: '<client_secret>'
    redirect_uri: 'https://code.example.com/users/auth/openid_connect/callback'

Reference the Secret from the values:

global:
  appConfig:
    omniauth:
      providers:
        - secret: code-omniauth-keycloak
          key: provider

The provider is an entry of the providers parameter in the spec.appConfig.omniauth section. The allowedGroups, adminGroups and groupsAttribute keys sit next to name; the CodeInstance resource has no parameter for auditor groups. The connection parameters sit inside args:

providers:
  - name: 'openid_connect'   # Do not change this value.
    label: 'Keycloak'        # Sign-in button label.
    allowedGroups:
      - 'gitlab'
    adminGroups:
      - 'admin'
    groupsAttribute: 'gitlab_group'
    args:
      name: 'openid_connect'
      scope:
        - 'openid'
        - 'profile'
        - 'email'
      response_type: 'code'
      issuer: 'https://keycloak.example.com/realms/example'
      discovery: true
      client_auth_method: 'query'
      uid_field: 'preferred_username'
      send_scope_to_token_endpoint: false
      pkce: true
      client_options:
        identifier: '<client_id>'
        secret: '<client_secret>'
        redirect_uri: 'https://code.example.com/users/auth/openid_connect/callback'

SAML provider

The parameters of a SAML provider and their effect are described in SAML.

  • Linux package
  • Omnibus Docker
  • Helm Chart
  • Deckhouse Kubernetes Platform module

A SAML provider is written as one more entry of the gitlab_rails['omniauth_providers'] array:

gitlab_rails['omniauth_providers'] = [
  {
    name: 'saml',
    allowed_groups: ['gitlab'],
    admin_groups: ['admin'],
    groups_attribute: 'gitlab_group'
  }
]
The entry is the one of the Linux package tab, written in /srv/code/config/gitlab.rb on the configuration volume.

A SAML entry is stored in a Secret and referenced from global.appConfig.omniauth.providers the same way as the OpenID Connect entry.

The provider is an entry of the providers parameter in the spec.appConfig.omniauth section:

providers:
  - name: 'saml'
    allowedGroups:
      - 'gitlab'
    adminGroups:
      - 'admin'
    groupsAttribute: 'gitlab_group'

LDAP servers

The key of a server entry is the server name. What each connection parameter does is described in LDAP synchronization; the group_sync section, which creates the groups and assigns the roles, is described in Groups and access rights and role_mapping section. The group_sync section is taken into account only for the server under the main key (see Synchronization scope).

  • Linux package
  • Omnibus Docker
  • Helm Chart
  • Deckhouse Kubernetes Platform module

Signing in through LDAP is turned on by gitlab_rails['ldap_enabled']. The servers are described in gitlab_rails['ldap_servers'], whose value is a YAML document.

The value is parsed as YAML, so the indentation inside the block is significant and tab characters break it.

gitlab_rails['ldap_enabled'] = true
gitlab_rails['ldap_servers'] = YAML.load <<-'EOS'
  main:
    label: 'Head office'
    host: ldap-main.example.com
    port: 3389
    uid: 'cn'
    bind_dn: 'uid=viewer,ou=People,dc=example,dc=com'
    password: 'viewer123'
    base: 'ou=People,dc=example,dc=com'
    # Ignore users blocked in the directory (optional).
    user_filter: '(!(nsAccountLock=TRUE))'
    # The user is found in LDAP — sign-in is allowed immediately.
    block_auto_created_users: false
    sync_name: true
    group_sync:
      create_groups: true
      base: 'ou=Groups,dc=example,dc=com'
      filter: '(objectClass=groupOfNames)'
      prefix:
        attribute: 'businessCategory'
        default: 'default-program'
      top_level_group: 'LdapGroups'
      name_mask: '(?<=-)[A-z0-9]*$'
      owner: 'root'
      role_mapping:
        - by_name: '.*-project_manager-.*'
          gitlab_role: 'maintainer'
        - by_name: '.*-developer-.*'
          gitlab_role: 'developer'
        - by_name: '.*-participant-.*'
          gitlab_role: 'reporter'
  contractors:
    label: 'Contractors'
    host: ldap-contractors.example.com
    port: 3389
    uid: 'cn'
    bind_dn: 'uid=viewer,ou=People,dc=contractors,dc=example,dc=com'
    password: 'viewer123'
    base: 'ou=People,dc=contractors,dc=example,dc=com'
EOS
The keys are gitlab_rails['ldap_enabled'] and gitlab_rails['ldap_servers'] of the Linux package tab. The value of gitlab_rails['ldap_servers'] spans several lines, so write it in /srv/code/config/gitlab.rb on the configuration volume.

The servers are values under global.appConfig.ldap.servers, with the same keys the product reads. The bind password is taken from a Secret:

d8 k -n code create secret generic code-ldap-password \
  --from-literal=password='viewer123'
global:
  appConfig:
    ldap:
      servers:
        main:
          label: 'Head office'
          host: ldap-main.example.com
          port: 3389
          uid: 'cn'
          bind_dn: 'uid=viewer,ou=People,dc=example,dc=com'
          password:
            secret: code-ldap-password
            key: password
          base: 'ou=People,dc=example,dc=com'
          user_filter: '(!(nsAccountLock=TRUE))'
          block_auto_created_users: false
          sync_name: true
          group_sync:
            create_groups: true
            base: 'ou=Groups,dc=example,dc=com'
            filter: '(objectClass=groupOfNames)'
            top_level_group: 'LdapGroups'
            owner: 'root'
            role_mapping:
              - by_name: '.*-developer-.*'
                gitlab_role: 'developer'
        contractors:
          label: 'Contractors'
          host: ldap-contractors.example.com
          port: 3389
          uid: 'cn'
          bind_dn: 'uid=viewer,ou=People,dc=contractors,dc=example,dc=com'
          password:
            secret: code-ldap-password
            key: password
          base: 'ou=People,dc=contractors,dc=example,dc=com'

The servers are keys of the servers parameter in the spec.appConfig.ldap section:

servers:
  main:
    label: ldap
    host: 127.0.0.1
    port: 3389
    bindDn: 'uid=viewer,ou=People,dc=example,dc=com'
    base: 'ou=People,dc=example,dc=com'
    uid: 'cn'
    password: 'viewer123'
    syncName: true
    groupSync:
      createGroups: true
      base: 'ou=Groups,dc=example,dc=com'
      filter: '(objectClass=groupOfNames)'
      prefix:
        attribute: 'businessCategory'
        default: 'default-program'
      topLevelGroup: 'LdapGroups'
      nameMask: '(?<=-)[A-z0-9]*$'
      owner: 'root'
      roleMapping:
        - byName: '.*-project_manager-.*'
          gitlabRole: 'Maintainer'
        - byName: '.*-developer-.*'
          gitlabRole: 'Developer'
        - byName: '.*-participant-.*'
          gitlabRole: 'Reporter'

Multiple LDAP servers

Several servers are described by repeating the server entry under another key. Each server has its own connection parameters; the group_sync section with everything in it is taken into account only for the server under the main key (see Synchronization scope). How a user is identified and how the access decision is taken when the same user is found on several servers is described in Multiple LDAP servers.

  • Linux package
  • Omnibus Docker
  • Helm Chart
  • Deckhouse Kubernetes Platform module
The entries are keys of the same YAML document in gitlab_rails['ldap_servers'], as main and contractors in the LDAP servers section above.
The entries are the ones of the Linux package tab, written in /srv/code/config/gitlab.rb on the configuration volume.

The entries are keys under global.appConfig.ldap.servers, as main and contractors in the LDAP servers section above.

The entries are keys of the servers parameter in the spec.appConfig.ldap section:

servers:
  main:
    label: 'Head office'
    host: ldap-main.example.com
    base: 'ou=People,dc=example,dc=com'
    uid: 'cn'
    # Other connection parameters.
    groupSync:
      base: 'ou=Groups,dc=example,dc=com'
      roleMapping:
        - byName: '.*-developer-.*'
          gitlabRole: 'Developer'
  contractors:
    label: 'Contractors'
    host: ldap-contractors.example.com
    base: 'ou=People,dc=contractors,dc=example,dc=com'
    uid: 'cn'
    # Other connection parameters.

Linking OIDC accounts to LDAP

Automatic linking of the OIDC account to the LDAP account is turned on by the auto_link_ldap_user parameter. How the LDAP account is found, and what happens on the first and the subsequent sign-ins, is described in Linking OIDC accounts to LDAP.

  • Linux package
  • Omnibus Docker
  • Helm Chart
  • Deckhouse Kubernetes Platform module
gitlab_rails['omniauth_auto_link_ldap_user'] = true
The key is the one of the Linux package tab. Its value is a single line, so it fits into GITLAB_OMNIBUS_CONFIG as well as into /srv/code/config/gitlab.rb. 
global:
  appConfig:
    omniauth:
      autoLinkLdapUser: true

The parameter is set in the spec.appConfig.omniauth section:

autoLinkLdapUser: true

LDAP as the source of truth

To allow users found in LDAP to sign in immediately and to send everyone else for administrator approval, combine auto_link_ldap_user and block_auto_created_users of the OmniAuth parameters with block_auto_created_users of the main LDAP server (see LDAP as the source of truth).

  • Linux package
  • Omnibus Docker
  • Helm Chart
  • Deckhouse Kubernetes Platform module
gitlab_rails['omniauth_auto_link_ldap_user'] = true
# The user is not found in LDAP — the account is created blocked,
# pending administrator approval.
gitlab_rails['omniauth_block_auto_created_users'] = true
gitlab_rails['ldap_servers'] = YAML.load <<-'EOS'
  main:
    # The user is found in LDAP — sign-in is allowed immediately.
    block_auto_created_users: false
    # Other connection parameters.
EOS
The keys are the ones of the Linux package tab, written in /srv/code/config/gitlab.rb on the configuration volume. 
global:
  appConfig:
    omniauth:
      autoLinkLdapUser: true
      # The user is not found in LDAP — the account is created blocked,
      # pending administrator approval.
      blockAutoCreatedUsers: true
    ldap:
      servers:
        main:
          # The user is found in LDAP — sign-in is allowed immediately.
          block_auto_created_users: false

The parameters are set in the spec.appConfig section:

omniauth:
  autoLinkLdapUser: true
  # The user is not found in LDAP — the account is created blocked,
  # pending administrator approval.
  blockAutoCreatedUsers: true
ldap:
  servers:
    main:
      # The user is found in LDAP — sign-in is allowed immediately.
      blockAutoCreatedUsers: false

Synchronization schedule

The schedule of the synchronization job is written in cron format. What the job does on each run is described in LDAP synchronization; a run started by hand is described in Manual synchronization run.

  • Linux package
  • Omnibus Docker
  • Helm Chart
  • Deckhouse Kubernetes Platform module
gitlab_rails['ldap_sync_worker_cron'] = "0 * * * *"
The key is the one of the Linux package tab. Its value is a single line, so it fits into GITLAB_OMNIBUS_CONFIG as well as into /srv/code/config/gitlab.rb. 
global:
  appConfig:
    cron_jobs:
      ldap_sync_worker:
        cron: "0 * * * *"

The interval is set by the cronJobs parameter of the spec.appConfig section:

cronJobs:
  ldapSyncWorker:
    cron: "0 * * * *"

Applying the configuration

  • Linux package
  • Omnibus Docker
  • Helm Chart
  • Deckhouse Kubernetes Platform module

Every change to /etc/gitlab/gitlab.rb takes effect after:

sudo gitlab-ctl reconfigure

Apply the edited file inside the running container:

docker exec code gitlab-ctl reconfigure

A container restart applies the configuration as well, and it is the way a changed GITLAB_OMNIBUS_CONFIG of a recreated container takes effect:

docker restart code

Apply the edited values.yaml file to the release:

helm upgrade code deckhouse-code \
  -n code \
  -f values.yaml
The operator applies a changed CodeInstance itself.

Complete example: signing in through OIDC with permissions from LDAP

The steps below describe a setup where users sign in through an OIDC provider (for example, Keycloak), while groups, memberships, and roles come from LDAP.

The setup includes the following steps:

  1. Configure the LDAP provider.
  2. Configure the OIDC provider and enable the LDAP integration.
  3. Verify the integration upon first login.
  4. Synchronize permissions.

Prerequisites

To set this up, you’ll need:

  • An OIDC provider.
  • An LDAP directory with the same users and with groups whose names allow determining the role.
  • An LDAP service account with read access to the directory (the bind_dn and password parameters).

The uid or email value in the OIDC provider must match the value of the corresponding attribute in LDAP, otherwise linking will not work.

How the account is matched is described in How the LDAP account is found.

Configure the LDAP provider

The server entry names the directory, the search base and the service account, and its group_sync section turns the group names into roles.

  • Linux package
  • Omnibus Docker
  • Helm Chart
  • Deckhouse Kubernetes Platform module
gitlab_rails['ldap_enabled'] = true
gitlab_rails['ldap_servers'] = YAML.load <<-'EOS'
  main:
    label: ldap
    host: ldap.example.com
    port: 3389
    bind_dn: 'uid=viewer,ou=People,dc=example,dc=com'
    password: 'viewer123'
    base: 'ou=People,dc=example,dc=com'
    uid: 'cn'
    sync_name: true
    # Ignore users blocked in the directory (optional).
    user_filter: '(!(nsAccountLock=TRUE))'
    # The user is found in LDAP — sign-in is allowed immediately.
    block_auto_created_users: false
    group_sync:
      create_groups: true
      base: 'ou=Groups,dc=example,dc=com'
      filter: '(objectClass=groupOfNames)'
      top_level_group: 'LdapGroups'
      name_mask: '(?<=-)[A-z0-9]*$'
      owner: 'root'
      role_mapping:
        - by_name: '.*-maintainer-.*'
          gitlab_role: 'maintainer'
        - by_name: '.*-developer-.*'
          gitlab_role: 'developer'
        - by_name: '.*-participant-.*'
          gitlab_role: 'reporter'
EOS
The keys are gitlab_rails['ldap_enabled'] and gitlab_rails['ldap_servers'] of the Linux package tab, written in /srv/code/config/gitlab.rb on the configuration volume. 
global:
  appConfig:
    ldap:
      servers:
        main:
          label: ldap
          host: ldap.example.com
          port: 3389
          bind_dn: 'uid=viewer,ou=People,dc=example,dc=com'
          password:
            secret: code-ldap-password
            key: password
          base: 'ou=People,dc=example,dc=com'
          uid: 'cn'
          sync_name: true
          # Ignore users blocked in the directory (optional).
          user_filter: '(!(nsAccountLock=TRUE))'
          # The user is found in LDAP — sign-in is allowed immediately.
          block_auto_created_users: false
          group_sync:
            create_groups: true
            base: 'ou=Groups,dc=example,dc=com'
            filter: '(objectClass=groupOfNames)'
            top_level_group: 'LdapGroups'
            name_mask: '(?<=-)[A-z0-9]*$'
            owner: 'root'
            role_mapping:
              - by_name: '.*-maintainer-.*'
                gitlab_role: 'maintainer'
              - by_name: '.*-developer-.*'
                gitlab_role: 'developer'
              - by_name: '.*-participant-.*'
                gitlab_role: 'reporter'

Set up the configuration in the servers parameter of the spec.appConfig.ldap section:

servers:
  main:
    label: ldap
    host: ldap.example.com
    port: 3389
    bindDn: 'uid=viewer,ou=People,dc=example,dc=com'
    password: 'viewer123'
    base: 'ou=People,dc=example,dc=com'
    uid: 'cn'
    syncName: true
    # Ignore users blocked in the directory (optional).
    userFilter: '(!(nsAccountLock=TRUE))'
    # The user is found in LDAP — sign-in is allowed immediately.
    blockAutoCreatedUsers: false
    groupSync:
      createGroups: true
      base: 'ou=Groups,dc=example,dc=com'
      filter: '(objectClass=groupOfNames)'
      topLevelGroup: 'LdapGroups'
      nameMask: '(?<=-)[A-z0-9]*$'
      owner: 'root'
      roleMapping:
        - byName: '.*-maintainer-.*'
          gitlabRole: 'Maintainer'
        - byName: '.*-developer-.*'
          gitlabRole: 'Developer'
        - byName: '.*-participant-.*'
          gitlabRole: 'Reporter'

Configure the OIDC provider and enable linking to LDAP

Pay attention to the uid_field parameter: the field it points to becomes the account uid, and this value is used when looking the user up in LDAP. It must match the value of the attribute specified in the LDAP server uid parameter (cn in this example), or the email address — for details, see How the LDAP account is found.

The remaining provider parameters are described in the OpenID Connect (OIDC) section.

  • Linux package
  • Omnibus Docker
  • Helm Chart
  • Deckhouse Kubernetes Platform module
gitlab_rails['omniauth_enabled'] = true
gitlab_rails['omniauth_auto_link_ldap_user'] = true
gitlab_rails['omniauth_providers'] = [
  {
    name: 'openid_connect',   # Do not change this value.
    label: 'Keycloak',        # Sign-in button label.
    groups_attribute: 'gitlab_group',
    args: {
      name: 'openid_connect',
      scope: ['openid', 'profile', 'email'],
      response_type: 'code',
      issuer: 'https://keycloak.example.com/realms/example',
      discovery: true,
      client_auth_method: 'query',
      uid_field: 'preferred_username',
      send_scope_to_token_endpoint: false,
      pkce: true,
      client_options: {
        identifier: '<client_id>',
        secret: '<client_secret>',
        redirect_uri: 'https://code.example.com/users/auth/openid_connect/callback'
      }
    }
  }
]
The keys are gitlab_rails['omniauth_enabled'], gitlab_rails['omniauth_auto_link_ldap_user'] and gitlab_rails['omniauth_providers'] of the Linux package tab, written in /srv/code/config/gitlab.rb on the configuration volume.

The provider entry of this example is stored in a Secret and referenced from the values, with linking turned on beside it:

global:
  appConfig:
    omniauth:
      enabled: true
      autoLinkLdapUser: true
      providers:
        - secret: code-omniauth-keycloak
          key: provider

Set up the configuration in the spec.appConfig.omniauth section:

autoLinkLdapUser: true
providers:
  - name: 'openid_connect'   # Do not change this value.
    label: 'Keycloak'        # Sign-in button label.
    groupsAttribute: 'gitlab_group'
    args:
      name: 'openid_connect'
      scope:
        - 'openid'
        - 'profile'
        - 'email'
      response_type: 'code'
      issuer: 'https://keycloak.example.com/realms/example'
      discovery: true
      client_auth_method: 'query'
      uid_field: 'preferred_username'
      send_scope_to_token_endpoint: false
      pkce: true
      client_options:
        identifier: '<client_id>'
        secret: '<client_secret>'
        redirect_uri: 'https://code.example.com/users/auth/openid_connect/callback'

Verify linking on the first sign-in

To verify linking, follow these steps:

  1. Sign in with a test user through the OIDC provider.
  2. Open the user page in the admin area (/admin/users/<username>/identities). A linked account must have two identities: openid_connect and ldapmain (the LDAP identity name consists of the ldap prefix and the LDAP server name, main in this example).

If the LDAP identity is missing, check the following:

  • the uid or email values match in the OIDC provider and in LDAP;
  • the user falls within the base search scope and is not filtered out by user_filter;
  • the auto_link_ldap_user parameter is enabled.

Rights synchronization

Right after the first sign-in, the user has an account but no group or project memberships. Wait for the next synchronization or run it manually (see Manual synchronization run), then check that:

  • the groups are created inside the group specified in group_sync.top_level_group;
  • the user is added to them with the role matching role_mapping.
←
Authentication / Overview
Authentication / Linux package
→