Cấu hình thiết lập mật khẩu trong Windows Server 2008 - Phần 2
Ngu
ồn : quantrimang.com 
Jakob H. Heidelber
g
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.

79.
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

viên nhóm bảo mật toàn cục của người dùng được mang đi xét. Nếu
người dùng là thành viên của nhiều nhóm bảo mật có áp dụng các PSO
khác nhau thì PSO với giá trị ưu tiên thấp nhất sẽ là PSO kết quả. Nếu hệ
thống không có hai hay nhiều PSO được áp dụng bởi thành viên nhóm
cho mỗi người dùng, tất cả cùng giá trị msDS-
PasswordSettingsPrecedence, thì PSO với GUID nhỏ nhất sẽ được áp
dụ
ng.
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)

ư
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"