Cách tìm nguyên nhân bị khóa tài khoản người dùng trong miền Windows AD

Sau một sự cố gần đây với Outlook, tôi đã tự hỏi làm thế nào tôi có thể giải quyết vấn đề sau một cách hiệu quả nhất:

Giả sử một cơ sở hạ tầng AD nhỏ đến trung bình khá điển hình: một số DC, một số máy chủ nội bộ và máy khách windows, một số dịch vụ sử dụng AD và LDAP để xác thực người dùng từ trong DMZ (chuyển tiếp SMTP, VPN, Citrix, v.v.) và một số nội bộ tất cả các dịch vụ đều dựa vào AD để xác thực (Exchange, máy chủ SQL, máy chủ tệp và in, máy chủ dịch vụ đầu cuối). Bạn có toàn quyền truy cập vào tất cả các hệ thống nhưng chúng có quá nhiều (tính cả khách hàng) để kiểm tra riêng lẻ.

Bây giờ giả sử rằng, vì một số lý do không xác định, một (hoặc nhiều) tài khoản người dùng sẽ bị khóa do chính sách khóa mật khẩu cứ sau vài phút.

• Điều gì sẽ là cách tốt nhất để tìm dịch vụ / máy chịu trách nhiệm cho việc này?
• Giả sử cơ sở hạ tầng là thuần túy, Windows tiêu chuẩn không có công cụ quản lý bổ sung và một vài thay đổi từ mặc định, liệu có cách nào để tìm ra nguyên nhân khóa như vậy có thể được tăng tốc hoặc cải thiện không?
• Những gì có thể được thực hiện để cải thiện khả năng phục hồi của hệ thống chống lại việc khóa tài khoản DOS như vậy? Vô hiệu hóa khóa tài khoản là một câu trả lời rõ ràng nhưng sau đó bạn gặp phải vấn đề người dùng có cách dễ dàng khai thác mật khẩu, ngay cả với sự phức tạp được thi hành.

Thêm một cái gì đó tôi không thấy trong các câu trả lời được đưa ra.

Điều gì sẽ là cách tốt nhất để tìm dịch vụ / máy chịu trách nhiệm cho việc này?

Bạn không thể chỉ xem Nhật ký bảo mật trên PDCe, bởi vì, trong khi PDCe có thông tin cập nhật nhất về việc khóa tài khoản cho toàn bộ miền, thì nó không có thông tin về khách hàng nào (IP hoặc tên máy chủ) các lần đăng nhập thất bại đến từ, giả sử rằng các lần đăng nhập thất bại xảy ra trên một DC khác ngoài PDCe. PDCe sẽ nói rằng "Tài khoản xyz đã bị khóa", nhưng nó sẽ không nói từ đâu, nếu đăng nhập thất bại xảy ra trên một DC khác trong miền. Chỉ có DC thực sự xác thực đăng nhập sẽ ghi lại lỗi đăng nhập, bao gồm cả địa chỉ của khách hàng. (Cũng không đưa RODC vào cuộc thảo luận này.)

Có hai cách tốt để tìm ra nơi mà các lần đăng nhập thất bại đến từ khi bạn có một số bộ điều khiển miền. Chuyển tiếp sự kiện và Công cụ khóa tài khoản của Microsoft .

Tôi thích chuyển tiếp sự kiện đến một vị trí trung tâm. Chuyển tiếp các lần đăng nhập thất bại từ tất cả các bộ điều khiển miền của bạn đến một máy chủ ghi nhật ký trung tâm. Sau đó, bạn chỉ có một nơi để tìm kiếm các đăng nhập thất bại trong toàn bộ miền của bạn. Trên thực tế, cá nhân tôi không thực sự yêu thích các công cụ Khóa tài khoản của Microsoft, vì vậy bây giờ có một cách tốt.

Chuyển tiếp sự kiện. Bạn sẽ yêu nó.

Giả sử cơ sở hạ tầng là thuần túy, Windows tiêu chuẩn không có công cụ quản lý bổ sung và một vài thay đổi từ mặc định, có cách nào để quá trình tìm nguyên nhân của việc khóa như vậy có thể được tăng tốc hoặc cải thiện không?

Xem ở trên. Sau đó, bạn có thể có hệ thống giám sát của mình, chẳng hạn như SCOM hoặc Nagios hoặc bất cứ thứ gì bạn sử dụng, kết hợp nhật ký sự kiện duy nhất đó và làm nổ điện thoại di động của bạn bằng tin nhắn văn bản hoặc bất cứ điều gì. Nó không được tăng tốc nhiều hơn thế.

Những gì có thể được thực hiện để cải thiện khả năng phục hồi của hệ thống chống lại việc khóa tài khoản DOS như vậy?

1. Giáo dục người dùng. Yêu cầu họ ngừng thiết lập các dịch vụ Windows để chạy trong tài khoản người dùng trong miền của họ, đăng xuất khỏi các phiên RDP khi hoàn tất, hướng dẫn họ cách xóa Vault xác thực Windows của mật khẩu được lưu trong bộ nhớ cache cho Outlook, v.v.
2. Sử dụng Tài khoản dịch vụ được quản lý nơi bạn có thể để người dùng không còn phải quản lý mật khẩu cho các tài khoản người dùng đó. Người dùng làm hỏng mọi thứ. Nếu bạn cho người dùng lựa chọn, người đó sẽ luôn chọn sai. Vì vậy, đừng cho họ lựa chọn.
3. Thực thi thời gian chờ phiên từ xa thông qua GPO. Nếu người dùng không sử dụng trong phiên RDP trong 6 giờ, hãy khởi động họ.

Chúng tôi đã có cùng một vấn đề trong khi dọn dẹp tài khoản quản trị viên trong một môi trường lớn hơn một thời gian trước. Mặc dù các bản ghi kiểm toán của DC về mặt kỹ thuật cung cấp thông tin cần thiết, chúng tôi đã quyết định triển khai sản phẩm ADAudit Plus của ManageEngine, quét các bản ghi này và tìm kiếm các lần đăng nhập, cùng với bất kỳ thay đổi nào trong AD. Sử dụng tính năng báo cáo dựng sẵn và một chút công việc của Excel, chúng tôi có thể theo dõi (khá dễ dàng) nơi đăng nhập. Trong trường hợp của chúng tôi, nó chủ yếu liên quan đến quản trị viên đã sử dụng tài khoản quản trị viên thay vì tài khoản dịch vụ khi triển khai các ứng dụng khác nhau.

Những gì có thể được thực hiện để cải thiện khả năng phục hồi của hệ thống chống lại việc khóa tài khoản DOS như vậy?

Bạn không thể.

Có rất nhiều thứ có thể đốt cháy ngôi nhà của bạn. Giống như mã đơn giản để liên tục yêu cầu địa chỉ IP cho đến khi phạm vi DHCP hết. Hoặc mã đơn giản tạo thư mục cho đến khi MFT đầy và bạn phải định dạng lại phân vùng của mình để khôi phục nó. Bạn không thể bảo vệ chống lại mọi thứ.

Một kịch bản phổ biến hơn với khóa máy là những người nhập thông tin đăng nhập của họ vào nhiều loại thiết bị hơn nhiều so với phổ biến chỉ một vài năm trước đây. Chẳng hạn như máy in (để quét email) hoặc điện thoại thông minh hoặc máy tính bảng. Nếu họ quên nơi họ đã nhập thông tin đăng nhập hoặc nếu họ không còn quyền truy cập vào thiết bị, có thể thiết bị đó sẽ tiếp tục cố gắng xác thực mãi mãi. Email auth là một vectơ khó khăn để theo dõi các thiết bị này và ngay cả khi bạn làm như vậy, người dùng có thể không có quyền truy cập vào nó hoặc biết nó ở đâu. IP 10.4.5.27? Tôi biết một người dùng phải gọi bàn trợ giúp mỗi ngày để mở khóa tài khoản của họ, sau đó họ sẽ đăng nhập ngay lập tức và sau đó tài khoản của họ sẽ bị khóa lại. Họ đã làm điều này trong nhiều tháng. Tôi nói với họ để đổi tên tài khoản của họ.

Cuộc sống có những điều không thuận lợi, chúng ta không thể loại bỏ tất cả chúng.