Windows Server 2012 R2, Kerberos: Должен ли существовать SPN “host/localhost”?

Я заметил, что журнал событий “Microsoft-Windows-Security-Kerberos” заполняется одной и той же записью примерно каждую минуту (иногда три раза в минуту, иногда только через две или три минуты):

• ID события: 100
• Описание (в грубом переводе с немецкого): Имя сервисного принципала “host/[email protected]” не зарегистрировано, что вызывает ошибку при аутентификации Kerberos: 0x7. Используйте командную утилиту “setspn.exe”, чтобы зарегистрировать SPN

Это происходит на нашем основном контроллере домена (также хостит Exchange 2013), но не на вторичном.

Я много искал, но не смог найти ничего применимого, кроме https://comp.protocols.kerberos.narkive.com/WfAhMzuZ/host-localhost-principal:

Существуют серьезные проблемы безопасности, связанные с наличием host/localhost на всех ваших машинах. Если одна из ваших машин будет скомпрометирована, ее можно использовать для атаки на другие машины.

Я понятия не имею, какая служба может вызывать эти записи. Я мог бы зарегистрировать SPN, но не знаю, хорошо ли это, или это может вызвать другие проблемы. Также я не заметил каких-либо проблем, которые могли бы быть вызваны этими записями.

• Как я могу узнать, какая служба это вызывает?
• Следует ли мне создать SPN?

Нет, не создавайте этот SPN никогда, если это возможно (это возможно). Это куда хуже, чем просто использование NTLM с самого начала.

Запись в журнале событий будет содержать идентификатор процесса на вкладке с деталями.

Этот идентификатор процесса можно сопоставить с именем процесса с помощью Get-Process -Id thatId -IncludeUserName в PowerShell, или даже просто посмотрев в Диспетчере задач, с показанным столбцом PID, чтобы определить, какой именованный процесс вызывает ошибку, и под какой учетной записью он работает. Добавьте | fl * в конце этого, чтобы увидеть ВСЕ свойства, возвращаемые этой командой, если вам нужно, так как вывод по умолчанию довольно базовый (но все же, вероятно, достаточный для его идентификации).

Если это что-то вроде lsass или другого системного процесса, вероятно, у вас есть проблемы с настройками доменных политик. Возможной причиной может быть разрешение нулевых сеансов, что различные компоненты будут с радостью делать, когда общаются с localhost и работают как локальная система или локальная служба. Kerberos не любит этого, и если у вас отключен NTLM для этой системы, не обеспечив, что ничего не будет пытаться использовать NTLM, скорее всего, вы получите эти ошибки.

Дополнительная информация, связанная с устранением неисправностей:

Судя по тому, что я смог узнать из опыта устранения неисправностей, исследований и исправления этого, очень сложно найти о этом что-то в интернете, и мне кажется, что это связано с тем, что у большинства людей, у кого есть похожие проблемы, они “более сломаны” и, следовательно, получают ещё больше записей в журнале событий с гораздо более полезными идентификаторами событий, и в конечном итоге решают эту проблему в процессе исправления своих больших конфигурационных проблем. Иными словами, ваша конфигурация, вероятно, очень близка к правильной, иначе у вас были бы гораздо более серьезные проблемы, такие как недоступные общие ресурсы, сбои входа, проблемы с репликацией и все эти милые чрезвычайные ситуации, которые могут возникать в результате системных ошибок в конфигурации Kerberos.

Если это приемлемо для вас как краткосрочное решение (так как это потенциальное снижение безопасности и может иметь другие непредвиденные эффекты) и как часть процесса устранения неисправностей для подтверждения того, что не так, вы можете включить исключение для этого сервера, чтобы разрешить NTLM. Вам нужно будет убедиться, что сервер захватывает и применяет обновленную групповую политику и перезагрузить его, прежде чем вы увидите значительное изменение. Если ошибки исчезнут или существенно уменьшатся, вы нашли виновника и можете продолжать с этого момента. Если нет, вероятно, это все еще NTLM и нулевые сеансы, но вам, возможно, придется отрегулировать некоторые другие политики, подождать репликации и выполнять перезагрузки после каждого изменения, чтобы найти окончательное решение.

Помогает ознакомиться со всеми документами и записями в блоге MS Learn по отключению NTLM, если вы застряли где-то с Kerberos.

В дополнение к различным групповым политикам, влияющим на NTLM и Kerberos, Kerberos абсолютно необходима полностью и правильно функционирующая DNS (как прямая, так и обратная) и правильные сертификаты на серверах, которым доверяют клиенты, чтобы работать должным образом, и любые остатки NTLM, включая такие вещи, как WINS и NetBIOS (которые не используют Kerberos и, следовательно, внедряют NTLM), необходимо либо полностью устранить, либо по крайней мере убедиться, что они не будут и не могут использоваться там, где требуется Kerberos.