2013-03-10 18 views
8

Chcę skonfigurować Gitlab z LDAP naszej firmy jako demo. Ale niestety muszę podać hasło administratora w gitlab.yml, aby gitlab miał dostęp do usługi LDAP. Problem polega na tym, że administracja nie chce konfigurować innego konta tylko dla Gitlaba. Czy istnieje sposób na obejście tego bez konieczności wypełniania mojego hasła? Czy istnieje sposób, aby Gitlab ustanowił połączenie LDAP tylko z dostarczonymi danymi uwierzytelniającymi użytkownika?konfiguracja gitlab Uwierzytelnianie LDAP bez specjalnego użytkownika gitlab

Wszelkie pomysły oprócz logowania jako anonimowe?

Już opublikowane here.

Odpowiedz

9

Nie próbowałem tego jeszcze, ale z tego, co dotychczas zbudowałem, uwierzytelniając się przed LDAP i informacjami z pliku konfiguracyjnego, to konto użytkownika wydaje się być potrzebne tylko wtedy, gdy LDAP nie obsługuje anonimowego wiązania i wyszukiwanie.

Więc zostawiłbym dwa wpisy bind_dn i password skomentował i spróbuj, czy to działa, czy nie.

UPDATE

I zostały wdrożone LDAP Autehntication w Gitlab i to dość łatwe.

W pliku gitlab.yml znajduje się sekcja o nazwie ldap.

Tam musisz podać informacje, aby połączyć się z LDAP. Wygląda na to, że wszystkie pola muszą być podane, nie ma domyślnego ustawienia zastępczego! Jeśli chcesz użyć anonimowego powiązania do pobrania nazwy DN użytkownika, podaj ciąg pusty dla bind_dn i password. Komentowanie ich wydaje się nie działać! Przynajmniej dostałem komunikat o błędzie 501.

Więcej informacji można znaleźć na stronie https://github.com/patthoyts/gitlabhq/wiki/Setting-up-ldap-auth i (bardziej przestarzałe, ale nadal pomocny) https://github.com/intridea/omniauth-ldap

+0

To nie działa w mojej firmie, ponieważ nie ma ustawionych uprawnień do anonimowego wiązania ani wyszukiwania. Odtwarzanie z parametrami prowadzi tylko do komunikatów o błędach, ponieważ gitlab nie może się połączyć i dlatego nie może zweryfikować istnienia dostarczonego użytkownika (o ile wiem, że gitlab próbuje uzyskać pełny bind_dn w tym kroku programu). – Bubu

+0

Następnie będziesz potrzebować użytkownika, który ma uprawnienia do łączenia się z LDAP w celu wyszukania nazwy Bind-DN ​​użytkownika próbującego się zalogować. Nie ma możliwości obejścia, gdy wyszukiwanie anonimowe nie jest włączone. Przepraszam. – heiglandreas

+0

Ale dlaczego miałbym szukać Bind-DN, jeśli już to znam? Na przykład. użytkownik [email protected] chce się zalogować; Wiem, że Bind-DN ​​to coś w stylu "uid = [email protected], ou = ludzie, dc = example, dc = com" - Gitlab mógł to opcjonalnie wykorzystać, umożliwiając w ten sposób logowanie LDAP bez potrzeby początkowe wiązanie. Nie widzę, dlaczego nie jest to domyślna strategia uwierzytelniania LDAP. – Bubu

1

GitLab używa omniauth do zarządzania wieloma źródłami logowania (w tym LDAP).

Jeśli możesz w jakiś sposób rozszerzyć omniauth w celu zarządzania połączeniem LDAP w inny sposób, możesz pobrać hasło z innego źródła.
Pozwoliłoby to uniknąć trzymania wspomnianego hasła w numerze ldap section of the gitlab.yml config file.

+0

To był mój pierwszy pomysł, ale dokąd się udać? Nie przepadam za rubinem. Znalazłem [to] (https://gist.github.com/mgrobelin/3953472) - ponieważ wydaje się nie używać początkowego powiązania, wygląda na bardzo obiecujące. Czy masz inne wskazówki, gdzie kopać? – Bubu

+0

@Bubu Brak innych wskazówek w tej chwili. To, co znalazłeś, wydaje się być dobrym przykładem rozszerzenia omniauth, co właśnie sugeruję. – VonC

+0

Czy zdarzyło Ci się, że to działa? Próbuję zrobić to samo. – orodbhen

3

mam poprawione gitlab pracować w ten sposób i udokumentowany proces w http://foivos.zakkak.net/tutorials/gitlab_ldap_auth_without_querying_account.html

I bezczelnie skopiować z instrukcjami tutaj dla siebie -kompletność.

Uwaga: Ten samouczek został ostatnio przetestowany przy pomocy gitlab 8.2 zainstalowanego ze źródła.

Ten samouczek ma na celu opisać, jak zmodyfikować instalację Gitlab na , używając poświadczeń użytkowników do uwierzytelnienia na serwerze LDAP. Według domyślnie Gitlab polega na anonimowym wiązaniu lub specjalnym zapytaniu użytkownika , aby zapytać serwer LDAP o istnienie użytkownika przed uwierzytelnieniem jej przy użyciu własnych poświadczeń.Ze względów bezpieczeństwa, jednak wielu administratorów wyłącza anonimowe wiązanie i zabrania tworzenia specjalnych zapytań o użytkowników LDAP.

W tym poradniku zakładamy, że mamy konfigurację gitlab na gitlab.example.com i serwer LDAP działa na ldap.example.com i użytkownicy mają DN następującą postać: CN=username,OU=Users,OU=division,OU=department,DC=example,DC=com.

Łatanie

Aby Gitlab pracę w takich przypadkach musimy częściowo zmodyfikować swój mechanizm uwierzytelniania dotyczące LDAP.

Najpierw zamienimy moduł omniauth-ldap na pochodną this. Aby to osiągnąć możemy zastosować następującą poprawkę do 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" 

Teraz musimy wykonać następujące czynności:

  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

Polecenia te pobierze zmodyfikowany moduł omniauth-ldap w gitlab/vendor/bundle/ruby/2.x.x/bundler/gems. Teraz, gdy moduł jest pobierany , musimy go zmodyfikować, aby użyć nazwy wyróżniającej, której oczekuje nasz serwer LDAP. Osiągamy to poprzez łatanie lib/omniauth/strategies/ldap.rb w gitlab/vendor/bundle/ruby/2.x.x/bundler/gems/omniauth-ldap z:

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 

Z tego modułu, gitlab wykorzystuje poświadczenia użytkownika do wiązania się z serwerem LDAP i zapytać go, jak również w celu uwierzytelnienia użytkownika siebie.

To jednak działa tylko tak długo, jak użytkownicy nie używają kluczy SSH do uwierzytelniania z Gitlab. Podczas uwierzytelniania za pomocą klucza SSH przez domyślnie Gitlab wysyła zapytanie do serwera LDAP, aby dowiedzieć się, czy odpowiedni użytkownik (nadal) jest prawidłowym użytkownikiem, czy nie. W tym momencie możemy nie można użyć poświadczeń użytkownika do wysłania zapytania do serwera LDAP, ponieważ użytkownik nie dostarczył nam go. W rezultacie wyłączamy ten mechanizm, zasadniczo zezwalając użytkownikom z zarejestrowanymi kluczami ssh, ale usuniętym z serwera LDAP , aby nadal korzystać z naszej konfiguracji Gitlab. Aby uniemożliwić takim użytkownikom korzystanie z konfiguracji , należy nadal ręcznie usuwać klucze ssh z dowolnych kont w konfiguracji, ręcznie .

Aby wyłączyć ten mechanizm załatać gitlab/lib/gitlab/ldap/access.rb z:

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 

Konfiguracja

W gitlab.yml użyć coś jak poniżej (modyfikować do swoich potrzeb):

# 
# 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))'