Skip to content

LDAP sign-in uses email even if username attr is provided

Summary

New users signing in using LDAP get assigned a wrong username, based on their mail address instead of on the attribute specified under attributes.username.

This wasn't happening with 15.10, and seems to be a regression introduced with 15.11 (regression:15.11)

Steps to reproduce

  1. Configure LDAP for user authentication

  2. Map an existing attribute to the attribute.username

  3. Create a test user in your LDAP:

    Attribute Value
    uid maxmust42
    givenName Max
    sn Mustermann
    mail max.mustermann@tu-berlin.de

  4. Try to log-in using that user

    • it will be created with the username max.mustermann

What is the current bug behavior?

The username is generated out of the mail attribute

What is the expected correct behavior?

The username should be the value of whichever parameter is defined under attribute.username (in our case: uid => maxmust42)

Relevant logs and/or screenshots

May 16, 2023 @ 13:57:03.855 {"component": "gitlab","subcomponent":"production_json","level":"info","method":"POST","path":"/users/auth/ldaplegacy/callback","format":"html","controller":"Ldap::OmniauthCallbacksController","action":"ldaplegacy","status":302,"location":"https://test2.gitlab.tu-berlin.de/","time":"2023-05-16T11:57:03.851Z","params":[{"key":"authenticity_token","value":"[FILTERED]"},{"key":"username","value":"maxmust42"},{"key":"password","value":"[FILTERED]"},{"key":"remember_me","value":"1"}],"correlation_id":"01H0J6QGFVX075VBTWG74RHQ4F","meta.caller_id":"Ldap::OmniauthCallbacksController#ldaplegacy","meta.remote_ip":"141.23.30.198","meta.feature_category":"system_access","meta.user":"max.mustermann","meta.user_id":238,"meta.client_id":"user/238","remote_ip":"141.23.30.198","ua":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36","queue_duration_s":0.017327,"request_urgency":"default","target_duration_s":1,"redis_calls":27,"redis_duration_s":0.140671,"redis_read_bytes":2032,"redis_write_bytes":3508,"redis_cache_calls":13,"redis_cache_duration_s":0.085859,"redis_cache_read_bytes":1907,"redis_cache_write_bytes":1211,"redis_queues_calls":6,"redis_queues_duration_s":0.02815,"redis_queues_read_bytes":9,"redis_queues_write_bytes":1776,"redis_sessions_calls":5,"redis_sessions_duration_s":0.010837,"redis_sessions_read_bytes":110,"redis_sessions_write_bytes":241,"redis_shared_state_calls":3,"redis_shared_state_duration_s":0.015825,"redis_shared_state_read_bytes":6,"redis_shared_state_write_bytes":280,"db_count":75,"db_write_count":18,"db_cached_count":15,"db_replica_count":0,"db_primary_count":75,"db_main_count":75,"db_main_replica_count":0,"db_replica_cached_count":0,"db_primary_cached_count":15,"db_main_cached_count":15,"db_main_replica_cached_count":0,"db_replica_wal_count":0,"db_primary_wal_count":0,"db_main_wal_count":0,"db_main_replica_wal_count":0,"db_replica_wal_cached_count":0,"db_primary_wal_cached_count":0,"db_main_wal_cached_count":0,"db_main_replica_wal_cached_count":0,"db_replica_duration_s":0.0,"db_primary_duration_s":0.172,"db_main_duration_s":0.172,"db_main_replica_duration_s":0.0,"cpu_s":1.130994,"mem_objects":230238,"mem_bytes":26323040,"mem_mallocs":94859,"mem_total_bytes":35532560,"pid":40,"worker_id":"puma_0","rate_limiting_gates":[],"net_ldap_count":3,"net_ldap_duration_s":0.1567150428891182,"db_duration_s":0.50696,"view_duration_s":0.0,"duration_s":1.89057}
May 16, 2023 @ 13:57:03.546 {"component": "gitlab","subcomponent":"application_json","level":"debug","severity":"DEBUG","time":"2023-05-16T11:57:03.545Z","correlation_id":"01H0J6QGFVX075VBTWG74RHQ4F","message":"Instantiating Gitlab::Auth::Ldap::Person with LDIF:\ndn: uid=maxmust42,ou=user,dc=tu-berlin,dc=de\ngivenname: Max\nmail: max.mustermann@tu-berlin.de\nmemberof: cn=zecm_member,ou=Organisationunits,ou=Groups,dc=tu-berlin,dc=de\nsn: Mustermann\nuid: maxmust42\n"}
May 16, 2023 @ 13:57:03.498 {"component": "gitlab","subcomponent":"application_json","level":"info","severity":"INFO","time":"2023-05-16T11:57:03.497Z","correlation_id":"01H0J6QGFVX075VBTWG74RHQ4F","message":"(LDAP) saving user max.mustermann@tu-berlin.de from login with admin =\u003e false, extern_uid =\u003e uid=maxmust42,ou=user,dc=tu-berlin,dc=de"}

gitlab.yml:

      ldap:
        enabled: true
        prevent_ldap_sign_in: false
        servers:
          legacy:
            active_directory: false
            allow_username_or_email_login: false
            attributes:
              first_name: givenName
              last_name: sn
              name: computed_using_first_and_last_name
              username: uid
            lowercase_usernames: true
            uid: uid
            # … other attrs

Results of GitLab application Check

Expand for output related to the GitLab application check 
Checking GitLab subtasks ...

Checking GitLab Shell ...


GitLab Shell: ... GitLab Shell version >= 14.18.0 ? ... OK (14.18.0)
Running /home/git/gitlab-shell/bin/check
gitlab-shell self-check failed
Try fixing it:
Make sure GitLab is running;
Check the gitlab-shell configuration file:
sudo -u git -H editor /home/git/gitlab-shell/config.yml
Please fix the error above and rerun the checks.


Checking GitLab Shell ... Finished


Checking Gitaly ...


Gitaly: ... default ... OK


Checking Gitaly ... Finished


Checking Sidekiq ...


Sidekiq: ... Running? ... no
Try fixing it:
sudo -u git -H RAILS_ENV=production bin/background_jobs start
For more information see:
doc/install/installation.md in section "Install Init Script"
see log/sidekiq.log for possible errors
Please fix the error above and rerun the checks.


Checking Sidekiq ... Finished


Checking Incoming Email ...


Incoming Email: ... Reply by email is disabled in config/gitlab.yml


Checking Incoming Email ... Finished


Checking LDAP ...


LDAP: ... Server: ldaplegacy
not verifying SSL hostname of LDAPS server 'ldap-slaves.tu-berlin.de:636'
LDAP authentication... Success
LDAP users with access to your GitLab server (only showing the first 100 results)
User output sanitized. Found 91 users of 100 limit.


Checking LDAP ... Finished


Checking GitLab App ...


Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Cable config exists? ... yes
Resque config exists? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... skipped (no tmp uploads folder yet)
Systemd unit files or init script exist? ... no
Try fixing it:
Install the Service
For more information see:
doc/install/installation.md in section "Install the Service"
Please fix the error above and rerun the checks.
Systemd unit files or init script up-to-date? ... can't check because of previous errors
Projects have namespace: ...
213/1 ... yes
6/2 ... yes
6/37 ... yes
6/40 ... yes
122/119 ... yes
101/140 ... yes
101/151 ... yes
101/152 ... yes
6/193 ... yes
180/204 ... yes
121/205 ... yes
6/206 ... yes
197/207 ... yes
6/214 ... yes
6/247 ... yes
6/248 ... yes
6/287 ... yes
299/288 ... yes
299/321 ... yes
6/322 ... yes
6/323 ... yes
6/324 ... yes
Redis version >= 6.0.0? ... yes
Ruby version >= 2.7.2 ? ... yes (3.0.6)
Git user has default SSH configuration? ... yes
Active users: ... 13
Is authorized keys file accessible? ... skipped (authorized keys not enabled)
GitLab configured to store new projects in hashed storage? ... yes
All projects are in hashed storage? ... yes
Elasticsearch version 7.x-8.x or OpenSearch version 1.x ... skipped (Advanced Search is disabled)
All migrations must be finished before doing a major upgrade ... skipped (Advanced Search is disabled)


Checking GitLab App ... Finished


Checking GitLab subtasks ... Finished

Possible fixes

Workaround

(From comment by Drew below):

While we triage this and determine whether it's a regression, I believe a workaround is to set auto_link_ldap_user to true. This overrides some code in GitLab that causes us to do our own lookup and set the username rather than relying on omniauth-ldap. This has worked for some other users we've worked with.

For Omnibus that would be gitlab_rails['omniauth_auto_link_ldap_user'] = true

Edited by Alvin Gounder