GitLab access OpenLDAP and AD Domains

GitLab access OpenLDAP and AD Domains

Today, we debugged GitLab to access AD domain control and found a lot of information to solve the problem. Here we will record it.

GitLab has its own user mechanism, but it is also compatible with ldap's user authentication mechanism (in essence, both OpenLDAP and AD domain control are based on the LDAP mechanism). As the company's internal unified account mechanism is being adjusted, therefore, GitLab needs to be configured. After testing, the GitLab of the Community edition can use OpenLDAP and Microsoft AD domain control as its user mechanism after modifying the configuration file.

Version: gitlab Community version 9.3.4 (Chinese)

Gitlab Directory:/etc/gitlab

Gitlab configuration file:/etc/gitlab. rb (the content of this file is blank in the Community version)

1. Access openldap

1.1 modify the configuration file gitlab. rb

Add the following configuration in the gitlab. rb file:

1. host: the ip address of openldap, which can be modified according to the actual situation;

2. uid, which can be configured with cn or uid, which can be identified (why not study it in depth );

3. bind_dn: the Administrator account of openldap, which can be modified according to the actual situation;

4. password, the administrator of openldap, which can be modified according to the actual situation;

5. active_directory indicates whether the connection is active domain control. This part is configured in openldap and false;

6. allow_username_or_email_login, which indicates whether the user name and email address can be used for Logon. Therefore, you can configure true for ease of use;

7. base: the directory where the user list is located. Because the new users are all under the People of openldap, the configuration is modified according to the actual situation;

# Specify the service address
External_url = 'HTTP: // localhost'

# Enable ldap
Gitlab_rails ['ldap _ enabled'] = true
Gitlab_rails ['ldap _ servers'] = YAML. load <-'eos '###! ** Remember to close this block with 'eos 'Below **
Main: # 'main' is the GitLab 'provider id' of this LDAP server
Label: 'ldap'
Host: '192. 168.6.4'
Port: 389
Uid: 'uid'
Method: 'plain '# "tls" or "ssl" or "plain"
Bind_dn: 'cn = Manager, dc = abc, dc = cn'
Password: '000000'
Active_directory: false
Allow_username_or_email_login: true
Block_auto_created_users: false
Base: 'ou = People, dc = abc, dc = cn'
User_filter :''
EOS

1.2 reload new configuration

# gitlab-ctl reconfigure

The last line after running is "gitlab Reconfigured !" It indicates that the new configuration is successfully loaded. Otherwise, an error is returned based on the error message.

1.3 check whether the user list can be obtained normally

# gitlab-rake gitlab:ldap:check

You can view the user list after running the command normally.

1.4 restart gitlab

# gitlab-ctl restart

 

After successful restart, the gitlab interface will become as follows.

 

Openldap Users enter through the "LDAP" page, and the administrator root enters through the "standard" page.

Ii. Access AD

2.1 modify the configuration file gitlab. rb

Add the following configuration in the gitlab. rb file:

1. host is the ip address of the Microsoft Domain Server, which is modified according to the actual situation;

2. uid. sAMAccountName must be configured for identification;

3. bind_dn: the Administrator account of the Domain Server, which can be modified according to the actual situation;

4. password, the administrator of the Domain Server, which can be modified according to the actual situation;

5. active_directory indicates whether the connection is active domain control. This part is the configuration of the Domain Server, so it is true;

6. allow_username_or_email_login, which indicates whether the user name and email address can be used for Logon. Therefore, you can configure true for ease of use;

7. base, the directory where the User list is located, because the new users are all under People (gitlab failed to detect the User when the User was put in the User experiment, so a new directory "People" was created, and moved the new user to the directory). Therefore, the configuration is modified according to the actual situation;

external_url = 'http://localhost'gitlab_rails['ldap_enabled'] = truegitlab_rails['ldap_servers'] = YAML.load <<-'EOS' ###! **remember to close this block with 'EOS' below**main: # 'main' is the GitLab 'provider ID' of this LDAP server  label: 'LDAP'  host: '192.168.6.1'  port: 389  uid: 'sAMAccountName'  method: 'plain' # "tls" or "ssl" or "plain"  bind_dn: 'cn=Administrator,cn=users,dc=myad,dc=cn'  password: '123456'  active_directory: true  allow_username_or_email_login: true  block_auto_created_users: false  base: 'ou=People,dc=myad,dc=cn'  user_filter: ''EOS 

2.2 reload new configuration

# gitlab-ctl reconfigure

The last line after running is "gitlab Reconfigured !" It indicates that the new configuration is successfully loaded. Otherwise, an error is returned based on the error message.

2.3 check whether the user list can be obtained normally

# gitlab-rake gitlab:ldap:check

You can view the user list after running the command normally.

2.4 restart gitlab

# gitlab-ctl restart

 

After successful restart, the gitlab interface will become as follows.

 

Openldap Users enter through the "LDAP" page, and the administrator root enters through the "standard" page.

2.5 confirm that the user is not in a special status

1. The account is not in the "forbidden account" status;

2. It is not in the "Change Password Upon first login" status;

(An account in any of the above States will report "Cloud not authenticate you from Ldapmain because" Invalid creadentials "." When logging on to gitlab ".")