Cấu hình thiết lập mật khẩu trong Windows Server 2008 - Phần 2

Jakob H. Heidelberg

Trong phần hai này chúng tôi sẽ giới thiệu cho bạn các thông tin cơ bản rất hữu dụng về các thiết lập mật khẩu trong Windows Server 2008. Chúng tôi sẽ đề cập đến một số thuộc tính mới và các đối tượng người dùng, đối tượng thiết lập mật khẩu (PSO), PSO kết quả, giới thiệu về thiết kế, Shadow Groups (SG)…

Tại sao chúng ta muốn thực hiện điều này?

Chúng ta đã thấy cách tạo các PSO và gán chúng cho người dùng hoặc nhóm, nhưng tại sao chúng ta lại cần nhiều mật khẩu và tài khoản để đến vậy? Có một số lý do cho việc này – một có thể là các kịch bản “hosting” có nhiều công ty nằm trong một miền AD riêng, lý do khác là chúng ta cần các thiết lập chặt chẽ để áp dụng cho một nhóm người nào đó có tài khoản đặc quyền (giống như quản trị viên miền hoặc nhân viên trợ giúp).

Các tài khoản có quyền ưu tiên này cần phải có các yêu cầu phức tạp và yêu cầu cho việc định nghĩa một mật khẩu có tối thiểu 16 kí tự trong mật khẩu của họ, các tài khoản được giới hạn nhiều hơn và có thể có nhiều yêu cầu “thân thiện với người dùng” hơn.

Những ai có thể tác động?

Chính sách đa mật khẩu mới trong Windows Server 2008 (tên mã là “Longhorn”) cho phép chúng ta thiết lập các chính sách mật khẩu riêng và tài khoản khóa chính sách trên các đối tượng người dùng - user objects, đối tượng interOrgPerson và nhóm bảo mật toàn cục - global security groups.

Các chính sách mật khẩu không thể được áp dụng cho OU (đối tượng người dùng) một cách trực tiếp – mà phải áp dụng chính sách này cho các nhóm. Không phải bất kỳ nhóm nào cũng được – nó phải là nhóm bảo mật được thiết lập trong phạm vi toàn cục và có thể thiết lập tùy chọn trên các nhóm khác; mặc dù vậy nó sẽ không làm việc như mong đợi (nếu các thiết lập bị bỏ qua).

Nếu bạn thực sự muốn quản lý các chính sách mật khẩu bên trong cấu trúc OU thì ‘Shadow Groups’ có thể sẽ hữu dụng. (Xem thêm phần “Shadow Groups và cách tạo kịch bản” ở phần dưới)

Mặc định, chỉ có các thành viên của “nhóm quản trị miền” mới có thể thiết lập, tạo và xóa các chính sách mật khẩu– được biết đến như các đối tượng thiết lập mật khẩu (PSO). Mặc dù vậy, các cho phép đó có thể được ủy nhiệm và điều chỉnh nếu cần thiết, nhưng thiết lập mặc định sẽ là tốt hơn trong hầu hết các môi trường. Cụ thể hơn, chỉ thành viên của nhóm quản trị miền mới có các cho phép (quyền) “tạo” và “xóa” trong đối tượng thiết lập mật khẩu - Password Settings Container (PSC).

Để áp dụng PSO cho một người dùng hoặc một đối tượng nhóm bạn phải có các cho phép “ghi” (quyền được ghi) trên đối tượng PSO – các thành viên của nhóm quản trị miền là những người có quyền này mặc định.

Xem xét qua các thuộc tính

Chúng ta phải xem xét một số thuộc tính đó là:

msDS-PSOAppliesTo

Mỗi PSO có một thuộc tính đa giá trị có tên là msDS-PSOAppliesTo, thuộc tính này được biết đến như một “liên kết chuyển tiếp” để liên kết đến các đối tượng người dùng hay các đối tượng nhóm, một nhóm riêng hay nhiều người dùng, nhiều nhóm hoặc nhiều người dùng và các nhóm. Các liên kết trên thực tế là các tên phân biệt (ví dụ “CN=GroupA,OU=MyGoups,DC=Contoso,DC=Local”) của các đối tượng được kết hợp.

Câu hỏi đặt ra: Điều gì sẽ xảy ra nếu chúng đặt lại tên hoặc di chuyển đối tượng người dùng hay đối tượng nhóm (đến OU khác hoặc mục khác), các PSO sẽ theo sau các đối tượng không? Thuộc tính msDS-PSOAppliesTo sẽ được tự động cập nhật bởi dịch vụ thư mục trong background để chỉ ra địa điểm mới (tên phân biệt) của đối tượng đã thay đổi.

msDS-PSOApplied

Thuộc tính msDS-PSOAppliesTo trên các PSO có thể được soạn thảo trái với thuộc tính “liên kết ngược” msDS-PSOApplied, thuộc tính được sử dụng trên các đối tượng người dùng và nhóm. Thuộc tính sau là “chỉ xem” và được quản lý bởi dịch vụ thư mục trong background.

Thuộc tính msDS-PSOApplied gồm có một “liên kết ngược” để PSO trỏ vào đối tượng cha của nó – khi người dùng hay nhóm có nhiều PSO được áp dụng cho họ thì thuộc tính này cũng có nhiều giá trị.

msDS-ResultantPSO

Thuộc tính msDS-ResultantPSO chỉ có trong đối tượng người dùng. Nó gồm có một giá trị đã được tính toán, cũng được nhắc đến như “Resultant Set of Policy” (RSoP). Đây là một liên kết đến PSO riêng – liên kết “may mắn” được kích hoạt trên đối tượng người dùng riêng. Giá trị này được tính toán bởi quá trình dịch vụ thư mục trong background từ các nguyên tắc sẽ được đề cập đến trong phần tiếp theo của bài (Phần thiết kế).

Câu hỏi đặt ra: Khi nào chính sách mật khẩu có hiệu lực đối với người dùng - người đã được bổ sung vào một nhóm? Câu trả lời là, ngay sau khi người dùng được bổ sung vào nhóm thì PSO kết quả cũng được tính toán cho đối tượng người dùng bằng dịch vụ thư mục. Nó cũng tương tự nếu bạn xóa một tài khoản người dùng khỏi nhóm – sự thay đổi sẽ có hiệu quả ngay lập tức.

msDS-PasswordSettingsPrecedence

Thuộc tính msDS-PasswordSettingsPrecedence có trong các đối tượng PSO. Giá trị thấp hơn cho thuộc tính này chỉ thị rằng PSO có mức ưu tiên cao hơn. Thuộc tính này được sử dụng khi nhiều PSO được áp dụng cho một đối tượng người dùng – nghĩa là “cost” thấp nhất được chọn. Nếu bạn gán một giá trị có quyền ưu tiên duy nhất cho mỗi PSO trong miền thì bạn dễ dàng xác định được chính sách mật khẩu có hiệu lực cho một đối tượng người dùng nào đó chưa.

Thiết kế

Trước khi thực hiện các chính sách đa mật khẩu trong miền chúng tôi khuyên bạn nên xem qua các chính sách cần thiết và để kết thúc thiết kế tổng thể của các chính sách đó cùng với sự tương tác của chúng. Có thể có nhiều chính sách được gán cho một người dùng đơn, trực tiếp hoặc thông qua các thành viên nhóm (thậm chí nhóm bảo mật nào đó được định địa chỉ), nhưng chỉ một PSO có thể ảnh hưởng cho một đối tượng người dùng nào đó, mật khẩu hay các thiết lập khóa không thể được kết hợp trong Group Policy.

Vì vậy chúng tôi cần đến một số nguyên tắc tính toán khi nhiều PSO được thể hiện cho người dùng.

Các nguyên tắc đơn giản

PSO kết quả được xác định dưới đây:

Nếu không có PSO nào thu được từ các điều kiện 1 và 2 thì mật khẩu và các thiết lập khóa từ “Default Domain Policy” được áp dụng, giống như nó là các phiên bản trước của môi trường Active Directory.

Vậy để làm một câu chuyện dài thành ngắn: tập PSO trên các đối tượng người dùng sẽ chiến thắng tập các PSO trên đối tượng nhóm và giá trị có quyền ưu tiên thấp hơn sẽ chiến thắng cái cao hơn – nếu điều đó thất bại thì kết quả được dựa trên số GUID – và nếu không có gì áp dụng chúng ta sẽ trở về nơi bắt đầu: “Default Domain Policy”!

Như các gợi ý chung chúng tôi sẽ đề cập đến các vấn đề sau:

Trường ‘Description’ có thể được sử dụng để chỉ rõ mật khẩu và các thiết lập khóa được phép trong PSO. Sử dụng nó để cấu hình nhanh PSO và sử dụng dự định.

Tạo một tên cho PSO giống như bạn có cho các đối tượng Active Directory khác.

Gán các PSO cho nhóm thay vì trực tiếp đến các đối tượng người dùng, cho khả năng quản lý dễ dàng hơn.

Gán một giá trị ưu tiên duy nhất cho mỗi PSO trong miền của bạn, nó sẽ dễ dàng hơn nhiều khi xác định chính sách mật khẩu có hiệu lực cho một đối tượng người dùng nào đó.

Nguyên tắc Mặc định từ chối tất cả (Default Deny All)

Chúng tôi biết rằng điều này không phải là một thứ có thể nói rộng rãi nhưng vẫn khuyên bạn nên thiết lập các thiết lập mật khẩu có ở “Default Domain Policy” với mức bảo mật rất cao (hầu hết cảm thấy khó chịu). Điều này là bởi vì bạn – hoặc một ai đó – có thể quên tính đến người dùng trong một nhóm bảo mật mật khẩu. Trong trường hợp đó, chính sách mật khẩu tài khoản người dùng sẽ trở thành một chính sách được định nghĩa trong tập thiết lập chính sách mặc định trong mức miền!

Hãy xem chính sách bảo mật trong Default Domain Policy khi có nguyên tắc mặc định từ chối tất cả trong một tường lửa – nếu không có chính sách/ nguyên tắc cụ thể nào có sẵn cho người dùng (hoặc ai đó trong nhóm mà anh ta là một thành viên) thì chúng ta nên đặt một chính sách khắt khe trên ‘đầu’ người dùng. Người dùng có thể gọi cho nhân viên trợ giúp để có được ASAP đã sửa – nếu chúng ta trao cho người dùng một chính sách mật khẩu dễ dàng thì có thể anh ta sẽ không bao giờ phàn nàn. Cách khác để thực hiện điều này là thiết lập một chính sách mật khẩu trên nhóm người dùng trong miền “Domain Users” có mức ưu tiên thấp nhất – nhưng đôi khi cần phải có một số tài khoản nằm bên ngoài nhóm để phục vụ cho các lý do khác…

Ở đây lựa chọn của tôi là nguyên tắc mặc định từ chối tất cả - Default Deny All

Shadow groups và cách tạo kịch bản

Nếu bạn chưa bao giờ nghe về “Shadow Groups” thì cũng đừng lo lắng. Shadow Group (SG) là một nhóm bảo mật (trong trường hợp này là nhóm bảo mật Global) gồm có các đối tượng bên trong một OU như các thành viên. SG là một nhóm bảo mật được bản đồ hóa “một cách logic” đến một OU. Ví dụ bạn có thể có một OU, “OU=Sales,OU=CorpUsers,DC=Contoso,DC=Local”, với các tài khoản người dùng cho toàn bộ phòng bán hàng – SG sẽ là một nhóm tương xứng với 100% nội dung. Với các chính sách mật khẩu thì điều này có thể là một ưu điểm nếu chúng ta muốn các chính sách mật khẩu tuân theo cấu trúc OU “một cách ảo hóa” thay vì theo cấu trúc SG.

Bạn có thể hình dung rằng điều này có ý nghĩa tuyệt vời cho công việc nếu phải nâng cấp các SG một cách thủ công hàng giờ, đó là lý do tại sao chúng tôi đã viết một kịch bản VBS đơn giản để tự động quá trình này bằng sử dụng một nhiệm vụ đã được lập lịch trình.

Kịch bản chọn các tài khoản người dùng từ một OU cụ thể - trên danh nghĩa lý thuyết như một đối số cho kịch bản – và đặt chúng vào một đối tượng thư mục. Sau đó kịch bản sẽ chọn người dùng bên trong một nhóm cụ thể - trên danh nghĩa cũng như một đối số cho kịch bản - và đặt chúng vào một đối tượng thư mục. Bằng việc so sánh các thư mục này, kịch bản có thể thêm, bới người dùng từ “shadows group”. Kịch bản được thiết kế để có thể tạo lịch trình như một nhiệm vụ và được sử dụng với câu lệnh sau: ShadowGroup.vbs "Target OU" "Shadow Group"

Ví dụ:

ShadowGroup.vbs "OU=Test,DC=Contoso,DC=Local" "CN=Shadow,OU=Test,DC=Contoso,DC=Local"

Kịch bản này bạn có thể download tại đây, tuy nhiên sử dụng trong môi trường thực tế có thể gây ra rủi ro. Vì vậy chúng tôi khuyên bạn nên có thói quen quản lý lỗi và có thể báo cáo về việc làm đó. Sự hỗ trợ cho các OU mức con cũng sẽ là một ý tưởng hay cần được bổ sung. Chúng tôi có thể cung cấp cho các bạn một kịch bản như vậy sau.

Tạo kịch bản



Bạn hoàn toàn có thể dùng kịch bản cho việc tạo và thay đổi chính sách mật khẩu và gán các chính sách đó cho người dùng hay nhóm cụ thể.

Chúng tôi sử dụng một công cụ cũ nhưng tốt: LDIFDE và PowerShell. Windows PowerShell có trong Windows Server 2008 và được bổ sung như một tính năng – chọn “Add Feature” trong Server Manager mới, chọn Windows PowerShell, sau đó một lúc PowerShell sẽ sẵn sàng cho bạn.

Chúng tôi khuyên các bạn nên thử Quest AD Cmdlets và kiểm tra PowerGui.org. Ngoài ra còn có một công cụ dòng lệnh miễn phí PSOmgr của Joeware. Với công cụ này bạn có thể quản lý được các đối tượng thiết lập mật khẩu (PSO) trong Windows Server 2008 một cách dễ dàng, như hiển thị các chính sách được áp dụng và chính sách có hiệu lực cho người dùng nào đó, hiển thị các PSO trong miền, thêm và bớt người dùng từ một PSO, tạo, đặt lại tên, xóa, thay đổi các PSO…

Kết luận

Hiểu được cách làm việc của thiết lập mật khẩu – như thế nào, khi nào và tại sao phải sử dụng chúng - là một điều quan trọng. Chúng tôi hy vọng qua hai bài viết về cấu hình thiết lập mật khẩu trong Windows Server 2008 sẽ mang lại nhiều bổ ích cho bạn.

Thiết kế chính sách mật khẩu, bản thân nó có thể là phần khó nhất và chủ yếu nhất trong việc thiết lập nhiều chính sách mật khẩu bên trong một miền AD riêng, và sau đó việc tạo các chính sách cần thiết, phần còn lại chỉ là sự quản lý như thông thường.