В данном howto показан один из вариантов интеграции Subversion и AD. К сожалению, сам по себе svnserve не поддерживает LDAP, поэтому придется использовать на стороне сервера Apache с модулем dav_svn, т.к. Apache поддерживает LDAP. Подробно описывать установку, настройку и вообще общие принципы Subversion не буду, будем считать, что на текущий момент он установлен. Установка проводится на примере GNU/Debian 7.0 и Windows Server 2012.

Ставим Apache и модуль для работы в качестве svn-сервера. <konsole> # apt-get install apache2 libapache2-svn </konsole>

Разрешаем все необходимые модули Apache. <konsole> # a2enmod dav # a2enmod dav_svn # a2enmod ldap # a2enmod authnz_ldap # a2enmod authz_svn </konsole>

Редактируем файл /etc/apache2/mods-enabled/dav_svn.conf

#  Указываем путь, по которому Apache будет обрабатывать svn-запросы. Можно указать /svn или любой другой. Мне удобнее обрабатывать запросы в корне.
<Location />

  # Включаем обработку svn-запросов по этому адресу
  DAV svn
  
  # Указываем путь к каталогу с репозиториями. Если же у нас один репозиторий, то нужно использовать опцию SVNPath и указать в ней путь к репозиторию.
  SVNParentPath /srv/svn/bases
  
  # Разрешить листинг репозиториев
  SVNListParentPath On
  
  # Путь к файлу с описанием прав доступа к репозиториям и подпапкам, если надо. Также в этом файле можно определить гуппы пользователей. В самом Apache и его модуле LDAP 
  # к сожалению нет возможности управлять группами, поэтому есть два варианта: либо формировать группы из доменных пользователей вручную, либо использовать спец. скрипты, 
  # вроде этого(см. ссылку в конце статьи). 
  AuthzSVNAccessFile /etc/apache2/svnaccessfile
  
  # Сделать авторизацию в каталоге LDAP главной
  AuthzLDAPAuthoritative on
  
  # Тип аунтификации
  AuthType Basic
  
  # Указываем, что данные по логинам и паролям следует брать в LDAP
  AuthBasicProvider ldap
  
  # Информационное сообщение, которое будет выводиться в окне аунтификации
  AuthName "Yohoho!"
  
  # Пользователь в AD с правами на чтение каталога
  AuthLDAPBindDN "reader@domain.local"
  
  # Его пароль
  AuthLDAPBindPassword "passw0rd"
  
  # Строка подключения к AD. В данном случае поиск пользовтелей выполняется не во всем домене, а только в контейнере AllUsers, также отфильтрованы заблокированные пользователи
  AuthLDAPURL "ldap://domain.local:389/OU=AllUsers,DC=domain,DC=local?sAMAccountName?sub?(&(objectClass=user)( !(userAccountControl:1.2.840.113556.1.4.803:=2)))" NONE
  
  # Позволяем получать доступ только авторизовавшимся пользователям. Также, если есть такая необходимость, можно разрешить авторизовываться в svn только пользователям, входящим
  # в определенную группу, например SvnGroup, тогда вместо этой строки следует прописать это:
  # Require ldap-group cn=SvnGroup,ou=AllGroups,dc=domain,dc=local
  Require valid-user
  
</Location>

В данном примере, группе group1 дан доступ на чтение/запись в репозиторий repo1, а группе group2 только на чтение. При этом в папку secret в репозитории repo1 предоставлен доступ только пользователю user6, а остальным явно запрещен(*= ), если не добавить этот параметр, то доступ к папке secret унаследуется от корня репозитория.

[groups]
group1 = user1, user2, user3
group2 = user4, user5

[repo1:/]
@groups1 = rw
@groups2 = r

[repo1:/secret]
user6 = rw
*=

Для поиска проблем в конфигурации лучше всего включить отладку, для этого в виртуалхосте, на котором работает svn(обычно - default) нужно заменить LogLevel warn на LogLevel debug.

Самая распространненая ошибка - 500 (internal server error). Чаще всего это связано с неправильными реквизитами доступа к каталогу LDAP. При этом в логах появляется что-то вроде:

"OPTIONS /svn HTTP/1.1" 500

Также, при корректной конфигурации, возможно следующая проблема:

[3574] auth_ldap authenticate: user foo authentication failed; URI /svn [ldap_search_ext_s() for user failed][Operations error]

Лечится добавлением в файл /etc/ldap/ldap.conf следующей строки:

REFERRALS off

Еще одна проблема, с которой я сталкнулся - нестабильное появление ошибки при комите:

Server sent unexpected return value (400 Bad Request) in response to MERGE  

Дело оказалось в Kaspersky Antivirus 2012, это он хулиганил. Решение проблемы - добавить в исключения файлы TortoiseProc.exe и TSVNCache.exe

• Скрипт синхронизации групп AD и Subversion
• Параметры Apache LDAP
• Документация по SVN