Active Directory (Kerberos)

Для использования Kerberos-аутентификации необходимо убедиться, что в DNS-зонах обратного просмотра присутствует PTR-запись для полного доменного имени (FQDN) и URL (если URL отличается от FQDN) каждого узла, на котором установлена АРХИВА.

Добавление PTR-записи АРХИВА в зону прямого просмотра

Откройте на контроллере домена Диспетчер DNS.
Перейдите в раздел Зоны прямого просмотра → [ваше дерево].
Создайте новый узел:
- Введите имя и IP-адрес сервера с установленной АРХИВА, например ar.contoso.com/10.0.1.107.
- Отметьте опцию Создать соответствующую PTR запись.
- Нажмите Добавить узел.

Добавление учетной записи для чтения каталога LDAP в AD

В оснастке Active Directory Users and Computers создайте учетную запись пользователя (например, archiva-user). Эта запись потребуется для дальнейшей настройки авторизации: АРХИВА выполняет от её имени поиск объектов пользователя и чтение его атрибутов, в том числе неизменяемого идентификатора objectGUID.

Настройка авторизации АРХИВА

Основные настройки

Область по умолчанию (Default Realm) — домен, который АРХИВА будет использовать при Kerberos-аутентификации. Название домена (realm) должно быть указано в верхнем регистре (например, CONTOSO.COM).
Логин на чтение LDAP — имя пользователя, используемого для чтения каталога LDAP.
Пароль учетной записи службы — пароль пользователя, используемого для чтения каталога LDAP.
Адрес сервера Active Directory — FQDN-адрес контроллера домена AD с указанием порта (по умолчанию 389) для доступа к каталогу LDAP.

Дополнительные настройки

Атрибут привязки — имя атрибута, используемого для привязки пользователя к учетной записи. По умолчанию userPrincipalName.
Атрибут электронной почты — имя атрибута, содержащего email пользователя. По умолчанию proxyAddresses.
Значение электронной почты — значение атрибута, используемое для извлечения email. По умолчанию SMTP:(.*).
Основной атрибут электронной почты — имя основного атрибута email. По умолчанию mail.
Основное значение электронной почты — значение атрибута для извлечения email. По умолчанию (.*).
Атрибут мобильного — имя атрибута для извлечения номера мобильного телефона. По умолчанию mobile.
Атрибут отображаемого имени — имя атрибута для отображения имени пользователя в АРХИВА. По умолчанию displayName.

Идентификатор пользователя (objectGUID)

АРХИВА однозначно распознаёт пользователя по атрибуту objectGUID — уникальному 16-байтному идентификатору объекта, который контроллер домена создаёт вместе с объектом пользователя.

Свойства objectGUID:

Создаётся контроллером домена вместе с объектом и защищён от записи: изменить значение не может ни один администратор.
Уникален в пределах леса Active Directory.
Неизменяем. Не меняется при переименовании учётной записи, переносе объекта в другой организационный раздел (OU), смене userPrincipalName, sAMAccountName, mail, displayName, mobile, членства в группах. Восстановление удалённой учётной записи из Корзины (AD Recycle Bin) сохраняет тот же objectGUID.
Не сохраняется только в двух случаях: объект удалён безвозвратно и создан заново, либо учётная запись мигрирована в другой домен или лес — там создаётся новый объект с новым objectGUID. В этих сценариях в АРХИВА формируется новый профиль пользователя.

Значение objectGUID АРХИВА получает по тому же LDAP-соединению (порт 389 или 636), что и остальные атрибуты, — под учётной записью, указанной в поле Логин на чтение LDAP. Отдельных прав настраивать не требуется: objectGUID входит в набор атрибутов, доступных на чтение аутентифицированным пользователям по умолчанию.

Проверка доступности objectGUID

Убедитесь, что учётная запись для чтения каталога получает идентификатор:

ldapsearch -x -H ldap://dc01.contoso.com:389 \
  -D "archiva-user@contoso.com" -W \
  -b "DC=contoso,DC=com" \
  "(userPrincipalName=ivanov@contoso.com)" dn userPrincipalName objectGUID

Атрибут возвращается в бинарном виде, поэтому в выводе ldapsearch он отображается как base64-строка:

dn: CN=Ivanov Ivan,Ivanovich,OU=Users,DC=contoso,DC=com
userPrincipalName: ivanov@contoso.com
objectGUID:: Xb3YSpkQyk2Rw5T/9Uf/2Q==

В PowerShell тот же идентификатор в привычном формате GUID:

(Get-ADUser -Identity ivanov -Properties objectGUID).objectGUID

Если objectGUID в ответе отсутствует, вход в АРХИВА для такого пользователя выполняться не будет.

Сетевые порты для Kerberos и LDAP

Обязательные порты

Kerberos (аутентификация)

Порт	Протокол	Назначение
88	TCP/UDP	Kerberos (KDC) — аутентификация пользователей и сервисов
464	TCP/UDP	Kerberos Password Change — смена/сброс пароля

Примечание: Kerberos может использовать UDP или TCP. При превышении размера пакета автоматически используется TCP.

LDAP (доступ к каталогу)

Порт	Протокол	Назначение
389	TCP/UDP	LDAP — нешифрованный доступ к каталогу AD
636	TCP	LDAPS — LDAP поверх SSL/TLS

DNS (критически важно для Kerberos и LDAP)

Порт	Протокол	Назначение
53	TCP/UDP	DNS — поиск контроллеров домена и Kerberos/LDAP SRV-записей

Дополнительные порты (рекомендуемые)
- Global Catalog (при использовании поиска по всему лесу)
Порт
Протокол
Назначение
3268
TCP
Global Catalog (LDAP)
3269
TCP
Global Catalog over SSL (LDAPS)
Минимальный набор правил Firewall (клиент → DC). Разрешите соединения к контроллерам домена по следующим портам:
- DNS: 53/TCP, 53/UDP
- Kerberos: 88/TCP, 88/UDP
- Kerberos password change: 464/TCP, 464/UDP
- LDAP: 389/TCP
- (опционально) LDAPS: 636/TCP
- (опционально) Global Catalog: 3268/TCP, 3269/TCP

Порт	Протокол	Назначение
3268	TCP	Global Catalog (LDAP)
3269	TCP	Global Catalog over SSL (LDAPS)

Пример настройки

Назначение ролей учетной записи

Для назначения роли в АРХИВА для учетной записи AD необходимо:

Нажать кнопку Назначить новую роль.
Выбрать соответствующую Роль.
Выбрать Атрибут LDAP, который будет сопоставляться с атрибутом учетной записи AD.
Указать условие содержит и ввести значение атрибута LDAP для сопоставления.

Форма поиска атрибутов

Для удобства выбора атрибута и значения можно воспользоваться формой поиска:

Нажмите кнопку Поиск в форме назначения ролей.
Введите email учетной записи и нажмите Поиск. Система найдет пользователя и отобразит список его атрибутов.
Дважды щелкните по нужному атрибуту, чтобы добавить его в форму назначения ролей.

Проверка авторизации в АРХИВА

Для проверки корректности авторизации:

Нажмите кнопку Проверить логин в форме назначения ролей.
Введите email учетной записи и нажмите Проверить новый логин.
При успехе появится сообщение с подтверждением прохождения проверки и назначения роли.

Взаимодействие Active Directory, Kerberos и DNS

Термины домен и область (realm) концептуально схожи, но относятся к разным системам. Области и их именование определены протоколом Kerberos, где они выполняют ту же роль, что и домены. На практике большинство областей Kerberos называются в соответствии с DNS-доменами.

В Active Directory домен представляет собой интегрированную среду, объединяющую DNS, LDAP, Kerberos и другие компоненты. Домен AD использует сервис DNS для поиска серверов, а само доменное имя DNS служит пространством имен для учетных записей. Как правило, контроллер домена AD одновременно выполняет роль DNS-сервера для своего домена.

Например, учетные записи пользователей имеют UPN вида i.ivanov@ad.contoso.com, состоящий из имени пользователя и DNS-домена (без учета регистра). Аналогично формируются SPN-адреса служб.

Внутренне эти имена преобразуются в «основное имя Kerberos», которое всегда записывается в верхнем регистре, например: i.ivanov@AD.EXAMPLE.COM. Каждый домен Active Directory функционирует как область Kerberos и имеет одно уникальное имя области. Каждый контроллер домена AD также выступает в роли KDC (Key Distribution Center) для соответствующей области.

Таким образом, область Kerberos является логическим подмножеством домена AD. Хотя Kerberos может работать автономно, в составе AD он тесно интегрирован с DNS и LDAP. Клиенты Kerberos используют DNS-записи SRV для автоматического обнаружения KDC.

09 September 2026