Tìm các tài khoản bị khóa trong Active Directory (một cách thực sự hoạt động!)


8

Tôi đã tìm hiểu cách liệt kê các tài khoản bị khóa và tìm thấy hai phương pháp cho đến nay, cả hai đều không hoạt động ...

Truy vấn đã lưu - (&(&(&(objectCategory=Person)(objectClass=User)(lockoutTime>=1))))

Liệt kê một số tài khoản, nhiều tài khoản không bị khóa. Nếu tôi mở khóa một cái mà tôi tình cờ biết đã bị khóa, nó vẫn bị truy vấn trả về.

Lệnh Powershell - Search-ADAccount -LockedOut

Không lam gi cả.

Vậy tôi cũng đang làm gì đó à? Hoặc - Có một phương pháp thực sự hoạt động?


Chỉ cần một lưu ý nhỏ: Để quản lý miền bằng các lệnh được bao gồm trong mô-đun AD PowerShell (bao gồm cả việc sử dụng lệnh Search-ADAccount), bạn phải cài đặt dịch vụ Active Directory Web Services (ADWS) trên ít nhất một bộ điều khiển miền trong miền này. Nhưng tôi đoán đây không phải là vấn đề vì nếu bạn không có ví dụ ADWS, bạn sẽ nhận được thông báo lỗi thông báo cho bạn về vấn đề đó.
Mikhail

Câu trả lời:


11

Tôi cũng không nhất thiết phải tin tưởng Get-ADUser -LDAPFilter "(&(objectCategory=Person)(objectClass=User)(lockoutTime>=1))" -Properties LockedOut, vì nó cũng không trả lại kết quả đáng tin cậy cho tôi, nhưng sau đó, tôi cũng không thể liên hệ trực tiếp với PDCe của mình vào lúc này. Để có kết quả tốt nhất, bạn sẽ muốn nhắm mục tiêu trực tiếp vào trình giả lập PDC của mình, vì nó luôn có thông tin cập nhật nhất về việc khóa tài khoản trên toàn miền.

Đó là điều tôi đang đặt cược rằng bạn đang chứng kiến ​​ở đây là một sự chậm trễ trong việc nhân rộng:

... khóa tài khoản được nhân rộng khẩn cấp sang chủ sở hữu vai trò giả lập bộ điều khiển miền chính (PDC) và sau đó được nhân rộng khẩn cấp như sau:

• Bộ điều khiển miền trong cùng một miền được đặt trong cùng một trang với trình giả lập PDC.

• Bộ điều khiển miền trong cùng một miền được đặt trong cùng một trang với bộ điều khiển miền đã xử lý khóa tài khoản.

• Bộ điều khiển miền trong cùng một miền được đặt trong các trang web đã được định cấu hình để cho phép thông báo thay đổi giữa các trang web (và do đó, sao chép khẩn cấp) với trang web chứa trình giả lập PDC hoặc với trang web nơi khóa tài khoản được xử lý. Các trang web này bao gồm bất kỳ trang web nào được bao gồm trong cùng một liên kết trang web với trang web chứa trình giả lập PDC hoặc trong cùng một liên kết trang web với trang web chứa bộ điều khiển miền đã xử lý khóa tài khoản.

Ngoài ra, khi xác thực thất bại tại bộ điều khiển miền khác với trình giả lập PDC, xác thực được thử lại tại trình giả lập PDC. Vì lý do này, trình giả lập PDC khóa tài khoản trước bộ điều khiển miền đã xử lý việc thử mật khẩu không thành công nếu đạt đến ngưỡng thử mật khẩu xấu. Để biết thêm thông tin về cách chủ sở hữu vai trò giả lập PDC quản lý thay đổi mật khẩu và khóa tài khoản, hãy xem "Quản lý hoạt động của một chủ nhân linh hoạt" trong cuốn sách này.

Vì vậy, hãy thử Search-ADAccount -LockedOut -Server DC-PDCEvà xem nếu kết quả của bạn là tốt hơn.

Ngoài ra, đây là một cái gì đó khác để xem xét khi xây dựng các truy vấn xung quanh thuộc tính lockoutTime:

Giá trị thuộc tính này chỉ được đặt lại khi tài khoản được đăng nhập thành công. Điều này có nghĩa là giá trị này có thể khác không, nhưng tài khoản không bị khóa. Để xác định chính xác nếu tài khoản bị khóa, bạn phải thêm Thời lượng khóa vào thời điểm này và so sánh kết quả với thời gian hiện tại, chiếm các múi giờ địa phương và thời gian tiết kiệm ánh sáng ban ngày.

Chỉnh sửa: Bằng cách kỹ thuật đảo ngược Microsoft.ActiveDirectory.Management.dll, tôi có thể nói với bạn rằng Search-ADAccount -LockedOut, dường như tôi tạo ra kết quả khá đáng tin cậy, chạy mã sau:

else if ((bool) this._paramSet.LockedOut)
      {
        list.Add(ADAccountFactory<ADAccount>.AttributeTable[cmdletSessionInfo.ConnectedADServerType]["AccountLockoutTime"].InvokeToSearcherConverter(ADOPathUtil.CreateFilterClause(ADOperator.Ge, "AccountLockoutTime", (object) 1), cmdletSessionInfo));
        this.OutputFilterFunction = new ADGetCmdletBase<SearchADAccountParameterSet, ADAccountFactory<ADAccount>, ADAccount>.OutputFilterDelegate(this.FilterIsLockedOut);
      }
      if (list.Count > 0)
        this.OutputSearchResults(list.Count != 1 ? ADOPathUtil.CreateAndClause(list.ToArray()) : list[0]);
      else
        this.OutputSearchResults((IADOPathNode) null);

Vì vậy, có vẻ như Search-ADAccount -LockedOutcũng đang xem thuộc tính AccountLockoutTime!

Chỉnh sửa một số chi tiết cho công lý vĩ đại: Richard Mueller, Dir. Dịch vụ MVP, cho biết điều này:

Bạn không thể sử dụng thuộc tính userAccountControl để xác định người dùng bị khóa. Có một chút userAccountControl được ghi lại cho điều này, nhưng nó không được sử dụng.

Tôi có thể xác minh điều này như vậy:

PS C:\Users\ryan> $(Search-ADAccount -LockedOut).Count
11
PS C:\Users\ryan> $(Get-ADUser -LDAPFilter "(&(objectCategory=User)(userAccountControl:1.2.840.113556.1.4.803:=16))").Count
0

Cuối cùng, tôi muốn kết thúc bài viết trên blog về chủ đề này , điều này giải thích tại sao giải lockoutTime>=1pháp này lại tiếp cận giải pháp tốt nhất, nhưng đó chỉ là một phần của câu chuyện. Bạn cần lọc thêm danh sách để chỉ bao gồm những người dùng có thời gian khóa của họ lớn hơn $ (thời gian khóa tên miền của bạn) trong quá khứ.


Tôi sẽ quan tâm để tìm tài liệu về thời điểm userAccountControlbit đó ngừng hoạt động. Nó hoạt động tốt trong quá khứ, nếu bộ nhớ phục vụ. Nó làm cho tôi tự hỏi nếu chức năng đã được gỡ bỏ trong một phiên bản sau của mã AD. Hmm ...
Evan Anderson

Chà, tôi ghét phải tiếp tục kháng cáo lên chính quyền, nhưng Richard Mueller nói rằng nó đã không hoạt động kể từ Windows 2000.
Ryan Ries

Tôi nghi ngờ rằng nó hoạt động trong Windows 2000 khi có Bộ kiểm soát miền Windows NT 4.0, bởi vì nó sẽ cần ở đó để tạo điều kiện sao chép sang các DC có SAM. Tôi không có môi trường thử nghiệm cho NT 4.0 nữa (tôi đã xóa tất cả các máy ảo cũ đó) nhưng tôi chắc chắn sẽ dùng thử. Sẽ phải một cách để các DC chỉ SAM có thể nhận thức được việc khóa tài khoản-- đó là cách duy nhất mà tôi có thể thấy nó hoạt động.
Evan Anderson

@EvenAnderson Tôi hết lòng ủng hộ nghiên cứu của bạn và nhiệt tình chờ đợi kết quả kiểm tra của bạn. :)
Ryan Ries
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.