Cấu hình thiết lập mật khẩu trong Windows Server 2008

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

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ỉ
/>ws_id=38979.
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