Вопрос или проблема
Моя проблема точно такая же, как упоминается здесь Link1, однако предложенные и альтернативные решения не сработали.
Контекст: Мы работаем в оффлайн-среде, из виртуальной машины, которую не управляем, но с несколькими (Windows) виртуальными машинами, которые можем управлять (но не создавать), только локальные учетные записи. Решили, что будет проще управлять этим с помощью AD и одной учетной записи на человека.
Итак, у нас есть Windows Server 2019, на нем я установил AD и DNS, и создал учетные записи пользователей, вместе с некоторыми GPO, в основном для предоставления прав пользователям подключаться удаленно.
На ВМ были настроены некоторые DNS (у меня нет доступа к настроенным DNS; их управляет другая команда); я всегда менял основной на IP моего AD/DNS (что иногда оставляло вторичный, не связанный с моим AD).
Затем я подключил их к AD. Никаких проблем, я видел, что политики обновлены, мог подключить пользователя-администратора. Но не мог подключить “обычного” пользователя, должен был сначала добавить группу “Remote Users” в авторизованные пользователи RDP на каждой ВМ, хотя я уже настроил политику “Allow Remote Desktop” (или как она называется на английском) и ограниченную группу, чтобы мои пользователи домена автоматически добавлялись в локальные группы “Remote Desktop Users” на ВМ.
Мне это показалось странным. Во время отладки я попробовал выполнить gpupdate /force на одной из ВМ. И она завершилась неудачно, с ошибкой 49, как в предоставленной ссылке; детали в журнале событий указывали на неудачную попытку аутентификации по LDAP. Попытался получить отчет с помощью GPResult /H Gpreport.html, но затем получил ошибку “у пользователя нет данных RSOP”
Я могу пинговать свой домен из ВМ без проблем. Некоторые политики применены (я вижу их в gpedit с именем связанной GPO) и мои пользователи AD могут подключаться к ВМ. Почему тогда gpupdate не удается??
Я провел день в поисках онлайн. Помимо ссылки (попробовал предложенный ответ, данных авторизации в интерфейсе НЕТ), большинство говорит, что это может быть проблема с DNS. И я должен признать, что DNS ведет себя немного странно, говоря “тайм-аут” и “сервер: неизвестен”, но все же выдает правильный результат. Я проверил мою конфигурацию DNS, она, кажется, в порядке, но я в этом не эксперт.
Есть идеи?
Итак, я нашел проблему, и она не связана с моим DNS (хотя это все равно странно) и полностью связана с тем, как я попытался добавить пользователей домена AD в локальную группу “Remote Desktop Users” с помощью GPO.
В GPO, в разделе Computer Configuration – Preferences – Control Panel Settings – Local Users and Groups, я создал новую локальную группу с действием: Update, названием группы: Remote Users (Built-in) и участниками: DOMAIN\Domain Users
На самом деле, именно после этого изменения gpupdate начал сбоить, а я не связал это. Глупый я.
В любом случае, удалил эту вещь, и все снова работает. Не знаю, почему это приводило к сбою всего, когда должно было просто позволить моим пользователям AD быть частью локальной группы Remote Desktop Users, но, думаю, мне нужно больше узнать о настройках панели управления, прежде чем их использовать.
Ответ или решение
Нажмите здесь, чтобы увидеть ответ на русском языке
#### Теория
Когда gpupdate терпит неудачу из-за проблемы с аутентификацией LDAP, это может быть связано с несколькими потенциальными причинами, включая DNS конфигурацию и настройки групповой политики. В контексте сетевой среды с доменом Active Directory на основе Windows Server 2019 часто приходится сталкиваться с различными аспектами взаимодействия AD и клиентских машин. Ваша ситуация может быть связана с проблемами при применении настроек GPO, особенно когда они затрагивают разрешения на уровне локальных групп пользователей.
Active Directory (AD) и служба LDAP (Protocol доступа к каталогу с легким весом) тесно связаны друг с другом. LDAP используется как протокол для аутентификации и управления доступом, именно через него доменные контроллеры обрабатывают запросы на аутентификацию и контролируют соответствие политики безопасности в системе. Если возникает ошибка LDAP аутентификации, это может быть следствием неверной настройки DNS, которая препятствует корректной маршрутизации и разрешению имен, либо сложной настройки GPO.
#### Пример
Как вы описали, ваша проблема началась после неправильной настройки GPO, связанной с добавлением доменных пользователей в локальную группу “Remote Desktop Users”. В вашем случае, изменение GPO включало настройку, которая предполагала добавление доменных пользователей в локальную группу “Remote Desktop Users”, что потенциально конфликтовало с существующими конфигурациями либо из-за синтаксических ошибок, либо из-за неправильно выбранных параметров.
Например, вы установили действие “Обновить” для локальной группы, однако это могло неправильно взаимодействовать с уже существующими настройками или механизмами безопасности системы, такими как механизм RDP (Remote Desktop Protocol). Не все изменения предпочитаются для обновления с использованием группы “Remote Users”, поскольку она управляется системными безопасными настройками.
#### Применение
Чтобы избежать подобных проблем в будущем и обновить вашу текущую конфигурацию к стабильному состоянию, стоит выполнить ряд шагов:
1. **Проверка DNS конфигурации**: Убедитесь, что все клиентские машины имеют правильно установленный DNS сервер. Если в вторичном DNS сервере указаны недействительные или чужие DNS записи, это может вызывать проблемы с подключением и синхронизацией групповых политик через LDAP.
2. **Корректировка GPO**: Выйдите за рамки простого “обновления” и рассмотрите возможность использования “замены” для действий, где это применимо. В случае с вашей настройкой GPO, лучше использовать “замену” для группы “Remote Desktop Users”, а также обозревать логи для лучше понимания порядка применения настроек.
3. **Мониторинг и диагностика**: Используйте средства диагностики, такие как `RSOP` (Resultant Set of Policy) и средства проверки событий, чтобы следить за процессом применения политики. Эти инструменты помогут увидеть, какие именно GPO вызывают проблемы и как они пересекаются.
4. **Обучение и уверенность в планировании**: При работе с сетевым окружением AD и множеством межзависимых компонентов, всегда важно иметь хорошо проработанную процедуру планирования и внедрения изменений. Рассматривайте использование тестовых окружений прежде чем разворачивание GPO на живых машинах.
Наконец, окружающая среда AD и конфигурации GPO могут быть сложными для внедрения и требуют скрупулезного подхода при любых изменениях. Консультация с профессионалами в области сетевой безопасности и системного администрирования может значительно упростить понимание и решение подобных проблем в будущем.