Как узнать, к какому контроллеру домена подключен компьютер
Обновлено: 21.11.2024
В некоторых случаях вам нужно определить, на каком контроллере домена вы прошли аутентификацию. Это может быть полезно по ряду причин, таких как устранение неполадок групповой политики, медленный вход в систему, проблемы с приложениями, подключение сетевых дисков или принтеров и т. д.
Например, недавно я столкнулся с проблемой, из-за которой единый вход не работал для нескольких приложений. Я устранял проблему с несколькими виртуальными рабочими столами и заметил, что единый вход работает на одном из них. Я подумал, что это странно, учитывая, что все виртуальные рабочие столы были одинаковыми. Именно тогда я проверил, на каком контроллере домена он прошел аутентификацию, и заметил, что это был DC2, а все остальные — DC1.
Как проверить сервер входа
Вы можете проверить сервер входа в систему с помощью командной строки или PowerShell.
Вариант 1. Использование командной строки
Откройте командную строку, введите команду ниже и нажмите Enter
На снимке экрана выше я выполнил аутентификацию на контроллере домена DC2. Команда set l отображает все из команды set, которая начинается с l, поэтому она также отображает данные локального приложения. Вы можете просто ввести set logon, чтобы увидеть только сервер входа в систему.
Вариант 2. Использование PowerShell
Откройте PowerShell, введите приведенную ниже команду и нажмите клавишу ввода
Поиск применения групповой политики контроллера домена
Если вам нужно узнать, с какого контроллера домена компьютер или пользователь применил параметры своей групповой политики, запустите команду gpresult /r.
На снимке экрана выше видно, что групповая политика была применена из DC2.
Обязательно проверьте раздел настроек пользователя, так как политика может применяться с другого контроллера домена.
Рекомендуется: средство очистки Active Directory
Выявление и удаление неактивных учетных записей пользователей и компьютеров в сети Active Directory.
Поиск по всему домену или ограничение поиска определенной группой или подразделением. Вы можете массово отключить и переместить учетные записи в другую организационную единицу. Найдите отключенные аккаунты, пустые группы и многое другое.
Здравствуйте, у меня есть вопрос о том, как узнать, к какому контроллеру домена я подключен. Я знаю 2 разные команды. 1 — команда echo %logonserver%, а другая — команда nltest /dsgetdc. Когда я запускаю их, я получаю 2 разных результата контроля домена. Одна из этих команд предназначена для профиля компьютера, а другая — для профиля пользователя?
алекс32165
Угрозы кибербезопасности и потребность в надежном резервном копировании
2022-03-29 18:00:00 UTC Вебинар Вебинар: Spanning — угрозы кибербезопасности и потребность в надежном резервном копировании Сведения о событии Просмотреть все события
17 ответов
ДжакЛАМБЕРТ
В проводнике просто введите %logonserver%
cmd.exe > эхо %logonserver%
или установить bginfo
OP alex32165
Хорошо, я знаю о команде logonserver, но я пытаюсь понять разницу между ней и командой nltest /dsgetdc и почему она дает другой результат.
ГуруГейб1
Будет ли последним результатом ваш основной контроллер домена?
alex32165 написал:
хорошо, я знаю о команде logonserver, но я пытаюсь понять разницу между ней и командой nltest /dsgetdc и почему она дает другой результат.< /p>
На первый взгляд, /dsgetdc возвращает эмулятор pdc, logonserver — это контроллер домена, с которым вы выполняете аутентификацию в текущем сеансе.
Или из командной строки C:\> установите L
чтобы получить сервер входа
OP alex32165
GuruGabe1 написал:
Будет ли последним результатом ваш PDC?
Нет, NLtest не отображает мой PDC.
ббигфорд
momurda написал:
cmd.exe > echo %logonserver%
или установить bginfo
Я часто использую его.
Я получаю одно и то же, два разных результата (оба контроллера домена) из двух разных команд, но я тоже не знаю почему.
адриан_йч
Какие ОС у вас на контроллерах домена?
Вы можете получить разные результаты, так как один должен проверить, какой контроллер домена доступен, а другой — проверить, на каком контроллере домена зарегистрирована машина.
Тогда также в зависимости от того, как параметры DNS установлены в обоих контроллерах домена (циклический или нет), не должно иметь особого значения, в какой контроллер домена входят компьютеры, поскольку предполагается, что контроллеры домена работают как HA и FT (если есть 2 правильно настроены или несколько контроллеров домена).
alex32165 написал:
хорошо, я знаю о команде logonserver, но я пытаюсь понять разницу между ней и командой nltest /dsgetdc и почему она дает другой результат.< /p>
Ответ заключается в том, что nltest не возвращает контроллер домена, в который вы вошли.
Рупеш (Лепид)
Представитель бренда Lepide
Вы можете запустить "echo %logonserver%" в командной строке, чтобы просмотреть текущий подключенный контроллер домена.
Для определения DC компьютера/сервера используйте NLTEST:
Чтобы перечислить все DC с их соответствующими сайтами, попробуйте:
Черная информация73
Как поясняется в приведенной ниже ссылке, nltest с переключателем dsgetdc — лучший вариант
Грифф_389
Я просто использую "set" из командной строки и проверяю переменную logonserver.
Или, как указывалось ранее, введите "set L", чтобы получить только переменные, начинающиеся с L (или "set Log", чтобы быть более точным).
Я всегда использовал команду Set на локальных рабочих станциях.
На серверах мне нравится nltest /DSGETDC. Чтобы получить больше опций, введите nltest /? если вам действительно нужно во всем разобраться.,
Команда SET возвращает значение с момента его установки, то есть оно не является динамическим. Таким образом, в случае нескольких контроллеров домена (и вероятности того, что вы переключились на новый) это может ввести в заблуждение.
Эта тема заблокирована администратором и больше не открыта для комментариев.
Чтобы продолжить это обсуждение, задайте новый вопрос.
Что бы вы сделали?
Итак, я работаю в MSP, который работает круглосуточно и без выходных. Старший инженер в нежелательную смену с 23:00 до 8:00 уходит. Теперь у меня есть возможность перейти на эту должность, насколько больше это потребует компенсации в процентах от того, что я зарабатываю сейчас? и я скажу это.
Щелкни! Lapsus$, Excel RAT, Honda Hackers, Lunar Landers, Windows Easter Egg
Ваша ежедневная доза технических новостей. Вы должны это услышать. Подозреваемые Lapsus$ арестованы за взломы Microsoft, Nvidia, Okta. Больше информации о группе Lapsus$, ответственной за ряд недавних кибератак. Несколько из группы».
Искра! Серия Pro — 25 марта 2022 г.
Friday Из бесплатной энциклопедии Википедии. Другие значения см. в Friday (значения). Пятница — день недели между четвергом и субботой. В странах, принимающих обычай "понедельник-первый".
В этой статье описывается механизм, используемый Windows для обнаружения контроллера домена в домене Windows.
Эта статья относится к Windows 2000. Поддержка Windows 2000 заканчивается 13 июля 2010 г. Центр решений по окончанию поддержки Windows 2000 является отправной точкой для планирования стратегии перехода с Windows 2000. Дополнительные сведения см. Политика жизненного цикла поддержки Майкрософт.
Применимо к: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Исходный номер базы знаний: 247811
Обзор
В этой статье подробно описывается процесс обнаружения домена по его имени в стиле DNS и его простому имени (NetBIOS). Имя в плоском стиле используется для обратной совместимости. Во всех остальных случаях следует использовать имена в стиле DNS в соответствии с политикой. В этой статье также рассматривается устранение неполадок в процессе определения местоположения контроллера домена.
Как Locator находит контроллер домена
Эта последовательность описывает, как локатор находит контроллер домена:
На клиенте (компьютере, на котором находится контроллер домена) локатор запускается как удаленный вызов процедуры (RPC) для локальной службы входа в сеть. Вызов интерфейса прикладного программирования (API) Locator DsGetDcName реализуется службой Netlogon.
Клиент собирает информацию, необходимую для выбора контроллера домена. Затем он передает информацию службе входа в сеть с помощью вызова DsGetDcName.
Служба Netlogon на клиенте использует собранную информацию для поиска контроллера домена для указанного домена одним из двух способов:
Для DNS-имени Netlogon запрашивает DNS с помощью локатора, совместимого с IP/DNS. То есть DsGetDcName вызывает вызов DnsQuery для чтения записей ресурсов службы (SRV) и записей "A" из DNS после добавления доменного имени к соответствующей строке, указывающей записи SRV.
Рабочая станция, которая входит в домен Windows, запрашивает у DNS записи SRV в общем виде:
Серверы Active Directory предлагают службу облегченного протокола доступа к каталогам (LDAP) по протоколу TCP. Таким образом, клиенты находят сервер LDAP, запрашивая у DNS запись вида:
Для NetBIOS-имени Netlogon выполняет обнаружение контроллера домена с помощью локатора, совместимого с Microsoft Windows NT версии 4.0. То есть с помощью механизма, специфичного для транспорта, такого как WINS.
В Windows NT 4.0 и более ранних версиях "обнаружение" — это процесс поиска контроллера домена для проверки подлинности либо в основном домене, либо в доверенном домене.
Служба Netlogon отправляет дейтаграммы на компьютеры, зарегистрировавшие это имя. Для доменных имен NetBIOS дейтаграмма реализована как сообщение почтового ящика. Для доменных имен DNS дейтаграмма реализована как поиск по протоколу пользовательских дейтаграмм (UDP) LDAP. (UDP – это протокол передачи дейтаграмм без установления соединения, входящий в набор протоколов TCP/IP. TCP – это транспортный протокол, ориентированный на установление соединения.)
Каждый доступный контроллер домена отвечает на дейтаграмму, чтобы указать, что он в настоящее время работает, и возвращает информацию в DsGetDcName.
UDP позволяет программе на одном компьютере отправлять дейтаграмму программе на другом компьютере. UDP включает номер порта протокола, который позволяет отправителю различать несколько получателей (программ) на удаленном компьютере.
- Каждый доступный контроллер домена отвечает на дейтаграмму, чтобы указать, что он в настоящее время работает, и возвращает информацию в DsGetDcName.
- Служба Netlogon кэширует информацию о контроллере домена, чтобы последующие запросы не повторяли процесс обнаружения. Кэширование этой информации способствует согласованному использованию одного и того же контроллера домена и единообразному представлению Active Directory.
Когда клиент входит в систему или присоединяется к сети, он должен иметь возможность найти контроллер домена. Клиент отправляет запрос DNS Lookup в DNS, чтобы найти контроллеры домена, предпочтительно в собственной подсети клиента. Таким образом, клиенты находят контроллер домена, запрашивая у DNS запись вида:
После того как клиент находит контроллер домена, он устанавливает связь с помощью LDAP для получения доступа к Active Directory. В рамках этого согласования контроллер домена определяет, на каком сайте находится клиент, на основе IP-подсети этого клиента.
Если клиент обменивается данными с контроллером домена, который не находится на ближайшем (наиболее оптимальном) сайте, контроллер домена возвращает имя сайта клиента. Если клиент уже пытался найти контроллеры домена на этом сайте, клиент использует неоптимальный контроллер домена. Например, клиент отправляет DNS-запрос поиска в DNS, чтобы найти контроллеры домена в подсети клиента.
В противном случае клиент снова выполняет поиск DNS для конкретного сайта с новым оптимальным именем сайта. Контроллер домена использует некоторую информацию службы каталогов для идентификации сайтов и подсетей.
После того как клиент находит контроллер домена, запись контроллера домена кэшируется. Если контроллер домена находится не на оптимальном сайте, клиент очищает кеш через 15 минут и отбрасывает запись кеша. Затем он пытается найти оптимальный контроллер домена на том же сайте, что и клиент.
После того как клиент установил путь связи с контроллером домена, он может установить учетные данные для входа и аутентификации. А при необходимости для компьютеров на базе Windows может настроить безопасный канал. После этого клиент готов выполнять обычные запросы и искать информацию в каталоге.
Клиент устанавливает соединение LDAP с контроллером домена для входа в систему. В процессе входа в систему используется диспетчер учетных записей безопасности. Путь связи использует интерфейс LDAP, и клиент аутентифицируется контроллером домена. Таким образом, учетная запись клиента проверяется и передается через диспетчер учетных записей безопасности агенту службы каталогов, затем на уровень базы данных и, наконец, в базу данных в механизме расширяемого хранилища (ESE).
Устранение неполадок в процессе поиска доменов
Чтобы устранить неполадки в процессе поиска доменов:
Проверьте средство просмотра событий как на клиенте, так и на сервере. Журналы событий могут содержать сообщения об ошибках, указывающие на наличие проблемы. Чтобы просмотреть средство просмотра событий, выберите «Пуск», выберите «Программы» > «Администрирование», а затем выберите «Просмотр событий». Проверьте системный журнал как на клиенте, так и на сервере. Также проверьте журналы службы каталогов на сервере и журналы DNS на DNS-сервере.
Проверьте конфигурацию IP с помощью команды ipconfig /all в командной строке.
Используйте утилиту Ping для проверки подключения к сети и разрешения имен. Пропингуйте как IP-адрес, так и имя сервера. Вы также можете проверить связь с доменным именем.
Используйте средство Netdiag, чтобы определить, правильно ли работают сетевые компоненты. Чтобы отправить подробный вывод в текстовый файл, используйте следующую команду:
netdiag /v >test.txt
Просмотрите файл журнала, найдите проблемы и изучите любые связанные компоненты. Этот файл также содержит другие сведения о конфигурации сети.
Для устранения мелких проблем используйте средство Netdiag со следующим синтаксисом:
Используйте команду nltest /dsgetdc:domainname, чтобы убедиться, что контроллер домена может быть расположен для определенного домена.
Используйте инструмент NSLookup, чтобы убедиться, что записи DNS правильно зарегистрированы в DNS. Убедитесь, что записи узла сервера и записи GUID SRV могут быть разрешены.
Если ни одна из этих команд не выполняется, используйте один из следующих методов для перерегистрации записей в DNS:
- Чтобы принудительно зарегистрировать запись хоста, введите ipconfig /registerdns.
- Чтобы принудительно зарегистрировать службу контроллера домена, остановите и снова запустите службу Netlogon.
Чтобы обнаружить проблемы с контроллером домена, запустите утилиту DCdiag из командной строки. Утилита запускает множество тестов, чтобы убедиться, что контроллер домена работает правильно. Используйте эту команду для отправки результатов в текстовый файл: dcdiag /v >dcdiag.txt
Используйте средство Ldp.exe для подключения и привязки к контроллеру домена, чтобы проверить правильность подключения LDAP.
Если вы подозреваете, что у конкретного контроллера домена есть проблемы, может быть полезно включить ведение журнала отладки Netlogon. Используйте утилиту NLTest, введя следующую команду: nltest /dbflag:0x2000ffff. Затем информация записывается в папку Debug в файле Netlogon.log.
Если вы все еще не изолировали проблему, используйте сетевой монитор для мониторинга сетевого трафика между клиентом и контроллером домена.
Ссылки
Дополнительную информацию см. в наборе ресурсов Windows, глава 10, "Диагностика Active Directory, устранение неполадок и восстановление".
Windows Server — как определить, какой контроллер домена аутентифицировал пользователя
Нравится этот блог 1
На этой неделе в классе возник вопрос, который мне задают довольно часто, когда я провожу занятия по Active Directory. Будь то класс администрирования Active Directory или класс расширенного проектирования, меня спрашивают: «У меня есть пользователь, который вошел в систему. Я не думаю, что они получили правильные настройки GPO, есть ли способ определить, какой контроллер домена аутентифицировал их?"
Ответ: «Да!» Ты сможешь. Вот как.
Попросите вошедшего в систему пользователя запустить командную строку на целевом компьютере. Введите Set Logonserver, и будет возвращено имя контроллера домена, который аутентифицировал пользователя. См. рисунок ниже.
Использование echo %username% позволит вам создать сценарий для идентификации аутентифицирующего контроллера домена. См. рисунок ниже.
Если вы просто хотите определить, с какого контроллера домена пользователь получил групповые политики, вы можете ввести gpresult /r. В возвращенных результатах будет указано имя контроллера домена, который предоставил вошедшему в систему пользователю объекты групповой политики. См. рисунок ниже.
Как видите, существует несколько способов определить, какой контроллер домена аутентифицировал пользователя.
Читайте также: