Czy * ktokolwiek * ma uwierzytelnianie systemu Windows SVNServe dla AD/Kerberos za pośrednictwem interfejsu SASL/GSSAPI?

Question

Scenariusz: serwer Windows w domenie AD hostującej repozytorium Subversion przy użyciu tylko SVNSERVE (bez Apache) i nie VisualSVN.

Cel: Uwierzytelnianie użytkowników w repozytorium Subversion za pośrednictwem SASL za pośrednictwem GSSAPI do domeny systemu Windows za pośrednictwem protokołu Kerberos.

Częste wpisy w wielu witrynach wskazują użytkownikom często ślepy zaułek w tej konfiguracji z "Nie można uzyskać listy mechanizmów SASL". Nie widziałem żadnego przypadku, w którym to faktycznie działa. Czy ktoś ma to działa?

Zadaję to pytanie w wyniku opublikowania w 2011 roku na forum Gentoo, w którym ktoś w tym scenariuszu przejrzał odpowiednie paczki źródłowe i stwierdził, że chociaż w pewnym momencie taka konfiguracja prawdopodobnie zadziałała, potrzebne pliki ponieważ nie są już w źródle.

GEntoo forum discussion where poster claims svnserve+gssapi+sasl worked at one time, but no longer does.

Teraz nie dochodzić tego roszczenia do być dokładne, ale wiem, siedzę dokładnie w tym samym miejscu, a ja nie widziałem jeszcze żadnych postów, które twierdzą, „zwycięstwo” nad taką konfiguracją. Jeśli tak, proszę podać szczegóły!

Wielkie dzięki z góry.

Answer 1

Po otrzymaniu odznaki "tumbleweed" za to bez odpowiedzi pytanie i znaczące dodatkowe badania na własną rękę, doszedłem do wniosku, że temat kombinacji dla Subversion pod Windows jest w rzeczywistości niemożliwy pod bieżącym kodem baza. Uważam, że problemem jest tutaj warstwa uwierzytelniania SASL, z pewnym źródłem usuniętym lub znacząco zmienionym na "zerwanie", co, jak sądzę, działa w pewnym momencie.

Moje rozwiązanie polegało na dodaniu Apache do miksu za pomocą mod_auth_sspi, a chociaż spowalnia to trochę repozytorium, uwierzytelnianie działa idealnie. Wydaje się, że jest to "poprawka" wymagająca uwierzytelnienia.

Answer 2

Dokonałem uwierzytelnienia przeciwko AD przy użyciu SASL + LDAP, ale nie w interfejsie SASL + GSSAPI, oraz z małym zastrzeżeniem: muszę używać i uruchamiać svnserve z Cygwin w Windows.

1) Uzyskanie uwierzytelnionych użytkowników przez SASL + LDAP/AD w Linuksie było dość łatwe (wiem, że pytanie dotyczy svnserve w systemie Windows, ale należy do mnie). Ważną częścią do uzyskania uwierzytelnienia działającego w stosunku do LDAP/AD jest saslauthd i przetestowania uwierzytelnienia za pomocą testsaslauthd.

Korzystanie Ubuntu jako przykład:

1a) /etc/sasl2/svn.conf

pwcheck_method: saslauthd 
mech_list: PLAIN 

Mówi subversion/svnserve używać saslauthd zrobić uwierzytelniania w jego imieniu.

1b) /etc/saslauthd.conf

ldap_servers: ldap://yourADserver.dept.org 
ldap_search_base: DC=dept,DC=org 
ldap_bind_dn: cn=bindaccount,dc=dept,dc=org 
ldap_bind_pw: passwordOfbindaccount 

ldap_deref: never 
ldap_restart: yes 
ldap_scope: sub 
ldap_use_sasl: no 
ldap_start_tls: no 
ldap_version: 3 
ldap_auth_method: bind 
ldap_filter: sAMAccountName=%u 
ldap_password_attr: userPassword 
ldap_timeout: 10 
ldap_cache_ttl: 5 
ldap_cache_mem: 32768 

1c) Czy test poprzez testsaslauthd

testsaslauthd -u myusername -p mypassword 

1d) Jeśli się powiedzie, a następnie uruchomić saslauthd i zacznij svnserve. i użyj dowolnego klienta svn do przetestowania uwierzytelnienia.

2) Problem polega na tym, że nie ma natywnego portu systemu Cyrus dla systemu Windows i prawdopodobnie nigdy nim nie będzie. Odpowiedź polega na użyciu Cygwin, który ma svnserve, testsaslauthd i saslauthd.

Powtórz powyższe kroki .. ale lokalizacja pliku svn.conf może być inna.

Answer 3

Właśnie udało mi się (po blisko 30 godzinach drapania głowy, kompilacji i braku debugowania kodu źródłowego, aby uzyskać przyzwoite kody błędów), aby svnserve + SASL + GSSAPI działał! Moje ustawienia są następujące:

• Serwer AD to Samba 4.1.0 na Debianie 7.2 (zbudowany ze źródła).
• Serwer subversion to subversion w wersji 1.8.5 w systemie Solaris Express (SunOS 5.11 snv_151a i86pc i386 i86pc). Zbudowany dla x64 ze źródła przy użyciu natywnego (Sun) SASL.
• Klient jest systemem Windows 7 x64 z TortoiseSVN 1.8.2 (wersja binarna x64) i Heimdal 1.5.1 (pliki binarne x64 z bezpiecznych punktów końcowych).
• Jak z niczego udziałem Kerberos, trzeba mieć przodu i do tyłu DNS działa sprawnie, zsynchronizowane zegary itp

kroki na pole okna z creds domen:

• Tworzenie „svnserve "konto użytkownika (nie konto komputera) dla serwera Subversion.
• Uruchom "ktpass -princ svn/server.domain.local@DOMAIN.LOCAL -mapuser DOMAIN.LOCAL \ svnserve -crypto RC4-HMAC-NT -pass password -typ KRB5_NT_PRINCIPAL -out svnserve.keytab". Wykonaj , a nie, aby włączyć DES dla tego konta lub system Windows 7 odmówi uwierzytelnienia. Włączyłem go wcześniej (zgodnie z przepisami) i musiałem go wyłączyć, aby działało.

Kroki dla serwera Subversion:

• Konfigurowanie /etc/krb5/krb5.conf

  [libdefaults] 
      default_realm = DOMAIN.LOCAL 
  
  [realms] 
      DOMAIN.LOCAL = { 
       kdc = pdc.domain.local 
       admin_server = pdc.domain.local 
      } 
  
  [domain_realm] 
      .domain.local = DOMAIN.LOCAL 
      domain.local = DOMAIN.LOCAL 
  
  # Other defaults left as-is. 
  

• Konfigurowanie repo/conf/svnserve.conf:

  [general] 
  anon-access = none 
  authz-db = authz 
  realm = DOMAIN.LOCAL 
  
  [sasl] 
  use-sasl = true 
  min-encryption = 0 
  max-encryption = 256 
  

• Konfigurowanie repo/conf/authz: ​​

  [aliases] 
  
  [groups] 
  
  [/] 
  * = 
  # Still investigating whether access to the server can be controlled through an AD group. 
  # Below is for user@DOMAIN.LOCAL, the realm appears to get lost. 
  user = rw 
  

• Konfigurowanie /etc/sasl/svn.conf:

  mech_list: GSSAPI 
  

• Kropla svnserve.keytab się, by /etc/krb5/krb5.keytab (keytab w konfiguracji SASL nie wydaje się robić cokolwiek).

• Uruchom svnserve.

Kroki dla klienta:

• zainstalować TortoiseSVN i Heimdal.
• Edytuj plik C: \ ProgramData \ Kerberos \ krb5.conf, aby był jak /etc/krb5/krb5.conf na serwerze Subversion.Są tam inne domyślne ustawienia, które zostawiłem w spokoju.
• Dokonaj kasy, nie jest wymagane hasło!

Jednym z problemów związanych z tą konfiguracją jest to, że proces svnserve musi być w stanie odczytać /etc/krb5/krb5.keytab, więc uprawnienia do tego trzeba trochę zmienić. svnserve wchodzi do własnej strefy, więc nie jest to dla mnie problemem. Również miałem mslsa_cc.dll awarii podczas testowania rzeczy, ale nie widziałem żadnych awarii, gdy wszystko zostało uporządkowane.

Z niektórymi problemami, możesz być w stanie uzyskać to działając na svnserve również w systemie Windows. Spróbowałem MIT Kerberos na kliencie Windows, ale rozbił się przy starcie, więc zrezygnowałem. Możesz mieć więcej szczęścia.

Aktualizacja: Wykryliśmy problem z awarią - jest to błąd w mslsa_cc.dll (podobny do https://github.com/krb5/krb5/commit/7acb524f5aa00274771dbbfac19d2dd779aad409, który również powoduje, że jest on nieco błędny, ponieważ nOutStringLen musi zostać podzielone przez 2 w celu wywołania metody ANSIToUnicode). Binary łata na mslsa_cc.dll jest:

• offsetowy 0xB46: Zmiana z FF 15 04 69 00 do D1 EE 0F 1F 40.
• offsetowy 0xB5E: zmiana od 77 do EB.