Fix blocked ldap user in GitLab container using GitLabs shell

If you are running GitLab in a docker container and your are using some directory service, for example ActiveDirectory with LDAPS for authentication, you might face the challenge, that when a user is moved in ActiveDirectory to another ad-group or the ad-group which is used as user-filter is deleted, then GitLab marks the user as "blocked".

Unblock the ldap user in GitLab

1. Connect to the docker host server
2. Open a connection to GitLabs Shell using docker exec -it <container-name> gitlab-rails console -e production
3. Find the user in GitLabs Shell using user = User.find_by_email("someone@e-mail")
4. Check the Users state using user.state
5. Unblock the user using user.state = "active"
6. Save using user.save
7. Exit

Example:

prdrhel8180:/ #
prdrhel8180:/ # docker exec -it gitlab gitlab-rails console -e production
--------------------------------------------------------------------------------
Ruby: ruby 2.7.5p203 (2021-11-24 revision f69aeb8314) [x86_64-linux]
GitLab: 15.3.1-ee (518311979e3) EE
GitLab Shell: 14.10.0
PostgreSQL: 12.10
------------------------------------------------------------[ booted in 37.73s ]
Loading production environment (Rails 6.1.6.1)
irb(main):001:0> user = User.find_by_email("someone@e-mail")
=> nil
irb(main):002:0> user = User.find_by_email("someone@e-mail.com")
=> #<User id:55 @someone>
irb(main):003:0> user.state
=> "ldap_blocked"
irb(main):004:0> user.state = "active"
=> "active"
irb(main):005:0> user.save
=> true
irb(main):006:0> exit
prdrhel8180:/ #
prdrhel8180:/ #

Fix the LDAP user filter

If the user was blocked due to a deleted AD group, which was used as ldap user filter, then you have to fix the LDAP connect from GitLab to ActiveDirectory. GitLab will log this in /var/log/gitlab/gitlab-rails/application.log as:

2023-02-02T01:30:18.098Z: LDAP account "cn=lastname\, firstname,ou=deleted-users,ou=someou,dc=internal,dc=domain,dc=local" does not exist anymore, blocking GitLab user "Lastname, Firstname" (firstname.lastname@domain.local)

prdrhel8180:/ #
prdrhel8180:/ # docker exec -it gitlab cat /etc/gitlab/gitlab.rbgitlab_rails
gitlab_rails['ldap_servers'] = YAML.load <<- br=""> someldap: #
label: 'LDAP'
host: 'some-ldaps-vip.internal.domain.local'
port: 636
uid: 'sAMAccountName'
[...]
user_filter: '(|(memberOf=CN=SomeGroup,OU=Groups,OU=SomeOU,DC=internal,DC=domain,DC=local)(memberOf=CN=SomeGroup2,OU=Groups2,OU=SomeOU2,DC=internal,DC=domain,DC=local))'
prdrhel8180:/ #
prdrhel8180:/ #

The user_filter has to be adjusted to the new AD group, which includes the blocked user(s).

FortiGate default configuration does not verify the LDAP server identity - CVE-2019-5591

I have found a vulnerability in all FortiOS versions, including the current 5.4/5.6/6.0/6.2 branches. The issue has been fixed in 6.0.3/6.2.1 by using the new feature "server-identity-check":
 

The vulnerability is in the LDAPS connection of the FortiGate to a LDAP-Server. The FortiGate does not properly check the certificate sent from the LDAP-Server, allthough the correct CA certificate is configured. More details will be published later.

Fortinet PSIRT-team responded quickly, has acknowledged the issue, told me that some one else also reported the issue, assigned CVE-2019-5591 to it and released the following PSIRT advisory: https://fortiguard.com/psirt/FG-IR-19-037

Solution:

Update to FortiOS 6.0.3+ or 6.2.1+ and set the following option:


config user ldap
edit ldap-server
set server-identity-check enable