Компьютер не может установить безопасный сеанс с контроллером домена

Обновлено: 21.11.2024

По умолчанию только члены группы «Администраторы домена» имеют удаленный доступ RDP к рабочему столу контроллеров домена Active Directory. В этой статье мы покажем, как предоставить RDP-доступ к контроллерам домена для учетных записей пользователей, не являющихся администраторами, без предоставления прав администратора.

Многие из вас вполне резонно могут задаться вопросом: а зачем обычным пользователям домена доступ к рабочему столу ДЦ? Ведь в инфраструктурах малого или среднего размера, когда их обслуживает несколько администраторов с привилегиями администраторов домена, это вряд ли понадобится. В большинстве случаев достаточно делегирования некоторых административных разрешений в Active Directory или использования PowerShell Just Enough Administration (JEA).

Однако в крупных корпоративных сетях, обслуживаемых многими администраторами, может возникнуть необходимость предоставить RDP-доступ к контроллеру домена (обычно к контроллеру домена филиала или контроллеру домена только для чтения) для различных групп администраторов серверов, группы мониторинга, дежурных администраторов или других лиц. технические кадры. Кроме того, время от времени некоторые сторонние сервисы, не управляемые администраторами домена, развертываются на контроллере домена, и возникает необходимость в обслуживании этих сервисов.

Совет. Microsoft не рекомендует устанавливать доменные службы Active Directory и роль службы удаленных рабочих столов (сервер терминалов) на одном сервере. Если есть только один физический сервер, на котором вы хотите развернуть и DC, и RDS, лучше использовать виртуализацию, так как политика лицензирования виртуализации Microsoft позволяет запускать два виртуальных сервера под одной лицензией Windows Server Standard.

Для удаленного входа вам нужны права на вход через службы удаленных рабочих столов

После того, как сервер был повышен до контроллера домена, вы не можете управлять локальными пользователями и группами с помощью оснастки управления компьютером mmc. При попытке открыть консоль «Локальные пользователи и группы» ( lusrmgr.msc ) появляется следующая ошибка:

Как видите, на контроллере домена нет локальных групп. Вместо локальной группы Пользователи удаленного рабочего стола контроллер домена использует встроенную доменную группу Пользователи удаленного рабочего стола (находится в контейнере Builtin). Вы можете управлять этой группой из консоли ADUC или из командной строки контроллера домена.

Отобразите членов доменной группы Пользователи удаленного рабочего стола на контроллере домена с помощью команды:

net localgroup "Пользователи удаленного рабочего стола"

Как видите, он пуст. Добавьте в него пользователя домена it-pro (в нашем примере это обычный пользователь домена без прав администратора):

net localgroup "Пользователи удаленного рабочего стола" /add corp\it-pro

Убедитесь, что пользователь добавлен в эту группу:

net localgroup "Пользователи удаленного рабочего стола"

Вы также можете убедиться, что пользователь теперь является членом доменной группы пользователей удаленного рабочего стола, с помощью оснастки ADUC ( dsa.msc ).

Однако даже после этого пользователь по-прежнему не может подключиться к контроллеру домена через удаленный рабочий стол с ошибкой:

Для удаленного входа вам необходимо право на вход через службы удаленных рабочих столов. По умолчанию этим правом обладают члены группы «Администраторы». Если группа, в которую вы входите, не имеет права или если право было удалено из группы администраторов, вам необходимо предоставить право вручную.

Групповая политика: разрешить вход через службы удаленных рабочих столов

Чтобы разрешить пользователю домена или группе удаленное подключение RDP к Windows, необходимо предоставить ему привилегии SeRemoteInteractiveLogonRight. По умолчанию этим правом обладают только члены группы «Администраторы». Это разрешение можно предоставить с помощью политики Разрешить вход через службы удаленных рабочих столов.

Чтобы разрешить удаленное подключение к контроллерам домена для членов группы «Пользователи удаленного рабочего стола», вам необходимо изменить настройки этой политики на вашем контроллере домена:

Запустите редактор локальной групповой политики ( gpedit.msc );
Перейдите в раздел GPO «Конфигурация компьютера» -> «Параметры Windows» -> «Параметры безопасности» -> «Локальные политики» -> «Назначение прав пользователя»;
Найдите политику Разрешить вход через службы удаленных рабочих столов;

После повышения роли сервера до контроллера домена в этой локальной политике остается только группа Администраторы (это администраторы домена).

Обратите внимание, что группа, которую вы добавили в политику «Разрешить вход в систему через службы удаленных рабочих столов», не должна присутствовать в политике «Запретить вход в систему через службы удаленных рабочих столов», поскольку она имеет более высокий приоритет (см. статью Ограничение доступа к сети). под локальными аккаунтами). Кроме того, если вы ограничиваете список компьютеров, на которых пользователи могут входить в систему, вам необходимо добавить имя контроллера домена в свойства учетной записи AD (атрибут пользователя LogonWorkstations).

Примечание. Чтобы разрешить пользователю локальный вход в ДК (через консоль сервера), необходимо добавить учетную запись или группу в политику «Разрешить локальный вход». По умолчанию это разрешение разрешено для следующих групп домена:

Операторы резервного копирования
Администраторы
Операторы печати
Операторы серверов
Операторы аккаунта

Лучше создать в домене новую группу безопасности, например, AllowLogonDC, и добавить в нее учетные записи пользователей, которым необходим удаленный доступ к контроллеру домена. Если вы хотите разрешить доступ ко всем контроллерам домена AD сразу, вместо редактирования локальной политики на каждом контроллере домена лучше добавить группу пользователей в политику контроллеров домена по умолчанию с помощью консоли GPMC.msc (изменить параметры политики в том же разделе: Конфигурация компьютера\Параметры Windows\Параметры безопасности\Локальные политики\Назначение прав пользователя -> Разрешить вход через службы удаленных рабочих столов).

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

Теперь пользователи (группы), добавленные вами в политику, смогут подключаться к контроллерам домена AD через RDP.

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

Отказано в доступе к запрошенному сеансу RDP

В некоторых случаях при подключении по RDP к контроллеру домена может появиться ошибка:

Если вы подключаетесь к контроллеру домена под учетной записью пользователя без прав администратора, это может быть связано с двумя проблемами:

Я получаю событие с идентификатором 5719, источником является NETLOGON. Я пробовал много разных вещей, таких как удаление и повторное добавление учетной записи компьютера. Я также искал в Интернете без успеха. Любая помощь будет высоко оценена. Я на Windows 7 PRO. Подробнее см. ниже:

Этому компьютеру не удалось установить безопасный сеанс с контроллером домена в домене домена по следующим причинам:

В настоящее время нет доступных серверов входа для обслуживания запроса на вход.

Это может привести к проблемам с аутентификацией. Убедитесь, что этот компьютер подключен к сети. Если проблема не устранена, обратитесь к администратору домена.

Система

[ SystemTime]

2010-10-13T22:43:37.000000000Z

EventData

Двоичные данные:

0000: 5E 00 00 C0 ^..À

Ответы

Спасибо за публикацию на форумах Microsoft TechNet.

Если вы можете правильно войти в домен, вы можете спокойно игнорировать событие с идентификатором 5719.

Поскольку служба Netlogon может запуститься до того, как сеть будет готова, компьютеру может не удаться найти контроллер домена для входа в систему. Поэтому регистрируется событие с кодом 5719. Однако после того, как сеть будет готова, компьютер снова попытается найти контроллер домена для входа в систему. В этой ситуации операция должна быть успешной.

Не забудьте нажать «Пометить как ответ» на сообщении, которое вам поможет, и нажать «Снять пометку как ответ», если помеченное сообщение на самом деле не отвечает на ваш вопрос. Это может быть полезно другим членам сообщества, читающим ветку. ”

Все ответы

Спасибо за публикацию на форумах Microsoft TechNet.

Если вы можете правильно войти в домен, вы можете спокойно игнорировать событие с идентификатором 5719.

Спасибо за публикацию на форумах Microsoft TechNet.

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

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

Вы недавно меняли пароль?

Также проверьте, синхронизировано ли время Win7 с контроллером домена входа в систему.

Леон Лю — технический руководитель

У меня точно такая же проблема. Это происходит только с моими компьютерами с Win7. У нас есть среда Win2003 DC. В моем случае драйвер устройства NIC сообщил, что он запущен со статусом соединения 100 Мбит/с в полнодуплексном режиме. Примерно через семь секунд получите ошибку Netlogon. Хотя мы можем войти в домен, ошибка присутствует на всех компьютерах. Мы также получаем задержки службы профилей пользователей до двух минут при входе в систему. Есть предложения?

Беннан, у меня такая же проблема. Сетевое соединение устанавливается за 12 секунд до того, как я вижу событие netlogon. Я использую W7 SP1 с доменом W2k3.

Кто-нибудь может ответить на этот вопрос? мы не видели его на XP

Беннан, у меня такая же проблема. Сетевое соединение устанавливается за 12 секунд до того, как я вижу событие netlogon. Я использую W7 SP1 с доменом W2k3.

Есть ли у кого-нибудь ответ на этот вопрос? мы не видели его на XP

На Expert Exchange я нашел связанную тему. Вот соответствующая часть:

Я обнаружил, что адаптерам Gigabite Broadcom не нравится функция "Распознавание носителя" от Microsoft.
Добавил ключ реестра в \hklm\system\currentcontrolset\services\tcpip\parameters - добавил "DWORD" DisableDHCPMediaSense = 1.
Это устранило все мои проблемы.

У меня была та же ошибка, и эта запись в реестре, похоже, решила ее.

Это отключение MediaSense работало на клиентах WinXP. Мы также обнаружили, что установка MediaType с Auto (1 Гбит/с) на 100Mbs-FullDuplex. Но оба больше не работали на Win7

У нас также есть несколько клиентов Win7, у которых есть эта проблема. Проблема в том, что затронутые ПК не получают групповые политики и не устанавливают пакеты MSI перед входом в систему.

На данный момент мы не нашли способ исправить это с клиентами Win7, и будем благодарны, если кто-нибудь это сделает.

У кого-нибудь есть новости по этой проблеме? У меня также есть эта проблема на клиентах Win7. Пользователи не могут войти в домен

Событие Netlogon 5719 само по себе является очень общим — само по себе оно не дает вам достаточно подробностей для устранения этой неполадки.
Суть в том, что при регистрации машина не может найти контроллер домена — обычно потому, что в этот момент у нее нет IP-подключения к сети.

Т.е. нет универсального ответа на то, что является основной причиной отсутствия контроллера домена при регистрации события - вам нужно копнуть глубже и найти другие факторы, чтобы ответить на этот вопрос. Большинство из них будут где-то на сетевом уровне.

У меня была такая же проблема. Я нашел следующую статью MS KB, которая наконец решила мою проблему:

Все пакеты MSI установлены должным образом.

Еще одна проблема, с которой мы столкнулись, заключалась в GPO «Отключить фоновое обновление групповой политики» (коллега включил это по ошибке) в сочетании с проблемой, когда клиенты вообще не получали никаких компьютерных политик.

Надеюсь, это также поможет вам.

Спасибо. Этот GpNetworkStartTimeoutPolicyValue является «рабочим» решением, но не решением.

Netlogon 5719 по-прежнему появляется, а также ошибки сервера времени.

Это странно, потому что не на каждом компьютере есть это, которое подключено к одному и тому же зданию с одним и тем же коммутатором

У меня примерно такие же ошибки (5719) и некоторые другие.Несколько пользователей ПК с Windows 7 сообщили, что они не могут войти в систему и получают сообщение «Сбой доверительных отношений между основным доменом и доверенным доменом»

При устранении неполадок мы обнаружили ошибку 5719:

Этому компьютеру не удалось установить безопасный сеанс с контроллером домена в домене DOMAIN по следующим причинам:

В настоящее время нет доступных серверов входа для обслуживания запроса на вход.

А также обнаружил ошибку 3210:

Этому компьютеру не удалось пройти аутентификацию в DC, контроллере домена Windows для домена DOMAIN, поэтому этот компьютер может отклонять запросы на вход. Эта невозможность аутентификации может быть вызвана тем, что другой компьютер в той же сети использует то же имя или пароль для этой учетной записи компьютера не распознан. Если это сообщение появится снова, обратитесь к системному администратору.

Мы также потеряли возможность входа в систему с помощью локального администратора, так как пароль был изменен случайным образом.

Netlogon 5719 — это ваша рабочая станция, говорящая "Эй! Я не могу найти контроллер домена в сети для этого домена!!". Само по себе это не означает, что у вас есть проблема, если ваш рабочая станция находит контроллер домена позже, когда у него есть сетевое подключение.

Т.е. это почти всегда проблема с сетевым или DNS-именем, на котором следует сосредоточиться на первоначальном устранении неполадок.

Привет, почти неделю я работаю над этой проблемой, и я решить ее! . У нас есть 400 windows Seven, подключенных к домену с 2003 сервером s008. «Время ожидания обработки политики запуска» выше решает почти все проблемы политики, которые у нас есть. Я установил его на 60 сек. (идентификатор события 1055 и 1058). Теперь единственным событием, которое у нас есть, было даже 5719 NETLOGON при запуске системы. я играю, чтобы попытаться остановить службу teredo без успеха (netst, int teredo, set state disabled). Я также отключаю и удаляю хост-адаптер Teredo с тем же результатом. Я запустил сетевой журнал, и когда я смотрю в журнал, мы видим пару строк перед «[MISC] Eventlog: 5719 (1) «NETBIOS_DOMAIN. " эта строка "[CRITICAL] NlBrowserSendDatagram: No transports available" означает, что носитель не обнаружен. Я решаю проблему, устанавливая свойство сетевой карты "Ждать ссылки" с "Авто" на "Вкл" на моей тележке адаптера.

Вот бонус, если вы хотите применить «Ждать ссылку» через объект групповой политики!

Просто добавьте скрипт vbs в объект групповой политики выключения на вашем компьютере. Возможно, вам потребуется изменить имя описания для вашего nic Mnfgr.

Этот сценарий представляет собой сценарий завершения работы машины, применяемый к объекту групповой политики на всех машинах. Это будет применяться только к компьютерам, на которых установлена сетевая карта Intel.

Надеюсь, это поможет,

Option Explicit
Dim WshShell, bKey
Set WshShell = WScript.CreateObject("WScript.Shell")

Если bKey = "Intel(R) 82578DM Gigabit Network Connection", то
WshShell.RegWrite "HKLM\SYSTEM\CurrentControlSet\Control\Class\\0007\WaitAutoNegComplete" , "1", "REG_SZ"
Еще
WScript.quit
Конец, если

Я заметил, что проблема может быть связана с аппаратным обеспечением сетевой карты.

На всех компьютерах, на которых я экспериментировал с этой проблемой (с соответствующим событием GroupPolicy 1129 и событием службы времени 129), сегодня я обнаружил, что при подключении сетевой карты к небольшому коммутатору 10/100 проблема исчезнет.

Все затронутые ПК имеют встроенную сетевую карту Relateck, у меня нет ПК W7 с сетевой картой другой марки, поэтому я не могу проверить, связана ли проблема с этим семейством адаптеров или это общая проблема Windows.

у кого-нибудь есть решения с момента последнего сообщения. У нас возникла та же проблема, что некоторые ПК не имеют подключения к серверу при запуске, не получают групповые политики и не устанавливают пакеты MSI перед входом в систему.

Это связано с тем, что это затрагивает около 30% ПК, одного типа ПК и установки образа

Здравствуйте! Может быть, это не связано с первоначальной проблемой, но сегодня утром у меня была именно эта ошибка, и в моем случае это было связано с доменом, который когда-то был доверенным, а теперь был удален.

Это решение устранило мою проблему. Я видел, как он периодически появлялся последние 24 месяца или около того на некоторых (но не на всех) сайтах. Решение, которое, как мы знаем, сработало, заключалось в полной перестройке системы, но на самом деле это не исправление. Установка времени ожидания приложения GPO при запуске для каждого КБ, на который ссылается Staffler (KB2421599), мгновенно устранила нашу последнюю проблему. Хотя база знаний рекомендует задержку в 60 секунд, мы установили ее на 20 секунд, и все заработало нормально.

Спасибо, Staffler, это мне очень помогло.

Привет всем, такая же ошибка происходит на одном из моих файловых серверов. При доступе через UNC выдает ошибку: «В настоящее время нет доступных серверов входа в систему для обслуживания запроса на вход». После перезапуска службы Netlogon или сервера ошибка исчезает.Но я ищу постоянное решение для этого. Я надеюсь, что некоторые эксперты могут помочь, для вашей справки; Ниже я предоставил подробную информацию о событии.

Тип события: Ошибка
Источник события: NETLOGON
Категория события: Нет
Идентификатор события: 5719
Дата: 30/03/2016
Время: 9: 28:37
Пользователь: Н/Д
Компьютер: BL-FIS
Описание:
Этому компьютеру не удалось установить безопасный сеанс с контроллером домена в домене из-за на следующее:
В настоящее время нет доступных серверов входа в систему для обслуживания запроса на вход.
Это может привести к проблемам с аутентификацией. Убедитесь, что этот компьютер подключен к сети. Если проблема не устранена, обратитесь к администратору домена.

ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ
Если этот компьютер является контроллером домена для указанного домена, он устанавливает безопасный сеанс для эмулятора основного контроллера домена в указанном домене. В противном случае этот компьютер устанавливает безопасный сеанс с любым контроллером домена в указанном домене.

Тип события: Ошибка
Источник события: NETLOGON
Категория события: Нет
Идентификатор события: 5719
Дата: 30/03/2016
Время: 9: 29:44
Пользователь: Н/Д
Компьютер: BL-FIS
Описание:
Этому компьютеру не удалось установить безопасный сеанс с контроллером домена в домене из-за на следующее:
Сервер RPC недоступен.
Это может привести к проблемам с аутентификацией. Убедитесь, что этот компьютер подключен к сети. Если проблема не устранена, обратитесь к администратору домена.

В этом сообщении блога основное внимание будет уделено настройке безопасного доступа RDP (протокол удаленного рабочего стола) для jumphost/PAW (привилегированная рабочая станция) к DC (контроллеру домена), так что jumphost/PAW является единственным компьютером, который DC будет принимать входящие подключения RDP от. Кроме того, я буду защищать RDP-соединение между хостами с помощью IPSec. Это руководство предназначено для соединений между jumphost/PAW и контроллером домена, но его можно использовать для любых компьютеров Windows Vista/Server 2008 и более поздних версий.

PAW (рабочая станция с привилегированным доступом)
Физическая рабочая станция с максимальным усилением безопасности. Его следует использовать только для управления критически важными серверами, такими как контроллер домена, а повседневная деятельность, такая как электронная почта и просмотр Интернета, должна быть заблокирована, чтобы предотвратить проникновение хакеров через эти пути.

Jumphost (или jump-server/jump-box)

Прыжковый хост — это то же самое, что и PAW, однако переходный хост обычно представляет собой сервер, совместно используемый системными администраторами, тогда как PAW часто представляет собой выделенную физическую рабочую станцию, назначенную каждому администратору. Вы часто будете заходить на jumphost по сети со своей рабочей станции и RDP на критически важный сервер. PAW является лучшим решением для обеспечения безопасности, поскольку принцип чистого исходного кода нарушается с помощью общего сервера, к которому обращается обычная рабочая станция уровня 2. Однако системные администраторы не всегда предпочитают PAW из-за необходимости в дополнительной выделенной рабочей станции.

Содержание этого поста:

а. Протоколы IPSec

б. Режимы работы

<р>в. Установление соединения IPSec

д. IPSec в Windows и Active Directory

а. Объект групповой политики RDP IPSec

б. Входящие ограничения RDP GPO

Перед развертыванием — распространенная проблема при тестировании

Подтвердите соединение IPSec с WDFAS

Подтвердите соединение IPSec с помощью Wireshark

Пропустите разделы 2, 3 и 4, если вы хотите узнать только, как его настроить.

Что такое IPSec?

Безопасность интернет-протокола (IPsec) – это безопасный сетевой протокол, реализованный в виде надстройки в IPv4 для защиты связи. Он обеспечивает конфиденциальность данных, целостность данных и аутентификацию данных между участвующими одноранговыми узлами на уровне IP, что предотвращает попытки олицетворения, фальсификации данных, подслушивания и повторных атак. IPSec интегрирован в брандмауэр Защитника Windows.

Протоколы IPSec

IPSec состоит из следующих двух протоколов:

Заголовок аутентификации (AH)

AH обеспечивает аутентификацию и целостность IP-пакета. Заголовок IP и полезная нагрузка IP хэшируются вместе, и хэш используется для создания заголовка AH, который добавляется к исходному пакету. Если получатель также будет хешировать заголовок IP и полезную нагрузку IP, чтобы проверить, соответствует ли он хешу заголовка AH. Если хэши не совпадают, заголовок или данные должны быть подделаны. Некоторые поля заголовка IP, такие как TTL, исключаются из хэша, так как они будут изменяться в законном трафике.IP-адреса в заголовке IP не исключаются из хэша, поэтому преобразование сетевых адресов (NAT) делает пакет недействительным. Однако NAT-T (обход NAT) для IPSec позволяет использовать транспортный режим и NAT без конфликтов. AH также может предотвратить атаку повторного воспроизведения, требуя порядковый номер в заголовке. Конфиденциальность не обеспечивается, так как IP-пакет не шифруется.

Инкапсуляция полезной нагрузки безопасности (ESP)

ESP обеспечивает конфиденциальность, целостность, защиту от воспроизведения и дополнительную аутентификацию. IP-пакет шифруется с помощью шифрования с симметричным ключом.

Режимы работы

У IPSec есть два режима работы. Оба режима можно использовать с AH, ESP и AH в сочетании с ESP.

Туннельный режим

Весь IP-пакет инкапсулируется внутри другого IP-пакета. В первую очередь он предназначен для обмена данными между сетями или между узлами (например, VPN), но также может использоваться и для обмена данными между узлами.

Недавно у меня был клиент, у которого была относительно свежая среда AD в результате продажи, однако контроллеры домена были включены в разные периоды времени во время сборки среды. Таким образом, у каждого их контроллера домена были разные параметры усиления в зависимости от того, какую сборку они использовали (и какие уровни усиления применялись постепенно с течением времени).

Кроме того, у них было несколько сборок: одна для центров обработки данных, одна для Oracle Cloud, одна для AWS, одна для облака IBM и одна для облака Azure.

Итак, в конечном итоге их компьютеры, входящие в домен, «выпадали из домена» (т.н. NETLOGON 3210):

Моей первой мыслью было попробовать сбросить пароль учетной записи их компьютера, что можно сделать локально через NETDOM (см. ниже):

netdom resetpwd /s:server /ud:domain\User /pd:*

[Примечание: вы должны заменить указанный сервер на имя хоста машины, пароль которой вы сбрасываете; замените домен и пользователя своими учетными данными AD, которым должна быть делегирована привилегия «сбросить пароль» в AD; вы можете ввести *, чтобы получить запрос на ввод пароля, или же ввести пароль после двоеточия]

Команда выполнена успешно, но проблема осталась.

Я продолжил копаться и нашел NETLOGON 5719 в журналах событий члена домена:

Этому компьютеру не удалось установить безопасный сеанс с контроллером домена в домене DOMAIN по следующим причинам:
Удаленный вызов процедуры завершился неудачно и не был выполнен.
Это может привести к проблемам с аутентификацией. Убедитесь, что этот компьютер подключен к сети. Если проблема не устранена, обратитесь к администратору домена.

Поэтому я проверил, чтобы убедиться, что порты RPC контроллера домена не блокируются локальным брандмауэром на основе хоста или аппаратным брандмауэром. Я также перепроверил, что никто не настраивал свои диапазоны портов RPC на контроллерах домена, как это иногда делают компании (в попытке успокоить свои команды по сети/безопасности, которые задыхаются от 16 383 портов в диапазоне по умолчанию, начиная с Windows Vista/2008 — раньше было всего 3985). портов в XP-днях).

Нет, никто не заморачивался с портами RPC контроллера домена… Продолжаю смотреть журнал событий и вижу TIME-SERVICE 130:

Это заставило меня начать искать, что еще может вызвать такие проблемы, и после того, как я прокрутил свои шины в поисках информации, я решил попробовать выполнить NLTEST.

В ответ я получил странную ошибку отказа в доступе:

Флаги: 0
Имя доверенного контроллера домена
Статус подключения к доверенному контроллеру домена = 5 0x5 ERROR_ACCESS_DENIED
Команда выполнена успешно

Хм… странно! Я попытался сбросить соединение с

Похожая ошибка отказа в доступе. Поэтому я начал тестировать каждый контроллер домена по отдельности, вот так:

Я обнаружил, что некоторые контроллеры домена принимают сброс/подключение безопасного канала, а некоторые нет. Я также заметил, что это относится не к одному физическому или облачному местоположению, а скорее к отдельным контроллерам домена.

Я начал лихорадочно сравнивать все локальные параметры безопасности в SECPOL и заметил множество несоответствий (из-за постепенных и непоследовательных усилий по укреплению безопасности в каждой используемой сборке). Я исправил их, перезагрузил контроллер домена и член домена… все равно не повезло.

Поэтому я продолжил просматривать групповую политику и…. ничего. (позже я объясню, почему это важно).

nltest /DBFlag:2080FFFF

Не обязательно перезапускать службу входа в сеть, но вы можете, если хотите:

net stop netlogon && net start netlogon

Затем я повторно выполнил команду SC_RESET на члене домена и проверил журналы:

Обратите внимание, что ошибка связана с «несанкционированным вызовом RPC»... Хм.Я мог бы поклясться, что проверил все настройки как в SECPOL, так и в GPEDIT локально, а также в групповой политике AD. Но я не проверял раздел реестра на контроллерах домена на безопасность RPC. Видите ли, я знал, что это связано с усилением безопасности! (Что, безусловно, хорошо, когда документировано и протестировано должным образом, а не просто разорвано и схвачено, как, к сожалению, большинство мер по усилению безопасности в наши дни сделано)

Регистрационный ключ HKLM:SOFTWARE\Policies\Microsoft\Windows NT\RPC\RestrictRemoteClients имеет значение DWORD:0x00000002.

Я сравнил наличие этого ключа на всех контроллерах домена и обнаружил, что он несовместим между серверами. Таким образом, это означает, что кто-то должен был либо усилить защиту машины с помощью RegKeys, и это не оставило отметки в локальных политиках GPEDIT *ИЛИ*, возможно, оно было в локальном GPEDIT на машине или, возможно, в объектной групповой политике на основе домена, а затем по какой-то причине не связано политика — и настройка застряла. Я не совсем уверен, так как не проверял поведение.

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

Настройка — «Включить аутентификацию клиента RPC Endpoint Mapper», которая, если вы не установите значение «Включено», отключена и, следовательно, использует неаутентифицированные вызовы RPC (поэтому более защищенные контроллеры домена отклоняли вызовы клиентов RPC).

Я включил его и перезагрузил — проблема исчезла. Таким образом, нет никаких компромиссов в отношении безопасности! См. ниже информацию об успешном сбросе/соединении безопасного канала. Виола! Нет больше NETLOGON 3210, NETLOGON 5719 или TIME-SERVER 130. Проблема исправлена 🙂

Я также вернулся и добавил в доменную политику параметр "Ограничить неаутентифицированные RPC-клиенты", чтобы гарантировать, что RPC всегда аутентифицируется клиентами, а серверы RPC (будь то на контроллере домена, рядовом сервере домена или рабочая станция участника). Таким образом, мы на самом деле добились большего, усилив защиту всего домена, чем раньше, устанавливая ключи реестра в сборке и на отдельных серверах.

Параметры безопасности проверки подлинности RPC-клиента и RPC-сервера находятся в одном и том же месте в групповой политике: Компьютер > Административные шаблоны > Система > Удаленный вызов процедур

Настройки на стороне клиента = «Включить аутентификацию клиента RPC Endpoint Mapper»
Настройки на стороне сервера = «Ограничить неаутентифицированные RPC-клиенты»

Также обратите внимание, что RPC является универсальным протоколом в Windows и используется для многих вещей, таких как WinRM, WMI, инструменты MMC, обработка групповой политики AD, MS Exchange и т. д. Таким образом, настройки сервера RPC применяются не только к тому, что мы традиционно рассматривайте серверы, но также и рабочие станции (которые будут действовать как RPC-сервер, если вы подключаетесь через MMC для управления им); кроме того, то, что мы традиционно считаем серверами, также может быть RPC-клиентами (т. е. Exchange Server, взаимодействующий через RPC с контроллером домена для чтения/записи в каталог).

Усвоенный урок состоит в том, что БУДЬТЕ ОСТОРОЖНЫ, ЧТО ВЫ РАЗВЕРТЫВАЕТЕ В СВОИХ СБОРКАХ, ОСТАВЛЯЙТЕ ДОКУМЕНТАЦИЯ И, САМОЕ ГЛАВНОЕ, ПОЛНОСТЬЮ ПРОВЕРЯЙТЕ ВСЕ СВОИ НАСТРОЙКИ УСТОЙЧИВОСТИ. Недостаточно включить компьютер и убедиться, что пользователи все еще могут войти в систему и что приложения все еще работают. Если вы усиливаете защиту определенного аспекта среды или протокола, вам необходимо протестировать влияние на этот протокол и любые приложения или инструменты управления (например, MMC), которые на него полагаются!

[Сноска: из-за множества связанных с этим симптомов мы с клиентом потратили уууууууууу много времени на устранение неполадок, так как мы постоянно отвлекались на все, от DNS до NTP, и обнаружили много других аномалий, которые также нужно было исправить. и привели в соответствие с тем, что стандарты должны были быть вместе. Будьте осторожны, устанавливайте стандарты с самого начала и убедитесь, что все стороны готовы к настройке всего, от сетевых устройств до компьютеров с Windows и Linux, и всегда будьте осторожны с изменениями в ваших сборках!]

ВЫБОРОЧНОЕ ИСКЛЮЧЕНИЕ LdapAuth.login(): НЕВОЗМОЖНО подключиться к основному серверу LDAP: javax.naming.AuthenticationNotSupportedException: [LDAP: код ошибки 8 — 00002028: LdapErr: DSID-0C0901FC, комментарий: для включения сервера требуются привязки проверка целостности, если SSLTLS еще не активны в соединении, данные 0, v1772

Причина

Эта проблема возникает из-за того, что в Active Directory установлена нестандартная политика домена, которая обеспечивает защиту всей аутентификации LDAP с помощью SSL.

Эта политика на контроллере домена: «Контроллер домена: требования к подписи сервера LDAP», и если установлено значение «Требовать подписи», необходимо согласовать параметр подписи данных LDAP, если не используется протокол Transport Layer Security/Secure Socket Layer (TLS/SSL). используется. Это также устанавливает следующий раздел реестра на всех контроллерах домена:

Эта проблема наблюдается много раз после обновления Microsoft.

Разрешение

Есть два способа решить эту проблему:

Способ 1

ПРИМЕЧАНИЕ. Это настройка по умолчанию.

Метод 2

Настройте процесс ESP Adminserver для безопасной связи с сервером LDAP, размещенным на контроллере домена Windows. Для этого необходимо выполнить следующие шаги:

ПРИМЕЧАНИЕ. Для получения необходимого сертификата можно обратиться к группе безопасности Windows.

ПРИМЕЧАНИЕ. 636 — это защищенный порт LDAP (LDAPS).

ПРИМЕР: $JAVA_HOME/bin/keytool -import -alias root -keystore $JAVA_HOME/lib/security/cacerts -trustcacerts -file /ldap-server.cer

ПРИМЕЧАНИЕ. Сертификат добавляется в хранилище доверенных сертификатов JVM по умолчанию $JAVA_HOME/lib/security/cacerts и добавляется с псевдонимом «root».
/ldap-server.cer относится к сертификату SSL, который JVM клиент использует, чтобы доверять серверу LDAP.

ПРИМЕЧАНИЕ. Разница в этом параметре по сравнению с KB2441205 заключается в том, что URL-адрес LDAP меняется на ldaps и порт 636, необходимый для установки безопасного соединения ldap.

ПРИМЕР: выберите «может создавать и удалять пользователей и группы (админ)»:

ПРИМЕЧАНИЕ. Если выбрана аутентификация пользователя с помощью внешней системы управления пользователями, поле «Имя пользователя» должно соответствовать имени пользователя во внешней системе управления пользователями (в данном случае учетной записи пользователя AD). Не требуется заполнять поля электронной почты и пароля для пользователей, прошедших аутентификацию через внешнюю систему управления пользователями.

Читайте также: