5 шокирующих причин ночных блокировок аккаунтов в AD и как их быстро устранить

Вступление

Блокировка учётных записей в Active Directory (AD) – обычное явление, но когда она происходит регулярно в одно и то же время ночи, это уже выглядит как загадка из фильма‑детектива. В нашем случае бухгалтерка получает блокировку между 2‑й и 4‑й часами утра, хотя в это время она спит, а её ноутбук, как она уверяет, никогда не подключается к корпоративной сети. Почему же система «запирает» её аккаунт именно в эти часы? Как быстро найти источник и остановить «ночных охотников»? В статье мы разберём реальный пост из Reddit, проанализируем комментарии экспертов, рассмотрим типичные причины и предложим практический набор инструментов, включая готовый скрипт на Python, который поможет автоматизировать поиск виновника.

И в завершение – небольшое японское хокку, которое, как ни странно, отражает суть нашей ночной головоломки:

Тихий свет монитора —
Тени в логах шепчут:
«Кто в полночь пришёл?»

Пересказ Reddit‑поста

Автор поста – администратор корпоративной сети – столкнулся с проблемой: у сотрудницы бухгалтерии постоянно блокируют учётную запись. Блокировки происходят только в промежутке с 2‑х до 4‑х часов ночи. Сотрудница уверена, что в это время не работает, не использует личные устройства и не подключает их к корпоративной инфраструктуре.

Что уже сделано:

1. Запущена утилита Lockoutstatus.exe. По ней блокировка «приходит» с одного из контроллеров домена, но в журналах безопасности видно лишь факт блокировки, без указания источника.
2. Проверены запланированные задачи на её рабочей станции – ничего, что могло бы запускаться в ночные часы, не найдено.
3. Учётную запись отключили на Wi‑Fi‑контроллере, полагая, что может быть старый телефон, но блокировки продолжаются.

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

Суть проблемы, «хакерский» подход и основные тенденции

Суть проблемы – «невидимый» клиент, который использует учётные данные сотрудницы и пытается аутентифицироваться в ночное время, вызывая блокировку из‑за превышения лимита неудачных попыток входа. Традиционный «хакерский» подход к решению такой задачи включает:

• Сбор полной картины событий в журналах безопасности всех контроллеров домена.
• Определение IP‑адреса или имени компьютера, откуда приходят неудачные попытки (событие 4625 в Windows).
• Проверка наличия кэшированных учётных данных на устройствах, которые могут «просыпаться» для установки обновлений.
• Аудит сервисных аккаунтов и автоматических задач (Scheduled Tasks, PowerShell‑скрипты, службы).
• Отслеживание синхронизации с облачными сервисами (M365, Azure AD) – иногда миграция почтовых ящиков оставляет «запасные» токены.

Тенденции, которые часто приводят к подобным блокировкам:

1. Автоматические обновления ОС и приложений. Многие ноутбуки «просыпаются» ночью, чтобы установить патчи, используя кэшированные учётные данные.
2. Службы резервного копирования. Некоторые решения (Veeam, Backup Exec) могут запускать аутентификацию от имени пользователя для доступа к файлам.
3. Синхронизация почтовых ящиков. При миграции в облако могут оставаться старые задачи, которые пытаются подключиться к старому серверу.
4. Старые мобильные устройства. Даже если пользователь их «отключил», телефон может периодически обращаться к корпоративному Wi‑Fi, если он настроен на автоматическое подключение.
5. Скрипты и планировщики задач на сервере. Иногда администраторы забывают удалить задачи, которые работают от имени обычных пользователей.

Детальный разбор проблемы с разных сторон

1. Журналы безопасности контроллеров домена

Событие 4625 (неудачная попытка входа) содержит такие поля, как Source Network Address (IP‑адрес) и Workstation Name. Если в журнале указано «UNKNOWN», значит аудит не настроен полностью. Нужно убедиться, что на всех контроллерах включён аудит «Logon/Logoff – Failure» (политика Audit Logon).

2. Кешированные учётные данные

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

3. Службы и задачи, работающие от имени пользователя

Проверка Task Scheduler на всех серверах, где может быть запущена задача от имени этой учётки, часто раскрывает виновника. Важно искать не только задачи на её рабочей станции, но и на файловых серверах, серверах печати, серверах резервного копирования.

4. Облачные сервисы и миграция в M365

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

5. Сетевые устройства (Wi‑Fi‑контроллер, VPN‑шлюз)

Некоторые контроллеры могут кэшировать учётные данные для «быстрого входа». Если кэш не обновился, они могут отправлять запросы с устаревшими данными.

Практические примеры и кейсы

Рассмотрим два типовых кейса, которые часто встречаются в реальной практике.

Кейс 1. «Просыпающийся ноутбук»

Сотрудник оставил ноутбук в спящем режиме, а Windows Update настроен на ночную установку. При попытке установить обновления система использует кэшированный пароль, который уже не актуален (пароль был изменён в начале недели). В результате контроллер домена фиксирует несколько неудачных попыток входа и блокирует учётную запись.

Кейс 2. «Забытый скрипт резервного копирования»

На файловом сервере был настроен скрипт, который каждый день в 3:00 am копирует файлы из домашней папки пользователя, используя её учётные данные. После смены пароля скрипт продолжал работать, но аутентификация не проходила, вызывая блокировку.

Экспертные мнения из комментариев

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

— thelemon8er-2

«Логи DC должны содержать IP‑адрес источника. Возможно, вам придётся проверить логи всех контроллеров, чтобы найти виновника.»

— Salt_Being2908

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

— Secret_Account07

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

— Ihaveasmallwang

«Отключите её машину на одну ночь и отключите от сети. Если блокировки продолжаются, значит виновник – не её устройство.»

— silentstorm2008

Возможные решения и рекомендации

1. Настройте аудит входов. В групповой политике включите Audit Logon (успешные и неуспешные) на всех контроллерах домена.
2. Соберите и проанализируйте события 4625. Используйте PowerShell или Python‑скрипт (см. ниже) для агрегации данных и определения IP‑адреса/имени компьютера.
3. Проверьте кэшированные учётные данные. На всех устройствах, где пользователь мог входить, выполните cmdkey /list и очистите устаревшие записи.
4. Аудит запланированных задач. На всех серверах выполните Get-ScheduledTask | Where-Object {$_.Principal.UserId -eq "DOMAIN\user"}.
5. Отключите автоматический вход в Wi‑Fi. Убедитесь, что на контроллере Wi‑Fi не хранит учётные данные пользователя.
6. Проверьте облачную синхронизацию. В Azure AD проверьте Sign‑ins в Azure Portal, найдите попытки входа в указанные часы.
7. Временное решение. Смените пароль пользователя и сразу же сбросьте кэш на всех устройствах (команда klist purge для Kerberos).

Прогноз развития ситуации

С ростом гибридных инфраструктур (локальные серверы + облако) количество «скрытых» точек входа будет только увеличиваться. Автоматические обновления, облачные сервисы и мобильные устройства создают новые векторы, которые часто остаются незамеченными. Поэтому в ближайшие годы администраторы будут всё чаще использовать централизованные системы SIEM (Security Information and Event Management) и автоматизированные скрипты для корреляции событий, чтобы быстро находить «ночных» виновников.

Практический пример на Python

Ниже представлен скрипт, который подключается к контроллерам домена через LDAP, собирает события 4625 за последние 7 дней, фильтрует их по времени (02:00‑04:00) и выводит список уникальных источников (IP‑адресов и имён компьютеров). Скрипт использует библиотеку ldap3 и может быть запущен на любой машине с правами чтения журналов AD.

# -*- coding: utf-8 -*-
"""
Скрипт для поиска источников блокировок учётных записей в AD.
Собирает события 4625 (неудачный вход) за последние 7 дней,
фильтрует их по времени 02:00‑04:00 и выводит уникальные IP/имена.
Требуется библиотека ldap3 (pip install ldap3).
"""

import datetime
from collections import defaultdict

from ldap3 import Server, Connection, ALL, NTLM, SUBTREE

# Параметры подключения к контроллеру домена
DC_HOST = 'dc01.example.com'          # имя или IP контроллера
DOMAIN = 'EXAMPLE'                    # домен в верхнем регистре
USER = 'admin_user'                   # учётка с правом чтения журналов
PASSWORD = 'StrongPassword123!'       # пароль

# Диапазон дат: последние 7 дней
end_date = datetime.datetime.utcnow()
start_date = end_date - datetime.timedelta(days=7)

# Формат даты для LDAP‑фильтра (yyyyMMddHHmmss.0Z)
def ldap_time(dt):
    return dt.strftime('%Y%m%d%H%M%S.0Z')

# LDAP‑фильтр: событие 4625, время в диапазоне, пользователь (по желанию)
LDAP_FILTER = (
    f'(&(eventID=4625)'
    f'(timeCreated>={ldap_time(start_date)})'
    f'(timeCreated<={ldap_time(end_date)}))'
)

def main():
    # Подключаемся к контроллеру
    server = Server(DC_HOST, get_info=ALL)
    conn = Connection(server,
                      user=f'{DOMAIN}\\{USER}',
                      password=PASSWORD,
                      authentication=NTLM,
                      auto_bind=True)

    # Поиск в контейнере "Domain Controllers"
    base_dn = f'DC={DOMAIN},DC=com'   # замените на ваш DN
    conn.search(search_base=base_dn,
                search_filter=LDAP_FILTER,
                search_scope=SUBTREE,
                attributes=['timeCreated',
                            'targetUserName',
                            'workstationName',
                            'sourceNetworkAddress'])

    # Словарь для агрегации источников
    sources = defaultdict(set)

    for entry in conn.entries:
        # Преобразуем время в datetime
        event_time_str = entry.timeCreated.value
        event_time = datetime.datetime.strptime(event_time_str, '%Y%m%d%H%M%S.0Z')

        # Фильтрация по ночному интервалу
        if 2 <= event_time.hour < 4:
            user = entry.targetUserName.value
            workstation = entry.workstationName.value or 'UNKNOWN'
            ip = entry.sourceNetworkAddress.value or 'UNKNOWN'
            sources[user].add((workstation, ip, event_time))

    # Вывод результатов
    for user, records in sources.items():
        print(f'Пользователь: {user}')
        for ws, ip, ts in sorted(records, key=lambda x: x[2]):
            print(f'  [{ts}] Рабочая станция: {ws}, IP: {ip}')
        print('-' * 40)

    conn.unbind()

if __name__ == '__main__':
    main()

Скрипт собирает события из журнала безопасности контроллера, отбирает только те, что произошли в ночные часы, и выводит список подозрительных источников. Полученные IP‑адреса можно сопоставить с инвентаризацией устройств, а имена рабочих станций – с планировщиком задач.