У нас есть заказчик с контроллером домена Windows Server 2016. Это небольшой бизнес, поэтому их серверная инфраструктура состоит из хоста Hyper-V и этого контроллера домена. На DC размещаются общие файловые ресурсы и Azure AD Connect для синхронизации удостоверений с Office 365.
Мы отслеживаем событие с кодом 4625 и имеем порог срабатывания предупреждений, чтобы помочь нам определить потенциальные атаки методом грубой силы на сеть.
В октябре прошлого года мы начали получать предупреждения о превышении порога предупреждения о неудачном входе в систему. После расследования у нас есть следующее описание проблемы:
vssadmin list writersСписок устранения неполадок за последние несколько месяцев длинный. Это неполный список:
rundll32 keymgr.dll,KRShowKeyMgr - учетные данные не кешируются)Полезная вещь, которую вы узнали во время всего этого
vssadmin list writers постоянно в процессе установки появляются ошибки немедленно после установки компонентов SQL, еще до того, как программа установки завершит работу.Проблема явно связана с AADC, потому что я могу остановить службу синхронизации AAD или удалить AADC, и все неудачные события входа в систему исчезнут. Но удаление AADC и удаление папок AADC, очистка учетных записей пользователей AADC и очистка записей реестра AADC, чтобы попытаться получить действительно новую установку, не имеет никакого эффекта, ошибки сразу же возвращаются, когда я переустанавливаю AADC.
На данный момент я в своем уме и не знаю, что еще делать и куда еще даже смотреть. Я надеюсь, что кто-то там, в эфире, знает больше, чем я (вероятно), или испытал это раньше и нашел исправление.
И последнее замечание: DNS-имя сервера состоит из 9 символов, что означает, что оно не соответствует его имени NETBIOS. Не думаю, что это причина, но при необходимости могу переименовать сервер. Это просто небольшая головная боль для серийного DC и файлового сервера.
Первоначально эта проблема возникла в октябре 2019 года. На это потребовался почти год, но я наконец нашел решение, которое намекает на возможное объяснение.
Решением было настроить следующий раздел и значение реестра:
Это разрешало неудачные попытки входа в систему, когда VSS работал с базой данных SQL.
Это часть функции безопасности, представленной в Windows Server 2003, которая называется Функциональность кольцевой проверки.
Из того, что я читал о том, как работает функция Loopback Check Function, я считаю, что происходит то, что всякий раз, когда VSS входит в SQL для выполнения резервного копирования, он входит в систему как SYSTEM. LSA ожидает, что вход в систему для SYSTEM будет происходить от имени DNS сервера, но на самом деле вход в систему происходит по имени NETBIOS сервера. Поскольку имя DNS не совпадает с именем NETBIOS в этом случае, LSA не проходит проверку подлинности Kerberos, и вход возвращается к NTLM, который принимает имя NETBIOS.
Настроив BackConnectionHostNames мы говорим LSA принимать соединение как от имен NETBIOS, так и от DNS, и аутентификация проходит успешно.
Мне удалось отследить ошибку, используя Sysinternals ProcessMonitor чтобы отследить все, что VSS делал, когда возникали ошибки. Я обнаружил, что VSS обращается к папкам, расположенным по адресу C: \ Users \ {AzureADConnect Account} \ AppData \ Local \ Microsoft \ Microsoft SQL Server Local DB \ Instances \ ADSync где я нашел журнал ошибок файлы. Эти журналы содержали следующую ошибку:
2020-08-13 13:00:47.43 Logon Error: 17806, Severity: 20, State: 14.
2020-08-13 13:00:47.43 Logon SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. The logon attempt failed [CLIENT: <named pipe>]
Это был прорыв, в котором я нуждался, поскольку эта информация об ошибке привела меня к нескольким местам, таким как этот вопрос SE, который рекомендовал полностью отключить проверки обратной связи. Не желая отключать функцию безопасности, я продолжал поиск, пока не нашел источники (1) и (2) в котором описано, как настроить функцию проверки обратной связи, не отключая ее, путем создания записи реестра для BackConnectionHostNames как я обрисовал выше.