Chúng tôi có một tài khoản miền đang bị khóa thông qua 1 trong 2 máy chủ. Kiểm toán tích hợp chỉ cho chúng ta biết rất nhiều (đã bị khóa từ SERVER1, SERVER2).

Tài khoản sẽ bị khóa trong vòng 5 phút, dường như khoảng 1 yêu cầu mỗi phút.

Ban đầu, tôi đã thử chạy procmon (từ sysiternals) để xem liệu có bất kỳ PROCESS START mới nào được sinh ra sau khi tôi mở khóa tài khoản không. Không có gì đáng ngờ xuất hiện. Sau khi chạy procmon trên máy trạm của tôi và nâng lên trình bao UAC (conscent.exe), có vẻ như từ ngăn xếp đó ntdll.dllvà rpct4.dllđược gọi khi bạn cố gắng tự động chống lại AD (không chắc chắn).

Có cách nào để thu hẹp quá trình nào gây ra yêu cầu xác thực cho DC của chúng tôi không? Nó luôn luôn là cùng một DC vì vậy chúng tôi biết nó phải là một máy chủ trong trang web đó. Tôi có thể thử tìm kiếm các cuộc gọi trong wireshark, nhưng tôi không chắc điều đó sẽ thu hẹp quá trình nào thực sự kích hoạt nó.

Không có dịch vụ, ánh xạ ổ đĩa hoặc tác vụ theo lịch trình đang sử dụng tài khoản miền đó - vì vậy nó phải là thứ có tín dụng tên miền được lưu trữ. Không có phiên RDP mở nào với tài khoản miền đó trên bất kỳ máy chủ nào (chúng tôi đã kiểm tra).

Ghi chú thêm

Có, Kiểm tra đăng nhập "Thành công / thất bại" được bật trên DC được đề cập - không có sự kiện lỗi nào được ghi lại cho đến khi tài khoản thực sự bị khóa.

Việc đào thêm cho thấy LSASS.exethực hiện KERBEROScuộc gọi tới DC sau khi tài khoản được mở khóa. Nó đi trước (nói chung) bởi java mà dường như được gọi vpxd.exelà quá trình vCenter. NHƯNG, khi tôi nhìn vào "server2" khác là khóa tài khoản có thể (cũng) xảy ra, tôi không bao giờ thấy một cuộc gọi đến lsass.exevà chỉ các quá trình apache đang được sinh ra. Mối quan hệ duy nhất mà hai người có là SERVER2 là một phần của cụm vSphere của SERVER1 (server1 là một vSphere OS).

Lỗi trên DC

Vì vậy, có vẻ như tất cả những gì tôi sẽ được AD nói rằng đó là lỗi Kerberos trước khi tự động. Tôi đã kiểm tra và không có vé nào klistvà thực hiện mọi việc chỉ trong trường hợp. Vẫn không có ý tưởng gì gây ra lỗi kerberos này.

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.

Sự kiện đăng nhập ghi lại quá trình cố gắng đăng nhập. Cho phép kiểm tra đăng nhập thất bại (Cài đặt bảo mật> Chính sách cục bộ> Chính sách kiểm toán> Sự kiện đăng nhập kiểm toán) trong Chính sách bảo mật cục bộ (secpol.msc) sau đó xem nhật ký sự kiện bảo mật cho một sự kiện. Bạn cũng có thể kích hoạt nó thông qua Chính sách nhóm, nếu điều đó thích hợp hơn.

Sẽ có một phần Thông tin quy trình ghi lại cả đường dẫn thực thi và ID tiến trình.

Thí dụ:

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

Tôi tìm thấy câu hỏi cũ này trong khi nghiên cứu một vấn đề khác, nhưng đối với bất kỳ ai có vấn đề tương tự:

Mã lỗi 0x18 có nghĩa là tài khoản đã bị vô hiệu hóa hoặc bị khóa khi khách hàng cố gắng xác thực.

Bạn cần tìm ID sự kiện tương tự với mã lỗi 0x24 , mã này sẽ xác định các lần đăng nhập thất bại khiến tài khoản bị khóa. (Điều này giả định rằng nó đang xảy ra do mật khẩu được lưu trong bộ nhớ cache ở đâu đó.)

Sau đó, bạn có thể xem Địa chỉ khách hàng trên các sự kiện đó để xem hệ thống nào đang chuyển các thông tin xấu. Từ đó, bạn phải tìm hiểu xem đó có phải là dịch vụ có mật khẩu cũ, ổ đĩa mạng được ánh xạ, v.v.

Có nhiều loại mã lỗi, vì vậy bạn nên tìm kiếm bất cứ thứ gì ngoài 0x18 để xác định nguyên nhân gây ra khóa tài khoản nếu không có sự kiện nào với mã 0x24. Tôi tin rằng loại thất bại duy nhất sẽ dẫn đến khóa là 0x24 (mật khẩu xấu), nhưng tôi có thể sai.

Kerberos 0x18 thực sự là một nỗ lực mật khẩu xấu.

Kerberos 0x12 bị vô hiệu hóa tài khoản, hết hạn, bị khóa hoặc hạn chế giờ đăng nhập.

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

Tôi đã dành rất nhiều thời gian ngày hôm nay và tìm hiểu nguyên nhân gốc rễ. Tôi đã đi sai đường - từ thông tin bị bắt với sniffer mạng (id quá trình lỗi kerberos là 566 = lsass.exe). Hãy để tôi tóm tắt thông tin.

1. Đăng nhập vào PC có vấn đề, chạy powershell với quyền nâng cao

2. Cho phép đăng nhập kiểm toán

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

3. Kiểm tra nguồn

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

Nếu bạn thấy:

Thông tin quy trình:

ID tiến trình người gọi: 0x140

Tên quy trình người gọi: C: \ Windows \ System32 \ services.exe

Điều đó có nghĩa là bạn có một số dịch vụ chạy từ tài khoản có vấn đề với mật khẩu cũ

Đây là từ ghi chú ở trên. Có vẻ như người khởi xướng bài đăng này đã nêu trên bình luận cuối cùng của mình. Quá trình gọi Java vpxd.exe.

Ghi chú thêm Có, Kiểm tra đăng nhập "Thành công / thất bại" được bật trên DC được đề cập - không có sự kiện lỗi nào được ghi lại cho đến khi tài khoản thực sự bị khóa.

Việc đào sâu hơn cho thấy LSASS.exe thực hiện cuộc gọi KERBEROS tới DC được đề cập sau khi tài khoản được mở khóa. Nó đi trước (nói chung) bởi java dường như được gọi bởi vpxd.exe, đây là một quá trình vCenter. NHƯNG, khi tôi nhìn vào "server2" khác là khóa tài khoản có thể (cũng) xảy ra, tôi không bao giờ thấy một cuộc gọi đến lsass.exe và chỉ có các quá trình apache được sinh ra. Mối quan hệ duy nhất mà hai người có là SERVER2 là một phần của cụm vSphere của SERVER1 (server1 là một vSphere OS).