Error message showing as below while trying to login to on prem gitlab:gitlab access denied
Background
Gitlab is using LDAP (Microsoft Active Directory) to authenticate users.
Confirmed with others users, only a small group of users are affected.
Keep digging information by asking around… previously, users were in 2 different ldap schema, admin used gitlab-rake gitlab:ldap:rename_provider[ldapbackup,ldapmain] to merge all old users to a single auth provider. But tested yesterday, login was fine.
Diagnostic
check log file: /var/log/gitlab/gitlab-rail/production.log while perform login action again…
Processing by Ldap::OmniauthCallbacksController#ldapmain as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"[FILTERED]", "username"=>"riveryang", "password"=>"[FILTERED]"}
LDAP search error: No Such Object
LDAP search error: No Such Object
Could not update DN for riveryang (451)
error messages: {:extern_uid=>["has already been taken"], :user=>["has already been taken"]}
Redirected to https://gitlab.domain.works/users/sign_in
Seems like it cannot find my name riveryang by using DN, but when trying to update with new DN, error saying extern_uid and user has been taken
Searched around in Google, cannot find any useful information…
check in db (danger, please make sure you know what you are doing)
I don’t know what’s gitlab’s DB looks like, so decided to look around. lol~
We can see all headers as object’s properties above, but nothing mentioned about Ldap schema or otherthings.
Also listed few users’s status by select * from user where name like 'riveryang', nothing interesting or very useful, but I found my id is 792…
As I got my user_id, check other tables user_synced_attributes_metadata:
1
2
3
4
5
6
7
8
9
10
gitlabhq_production=> select * from user_synced_attributes_metadata;
id | name_synced | email_synced | location_synced | user_id | provider
-------+-------------+--------------+-----------------+---------+------------
62 | f | t | f | 4 |
66 | f | t | f | 15 |
8335 | f | t | f | 273 | ldapmain
25250 | f | t | f | 565 | ldapmain
24843 | f | t | f | 431 | ldapmain
11527 | f | t | f | 298 | ldapmain
...
Interesting, at least we got some mapping information between user_id and provider ldapmain, check if mine is mapped:
1
2
3
gitlabhq_production=> select * from user_synced_attributes_metadata where user_id = 792;
id | name_synced | email_synced | location_synced | user_id | provider
-------+-------------+--------------+-----------------+---------+----------
Uhmm, nothing… Probably that’s why?
What if I manually add here? (I know I shouldn’t do it, but just want to verify…)
1
2
3
4
gitlabhq_production=> insert into
user_synced_attributes_metadata(name_synced, email_synced, location_synced, user_id, provider)
values
('f','t','f',792,'ldapmain');
Try again with web portal: same error… and try to do a search again
1
2
3
gitlabhq_production=> select * from user_synced_attributes_metadata where user_id = 792;
id | name_synced | email_synced | location_synced | user_id | provider
-------+-------------+--------------+-----------------+---------+----------
IT’S GONE!!! So, it’s dynamically changed by some logic behind sense… Well. OK…
Keep digging… search for other tables that may relevent…
