Как Windows определяет ближайший контроллер домена?
За определение LogonServer при загрузке Windows отвечает служба NetLogon. Она должны быть запущена:
Упрощенно процесс поиска контроллера домена клиентом Windows выглядит так:
- При загрузке Windows служба NetLogon делает DNS запрос за списком контроллеров домена (SVR записи
; - DNS возвращает список DC в домене;
- Клиент делает LDAP запрос к DC для определения сайта AD по-своему IP адресу;
- DC возвращает сайт, которому соответствует IP клиента или наиболее близкий сайт (эта информация кэшируется в ветке реестра
и используется при следующем входе для более быстрого поиска); - Клиент через DNS запрашивает список контроллеров домена в сайте (в разделе _
); - Windows пытается связаться со всеми DC в сайте и первый ответивший используется для выполнении аутентификации и в качестве LogonServer.
Вы можете переключить ваш компьютер на другой контроллер домена AD вручную с помощью команды:
Flags: 30 HAS_IP HAS_TIMESERV Trusted DC Name \MSK-DC02.winitpro.ru Trusted DC Connection Status Status = 0 0x0 NERR_Success The command completed successfully
Если указанный DC не доступен, появится ошибка:
I_NetLogonControl failed: Status = 1311 0x51f ERROR_NO_LOGON_SERVERS
Если ни один из контроллеров домена не доступен, или компьютер отключен от сети, то при входе пользователя появится надпись:
There are currently no logon servers available to service the logon request.
Отсутствуют серверы, которые могли бы обработать запрос на вход в сеть.
Войти на такой компьютер можно только под сохраненными учетными данными доменного пользователя.
Найти ближайший к вам контроллер домена согласно иерархии сайтов, подсетей и весов можно с помощью командлета Get-ADDomainController из модуля Active Directory для PowerShell:
Ошибки DNS
Поскольку репликация AD зависит от разрешения имен DNS, чтобы найти контроллеры домена для репликации, в случае поломки DNS может привести к возникновению событий 1311. Здесь полезно то, что если виновником является DNS, то в событии 1311 фраза «Ошибка поиска DNS» будет включена в описание. Если вы видите эту фразу, то у вас абсолютно точно есть проблема с DNS, которую нужно исправить. Я никогда не видел, чтобы эта ошибка оказалась ложной
Обратите внимание, что это не обязательно будет регистрировать событие в журнале DNS, и вы увидите это и в других событиях. Помните, что отсутствие значительных ошибок в журнале событий DNS не означает, что DNS исправен
Если вернуться конкретно к моему случаю, то у меня контроллер домена отсутствовал уже более 60 дней, и очень глупо его включать, так как это приведет к другим проблемам. Проще такой контроллер домена удалить и по необходимости развернуть новый. Даже если контроллер домена недоступен его можно корректно удалить.
Так же не забывайте проверить, что у вас контроллер удалился с сайта, и если он был в нем один, то лучше удалить сам сайт, если он не используется. Убедитесь, что теперь команды репликации не показывают ошибок 1722 или 1311. На этом у меня все с вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.
Дополнительно
- https://docs.microsoft.com/ru-ru/windows-server/identity/ad-ds/get-started/replication/active-directory-replication-concepts
- https://social.technet.microsoft.com/wiki/contents/articles/1375.event-id-1311-microsoft-windows-activedirectory-domainservice.aspx
Проверьте, виден ли клиент в LDAP
# ldapsearch -LLL -b "dc=test,dc=altlinux,dc=ru" -x -H "ldaps://ldap.test.altlinux.ru" "(&(objectClass=posixAccount)(uid=*))" dn: uid=fill,ou=People,dc=test,dc=altlinux,dc=ru uid: fill cn:: 0KTQuNC70LjQv9C/0L7QsiDQmNCy0LDQvSDQlNC80LjRgtGA0LjQtdCy0LjRhw== sn:: 0KTQuNC70LjQv9C/0L7Qsg== objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: sambaSamAccount loginShell: /bin/sh uidNumber: 5006 gidNumber: 5009 homeDirectory: /home/fil sambaAcctFlags: sambaSID: S-1-5-21-2552966934-293145977-2108249345-11012 sambaPwdLastSet: 2147483647 sambaLogonTime: 0 sambaLogoffTime: 2147483647 sambaKickoffTime: 2147483647 sambaPwdCanChange: 0 sambaPwdMustChange: 0 givenName:: 0JjQstCw0L0=
Как определить какой контроллер домена вас аутентифицировал
Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org. В данной статье, я хочу рассказать, как определить какой контроллер домена вас аутентифицировал. Иногда бывают ситуации, что нужно понять, данную информацию, для поиска проблем. Приведу простой пример, на пользователя была применена политика, которую я отключил на одном из контроллеров, через какое-то время, пользователь обратился, все стем же вопросом, выяснилось, что на другом DC, бала та же политика, отключив ее, все решилось, и в этом помогла информации, о том, кто его аутентифицировал.
Открываем cmd и пишем в ней волшебную команду.
И видим, очень информативную выборку.
Как определить какой контроллер домена вас аутентифицировал
Или без лишней воды
Второй метод определения контроллера домена, который проверил является использование команды:
Вот такая простоя, но очень полезная команда, и у нее еще очень много полезных функций. С вами был Иван Семин, автор и создатель 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.
Настройка Kerberos для веб клиента CommuniGate
Для того, чтобы настроить Kerberos аутентификацию необходимо выполнить следующие шаги:
1. В Active Directory создадим отдельного пользователя. Именно для этого пользователя мы в дальнейшем будем экспортировать ключи.
2. Выполним экспорт ключей:
Параметры экспорта следующие:
| Параметр | Описание |
| -princ | Указываем для какого сервера будет настроен экспорт. Составной параметр – service/domain@REALMservice – имя сервиса для которого выполняется экспорт. В нашем случае – HTTPdomain – DNS-имя по которому ваши клиенты будут заходить на веб клиент CommuniGate. В моем случае – com01.itproblog.ruREALM – имя домена Active Directory в котором будет выполняться аутентфиикация. В моем случае это – ITPROBLOG.RU |
| -mapuser | Имя пользователя от имени которого мы выполняем экспорт. Мы создали его в п. 1 |
| -pass | Пароль пользователя |
| -out | Путь до файла с ключами. Именно этот файл в последующем мы импортируем в CommuniGate |
| -crypto | Параметры криптографии. Оставляем без изменений |
| -ptype | Тип принципала. Оставляем без изменение |
3. После успешного экспорта в указанной нами директории должен появиться соответствующий файл.
4. Запускаем веб консоль администрирования CommuniGate.
5. Переходим в раздел для импорта ключей Kerberos: Users -> Domains -> itproblog.ru -> Security -> Kerberos.
6. Нажимаем кнопку “Browse”, находим файл из п. 3. Нажимаем кнопку “Import Keys”.
7. При успешном импорте мы увидим соответствующий ключ в списке:
Настройки на стороне сервера завершены. Теперь перейдет к проверкам на стороне клиента.
Причины ошибки 1311
Одна из самых печально известных ошибок репликации — это событие с кодом 1311, оно может быть вызвано рядом причины:
- Один или несколько контроллеров домена недоступны по сети или один или несколько контроллеров домена находятся в автономном режиме.
- Один или несколько сайтов не могут взаимодействовать друг с другом из сетевых ошибок, например один или несколько сайтов не содержатся в ссылке на сайт.
- Ссылки сайта содержат все сайты, но ссылки сайта не связаны между собой. Это условие известно как несвязанные ссылки на сайте.
- Контроллеры домена-плацдарма подключены, но возникают ошибки при попытке репликации необходимого раздела каталога между сайтами Active Directory.
- Предпочтительные серверы-плацдармы, определенные администратором, подключены к сети, но на них не размещен необходимый раздел каталога. Наиболее распространенная неправильная конфигурация — это определение серверов не глобального каталога в качестве серверов-плацдармов.
- Предпочтительные плацдармы правильно определены администратором, но в настоящее время они отключены.
- Сервер-плацдарм перегружен, поскольку сервер не производительный, слишком много сайтов филиалов пытаются реплицировать изменения с одного и того же контроллера домена-концентратора, или расписание репликации на сайтах слишком частое.
- Средство проверки согласованности знаний (KCC) создало альтернативный путь для обхода межсайтового соединения, но продолжает повторять попытку сбойного соединения каждые 15 минут.
- Мост включен в сайтах и службах Active Directory, но сеть не позволяет подключаться к сети между любыми двумя контроллерами домена в лесу.
- Предпочитаемый сервер-плацдарм настроен и отключен
- Ошибка разрешения DNS-имени
- Ошибка 1311 может быть просто результатом другой, более серьезной проблемы и исчезнет, когда эта проблема будет решена.
Get-ADDomainController: получаем информацию о контроллерах домена AD с помощью PowerShell
13.08.2019itproActive Directory, PowerShellкомментариев 5
Командлет 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:
Get-ADDomainController –ForceDiscover -Discover -Service ADWS
Параметр Service можно использовать, чтобы найти PDC в домене:
Get-ADDomainController -Discover -Service PrimaryDC
Если ваш контроллер домена не найден или не отвечает, вы можете найти контроллер домена в ближайшем сайте AD (определяется по весу межсайтовых связей):
Get-ADDomainController –Discover –ForceDiscover -NextClosestSite
Чтобы вывести список все контроллеров домена в текущем домене, выполните:
Get-ADDomainController -Filter * | ft
Посчитать количество контроллеров домена в AD можно с помощью команды:
Get-ADDomainController -Filter * | Measure-Object
Выведем более удобную таблицу, в которой указаны все контроллеры домена с их именем, IP адресом, версией ОС и именем сайта AD:
Get-ADDomainController -Filter *| Select Name, ipv4Address, OperatingSystem, site | Sort-Object name
Если вам нужно получить информацию о DC из другого домена, нужно указать имя любого доступного DC в стороннем домене с помощью параметра –Server (возможно при наличии доверительных отношений между доменами).
Get-ADDomainController -Filter * -server dc01.contoso.cpm | Select Name, ipv4Address, IsGlobalCatalog, Site
Используем Get-ADDomainController для выборки контроллеров домена по условиям
Рассмотрим несколько полезных командлетов, которые можно использовать для получения списка контролеров домена в AD по определенным критериям.
Найти контроллер домена по его IP адресу:
Get-ADDomainController -Identity «10.1.1.120»
Найти все DC, в имени которых есть символы DC04:
Get-ADDomainController -Filter | Select Name, ipv4Address, OperatingSystem, site
Поиск всех доступных DC в определенном сайте:
Get-ADDomainController -Discover -ForceDiscover -Site «Site-Name»
Вывести список DC в сайтах, имена которых начинаются с Mos*:
Get-ADDomainController -Filter | Select Name, ipv4Address, OperatingSystem, site
Get-ADDomainController -Filter | Select Name, ipv4Address, OperatingSystem, site
Найти DC в сайте “Site Name”, на которых включена роль Global Catalog:
Get-ADDomainController -Filter | Select Name, ipv4Address, OperatingSystem, site
PowerShell скрипт проверки доступности всех контроллеров домена
Следующая конструкция позволяет перебрать все контроллеры домена в Active Directory и выполнить для каждого из них определенное действие:
$AllDCs = Get-ADDomainController -Filter *ForEach($DC in $AllDCs)do something>
Ниже приведен пример простого PowerShell скрипта, который проверяет доступность LDAPS порта (TCP 636) на каждом DC в домене с помощью командлета Test-NetConnection. Если LDAPS порт на DC не доступен, появляется предупреждение.
$AllDCs = Get-ADDomainController -Filter * | Select-Object Hostname,Ipv4address,isGlobalCatalog,Site,Forest,OperatingSystemForEach($DC in $AllDCs)$PortResult=Test-NetConnection -ComputerName $DC.Hostname -Port 636 -InformationLevel Quietif ($PortResult -ne «$True»)write-host $DC.Hostname » не доступен» -BackgroundColor Red -ForegroundColor White>else write-host $DC.Hostname » доступен» >>
Как расследовать причину блокировки
Открываем журнал событий и идем в журнал безопасность (Security)» именно в нем собираются EventID которые могут помочь определить причину блокировки. Там очень много событий, так что отфильтруем их с помощью «Filter Current Log (Фильтр текущего журнала)», она позволит нам выбрать только те события, которые нам нужны. В поле Logged указываем за какой срок нужны данные, в поле Event ID указываем 4740 и нажимаем «Ок»
В отфильтрованных записях с помощью поиска (Find) находим имя интересующей нас учетной записи. В итоге должны отфильтроваться события по указанному логину с кодом 4740 в котором можно найти причину блокировки, например в поле Caller Computer Name будет указано имя компьютера с которого идут феилд логоны и который этим вызывает блокировку. Затем нужно перейти на этот компьютер и смотреть евент логи там, чтобы определить почему данная машина пытается залогиниться под некорректными кредами.
В событиях 4740 можно встреть еще такие причины блокировки как имя сервера, где происходит блокирование Exchange сервер организации – это значит, что проблема в Outlook, почтовом мобильном клиенте или его календарем. Чтобы расследовать данную блокировку нужно смотреть логи IIS на Exchange сервере. Так же можно использовать команду Get-ActiveSyncDeviceStatistics в PowerShell, чтобы увидеть проблемные мобильные устройства.
Ненадежный SSL-сертификат
Иногда при переходе на сайт, защищенный протоколом HTTPS, появляется ошибка «SSL-сертификат сайта не заслуживает доверия».
Одной из причин появления такой ошибки, как и в предыдущем случае, может стать неправильное время. Однако есть и вторая причина — браузеру не удается проверить цепочку доверия сертификата, потому что не хватает корневого сертификата. Для избавления от такой ошибки необходимо скачать специальный пакет GeoTrust Primary Certification Authority, содержащий корневые сертификаты. После скачивания переходим к установке. Для этого:
- Нажимаем сочетание клавиш Win+R и вводим команду certmgr.msc, жмем «Ок». В Windows откроется центр сертификатов.
- Раскрываем список «Доверенные корневые центры сертификации» слева, выбираем папку «Сертификаты», кликаем по ней правой кнопкой мышки и выбираем «Все задачи — импорт».
Запустится мастер импорта сертификатов. Жмем «Далее».
Нажимаем кнопку «Обзор» и указываем загруженный ранее сертификат. Нажимаем «Далее»:
В следующем диалоговом окне указываем, что сертификаты необходимо поместить в доверенные корневые центры сертификации, и нажимаем «Далее». Импорт должен успешно завершиться.
После вышеперечисленных действий можно перезагрузить устройство и проверить отображение сайта в браузере.
Перенос роли хозяина операций
Прежде чем начать перенос ролей, желательно добиться отсутствия ошибок в dcdiag!
Алгоритм переноса ролей FSMO (Flexible Single-Master Operations) такой же как и при захвате. В первом случае используется работающий главный контроллер домена (PDC), и переносимые роли на нём отключаются, если же он потерян, то роли захватываются новым контроллером принудительно.
Посмотрим список контроллеров домена mydomain.local:
nltest /dclist:mydomain.local
Выясняем, кто из контроллеров является хозяином операций:
C:\Users\pnm>netdom query FSMO Хозяин схемы dc1.mydomain.local Хозяин именования доменов dc1.mydomain.local PDC dc1.mydomain.local Диспетчер пула RID dc1.mydomain.local Хозяин инфраструктуры dc1.mydomain.local Команда выполнена успешно.
Перенос ролей можно сделать двумя способами:
1. через оснастку «Active Directory — Домены и доверие», открыв её из Диспетчера серверов — Средства.
C:\Users\pnm>ntdsutil ntdsutil: roles fsmo maintenance: connections server connections: connect to server dc2 Привязка к dc2 ... Подключен к dc2 с помощью учетных данных локального пользователя. server connections: quit fsmo maintenance: seize infrastructure master fsmo maintenance: seize naming master fsmo maintenance: seize PDC fsmo maintenance: seize RID master fsmo maintenance: seize schema master quit quit
Находясь в разделе fsmo maintenance можно узнать список всех ролей, послав команду ?.
В случае успешного захвата мы должны увидеть следующее
C:\Users\pnm>netdom query FSMO Хозяин схемы dc2.mydomain.local Хозяин именования доменов dc2.mydomain.local PDC dc2.mydomain.local Диспетчер пула RID dc2.mydomain.local Хозяин инфраструктуры dc2.mydomain.local Команда выполнена успешно.
Установка Active Directory
Установка производится через Server Manager и в ней нет ничего сложного, подробно все этапы установки вы можете увидеть ниже:
Сам процесс установки претерпел некоторые изменения 6 по сравнению с предыдущими версиями ОС:
Развертывание доменных служб Active Directory (AD DS) в Windows Server 2012 стало проще и быстрее по сравнению с предыдущими версиями Windows Server. Установка AD DS теперь выполняется на основе Windows PowerShell и интегрирована с диспетчером серверов. Сократилось количество шагов, необходимых для внедрения контроллеров домена в существующую среду Active Directory.
Необходимо выбрать только роль Доменные службы Active Directory, никакие дополнительные компоненты устанавливать не нужно. Процесс установки занимает незначительно время и можно сразу переходить к настройке.
На машине с Debian
С помощью ktutil
Этот способ работает если SPN предварительно были созданы и привязаны.
Установим необходимый пакет:
apt-get install krb5-kadmin
Запустим ktutil и создадим keytab-файл:
ktutil ktutil: addent -password -p HTTP/[email protected] -k 6 -e RC4-HMAC Password for HTTP/[email protected]: ktutil: wkt squid.keytab ktutil: q
С помощью Samba
Для создания keytab-файла с помощью samba, необходима работающая kerberos-аутентификация. При использовании этого метода нет необходимости генерировать и привязывать SPN на контроллере домена. Приведите файл настроек /etc/samba/smb.conf к следующему виду:
realm = DOMG.TESTG workgroup = DOMG server string = Samba server on %h (v. %v) security = ads dedicated keytab file = /etc/krb5.keytab kerberos method = dedicated keytab
Введите машину в домен:
net -v ads join DOMG.TESTG -UAdministrator Using short domain name -- DOMG Joined 'DOSERVER' to dns domain 'domg.testg'
Проверить ввод в домен можно командой:
net ads testjoin Join is OK
После этого в домене будет создан аккаунт компьютера к которому можно будет привязать SPN.
Создадим keytab-файл для компьютера:
net ads keytab create -UAdministrator
Добавим в keytab-файл принципала сервиса «HTTP»:
net ads keytab add HTTP -U Administrator Processing principals to add...
Далее можно поменять права на keytab и отредактировать его утилитой kutil.
С помощью Samba DC
При использовании этого метода kerberos ни при чём, а все действия выполняются на машине с домен-контроллером.
Создадим пользователя, с которым будем связывать создаваемые SPN:
samba-tool user create <someuser> samba-tool user setexpiry <someuser> --noexpiry
Привяжем к нему SPN (возможно несколько раз для разных сервисов):
samba-tool spn add <service-name>/test.example.com <someuser>
Создадим keytab:
samba-tool domain exportkeytab /tmp/keytab --principal=<service-name>/test.example.com
Данную процедуру необходимо выполнить несколько раз для всех spn, которые требуется поместить в keytab.
Проверка:
klist -ke /tmp/keytab
Keytab name: FILE:/etc/http.keytab
KVNO Principal
---- --------------------------------------------------------------------------
1 host/[email protected] (des-cbc-crc)
1 host/[email protected] (des-cbc-md5)
1 host/[email protected] (arcfour-hmac)
1 HTTP/[email protected] (des-cbc-crc)
1 HTTP/[email protected] (des-cbc-md5)
1 HTTP/[email protected] (arcfour-hmac)
С помощью FreeIPA Client
Для этого способа необходимо ввести машину в домен FreeIPA.
Для генерации keytab-файла используется команда:
ipa-getkeytab -s dc.ipa.server.ru -p HTTP/httpserver.ipa.server.ru -k /etc/http.keytab
Здесь:
- — FreeIPA сервер
- — SPN
- /etc/http.keytab — местоположение создаваемого keytab-файла
Работа над ошибками
DNS не удаётся разрешить IP-адрес
dcdiag выдаёт ошибку DNS:
Выполнение обязательных начальных проверок
Сервер проверки: Default-First-Site-Name\DC2
Запуск проверки: Connectivity
Узел a20970bf-3f73-400a-85ac-69c8f7b34301._msdcs.mydomain.local не удается
разрешить в IP-адрес. Проверьте DNS-сервер, DHCP, имя сервера и т. д.
Получена ошибка при проверке подключения LDAP и RPC. Проверьте параметры
брандмауэра.
......................... DC2 - не пройдена проверка Connectivity
Выполнение основных проверок
Сервер проверки: Default-First-Site-Name\DC2
Пропуск всех проверок, так как сервер DC2 не отвечает на запросы службы каталогов.
РЕШЕНИЕ:
Нужно проверить существует ли обратная DNS зона и синхронизирована ли она между контроллерами.
Детальная проверка службы DNS (может занять пару минут):
dcdiag /test:dns
Ошибка репликации 8453
repadmin /showrepl выдаёт ошибку:
Процесс DsReplicaGetInfo() завершился ошибкой с кодом состояния 8453 (0x2105):
Доступ к репликации отвергнут.
РЕШЕНИЕ:
Запустить репликацию вручную и командной строки с административными правами
repadmin /syncall
На контроллере нет сетевых ресурсов NetLogon и SysVol
Эта ошибка означает, что репликация данных с главного контроллера домена (хозяина операций) на проблемный не была произведена до конца.
Доступность сетевых ресурсов можно проверить командой:
net share
Исправность ресурсов SysVol и NetLogon можно проверить командой:
dcdiag /test:netlogons
Что такое Active Directory
Active Directory — это технология Microsoft, которая представляет собой распределенную базу данных, в которой хранятся объекты в иерархическом, структурированном и безопасном формате. Объекты AD обычно представляют пользователей, компьютеры, периферийные устройства и сетевые службы. Каждый объект уникально идентифицируется своим именем и атрибутами. Домен, лес и дерево представляют собой логические подразделения инфраструктуры AD.
Домены Windows обычно используются в больших сетях — корпоративных сетях, школьных сетях и государственных сетях. Они не то, с чем вы столкнётесь дома, если у вас нет ноутбука, предоставленного вашим работодателем или учебным заведением.
Типичный домашний компьютер — обособленный объект. Вы управляете настройками и учётными записями пользователей на компьютере. Компьютер, присоединённый к домену, отличается — этими настройками управляет контроллер домена.
Какие события отслеживать в журнале безопасность
При некорректном вводе данных генерируется событие 4740, на всех контроллерах домена если он не один. С кодами отказов Kerberos:
- 6 – имя пользователя не существует
- 12 – Ограничение времени входа в систему
- 18 – Учетная запись деактивирована, заблокирована или истек срок ее действия
- 23 – Истек срок действия пароля пользователя
- 24 – Предварительная аутентификация не удалась(неверный пароль)
- 32 – Истек срок действия тикета
- 37 – Время компьютера давно не синхронизировалось с доменным
и кодами ошибок NTLM
Код ошибки (десятичная система) — Код ошибки (16-ричная система) — Описание
- 3221225572 — С0000064 — Такого имени пользователя не существует
- 3221225578 — С000006А — Верное имя пользователя, но неверный пароль
- 3221226036 — С0000234 — Учетная запись пользователя заблокирована
- 3221225586 — С0000072 — Учетная запись деактивирована
- 3221225583 — С000006Е — Пользователь пытается войти в систему вне обозначенного периода времени
- 3221225584 — С0000070 — Ограничение рабочей станции
- 3221225875 — С0000193 — Истек срок действия учетной записи
- 3221225585 — 0000071 — Истек срок действия пароля
- 3221226020 — С0000224 — Пользователь должен поменять пароль при следующем входе в систему
Как выяснить причину блокировки учетной записи
Теперь, когда политика включена нам нужно определять из-за чего может все лочиться, и с какого компьютера или устройств, это происходит. Чтобы ответить на этот вопрос нужно настроить специальную политику аудита, призванную следить за соответствующими событиями, по которым вы сможете найти причину блокировок. По умолчанию данный вид аудита не настроен.
Снова открываем редактор групповой политики, создаем политику Audit Policy открываем ее и переходим по такому пути.
Конфигурация компьютера -> Политики -> Конфигурация Windows -> Параметры безопасности -> Локальные политики -> Политика аудита
Нам нужно включить аудит входа в систему, именно данная политика генерирует события 4771 и 4624. Настраиваем ее на «Успех и отказ».
Так же нужно задать политику аудита событий входа в систему на «Успех и отказ», а так же «Аудит управления учетными записями», чтобы видеть события 4740.
Принудительно обновляем политику и запускаем gpupdate /force на целевой машине
Токен и смарт-карта
Наверно, самым надежным и простым в реализации способом двухфакторной аутентификации является использование криптографического токена или смарт-карты. Токен — это USB-устройство, которое является и считывателем, и смарт-картой одновременно. Первым фактором в таком случае является факт владения устройством, а вторым — знание его PIN-кода.
Использовать токен или смарт-карту, тут кому, что удобнее. Но исторически так сложилось, что в России больше привыкли использовать токены, так как они не требуют использования встроенных или внешних считывателей смарт-карт. У токенов есть и свои минусы. Например, на нем не напечатаешь фотографию.
На фотографии изображена типичная смарт-карта и считыватель.
Однако вернемся к корпоративной безопасности.
А начнем мы с домена Windows, ведь в большинстве компаний в России корпоративная сеть построена именно вокруг него.
Как известно, политики Windows-домена, настройки пользователей, настройки групп в Active Directory предоставляют и разграничивают доступ к огромному количеству приложений и сетевых сервисов.
Защитив учетную запись в домене, мы можем защитить большинство, а в некоторых случаях и вообще все внутренние информационные ресурсы.
Как Windows определяет ближайший контроллер домена?
За определение LogonServer при загрузке Windows отвечает служба NetLogon. Она должны быть запущена:
Упрощенно процесс поиска контроллера домена клиентом Windows выглядит так:
- При загрузке Windows служба NetLogon делает DNS запрос за списком контроллеров домена (SVR записи _ldap._tcp.dc._msdcs.domain_ ;
- DNS возвращает список DC в домене;
- Клиент делает LDAP запрос к DC для определения сайта AD по-своему IP адресу;
- DC возвращает сайт, которому соответствует IP клиента или наиболее близкий сайт (эта информация кэшируется в ветке реестра HKLMSystemCurrentControlSetServicesNetlogonParameters и используется при следующем входе для более быстрого поиска);
- Клиент через DNS запрашивает список контроллеров домена в сайте (в разделе _ tcp.sitename._sites. );
- Windows пытается связаться со всеми DC в сайте и первый ответивший используется для выполнении аутентификации и в качестве LogonServer.
Вы можете переключить ваш компьютер на другой контроллер домена AD вручную с помощью команды:
Flags: 30 HAS_IP HAS_TIMESERV Trusted DC Name \MSK-DC02.winitpro.ru Trusted DC Connection Status Status = 0 0x0 NERR_Success The command completed successfully
Если указанный DC не доступен, появится ошибка:
I_NetLogonControl failed: Status = 1311 0x51f ERROR_NO_LOGON_SERVERS
Если ни один из контроллеров домена не доступен, или компьютер отключен от сети, то при входе пользователя появится надпись:
There are currently no logon servers available to service the logon request.
Найти ближайший к вам контроллер домена согласно иерархии сайтов, подсетей и весов можно с помощью командлета Get-ADDomainController из модуля Active Directory для PowerShell:
Get-ADDomainController -Discover -NextClosestSite
Так вы сможете определить имя контроллера домена, через который должен аутентифицироваться компьютер. Если он отличается от текущего, нужно понять почему.
Предыдущая статья Следующая статья
Читайте далее в разделе Active Directory Windows 10 Windows Server 2019
Настройка двухфакторной аутентификации (2FA) в Windows с помощью MultiOTP
Обновление/установка административных шаблонов групповых политик (ADMX)
Проверка здоровья контроллеров домена Active Directory и репликации
Как изменить имя (переименовать) домен Active Directory?
