Kerberos SPN кэшируется на серверах Windows?

Question

Я интегрировал аутентификацию Kerberos в мой проект единого входа. Наткнулся на своеобразный сценарий.

Я сделал нового пользователя и прикрепил к нему SPN. Последовали шаги по этому вопросу и все заработало. Под всем, что я имею в виду:

1. kinit username - а затем введя пароль, я получил сообщение о том, что билет был сохранен.
2. kinit spn (в формате HTTP/FQDN) - и затем ввод пароля дал мне сообщение, что галочка была сохранена.

Через некоторое время я решил попробовать еще раз, и поэтому я использовал команду

setspn -D spn username

отсоединить spn от имени пользователя. Затем я удалил этого пользователя (имя пользователя) из AD.

Затем я создал нового пользователя с именем username1 и сделал в соответствии с этим вопросом, чтобы зарегистрировать тот же spn, что и в предыдущем шаге для этого нового пользователя.

Теперь kinit username1 - и при вводе пароля выдает сообщение о том, что тикет сохранен, однако kinit spn - и при вводе пароля выдает мне ошибку

client not found in Kerberos database.

Обратите внимание, что все работает нормально, если я использую другой (новый) spn.

Таким образом, вопрос заключается в том, имеет ли сервер Windows определенный кэш, в котором все еще присутствуют некоторые ссылки, из-за чего я не могу снова использовать этот spn? Или я сделал какую-то ошибку при отсоединении spn от пользователя?

Спасибо, Нихил

Answer 1

После просмотра того, что вы написали в чате, а также полной истории проблем, проблема на самом деле состоит из двух проблем. (1) Необходимо всегда удалять используемый SPN перед созданием таблицы ключей. (2) Внутри команды создания таблицы ключей ktpass.exe вам необходимо сопоставить пользователя с использованием имени участника-службы HTTP/vinw12sec5225.eqsectest.local вместо краткого имени входа в систему krbspn. Кроме того, я просто сделаю наблюдение - вам не нужно размещать SPN во всех заглавных буквах. Это затрудняет чтение, хотя ради преемственности я это не изменил. Только область Kerberos должна быть во всех заглавных буквах. На основании предоставленной вами информации, чтобы решить это дело, вы должны выполнить следующие команды:

1. setspn -D HTTP/VINW12SEC5225.EQSECTEST.LOCAL krbspn
2. ktpass /princ HTTP/[e-mail] /ptype krb5_nt_principal /crypto All /mapuser [e-mail] /out c:\ticket\krbspn.keytab -kvno 0 /pass eQ@12345
3. klist -e -k -t c:\ticket\krbspn.keytab

Для справки я покажу пример того, как создать таблицу ключей, когда Microsoft Active Directory используется в качестве службы каталогов, здесь: Kerberos Keytabs - Explained. Я также предоставлю сопроводительное объяснение каждого параметра синтаксиса ktpass.exe.

Чтобы помочь решить, что еще может быть не так после описанных выше шагов, затем с помощью Notepad++ (не обычного Notepad) щелкните правой кнопкой мыши и отредактируйте файл keytab, просто скопируйте содержимое файла keytab (не вносите никаких изменений), а затем изучите Результаты. Секретный ключ внутри будет зашифрован - это нормально, посмотрите, как сформулирован SPN внутри keytab. Он должен соответствовать тому, что указано для имени участника-службы в учетной записи AD. Если они не совпадают, вы получите ошибку "клиент не найден в базе данных Kerberos". Также убедитесь, что в конфигурации сервера приложений указан правильный файл таблицы ключей, и перезапустите службу приложения, если что-то изменилось в отношении таблицы ключей.