Не применяются параметры Kerberos (через GPO)?

Question

[Aleksandr]

Собственно subj!
Достался в наследство домен - кто, как и в какой способ его насиловали ранее не суть важно... нужно решить озвученную проблему!
Преамбула: было (и есть сейчас) несколько контроллеров домена... симптотматика такова: если GPO изменялось на одном контроллере - все ОК, "выключалось" на первом изменялось на другом - от сосны иголочка: по gpresult касаемо Kerberos пусто! Возвращаем все назад (настраиваем GPO снова на первом, на другом предварительно все возвращаем в дефолт) - все ОК... По состоянию на сейчас - даже это перестало работать :(

Вопрос к всезнаюшему гуру: в какую сторону копать? Уже всю голову сломал... :( Предложение переставить домен "с нуля" априори не рассматривается - домен с древней историей и разломать его не представляется возможным... так же как и мигрировать на другой через траст...

Буду признателен за любые дельные советы, которые помогу решить проблему!
Спасибо.

Comments

[Alexey Dmitriev]

Копать в сторону поднятия своего уровня компетенций, или приглашения стороннего специалиста.
Очень странно, что вы беретесь за одну из "основ" инфраструктуры, не имея знаний.

[Aleksandr]

Alexey Dmitriev, вы всегда агрессируете или у вас только сегодня день с утра не задался?
Всего хорошего...

[Alexey Dmitriev]

Aleksandr, это не агрессия, а удивление. Вы описываете действия, показывающие, что у вас отсутствуют базовые знания по вопросу, а с учетом того, что судя по описанию, это в проде делается - выглядит вообще как вредительство.

Answer 1

[Роман Безруков]

Все контроллеры домена равнозначны - поэтому редактировать GPO можно на любом, где есть компонент Group Policy Management и достаточно прав. По вашему описанию я понял, что вы сбрасываете в "дефолт" какую-то политику на одном КД и тут же, не дожидаясь репликации, настраиваете ее на другом контроллере - кто вас научил делать именно так?
Обычный порядок такой: меняем политику - ждем репликацию (или подпинываем ее через repadmin) - выполняем gpupdate /force на клиенте - проверяем результат через gpresult /r или gpresult /h.
Kerberos Policy - политика уровня домена (domain-wide). Параметры настраиваются или в Default Domain Policy, или в отдельной политике, которая привязывается к корню домена и имеет более высокий приоритет, чем Default Domain Policy.
Не помешает проверить здоровье контроллеров домена (репликацию, ошибки и т.д.)

Comments

[Aleksandr]

Все это уже было сделано и проверено неоднократно! Ошибок репликации нет... Возможно выше неккоректно немного написано - параметры сбрасываются на одном контроллере, дожидаемся синка и после этого настраиваем на дургом...

Однако факт неработоспособности остается, посему и родился этот вопрос...

[Роман Безруков]

Aleksandr,

параметры сбрасываются на одном контроллере, дожидаемся синка и после этого настраиваем на дургом

а профит от этого в чем? какая разница между КД?
1. Что есть ваша политика с настройками Kerberos - Default Domain Policy или отдельная политика?
2. Если отдельная политика - куда она привязана и какой приоритет у нее в сравнении с Default Domain Policy?
3. Системные журналы на клиентах изучали на предмет ошибок применения групповых политик?

[Aleksandr]

1. Default
2. и 3. ошибок и варнингов связанных с этим - НЕТ

[Роман Безруков]

Aleksandr, если это Default Domain Policy - то она применяется ко всему домену, если только (внезапно) где-то на каком-то OU не отключено наследование. В gpresult видно, что политика применяется?
С любого КД можно запустить моделирование групповой политики для конкретного клиента: настраиваете политику - ждете репликацию - запускаете моделирование - смотрите в параметрах Winning Policy

[Aleksandr]

Нет, в gpresult следов от применения Kerberos НЕТ!
Хотя другие блоки/разделы из этой политики в Kerberos присутствуют... :(

[Aleksandr]

В симуляции отображается что параметры Kerberos должны применяться из Default Domain Policy...
Остальными политиками эти параметры НЕ перекрываются нигде - проверил уже неоднократно

[Роман Безруков]

Aleksandr, погодите...клиент, на котором запускается gpresult - это рядовой доменный сервер/ПК, не контроллер домена?

[Aleksandr]

Да, обычный доменный ПК на базе Windows 11
Контроллеры домена - на базе Windows 2022 Server

[Роман Безруков]

Aleksandr, на рядовых серверах/ПК таких настроек нет - они есть только на контроллерах домена...выполните gpresult /h на любом КД и посмотрите отчет

[Aleksandr]

На доменных контролерах - керберос в gpresult присутствует!
НО
ранее эти параметры были и в gpresult на рабочих станциях!

Кроме того, есть связанная проблема: через WinRM сейчас могут подключаться к доменным контроллерам даже неуполномоченные пользователи!
И есть предположение что это именно из-за Kerberos

[Aleksandr]

Klist на станции показывает что какие-то тикеты прилетают...

[Aleksandr]

Возможно иду по ложному пути... :( Однако есть еще личные обстоятельства, которые мешают способности думать логически...

[Alexey Dmitriev]

Aleksandr, никогда нельзя вносить изменения в любую из * Default Policy.
Для любых перекрывающих эти политики изменений необходимо создавать отдельные объекты GPO.

[Aleksandr]

Я в курсе про создание новых политик!

Посему сейчас по факту занимаюсь "реанимацией" домена, над которым поиздевалось куча народу... в том числе были ИЗМЕНЕНЫ дефолтные доменные политики.