Chính sách kiểm toán bảo mật Windows và điều tra nhật ký sự kiện trên thực tế — trở thành đội IT đọc được sự kiện 4625

“Từ tối qua một tài khoản cứ bị khóa liên tục. Hãy tìm nguyên nhân.” “Tôi muốn kiểm xem có ai đang thử đăng nhập bằng tài khoản của nhân viên đã nghỉ.” “Máy chủ này, có biết được khi nào ai đã chạy gì không?” — đó là những yêu cầu mà nhân viên IT doanh nghiệp vừa và nhỏ, hoặc nhà phát triển đã bàn giao hệ thống cho khách, bất ngờ nhận một ngày. Và thứ họ bám vào lúc đó là nhật ký sự kiện Security của Windows.

Nhưng khi thật sự mở Trình xem sự kiện, hai thực tế đang chờ. Sự kiện bạn muốn xem chưa từng được ghi (chính sách kiểm toán chưa bật), hoặc nó bị chôn dưới núi sự kiện không đọc nổi (ngập nhiễu và phình to). Kiểm toán bảo mật là thứ “bật thì ghi được”, nhưng nếu không thiết kế ghi cái gì và tới đâu, nó không giúp gì vào lúc bạn thật sự cần.

flowchart TB
    accTitle: Hai thực tế chờ trong Trình xem sự kiện
    accDescr: Khi mở Trình xem sự kiện có hai thực tế, hoặc chính sách kiểm toán chưa bật nên sự kiện cần xem không được ghi, hoặc nhật ký phình vì nhiễu nên sự kiện bị chôn dưới khối lượng lớn và không đọc được, vì thế cần thiết kế ghi cái gì và tới đâu
    open["Mở Trình xem sự kiện"] --> real{"Thực tế đang chờ là?"}
    real -->|Chưa được ghi| none["Sự kiện cần xem chưa được ghi"]
    real -->|Bị chôn| noise["Không đọc được vì quá nhiều sự kiện"]
    none -.-> cause1["Chính sách kiểm toán đang tắt"]
    noise -.-> cause2["Phình vì nhiễu"]
    none --> design["Thiết kế ghi cái gì và tới đâu"]
    noise --> design

Hình 1: “Chưa được ghi” hay “bị chôn nên không đọc được”. Cả hai đều do chưa thiết kế phạm vi ghi.

Bài viết này sắp xếp, dựa trên nguồn gốc tính đến tháng 8 năm 2026, cơ chế chính sách kiểm toán (hai hệ — cơ bản và nâng cao), các danh mục phụ nên bật tối thiểu trong môi trường vừa và nhỏ, cách đọc các ID sự kiện quen thuộc 4624/4625/4740/4688, thiết kế dung lượng nhật ký Security, và cách điều tra bằng PowerShell. Nếu các bài kiểm toán NTLM, SMB signing, BitLocker, và firewall trên site này là chuyện “siết phòng thủ”, bài này là chuyện “để sau này xác nhận được chuyện gì đã xảy ra” — phần tiếp nối buộc chúng lại với nhau.

1. Kết luận trước

• Chính sách kiểm toán có hai hệ — “cơ bản” và “nâng cao (Advanced Audit Policy)” — và không được trộn. Microsoft ghi rõ dùng cả hai để kết quả kiểm toán ở trạng thái không lường trước. Hãy thống nhất về phía nâng cao (hơn 40 danh mục phụ).¹
• Kiểm trạng thái hiện tại bằng auditpol /get /category:*. Lệnh này liệt kê cái đang thật sự có hiệu, bất kể đến từ GPO hay thiết lập cục bộ.²
• “Bật hết” là điều tuyệt đối không làm. Bật các danh mục phụ sinh khối lượng sự kiện khổng lồ sẽ chôn sự kiện thật sự quan trọng dưới nhiễu, và còn ảnh hưởng hiệu năng. Hãy xuất phát từ khuyến nghị baseline của Microsoft rồi chỉ thêm cái cần.³⁴
• Đăng nhập thành công là 4624; thất bại là 4625. Với 4624, hãy đọc “đó là kiểu đăng nhập nào” từ Logon Type (2 = Interactive, 3 = Network, 10 = RemoteInteractive, v.v.).⁵
• Với 4625, mã Status/Sub Status cho biết lý do thất bại. Các mã quen thuộc: 0xC0000064 = tên người dùng không tồn tại, 0xC000006A = sai mật khẩu, 0xC0000072 = tài khoản đã vô hiệu, 0xC0000234 = tài khoản đang bị khóa.⁶
• Chỗ sự kiện được ghi là cố định. 4624/4625 được ghi trên máy bị truy cập; xác thực thông tin đăng nhập (4776) và thất bại tiền xác thực Kerberos (4771) được ghi trên domain controller. Xem nhầm máy sẽ chẩn đoán sai rằng “không có nhật ký”.⁶⁷⁸
• Một nửa thiết kế nhật ký Security là khung chứa — kích thước tối đa và lưu giữ. Nếu lưu giữ đặt ghi đè, sự kiện cũ biến mất trước. Kiểm kích thước tối đa và số bản ghi bằng Get-WinEvent -ListLog Security, rồi mở rộng bằng cách tính ngược từ số ngày bạn thật sự cần giữ.⁹¹⁰
• Ghi dòng lệnh cho tạo tiến trình (4688) rất mạnh, nhưng đổi lại bằng rủi ro bí mật nằm trong nhật ký ở dạng văn bản thuần. Hãy rà tập lệnh trước khi bật.¹¹¹²

2. Cơ sở chính sách kiểm toán — đừng trộn “cơ bản” và “nâng cao”

Chính sách kiểm toán Windows có hai hệ.¹

• Chính sách kiểm toán cơ bản: chín thiết lập danh mục dưới “Local Policies > Audit Policy”. Đây là hệ cũ, có từ trước Windows Vista.
• Advanced Audit Policy Configuration: hơn 40 thiết lập danh mục phụ dưới “Security Settings > Advanced Audit Policy Configuration”. Nó tách mỗi danh mục cơ bản thành vài danh mục phụ — ví dụ, một danh mục cơ bản “Audit account logon events” tương ứng bốn danh mục phụ phía nâng cao. Bật một danh mục cơ bản có cùng hiệu ứng với bật hết các danh mục phụ tương ứng, nên ghi cả khối sự kiện bạn có thể chẳng quan tâm.¹

Điểm quan trọng là hai hệ này không tương thích với nhau. Microsoft nói thẳng: “Đừng dùng cả chính sách kiểm toán cơ bản lẫn nâng cao — làm vậy có thể để kết quả kiểm toán ở trạng thái không lường trước.” Khi chính sách kiểm toán nâng cao được áp qua Group Policy, thiết lập kiểm toán hiện có của máy đó bị xóa trước rồi thiết lập nâng cao mới được áp; từ đó trở đi chỉ phía nâng cao điều khiển kiểm toán một cách đáng tin. Ở môi trường dùng phía nâng cao, hãy bật tùy chọn bảo mật “Audit: Force audit policy subcategory settings to override audit policy category settings” để thiết lập cơ bản không ghi đè được (trên máy độc lập tùy chọn này bật theo mặc định).¹⁴

flowchart TB
    accTitle: Quan hệ giữa chính sách kiểm toán cơ bản và nâng cao
    accDescr: Chính sách kiểm toán cơ bản và chính sách kiểm toán nâng cao không tương thích, dùng cả hai để kết quả kiểm toán ở trạng thái không lường trước, nên thống nhất về phía nâng cao và bật ép thiết lập danh mục phụ để ngăn ghi đè từ phía cơ bản
    basic["Chính sách kiểm toán cơ bản（9 danh mục）"] --> both{"Dùng cả hai?"}
    adv["Chính sách kiểm toán nâng cao（hơn 40 danh mục phụ）"] --> both
    both -->|Có| bad["Kết quả kiểm toán không lường trước"]
    both -->|Không| unify["Thống nhất về phía nâng cao"]
    unify --> force["Bật ép thiết lập danh mục phụ"]
    force -.-> guard["Ngăn ghi đè từ phía cơ bản"]

Hình 2: Hai hệ không tương thích. Thống nhất về phía nâng cao, và dùng thiết lập “ép” để ngăn phía cơ bản ghi đè.

Kiểm trạng thái hiện tại chỉ một lệnh, chạy từ command prompt quản trị.²

rem liệt kê thiết lập kiểm toán đang có hiệu, theo danh mục phụ
auditpol /get /category:*

rem sao lưu thiết lập hiện tại ra CSV trước khi đổi, rồi khôi phục
auditpol /backup /file:C:\logs\auditpol-backup.csv
auditpol /restore /file:C:\logs\auditpol-backup.csv

Đầu ra của auditpol là “chính sách đang có hiệu như kết quả”, bất kể nguồn là GPO hay thiết lập cục bộ. Nó cũng hữu ích để đối chiếu khi thiết lập đáng lẽ phân phối bằng GPO lại không phản ánh. Lưu ý rằng chính thay đổi thiết lập kiểm toán được ghi thành sự kiện 4719, nên “kiểm toán bị tắt mà không ai hay” cũng truy được sau.¹²

flowchart TB
    accTitle: auditpol hiện chính sách kết quả
    accDescr: Đầu ra của auditpol là chính sách kiểm toán đang có hiệu như kết quả, bất kể nguồn GPO hay thiết lập cục bộ, dùng được để đối chiếu khi thiết lập GPO không phản ánh, còn chính thay đổi thiết lập kiểm toán thì sự kiện 4719 cho phép truy sau
    gpo["Thiết lập phân phối bằng GPO"] --> eff["Chính sách đang có hiệu như kết quả"]
    local["Thiết lập cục bộ"] --> eff
    eff --> get["Liệt kê bằng auditpol /get"]
    get -.-> diff["Dùng đối chiếu khi GPO chưa phản ánh"]
    change["Thay đổi chính thiết lập kiểm toán"] -.-> e4719["4719 được ghi và truy được sau"]

Hình 3: auditpol trả “thiết lập đang có hiệu” bất kể nguồn. Chính thay đổi thiết lập kiểm toán còn lại ở 4719.

3. Bảng quyết định các danh mục phụ nên bật tối thiểu

Lý do “cứ bật hết cho chắc” là nước cờ dở thì rõ. Ví dụ, Microsoft cảnh báo rằng kiểm toán cả thành công cho các danh mục phụ dùng đặc quyền sinh khối lượng sự kiện khổng lồ tới mức khó tìm các mục khác trong nhật ký bảo mật, và còn ảnh hưởng hiệu năng.⁴ Khung chứa nhật ký (Chương 5) là hữu hạn, nên càng ghi nhiễu, số ngày lưu giữ của sự kiện bạn thật sự cần càng bị cắt. Thiết kế kiểm toán thật ra là quyết định cái gì không ghi.

flowchart TB
    accTitle: Vì sao bật hết là nước cờ dở
    accDescr: Bật mọi danh mục phụ sinh khối lượng sự kiện lớn, chôn sự kiện then chốt dưới nhiễu, ảnh hưởng hiệu năng, và vì khung chứa nhật ký hữu hạn nên số ngày lưu giữ sự kiện cần thiết cũng bị cắt
    all["Bật mọi danh mục phụ"] --> flood["Sinh khối lượng sự kiện lớn"]
    flood --> noise["Sự kiện then chốt bị chôn"]
    flood --> perf["Ảnh hưởng hiệu năng"]
    flood --> keep["Số ngày lưu giữ bị cắt"]
    noise --> lesson["Quyết cái không ghi mới là thiết kế kiểm toán"]
    perf --> lesson
    keep --> lesson

Hình 4: “Bật hết” chôn sự kiện then chốt. Quyết cái không ghi mới là thiết kế kiểm toán.

Microsoft công bố khuyến nghị baseline và khuyến nghị siết hơn, tách theo máy trạm và máy chủ, và đó là điểm xuất phát.³ Từ đó, bảng dưới sắp xếp theo góc nhìn môi trường vừa và nhỏ: “tối thiểu ta muốn đọc được gì khi có sự cố”.

Ngược lại, nói chung an toàn hơn nếu mặc định không đụng kiểm toán truy cập đối tượng hệ thống tệp hay registry, dùng đặc quyền, hay các danh mục phụ lọc gói (5152 và tương tự). Chúng hữu ích khi bạn thu hẹp bằng cấu hình SACL nhắm đích, hoặc chỉ trong kỳ phân tách có hạn — chứ không phải thứ để luôn mở hết; làm vậy sẽ nuốt sạch nhật ký.⁴

flowchart TB
    accTitle: Cách xử lý danh mục phụ khối lượng lớn
    accDescr: Kiểm toán truy cập đối tượng hệ thống tệp hay registry, dùng đặc quyền, và lọc gói nếu luôn mở hết sẽ nuốt nhật ký, nên chúng chỉ hữu ích với SACL thu hẹp đối tượng hoặc chỉ trong kỳ phân tách
    heavy["Danh mục phụ khối lượng lớn"] --> use{"Bật thế nào?"}
    heavy -.-> ex1["Kiểm toán truy cập đối tượng"]
    heavy -.-> ex2["Dùng đặc quyền và lọc gói"]
    use -->|Luôn mở hết| eat["Nuốt sạch nhật ký"]
    use -->|SACL thu hẹp đối tượng| ok1["Hữu ích"]
    use -->|Chỉ trong kỳ phân tách| ok2["Hữu ích"]

Hình 5: Đừng luôn mở hết truy cập đối tượng hay dùng đặc quyền. Chỉ hữu ích khi thu hẹp đối tượng và thời gian.

4. Cách đọc các ID sự kiện quen thuộc

4.1. 4624 — đăng nhập thành công được đọc theo Logon Type

4624, “An account was successfully logged on”, được ghi trên máy nơi phiên đăng nhập được tạo (máy bị truy cập).⁵ Vì đây là sự kiện khối lượng lớn, bước đầu khi đọc là phân loại theo Logon Type.⁵

Các trường nên xem kèm là tên tài khoản dưới “New Logon”, địa chỉ nguồn dưới “Network Information”, “Authentication Package” (NTLM hay Kerberos), và “Elevated Token” (phiên có đặc quyền quản trị hay không). Nếu chỉ muốn lần các lần đăng nhập với đặc quyền quản trị, sự kiện 4672 (Special privileges assigned to new logon), ghi dưới cùng Logon ID, cũng hữu ích.⁵

flowchart TB
    accTitle: Thủ tục đọc tách 4624
    accDescr: 4624 được ghi rất nhiều nên trước hết phân loại theo Logon Type, rồi kiểm tên tài khoản và nguồn, gói xác thực, Elevated Token, còn đăng nhập đặc quyền quản trị thì đối chiếu với 4672 cùng Logon ID
    ev["4624 đăng nhập thành công"] --> type["Phân loại theo Logon Type"]
    type --> fields["Kiểm các trường chính"]
    fields -.-> f1["Tên tài khoản và nguồn"]
    fields -.-> f2["Gói xác thực"]
    fields -.-> f3["Elevated Token"]
    fields --> admin["Lần đăng nhập đặc quyền quản trị"]
    admin -.-> e4672["4672 cùng Logon ID"]

Hình 6: 4624 được phân loại theo Logon Type rồi mới đọc trường. Đăng nhập đặc quyền đối chiếu với 4672.

4.2. 4625 — chốt lý do thất bại bằng mã Status/Sub Status

4625, “An account failed to log on”, được ghi trên máy nơi lần đăng nhập được thử.⁶ Đáng tin hơn là đọc mã hex Status/Sub Status, chứ không tin vào câu chữ của trường “Failure Reason”. Các mã quen thuộc như sau.⁶

• 0xC0000064: Tên người dùng không tồn tại. Dồn dập trong cửa sổ ngắn có thể là dấu hiệu tấn công liệt kê tài khoản
• 0xC000006A: Sai mật khẩu. Thất bại lặp vào một tài khoản cụ thể có thể là dấu hiệu đoán mật khẩu
• 0xC000006D: Tên người dùng hoặc thông tin xác thực không hợp lệ
• 0xC000006F: Ngoài giờ đăng nhập được phép
• 0xC0000070: Từ máy trạm không được phép
• 0xC0000072: Tài khoản bị quản trị viên vô hiệu (lần thử vào tài khoản nhân viên đã nghỉ hiện ở đây)
• 0xC000015B: Kiểu đăng nhập được yêu cầu không được phép trên máy này
• 0xC0000193: Tài khoản hết hạn
• 0xC0000234: Đang bị khóa

“Ai, từ đâu, và vì sao thất bại” được chốt bằng bộ ba tài khoản đích, nguồn (tên máy trạm / địa chỉ IP), và mã này. Chương 6 có PowerShell trích cả ba cùng lúc.

flowchart TB
    accTitle: Luồng chốt lý do thất bại của 4625
    accDescr: Lý do thất bại của 4625 được chốt bằng mã hex Status/Sub Status, đọc dấu hiệu tấn công từ xu hướng mã, rồi xác định bằng bộ ba tài khoản đích cộng nguồn cộng mã
    ev["4625 đăng nhập thất bại"] --> code["Kiểm mã Sub Status"]
    code --> sign{"Xu hướng mã là?"}
    sign -->|Liền 0xC0000064| enum["Dấu hiệu liệt kê tài khoản"]
    sign -->|Liền 0xC000006A| guess["Dấu hiệu đoán mật khẩu"]
    sign -->|0xC0000072| disabled["Thử tài khoản nhân viên đã nghỉ"]
    enum --> triple["Chốt bằng bộ ba"]
    guess --> triple
    disabled --> triple
    triple -.-> t1["Tài khoản đích + nguồn + mã"]

Hình 7: Lý do thất bại được chốt bằng mã, rồi đọc cùng tài khoản đích và nguồn thành bộ ba.

4.3. 4740 — nguồn khóa nằm ở “Caller Computer Name”

4740, “A user account was locked out” (danh mục phụ: User Account Management). Trường then chốt của sự kiện này là “Caller Computer Name”, ghi máy tính đã phát lần đăng nhập kích hoạt khóa.¹⁶ Thủ tục chuẩn là xác định máy nguồn từ trường này, rồi săn thông tin đăng nhập cũ vẫn còn trên máy đó. Hầu hết nguyên nhân là thứ cứ dùng thông tin cũ sau khi đổi mật khẩu — thông tin đã lưu, phiên RDP để treo ở trạng thái ngắt, hoặc dịch vụ hay tác vụ đã lên lịch cấu hình bằng mật khẩu cũ.

flowchart TB
    accTitle: Thủ tục chuẩn điều tra khóa tài khoản
    accDescr: Xác định máy nguồn từ Caller Computer Name của 4740, rồi rà thông tin đăng nhập đã lưu, phiên RDP để treo ở trạng thái ngắt, và dịch vụ hay tác vụ dùng mật khẩu cũ trên máy đó
    ev["4740 khóa tài khoản xảy ra"] --> caller["Kiểm Caller Computer Name"]
    caller --> src["Xác định máy nguồn"]
    src --> sweep["Rà thông tin đăng nhập cũ"]
    sweep -.-> c1["Thông tin đăng nhập đã lưu"]
    sweep -.-> c2["Phiên RDP để treo ở trạng thái ngắt"]
    sweep -.-> c3["Dịch vụ hay tác vụ dùng mật khẩu cũ"]

Hình 8: Từ “Caller Computer Name” của 4740 xác định nguồn, rồi rà thông tin đăng nhập cũ trên máy đó.

Có một điểm cần để ý. 4625 được ghi trên máy tính đã nhận lần đăng nhập. Nếu nguyên nhân là đăng nhập mạng từ máy nguồn tới, ví dụ, máy chủ tệp, nhật ký Security của chính máy nguồn không còn 4625; dấu vết nằm ở 4625 trên máy chủ đích, hoặc với tài khoản miền ở 4776 (NTLM) hay 4771 (thất bại tiền xác thực Kerberos) trên DC.⁷⁸ Khi “nhật ký trên máy nguồn chẳng có gì”, hãy đi xem phía nhận.

flowchart TB
    accTitle: Máy còn dấu vết thất bại
    accDescr: Thất bại đăng nhập mạng không còn trên chính máy nguồn, mà được ghi thành 4625 trên máy chủ đích đã nhận lần đăng nhập, và với tài khoản miền dấu vết còn ở 4776 hoặc 4771 phía DC
    src["Máy nguồn（bản thân không còn 4625）"] -->|Đăng nhập mạng| target["Máy chủ đích"]
    target -.-> e4625["4625 được ghi"]
    src -->|Xác thực tài khoản miền| dc["Domain controller"]
    dc -.-> e4776["4776（NTLM）/4771（Kerberos）"]

Hình 9: 4625 còn ở phía nhận. Nếu máy nguồn trống, hãy xem máy chủ đích và phía DC.

4.4. Họ 4720 — tạo, sửa tài khoản, và thêm vào nhóm

Các sự kiện quản lý tài khoản nằm thành dãy số liền: 4720 (tạo tài khoản người dùng)¹⁷, 4726 (xóa), 4738 (sửa), rồi phía nhóm là thêm/gỡ thành viên. Lưu ý rằng ID sự kiện cho thay đổi thành viên nhóm phụ thuộc loại nhóm. Nhóm local là 4732/4733, nhóm global là 4728/4729, nhóm universal là 4756/4757.¹⁴ Domain Admins là nhóm global, nên lần thêm vào đó hiện thành 4728 — nếu bạn chỉ cảnh báo 4732, bạn sẽ trượt đúng sự kiện muốn bắt nhất. Ngày thường đây chủ yếu là nhật ký việc help desk, nhưng “người dùng thường đột nhiên được thêm vào nhóm quản trị” hay “một tài khoản không ai biết vừa được tạo” đáng điều tra dù chỉ một lần. Chính Microsoft lấy ví dụ thêm thành viên bất ngờ vào nhóm đặc quyền như sự kiện đáng cảnh báo từng lần.³

flowchart TB
    accTitle: Loại nhóm và sự kiện thêm thành viên
    accDescr: Thêm thành viên vào nhóm tách ID sự kiện theo loại nhóm, local ghi 4732, global ghi 4728, universal ghi 4756, nên lần thêm vào Domain Admins là nhóm global phải xem 4728
    add["Thêm thành viên vào nhóm"] --> kind{"Loại nhóm là?"}
    kind -->|Local| lg["Ghi thành 4732"]
    kind -->|Global| gg["Ghi thành 4728"]
    kind -->|Universal| ug["Ghi thành 4756"]
    gg -.-> da["Thêm vào Domain Admins nằm đây"]
    lg -.-> miss["Chỉ theo 4732 sẽ trượt"]

Hình 10: ID sự kiện thêm thành viên tách theo loại nhóm. Thêm vào Domain Admins là 4728.

4.5. 4688 — tạo tiến trình. Ghi dòng lệnh là công tắc riêng

4688, “A new process has been created”, ghi tài khoản tạo, đường dẫn tệp thực thi của tiến trình mới, tiến trình cha, và kiểu nâng token mỗi lần một tiến trình được tạo.¹¹ Đó là sự kiện giá trị điều tra cao, trả lời được “ai đã chạy gì trên máy chủ này”.

Theo mặc định, tuy nhiên, đối số dòng lệnh không được ghi. Chỉ khi bạn bật riêng thiết lập Group Policy “Include command line in process creation events” (Administrative Templates > System > Audit Process Creation), trường “Process Command Line” của 4688 mới được điền đối số.¹¹¹² Đây gần như bắt buộc để lần các lần khởi chạy đáng ngờ kiểu powershell -EncodedCommand ..., nhưng chỉ bật sau khi đã hiểu rủi ro lộ bí mật mô tả ở Chương 7.

flowchart TB
    accTitle: Quan hệ giữa 4688 và ghi dòng lệnh
    accDescr: Bật kiểm toán tạo tiến trình thì 4688 ghi tài khoản, đường dẫn tệp thực thi, và tiến trình cha, nhưng đối số dòng lệnh chỉ được ghi sau khi bật thêm Group Policy riêng, với rủi ro bí mật nằm ở dạng văn bản thuần
    audit["Bật kiểm toán tạo tiến trình"] --> ev["4688 được ghi"]
    ev -.-> base["Tài khoản, đường dẫn, tiến trình cha"]
    ev --> args{"Cũng muốn xem đối số?"}
    args -->|Để mặc định| none["Dòng lệnh để trống"]
    args -->|Bật thêm GPO| cmd["Đối số được ghi"]
    cmd -.-> risk["Rủi ro bí mật nằm ở dạng văn bản thuần"]

Hình 11: Ghi dòng lệnh của 4688 là công tắc riêng. Trước khi bật hãy rà rủi ro lẫn bí mật.

4.6. 4698 — tạo tác vụ đã lên lịch

4698, “A scheduled task was created”, ghi tên tác vụ và toàn bộ XML định nghĩa tác vụ (gồm lệnh chạy). Vì đăng ký tác vụ đã lên lịch là kỹ thuật quen thuộc malware dùng để sống sót qua khởi động lại, Microsoft khuyến nghị theo dõi sự kiện tạo tác vụ.¹⁵ Dù môi trường dùng nhiều tác vụ đã lên lịch cho nghiệp vụ, bản thân việc tạo không xảy ra mỗi ngày, nên mức nhiễu tương đối nhỏ.

flowchart TB
    accTitle: Persistence bằng đăng ký tác vụ và 4698
    accDescr: Malware thường đăng ký tác vụ đã lên lịch để sống sót sau khởi động lại, nên theo dõi 4698 ghi khi tạo tác vụ cho phép lần tới cả định nghĩa tác vụ gồm lệnh chạy
    mal["Persistence của malware"] --> task["Đăng ký tác vụ để sống sót"]
    task --> ev["4698 được ghi"]
    ev -.-> xml["Toàn bộ XML gồm lệnh chạy"]
    ev --> watch["Phát hiện bằng theo dõi tạo tác vụ"]
    watch -.-> low["Tạo không hàng ngày, nhiễu nhỏ"]

Hình 12: Đăng ký tác vụ — thủ pháp persistence quen thuộc — còn lại ở 4698. XML định nghĩa cho lần tới lệnh chạy.

Một sự kiện nữa đáng nhớ là 1102, “The audit log was cleared.” Xóa nhật ký Security luôn để lại sự kiện này, nên khi thấy “nhật ký trống”, bạn phân tách được sự cố với thao tác thường ngày.¹⁸

flowchart TB
    accTitle: Phân tách xóa nhật ký bằng 1102
    accDescr: Xóa nhật ký Security luôn để lại 1102, nên khi nhật ký trống hãy kiểm có 1102 hay không để phân tách thao tác xóa với khả năng sự cố
    empty["Nhật ký đang trống"] --> rule["Xóa luôn để lại 1102"]
    rule --> check{"Có 1102 không?"}
    check -->|Có| op["Đã có thao tác xóa"]
    check -->|Không| acc["Nghi khả năng sự cố"]

Hình 13: Xóa nhật ký Security luôn để lại 1102. Nhật ký trống được phân tách sự cố hay thao tác theo có 1102 hay không.

5. Thiết kế khung chứa nhật ký — kích thước tối đa và lưu giữ

Trước khi thêm chính sách kiểm toán, hãy kiểm bình nhận. Nhật ký Security có kích thước tối đa và chế độ lưu giữ: ở chế độ ghi đè (cấu hình điển hình), khi đạt kích thước tối đa, sự kiện mới ghi đè sự kiện cũ nhất. Ngược lại, ở chế độ lưu giữ (không ghi đè), khi nhật ký đầy, chính sự kiện mới bị hủy.¹⁰ Cả hai hành vi đều có thể để bạn với “nhật ký cần thiết chẳng còn”, nên nắm trạng thái hiện tại đến trước.

# Kiểm khung chứa nhật ký Security: chế độ lưu giữ, kích thước tối đa, số bản ghi hiện tại
Get-WinEvent -ListLog Security |
    Select-Object LogName, LogMode, MaximumSizeInBytes, RecordCount

# Hiện đang thật sự giữ bao nhiêu ngày (thời điểm sự kiện cũ nhất)
Get-WinEvent -LogName Security -Oldest -MaxEvents 1 |
    Select-Object TimeCreated

Get-WinEvent -ListLog trả cấu hình nhật ký cùng số bản ghi.⁹ Hiệu giữa “thời điểm sự kiện cũ nhất” và thời điểm hiện tại là khoảng lưu giữ thực; nếu thiếu so với yêu cầu (số ngày bạn muốn lần ngược khi điều tra sự cố), hãy mở rộng kích thước tối đa. Bạn cấu hình bằng wevtutil sl Security /ms:<số byte>, hoặc phân phối qua Group Policy.¹⁰

flowchart TB
    accTitle: Thiết kế dung lượng tính ngược từ số ngày lưu giữ
    accDescr: Kiểm cấu hình và số bản ghi bằng ListLog của Get-WinEvent, tính số ngày lưu giữ thực từ thời điểm sự kiện cũ nhất, rồi mở rộng kích thước tối đa nếu thiếu so với số ngày muốn lần ngược khi điều tra sự cố
    check["Kiểm cấu hình và số bản ghi bằng ListLog"] --> oldest["Kiểm thời điểm sự kiện cũ nhất"]
    oldest --> days["Tính số ngày lưu giữ thực"]
    days --> enough{"Đủ yêu cầu?"}
    enough -->|Đủ| keep["Giữ kích thước hiện tại"]
    enough -->|Thiếu| grow["Mở rộng kích thước tối đa"]
    grow -.-> how["Cấu hình bằng wevtutil sl hoặc GPO"]

Hình 14: Xác nhận số ngày đang thật sự còn, rồi tính ngược từ số ngày muốn lần ngược để quyết kích thước tối đa.

Ngoài ra còn tùy chọn bảo mật “Audit: Shut down system immediately if unable to log security audits” (thường gọi CrashOnAuditFail). Khi bật, nếu hệ thống không ghi được sự kiện kiểm toán, nó dừng với lỗi STOP C0000244. Tùy chọn tồn tại cho yêu cầu xác thực tuyệt đối không được mất dấu vết kiểm toán, và mặc định tắt. Chính Microsoft cảnh báo nó có thể bị biến thành DoS, kẻ tấn công cố ý sinh lũ sự kiện để dừng máy chủ — nên không phải thứ bật nhẹ tay trong môi trường vừa và nhỏ điển hình.¹⁹

flowchart TB
    accTitle: Hành vi khi nhật ký đầy
    accDescr: Cấu hình lưu giữ có hai kiểu, chế độ ghi đè và chế độ không ghi đè; khi chế độ không ghi đè khiến không ghi được kiểm toán, nếu CrashOnAuditFail — thiết lập riêng — đang bật thì hệ thống dừng với STOP C0000244
    full["Nhật ký Security đạt kích thước tối đa"] --> mode{"Cấu hình lưu giữ là?"}
    mode -->|Chế độ ghi đè| ow["Sự kiện cũ nhất bị ghi đè"]
    mode -->|Không ghi đè| drop["Sự kiện mới bị hủy"]
    ow -.-> lost["Cả hai đều là nguyên nhân nhật ký biến mất lúc phát hiện"]
    drop -.-> lost
    drop --> caf{"CrashOnAuditFail cũng bật?"}
    caf -->|Có| crash["Dừng với STOP C0000244"]

Hình 15: Cấu hình lưu giữ là ghi đè hoặc hủy. CrashOnAuditFail là thiết lập riêng, dừng hệ thống khi không ghi được.

6. Điều tra trên thực tế — bộ lọc, Get-WinEvent, và xuất

6.1. Thu hẹp trong Trình xem sự kiện

Với điều tra một lần, Trình xem sự kiện là đủ. Mở nhật ký Security và chỉ định ID sự kiện (ví dụ 4625) cùng khoảng thời gian bằng “Filter Current Log”. Lưu điều kiện bạn xem lặp lại thành “Custom View” để lần sau một cú nhấp. Nếu muốn thu hẹp theo tài khoản cụ thể chứ không chỉ ID sự kiện, bạn sửa trực tiếp truy vấn XPath trên tab XML của hộp thoại bộ lọc.

6.2. Trích xuất bằng Get-WinEvent

Với điều tra số bản ghi lớn, nhiều điều kiện, hoặc chạy định kỳ, hãy chuyển sang Get-WinEvent của PowerShell. Điểm mấu chốt là dùng -FilterHashtable, bộ lọc chạy phía máy chủ.⁹

flowchart TB
    accTitle: Phân vai các cách điều tra
    accDescr: Điều tra một lần đủ bằng bộ lọc Trình xem sự kiện, điều kiện xem lặp lại lưu thành Custom View, còn điều tra số lượng lớn hay nhiều điều kiện và chạy định kỳ thì chuyển sang Get-WinEvent
    q{"Điều tra kiểu gì?"}
    q -->|Một lần| viewer["Thu hẹp bằng Trình xem sự kiện"]
    q -->|Điều kiện xem lặp lại| view["Lưu thành Custom View"]
    q -->|Lớn, nhiều điều kiện, định kỳ| ps["Chuyển sang Get-WinEvent"]
    ps -.-> hash["Thu hẹp bằng FilterHashtable"]

Hình 16: Một lần thì Trình xem sự kiện, lặp lại thì Custom View, số lượng lớn thì Get-WinEvent.

# Lấy đăng nhập thất bại (4625) trong 24 giờ qua
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
}

# Định hình "ai, từ đâu, vì sao" thành bảng
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
} | ForEach-Object {
    $x = [xml]$_.ToXml()
    $d = @{}
    $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    [pscustomobject]@{
        Time      = $_.TimeCreated
        Account   = "$($d.TargetDomainName)\$($d.TargetUserName)"
        LogonType = $d.LogonType
        Source    = "$($d.WorkstationName) $($d.IpAddress)"
        Status    = $d.Status
        SubStatus = $d.SubStatus
    }
} | Group-Object Account, Status, SubStatus, Source |
    Sort-Object Count -Descending |
    Format-Table Count, Name -AutoSize

Một khi có mẫu kéo EventData ra từ biểu diễn XML của sự kiện, bạn tái sử dụng nguyên vậy cho 4624 hay 4688. Thiết kế lọc của Get-WinEvent — khi dùng FilterHashtable versus XPath, và cách sửa truy vấn chậm — được trình bày kỹ trong “Điều tra nhật ký sự kiện trên thực tế bằng Get-WinEvent — tốc độ lọc quyết định thời gian điều tra”.

flowchart TB
    accTitle: Mẫu định hình kéo EventData
    accDescr: Mẫu chuyển sự kiện lấy bằng Get-WinEvent sang biểu diễn XML, kéo từng trường EventData rồi định hình thành bảng, tái sử dụng cùng cách cho 4624 hay 4688 chứ không chỉ 4625
    get["Lấy bằng Get-WinEvent"] --> xml["Chuyển sự kiện sang biểu diễn XML"]
    xml --> pull["Kéo EventData"]
    pull --> shape["Định hình bảng rồi tổng hợp"]
    shape -.-> reuse["Cùng cách cho 4624 hay 4688"]

Hình 17: Mẫu kéo EventData từ biểu diễn XML thành bảng tái sử dụng được dù ID sự kiện đổi.

6.3. Xuất bằng wevtutil

Quy tắc với nhật ký trên máy đang điều tra là xuất và giữ một bản trước, trước khi bị ghi đè.¹⁰

rem bảo toàn toàn bộ nhật ký Security thành evtx
wevtutil epl Security C:\logs\security-20260801.evtx

rem xuất chỉ các sự kiện 4625, thu hẹp bằng XPath
wevtutil epl Security C:\logs\security-4625.evtx /q:"*[System[(EventID=4625)]]"

Tệp .evtx đã xuất phân tích được trên máy khác đúng cùng cách, bằng Get-WinEvent -Path C:\logs\security-20260801.evtx.⁹ Thói quen bảo toàn rồi mới phân tích cùng tư duy “giữ dump trước” khi điều tra sự cố (xem “Dẫn nhập thu thập dump sự cố Windows - WER/ProcDump/WinDbg”).

flowchart TB
    accTitle: Luồng bảo toàn rồi mới phân tích
    accDescr: Xuất nhật ký Security của máy đang điều tra thành tệp evtx bằng wevtutil epl để giữ, rồi phân tích cùng cách trên máy khác bằng Path của Get-WinEvent
    target["Máy đang điều tra"] --> export["Bảo toàn thành evtx bằng wevtutil epl"]
    export --> copy["Mang sang máy khác"]
    copy --> analyze["Phân tích bằng Get-WinEvent -Path"]
    export -.-> note["Giữ trước khi bị ghi đè mất"]

Hình 18: Bảo toàn trước, phân tích sau. Giữ thành evtx thì máy khác điều tra được cùng cách.

7. Cạm bẫy — bốn cái dễ giẫm trên hiện trường

(1) Bí mật nằm trên dòng lệnh của 4688. Bật ghi dòng lệnh đưa đối số của mọi tiến trình vào nhật ký Security ở dạng văn bản thuần. Microsoft ghi rõ “mọi người dùng có quyền đọc sự kiện bảo mật đều đọc được đối số dòng lệnh của mọi tiến trình tạo thành công. Đối số dòng lệnh có thể chứa thông tin nhạy cảm hoặc riêng tư như mật khẩu.” ¹² Nếu dù chỉ một ứng dụng nghiệp vụ hay tập lệnh khởi chạy kiểu myapp.exe /user:admin /password:P@ssw0rd, đó là bí mật công bố cho mọi người xem nhật ký. Trước khi bật, hãy rà chỗ truyền bí mật như đối số dòng lệnh rồi sửa. Nơi bạn xuất hay chuyển tiếp nhật ký cũng cần được xử lý ở cùng mức bí mật.

flowchart TB
    accTitle: Thứ tự bật ghi dòng lệnh
    accDescr: Trước khi bật ghi dòng lệnh của 4688 hãy rà ứng dụng nghiệp vụ và tập lệnh đang truyền bí mật như đối số, sửa chỗ đó rồi mới bật, và đòi cùng mức xử lý ở nơi bảo toàn và chuyển tiếp nhật ký
    audit["Rà chỗ truyền bí mật như đối số"] --> found{"Có chỗ nào?"}
    found -->|Có| fix["Sửa chỗ đang truyền"]
    found -->|Không| on["Bật ghi dòng lệnh"]
    fix --> on
    on -.-> dest["Nơi bảo toàn và chuyển tiếp cùng mức xử lý"]

Hình 19: Ghi dòng lệnh là “rà rồi sửa rồi mới bật”. Đảo thứ tự thành công bố bí mật.

(2) Vận hành mà không biết chuyện gì xảy ra khi nhật ký đầy. Ở chế độ ghi đè, bằng chứng cũ lặng lẽ biến mất; ở chế độ không ghi đè, sự kiện mới bị hủy; còn CrashOnAuditFail bật thì cả hệ thống dừng (Chương 5).¹⁰¹⁹ Cách đúng là biết mình đã chọn hành vi nào, rồi đặt cơ chế — xuất định kỳ, hoặc nền tảng thu nhật ký — thu dữ liệu trước khi bị ghi đè.

(3) Domain controller và máy trạm đòi bạn xem nhật ký khác nhau. 4624/4625 được ghi trên máy bị truy cập.⁵⁶ Ngược lại, xác thực thông tin đăng nhập của tài khoản miền (4776 của NTLM) được ghi trên máy có thẩm quyền với thông tin đăng nhập đó — với tài khoản miền, đó là DC⁷ — còn thất bại tiền xác thực Kerberos (4771) chỉ được ghi trên DC.⁸ “Không có 4625 trên máy chủ tệp” không nghĩa “không có tấn công”; bức tranh đầy đủ chỉ có khi bạn còn đối chiếu 4776/4771 trên DC. Xem “Giải thích NTLM và Kerberos bằng hình — vì sao xác thực rơi về NTLM” về luồng thực của từng giao thức xác thực.

(4) Đồng hồ lệch phá đối chiếu. Xếp nhật ký từ vài máy để lần “máy trạm nào sinh 4625 ngay trước 4740 này” chỉ chạy nếu đồng hồ mọi máy khớp. Trong môi trường miền, chính Kerberos đặt trần lệch đồng hồ (mặc định 5 phút); vượt ngưỡng đó thì bản thân xác thực bắt đầu thất bại.²⁰ Về góc điều tra, lệch dù vài giây — chứ đừng nói năm phút — đã có thể làm bạn đọc sai thứ tự sự kiện, nên kiểm trạng thái đồng bộ của w32time phải là bước đầu tiên của thủ tục điều tra. Cũng nhớ dấu thời gian sự kiện được lưu UTC và hiện theo múi giờ của máy đang xem, nên hãy đổi múi giờ khi đọc .evtx mang về từ chi nhánh nước ngoài hoặc máy chủ đặt UTC.

flowchart TB
    accTitle: Đồng bộ thời gian là tiên quyết của điều tra đối chiếu
    accDescr: Điều tra xếp nhật ký nhiều máy theo thời gian giả định đồng hồ mỗi máy khớp, lệch vài giây đã làm đọc sai trước sau, còn lệch quá mặc định 5 phút thì xác thực Kerberos thất bại, nên đưa kiểm w32time vào đầu thủ tục điều tra
    merge["Đối chiếu nhật ký nhiều máy"] --> pre["Tiên quyết là đồng hồ khớp"]
    pre --> skew{"Lệch đồng hồ thế nào?"}
    skew -->|Khớp| ok["Lần được theo thời gian"]
    skew -->|Lệch vài giây| misread["Đọc sai trước sau"]
    skew -->|Vượt mặc định 5 phút| kerb["Xác thực Kerberos thất bại"]
    pre -.-> first["Đưa kiểm w32time vào đầu thủ tục"]

Hình 20: Đối chiếu nhiều máy giả định đồng hồ đã khớp. Lệch vài giây cũng dẫn tới đọc sai trước sau.

8. Tóm tắt

• Chính sách kiểm toán có hai hệ, “cơ bản” và “nâng cao”, và trộn chúng cho kết quả không lường trước. Thống nhất về phía nâng cao, kiểm trạng thái hiện tại bằng auditpol /get /category:*, rồi thiết kế từ đó.
• “Bật hết” giết điều tra bằng nhiễu và phình. Xuất phát từ khuyến nghị baseline của Microsoft và làm việc qua bảng quyết định Chương 3, xoay quanh đăng nhập, quản lý tài khoản, và tạo tiến trình.
• 4624 đọc theo Logon Type, 4625 theo mã Status/Sub Status, 4740 theo Caller Computer Name, 4688 theo tiến trình cha và dòng lệnh — mỗi sự kiện có trường cụ thể bạn cần kiểm.
• Khung chứa nhật ký (kích thước tối đa và chế độ lưu giữ) là một nửa thiết kế kiểm toán. Kiểm số ngày đang thật sự được lưu giữ, định cỡ bằng cách tính ngược từ yêu cầu, rồi xuất hoặc gom trước khi bị ghi đè.
• Rà rủi ro lộ bí mật trước khi bật ghi dòng lệnh cho 4688. Chỗ mỗi sự kiện được ghi, và đồng bộ đồng hồ, là tiên quyết để đối chiếu xuyên máy.
• Bắt đầu điều tra bằng bộ lọc Trình xem sự kiện; chuyển sang Get-WinEvent -FilterHashtable cho thứ lặp lại; bảo toàn bằng wevtutil epl. Đừng phá thứ tự “bảo toàn trước, phân tích sau”.

Bài viết liên quan

• Điều tra nhật ký sự kiện trên thực tế bằng Get-WinEvent — tốc độ lọc quyết định thời gian điều tra
• Việc ngừng NTLM có làm dừng ứng dụng nghiệp vụ không — cách thu nhật ký kiểm toán và thứ tự gỡ phụ thuộc
• Giải thích NTLM và Kerberos bằng hình — vì sao xác thực rơi về NTLM
• SMB Signing và LDAP channel binding — siết nốt “nửa còn lại” của phòng thủ NTLM trên thực tế
• Dẫn nhập Windows Event Log và ETW — đưa nhật ký ứng dụng nghiệp vụ lên cơ chế chuẩn của OS
• Dẫn nhập thu thập dump sự cố Windows - WER/ProcDump/WinDbg

Lĩnh vực tư vấn liên quan

KomuraSoft LLC đảm nhận tư vấn chính sách kiểm toán và thiết kế nhật ký trên Windows, điều tra “khi nào, ai, làm gì” dựa trên nhật ký sự kiện, và phân tích nguyên nhân các sự cố xác thực cùng kiểm toán mà ứng dụng nghiệp vụ gặp. Bắt đầu từ giai đoạn “bảo xem nhật ký nhưng không biết bắt đầu từ đâu” cũng được.

• Điều tra lỗi và nguyên nhân
• Tư vấn kỹ thuật và đánh giá thiết kế
• Liên hệ với chúng tôi

Liên kết tham khảo

Bài viết liên quan

Các bài viết gần đây có cùng thẻ để tìm hiểu sâu hơn những chủ đề lân cận.

Chủ đề liên quan

Các trang này đặt chủ đề trong bối cảnh rộng hơn của dịch vụ và quyết định.

Dịch vụ liên quan đến chủ đề này

Bài viết liên quan trực tiếp đến các dịch vụ sau.

Câu hỏi thường gặp

Các câu hỏi thường gặp khi tư vấn về chủ đề của bài viết.

Chúng tôi chưa cấu hình chính sách kiểm toán nào, vậy sao nhật ký Security đã có 4624 và 4625?

Vì Windows có các danh mục phụ kiểm toán được bật theo mặc định. Ví dụ, danh mục phụ "Logon" đã bật kiểm toán cả thành công lẫn thất bại từ Windows 10 phiên bản 1809, nên 4624 (thành công) và 4625 (thất bại) vẫn được ghi dù bạn không cấu hình gì. Dù vậy, nếu để mặc định, nhiều sự kiện bạn thật sự muốn khi điều tra — như xác thực thông tin đăng nhập (4776) hay tạo tiến trình (4688) — không được ghi. Bạn kiểm cái gì đang bật trên môi trường mình bằng `auditpol /get /category:*`. Từ đó, thực tế chuẩn là bật tường minh các danh mục phụ còn thiếu ở phía chính sách kiểm toán nâng cao.

Tôi muốn điều tra đăng nhập thất bại nhưng không thấy sự kiện 4625 trong nhật ký Security của máy chủ đích. Nên xem ở đâu?

Trước hết hãy xác nhận nguyên tắc: 4625 được ghi trên "máy tính nơi lần đăng nhập được thử". Đăng nhập thất bại tại máy trạm của người dùng thì xem máy trạm đó; truy cập thất bại tới máy chủ tệp thì xem máy chủ tệp. Tiếp theo, dùng `auditpol /get /category:*` để kiểm danh mục phụ "Logon" đã bật kiểm toán thất bại chưa. Với tài khoản miền, dấu vết thường nằm ở xác thực thông tin đăng nhập (4776) hoặc thất bại tiền xác thực Kerberos (4771) trên domain controller; khi không xác định được máy trạm nào, bắt đầu từ phía DC thường nhanh hơn. Nếu vẫn không thấy gì, hãy kiểm sự kiện cũ đã bị ghi đè chưa (so kích thước tối đa của nhật ký với thời điểm sự kiện cũ nhất).

Có nên bật ghi dòng lệnh cho tạo tiến trình (4688) không?

Giá trị điều tra rất cao, nhưng đây là thiết lập chỉ nên bật sau khi đã hiểu rủi ro. Một khi bật, đối số dòng lệnh của mọi tiến trình được ghi vào nhật ký Security ở dạng văn bản thuần. Nếu dù chỉ một tập lệnh hay ứng dụng nghiệp vụ truyền mật khẩu hoặc khóa API như đối số dòng lệnh, bí mật đó hiện với mọi người đọc được nhật ký Security. Chính Microsoft ghi rõ cảnh báo này. Thứ tự khuyến nghị là trước hết kiểm tập lệnh của mình có truyền bí mật như đối số dòng lệnh không, sửa chỗ nào có, rồi mới bật thiết lập.

Kích thước tối đa của nhật ký Security nên là bao nhiêu?

Cách đúng là tính ngược từ "muốn giữ bao nhiêu ngày trong tay", chứ không có con số một-cỡ-cho-mọi-trường-hợp. Bạn kiểm thiết lập hiện tại và hành vi thực bằng `Get-WinEvent -ListLog Security`; hiệu giữa thời điểm sự kiện cũ nhất và thời điểm hiện tại chính là "số ngày đang thật sự được lưu giữ". Thêm danh mục phụ kiểm toán làm tăng khối lượng sự kiện, nên luôn kiểm lại khoảng lưu giữ thực này sau khi đổi thiết lập. Ứng phó sự cố không hiếm khi cần nhật ký từ vài tuần đến vài tháng trước, nên yên tâm hơn nếu xuất nhật ký định kỳ trước khi bị ghi đè, hoặc gom về máy khác bằng cơ chế thu nhật ký.

Điều tra nguyên nhân khóa tài khoản (4740) thế nào?

Manh mối đầu tiên là trường "Caller Computer Name" trong sự kiện 4740. Nó ghi máy tính đã phát lần đăng nhập thất bại kích hoạt khóa. Lưu ý rằng bản ghi thất bại (4625) nằm ở phía nhận lần đăng nhập, không phải máy nguồn. Nếu nguồn là đăng nhập mạng, hãy lần theo thời gian qua 4625 trên máy chủ đích, hoặc với tài khoản miền qua 4776/4771 trên domain controller. Khi đã xác định máy nguồn, hãy rà những thứ vẫn giữ thông tin đăng nhập cũ sau khi đổi mật khẩu — thông tin đã lưu, phiên Remote Desktop để treo ở trạng thái ngắt, hoặc dịch vụ hay tác vụ đã lên lịch cấu hình bằng mật khẩu cũ. Nếu khóa lặp lại, hãy kiểm cả đồng bộ đồng hồ có lệch không.

Hồ sơ tác giả

Trang giới thiệu tác giả bài viết.

Go Komura

Đại diện của KomuraSoft LLC

Chuyên về phát triển phần mềm Windows, tư vấn kỹ thuật và điều tra lỗi, đặc biệt trong các dự án có hệ thống hiện hữu và lỗi khó tái hiện.