Gerrit 2.15.12 - Kerberos + GSSAPI + Active Directory - возможная ошибка при отправке SPN - PullRequest
0 голосов
/ 29 марта 2019

Работа на RHEL 7.5 с Java 8. Kerberos 5, версия 1.15.1.

Мы наблюдаем странное поведение с этой настройкой, которое наблюдается во всех версиях с 2.11.10.

Обратите внимание, я не могу публиковать прямые журналы или конфигурацию, так как моя компания блокирует это.

Шаги для воспроизведения

1) Настройка gerrit для использования kerberos

gerrit.config

[container]
javaHome = <path to JRE>
javaOptions = -Djava.security.auth.login.config=<path to jaas.conf>

[auth]
type = LDAP

[ldap]
authentication = GSSAPI
server = ldap://<AD Realm>
<.. other AD related stuff..>

jaas.conf

KerberosLogin {
    com.sun.security.auth.module.Krb5LoginModule
            required
            useTicketCache=true
            doNotPrompt=true
            renewTGT=true;
};

, прямо из документации.

2) kinit keytab для создания заявки в кеш.3) Попробуйте авторизоваться.Сбой «Сервер не найден в базе данных Kerberos (7)».

Сбой также произойдет, если вы измените jaas.conf, чтобы попытаться использовать keytab напрямую.

Вы можете получить доступ к LDAPнапрямую используя имя пользователя / пароль, но из-за ограничений Компании у нас не может быть незашифрованного пароля в состоянии покоя на устройстве, так что это не жизнеспособное долгосрочное решение.

Мы взяли пакетный захват трафика дляAD Realm и мы видим одинаковое поведение, независимо от того, используем ли мы keytab или кеш.

1) Для kinit мы видим один запрос к AD с полем SPN, установленным в SPN из keytab.Это, конечно, отлично работает.2) Для любого запроса от Gerrit мы видим ДВА запроса к AD, первый имеет правильное имя участника-службы из кэша / таблицы ключей, второй пытается отправить имя участника-службы «ldap /» независимо от того, какое значение SPN установлено.Этот второй запрос является причиной ошибки, поскольку имя SPN не распознается в AD. Обратите внимание, что мы пробовали набор ключей с различными именами SPN (HTTP / устройство, хост / устройство, HTTP / устройство @ и т. Д. И т. Д.).То же самое происходит каждый раз.

Это может быть что-то очень простое, что-то не так в нашей конфигурации, но мы уже несколько недель ломаем голову над этим.

1 Ответ

0 голосов
/ 30 марта 2019

Второй запрос, скорее всего, появляется, потому что вы указали сервер LDAP ldap://<AD Realm> в конфигурации Gerrit. Аутентификация HTTP GSSAPI вполне может быть успешной на этом этапе, но теперь приложение должно аутентифицировать себя на сервере LDAP, прежде чем оно сможет получить информацию о пользователе. Это происходит независимо от самой аутентификации HTTP.

Обычно SPN не распознается, поскольку Active Directory обычно не использует <AD Realm> для выбора контроллера домена - вместо этого необходимо указывать имена отдельных серверов, например, ldap://dc01.ad.example.com. (Реальные клиенты AD выбирают сервер автоматически через записи DNS SRV, но простые клиенты LDAP часто не поддерживают это.)

Также обратите внимание, что keytab - это , по сути, незашифрованный пароль в состоянии покоя.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...