kotovalexarian-likes-gitlab/gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

General improvements to LDAP docs

Browse source
This commit is contained in:
Evan Read 2019-08-01 08:37:18 +00:00 committed by Achilleas Pipinellis
parent abbcef43d7
commit ad228df774
2 changed files with 103 additions and 73 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

126
doc/administration/auth/ldap-ee.md
View file

@ -4,37 +4,27 @@ type: reference
# LDAP Additions in GitLab EE **(STARTER ONLY)**
This is a continuation of the main [LDAP documentation](ldap.md), detailing LDAP
features specific to GitLab Enterprise Edition Starter, Premium and Ultimate.
This section documents LDAP features specific to to GitLab Enterprise Edition
[Starter](https://about.gitlab.com/pricing/#self-managed) and above.
## Overview
[LDAP](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol)
stands for **Lightweight Directory Access Protocol**, which
is a standard application protocol for
accessing and maintaining distributed directory information services
over an Internet Protocol (IP) network.
GitLab integrates with LDAP to support **user authentication**. This integration
works with most LDAP-compliant directory servers, including Microsoft Active
Directory, Apple Open Directory, Open LDAP, and 389 Server.
**GitLab Enterprise Edition** includes enhanced integration, including group
membership syncing.
For documentation relevant to both Community Edition and Enterprise Edition,
see the main [LDAP documentation](ldap.md).
## Use cases
- User sync: Once a day, GitLab will update users against LDAP
- User sync: Once a day, GitLab will update users against LDAP.
- Group sync: Once an hour, GitLab will update group membership
based on LDAP group members
based on LDAP group members.
## Multiple LDAP servers
## Multiple LDAP servers **(STARTER ONLY)**
With GitLab Enterprise Edition Starter, you can configure multiple LDAP servers
that your GitLab instance will connect to.
To add another LDAP server, you can start by duplicating the settings under
[the main configuration](ldap.md#configuration) and edit them to match the
additional LDAP server.
To add another LDAP server:
1. Duplicating the settings under [the main configuration](ldap.md#configuration).
1. Edit them to match the additional LDAP server.
Be sure to choose a different provider ID made of letters a-z and numbers 0-9.
This ID will be stored in the database so that GitLab can remember which LDAP
@ -47,19 +37,19 @@ users against LDAP.
The process will execute the following access checks:
1. Ensure the user is still present in LDAP
1. If the LDAP server is Active Directory, ensure the user is active (not
blocked/disabled state). This will only be checked if
`active_directory: true` is set in the LDAP configuration [^1]
- Ensure the user is still present in LDAP.
- If the LDAP server is Active Directory, ensure the user is active (not
blocked/disabled state). This will only be checked if
`active_directory: true` is set in the LDAP configuration. [^1]
The user will be set to `ldap_blocked` state in GitLab if the above conditions
fail. This means the user will not be able to login or push/pull code.
The process will also update the following user information:
1. Email address
1. If `sync_ssh_keys` is set, SSH public keys
1. If Kerberos is enabled, Kerberos identity
- Email address.
- If `sync_ssh_keys` is set, SSH public keys.
- If Kerberos is enabled, Kerberos identity.
NOTE: **Note:**
The LDAP sync process updates existing users while new users will
@ -72,9 +62,6 @@ first time GitLab will trigger a sync for groups the user should be a member of.
That way they don't need to wait for the hourly sync to be granted
access to their groups and projects.
In GitLab Premium, we can also add a GitLab group to sync with one or multiple LDAP groups or we can
also add a filter. The filter must comply with the syntax defined in [RFC 2254](https://tools.ietf.org/search/rfc2254).
A group sync process will run 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.
@ -120,13 +107,26 @@ following.
1. [Restart GitLab][restart] for the changes to take effect.
---
To take advantage of group sync, group owners or maintainers will need to create an
LDAP group link in their group **Settings > LDAP Groups** page. Multiple LDAP
groups and/or filters can be linked with a single GitLab group. When the link is
created, an access level/role is specified (Guest, Reporter, Developer, Maintainer,
or Owner).
LDAP group link in their group **Settings > LDAP Groups** page.
Multiple LDAP groups and [filters](#filters-premium-only) can be linked with
a single GitLab group. When the link is created, an access level/role is
specified (Guest, Reporter, Developer, Maintainer, or Owner).
### Filters **(PREMIUM ONLY)**
In GitLab Premium, you can add an LDAP user filter for group synchronization.
Filters allow for complex logic without creating a special LDAP group.
To sync GitLab group membership based on an LDAP filter:
1. Open the **LDAP Synchronization** page for the GitLab group.
1. Select **LDAP user filter** as the **Sync method**.
1. Enter an LDAP user filter in the **LDAP user filter** field.
The filter must comply with the
syntax defined in [RFC 2254](https://tools.ietf.org/search/rfc2254).
## Administrator sync
@ -190,10 +190,13 @@ group, as opposed to the full DN.
## 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. When enabled following happens:
to lock down user abilities to invite new members to a group.
1. Only administrator can manage memberships of any group including access levels.
1. Users are not allowed to share project with other groups or invite members to a project created in a group.
When enabled, the following applies:
- Only administrator can manage memberships of any group including access levels.
- Users are not allowed to share project with other groups or invite members to
a project created in a group.
## Adjusting LDAP user sync schedule
@ -333,10 +336,18 @@ administrative duties.
### Supported LDAP group types/attributes
GitLab supports LDAP groups that use member attributes `member`, `submember`,
`uniquemember`, `memberof` and `memberuid`. This means group sync supports, at
least, LDAP groups with object class `groupOfNames`, `posixGroup`, and
`groupOfUniqueName`. Other object classes should work fine as long as members
GitLab supports LDAP groups that use member attributes:
- `member`
- `submember`
- `uniquemember`
- `memberof`
- `memberuid`.
This means group sync supports, at least, LDAP groups with object class:
`groupOfNames`, `posixGroup`, and `groupOfUniqueName`.
Other object classes should work fine as long as members
are defined as one of the mentioned attributes. This also means GitLab supports
Microsoft Active Directory, Apple Open Directory, Open LDAP, and 389 Server.
Other LDAP servers should work, too.
@ -344,11 +355,12 @@ Other LDAP servers should work, too.
Active Directory also supports nested groups. Group sync will recursively
resolve membership if `active_directory: true` is set in the configuration file.
> **Note:** Nested group membership will only be resolved if the nested group
also falls within the configured `group_base`. For example, if GitLab sees a
nested group with DN `cn=nested_group,ou=special_groups,dc=example,dc=com` but
the configured `group_base` is `ou=groups,dc=example,dc=com`, `cn=nested_group`
will be ignored.
NOTE: **Note:**
Nested group membership will only be resolved if the nested group
also falls within the configured `group_base`. For example, if GitLab sees a
nested group with DN `cn=nested_group,ou=special_groups,dc=example,dc=com` but
the configured `group_base` is `ou=groups,dc=example,dc=com`, `cn=nested_group`
will be ignored.
### Queries
@ -403,7 +415,7 @@ main: # 'main' is the GitLab 'provider ID' of this LDAP server
[^1]: 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. See https://ctogonewild.com/2009/09/03/bitmask-searches-in-ldap/
has bit 2 set. See <https://ctogonewild.com/2009/09/03/bitmask-searches-in-ldap/>
for more information.
### User DN has changed
@ -423,10 +435,10 @@ things to check to debug the situation.
- Ensure LDAP configuration has a `group_base` specified. This configuration is
required for group sync to work properly.
- Ensure the correct LDAP group link is added to the GitLab group. Check group
links by visiting the GitLab group, then **Settings dropdown -> LDAP groups**.
- Check that the user has an LDAP identity
links by visiting the GitLab group, then **Settings dropdown > LDAP groups**.
- Check that the user has an LDAP identity:
1. Sign in to GitLab as an administrator user.
1. Navigate to **Admin area -> Users**.
1. Navigate to **Admin area > Users**.
1. Search for the user
1. Open the user, by clicking on their name. Do not click 'Edit'.
1. Navigate to the **Identities** tab. There should be an LDAP identity with
@ -437,7 +449,7 @@ Often, the best way to learn more about why group sync is behaving a certain
way is to enable debug logging. There is verbose output that details every
step of the sync.
1. Start a Rails console
1. Start a Rails console:
```bash
# For Omnibus installations
@ -446,6 +458,7 @@ step of the sync.
# For installations from source
sudo -u git -H bundle exec rails console production
```
1. Set the log level to debug (only for this session):
```ruby
@ -540,8 +553,9 @@ and more DNs may be added, or existing entries modified, based on additional
LDAP group lookups. The very last occurrence of this entry should indicate
exactly which users GitLab believes should be added to the group.
> **Note:** 10 is 'Guest', 20 is 'Reporter', 30 is 'Developer', 40 is 'Maintainer'
and 50 is 'Owner'
NOTE: **Note:**
10 is 'Guest', 20 is 'Reporter', 30 is 'Developer', 40 is 'Maintainer'
and 50 is 'Owner'.
```bash
Resolved 'my_group' group member access: {"uid=john0,ou=people,dc=example,dc=com"=>30,

50
doc/administration/auth/ldap.md
View file

@ -7,16 +7,29 @@ type: reference
# LDAP
GitLab integrates with LDAP to support user authentication.
This integration works with most LDAP-compliant directory
servers, including Microsoft Active Directory, Apple Open Directory, Open LDAP,
and 389 Server. GitLab Enterprise Editions include enhanced integration,
This integration works with most LDAP-compliant directory servers, including:
- Microsoft Active Directory
- Apple Open Directory
- Open LDAP
- 389 Server.
GitLab Enterprise Editions (EE) include enhanced integration,
including group membership syncing as well as multiple LDAP servers support.
## GitLab EE
For more details about EE-specific LDAP features, see the
[LDAP Enterprise Edition documentation](ldap-ee.md).
The information on this page is relevant for both GitLab CE and EE. For more
details about EE-specific LDAP features, see the
[LDAP Enterprise Edition documentation](ldap-ee.md). **(STARTER ONLY)**
NOTE: **Note:**
The information on this page is relevant for both GitLab CE and EE.
## Overview
[LDAP](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol)
stands for **Lightweight Directory Access Protocol**, which is a standard
application protocol for accessing and maintaining distributed directory
information services over an Internet Protocol (IP) network.
## Security
@ -64,9 +77,12 @@ NOTE: **Note**:
In GitLab Enterprise Edition Starter, you can configure multiple LDAP servers
to connect to one GitLab server.
For a complete guide on configuring LDAP with GitLab Community Edition, please check
the admin guide [How to configure LDAP with GitLab CE](how_to_configure_ldap_gitlab_ce/index.md).
For GitLab Enterprise Editions, see also [How to configure LDAP with GitLab EE](how_to_configure_ldap_gitlab_ee/index.md). **(STARTER ONLY)**
For a complete guide on configuring LDAP with:
- GitLab Community Edition, see
[How to configure LDAP with GitLab CE](how_to_configure_ldap_gitlab_ce/index.md).
- Enterprise Editions, see
[How to configure LDAP with GitLab EE](how_to_configure_ldap_gitlab_ee/index.md). **(STARTER ONLY)**
To enable LDAP integration you need to add your LDAP server settings in
`/etc/gitlab/gitlab.rb` or `/home/git/gitlab/config/gitlab.yml` for Omnibus
@ -384,7 +400,7 @@ production:
Tip: If you want to limit access to the nested members of an Active Directory
group, you can use the following syntax:
```
```text
(memberOf:1.2.840.113556.1.4.1941:=CN=My Group,DC=Example,DC=com)
```
@ -402,13 +418,13 @@ The `user_filter` DN can contain special characters. For example:
- A comma:
```
```text
OU=GitLab, Inc,DC=gitlab,DC=com
```
- Open and close brackets:
```
```text
OU=Gitlab (Inc),DC=gitlab,DC=com
```
@ -417,13 +433,13 @@ The `user_filter` DN can contain special characters. For example:
- Escape commas with `\2C`. For example:
```
```text
OU=GitLab\2C Inc,DC=gitlab,DC=com
```
- Escape open and close brackets with `\28` and `\29`, respectively. For example:
```
```text
OU=Gitlab \28Inc\29,DC=gitlab,DC=com
```
@ -507,11 +523,11 @@ timeout), the login is rejected and a message will be logged to
### Debug LDAP user filter with ldapsearch
This example uses ldapsearch and assumes you are using ActiveDirectory. The
This example uses `ldapsearch` and assumes you are using ActiveDirectory. The
following query returns the login names of the users that will be allowed to
log in to GitLab if you configure your own user_filter.
```
```sh
ldapsearch -H ldaps://$host:$port -D "$bind_dn" -y bind_dn_password.txt -b "$base" "$user_filter" sAMAccountName
```