Как узнать контроллер домена

Как узнать контроллер домена

Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org. В данной статье, я хочу рассказать, как определить какой контроллер домена вас аутентифицировал. Иногда бывают ситуации, что нужно понять, данную информацию, для поиска проблем. Приведу простой пример, на пользователя была применена политика, которую я отключил на одном из контроллеров, через какое-то время, пользователь обратился, все стем же вопросом, выяснилось, что на другом DC, бала та же политика, отключив ее, все решилось, и в этом помогла информации, о том, кто его аутентифицировал.

И видим, очень информативную выборку.

Как определить какой контроллер домена вас аутентифицировал

Или без лишней воды

Вот такая простоя, но очень полезная команда, и у нее еще очень много полезных функций. С вами был Иван Семин, автор и создатель IT блога pyatilistnik.org.

Популярные Похожие записи:

5 Responses to Как определить какой контроллер домена вас аутентифицировал

данную информацию украли как понять

Это автоматическая ссылка, которая показывает кто и откуда без спроса автора взял его контент.

Кстати, Иван, почитав статейку «Как узнать версию windows, за минуту», я обнаружил еще один способ: в cmd ввести команду systeminfo, в выведенной информации найти строку «Сервер входа в сеть:»
Хочу поблагодарить тебя за твой сайт, очень полезный. Смело его можно рекомендовать к изучению Windows Server.

set logon, set, echo %logonserver% — это все команды, берущие информацию с одной точки — переменной окружения. Можно еще задать set logonserver, берет с той же точки, и показывает за какой DC прицепился при логоне пользователь. А вот nltest /dsgetdc показывает за какой DC зацепился при логоне компьютер. Они могут различаться. И если есть проблемы при общении компа с доменом, то можно проверить их сопряжением командой powershell Test-ComputerSecurityChannel (набрать в окне пошика Test-Co и нажать табуляцию, он сам допишет). Если выдаст False, значит компьютер не может общаться со DC, за который зацепился. Причин может быть много, одна из них — проблемы на стороне DC.

Источник

Get-ADDomainController: получаем информацию о контроллерах домена AD с помощью PowerShell

Командлет Get-ADDomainController можно использовать для получения информации о контроллерах домена в Active Directory. Данный командлет входит в состав модуля Active Directory для PowerShell и требует установки отдельного компонента RSAT (в Windows 10 1809 и выше RSAT устанавливается по-новому).

Командлет Get-ADDomainController

При запуске Get-ADDomainController без параметров командлет выводит информацию о текущем контроллере домена (LogonServer), который используется данным компьютером для аутентификации (DC выбирается при загрузке в соответствии с топологией сайтов AD).

Командлет вернул все поля с информацией о контроллере домена, доступной в AD.

Также вы можете найти контроллер домена, к которому должен относится ваш компьютер через механизм DCLocator:

Вы можете найти ближайший доступный DC с активной ролью AD Web Services:

Параметр Service можно использовать, чтобы найти PDC в домене:

Если ваш контроллер домена не найден или не отвечает, вы можете найти контроллер домена в ближайшем сайте AD (определяется по весу межсайтовых связей):

Чтобы вывести список все контроллеров домена в текущем домене, выполните:

Посчитать количество контроллеров домена в AD можно с помощью команды:

Выведем более удобную таблицу, в которой указаны все контроллеры домена с их именем, IP адресом, версией ОС и именем сайта AD:

Если вам нужно получить информацию о DC из другого домена, нужно указать имя любого доступного DC в стороннем домене с помощью параметра –Server (возможно при наличии доверительных отношений между доменами).

Используем Get-ADDomainController для выборки контроллеров домена по условиям

Рассмотрим несколько полезных командлетов, которые можно использовать для получения списка контролеров домена в AD по определенным критериям.

Найти контроллер домена по его IP адресу:

Найти все DC, в имени которых есть символы DC04:

Поиск всех доступных DC в определенном сайте:

Вывести список DC в сайтах, имена которых начинаются с Mos*:

Найти DC в сайте “Site Name”, на которых включена роль Global Catalog:

PowerShell скрипт проверки доступности всех контроллеров домена

Следующая конструкция позволяет перебрать все контроллеры домена в Active Directory и выполнить для каждого из них определенное действие:

Ниже приведен пример простого PowerShell скрипта, который проверяет доступность LDAPS порта (TCP 636) на каждом DC в домене с помощью командлета Test-NetConnection. Если LDAPS порт на DC не доступен, появляется предупреждение.

Получился простой скрипт мониторинга доступности DC. Ест еще различные сценарии перебора всех DC в домене. В предыдущих статьях мы уже показывали, как использовать Get-ADDomainController для поиска определенного события в журналах на всех контролерах домена. Например, для: поиска события блокировки учетной записи пользователя, поиска событий NTLMv1 аутентификации, поиска событий добавления пользователя в группу AD и т.д.

Источник

PowerShell: системное администрирование и программирование

Всё о PowerShell в Windows и на Linux. Системное администрирование Windows

Get-ADDomainController: получение информации о контроллерах домена через PowerShell

Вы можете использовать командлет PowerShell Get-ADDomainController для получения информации о контроллерах домена в Active Directory. Этот командлет является частью модуля Active Directory для Windows PowerShell, который может быть установлен как на Windows Server, так и на рабочих станциях Windows. Подробности смотрите в статье «Как установить и использовать Модуль Active Directory для Windows PowerShell».

Командлет Get-ADDomainController

Get-ADDomainController выводит информацию об одном или нескольких контроллеров домена Active Directory на основе критериев обнаруживаемых служб, параметров поиска или путём предоставления идентификатора контроллера домена, например имени NetBIOS.

Командлет Get-ADDomainController получает контроллеры домена, указанные в параметрах. Вы можете получить контроллеры домена, используя опции -Identity, -Filter или -Discover.

При запуске Get-ADDomainController без каких-либо параметров командлет отображает информацию о текущем контроллере домена (LogonServer), используемом этим компьютером для проверки подлинности (контроллер домена выбирается в соответствии с топологией IP-подсети сайта AD):

Командлет вернул все поля с информацией о контроллере домена, доступной в базе данных Active Directory.

Примеры использования Get-ADDomainController

Чтобы получить контроллер домена с помощью механизма обнаружения DCLocator, используйте опцию -Discover. Вы можете указать критерии поиска, задав такие опции, как -Service, -SiteName, -DomainName, -NextClosestSite, -AvoidSelf и -ForceDiscover.

Также вы можете найти контроллер домена, которому должен принадлежать ваш компьютер, через службу -DCLocator:

Следующая команда получит один доступный контроллер домена на указанном сайте:

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

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

Вы можете найти ближайший доступный контроллер домена с активной ролью веб-служб AD:

Опция -Service задаёт типы получаемых контроллеров домена. Вы можете указать более одного типа, используя список, разделённый запятыми. Допустимые значения для этого параметра:

Пример использования опции -Service для поиска PDC (Primary Domain Controller Emulator) в вашем домене:

Эта команда ищет компьютер с функцией Глобального каталога в текущем лесу:

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

Если ваш контроллер домена не найден или не отвечает, вы можете найти его на ближайшем сайте AD (определяется весом межсайтовых ссылок):

Чтобы найти и получить более одного контроллера домена, используйте опцию -Filter.

Чтобы отобразить список всех контроллеров домена в текущем домене, выполните такую команду:

Используя следующую команду, вы можете подсчитать количество контроллеров домена в AD:

Вы можете отобразить более удобную таблицу, в которой показаны все контроллеры домена, их имена хостов, IP-адреса, версии ОС и имена сайтов AD:

Использование Get-ADDomainController для поиска контроллеров домена по определенным критериям

Давайте рассмотрим несколько полезных команд, которые вы можете использовать для получения списка контроллеров домена в AD по определенным критериям.

Опция -Identity указывает контроллер домена, который нужно получить. Вы можете идентифицировать контроллер домена по его GUID, IPV4Address, глобальному IPV6Address или имени узла DNS.

Чтобы найти контроллер домена по его IP-адресу:

Эта команда получает контроллер домена, используя его NetBIOS имя.

Эта команда получает контроллер домена, используя его имя хоста DNS, в домене, указанном параметром -Site, указанным в параметре -Server, и с указанием учётных данных администратора.

Чтобы найти все контроллеры домена, в именах которых есть DC02:

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

Чтобы отобразить список всех контроллеров домена только для чтения (RODC):

Чтобы найти контроллеры домена на сайте «Rome» с включённой ролью глобального каталога:

Скрипт PowerShell для проверки доступности всех контроллеров домена

Следующий скрипт PowerShell позволяет поочерёдно проверять контроллеры домена и выполнять для каждого из них определённые действия:

Вот пример простого скрипта PowerShell, который проверяет доступность порта LDAPS (TCP 636) на каждом контроллере домена в вашем домене с помощью командлета Test-NetConnection. Если порт LDAPS недоступен, появится предупреждение.

Получился простой скрипт для отслеживания доступности всех контроллеров домена в вашем домене.

Также существуют разные сценарии для проверки всех контроллеров домена по очереди.

Источник

Передача/захват ролей FSMO на другой контроллер домена Active Directory

В этой статье мы рассмотрим, как определить контроллеры домена с ролями FSMO в Active Directory, способы передачи одной или нескольких FSMO ролей другому контроллеру домена (дополнительному), а также способ принудительного захвата FSMO ролей в случае выхода из строя контроллера домена, которой является владельцем роли.

Для чего нужны FSMO роли в домене Active Directory?

Кратко попытаюсь напомнить для чего нужный роли FSMO (Flexible Single Master Operation, операции с одним исполнителем) в домене Active Directory.

Не секрет, что в Active Directory большинство стандартных операций (таких как заведение новых учетных записей пользователей, групп безопасности, добавление компьютера в домен) можно выполнять на любом контроллере домена. За распространение этих изменений по всему каталогу AD отвечает служба репликации AD. Различные конфликты (например, одновременное переименование пользователя на нескольких контроллерах домена) разрешаются по простому принципу — кто последний тот и прав. Однако есть ряд операций, при выполнении которых недопустимо наличие конфликта (например, при создании нового дочернего домена/леса, изменении схемы AD и т.д). Для выполнения операций, требующих обязательной уникальности нужны контроллеры домена с ролями FSMO. Основная задача ролей FSMO – не допустить конфликты такого рода

Всего в домене Active Directory может быть пять ролей FSMO.

Две уникальные роли для леса AD:

И три роли для каждого домена (для управления этими ролями ваша учетная запись должна состоять в группе “Domain Admins”):

Просмотр владельцев FSMO ролей в домене

Как определить какой контролер домена является хозяином/владельцем конкретной FSMO роли?

Чтобы найти всех владельцев FSMO ролей в домене AD, выполните команду:

Можно просмотреть FSMO роли для другого домена:

netdom query fsmo /domain:contoso.com

В этом примере видно, что все FSMO роли расположены на контроллере домена DC01. При развертывании нового леса AD (домена), все FSMO роли помещаются на первый DC. Любой контроллер домена кроме RODC может быть хозяином любой FSMO роли. Соответственно, администратора домена может передать любую FSMO роль на любой другой контроллер домен.

Можно получить информацию о FSMO ролях в домене через PowerShell с помощью Get-ADDomainController (должен быть установлен модуль Active Directory для PowerShell из состава RSAT):

Или можно получить FSMO роли уровня леса и уровня домена так:

Get-ADDomain | Select-Object InfrastructureMaster, RIDMaster, PDCEmulator
Get-ADForest | Select-Object DomainNamingMaster, SchemaMaster

Общие рекомендации Microsoft по размещении FSMO ролей на контроллерах домена:

В Active Directory вы можете передать FSMO роли несколькими способами: с помощью графических mmc оснасток AD, с помощью утилиты ntdsutil.exe или через PowerShell. О переносе ролей FSMO обычно задумываются при оптимизации инфраструктуры AD, при выводе из эксплуатации или поломке контроллера домена с ролью FSMO. Есть два способа передачи FSMO ролей: добровольный (когда оба DC доступны) или принудительный (когда DC с ролью FSMO недоступен/вышел из строя)

Передача FSMO ролей с помощью PowerShell

Самый простой и быстрый способ передачи FSMO ролей в домене – PowerShell командлет Move-ADDirectoryServerOperationMasterRole.

Вы можете передать на указанный DC одну или несколько FSMO ролей за раз. Следующая команда выполнит передачу двух ролей на DC02:

В аргументе OperationMasterRole можно указать как имя FSMO роли, так и ее индекс в соответствии с таблицей:

Предыдущая команда в более коротком виде выглядит так:

А чтобы передать сразу все FSMO роли на дополнительный контроллер домена, выполните:

Передача FSMO ролей из графических оснасток Active Directory

Для переноса FSMO ролей можно использовать стандартные графические оснастки Active Directory. Операцию переноса желательно выполнять на DC с FSMO ролью. Если же консоль сервера не доступна, необходимо выполнить команду Change Domain Controller и выбрать контроллер домена в mmc-оснастке.

Передача ролей RID Master, PDC Emulator и Infrastructure Master

Для передачи ролей уровня домена (RID, PDC, Infrastructure Master) используется стандартная консоль Active Directory Users and Computers (DSA.msc)

Передача роли Schema Master

Для переноса FSMO уровня леса Schema Master используется оснастка Active Directory Schema.

Передача FSMO роли Domain naming master

Передача FSMO ролей из командной строки с помощью утилиты ntdsutil

Принудительный захват FSMO ролей Active Directory

Если DC с одной из FSMO ролью вышел из строя (и его не возможно восстановить), или недоступен длительное время, вы можете принудительно перехватить у него любую из FSMO ролей. Но при этом крайне важно убедиться, что сервер, у которого забрали FSMO роль никогда не должен появится в сети, если вы не хотите новых проблем с AD (даже если вы позднее восстановите DC из резервной копии). Если вы захотите вернуть потерянный сервер в домен, единственный правильный способ – удаление его из AD, чистая переустановка Windows под новым именем, установка роли ADDS и повышение сервера до контроллера домена

Вы можете принудительно захватить FSMO роли с помощью PowerShell или утилиты NTDSUtil.

Проще всего захватить FSMO роль через PowerShell. Для этого используется тот-же самый командлет Move-ADDirectoryServerOperationMasterRole, что и для переноса роли, но добавляется параметр –Force.

Например, чтобы захватить роль PDCEmulator и принудительно передать ее на DC02, выполните:

Также вы можете перенести роли FSMO на сервер DC02 с помощью утилиты ntdsutil. Процедура захвата роли через ntdsutil похожа на обычную передачу. Используйте следующие команды:

ntdsutil
roles
connections
connect to server DC02 (на этот сервер вы перенесете роль)
quit

Для захвата различных ролей FSMO используйте команды:
seize schema master
seize naming master
seize rid master
seize pdc
seize infrastructure master
quit

Источник

Как найти контроллер домена в сети

Найти имя контроллера домена Active Directory

Как узнать имя /IP-адрес контроллера домена AD в моей сети?

7 ответов

На любом компьютере, настроенном DNS для DNS-сервера AD, выполните следующие действия:

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

Вернет все переменные среды, начинающиеся с «L», включая имя DC.

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

Просто замените имя домена на свой домен

Вы также можете запустить несколько других опций, чтобы узнать больше:

/dcname:domainname получает имя PDC для домена /dsgetdc:domainname содержит флажки для другой информации

Попробуйте nltest /? в вашем приглашении, чтобы получить больше опций! 🙂

Это вернет ваш ближайший контроллер домена в Powershell:

DNS и DHCP — лучший способ проверить, поскольку в сети могут быть компьютеры Unix /Linux, управляемые контроллером домена AD или действующие в качестве контроллера домена.

Плюс, учитывая, что активный каталог является не чем иным, как версией Microsoft Kerberos, LDAP, dhcp и dns. Было бы лучше понять и отладить вещи на более низких уровнях, чем слой 7+. Это связано с тем, что операционная система будет предировать эти же запросы, а подчеркивание RFC для каждого протокола фактически работает на уровне OSI, а не в «вставке любимого инструмента здесь».

Затем, используя dns для проверки _kerberos._tcp, _kpasswd._tcp, _LDAP._TCP.dc._msdcs и _ldap._tcp SRV записей:

Это разбивается на три области: две поддерживаемые протоколом записи DNS-SD:

Crude CMD

Просто найдите имена DC

Сохранить как GetDcNames.cmd :

(Примечание: конечная точка в «% userdnsdomain%.» предназначена специально. Она останавливает ваш локальный nslookup с использованием любых строк пути поиска DNS.)

Найти больше доменов DNS, связанных с AD

Я взломал быстрый и грязный пакетный файл, так что мне не нужно запоминать имена доменов DNS и /или им нужно набирать их все. (Список может быть неполным.)

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

Как определить какой контроллер домена вас аутентифицировал

Как определить какой контроллер домена вас аутентифицировал

Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org. В данной статье, я хочу рассказать, как определить какой контроллер домена вас аутентифицировал. Иногда бывают ситуации, что нужно понять, данную информацию, для поиска проблем. Приведу простой пример, на пользователя была применена политика, которую я отключил на одном из контроллеров, через какое-то время, пользователь обратился, все стем же вопросом, выяснилось, что на другом DC, бала та же политика, отключив ее, все решилось, и в этом помогла информации, о том, кто его аутентифицировал.

И видим, очень информативную выборку.

Как определить какой контроллер домена вас аутентифицировал

Или без лишней воды

Вот такая простоя, но очень полезная команда, и у нее еще очень много полезных функций. С вами был Иван Семин, автор и создатель IT блога pyatilistnik.org.

Популярные Похожие записи:

5 Responses to Как определить какой контроллер домена вас аутентифицировал

данную информацию украли как понять

Это автоматическая ссылка, которая показывает кто и откуда без спроса автора взял его контент.

Кстати, Иван, почитав статейку «Как узнать версию windows, за минуту», я обнаружил еще один способ: в cmd ввести команду systeminfo, в выведенной информации найти строку «Сервер входа в сеть:»
Хочу поблагодарить тебя за твой сайт, очень полезный. Смело его можно рекомендовать к изучению Windows Server.

set logon, set, echo %logonserver% — это все команды, берущие информацию с одной точки — переменной окружения. Можно еще задать set logonserver, берет с той же точки, и показывает за какой DC прицепился при логоне пользователь. А вот nltest /dsgetdc показывает за какой DC зацепился при логоне компьютер. Они могут различаться. И если есть проблемы при общении компа с доменом, то можно проверить их сопряжением командой powershell Test-ComputerSecurityChannel (набрать в окне пошика Test-Co и нажать табуляцию, он сам допишет). Если выдаст False, значит компьютер не может общаться со DC, за который зацепился. Причин может быть много, одна из них — проблемы на стороне DC.

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

Восстанавливаем доверительные отношения в домене

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

Учетные записи компьютеров, также, как и учетные записи пользователей, являются участниками безопасности домена. Каждому участнику безопасности автоматически присваивается идентификатор безопасности (SID) на уровне которого осуществляется доступ к ресурсам домена.

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

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

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

Доверительные отношения нарушаются в том случае, если компьютер пытается аутентифицироваться в домене с недействительным паролем. Как такое может произойти? Самый простой способ — это откатить состояние компьютера, например, штатной утилитой восстановления системы. Такой же эффект может быть достигнут при восстановлении из образа, снапшота (для виртуальных машин) и т.п.

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

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

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

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

Пользователи и компьютеры Active Directory

Это самый простой, но не самый быстрый и удобный способ. Открываем на любом контроллере домена оснастку Пользователи и компьютеры Active Directory, находим необходимую учетную запись компьютера и, щелкнув правой кнопкой мыши, выбираем Переустановить учетную запись.

Затем входим на потерявшем доверительные отношения компьютере под локальным администратором и выводим машину из домена.

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

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

Утилита Netdom

Данная утилита входит в состав Windows Server начиная с редакции 2008, на пользовательские ПК ее можно установить из состава пакета RSAT (Средства удаленного администрирования сервера). Для ее использования войдите на целевой системе локальным администратором и выполните команду:

Разберем опции команды:

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

Командлет PowerShell 3.0

В отличие от утилиты Netdom, PowerShell 3.0 входит в состав системы начиная с Windows 8 / Server 2012, для более старых систем его можно установить вручную, поддерживаются Windows 7, Server 2008 и Server 2008 R2. В качестве зависимости требуется Net Framework не ниже 4.0.

Точно также войдите на системе, для которой нужно восстановить доверительные отношения, локальным администратором, запустите консоль PowerShell и выполните команду:

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

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

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

ИТ База знаний

Полезно

— Узнать IP — адрес компьютера в интернете

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Калькулятор инсталляции IP — АТС Asterisk

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Популярное и похожее

Пошаговый ввод в домен Windows 10

Погружение в Iptables – теория и настройка

Фиксируем проблему SQL Error 233

Apache Maven – установка и настройка

Создание доменного пользователя и ввод компьютера в домен

В прошлой статье мы создали и настроили контроллер домена (DC), настало время наполнить наш домен пользователями и рабочими станциями.

Конфигурация

Открываем Server Manager и выбираем опцию Roles.

Из доступных ролей выбираем недавно установленную — Active Directory Domain Services, далее Active Directory Users and Computers и находим созданный нами домен (в нашем случае — merionet.loc). В выпадающем списке объектов находим Users и кликаем по данной опции правой кнопкой мыши и выбираем New → User.

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

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

Далее, нас просят ввести пароль для новой учетной записи и выбрать дополнительные опции:

После того, как все данные будут заполнены, нас попросят подтвердить создание нового объекта.

Отлично, новый пользователь домена создан. Теперь нам нужно зайти на компьютер пользователя и ввести его в домен. Для этого логинимся на компьютер пользователя с локальными учетными данными и открываем Свойства компьютера. Как видите, наш компьютер пока еще не стал частью домена, он ещё является частью рабочей группы WORKGROUP/. Убедитесь, что компьютер пользователя имеет версию Windows не ниже Professional. Чтобы ввести его в домен выбираем Change Settings

Важно! Поддержка доменной инфраструктуры начинается только с версии Windows Professional. На версиях Starter, Home Basic, Home Premium подключиться к домену не получится!

Далее напротив опции «To rename this computer or change its domain or workgroup, click Change» нажимаем собственно Change

Важно! Для того, чтобы наш компьютер узнал о существующем контроллере домена нам нужно указать ему на DNS сервер, который имеет такую информацию. В нашем случае – контроллер домена является по совместительству DNS сервером для пользовательских машин. Поэтому мы указываем контроллер домена в качестве DNS сервера для настраиваемого компьютера.

Далее в открывшемся окне в опции «Member of» вместо Workgroup выбираем Domain и вводим имя нашего домена (в нашем случае – merionet.loc)

Далее нас попросят ввести учетные данные для учетной записи, которая уже создана и имеет право присоединиться к домену. Вводим учетные данные ранее созданного пользователя.

Если все было сделано корректно, то мы увидим сообщение, свидетельствующее о том, что наш компьютер теперь является частью домена (в нашем случае — merionet.loc)

После чего, нас попросят перезагрузить компьютер для применения изменений.

После перезагрузки, мы можем логиниться уже с учетными данными доменного пользователя.

Теперь, если мы откроем свойства компьютера, то увидим, что наш компьютер принадлежит домену (в нашем случае – merionet.loc)

Полезна ли Вам эта статья?

Пожалуйста, расскажите почему?

Нам жаль, что статья не была полезна для вас 🙁 Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

Подпишитесь на нашу еженедельную рассылку, и мы будем присылать самые интересные публикации 🙂 Просто оставьте свои данные в форме ниже.

Настройка Active Directory Domain Services

Если вам интересна тематика Windows Server, рекомендую обратиться к тегу Windows Server на моем блоге. Также рекомендую ознакомиться с основной статье по Active Directory — Active Directory Domain Services

Подготовка окружения

Разворачивать роль AD я планирую на двух виртуальных серверах (будущих контроллерах домена) по очереди.

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

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

Вообще сам подход к администрированию виртуализованных контроллеров домена отличается в виду некоторых особенностей функционирования AD DS 4 5 :

Виртуальные среды представляют особую трудность для распределенных рабочих потоков, зависящих от логической схемы репликации по времени. Например, репликация AD DS использует равномерно увеличивающееся значение (которое называется USN, или номер последовательного обновления), назначенное транзакциям в каждом контроллере домена. Каждый экземпляр базы данных контроллера домена также получает идентификатор под названием InvocationID. InvocationID контроллера домена и его номер последовательного обновления вместе служат уникальным идентификатором, который связан с каждой транзакцией записи, выполняемой на каждом контроллере домена, и должны быть уникальны в пределах леса.

На этом основные шаги по подготовке окружения завершены, переходим к этапу установки.

Установка Active Directory

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

Сам процесс установки претерпел некоторые изменения 6 по сравнению с предыдущими версиями ОС:

Развертывание доменных служб Active Directory (AD DS) в Windows Server 2012 стало проще и быстрее по сравнению с предыдущими версиями Windows Server. Установка AD DS теперь выполняется на основе Windows PowerShell и интегрирована с диспетчером серверов. Сократилось количество шагов, необходимых для внедрения контроллеров домена в существующую среду Active Directory.

Необходимо выбрать только роль Доменные службы Active Directory, никакие дополнительные компоненты устанавливать не нужно. Процесс установки занимает незначительно время и можно сразу переходить к настройке.

Настройка Active Directory

Когда установится роль, справа вверху Server Manager вы увидите восклицательный знак — требуется провести конфигурацию после развертывания. Нажимаем Повысить роль этого сервера до контроллера домена.

Далее весь процесс будет проходить в мастере настройки.

Повышение роли сервера до контроллера домена

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

После этого сервер самостоятельно перезагрузится.

Создание учетных записей администраторов домена/предприятия

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

Сразу же рекомендую настроить и иерархию организации (только не используйте русские символы!).

Настройка DNS на единственном DC в домене

Во время установки AD также была установлена роль AD DNS, поскольку других серверов DNS у меня в инфраструктуре не было. Для правильно работы сервиса необходимо изменить некоторые настройки. Для начала нужно проверить предпочитаемые серверы DNS в настройках сетевого адаптера. Необходимо использовать только один DNS-сервер с адресом 127.0.0.1. Да, именно localhost. По умолчанию он должен прописаться самостоятельно.

Убедившись в корректности настроек, открываем оснастку DNS. Правой кнопкой нажимаем на имени сервера и открываем его свойства, переходим на вкладку «Сервер пересылки». Адрес DNS-сервера, который был указан в настройках сети до установки роли AD DS, автоматически прописался в качестве единственного сервера пересылки:

Необходимо его удалить и создать новый и крайне желательно, чтобы это был сервер провайдера, но никак не публичный адрес типа общеизвестных 8.8.8.8 и 8.8.4.4. Для отказоустойчивости пропишите минимум два сервера. Не снимайте галочку для использования корневых ссылок, если нет доступных серверов пересылки. Корневые ссылки — это общеизвестный пул DNS-серверов высшего уровня.

Добавление второго DC в домен

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

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

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

Настройка DNS на нескольких DC в домене

Для предупреждения проблем с репликацией нужно снова изменить настройки сети и делать это необходимо на каждом контроллере домена (и на существовавших ранее тоже) и каждый раз при добавлении нового DC:

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

Настройка времени

Этот этап нужно выполнить обязательно, особенно если вы настраиваете реальное окружение в продакшене. Как вы помните, ранее я отключил синхронизацию времени через гипервизор и теперь нужно её настроить должным образом. За распространение правильного время на весь домен отвечает контроллер с ролью FSMO PDC эмулятор (Не знаете что это такая за роль? Читайте статью PDC emulator — Эмулятор первичного контроллера домена). В моем случае это конечно же первый контроллер домена, который и является носителем всех ролей FSMO изначально.

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

Назовите её как считаете нужным и как объект будет создан, нажмите правой кнопкой — Изменить. Переходим в Конфигурация компьютераПолитикиАдминистративные шаблоныСистемаСлужба времени WindowsПоставщики времени. Активируем политики Включить NTP-клиент Windows и Включить NTP-сервер Windows, заходим в свойства политики Настроить NTP-клиент Windows и выставляем тип протокола — NTP, остальные настройки не трогаем:

Дожидаемся применения политик (у меня это заняло примерно 5-8 минут, несмотря на выполнение gpupdate /force и пару перезагрузок), после чего получаем:

Вообще надо сделать так, чтобы время с внешних источников синхронизировал только PDC эмулятор, а не все контроллеры домена под ряд, а будет именно так, поскольку групповая политика применяется ко всем объектам в контейнере. Нужно её перенацелить на конкретный объект учетной записи компьютера-владельца роли PDC-эмулятор. Делается это также через групповые политики — в консоли gpmc.msc нажимаем левой кнопкой нужную политику и справа у вас появятся её настройки. В фильтрах безопасности нужно добавить учетную запись нужного контроллера домена:

На этом настройка времени, а вместе с ней и начальная настройка Active Directory, завершена.

Источник