Используйте Netdom.exe для сброса пароля учетной записи машины
-
Установите средства Windows Server 2003 на контроллер домена, пароль которого необходимо сбросить. Эти средства находятся в папке на Windows Server 2003 CD-ROM. Чтобы установить эти средства, щелкните правой кнопкой мыши Suptools.msi файл в папке, а затем выберите Установите.
Примечание
Этот шаг не требуется в Windows Server 2008, Windows Server 2008 R2 или более поздней версии, так как средство Netdom.exe включено в Windows выпусков.
-
Если вы хотите сбросить пароль для контроллера Windows домена, необходимо остановить службу Центра рассылки ключей Kerberos и настроить тип запуска в Руководство.
Примечание
- После перезапуска и проверки успешного сброса пароля можно перезапустить службу Центра рассылки ключей Kerberos (KDC) и вернуть ее тип запуска в Автоматическую. Это заставляет контроллер домена с неправильным паролем учетной записи компьютера обращаться к другому контроллеру домена для билета Kerberos.
- Возможно, вам придется отключить службу Центра рассылки ключей Kerberos на всех контроллерах домена, кроме одного. Если это возможно, не отключайте контроллер домена, который имеет глобальный каталог, если у него нет проблем.
-
Удалите кэш билета Kerberos на контроллере домена, где будут допущены ошибки. Это можно сделать, перезапустив компьютер или используя средства KLIST, Kerbtest или KerbTray. KLIST включен в Windows Server 2008 и Windows Server 2008 R2. Для Windows Server 2003 KLIST доступен в качестве бесплатной загрузки в средствах набора ресурсов Windows Server 2003.
-
В командной подсказке введите следующую команду:
Описание этой команды:
-
это имя контроллера домена, используемого для настройки пароля учетной записи компьютера. Это сервер, на котором работает KDC.
-
это учетная запись пользователя, которая создает подключение к домену, указанному в параметре. Он должен быть в формате domain\User. Если этот параметр опущен, используется учетная запись текущего пользователя.
-
указывает пароль учетной записи пользователя, указанный в параметре. Для запроса пароля используйте звездочку (*). Например, локальный компьютер контроллера домена — Server1, а одноранговой Windows контроллер домена — Server2. Если вы запустите Netdom.exe Server1 со следующими параметрами, пароль будет изменен локально и одновременно записан на Server2. Репликация распространяет изменения на другие контроллеры домена:
-
-
Перезапустите сервер, пароль которого был изменен. В этом примере это Server1.
В общем
Active Directory позволяет администраторам сети создавать домены, пользователей, объекты в сети и управлять ими. Например, администратор может создать группу пользователей и предоставить им определенные права доступа к определенным каталогам на сервере. По мере роста сети Active Directory позволяет организовать большое количество пользователей в логические группы и подгруппы, обеспечивая при этом контроль доступа на каждом уровне.
Структура Active Directory включает три основных уровня:
1) домены,
2) группы,
3) коллекции.
Несколько объектов (пользователей или устройств), использующих одну и ту же базу данных, могут быть сгруппированы в один домен. Несколько доменов можно объединить в одну группу. Несколько групп могут быть объединены в коллекцию. Каждому из этих уровней могут быть назначены определенные права доступа и привилегии.
Служба каталогов — это иерархическая структура, которая отображает имена всех ресурсов в сети на ее сетевой адрес. Он позволяет хранить, организовывать и управлять всеми сетевыми ресурсами, а также определять структуру именования. Это упрощает управление всеми устройствами из единой системы.
Контроллер домена — это сервер, на котором запущены службы Active Directory в домене. Все пользователи, информация о пользователях, компьютеры и их политики контролируются «Контроллером домена». Каждый пользователь должен пройти аутентификацию с помощью “Контроллера домена” для доступа к любому ресурсу или услуге в домене. Он определяет политики для всех пользователей, какие действия могут быть выполнены, какой уровень привилегий должен быть предоставлен и т.д . Это упрощает жизнь администраторам для управления пользователями и компьютерами в сети.
Управление делегированием в Active Directory долгое время было очевидной проблемой. Многие компании стали лучше внедрять жесткие политики для администраторов домена. Если злоумышленник сможет получить доступ к привилегированной учетной записи и изучит вашу сеть, он сможет узнать полезную информацию о том, что находится в AD с точки зрения привилегированного доступа, и создать схему этой “среды”.Другая уязвимость заключается в том, что пользователям без прав администратора могут быть предоставлены права на выполнение привилегированных действий. Злоумышленники могут просматривать списки управления доступом (ACL), видеть, у кого есть доступ и к каким объектам, и использовать эту информацию для компрометации Active Directory. Если сотрудник службы поддержки может сбросить пароли для ваших наиболее привилегированных пользователей, и злоумышленник получает доступ к учетной записи этого человека, то вы, по сути, позволяете этому злоумышленнику один из векторов для повышения прав.
Для понимания некоторых техник вначале следует разобраться, как устроен хэш. В Windows типичный хэш выглядит примерно так:
helpdesk:500:aad3b435b51404eeaad3b435b51404ee:94c2605ea71fca715caacfaa92088150:::
Строка выше состоит из четырех секций, разделенных двоеточиями. Первая часть – имя пользователя, вторая – относительный числовой идентификатор.
Третья часть представляет собой LM хэш, прекративший использоваться, начиная с Windows Vista/Server 2008. На данный момент вы навряд ли встретите где-либо подобный тип, если только в старых системах. В случае если вы столкнетесь с подобными ситуациями, считайте, что вам повезло, поскольку эти хэши легко взламываются.
Четвертая часть представляет собой NTLM хэш (иногда называемый NTHash).
Скрипт PowerShell по изменению пароля локальной учетной записи на удаленном компьютере
Для того, чтобы наш скрипт нормально отработал нам нужно выполнить некоторые требования:
- Иметь права администратора на том компьютере, где будет изменяться пароль для локальной учетной записи, я уверен, что вы все доменные администраторы
- Выяснить версию PowerShell, так как я приведу два варианта скрипта по изменению пароля, и тут нужно понимать, какой командлет поддерживает ваша версия.
- Подготовить список с именами серверов и сформировать текстовый файл, по идее все.
Подготовка файла со списком серверов
Давайте я покажу формат и структуру файла, в котором будет содержаться список наших серверов. Создайте обычный txt файл и задайте ему имя. у меня пусть будет comps.txt. Далее скопируйте в него список ваших FQDN имен серверов, ОДНА СТРОКА — ОДНО имя.
Уведомления
Чтобы улучшить осведомленность о событиях, связанных с паролями, функция самостоятельного сброса пароля позволяет настраивать уведомления как для пользователей, так и для администраторов удостоверений.
«Уведомлять пользователей о сбросе пароля»
Если для этого параметра задать значение Да, пользователи, сбрасывающие пароль, получат письмо, в котором указано, что пароль изменен. Электронное письмо отправляется через портал SSPR на основной и запасной адрес электронной почты, указанные в Azure AD. Больше это уведомление никому не отправляется.
«Уведомлять всех администраторов, если другие администраторы сбрасывают свои пароли»
Если для этого параметра задать значение Да, то все остальные администраторы Azure получат письмо по основному и запасному адресу электронной почты, которые указаны в Azure AD. В сообщении будет указано, что другой администратор изменил пароль с помощью SSPR.
Рассмотрим следующий пример сценария:
- В среде есть 4 администратора.
- Администратор А сбрасывает их пароли с помощью SSPR.
- Администраторы B, C и D получат письмо с уведомлением о сбросе пароля.
Политики паролей Azure AD
Политика паролей применяется ко всем учетным записям пользователей, которые создаются в службе Azure AD и находятся под ее управлением. Некоторые из этих параметров политики паролей нельзя изменить, хотя можно настроить заданные запрещенные пароли для защиты паролей Azure AD или параметры блокировки учетной записи.
По умолчанию после 10 неудачных попыток входа с неправильным паролем учетная запись блокируется. Пользователь блокируется на одну минуту. Последующие неудачные попытки входа приведут к блокировке пользователя на более длительное время. Смарт-блокировка отслеживает хэши последних трех попыток неправильного ввода пароля во избежание повторного увеличения счетчика блокировки для того же пароля. Если пользователь введет один и тот же неправильный пароль несколько раз, это не приведет к блокировке учетной записи. При этом можно определить пороговое значение и длительность умной блокировки.
Политика паролей Azure AD не применяется к учетным записям пользователей, синхронизированным из локальной среды AD DS с помощью Azure AD Connect, если не включен параметр EnforceCloudPasswordPolicyForPasswordSyncedUsers.
Определены следующие параметры политики паролей Azure AD. Если не указано иное, эти параметры изменить нельзя.
| Свойство | Требования |
|---|---|
| Допустимые символы |
|
| Недопустимые символы | Знаки Юникода. |
| Ограничения для пароля |
|
| Длительность срока действия пароля (максимальный срок существования пароля) |
|
| Уведомление об истечении срока действия пароля (когда пользователи получают уведомление об истечении срока действия пароля) |
|
| Срок действия пароля истекает (пароли можно сделать бессрочными) |
|
| Журнал изменения пароля | Последний пароль невозможно использовать повторно, когда пользователь изменяет пароль. |
| Журнал сброса пароля | Последний пароль можно использовать повторно, когда пользователь сбрасывает забытый пароль. |
Возможные причины блокировки пользователя в Active Directory
Данная ситуация существует в компаниях, где настроена политика блокировки учетной записи при вводе определенного количества не правильных паролей, это правильно с точки зрения кибербезопасности так как помогает защититься от брутфорса.
Из основных причин блокировки можно выделить:
- — Постоянный маппинг дисков со старыми учетными данными
- — Мобильные устройства, использующие корпоративные сервисы
- — Учетные записи служб, использующие кэшированные пароли, которые были изменены в ходе технического обслуживания
- — Запланированные задачи с устаревшими паролями
- — Программы, использующие сохраненные пароли, которые были изменены
- — Отключенные сеансы сервера терминалов
- — Проблемы с репликацией Active Directory
- — Неправильно настроенные параметры политики домена
- — Вредоносная активность, например, атака перебора паролей.
Тестирование пользовательского списка запрещенных паролей
Чтобы проверить, как действует пользовательский список запрещенных паролей, попробуйте изменить пароль так, чтобы он содержал любое из слов, добавленных в предыдущем разделе. Когда Azure AD начнет обрабатывать запрос на изменение пароля, обнаружится совпадение нового пароля с записью в пользовательском списке запрещенных паролей. Пользователь получит сообщение об ошибке.
Примечание
Чтобы пользователь мог сменить свой пароль через веб-портал, для клиента Azure AD должна быть включена функция самостоятельного сброса пароля. При необходимости пользователь может зарегистрироваться для SSPR на странице .
-
Перейдите на страницу Мои приложения в .
-
Вверху справа щелкните имя и выберите Профиль в раскрывающемся меню.
-
На странице Профиль щелкните Изменить пароль.
-
На странице Изменение пароля введите существующий (старый) пароль. Введите и подтвердите новый пароль, включенный в пользовательский список запрещенных паролей, который вы определили в предыдущем разделе, а затем щелкните Отправить.
-
Вы получите сообщение об ошибке, в котором сказано, что пароль заблокирован администратором, как показано в следующем примере:
Как работает процесс сброса паролей?
Пользователь может сбросить или изменить пароль с помощью портала SSPR. Сначала он должен зарегистрировать нужные методы проверки подлинности. Когда пользователь выполняет вход на портал SSPR, платформа Azure учитывает следующие факторы:
- язык страницы;
- допустимость учетной записи;
- организация, к которой принадлежит пользователь;
- параметры управления паролем пользователя;
- наличие лицензии на использование функции.
Когда пользователь нажимает ссылку Не удается получить доступ к своей учетной записи в приложении или на странице, либо когда он переходит непосредственно к https://aka.ms/sspr, язык, используемый на портале SSPR, выбирается с учетом следующих параметров:
- По умолчанию язык, на котором портал SSPR отображается для пользователя, определяется по языковому стандарту браузера. Эта функция сброса пароля переведена на все языки, поддерживаемые Microsoft 365.
- Если вы хотите создать ссылку, при переходе по которой порта SSPR будет отображаться на определенном языке, добавьте в конец URL-адреса сброса пароля вместе с требуемым языковым стандартом.
После отображения портала SSPR на требуемом языке пользователю будет предложено ввести идентификатор пользователя и подтвердить, что он не робот. Azure AD проверяет, может ли пользователь использовать самостоятельный сброс пароля, с помощью следующих проверок:
- Проверяет, включена ли данная функция у пользователя и назначена ли ему лицензия Azure AD.
- Проверяет наличие у пользователя соответствующих методов проверки подлинности, определенных в его учетной записи в соответствии с политикой администратора.
- Если политика требует только один метод, то проверяется, определены ли у пользователя соответствующие данные по крайней мере для одного из методов проверки подлинности, разрешенных политикой администратора.
- Если политика требует два метода, то проверяется, определены ли у пользователя соответствующие данные по крайней мере для двух методов проверки подлинности, разрешенных политикой администратора.
- Если пользователю назначается роль администратора Azure, применяется строгая двухфакторная политика паролей. Дополнительные сведения см. в разделе .
- Проверяет, управляется ли пароль пользователя локально (использует ли клиент Azure AD федеративную, сквозную аутентификации, или для него включена синхронизация хэшей паролей):
- Если обратная запись самостоятельного сброса пароля настроена, а управление паролем пользователя осуществляется локально, то пользователю разрешается продолжить проверку подлинности и сбросить свой пароль.
- Если обратная запись самостоятельного сброса пароля не развернута, а управление паролем пользователя осуществляется локально, то пользователю предлагается обратиться к администратору для сброса своего пароля.
Если все предыдущие проверки успешно выполнены, пользователь проходит через процесс сброса или изменения пароля.
Примечание
Функция самостоятельного сброса пароля может отправлять пользователям уведомления по электронной почте в рамках процесса сброса пароля. Эти сообщения отправляются с помощью службы ретранслятора SMTP, работающей в режиме «активный — активный» в нескольких регионах.
Службы ретранслятора SMTP получают и обрабатывают текст сообщений электронной почты, но не сохраняют его. Текст сообщения электронной почты от функции самостоятельного сброса пароля, который потенциально может содержать сведения, предоставленные клиентом, не хранится в журналах службы ретранслятора SMTP. В журналах содержатся только метаданные протокола.
Чтобы приступить к работе с функцией самостоятельного сброса пароля, ознакомьтесь со следующим руководством.
Сброс пароля администратора домена Active Directory
Мой лабораторный стенд будет состоять из 3-х виртуальных машин:
dc01.corp.ait.in.ua и dc02.corp.ait.in.ua — контроллеры домена
Some Host — не доменный хост с установленным модулем DSInternals
Первым шагом будет выключение контроллера dc02.corp.ait.in.ua и подключение его системного диска к серверу Some Host.
Подключение диска контроллера домена
После подключения диска к серверу Some Host, в диспетчере дисков переводим его в состояние Online.
Включение диска
Устанавливаем модуль DSInternals
PowerShell
Install-Module DSInternals -Force
| 1 | Install-ModuleDSInternals-Force |
Первым делом необходимо получить загрузочный ключ (boot key). С его помощью шифруются все хранимые хеши паролей Active Directory в базе ntds.dit. Добывается он с файлов реестра, которые доступны по пути «E:\Windows\System32\config\SYSTEM» Воспользуемся коммандлетом Get-BootKey:
PowerShell
Get-BootKey -SystemHiveFilePath «E:\Windows\System32\config\SYSTEM»
| 1 | Get-BootKey-SystemHiveFilePath»E:\Windows\System32\config\SYSTEM» |
Получение загрузочных ключей
Далее, получим сведения об аккаунте Administrator. Для этого выполняем:
PowerShell
Get-ADDBAccount -SamAccountName ‘Administrator’ -DBPath «E:\Windows\NTDS\ntds.dit» -BootKey a2d2082ad0aed16cdb6a678303b96b99
| 1 | Get-ADDBAccount-SamAccountName’Administrator’-DBPath»E:\Windows\NTDS\ntds.dit»-BootKeya2d2082ad0aed16cdb6a678303b96b99 |
Будет интересовать активирован ли аккаунт или нет.
Полная информация об аккаунте Administrator
как показано на скриншоте, аккаунт деактивирован. Включаем учетную запись коммандлетом Enable-ADDBAccount:
PowerShell
Enable-ADDBAccount -SamAccountName ‘Administrator’ -DBPath «E:\Windows\NTDS\ntds.dit»
| 1 | Enable-ADDBAccount-SamAccountName’Administrator’-DBPath»E:\Windows\NTDS\ntds.dit» |
В завершение, осталось установить новый пароль. Для этого выполняем:
PowerShell
Set-ADDBAccountPassword -SamAccountName ‘administrator’ -DBPath «E:\Windows\NTDS\ntds.dit» -BootKey a2d2082ad0aed16cdb6a678303b96b99
| 1 | Set-ADDBAccountPassword-SamAccountName’administrator’-DBPath»E:\Windows\NTDS\ntds.dit»-BootKeya2d2082ad0aed16cdb6a678303b96b99 |
Сброс пароля администратора домена Active Directory
Отключаем диск от виртуального сервера Some Host и включаем контроллер домена dc02.corp.ait.in.ua. Стоит заметить, что dc01.corp.ait.in.ua все это время работал. После включения второго он примет входящую репликацию сделанных изменений.
Диагностика статуса репликации Active Directory
Дополнительная информация
Пароль хранится в базе данных AD и LDS на объекте пользователя в атрибуте unicodePwd. Этот атрибут можно написать в ограниченных условиях, но его невозможно прочитать. Атрибут можно изменить только; она не может быть добавлена при создании объекта или запрашивается поиском.
Чтобы изменить этот атрибут, клиент должен иметь 128-битную связь с безопасностью транспортного слоя (TLS)/Secure Socket Layer (SSL) на сервере. Зашифрованный сеанс с помощью созданных SSP-ключей сеанса с использованием NTLM или Kerberos также приемлем до тех пор, пока не будет удовлетворены минимальные длины ключей.
Чтобы это подключение было возможным с помощью TLS/SSL:
- Сервер должен обладать сертификатом сервера для 128-битного подключения RSA.
- Клиент должен доверять органу сертификации (CA), сгенерированию сертификата сервера.
- Клиент и сервер должны быть способны к 128-битной шифрованию.
Синтаксис атрибута unicodePwd — octet-string; однако служба каталогов ожидает, что в строке octet-string будет содержаться строка UNICODE (как указывает имя атрибута). Это означает, что любые значения для этого атрибута, переданные в LDAP, должны быть строками UNICODE, кодируемыми BER (Основные правила кодирования) в качестве октета-строки. Кроме того, строка UNICODE должна начинаться и заканчивается кавычками, которые не являются частью нужного пароля.
Существует два возможных способа изменения атрибута unicodePwd. Первый похож на обычную операцию по смене пароля пользователя. В этом случае запрос на изменение должен содержать как операцию удаления, так и операцию добавления. Операция удаления должна содержать текущий пароль с кавычками вокруг него. Операция добавления должна содержать нужный новый пароль с кавычками вокруг него.
Второй способ изменения этого атрибута аналогичен администратору, сбросив пароль для пользователя. Для этого клиент должен связаться как пользователь с достаточными разрешениями, чтобы изменить пароль другого пользователя. Этот запрос на изменение должен содержать одну операцию замены новым нужным паролем, окруженным кавычками. Если у клиента достаточно разрешений, этот пароль становится новым паролем независимо от старого пароля.
В следующих двух функциях приводится пример этих операций:
Повторный ввод данных проверки подлинности
Чтобы убедиться в правильности методов проверки подлинности, когда необходимо сбросить или изменить пароль, можно потребовать от пользователей подтвердить зарегистрированную информацию по истечении определенного периода времени. Это возможно только, если включить параметр Требовать регистрации пользователей при входе.
Допустимые значения, по которым пользователю предлагается подтвердить свои зарегистрированные методы, находятся в диапазоне от до 730 дней. Если установить этому параметру значение , пользователям не будет предлагаться подтвердить данные проверки подлинности. При использовании Объединенных возможностей регистрации пользователи должны подтвердить свою личность, прежде чем повторно подтвердить свои данные.
Поддерживаемые сценарии
Действительны следующие условия.
-
Администраторы могут включать различные способы проверки подлинности без пароля для своего арендатора.
-
Администраторы могут развертывать эти решения для всех сотрудников организации или выбирать отдельных пользователей и группы в арендаторе для каждого способа.
-
Пользователи могут регистрироваться и управлять этими способами проверки подлинности без пароля на портале учетных записей.
-
Пользователям доступны перечисленные ниже способы проверки подлинности без пароля.
- Приложение Microsoft Authenticator: работает в сценариях, где используется проверка подлинности Azure AD, в том числе во всех браузерах, во время установки Windows 10, а также с интегрированными мобильными приложениями в любой операционной системе.
- Ключи безопасности: работают на экране блокировки Windows 10 и на веб-страницах в поддерживаемых браузерах, таких как Microsoft Edge (как в устаревшей, так и в новой версии).
-
Пользователи могут использовать учетные данные без пароля для доступа к ресурсам арендаторов, где они работают в режиме гостя, но при этом от них все равно может требоваться прохождение MFA на соответствующем арендаторе. Дополнительные сведения см. в статье .
-
Пользователи не могут регистрировать учетные данные для входа без пароля на арендаторе, где они работают в режиме гостя, равно как и иметь управляемый пароль на этом арендаторе.
Другие причины блокировок пользовательских учетных записей
Если проблема локаута кроется в сервисах Google Workspaces (Gmail, Gdrive…) то в логах будет отображаться, что феилд логоны идут с компьютера WORKSTATION. Так же подробную информацию о блокировке можно посмотреть в событии 4771. Там можно найти Керберос коды, которые были описаны выше и IP адрес устройства с которого идут фейлд логоны.
Если в полях Caller Computer Name ивента 4770 и Client Address 4771 пусто – это значит что вас скорее всего брутфорсят!
Чтобы определить источник фейлд логонов в этом случае необходимо включить netlogon и смотреть его логи.
NETLOGON Netlogon — это процесс Windows Server, который аутентифицирует пользователей и другие службы в домене. Включите ведение журнала Netlogon: Пуск > Выполнить > введите:
После перезапуска службы Netlogon соответствующая активность может быть записана в %windir%/debug/netlogon.log.
Можно так же разобрать журналы Netlogon с помощью скрипта:
Внимание! Не забудьте отключить Netlogon после того, как вы зафиксировали события, так как производительность системы может быть немного снижена из-за процесса дебаггинга. Отключите ведение журнала Netlogon:. Пуск > Выполнить > введите:
Пуск > Выполнить > введите:
В логах можно найти айпишники тех компьютеров, с которых идут скрытые фейлд логоны, это могут быть терминальные сервера или RDP на которые ведется атака по перебору паролей.
Возвращаемся к журналу событий безопасности. Еще может быть полезным событие с кодом 4776, тут тоже можно найти с какой рабочей станции была попытка ввода учетных данных.
Если айпи вам неизвестен можно посмотреть его mac на на DHCP сервере или же на сетевом оборудовании, далее с помощью специальных сервисов, которые легко можно найти в интернете можно определить, что за производитель у данного mac-адреса. Это полезно, когда феилд логоны идут с какого-то смартфона или планшета.
Еще полезным будет изучение события 4625, там вы можете обнаружить процесс, из-за которого происходит блокировка учетных записей. Используйте Process Hacker или Process Monitor для просмотра учетных данных активных процессов.
Проблемой блокировки может быть планировщик задач Windows — возможно, есть задача, настроенная на запуск с использованием учетной записи, пароль к которой поменялся.
На локальной машине могут быть сохраненные учетные данные, найти которые можно так:
Пуск> Выполнить > rundll32 keymgr.dll, KRShowKeyMgr > OK.
Или Netplwiz:
Пуск> Выполнить > введите: netplwiz > OK Перейдите на вкладку Дополнительно, а затем нажмите Управление паролями.
Блокировку может вызывать сессия сервера терминалов с устаревшими учетными данными. Для отключения RDP сессии выполните следующие команды в командной строке (Win+R > «cmd»), заменив «server_ip», «name» и «password» на необходимые учетные данные:
Это позволит вам войти на удаленный сервер без использования RDP.
Замените «name» на имя сервера. Здесь вы получите идентификатор сессии.
Это завершает активную сессию на удаленном сервере.
Блокировку учетки может вызывать репликация AD, когда обновление пароля не было реплицировано на все контроллеры домена. Для принудительной репликации выполните следующую команду на вашем DC:
