Autenticación de Active Directory de GitLab: sin resultados ni autenticación

8

Estoy tratando de configurar la autenticación LDAP con GitLab (versión 7.12.2 instalada en Ubuntu 14.04 amd64 en una VM, configuración Omnibus). He editado mi archivo gitlab.rb para que se vea así:

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: '********'
   port: 389
   uid: 'sAMAccountName'
   method: 'plain' # "tls" or "ssl" or "plain"
   bind_dn: 'CN=********,OU=********,OU=********,DC=********,DC=***'
   password: '********'
   active_directory: true
   allow_username_or_email_login: false
   block_auto_created_users: false
   base: 'DC=********,DC=***'
   user_filter: ''
EOS

Esto da como resultado el temido "No se pudo autorizar desde Ldapmain porque" Credenciales no válidas "". error. He intentado, para el nombre de usuario (en la variable bind_dn): "[email protected]" (correo electrónico basado en nombre de usuario), "John Smith" (nombre completo) y "johnsmith" (nombre de usuario). Los resultados son siempre los mismos. Mi contraseña tiene un signo @. No estoy seguro si necesito escapar, o cómo.

Los registros muestran esto:

Started POST "/users/auth/ldapmain/callback" for 127.0.0.1 at 2015-07-22 17:15:01 -0400
Processing by OmniauthCallbacksController#failure as HTML
  Parameters: {"utf8"=>"✓", "authenticity_token"=>"[FILTERED]", "username"=>"********", "password"=>"[FILTERED]"}
Redirected to http://192.168.56.102/users/sign_in
Completed 302 Found in 14ms (ActiveRecord: 3.6ms)
Started GET "/users/sign_in" for 127.0.0.1 at 2015-07-22 17:15:01 -0400
Processing by SessionsController#new as HTML
Completed 200 OK in 20ms (Views: 8.3ms | ActiveRecord: 2.9ms)

Y gitlab-rake gitlab:ldap:checkmuestra esto:

Checking LDAP ...

LDAP users with access to your GitLab server (only showing the first 100 results)
Server: ldapmain

Checking LDAP ... Finished

Sin embargo, cuando uso ldapsearch de Ubuntu VM (tan mismo entorno), obtengo muchos resultados:

ldapsearch -x -h ******** -D "********@********.***" -W -b "OU=********,OU=********,DC=********,DC=***" -s sub "(cn=*)" cn mail sn dn

Curiosamente, los DN en los resultados se ven así:

dn: CN=John Smith,OU=********,OU=********,OU=********,DC=********,DC=***

Es decir, hay una unidad organizativa adicional allí. También veo que el comando ldapsearch tiene -s sub, lo que creo que significa buscar subgrupos. No estoy muy familiarizado con los entresijos de LDAP o Active Directory.

Así que creo que me falta algo en mi base, pero no estoy seguro de qué. También puede ser un problema con el filtro de usuario. Hice el Google requerido, lo que me llevó hasta aquí, pero ahora no tengo ideas ni soluciones.

siride
fuente
1
Su entrada para baseparece un poco corta. ¿Qué sucede cuando coloca la ruta completa de su resultado de ldapsearch allí (incluidas todas las unidades organizativas)?
etagenklo
@etagenklo: tienes razón. Hice algunos otros cambios y pude hacer que funcionara. Publicaré como respuesta para la posteridad.
siride
esta respuesta puede ser útil: stackoverflow.com/a/54462889/6290553
Raktim Biswas el

Respuestas:

11

Pude resolver esto después de muchos intentos diferentes. Algunas notas

  • Asegúrese de que todas las líneas, excepto la primera, tengan un espacio único para la sangría. La primera línea es la que dice "main:" y que no tiene sangría en absoluto.
  • Bind_dn no es la ruta LDAP completa para el usuario de enlace, sino solo el nombre de usuario. En mi caso es "[email protected]".
  • La base debe ser el grupo de Active Directory o DN o como se llame que contenga a todos los usuarios.

Aquí está el YAML final:

main: # 'main' is the GitLab 'provider ID' of this LDAP server
 label: 'Active Directory'
 host: 'ad-server.example.com'
 port: 389
 uid: 'sAMAccountName'
 method: 'plain' # "tls" or "ssl" or "plain"
 bind_dn: '[email protected]'
 password: 'password'
 active_directory: true
 allow_username_or_email_login: false
 block_auto_created_users: false
 base: 'OU=ABC,OU=XYZ,DC=example,DC=com'
 user_filter: ''
siride
fuente
1
tanto +1! ¡Esta es la única solución en toda la red de stackexchange que funcionaba para mí!
Noir