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

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.

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. Bạn có thể tìm hiểu thêm về các tên phân biệt tạ
i
địa chỉ
/>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
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:
1. Một PSO được liên kết tr
ực tiếp với một đối tượng người dùng sẽ có hiệu
lực trừ khi nhiều PSO được liên kết trực tiếp với đối tượng người dùng.
Nếu có nhiều PSO được liên kết thì PSO có giá trị ưu tiên thấp nhất
(msDS-PasswordSettingsPrecedence) sẽ là PSO kết quả. Nếu hệ thống
có hai hay nhiều PSO được áp dụng trực tiếp cho một người dùng, tất cả
cùng một giá trị msDS-PasswordSettingsPrecedence thì PSO với
Global Unique Identifier (GUID) nhỏ nhất sẽ được áp dụng.
2. Nếu không có PSO nào đượ
c liên kết với đối tượng người dùng thì các hội
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)
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"