Mamy konto domeny, które jest blokowane przez 1 z 2 serwerów. Wbudowana kontrola tylko tyle nam mówi (zablokowane z SERVER1, SERVER2).

Konto zostaje zablokowane w ciągu 5 minut, wydaje się, że około 1 żądanie na minutę.

Początkowo próbowałem uruchomić procmon (z sysinternals), aby sprawdzić, czy po odblokowaniu konta pojawił się nowy PROCES START. Nie pojawia się nic podejrzanego. Po uruchomieniu procmon na mojej stacji roboczej i podniesieniu do powłoki UAC (conscent.exe) wydaje się, że ze stosu ntdll.dlli jest rpct4.dllwywoływany przy próbie uwierzytelnienia przeciwko AD (nie jestem pewien).

Czy istnieje możliwość zawężenia procesu, który powoduje żądanie uwierzytelnienia do naszego DC? Zawsze jest to ten sam kontroler domeny, więc wiemy, że musi to być serwer w tej witrynie. Mógłbym spróbować poszukać połączeń w wireshark, ale nie jestem pewien, czy zawęziłoby to, który proces faktycznie go uruchamia.

Żadne usługi, mapowania dysków ani zaplanowane zadania również nie korzystają z tego konta domeny - więc musi to być coś, co ma zapisane poświadczenia domeny. Na żadnym serwerze nie ma otwartych sesji RDP z tym kontem domeny (sprawdziliśmy).

Dalsze uwagi

Tak, kontrole logowania „Sukces / Niepowodzenie” są włączone na danym kontrolerze - żadne zdarzenia awarii nie są rejestrowane, dopóki konto nie zostanie zablokowane.

Dalsze kopanie pokazuje, że LSASS.exenawiązuje KERBEROSpołączenie z danym kontem DC po odblokowaniu konta. Poprzedza go (ogólnie) java, która wydaje się być wywoływana przez vpxd.exeproces vCenter. ALE, kiedy patrzę na inny „serwer2”, z którego może (również) nastąpić blokada konta, nigdy nie widzę połączenia lsass.exei tylko procesy apache są odradzane. Jedyną relacją między nimi jest to, że SERVER2 jest częścią klastra vSphere SERVER1 (serwer1 jest systemem operacyjnym vSphere).

Błąd na DC

Wygląda więc na to, że AD powie mi tylko, że jest to błąd Kerberos przed autoryzacją. Sprawdziłem i nie było żadnych biletów, klisti tak czy inaczej zrobiłem kolor. Nadal nie mam pojęcia, co powoduje ten błąd 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.

Zdarzenia logowania rejestrują proces próby logowania. Włącz inspekcję nieudanego logowania (Ustawienia zabezpieczeń> Zasady lokalne> Zasady inspekcji> Audytuj zdarzenia logowania) w lokalnych zasadach bezpieczeństwa (secpol.msc), a następnie wyszukaj zdarzenie w dzienniku zdarzeń bezpieczeństwa. Możesz to również włączyć za pomocą Zasad Grupy, jeśli byłoby to preferowane.

Pojawi się sekcja Informacje o procesie, która rejestruje zarówno ścieżkę wykonywalną, jak i identyfikator procesu.

Przykład:

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

Spędziłem dziś dużo czasu i odkryłem przyczynę. Poszedłem nie tak - z przechwyconych informacji za pomocą sieciowego sniffera (identyfikator procesu błędu kerberos to 566 = lsass.exe). Pozwól, że streszczę informacje.

1. Zaloguj się na problematycznym komputerze, uruchom PowerShell z podwyższonymi uprawnieniami

2. Włącz logowanie kontrolne

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

3. Sprawdź źródło

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

Jeśli zobaczysz:

Przetwarzać informacje:

Identyfikator procesu dzwoniącego: 0x140

Nazwa procesu wywołującego: C: \ Windows \ System32 \ services.exe

Oznacza to, że masz usługę uruchomioną z konta problemowego ze starym hasłem

Znalazłem to stare pytanie podczas badania innego problemu, ale dla każdego, kto ma podobny problem:

Kod błędu 0x18 oznacza, że ​​konto zostało już wyłączone lub zablokowane, gdy klient próbował się uwierzytelnić.

Musisz znaleźć ten sam identyfikator zdarzenia z kodem błędu 0x24 , który zidentyfikuje nieudane próby logowania, które spowodowały zablokowanie konta. (Zakłada się, że występuje ono z powodu złego buforowanego hasła.)

Następnie możesz spojrzeć na adres klienta tych zdarzeń, aby zobaczyć, który system przekazuje złe dane uwierzytelniające. Następnie musisz dowiedzieć się, czy jest to usługa ze starym hasłem, zmapowany dysk sieciowy itp.

Istnieje wiele kodów błędów, więc powinieneś poszukać czegoś poza 0x18, aby ustalić, co spowodowało blokadę konta, jeśli nie ma zdarzeń o kodach 0x24. Uważam, że jedynym typem awarii, która doprowadzi do blokady, jest 0x24 (złe hasło), ale mogę się mylić.

Kerberos 0x18 to rzeczywiście próba złego hasła.

Kerberos 0x12 jest wyłączony, wygasł, zablokowany lub ograniczenia godzin logowania do konta.

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

To z powyższych notatek. Wygląda na to, że inicjator tego postu stwierdził w swoim ostatnim komentarzu. Java wywołuje proces vpxd.exe.

Dalsze uwagi Tak, Audyty logowania „Sukces / Niepowodzenie” są włączone na danym kontrolerze domeny - żadne zdarzenia awarii nie są rejestrowane, dopóki konto nie zostanie zablokowane.

Dalsze kopanie pokazuje, że LSASS.exe wykonuje połączenie KERBEROS z tym kontem DC po odblokowaniu konta. Poprzedza go (ogólnie) java, która wydaje się być wywoływana przez vpxd.exe, który jest procesem vCenter. ALE, kiedy patrzę na inne „server2”, z którego może (również) nastąpić blokada konta, nigdy nie widzę połączenia z lsass.exe i odradzają się tylko procesy apache. Jedyną relacją między nimi jest to, że SERVER2 jest częścią klastra vSphere SERVER1 (serwer1 jest systemem operacyjnym vSphere).