У нас є доменний рахунок, який блокується через 1 з 2 серверів. Вбудований аудит лише нам це говорить (заблокований із SERVER1, SERVER2).

Обліковий запис закриється протягом 5 хвилин, здається, приблизно 1 запит на хвилину.

Спочатку я спробував запустити прокмон (від sysinternals), щоб побачити, чи виникли якісь нові СТАРТ ПРОЦЕСУ після розблокування облікового запису. Нічого підозрілого не виходить. Після запуску промоу на моїй робочій станції та піднесення до оболонки UAC (conscent.exe) здається, що зі стека це відбувається ntdll.dllі дзвонять, rpct4.dllколи ви намагаєтесь отримати автентифікацію проти AD (не впевнений).

Чи все-таки можна звузити, який процес викликає запит на аутентифікацію до нашого постійного струму? Це завжди один і той же DC, тому ми знаємо, що на цьому сайті повинен бути сервер. Я міг би спробувати шукати дзвінки в проводці, але я не впевнений, що це звузить, який процес насправді викликає його.

Ніякі сервіси, відображення дисків або заплановані завдання також не використовують цей обліковий запис домену - значить, він повинен зберігати записи домену. На цьому сервері немає жодних відкритих сеансів RDP з цим обліковим записом домену (ми перевірили).

Подальші замітки

Так, у відповідному постійному току ввімкнено перевірку входу в систему "Успіх / Невдача" - жодні події відмов не реєструються, поки акаунт фактично не заблокований.

Подальше копання показує, що LSASS.exeздійснює KERBEROSдзвінок у відповідний DC, коли обліковий запис розблоковано. Йому передує (як правило) java, який, схоже, називається vpxd.exeпроцесом vCenter. АЛЕ, коли я дивлюся на інший "server2", якщо блокування облікового запису може (також) траплятися, я ніколи не бачу виклику lsass.exeі породжуються лише процеси apache. Єдине відношення, яке вони мають, - це те, що SERVER2 є частиною кластера vSphere SERVER1 (server1 є vSphere OS).

Помилка DC

Тож, здається, все, що мені скаже AD, - це попередня помилка Кербероса. Я перевірив, і квитків не було, klistі все-таки промив на всякий випадок. Досі поняття не маю, що викликає цю помилку kerberos.

Index              : 202500597
EntryType          : FailureAudit
InstanceId         : 4771
Message            : Kerberos pre-authentication failed.

                     Account Information:
                         Security ID:        S-1-5-21-3381590919-2827822839-3002869273-5848
                         Account Name:        USER

                     Service Information:
                         Service Name:        krbtgt/DOMAIN

                     Network Information:
                         Client Address:        ::ffff:x.x.x.x
                         Client Port:        61450

                     Additional Information:
                         Ticket Options:        0x40810010
                         Failure Code:        0x18
                         Pre-Authentication Type:    2

                     Certificate Information:
                         Certificate Issuer Name:
                         Certificate Serial Number:
                         Certificate Thumbprint:

                     Certificate information is only provided if a certificate was used for pre-authentication.

                     Pre-authentication types, ticket options and failure codes are defined in RFC 4120.

                     If the ticket was malformed or damaged during transit and could not be decrypted, then many fields
                      in this event might not be present.

Події входу записують процес спроби входу. Увімкніть невдалий аудит входу (Налаштування безпеки> Місцева політика> Аудиторська політика> Аудит подій входу) у політиці локальної безпеки (secpol.msc), тоді загляньте в журнал подій безпеки для події. Ви також можете ввімкнути це за допомогою групової політики, якщо це буде кращим.

Буде розділ Інформація про процес, який записує і виконавчий шлях, і ідентифікатор процесу.

Приклад:

Process Information:
    Process ID:         0x2a4
    Process Name:       C:\Windows\System32\services.exe

Я сьогодні витрачаю багато часу і з’ясовую першопричину. Я пішов неправильним шляхом - із захопленої інформації з мережевим sniffer (ідентифікатор помилки kerberos був 566 = lsass.exe). Дозвольте узагальнити інформацію.

1. Увійдіть на проблемний ПК, запустіть паттерн з підвищеними правами

2. Увімкнути вхід у систему аудиту

   auditpol /set /subcategory:"logon" /failure:enable

3. Перевірте джерело

   Get-WinEvent -Logname 'Security' -FilterXPath "*[System[EventID=4625]]" -MaxEvents 2 | fl

Якщо ви бачите:

Інформація про процес:

ID процесу виклику: 0x140

Назва процесу виклику: C: \ Windows \ System32 \ services.exe

Це означає, що у вас є служба, яка працює з проблемного облікового запису зі старим паролем

Я знайшов це старе питання під час дослідження іншого питання, але для тих, хто має подібне питання:

Код відмови 0x18 означає, що обліковий запис було вже вимкнено або заблоковано, коли клієнт намагався пройти автентифікацію.

Потрібно знайти той самий ідентифікатор події з кодом відмови 0x24 , який ідентифікує невдалі спроби входу, які призвели до блокування облікового запису. (Це передбачає, що воно виникає через неправильний кешований пароль десь.)

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

Існує безліч кодів відмов, тому вам слід шукати що-небудь крім 0x18, щоб визначити, що спричинило блокування облікового запису, якщо немає подій з кодами 0x24. Я вважаю, що єдиний тип відмови, який призведе до блокування, - це 0x24 (неправильний пароль), але я можу помилитися.

Kerberos 0x18 - це справді погана спроба пароля.

Kerberos 0x12 - це вимкнено, втрачено чинність, заблоковано чи обмежено години входу.

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4771

Це зверху примітки. Схоже, ініціатор цієї публікації заявив у своєму останньому коментарі. Процес виклику Java vpxd.exe.

Подальші зауваження Так. Аудити входу в систему "Успіх / Невдача" увімкнено для відповідного постійного струму - жодних подій відмови не реєструються, поки акаунт фактично не заблокований.

Подальше копання показує, що LSASS.exe здійснює виклик KERBEROS у відповідний DC, коли обліковий запис розблоковано. Йому передує (як правило) java, який, схоже, називається vpxd.exe, що є процесом vCenter. Але, коли я дивлюся на інший "server2", якщо блокування облікового запису може (також) траплятися, я ніколи не бачу виклику lsass.exe і породжуються лише апаш-процеси. Єдине відношення, яке вони мають, - це те, що SERVER2 є частиною кластера vSphere SERVER1 (server1 є vSphere OS).