Este grupo especializado pasados ciertos días de trabajo y recopilación de de información, hemos dado con la respuesta, deseamos que resulte útil para ti en tu plan.
Solución:
No lo he probado todavía, pero por las cosas que he creado hasta ahora para la autenticación contra LDAP y la información del archivo de configuración, esta cuenta de usuario parece ser necesaria solo cuando su LDAP no admite la búsqueda y el enlace anónimos.
Entonces dejaría las dos entradas bind_dn y password comentado y prueba si funciona o no.
ACTUALIZAR
Implementé LDAP-Autehntication en Gitlab y es bastante fácil.
En el gitlab.yml-archivo hay una sección llamada ldap.
Allí debe proporcionar la información para conectarse a su LDAP. Parece que se deben proporcionar todos los campos, ¡parece que no hay un valor predeterminado de respaldo! Si desea utilizar un enlace anónimo para la recuperación del DN de los usuarios, proporcione un string por bind_dn y password. ¡Comentarlos parece no funcionar! Al menos recibí un mensaje de error 501.
Se puede encontrar más información en https://github.com/patthoyts/gitlabhq/wiki/Setting-up-ldap-auth y (más desactualizado pero aún útil) https://github.com/intridea/omniauth-ldap
He parcheado gitlab para que funcione de esta manera y documenté el proceso en https://foivos.zakkak.net/tutorials/gitlab_ldap_auth_without_querying_account/
Copio descaradamente las instrucciones aquí para completarlo.
Nota: Este tutorial se probó por última vez con gitlab 8.2 instalado desde la fuente.
Este tutorial tiene como objetivo describir cómo modificar una instalación de Gitlab para usar las credenciales de los usuarios para autenticarse con el servidor LDAP. Por defecto, Gitlab se basa en un enlace anónimo o un especial preguntando usuario para preguntar al servidor LDAP sobre la existencia de un usuario antes de autenticarlo con sus propias credenciales. Sin embargo, por razones de seguridad, muchos administradores deshabilitan el enlace anónimo y prohíben la creación de preguntando Usuarios de LDAP.
En este tutorial asumimos que tenemos una configuración de gitlab en gitlab.example.com y un servidor LDAP que se ejecuta en ldap.example.com, y los usuarios tienen un DN de la siguiente forma:
CN=username,OU=Users,OU=division,OU=department,DC=example,DC=com.
Parcheo
Para que Gitlab funcione en tales casos, necesitamos modificar parcialmente su mecanismo de autenticación con respecto a LDAP.
Primero, reemplazamos el módulo omniauth-ldap con esta derivación. Para conseguirlo aplicamos el siguiente parche a gitlab/Gemfile:
diff --git a/Gemfile b/Gemfile
index 1171eeb..f25bc60 100644
--- a/Gemfile
+++ b/Gemfile
@@ -44,4 +44,5 @@ gem 'gitlab-grack', '~> 2.0.2', require: 'grack'
# LDAP Auth
# GitLab fork with several improvements to original library. For full list of changes
# see https://github.com/intridea/omniauth-ldap/compare/master...gitlabhq:master
-gem 'gitlab_omniauth-ldap', '1.2.1', require: "omniauth-ldap"
+#gem 'gitlab_omniauth-ldap', '1.2.1', require: "omniauth-ldap"
+gem 'gitlab_omniauth-ldap', :git => 'https://github.com/zakkak/omniauth-ldap.git', require: 'net-ldap', require: "omniauth-ldap"
Ahora, debemos realizar las siguientes acciones:
sudo -u git -H bundle install --without development test mysql --path vendor/bundle --no-deploymentsudo -u git -H bundle install --deployment --without development test mysql aws
Estos comandos buscarán el módulo omniauth-ldap modificado en
gitlab/vendor/bundle/ruby/2.x.x/bundler/gems. Ahora que se obtiene el módulo, debemos modificarlo para usar el DN que espera nuestro servidor LDAP. Logramos esto parcheando lib/omniauth/strategies/ldap.rb en
gitlab/vendor/bundle/ruby/2.x.x/bundler/gems/omniauth-ldap con:
diff --git a/lib/omniauth/strategies/ldap.rb b/lib/omniauth/strategies/ldap.rb
index 9ea62b4..da5e648 100644
--- a/lib/omniauth/strategies/ldap.rb
+++ b/lib/omniauth/strategies/ldap.rb
@@ -39,7 +39,7 @@ module OmniAuth
return fail!(:missing_credentials) if missing_credentials?
# The HACK! FIXME: do it in a more generic/configurable way
- @options[:bind_dn] = "CN=#request['username'],OU=Test,DC=my,DC=example,DC=com"
+ @options[:bind_dn] = "CN=#request['username'],OU=Users,OU=division,OU=department,DC=example,DC=com"
@options[:password] = request['password']
@adaptor = OmniAuth::LDAP::Adaptor.new @options
Con este módulo, gitlab usa las credenciales del usuario para vincularse al servidor LDAP y consultarlo, así como para autenticar al usuario.
Sin embargo, esto solo funcionará mientras los usuarios no utilicen ssh-keys para autenticarse con Gitlab. Al autenticarse a través de un ssh-key, de forma predeterminada, Gitlab consulta al servidor LDAP para averiguar si el usuario correspondiente es (todavía) un usuario válido o no. En este punto, no podemos usar las credenciales del usuario para consultar el servidor LDAP, ya que el usuario no nos las proporcionó. Como resultado, deshabilitamos este mecanismo, esencialmente permitiendo a los usuarios con ssh-keys pero eliminado del servidor LDAP para seguir usando nuestra configuración de Gitlab. Para evitar que dichos usuarios puedan seguir usando su configuración de Gitlab, tendrá que eliminar manualmente su ssh-keys desde cualquier cuenta en su configuración.
Para deshabilitar este mecanismo, parcheamos gitlab/lib/gitlab/ldap/access.rb
con:
diff --git a/lib/gitlab/ldap/access.rb b/lib/gitlab/ldap/access.rb
index 16ff03c..9ebaeb6 100644
--- a/lib/gitlab/ldap/access.rb
+++ b/lib/gitlab/ldap/access.rb
@@ -14,15 +14,16 @@ module Gitlab
end
def self.allowed?(user)
- self.open(user) do |access|
- if access.allowed?
- user.last_credential_check_at = Time.now
- user.save
- true
- else
- false
- end
- end
+ true
+ # self.open(user) do |access|
+ # if access.allowed?
+ # user.last_credential_check_at = Time.now
+ # user.save
+ # true
+ # else
+ # false
+ # end
+ # end
end
def initialize(user, adapter=nil)
@@ -32,20 +33,21 @@ module Gitlab
end
def allowed?
- if Gitlab::LDAP::Person.find_by_dn(user.ldap_identity.extern_uid, adapter)
- return true unless ldap_config.active_directory
+ true
+ # if Gitlab::LDAP::Person.find_by_dn(user.ldap_identity.extern_uid, adapter)
+ # return true unless ldap_config.active_directory
- # Block user in GitLab if he/she was blocked in AD
- if Gitlab::LDAP::Person.disabled_via_active_directory?(user.ldap_identity.extern_uid, adapter)
- user.block unless user.blocked?
- false
- else
- user.activate if user.blocked? && !ldap_config.block_auto_created_users
- true
- end
- else
- false
- end
+ # # Block user in GitLab if he/she was blocked in AD
+ # if Gitlab::LDAP::Person.disabled_via_active_directory?(user.ldap_identity.extern_uid, adapter)
+ # user.block unless user.blocked?
+ # false
+ # else
+ # user.activate if user.blocked? && !ldap_config.block_auto_created_users
+ # true
+ # end
+ # else
+ # false
+ # end
rescue
false
end
Configuración
En gitlab.yml use algo como lo siguiente (modifíquelo según sus necesidades):
#
# 2. Auth settings
# ==========================
## LDAP settings
# You can inspect a sample of the LDAP users with login access by running:
# bundle exec rake gitlab:ldap:check RAILS_ENV=production
ldap:
enabled: true
servers:
##########################################################################
#
# Since GitLab 7.4, LDAP servers get ID's (below the ID is 'main'). GitLab
# Enterprise Edition now supports connecting to multiple LDAP servers.
#
# If you are updating from the old (pre-7.4) syntax, you MUST give your
# old server the ID 'main'.
#
##########################################################################
main: # 'main' is the GitLab 'provider ID' of this LDAP server
## label
#
# A human-friendly name for your LDAP server. It is OK to change the label later,
# for instance if you find out it is too large to fit on the web page.
#
# Example: 'Paris' or 'Acme, Ltd.'
label: 'LDAP_EXAMPLE_COM'
host: ldap.example.com
port: 636
uid: 'sAMAccountName'
method: 'ssl' # "tls" or "ssl" or "plain"
bind_dn: ''
password: ''
# This setting specifies if LDAP server is Active Directory LDAP server.
# For non AD servers it skips the AD specific queries.
# If your LDAP server is not AD, set this to false.
active_directory: true
# If allow_username_or_email_login is enabled, GitLab will ignore everything
# after the first '@' in the LDAP username submitted by the user on login.
#
# Example:
# - the user enters '[email protected]' and '[email protected]' as LDAP credentials;
# - GitLab queries the LDAP server with 'jane.doe' and '[email protected]'.
#
# If you are using "uid: 'userPrincipalName'" on ActiveDirectory you need to
# disable this setting, because the userPrincipalName contains an '@'.
allow_username_or_email_login: false
# To maintain tight control over the number of active users on your GitLab installation,
# enable this setting to keep new users blocked until they have been cleared by the admin
# (default: false).
block_auto_created_users: false
# Base where we can search for users
#
# Ex. ou=People,dc=gitlab,dc=example
#
base: 'OU=Users,OU=division,OU=department,DC=example,DC=com'
# Filter LDAP users
#
# Format: RFC 4515 http://tools.ietf.org/search/rfc4515
# Ex. (employeeType=developer)
#
# Note: GitLab does not support omniauth-ldap's custom filter syntax.
#
user_filter: '(&(objectclass=user)(objectclass=person))'
Usos de GitLab omniauth para administrar múltiples fuentes de inicio de sesión (incluido LDAP).
Entonces, si de alguna manera puedes extender omniauth Para administrar la conexión LDAP de manera diferente, puede obtener la contraseña de una fuente diferente.
Eso le permitiría evitar mantener dicha contraseña en la sección ldap del gitlab.yml archivo de configuración.