Jak mogę przełączyć istniejący zestaw repozytoriów Subversion, aby korzystać z ActiveDirectory? (svnserve / windows)

Mam zestaw prywatnych repozytoriów Subversion na komputerze z systemem Windows Server 2003, do którego programiści uzyskują dostęp za pośrednictwem SVNServe za pośrednictwem protokołu svn: //. Obecnie używamy plików authz i passwd dla każdego repozytorium do kontrolowania dostępu, jednak wraz z rosnącą liczbą repozytoriów i programistów rozważam przejście na używanie ich poświadczeń z ActiveDirectory. Działamy w sklepie Microsoft i używamy IIS zamiast Apache na wszystkich naszych serwerach internetowych, więc wolę nadal używać SVNServe, jeśli to możliwe.

Oprócz tego jestem również zaniepokojony tym, jak migrować nasze repozytoria, aby historia istniejących użytkowników była mapowana na prawidłowe konta ActiveDirectory. Pamiętaj również, że nie jestem administratorem sieci i nie znam się dobrze z ActiveDirectory, więc prawdopodobnie będę musiał przejść przez inne osoby, aby w razie potrzeby wprowadzić zmiany w ActiveDirectory.

Jakie są moje opcje?

AKTUALIZACJA 1: Z dokumentacji SVN wynika, że korzystając z SASL powinienem mieć możliwość uwierzytelnienia SVNServe za pomocą ActiveDirectory. Aby wyjaśnić, odpowiedź, której szukam, brzmi: jak skonfigurować SVNServe (jeśli to możliwe) do używania ActiveDirectory do uwierzytelniania, a następnie jak zmodyfikować istniejące repozytorium, aby ponownie przypisać istniejących użytkowników svn do ich kont logowania do domeny ActiveDirectory.

AKTUALIZACJA 2: Wygląda na to, że obsługa SASL w SVNServe działa na podstawie modelu wtyczki, a dokumentacja pokazuje tylko jako przykład. Patrząc na bibliotekę Cyrus SASL wygląda na to, że obsługiwanych jest wiele „mechanizmów” uwierzytelniania, ale nie jestem pewien, który z nich będzie używany do obsługi ActiveDirectory, ani nie mogę znaleźć żadnej dokumentacji dotyczącej takich kwestii.

AKTUALIZACJA 3: Ok, wygląda na to, że do komunikacji z ActiveDirectory chcę użyć saslauthd zamiast sasldb dla właściwości auxprop_plugin . Niestety wydaje się, że według niektórych postów (być może przestarzałych i niedokładnych) saslauthd nie opiera się na systemie Windows i takie starania są uważane za prace w toku .

AKTUALIZACJA 4: Ostatni post, który znalazłem na ten temat, brzmi tak, jakby odpowiednie pliki binarne () były dostępne za pośrednictwem biblioteki Kerberos MIT, ale wygląda na to, że autor tego postu na Nabble.com nadal ma problemy z działaniem .

AKTUALIZACJA 5: Wygląda jak z dyskusji TortoiseSVN, a także z tego postu na svn.haxx.seże nawet jeśli saslgssapi.dll lub inne niezbędne pliki binarne są dostępne i skonfigurowane na serwerze Windows, klienci również będą potrzebować tego samego dostosowania w celu pracy z tymi repozytoriami. Jeśli to prawda, będziemy mogli uzyskać wsparcie ActiveDirectory z klienta Windows tylko wtedy, gdy zostaną wprowadzone zmiany w tych klientach, takich jak TortoiseSVN i kompilacja plików binarnych klienta CollabNet w celu obsługi takich schematów uwierzytelniania. Chociaż takie są sugestie tych postów, jest to sprzeczne z tym, co pierwotnie zakładałem na podstawie innych odczytów, że zgodność z SASL nie powinna wymagać żadnych zmian na kliencie, a jedynie skonfigurowanie serwera do obsługi mechanizmu uwierzytelniania. Po dokładniejszym przeczytaniu dokumentu o Cyrus SASL w Subversionsekcja 5 stwierdza: „Klienci 1.5+ z obsługą Cyrus SASL będą mogli uwierzytelniać się na serwerach 1.5+ z włączoną obsługą SASL, pod warunkiem, że klient obsługuje co najmniej jeden z mechanizmów obsługiwanych przez serwer”. Tak więc obsługa GSSAPI (która, jak rozumiem, jest wymagana dla Active Directory), musi być dostępna na kliencie i serwerze.

Muszę powiedzieć, że dowiaduję się o wiele za dużo o tym, jak Subversion obsługuje uwierzytelnianie, niż kiedykolwiek chciałem. I niestety po prostu szukałem odpowiedzi na pytanie, czy mogę mieć obsługę uwierzytelniania Active Directory podczas używania SVNServe na serwerze Windows i uzyskiwania dostępu do tego z klientów Windows. Według oficjalnej dokumentacji wydaje się, że jest to możliwe, jednak można zauważyć, że konfiguracja nie jest trywialna, jeśli w ogóle możliwa.

AKTUALIZACJA: 6: Ponieważ prace nad Subversion 1.7 się kończą, czy ktoś mógłby dodać coś o tym, czy Subversion 1.7 poprawi się po uzyskaniu uwierzytelnienia SVNServe przy użyciu Active Directory?

Jak już wspomniano, VisualSVN Server to narzędzie, którego potrzebujesz. Jest to pakiet „wszystko w jednym” dla systemu Windows, który akurat używa w nim Apache - nigdy byś się nie dowiedział, chyba że poszedłbyś szukać w instalowanych przez siebie bibliotekach DLL, dla wszystkich jest to usługa systemu Windows z przystawką mmc do podaj to. Możesz zmienić port, na którym działa, jeśli już masz zajęty port 80.

Rozumiem, że obecnie obsługiwane jest wsparcie Sasl przez svnserve.

Używam apache z svn działającym na systemie Debian Linux autoryzującym serwer Active Directory. klienci łączą się z repozytorium za pomocą protokołu HTTP. jeśli ta konfiguracja jest dla Ciebie do zaakceptowania - kontynuuj czytanie.

powinno to również działać pod apache dla Windows, ale nigdy tego nie próbowałem. to, co następuje, jest specyficzne dla Debiana, ale powinno działać podobnie w systemie Windows / innych dystrybucjach; nie stracisz historii svn podczas migracji ...

zainstaluj wymagane oprogramowanie:

apt-get install libapache2-svn subversion apache2

w konfiguracji dla vhosta Apache [dowiązania do nich można znaleźć w / etc / apache2 / sites-enabled]. wewnątrz VirtualHost dodaj:

<Location /svn>
        DAV svn
        #change this to actual path
        SVNPath /full/path/to/your/current/svn/directory

        AuthType Basic
        AuthName "SVN Server"
        AuthBasicProvider ldap
        AuthzLDAPAuthoritative Off

        # provide here credentials for existing domain user. 
        # in my case domain is called domainName and user - user
        AuthLDAPBindDN "domainName\user"
        AuthLDAPBindPassword usersPassword
        # put here ip of the domain controler and full path to OU containing accounts
        AuthLDAPURL ldap://10.11.22.33:389/ou=Users,dc=domainName,dc=companyName,dc=whatever?sAMAccountName?sub?(objectClass=*)
        Require valid-user
        SVNAutoversioning on

        AuthzSVNAccessFile /etc/apache2/svn_authz
</Location>

upewnij się, że apache ładuje moduł ldap:

cd /etc/apache2/mods-enabled
ln -s ../mods-available/authnz_ldap.load
ln -s ../mods-available/ldap.load
/etc/init.d/apache2 reload

upewnij się, że apache może modyfikować pliki w repozytorium svn:

chown www-data:www-data -R /full/path/to/your/current/svn/directory

twój svn_authz powinien zawierać reguły informujące, kto może uzyskać dostęp do czego. w moim przypadku:

[groups]
ops=jack.brown,john.smith

[/]
* = rw

[/priv]
* =
@ops = rw

Więcej informacji o składni tego pliku można znaleźć tutaj .

jeśli doszedłeś tak daleko - użytkownicy mogą sprawdzić z http: //server.address/svn/ za pomocą dowolnego klienta svn [tortoise / cmdline / visual svn], zobaczą całą historię i będą kontynuować czytanie / pisanie do niej.

Możesz użyć saslNTML zamiast GSSAPI. Biblioteka dll saslNTML jest domyślnie instalowana z TSVN i myślę, że jest również zawarta w kliencie svn z collab.net.

w pliku konfiguracyjnym sasl musisz ustawić dwie opcje :

ntml_server

i opcjonalnie

ntml_v2

i oczywiście musisz ustawić listę mechów w pliku konfiguracyjnym, aby zawierała NTML.

Próbowałem tego tylko raz z TSVN, kiedy wszystko zaimplementowałem. Ale miałem kogoś innego, który skonfigurował dla mnie serwer testowy, więc nie mam pojęcia, jakie są dokładne opcje konfiguracji.