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
-
Configure LDAP for user authentication
-
Map an existing attribute to the
attribute.username
-
Create a test user in your LDAP:
Attribute Value uid
maxmust42
givenName
Max
sn
Mustermann
mail
max.mustermann@tu-berlin.de
-
Try to log-in using that user
- it will be created with the username
max.mustermann
- it will be created with the username
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
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 onomniauth-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