Tài liệu Làm việc với Read Only Domain Controller – Phần 2 doc

Làm việc với Read Only Domain Controller – Phần 2
Ngu
ồn : quantrimang.com 
Brien M. Pose
y
Quản trị mạng – Trong phần hai này chúng tôi sẽ giới thiệu cho các bạn về một
số khía cạnh trong triển khai Read Only Domain Controllers.
Giới thiệu
Trong phần trước của loạt bài này, chúng tôi đã giới thiệu cho các bạn một số lý
do cơ bản về việc Microsoft cung cấp Read Only Domain Controllers trong
Windows Server 2008. Trong phần hai này, chúng tôi sẽ giới thiệu cho các bạn
một số khía cạnh thực hành trong quá trình làm việc với Read Only Domain
Controllers.
Tiêu chuẩn tài khoản ngườ
i dùng
Chúng tôi sẽ bắt đầu bằng cách làm rõ một số thứ đã đưa ra trong phần cuối của
phần một. Ở phần cuối của phần một đó, chúng tôi đã cho rằng không có các
thông tin tài khoản nào được lưu trên read only domain controller.
Tuy nhiên trong thực tế không hẳn như vậy, các thông tin tài khoản người dùng
lại được lưu trên các bộ điều khiển miền chỉ đọc. Những gì mà các bộ điều khi
ển
miền domain controllers đang thiếu là các mật khẩu của người dùng. Những mật
khẩu này không được sao chép vào Read Only Domain Controllers. Nếu ai đó
đánh cắp một domain controller từ một văn phòng chi nhánh thì họ cũng không
thể sử dụng các thông tin được lưu trong cơ sở dữ liệu Active Directory để bẻ
khóa mật khẩu của người dùng.
Thuộc tính của người dùng
Mặc định, mật khẩu chỉ là thuộc tính củ
a người dùng và không được tạo bản sao
đến Read Only Domain Controllers. Mặc dù vậy bạn vẫn thể cấu hình Windows
nhằm ngăn chặn việc bị tạo bản sao các thuộc tính của những người dùng khác.

Vậy tại sao bạn lại sử dụng tính năng như vậy? Cần phải nói rằng nếu chỉ sử
dụng với tư cách là một cơ chế thẩm định thì bạn có thể sẽ không cầ
n đến tính
năng này. Tuy nhiên bạn cần lưu ý có nhiều tổ chức phụ thuộc nhiều vào Active
Directory hơn dùng cơ chế thẩm định quyền.
Trong ví dụ mà chúng tôi sẽ đề cập đến, đó là một môi trường doanh nghiệp lớn,
ở đây họ đã có những nhân viên phát triển “on site”. Các chuyên gia phát triển
của công ty đã tạo các ứng dụng sử dụng cho các công việc của riêng công ty.
Hầu hết tất cả các ứng dụng này đều sử dụng cơ sở dữ liệu nhưng các cơ sở dữ
liệu này không được liên kết với nhau.
Điều đó có nghĩa rằng mỗi một cơ sở dữ liệu đề
u có một số thông tin nhân bản.
Cho ví dụ, tên của mỗi một nhân viên, số điện thoại nội bộ và số ID cá nhân
(cùng với nhất nhiều thứ khác) đều có trong mỗi cơ sở dữ liệu. Nếu có lỗi nào đó
xuất hiện trong quá trình nhập dữ liệu thì dữ liệu đó sẽ không nhất quán trong
các cơ sở dữ liệu với nhau. Ví dụ, tên của một nhân viên có thể bị đánh sai
chính tả trong một cơ sở dữ liệu nhưng lại đúng trong các cơ sở dữ liệu khác,
hoặc hai số trong số ID của nhân viên có thể bị hoán vị trong một cơ sở dữ liệu.
Một vài năm cách đây, một số công ty đã nhận ra rằng việc sử dụng phương
pháp này không thu lại được nhiều hiệu quả như mong đợi. Phương pháp này
không những sinh ra các lỗi mà còn làm cho các công ty phả
i tốn thêm chi phí
cho việc trả lương cho các nhân viên nhập dữ liệu có trong cơ sở dữ liệu khác.
Có nhiều giải pháp khác để khắc phục tình trạng này, tuy nhiên phương pháp
thường được sử dụng nhất là sử dụng các thông tin trong Active Directory.
Cho ví dụ, một tổ chức đã tạo một ứng dụng nhân sự để họ có thể sử dụng nội
bộ. Tuy nhiên dữ liệu được lưu trong một c
ơ sở dữ liệu SQL Server, còn những
dữ liệu như tên nhân viên, tiêu đề, số điện thoại,… lại được lưu trong Active
Directory với tư cách là các thuộc tính của tài khoản. Phương pháp này cho

phép các thông tin được dùng chung sẽ được sử dụng lại ở nhiều địa điểm và nó
cho phép hủy kết nối giữa tên của người dùng và các dữ liệu quan trọng khác.
Cơ sở dữ liệu SQL Server có chứa những d
ữ liệu như số bảo mật xã hội và
thông tin về tiền lương, tuy nhiên nó không chứa tên của bất cứ nhân viên nào.
Chỉ có một thứ gắn hai cơ sở dữ liệu với nhau là số nhân viên trong cả hai cơ sở
dữ liệu.
Lý do tại sao chúng tôi giới thiệu cho các bạn điều này là muốn chỉ ra sự thật
rằng một số tổ chức sử dụng các thuộc tính tài khoản ng
ười dùng và các thuộc
tính này có thể chứa các thông tin nhạy cảm. Trừ khi có một nhu cầu trực tiếp về
kiểu thông tin cần lưu nội bộ trên một domain controller trong một văn phòng chi
nhánh, bằng không bạn nên xem xét đến việc khóa quá trình tạo bản sao một số
tính năng nhạy cảm.
Một thứ mà bạn cần phải lưu ý là trong khi một số tổ chức sử dụng các thuộc
tính người dùng trong các ứng dụng thì các công ty này vẫ
n tận dụng các
partition thư mục ứng dụng. Các partition thư mục ứng dụng ở đây chính là các
partition Active Directory đặc biệt được tạo riêng để sử dụng cho ứng dụng.
Read Only Domain Controllers hỗ trợ đầy đủ việc tạo bản sao dữ liệu được lưu
trong các partition thư mục ứng dụng.
Một lưu ý nữa đó là Read Only Domain Controllers cũng có thể được cấu hình
để thực hiện như một máy chủ DNS chỉ đọc. Về cơ bản thì điều đó có nghĩa rằng
nếu bạn cấu hình một máy chủ DNS trên một Read Only Domain Controller thì
người muốn xâm nhập sẽ không thể can thiệp vào bản ghi DNS.
Các vấn đề về quản trị
Mộ
t câu hỏi mà có lẽ các bạn sẽ đặt ra đó là người dùng thẩm định như thế nào
nếu không có dữ liệu mật khẩu?
Đây thực sự là một mẹo. Như các bạn đã biết, cả tài khoản người dùng và tài

khoản máy tính đều có mật khẩu đi kèm với chúng. Mặc định, chỉ có mật khẩu
mà Read Only Domain Controller sẽ lưu là mật khẩu tài khoản của chính máy
tính đó.
Vì không có mật kh
ẩu lưu nội bộ nên các yêu cầu thẩm định sẽ được chuyển
đến một writable domain controller. Nếu mục tiêu của bạn là cho phép người
dùng có thể đăng nhập thậm chí nếu writable domain controller không thể liên
lạc, khi đó bạn cần kích hoạt cache mật khẩu. Nếu cache mật khẩu được kích
hoạt, khi đó chỉ các tài khoản thẩm định thông qua domain controller mới có các
mật khẩu được cache. Nếu domain controller bị thỏa hiệp, b
ạn có thể sử dụng
các domain controller khác để tìm ra mật khẩu tài khoản nào được cache để thiết
lập lại các mật khẩu đó.
Quản trị viên làm việc như thế nào?
Trong các văn phòng chi nhánh một domain controller cũng được cấu hình để
thực hiện như một máy chủ ứng dụng. Nếu không có các nhân viên CNTT
chuyên trách trong một văn phòng chi nhánh thì bạn có thể chỉ định ai đó là quản
trị viên của read only domain controller. Bằng cách đ
ó, họ có thể kiểm soát việc
quản trị nội bộ trên máy chủ mà không thể can thiệp vào Active Directory. Quản
trị viên này chỉ được phép cài đặt bản vá phần mềm và thực hiện các nhiệm vụ
bảo dưỡng hàng ngày cần thiết. Việc chỉ định ai đó là quản trị viên trên Read
Only Domain Controller giống như việc bổ nhiệm ai đó là quản trị viên nội bộ cho
một số lượng máy nhất đị
nh.
Kết luận
Qua phần hai này chúng tôi hy vọng các bạn có được kiến thức cơ bản về Read
Only Domain Controllers được sử dụng như thế nào trong thế giới thực. Trong
phần ba của loạt bài, chúng tôi sẽ giới thiệu cho các bạn về quá trình triển khiai
một Read Only Domain Controller.