Kerberos/SPNEGO: несколько SPN для той же учетной записи AD

Question

Развертывание одного и того же HTTP-приложения на нескольких веб-серверах (srv1, srv2 и т. Д.). Защита приложения с помощью SPNEGO auth. Серверы Linux и AD не знают об их существовании, т. Е. Не присоединяются к домену. У меня все SPNEGO работает плавно на одном хосте. Теперь перейдем к последующим хостам.

Большинство руководств, которые я нашел скажу вам, что вам нужно

1. счет в AD
2. SPN
3. A Keytab (генерируемый на сервере AD, а затем перешел к хосту Linux)

Хотя я считаю, что (2) + (3) всегда должен быть на сервере, я несколько не уверен в (1). Можно ли использовать только одну учетную запись? Я бы очень хотел, чтобы у меня не было всех этих учетных записей в AD, если я могу сделать только с одним.

This blog имеет хороший рецепт для того, как это можно сделать: первый вызов ktpass (для srv1) должно быть, как описано в всех руководствах вы найдете в Интернете, однако последующие вызовы (для srv2, srv3 и т.д.) следует использовать параметры -setpass и -setupn.

Однако я обнаружил, что при использовании инструмента ktpass.exe атрибут учетной записи userPrincipalName изменяется так, как указано аргументом princ от последнего вызова ktpass. Таким образом, имя srv, например. srv3 закодирован в имя, и поэтому имя учетной записи будет в основном изменяться с каждым вызовом ktpass. Когда веб-сервер выполняет последний этап в цепочке событий SPNEGO, который должен связаться с AD с помощью keytab в качестве учетных данных, он будет искать учетную запись в AD с userPrincipalName, равным SPN, и поэтому этот шаг завершится с ошибкой. (source, перейти к последнему сообщению, item item 3). Противоречие в том, что я использую Tomcat и тем самым JAAS, и насколько я понимаю, я могу hardcode the principal name to use in my jaas.conf file, тем самым эффективно игнорируя главное имя из keytab.

Может ли работать несколько серверов приложений с одной учетной записью в AD, и если да, то как?

Answer 1

Короче говоря, да, это сработает, и я расскажу вам, как это сделать. Прежде всего, давайте проясним некоторые вещи и некоторые утверждения, которые не были должным образом описаны в вашем вопросе или комментарии:

У вас есть три машины, которые обслуживают одно и то же DNS-имя, это означает, что у вас либо есть DNS-механизм: service.example .com вернет перетасованный список, если IP-адреса или балансировщик нагрузки (жесткий сортировки) будут иметь только один IP-адрес для записи A в зависимости от нагрузки. Для Kerberos обе настройки равны в результатах. Теперь вы не можете сказать, что AD не знает о существовании службы или сервера, если требуется проверка подлинности Kerberos. Он будет и должен знать иначе он не может создать служебные билеты для ваших клиентов, которые они передают на сервер. Кроме того, Tomcat will not contact KDC принимает контекст безопасности, поскольку билет на обслуживание зашифрован с помощью долгосрочного ключа учетной записи.

Вот такой подход: вы уже поняли, что один SPN может быть привязан к одной машине, несколько привязок не допускаются. Это тот случай, когда имя машины привязано к учетной записи машины (srv1$ и т. Д.).Вам нужна служебная учетная запись . Учетная запись службы является обычной учетной записью без истечения срока действия пароля, например, my-service@EXAMPLE.COM. Для этой учетной записи вы привяжете свою запись CNAME или A. У вас есть Tomcat authenticator, чтобы принять все контексты безопасности с этой учетной записью службы, и она будет работать.

Как создать эту волшебную учетную запись службы на Unix-подобной ОС? Использования mskutil для

1. создать учетную запись службы,
2. создать Keytab для этой учетной записи службы,
3. привязки вашего SPN к этой учетной записи службы и имеет Keytab обновляется.

После этого у вас будет keytab, подходящий для вашего использования. Проверьте с помощью LDAP-запроса (например, с помощью браузера LDAP Softerra или другого), что учетная запись существует, SPN (servicePrincipalName) привязан к этой учетной записи, и все готово.

Важно: если какой-либо из ваших клиентов использовать MIT Kerberos или Хеймдал, вы необходимо установитьrdns = false ваш ваш krb5.conf.

Godspeed!