Ldap gitlab что это
Как настроить LDAP авторизацию в Gitlab 7.9.1 на Ubuntu 14
Всем привет после того как мы установили Gitlab, нужно чтобы пользователи домена проходили авторизацию в Gitlab через LDAP, давайте научимся это делать и не будем заставлять пользователей запоминать еще один пароль, всегда старайтесь, чтобы локальных учетных записей было поменьше, надежнее и правильнее с точки зрения безопасности, иметь централизованную базу данных с учетками, и управлять ей проще в разы, поверьте связка LDAP Gitlab, отличное тому доказательство, конечно придется по шаманить с конфигурационными файлами, но не волнуйтесь ниже, об этом все подробно описано. как говорится step by step.
Настройка LDAP в Gitlab
И так, открываем Midnight Commander с помощью команды mc и идем в
Как настроить LDAP авторизацию в Gitlab 7.9.1 на Ubuntu 14-02
Вас спросят каким редактором его открывать я буду использовать встроенный и нажимаю 3
Как настроить LDAP авторизацию в Gitlab 7.9.1 на Ubuntu 14-03
Перед вами откроется конфигурационный файл который мы и будем править. Данный конфиг как раз и поможет нам настроить LDAP авторизацию в Gitlab 7.9.1. Хочу сказать, что для авторизации нам потребуется создать обычную учетку в Active Directory, без всяких дополнительных полномочий.
Как настроить LDAP авторизацию в Gitlab 7.9.1 на Ubuntu 14-04
Integrate LDAP with GitLab
GitLab integrates with LDAP to support user authentication.
Security
GitLab has multiple mechanisms to verify a user is still active in LDAP. If the user is no longer active in LDAP, they are placed in an ldap_blocked status and are signed out. They are unable to sign in using any authentication provider until they are reactivated in LDAP.
Security risks
Configure LDAP
After configuring LDAP, to test the configuration, use the LDAP check Rake task.
LDAP users must have a set email address, regardless of whether or not it’s used to sign in.
Example Omnibus GitLab configuration
This example shows configuration for Omnibus GitLab instances:
Example source install configuration
This example shows configuration for source install instances:
Basic configuration settings
Examples of user filters
SSL configuration settings
Attribute configuration settings
LDAP sync configuration settings
These LDAP sync configuration settings are available:
| Setting | Description | Required | Examples |
|---|---|---|---|
| group_base | Base used to search for groups. | No | ‘ou=groups,dc=gitlab,dc=example’ |
| admin_group | The CN of a group containing GitLab administrators. Not cn=administrators or the full DN. | No | ‘administrators’ |
| external_groups | An array of CNs of groups containing users that should be considered external. Not cn=interns or the full DN. | No | [‘interns’, ‘contractors’] |
| sync_ssh_keys | The LDAP attribute containing a user’s public SSH key. | No | ‘sshPublicKey’ or false if not set |
Use multiple LDAP servers
Example of multiple LDAP servers
The following example shows how to configure three LDAP servers in gitlab.rb :
This example results in the following sign-in page:
Set up LDAP user filter
Example user filter for Omnibus GitLab instances:
Example user filter for source install instances:
To limit access to the nested members of an Active Directory group, use the following syntax:
For more information about LDAP_MATCHING_RULE_IN_CHAIN filters, see Search Filter Syntax.
Support for nested members in the user filter shouldn’t be confused with group sync nested groups support.
GitLab does not support the custom filter syntax used by OmniAuth LDAP.
Escape special characters
The user_filter DN can contain special characters. For example:
Open and close brackets:
These characters must be escaped as documented in RFC 4515.
Enable LDAP username lowercase
Some LDAP servers, depending on their configurations, can return uppercase usernames. This can lead to several confusing issues such as creating links or namespaces with uppercase names.
Omnibus configuration
Reconfigure GitLab for the changes to take effect.
Source configuration
Restart GitLab for the changes to take effect.
Disable LDAP web sign in
It can be useful to prevent using LDAP credentials through the web UI when an alternative such as SAML is preferred. This allows LDAP to be used for group sync, while also allowing your SAML identity provider to handle additional checks like custom 2FA.
When LDAP web sign in is disabled, users don’t see an LDAP tab on the sign-in page. This does not disable using LDAP credentials for Git access.
Omnibus configuration
Reconfigure GitLab for the changes to take effect.
Source configuration
Restart GitLab for the changes to take effect.
Use encrypted credentials
Instead of having the LDAP integration credentials stored in plaintext in the configuration files, you can optionally use an encrypted file for the LDAP credentials. To use this feature, first you must enable GitLab encrypted configuration.
The unencrypted contents of the file should be a subset of the secret settings from your servers block in the LDAP configuration.
The encrypted contents can be configured with the LDAP secret edit Rake command.
Omnibus configuration
Edit the encrypted secret:
The unencrypted contents of the LDAP secret should be entered like:
Reconfigure GitLab for the changes to take effect.
Source configuration
If initially your LDAP configuration looked like:
Edit the encrypted secret:
The unencrypted contents of the LDAP secret should be entered like:
Restart GitLab for the changes to take effect.
Disable anonymous LDAP authentication
The TLS client authentication setting in your LDAP server cannot be mandatory and clients cannot be authenticated with the TLS protocol.
Deleting users
However, these users can continue to use Git with SSH until the next time the LDAP check cache runs.
To delete the account immediately, you can manually block the user.
Google Secure LDAP
Introduced in GitLab 11.9.
Google Cloud Identity provides a Secure LDAP service that can be configured with GitLab for authentication and group sync. See Google Secure LDAP for detailed configuration instructions.
Synchronize users and groups
For more information on synchronizing users and groups between LDAP and GitLab, see LDAP synchronization.
LDAP synchronization
If you have configured LDAP to work with GitLab, GitLab can automatically synchronize users and groups. This process updates user and group information.
You can change when synchronization occurs.
User sync
Once per day, GitLab runs a worker to check and update GitLab users against LDAP.
In Active Directory, a user is marked as disabled/blocked if the user account control attribute ( userAccountControl:1.2.840.113556.1.4.803 ) has bit 2 set.
The user is set to an ldap_blocked state in GitLab if the previous conditions fail. This means the user cannot sign in or push or pull code.
Adjust LDAP user sync schedule
By default, GitLab runs a worker once per day at 01:30 a.m. server time to check and update GitLab users against LDAP.
You can manually configure LDAP user sync times by setting the following configuration values, in cron format. If needed, you can use a crontab generator. The example below shows how to set LDAP user sync to run once every 12 hours at the top of the hour.
Omnibus installations
Reconfigure GitLab for the changes to take effect.
Source installations
Restart GitLab for the changes to take effect.
Group sync
If your LDAP supports the memberof property, when the user signs in for the first time GitLab triggers a sync for groups the user should be a member of. That way they don’t have to wait for the hourly sync to be granted access to their groups and projects.
A group sync process runs every hour on the hour, and group_base must be set in LDAP configuration for LDAP synchronizations based on group CN to work. This allows GitLab group membership to be automatically updated based on LDAP group members.
Omnibus configuration
Source configuration
Restart GitLab for the changes to take effect.
To take advantage of group sync, group Owners or users with the Maintainer role must create one or more LDAP group links.
Add group links
For information on adding group links by using CNs and filters, refer to the GitLab groups documentation.
Administrator sync
As an extension of group sync, you can automatically manage your global GitLab administrators. Specify a group CN for admin_group and all members of the LDAP group are given administrator privileges. The configuration looks like the following.
Omnibus configuration
Source configuration
Restart GitLab for the changes to take effect.
Global group memberships lock
“Lock memberships to LDAP synchronization” setting allows instance administrators to lock down user abilities to invite new members to a group.
Adjust LDAP group sync schedule
By default, GitLab runs a group sync process every hour, on the hour. The values shown are in cron format. If needed, you can use a Crontab Generator.
You can manually configure LDAP group sync times by setting the following configuration values. The example below shows how to set group sync to run once every two hours at the top of the hour.
Omnibus installations
Reconfigure GitLab for the changes to take effect.
Source installations
Restart GitLab for the changes to take effect.
External groups
Using the external_groups setting allows you to mark all users belonging to these groups as external users. Group membership is checked periodically through the LdapGroupSync background task.
Omnibus configuration
Source configuration
Restart GitLab for the changes to take effect.
Group sync technical details
This section outlines what LDAP queries are executed and what behavior you can expect from group sync.
Group member access are downgraded from a higher level if their LDAP group membership changes. For example, if a user the Owner role in a group and the next group sync reveals they should only have the Developer role, their access is adjusted accordingly. The only exception is if the user is the last owner in a group. Groups need at least one owner to fulfill administrative duties.
Supported LDAP group types/attributes
Other object classes should work if members are defined as one of the mentioned attributes.
Active Directory supports nested groups. Group sync recursively resolves membership if active_directory: true is set in the configuration file.
Nested group memberships
Queries
Benchmarks
Group sync was written to be as performant as possible. Data is cached, database queries are optimized, and LDAP queries are minimized. The last benchmark run revealed the following metrics:
These metrics are meant to provide a baseline and performance may vary based on any number of factors. This benchmark was extreme and most instances don’t have near this many users or groups. Disk speed, database performance, network and LDAP server response time affects these metrics.
How to configure LDAP with GitLab CE
Article Type: admin guide || Level: intermediary || Author: Chris Wilson || Publication date: 2017/05/03
Introduction
Managing a large number of users in GitLab can become a burden for system administrators. As an organization grows so do user accounts. Keeping these user accounts in sync across multiple enterprise applications often becomes a time consuming task.
In this guide we will focus on configuring GitLab with Active Directory. Active Directory is a popular LDAP compatible directory service provided by Microsoft, included in all modern Windows Server operating systems.
GitLab has supported LDAP integration since version 2.2. With GitLab LDAP group syncing being added to GitLab Enterprise Edition in version 6.0. LDAP integration has become one of the most popular features in GitLab.
Getting started
Choosing an LDAP Server
The main reason organizations choose to utilize a LDAP server is to keep the entire organization’s user base consolidated into a central repository. Users can access multiple applications and systems across the IT environment using a single login. Because LDAP is an open, vendor-neutral, industry standard application protocol, the number of applications using LDAP authentication continues to increase.
There are many commercial and open source directory servers that support the LDAP protocol. Deciding on the right directory server highly depends on the existing IT environment in which the server will be integrated with.
For example, Active Directory is generally favored in a primarily Windows environment, as this allows quick integration with existing services. Other popular directory services include:
GitLab uses the Net::LDAP library under the hood. This means it supports all IETF compliant LDAPv3 servers.
Active Directory (AD)
We won’t cover the installation and configuration of Windows Server or Active Directory Domain Services in this tutorial. There are a number of resources online to guide you through this process:
Install Active Directory Domain Services (AD DS) (technet.microsoft.com)- Install Active Directory Domain Services
Creating an AD OU structure
Configuring organizational units (OUs) is an important part of setting up Active Directory. OUs form the base for an entire organizational structure. Using GitLab as an example we have designed the OU structure below using the geographic OU model. In the Geographic Model we separate OUs for different geographic regions.
| GitLab OU Design | GitLab AD Structure |
|---|---|
 |  |
Using PowerShell you can output the OU structure as a table (all names are examples only):
See more information on searching Active Directory with Windows PowerShell from The Scripting Guys
GitLab LDAP configuration
The initial configuration of LDAP in GitLab requires changes to the gitlab.rb configuration file. Below is an example of a complete configuration using an Active Directory.
Example gitlab.rb LDAP
Note: Remember to run gitlab-ctl reconfigure after modifying gitlab.rb
Security improvements (LDAPS)
Security is an important aspect when deploying an LDAP server. By default, LDAP traffic is transmitted unsecured. LDAP can be secured using SSL/TLS called LDAPS, or commonly «LDAP over SSL».
Securing LDAP (enabling LDAPS) on Windows Server 2012 involves installing a valid SSL certificate. For full details see Microsoft’s guide How to enable LDAP over SSL with a third-party certification authority
By default a LDAP service listens for connections on TCP and UDP port 389. LDAPS (LDAP over SSL) listens on port 636
Testing you AD server
Using AdFind (Windows)
You can use the AdFind utility (on Windows based systems) to test that your LDAP server is accessible and authentication is working correctly. This is a freeware utility built by Joe Richards.
Return all objects
You can use the filter objectclass=* to return all directory objects.
Return single object using filter
Using ldapsearch (Unix)
You can use the ldapsearch utility (on Unix based systems) to test that your LDAP server is accessible and authentication is working correctly. This utility is included in the ldap-utils package.
Return all objects
You can use the filter objectclass=* to return all directory objects.
Return single object using filter
Basic user authentication
After configuring LDAP, basic authentication will be available. Users can then login using their directory credentials. An extra tab is added to the GitLab login screen for the configured LDAP server (e.g «GitLab AD«).
Users that are removed from the LDAP base group (e.g OU=GitLab INT,DC=GitLab,DC=org ) will be blocked in GitLab. More information on LDAP security.
LDAP extended features on GitLab EE
With GitLab Enterprise Edition (EE), besides everything we just described, you’ll have extended functionalities with LDAP, such as:
Read through the article on LDAP for GitLab EE for an overview.
Ldap gitlab что это
Integrate LDAP with GitLab (FREE SELF)
GitLab integrates with LDAP to support user authentication.
This integration works with most LDAP-compliant directory servers, including:
Users added through LDAP:
The LDAP DN is associated with existing GitLab users when:
If an existing GitLab user wants to enable LDAP sign-in for themselves, they should:
GitLab has multiple mechanisms to verify a user is still active in LDAP. If the user is no longer active in LDAP, they are placed in an ldap_blocked status and are signed out. They are unable to sign in using any authentication provider until they are reactivated in LDAP.
Users are considered inactive in LDAP when they:
Status is checked for all LDAP users:
You should only use LDAP integration if your LDAP users cannot:
To configure LDAP integration, add your LDAP server settings in:
After configuring LDAP, to test the configuration, use the LDAP check Rake task.
LDAP users must have a set email address, regardless of whether or not it’s used to sign in.
Example Omnibus GitLab configuration
This example shows configuration for Omnibus GitLab instances:
Example source install configuration
This example shows configuration for source install instances:
Basic configuration settings
These configuration settings are available:
Examples of user filters
Some examples of the user_filter field syntax:
SSL configuration settings
These SSL configuration settings are available:
Attribute configuration settings
GitLab uses these LDAP attributes to create an account for the LDAP user. The specified attribute can be either:
LDAP sync configuration settings (PREMIUM SELF)
These LDAP sync configuration settings are available:
| Setting | Description | Required | Examples |
|---|---|---|---|
| group_base | Base used to search for groups. | No | ‘ou=groups,dc=gitlab,dc=example’ |
| admin_group | The CN of a group containing GitLab administrators. Not cn=administrators or the full DN. | No | ‘administrators’ |
| external_groups | An array of CNs of groups containing users that should be considered external. Not cn=interns or the full DN. | No | [‘interns’, ‘contractors’] |
| sync_ssh_keys | The LDAP attribute containing a user’s public SSH key. | No | ‘sshPublicKey’ or false if not set |
Use multiple LDAP servers (PREMIUM SELF)
If you have users on multiple LDAP servers, you can configure GitLab to use them. To add additional LDAP servers:
Example of multiple LDAP servers
The following example shows how to configure three LDAP servers in gitlab.rb :
This example results in the following sign-in page:
Set up LDAP user filter
Example user filter for Omnibus GitLab instances:
Example user filter for source install instances:
To limit access to the nested members of an Active Directory group, use the following syntax:
For more information about LDAP_MATCHING_RULE_IN_CHAIN filters, see Search Filter Syntax.
Support for nested members in the user filter shouldn’t be confused with group sync nested groups support.
GitLab does not support the custom filter syntax used by OmniAuth LDAP.
Escape special characters
The user_filter DN can contain special characters. For example:
Open and close brackets:
These characters must be escaped as documented in RFC 4515.
Enable LDAP username lowercase
Some LDAP servers, depending on their configurations, can return uppercase usernames. This can lead to several confusing issues such as creating links or namespaces with uppercase names.
Omnibus configuration
Reconfigure GitLab for the changes to take effect.
Source configuration
Restart GitLab for the changes to take effect.
Disable LDAP web sign in
It can be useful to prevent using LDAP credentials through the web UI when an alternative such as SAML is preferred. This allows LDAP to be used for group sync, while also allowing your SAML identity provider to handle additional checks like custom 2FA.
When LDAP web sign in is disabled, users don’t see an LDAP tab on the sign-in page. This does not disable using LDAP credentials for Git access.
Omnibus configuration
Reconfigure GitLab for the changes to take effect.
Source configuration
Restart GitLab for the changes to take effect.
Use encrypted credentials
Instead of having the LDAP integration credentials stored in plaintext in the configuration files, you can optionally use an encrypted file for the LDAP credentials. To use this feature, first you must enable GitLab encrypted configuration.
The unencrypted contents of the file should be a subset of the secret settings from your servers block in the LDAP configuration.
The supported configuration items for the encrypted file are:
The encrypted contents can be configured with the LDAP secret edit Rake command.
Omnibus configuration
If initially your LDAP configuration looked like:
Edit the encrypted secret:
The unencrypted contents of the LDAP secret should be entered like:
Reconfigure GitLab for the changes to take effect.
Source configuration
If initially your LDAP configuration looked like:
Edit the encrypted secret:
The unencrypted contents of the LDAP secret should be entered like:
Restart GitLab for the changes to take effect.
Disable anonymous LDAP authentication
GitLab doesn’t support TLS client authentication. Complete these steps on your LDAP server.
The TLS client authentication setting in your LDAP server cannot be mandatory and clients cannot be authenticated with the TLS protocol.
Users deleted from the LDAP server:
However, these users can continue to use Git with SSH until the next time the LDAP check cache runs.
To delete the account immediately, you can manually block the user.
Google Secure LDAP
Google Cloud Identity provides a Secure LDAP service that can be configured with GitLab for authentication and group sync. See Google Secure LDAP for detailed configuration instructions.
Synchronize users and groups
For more information on synchronizing users and groups between LDAP and GitLab, see LDAP synchronization.
