Autenticazione GitLab Active Directory: nessun risultato e nessuna autenticazione


8

Sto cercando di configurare l'autenticazione LDAP con GitLab (versione 7.12.2 installata su Ubuntu 14.04 amd64 su una macchina virtuale, configurazione Omnibus). Ho modificato il mio file gitlab.rb per assomigliare al seguente:

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

Ciò si traduce nel temuto "Impossibile autorizzarti da Ldapmain perché" Credenziali non valide "." errore. Ho provato, per il nome utente (nella variabile bind_dn): "johnsmith@example.com" (e-mail basato sul nome utente), "John Smith" (nome completo) e "johnsmith" (nome utente). I risultati sono sempre gli stessi. La mia password contiene un segno @. Non sono sicuro se devo scappare o come.

I registri mostrano questo:

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)

E gitlab-rake gitlab:ldap:checkmostra questo:

Checking LDAP ...

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

Checking LDAP ... Finished

Tuttavia, quando utilizzo ldapsearch dalla macchina virtuale Ubuntu (quindi lo stesso ambiente), ottengo un sacco di risultati:

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

Curiosamente, i DN nei risultati sembrano così:

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

Cioè, c'è un OU extra lì dentro. Vedo anche che il comando ldapsearch ha -s sub, che credo significhi cercare sottogruppi. Non ho familiarità con i dettagli di LDAP o Active Directory.

Quindi credo che mi manchi qualcosa nella mia base, ma non sono sicuro di cosa. Potrebbe anche essere un problema con il filtro utente. Ho fatto il googling necessario, che mi ha portato così lontano, ma ora sono senza idee e soluzioni.


1
La tua voce per basesembra un po 'breve. Cosa succede quando inserisci il percorso completo del risultato di ldapsearch (comprese tutte le unità organizzative)?
etagenklo,

@etagenklo: hai ragione. Ho apportato alcune altre modifiche e sono riuscito a farlo funzionare. Pubblicherò come risposta per i posteri.
siride,

questa risposta potrebbe essere utile: stackoverflow.com/a/54462889/6290553
Raktim Biswas

Risposte:


11

Sono stato in grado di risolverlo dopo molti tentativi diversi. Alcune note:

  • Assicurarsi che tutte le righe tranne la prima abbiano un unico spazio per il rientro. La prima riga è quella che dice "main:" e che non ha alcun rientro.
  • Bind_dn non è il percorso LDAP completo per l'utente bind, ma solo il nome utente. Nel mio caso è "xxx@example.com".
  • La base deve essere il gruppo o DN di Active Directory o qualunque cosa si chiami che contenga tutti gli utenti.

Ecco l'ultimo YAML:

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: 'user@example.com'
 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: ''

1
così tanto +1! Questa è l'unica soluzione su tutta la rete di stackexchange che funzionava per me!
Noir,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.