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 1 Nguồn : quantrimang.com  Jakob H. Heidelberg Trong các phiên bản Active Directory trước chúng ta chỉ có một mật khẩu và một tài khoản để khóa chính sách cho toàn bộ miền. Tuy nhiên ở một số công ty phải sử dụng nhiều miền để có nhiều chính sách mật khẩu khác nhau trên các người dùng khác nhau; một số công ty khác thì phát triển các bộ lọc mật khẩu của chính họ hoặc mua từ các nhóm phát triển phần mềm thứ ba. Với Windows Server 2008, chúng ta có thể tùy chọn để chỉ định nhiều chính sách mật khẩu khác nhau cho các người dùng và nhóm khác nhau. Trong phần đầu tiên của bài gồm hai phần này chúng ta sẽ tìm hiểu về cách tạo một chính sách mật khẩu bổ sung vào chính sách vẫn có trong “Default Domain Policy” Điểm mới Trong các tính năng mới, chúng ta tập trung vào “Granular Password Settings” hoặc “Fine-Grained Password Policy“,dựa trên hai lớp đối tượng mới trong lược đồ AD: các đối tượng “Password Settings Container” và “Password Setting”. Các đối tượng này có bản cung cấp cho chúng ta tùy chọn để giới thiệu nhiều chính sách mật khẩu trong một miền Active Directory đơn. Tuy nhiên chúng ta hãy xem xem mình phải cần những gì… Các công cụ và điều kiện quyết định Đây là một xem xét sơ qua về các công cụ và điều kiện quyết định cần thiết cho việc tạo chính sách mật khẩu bổ sung. ADUC Trước hết, mức chức năng miền Active Directory phải là “Windows Server 2008”. Điều này có thể được kiểm tra bằng cách sử dụng Active Directory Users and Computers (ADUC) – bằng cách kích chuột phải vào miền > chọn “Raise domain functional level” – mức chức năng miền hiện hành sẽ đọc “Windows Server 2008” (dưới đây là màn hình phiên bản beta 3 của Windows Server 2008): Simpo PDF Merge and Split Unregistered Version - Hình 1 GPMC Chúng ta vẫn phải sử dụng Group Policy Management Console (GPMC) để thiết lập chính sách mật khẩu mặc định cho toàn bộ miền. Nếu quên cách thiết lập mật khẩu miền mặc định và khóa các thiết lập thì bạn có thể tìm thấy chúng trong GPMC tại mức miền tại “Default Domain Policy” > Computer Configuration > Windows Settings > Security Settings > Account Policies > Password Policy/Account Lockout Policy. Bằng cách này, GPMC có trong Windows Server 2008 (giống như Windows Vista), nhưng phải được bổ sung như một tính năng – chọn “Add Feature” trong Server Manager, chọn ‘Group Policy Management’, sau đó bạn sẽ vào được ‘Group Policy Ready’. ADSI Edit Công cụ quan trọng nhất cho “bài tập” này là một công cụ mà hầu hết các quản trị viên đều lo ngại trong nhiều năm – vì bất cứ khi nào bạn sử dụng nó thì gần như sẽ có một vấn đề nào đó lại xuất hiện -, chúng tôi chuyển sang tiện ích ADSI Edit (adsiedit.msc). Hầu hết các thiết lập chính sách mật khẩu cốt lõi đều được tạo và cấu hình từ bên trong công cụ này. ADSI Edit là một phần của bộ cài đặt Windows Server 2008 chuẩn vì vậy bạn không cần phải bổ sung nó về sau. Các bước Các bước cần thiết để cấu hình thiết lập chính sách mật khẩu trong Windows Server 2008: 1. Tạo đối tượng thiết lập mật khẩu (Password Settings Object - PSO) trong thư Simpo PDF Merge and Split Unregistered Version - mục thiết lập mật khẩu (Password Settings Container - PSC) bằng ADSI Edit 2. Cấu hình các tùy chọn PSO bằng cách hoàn thành wizard gốc bên trong ADSI Edit 3. Gán PSO cho một tài khoản người dùng hoặc một nhóm bảo mật toàn cục. 4. Xác nhận các thiết lập này được áp dụng Bắt đầu Đầu tiên, chúng ta mở ADSI Edit bằng cách kích Start > Run… > “adsiedit.msc” và kích OK (hoặc nhấn Enter). Kích chuột phải vào “ADSI Edit” và chọn “Connect to…” Hình 2 Kích OK để đồng ý với các tùy chọn mặc định trong hộp thoại “Connection Settings” Simpo PDF Merge and Split Unregistered Version - Hình 3 Trong ADSI Edit bạn có thể mở rộng miền, mở rộng thư mục ‘System’ và cuối cùng là kích chuột phải vào ‘Password Settings Container’ (PSC) mới và chọn New > “Object...”. Simpo PDF Merge and Split Unregistered Version - Hình 4 Bây giờ phải chọn một lớp cho đối tượng mới, nhưng bạn chỉ nhận được một lựa chọn. Chọn msDS-PasswordSettings và kích Next: Simpo PDF Merge and Split Unregistered Version - Hình 5 Lúc này, wizard được bắt đầu, hướng dẫn chúng ta đi qua toàn bộ quá trình tạo đối tượng thiết lập mật khẩu (PSO). Chúng ta phải chỉ định giá trị cho một trong 11 thuộc tính dưới đây. Nhập vào giá trị như thể hiện trong bản dưới đây. Thuộc tính Giá trị Giải thích nhanh Cn PassPolAdmins Đây là tên của chính sách. Bạn nên đặt tên thường lệ cho các chính sách này msDS-PasswordSettingsPrecedence 10 Số này được sử dụng Simpo PDF Merge and Split Unregistered Version - như một “chi phí” cho sự ưu tiên giữa các chính sách khác nhau trong trường hợp một người dùng được sử dụng bởi nhiều PSO. Bạn phải để lại khoảng trắng bên dưới và ở trên cho sử dụng tương lai. Các thiết lập mật khẩu PSO càng mạnh hơn thì “chi phí” càng thấp hơn. msDS- PasswordReversibleEncryptionEnabled False Giá trị nhị phân để chọn nếu các mật khẩu Simpo PDF Merge and Split Unregistered Version - được lưu với sự mã hóa đảo ngược (thường thì đây không phải là ý tưởng tốt) msDS-PasswordHistoryLength 32 Bao nhiêu mật khẩu trước đó sẽ được hệ thống lưu lại. msDS-PasswordComplexityEnabled True Người dùng phải sử dụng mật khẩu phức tạp? (giá trị nhị phân) msDS-MinimumPasswordLength 16 Số lượng tối thiểu của các kí tự trong mật khẩu tài khoản người dùng? msDS-MinimumPasswordAge -864000000000 (9 zeros) Thời hạn tối thiểu của mật khẩu là bao Simpo PDF Merge and Split Unregistered Version - nhiêu (trong trường hợp này là 1 ngày) msDS-MaximumPasswordAge - 36288000000000 (9 zeros) Thời hạn tối đa của mật khẩu là bao nhiêu? (trong trường hợp này là 42 ngày) msDS-LockoutTreshold 30 Bao nhiêu lần thử thất bại trước khi tài khoản người dùng sẽ bị khóa? msDS-LockoutObservationWindow -18000000000 (9zeros) Sau bao nhiêu lâu bộ đếm các lần thử thất bại được thiết lập lại? (trong trường hợp này là 6 phút) msDS-LockoutDuration -18000000000 (9zeros) Bao lâu thì đối tượng tài Simpo PDF Merge and Split Unregistered Version - khoản người dùng bị khóa trong trường hợp có quá nhiều mật khẩu sai nhập vào? (trong trường hợp này là 6 phút) Bảng 1 Khi tất cả dược đưa vào thì bạn sẽ thấy cửa sổ dưới đây – hãy kích Finish. Hình 6 Thực hiện Simpo PDF Merge and Split Unregistered Version - Bây giờ PSO được tạo và bạn có thể thấy được nó dưới PSC trong cả ADSI Edit và ADUC/Server Manager (hãy nhớ kích hoạt “Advanced Features” trong menu View), nó trông giống như hình dưới đây Hình 7 Từ đây những gì chúng ta phải thực hiện là gán một chính sách mới cho một người dùng, nhiều người dùng, một nhóm bảo mật toàn cục, nhiều nhóm bảo mật toàn cục hoặc kết hợp các người dùng và nhóm bảo mật toàn cục. Để thực hiện điều này, bạn kích chuột phải và PSO trong ADUC (hoặc ADSI Edit), chọn Properties – kích Filter và bảo đảm rằng bạn đã chọn các tùy chọn dưới đây: Simpo PDF Merge and Split Unregistered Version - Hình 8 Hình trên bao gồm các tùy chọn được chọn: “Mandatory”, “Optional”, “Constructed”, “Backlinks” và “System-only”. Tùy chọn “Show only attributes that have values” không được chọn. Bây giờ thì vào msDS-PSOAppliesTo, chọn nó và kích Edit. Hình 9 Trong “Multi-valued String Editor” bạn chèn tên phân biệt của người dùng hoặc Simpo PDF Merge and Split Unregistered Version - nhóm bảo mật toàn cục trong trường “Value to add” và kích Add. Bạn có thể thêm nhiều tên phân biệt trong hộp thoại này – khi xong kích OK. Hình 10 Trong ví dụ trên, chúng tôi đã bổ sung một nhóm bảo mật toàn cục có tên là “Admins” (với tên phân biệt là “CN=Admins,CN=Users,DC=Contoso,DC=Local”). Mỗi tài khoản người dùng là một thành viên của nhóm này được sử dụng bởi chính sách mật khẩu mới “PassPolAdmins” thay cho chính sách đã được định nghĩa trong Default Domain Policy. Tới đây, bạn có thể phân vân rằng điều gì sẽ xảy ra nếu người dùng sẽ bị ảnh hưởng bởi nhiều chính sách mật khẩu xung đột. Chúng tôi sẽ quay trở lại vấn đề này một cách chi tiết hơn trong phần tiếp theo. Chú ý đến sự thay đổi Khi duyệt trong ADUC, bạn có chú ý đến tab “Attribute Editor” mà chúng ta có trên hầu hết các đối tượng (xem các tính năng nâng cao “Advanced Features” phải được kích hoạt) hay không? Simpo PDF Merge and Split Unregistered Version - Hình 11 Điều này thực sự hữu dụng bởi vì nó cho phép quản trị viên có thể xem hoặc soạn thảo rất nhiều thứ như chúng ta bình thường vẫn làm trong công cụ soạn thảo ADSI Edit. Với tab này, chúng ta có thể lấy các thuộc tính trên PSO trong miền và thay đổi thuộc tính msDS-PSOAppliesTo để thiết lập dễ dàng chính sách mật khẩu trên người dùng hoặc các đối tượng nhóm. Chính sách nào đã được áp dụng ở đây? Bạn có thể khó nhận ra chính sách nào đã được áp dụng cho đối tượng người dùng cụ thể (có thể là một ai đó với giá trị ưu tiên AKA thấp nhất) - Resultant Set of Policy (RSoP) có thể cho bạn thực hiện điều này một cách dễ dàng. Tuy nhiên Microsoft đã đề cập đến vấn đề này bằng cách giới thiệu thuộc tính msDS- ResultantPSO lại chỉ cho các đối tượng người dùng. Simpo PDF Merge and Split Unregistered Version - Hình 12 Giá trị này xác định ra chính sách nào được áp dụng cho người dùng nào đó (trong ví dụ của chúng tôi, người dùng có tên là “Windows Admin”). Cả đối tượng nhóm và người dùng đều có thuộc tính mới, msDS-PSOApplied, thuộc tính nắm giữ tất cả các chính sách mà nhóm hoặc người dùng được sử dụng trực tiếp hoặc thông qua thành viên nhóm. Trong ví dụ dưới đây, nhóm có tên gọi là “Admins” được sử dụng bởi hai chính sách mật khẩu khác nhau. Simpo PDF Merge and Split Unregistered Version - Hình 13 Nếu bạn không thấy các giá trị được đề cập ở đây, hãy bảo đảm là đã thiết lập đúng tab “Attribute Editor” được phép lọc các tùy chọn trong phần Make it happen ở trên. Simpo PDF Merge and Split Unregistered Version - 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. 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) Simpo PDF Merge and Split Unregistered Version - 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 Simpo PDF Merge and Split Unregistered Version - 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 Simpo PDF Merge and Split Unregistered Version - 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 Simpo PDF Merge and Split Unregistered Version - 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í