impostazione dell'autenticazione LDAP gitlab senza utente gitlab speciale

Question

Desidero configurare Gitlab con l'LDAP della nostra azienda come demo. Ma sfortunatamente devo inserire una password di amministratore in gitlab.yml per fare in modo che gitlab acceda al servizio LDAP. Il problema in realtà è l'amministrazione, in quanto non vogliono impostare un altro account solo per Gitlab. C'è un modo per aggirare questo senza inserire la mia password? C'è un modo per far sì che Gitlab stabilisca la connessione LDAP con le sole credenziali utente fornite?

Qualche idea dopo l'accesso come anonimo?

Già pubblicato here.

Answer 1

Non l'ho ancora provato, ma dalle cose che ho creato fino ad ora l'autenticazione con LDAP e le informazioni dal file di configurazione questo account utente sembra essere necessario solo quando il vostro LDAP non supporta l'associazione anonima e alla ricerca.

Quindi vorrei lasciare le due voci bind_dn e password commentate e provare se funziona o meno.

UPDATE

Ho implementato LDAP-Autehntication in Gitlab ed è abbastanza facile.

Nel file gitlab.yml è presente una sezione denominata ldap.

Qui è necessario fornire le informazioni per connettersi al proprio LDAP. Sembra che tutti i campi debbano essere dati, non sembra esserci un default di fallback! Se si desidera utilizzare l'associazione anonima per il recupero degli utenti, DN fornisce una stringa vuota per bind_dn e password. Commentarli sembra non funzionare! Almeno ho ricevuto un messaggio di errore 501.

Maggiori informazioni sono disponibili all'indirizzo https://github.com/patthoyts/gitlabhq/wiki/Setting-up-ldap-auth e (più datata ma comunque utile) https://github.com/intridea/omniauth-ldap

Answer 2

GitLab utilizza omniauth per gestire più origini di accesso (incluso LDAP).

Quindi, se è possibile estendere in qualche modo omniauth per gestire la connessione LDAP in modo diverso, è possibile recuperare la password da un'altra fonte.
Ciò consentirebbe di evitare di mantenere detta password nel ldap section of the gitlab.yml config file.

Answer 3

ho patchato gitlab a lavorare in questo modo e documentato il processo in http://foivos.zakkak.net/tutorials/gitlab_ldap_auth_without_querying_account.html

ho spudoratamente copiare le istruzioni qui per l'auto -completezza.

Nota: questo tutorial è stato testato l'ultima volta con gitlab 8.2 installato dal sorgente.

Questo tutorial si propone di descrivere come modificare un'installazione Gitlab su utilizzando le credenziali dell'utente per l'autenticazione con il server LDAP. Con il valore predefinito Gitlab si basa sul binding anonimo o su uno speciale che richiede utente per chiedere al server LDAP l'esistenza di un utente prima di che l'autentica con le proprie credenziali.Tuttavia, per motivi di sicurezza, , molti amministratori disabilitano l'associazione anonima e vietano la creazione di speciali agli utenti di LDAP.

In questo tutorial si assume che abbiamo una configurazione gitlab a gitlab.example.com e un server LDAP in esecuzione su ldap.example.com, e gli utenti hanno un DN della forma seguente: CN=username,OU=Users,OU=division,OU=department,DC=example,DC=com.

Patching

Per far Gitlab lavoro in questi casi abbiamo bisogno di modificare in parte il suo meccanismo di autenticazione riguardo LDAP.

Innanzitutto, sostituiamo il modulo omniauth-ldap con la derivazione this. Per raggiungere questo applichiamo la seguente patch per 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" 

Ora, abbiamo bisogno di eseguire le seguenti azioni:

1. sudo -u git -H bundle install --without development test mysql --path vendor/bundle --no-deployment
2. sudo -u git -H bundle install --deployment --without development test mysql aws

Questi comandi preleveranno il modulo omniauth-ldap modificato in gitlab/vendor/bundle/ruby/2.x.x/bundler/gems. Ora che il modulo è scaricato, dobbiamo modificarlo per utilizzare il DN che il nostro server LDAP si aspetta. Abbiamo Realizziamo questo patch lib/omniauth/strategies/ldap.rb in 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 questo modulo, gitlab utilizza le credenziali dell'utente per collegarsi al server LDAP e interrogare esso, così come, per autenticare l'utente se stessa.

Questo tuttavia funzionerà solo fino a quando gli utenti non utilizzano i tasti ssh su autenticare con Gitlab. Quando si effettua l'autenticazione tramite una chiave ssh, tramite le query predefinite Gitlab interrogano il server LDAP per scoprire se l'utente corrispondente è (ancora) un utente valido o meno. A questo punto, non è possibile utilizzare le credenziali dell'utente per interrogare il server LDAP , poiché l'utente non ce li ha forniti. Di conseguenza disabilitiamo questo meccanismo, essenzialmente consentendo agli utenti con chiavi ssh-registrate ma rimossi dal server LDAP di utilizzare ancora la nostra installazione Gitlab. Per evitare che tali utenti di possano continuare a utilizzare l'installazione Gitlab, sarà necessario manualmente eliminare le proprie chiavi ssh da qualsiasi account nella configurazione.

Per disattivare questo meccanismo ci applichiamo nessuna patch 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 

configurazione

In gitlab.yml uso qualcosa di simile a quanto segue (modificare per le vostre esigenze):

# 
# 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 'jane.doe@example.com' and 'p@ssw0rd' as LDAP credentials; 
     # - GitLab queries the LDAP server with 'jane.doe' and 'p@ssw0rd'. 
     # 
     # 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))'