Внедрение «Защищенных пользователей» и столкновение с этой проблемой, решение которой я нигде не мог найти. Не удается присоединить компьютеры к домену с разрешениями делегирования. Вместо этого группе было назначено право «Добавить рабочую станцию в домен».
Обширный фон:
Насколько я понимаю, члены защищенных пользователей будут вынуждены использовать аутентификацию Kerberos. Фактически это то, что я вижу, когда пытаюсь присоединиться к рабочей станции, предоставляя члену этой группы следующие разрешения в контейнере Computers:
Делегация у контейнера "Компьютеры":
Создание компьютерных объектов - этот объект и все его потомки
Ограничения для чтения / записи учетной записи - объекты-потомки
Подтвержденная запись в имя участника службы - объекты дочернего компьютера
Подтвержденная запись на имя хоста DNS - объекты дочернего компьютера
Создать все дочерние объекты - объекты-потомки
Сброс пароля - объекты дочернего компьютера
Протестировано на двух пользователях: пользователь с членством в группе «Защищенные пользователи» и пользователь без членства в группе «Защищенные пользователи». Оба пользователя входят в группу делегирования.
Сам тест:
При попытке добавить компьютер в домен пользователь без группы Protected Users успешно добавляет рабочую станцию в домен. Пользователь с группой «Защищенные пользователи» получит сообщение об ошибке: «Ограничения учетной записи не позволяют этому пользователю войти в систему». Я вижу сбой проверки подлинности NTLM в ProtectedUserFailures-DomainController
Однако изменение групповой политики, позволяющей «добавлять рабочие станции в домен» путем добавления группы, к которой принадлежат оба пользователя, изменит результат на успех для обоих. Теперь я могу видеть информацию в ProtectedUserSuccesses-DomainController с аутентификацией Kerberos.
Итак, мой вопрос: какие механизмы задействованы и какие разрешения я могу делегировать для достижения того же результата, или это невозможно? Почему права пользователя позволяют выполнить это действие для члена группы «Защищенные пользователи», а простое делегирование - нет?
Прежде чем кто-нибудь спросит, это было протестировано и работает как в продукте, так и в простой тестовой среде, которую вы можете воссоздать с помощью приведенной выше информации.
Я подозреваю, что это проблема, потому что вы нарушаете явные рекомендации Microsoft, применяя делегированные разрешения к контейнеру Computers.
Из Делегирование администрирования контейнеров и подразделений по умолчанию:
Если вам необходимо делегировать контроль над пользователями или компьютерами, не изменяйте настройки по умолчанию для контейнеров пользователей и компьютеров. Вместо этого создайте новые подразделения (по мере необходимости) и переместите объекты пользователя и компьютера из контейнеров по умолчанию в новые подразделения. При необходимости делегируйте контроль над новыми организационными единицами. Мы рекомендуем вам не изменять, кто контролирует контейнеры по умолчанию.
Таким образом, вы можете использовать устаревший контейнер Computers и соответствующее право «Добавить рабочие станции в домен». или вы можете использовать правильные подразделения с делегированными разрешениями, но если вы решите использовать устаревший контейнер Computers, вы не ожидаете, что будете использовать делегированные разрешения. Поэтому неудивительно, что Microsoft не тестировала этот конкретный сценарий при внедрении Protected Users!
Обратите внимание, что если вы используете отдельные подразделения, присоединение нового компьютера к домену становится двухэтапным процессом: вы должны явно создать объект компьютера в желаемом подразделении перед присоединением компьютера к домену.
Более предположительно:
Кажется вероятным, что ваш текущий процесс падает, когда новый компьютер пытается присоединиться к домену и обнаруживает, что существующего объекта-компьютера нет, и в этом случае он автоматически создает его в контейнере Computers. Казалось бы, этот автоматизированный процесс, который требуется только в устаревшем сценарии, знает только, как создать компьютер одним из двух способов, один из которых требует привилегии «Добавить рабочие станции в домен», а другой использует NTLM. аутентификация.
Использование NTLM здесь может быть неотъемлемым ограничением соответствующего протокола или может быть просто артефактом устаревшего кода, используемого клиентом Windows в этом сценарии. Я полагаю, что вы могли бы в принципе реконструировать этот процесс, перехватив трафик между сервером и клиентом, но это, вероятно, не стоит затраченных усилий.
В любом случае, вы можете проверить эту теорию, убедив защищенного пользователя явно создать новый компьютерный объект в контейнере Computers (используя Active Directory Users and Computers с машины, которая уже находится в домене), прежде чем пытаться присоединить новый компьютер к домен. Я подозреваю, что вы обнаружите, что этот процесс работает даже без привилегии «Добавить рабочие станции в домен».