Come eseguire il debug dell'autenticazione LDAP Gitlab?

Question

Sto provando a configurare l'autenticazione LDAP con gitlab. La mia configurazione è someting come:

ldap: 
    enabled: true 
    host: 'ldap.example.com' 
    base: 'ou=People,o=example.com' 
    port: 636 
    uid: 'uid' 
    method: 'ssl' # "ssl" or "plain" 
    bind_dn: 'cn=gitlab,ou=Apps,o=example.com' 
    password: 'password' 
    allow_username_or_email_login: true 

ho provato con il seguente:

ldapsearch -b "ou=People,o=example.com" -s sub -D "cn=gitlab,ou=Apps,o=example.com" -H ldaps://ldap.example.com:636 -w "password" -x "(uid=myname@example.com)" 

La linea di cui sopra funziona, ma quando provo ad accedere utilizzando LDAP, ho sempre avuto "credenziali non valide".

Come posso risolvere questo problema e limitare la causa principale di questo problema?

Edit 26/09:

Ecco alcune cose che ho trovato su production.log:

Started GET "https://stackoverflow.com/users/sign_in" for 127.0.0.1 at 2013-09-23 17:42:58 -0300 
Processing by Devise::SessionsController#new as HTML 
    Rendered devise/sessions/_new_ldap.html.haml (1.7ms) 
    Rendered devise/sessions/_new_base.html.haml (1.8ms) 
    Rendered devise/sessions/_oauth_providers.html.haml (0.0ms) 
    Rendered devise/sessions/new.html.haml within layouts/devise (4.2ms) 
    Rendered layouts/_head.html.haml (1.6ms) 
    Rendered layouts/_flash.html.haml (0.1ms) 
Completed 200 OK in 9ms (Views: 6.9ms | ActiveRecord: 0.0ms) 
Started POST "https://stackoverflow.com/users/auth/ldap/callback" for 127.0.0.1 at 2013-09-23 17:43:00 -0300 
Processing by OmniauthCallbacksController#failure as HTML 
    Parameters: {"utf8"=>"â", "authenticity_token"=>"AwqZsVHRqOeZr+GLWWeGM7MyOAdk7cFl8/rZgbVRU+8=", "username"=>"name@example.com", "password"=>"[FILTERED]"} 
Redirected to http://example.com/users/sign_in 
Completed 302 Found in 3ms (ActiveRecord: 0.0ms) 
Started GET "https://stackoverflow.com/users/sign_in" for 127.0.0.1 at 2013-09-23 17:43:00 -0300 
Processing by Devise::SessionsController#new as HTML 
    Rendered devise/sessions/_new_base.html.haml (2.8ms) 
    Rendered devise/sessions/_oauth_providers.html.haml (0.1ms) 
    Rendered devise/sessions/new.html.haml within layouts/devise (3.7ms) 
    Rendered layouts/_head.html.haml (1.7ms) 
    Rendered layouts/_flash.html.haml (0.1ms) 
Completed 200 OK in 9ms (Views: 6.6ms | ActiveRecord: 0.0ms) 
Started GET "/" for 127.0.0.1 at 2013-09-23 18:50:08 -0300 
Processing by DashboardController#show as HTML 
Completed 401 Unauthorized in 1ms 

Edit: ho finalmente avuto la risposta: una configurazione su disposizione testamentaria è stata spogliando everyting dopo la "@ ". Non riesco a ricordare il nome esatto, ma posso postare non appena ho avuto accesso alla macchina. Ho scoperto questo aggiungendo i log al login oauth di ldap.

Answer 1

Il OP kidbombmentions:

Una configurazione a concepire era strippaggio tutto dopo il "@".
Ho scoperto questo aggiungendo i registri all'accesso ldap oauth.

---

Verificare se il server LDAP è accessibile attraverso ldap (non ldaps://) anche

ldapsearch -b "ou=People,o=example.com" -s sub -D "cn=gitlab,ou=Apps,o=example.com" -H ldap://ldap.example.com:389 -w "password" -x "(uid=myname@example.com)" 

Se sì, cercare di modificare il file gitlab.yml impostazione ldap.method da 'ssl' a "plain".

L'obiettivo è quello di convalidare se il certificato utilizzato per contattare il server LDAP è il problema qui o no.

Se è possibile contattare il server tramite ldap: // (senza certificato), ciò offre almeno una soluzione alternativa.

In caso contrario (è necessario passare attraverso ldaps://), è necessario studiare più in dettaglio il certificato associato al server LDAP.

openssl s_client -connect ldap.example.com:636 2>/dev/null < /dev/null 

(non sto usando -CAFile o -CAPath qui, assumendo la CA sono al loro posto di default di cui al /etc/ssl/openssl.cnf)

Se si arriva alla fine del l'output di quel comando il messaggio:

error:num=21:unable to verify the first certificate 

Ciò significa che è necessario ottenere il certificato dall'emittente.
Vedere "How To Verify SSL Certificate From A Shell Prompt".

Answer 2

Abbiamo gitlabs configurati con credenziali LDAP, ma ogni volta che qualcuno ha effettuato l'accesso, ricevevamo messaggi "500 Internal Server Error". Il problema sembrava andare via comunque quando abbiamo formattato correttamente /etc/gitlab/gitlab.rb. Sembra che ci siano diversi modi per formattare le variabili ldap, a seconda della versione di gitlabs che usi: 7.3.2.omnibus e master.

Answer 3

Vedo che hai trovato la soluzione per il tuo scenario, ma ho pensato di includere alcuni passaggi aggiuntivi per la risoluzione dei problemi per gli altri che si imbattono in problemi di autenticazione con GitLab & LDAP.

• Eseguire il controllo rake LDAP di GitLab per localizzare il problema. https://docs.gitlab.com/ce/administration/raketasks/ldap.html#check. Ce n'è anche uno più completo che è elencato nel documento di installazione di GitLab che stai utilizzando.
• Se si utilizza SELinux, impostarlo in modalità permissiva.
• Se si utilizza Apache con GitLab: Installare LDAP - Apache Directory Studio e provare a stabilire una connessione. Se non puoi, allora qualcosa è probabilmente sbagliato nel tuo file config.yml. Comincerei guardando la base .
• Eseguire tcpdump e importare il file .pcap in WireShark per l'insepzione.
• log recensione su server LDAP e il server GitLab