Làm việc với tiện ích chuẩn đoán Domain Controller – Phần 3

Chia sẻ: Nguyenhoang Nhan | Ngày: | Loại File: PDF | Số trang:4

Thêm vào BST

Báo xấu

95
lượt xem 24
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Cho đến đây các bạn đã biết được rằng Domain Controller Diagnostic Utility có rất nhiều vấn đề mà bạn có thể sử dụng để cấu hình tiện ích chạy theo cách thích hợp nhất cho mỗi tình huống riêng của mình

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Làm việc với tiện ích chuẩn đoán Domain Controller – Phần 3

Làm việc với tiện ích chuẩn đoán Domain Controller – Phần 3 Nguồn : quantrimang.com.vn Brien M. Posey Quản trị mạng – Trong phần 3 này chúng tôi sẽ tiếp tục giới thiệu cho các bạn về cách làm việc với tiện ích chuẩn đoán Domain Controller bằng cách khảo sát một số bài test. Cho đến đây các bạn đã biết được rằng Domain Controller Diagnostic Utility có rất nhiều vấn đề mà bạn có thể sử dụng để cấu hình tiện ích chạy theo cách thích hợp nhất cho mỗi tình huống riêng của mình. Chúng tôi đã giới thiệu cho các bạn về các tiếp lệnh, còn bây giờ sẽ quay trở về các test riêng biệt mà tiện ích có khả năng thực hiện. Advertising – quảng bá dịch vụ Bài test đầu tiên mà bạn có thể thực hiện là advertising. Test này thực hiện một hành động kiểm tra để tìm ra xem Directory System Agent hiện có advertising bản thân nó hay không. Nếu Directory System Agent hiện đang advertising bản thân nó thì test sẽ bảo đảm rằng sự quảng bá sẽ liệt kê domain controller với những khả năng của Directory System Agent. Trong trường hợp bạn không quen với khái niệm Directory System Agent, thì cần phải hiểu rằng, Directory System Agent (thường được viết tắt là DSA), là một bộ sưu tập các dịch vụ và các quá trình chạy trên domain controller. Công việc của nó là cung cấp sự truy cập vào cơ sở dữ liệu Active Directory. DSA là một thành phần con trong Local System Authority (LSA). Lý do tại sao nó lại liên quan đến các quá trình và dịch vụ như vậy là vì khả năng cung cấp nhiều cơ chế để máy khách có khả năng truy cập. Có thể được biết đến nhiều nhất trong các cơ chế này chính là Light Weight Directory Access Protocol, hay còn được viết tắt là LDAP. LDAP là một giao thức mà thông qua đó, hầu hết các hệ điều hành Windows gần đây đều sử dụng để truy vấn Active Directory. Các máy khách cũ hơn vẫn yêu cầu sự truy cập DSA, tuy nhiên điển hình vẫn được thực hiện thông qua Security Account Manager (SAM). Điều này là do không có cơ chế nào để truy cập DSA. Cho ví dụ, Microsoft exchange truyền thông với DSA bằng các cuộc gọi MAPI. Các DSA cũng truyền thông với một DSA khác bằng cách sử dụng các cuộc gọi thủ tục từ xa.
CheckSDRefDom Test này sẽ thẩm định rằng tất cả các partition chứa thư mục ứng dụng có bộ chỉ thị bảo mật cho các miền tham chiếu thích hợp. Bài test này sẽ vô nghĩa với những người không thành thạo về Active Directory. Chính vì vậy chúng tôi sẽ dành một chút thời gian để giới thiệu về bài test này là gì. Có thể các bạn đã biết điều này, mỗi đối tượng trong Active Directory gồm có một bộ chỉ thị bảo mật. Công việc của bộ chỉ thị bảo mật là duy trì một danh sách các thông tin điều khiển truy cập. Thông thường, bộ chỉ thị bảo mật đi kèm thường làm việc tốt cho việc duy trì bản ghi về những ai đã truy cập và các thành phần mà họ truy cập là thành phần nào. Tuy nhiên vấn đề có thể xuất hiện ở đây nếu một tổ chức sử dụng các partition thư mục ứng dụng (trước đây được biết đến với tên Active Directory Application Mode hoặc ADAM). Lý do cho điều đó là rằng các partition thư mục ứng dụng là miền độc lập. Trong thực tế, có thể tạo một partition thư mục ứng dụng và sau đó tạo bản sao cho các bộ điều khiển miền khác trong nhiều miền. Do có thể thực hiện được điều đó nên Windows gán một bộ chỉ thị bảo mật có tham chiếu miền co mỗi một partition thư mục ứng dụng khi được tạo. Miền tham chiếu này sẽ thông báo cho bạn về partition thư mục ứng dụng mà tên miền nào sử dụng khi một giá trị miền cần phải nhập vào bên trong một bộ chỉ thị bảo mật. Windows có rất nhiều rule để phân biệt tên miền nào được sử dụng. Đơn giản hóa, nếu bạn tạo một partition miền ứng dụng mới không phải là con của bất cứ partition nào và miền tham chiếu của bộ chỉ thị bảo mật sử dụng miền forest root như tên miền để sử dụng bên trong các bộ chỉ thị bảo mật khác nhau. Nếu partition thư mục ứng dụng là con của một đối tượng nào đó thì nó sẽ đảm nhận miền tham chiếu bộ chỉ thị bảo mật của đối tượng cha của nó. CheckSecurityError Test tiếp theo mà chúng tôi muốn giới thiệu cho các bạn là Check Security Error. Không giống như test trước mà chúng tôi đã giới thiệu cho các bạn. Check Security Error không hoạt động mặc định. Nếu muốn chạy test này, bạn phải tự chỉ định nó bên trong lệnh DCDIAG. Khi chạy test này, DCDIAG sẽ tìm ra các lỗi liên quan đến vấn đề bảo mật, cũng như các lỗi có thể liên quan, sau đó cố gắng chuẩn đoán vấn đề. Có một tham số tùy chọn mà bạn có thể sử dụng với tiếp lệnh này. Tiếp lệnh /ReplSource cho phép bạn chỉ định bộ điều khiển miền cụ thể để chạy test. Bạn có thể sử dụng bất cứ bộ điều khiển miền nào mong muốn, không cần quan tâm đến trạng thái lỗi của nó hoặc nó có phải là đối tác hiện hành hay không. Đơn giản chỉ cần nhập vào tên của test (CheckSecurityError), và gắn thêm vào đó tiếp lệnh
/ReplSource, dấu hai chấm và tên của domain controller mà bạn muốn test. Connectivity Connectivity là một trong những test hữu dụng nhất mà bạn có thể thực hiện với nó. Trong thực tế, test này rất quan trọng đến nỗi thậm chí DCDIAG không cho phép bạn bỏ qua. Nếu bạn chạy một instance mặc định của DCDIAG thì Connectivity sẽ chạy hoàn toàn tự động. Connectivity sẽ kiểm tra xem các bộ điều khiển miền đã được đăng ký trong DNS chưa. Nó cũng kiểm tra xem liệu nó có thể ping mỗi domain controller và có thể thiết lập được kết nối LDAP và RDP hay không. CrossRefValidation Đây là một test mà bạn sẽ không thể thấy nhiều tài liệu nó về nó. Những gì mà chúng tôi có thể giới thiệu cho các bạn về nó cũng giống như các tham chiếu không chính thức. Nếu các bạn bắt gặp một lỗi hợp lệ hóa tham chiếu thì vấn đề có thể được giải quyết bằng cách sử dụng ADSI edit để remove đối tượng gây lỗi đó. Chúng tôi cũng muốn chỉ ra rằng nếu sử dụng ADSI edit sai, bạn có thể phá hủy Active Directory của mình. Chính vì vậy, hãy thực hiện một backup toàn bộ trạng thái hệ thống cho các bộ điều khiển miền từ trước khi thực hiện bất cứ sự thay đổi nào. CutOffServers Test cuối cùng của chúng tôi là về Cut off Servers. Ý tưởng cơ bản nằm trong test này là trong hầu hết các trường hợp, các bộ điều khiển miền đều có một hoặc nhiều đối tác bản sao. Nếu đối tác sao chép của domain controller gặp vấn đề thì domain controller có thể sẽ không được cập nhật các nâng cấp của Active Directory và DCDIAG sẽ báo cáo lỗi Cut off Servers. Một mánh có thể giải quyết được vấn đề này là bạn phải chỉ ra những đối tác bản sao là domain controller là gì. Phương pháp thực tế có nhiều thay đổi phụ thuộc vào các phiên bản Windows, tuy nhiên trong Windows Server 2003, bạn có thể tra cứu các đối tác bản sao thông qua Active Directory Site and Services console. Khi mở giao diện hình cây, bạn hãy mở mục Site để hiển thị danh sách các site trong Active Directory của mình. Tiếp đến, kích đúp vào site chứa domain controller mà bạn muốn kiểm tra. Tiếp đến, mở phần thư mục Servers, sau đó là
thư mục tương ứng với tên của domain controller mà bạn quan tâm đến. Cuối cùng là kích đúp vào mục NTDSSettings, khi đó Windows sẽ hiển thị danh sách các đối tượng kết nối. Danh sách này sẽ hiển thị các đối tác bản sao trong cột From Server. Kết luận Trong phần này, chúng tôi đã giới thiệu cho các bạn về một số bài test chạy với tiện ích DCDIAG. Trong phần tiếp theo của loạt bài này, chúng tôi sẽ tiếp tục giới thiệu cho các bạn về một số bài test khác.