Cấu hình dịch vụ Lightweight Directory Service – Phần 1

Quản trị mạng –Trong loạt bài này, chúng tôi sẽ giới thiệu về khả năng và cách sử dụng các dịch vụ Lightweight Directory Service như thế nào.

Lightweight Directory Service tỏ ra rất hữu dụng cho các trường hợp mà ở đó các ứng dụng cần truy cập vào một dịch vụ thư mục nào đó nhưng bạn không muốn gặp phải rủi ro thỏa hiệp cơ sở dữ liệu Active Directory của mình. Chính vì sự hữu dụng này, mà chúng tôi muốn giới thiệu cho các bạn loạt bài về các dịch vụ Lightweight Directory Service, cụ thể là về khả năng và cách sử dụng nó như thế nào.

Khi Microsoft giới thiệu Active Directory trong Windows 2000, người dùng không lâu sau đó đã nhanh chóng nhận ra rằng Active Directory không chỉ là một cơ sở dữ liệu tập trung mà còn có thể được sử dụng cho nhiều mục đích khác mà trước đó chưa được dự định tới.

Ngay sau đó, hầu như tất cả các hãng phần mềm đều thiết kế các phần mềm của họ có khả năng tích hợp Active Directory. Nhiều ứng dụng như vậy đã lưu các thông tin cấu hình trong Active Directory, một số thậm chí còn coi Active Directory như một cơ sở dữ liệu thay thế cho cơ sở dữ liệu SQL và lưu tất cả các dữ liệu ứng dụng thực vào cơ sở dữ liệu Active Directory.

Ngày nay, hầu hết các nhà xuất bản phần mềm thứ ba lại sử dụng phương pháp ít phụ thuộc hơn trong việc giao tiếp với Active Directory. Nhiều ứng dụng vẫn đọc dữ liệu Active Directory, nhưng không phải gần như tất cả đều lưu dữ liệu vào Active Directory như vài năm cách đây.

Mặc dù các nhà xuất bản phần mềm có thể không sử dụng Active Directory cho phạm vi mà họ đã làm, nhưng quả thực Active Directory vẫn rất hữu dụng trong hỗ trợ một số ứng dụng khác. Để lý giải cho vấn đề này, chúng ta có thể thấy ngay một sự thật là Microsoft vẫn thiết kế nhiều ứng dụng máy chủ của họ có mức tích hợp Active Directory rất cao. Exchange Server 2007 và Exchange Server 2010 là các ví dụ, được thiết kế theo cách đó để tất cả các thông tin cấu hình máy chủ được lưu trong Active Directory thay vì lưu cục bộ trên máy chủ nào đó. Ưu điểm của phương pháp này là có thể tái tạo lại một máy chủ bị lỗi ngay lập tức.

Lấy ví dụ rằng bạn gặp phải một lỗi ổ cứng nghiêm trọng trên máy chủ Exchange 2010 server đang giữ vai trò Hub Transport Server Role. Do Exchange lưu các thông tin cấu hình của nó trong Active Directory nên bạn không cần khôi phục một backup để khắc phục vấn đề mà thay vào đó thực hiện khắc phục bằng cách thiết lập lại tài khoản máy tính cho máy chủ bị lỗi bên trong Active Directory. Sau đó cài đặt Windows và các gói dịch vụ ứng dụng vào máy chủ mới. Tiếp đến, gán máy chủ đó một tên giống với tên máy chủ bị lỗi đã sử dụng trước đó và join máy chủ mới này vào Active Directory. Do đã thiết lập lại tài khoản máy tính Active Directory nên máy chủ mới hoàn toàn có thể sử dụng nó.

Từ đây, việc khắc phục vấn đề trở nên đơn giản bằng cách chạy chương trình Setup của Exchange Server và sử dụng một switch lệnh đặc biệt. Chương trình Setup sẽ các cài đặt nhị nguyên phân cần thiết và sau đó cấu hình máy chủ theo thông tin cấu hình có trong Active Directory. Máy chủ mới có thể được đưa vào phục vụ không đến một giờ sau đó mà không cần phải khôi phục một backup.

Quan điểm của chúng tôi là Active Directory rất hữu dụng cho việc hỗ trợ ứng dụng, tuy nhiên nhiều nhà xuất bản phần mềm không sẵn lòng sử dụng nó cho phạm vi mà Microsoft có thể quản lý là vì một nhược điểm trong việc mở rộng giản đồ Active Directory.

Một lý do khác tại sao bạn không thấy nhiều nhà xuất bản phần mềm lưu dữ liệu trong Active Directory là việc tạo bản sao. Nói chung, bất cứ dữ liệu nào được lưu trong Active Directory đều được tạo bản sao đến tất cả các domain controller trong miền (thậm chí có thể là tất cả các domain controller trong forest). Như vậy nếu có một ứng dụng nào đó lưu một lượng lớn dữ liệu trong Active Directory thì dữ liệu này có thể ảnh hưởng đến tốc độ của quá trình tạo bản sao – đặc biệt nếu có sự thay đổi thường xuyên.

Dù có những khó khăn như vậy nhưng chúng ta vẫn có một cách có thể tận dụng sự tích hợp Active Directory mà không bị ảnh hưởng đến cơ sở dữ liệu Active Directory của mình. Windows Server 2008 và Windows Server 2008 R2 đều có một dịch vụ mang tên Active Directory Lightweight Directory Service hay được viết tắt là AD LDS. Cũng có một dịch vụ tương tự như vậy tồn tại bên trong Windows Server 2003 nhưng được biết đến với cái tên Active Directory Application Mode (ADAM).

AD LDS cung cấp cho bạn một môi trường giống nhưng lại tách biệt hoàn toàn với Active Directory. AD LDS là một dịch vụ độc lập không phụ thuộc vào Active Directory Directory Service. Trong thực tế, người ta thường triển khai AD LDS trong các môi trường mà ở đó không tồn tại các miền Active Directory.

Một ví dụ hoàn hảo cho trường hợp này là Microsoft Exchange Server. Trước đây chúng ta đã biết Exchange Server 2007 và 2010 cả hai đều được thiết kế để lưu tất cả các thông tin cấu hình của chúng trong cơ sở dữ liệu Active Directory. Mặc dù vậy có một ngoại lệ trong trường hợp này.

Exchange Server định nghĩa một loạt các vai trò (role) để quản lý máy chủ Exchange Server và nhiệm vụ các máy chủ thực hiện. Tuy nhiên có một role máy chủ được thiết kế để lưu cấu hình máy chủ trong Active Directory.

Role máy chủ không sử dụng Active Directory được biết đến là Edge Transport Server Role. Edge Transport Server được thiết kế để cư trú tại vành đai mạng và giữ cho các máy chủ Exchange Server khác không bị phô bày trực tiếp với Internet.

Do Edge Transport Server bị phô bày với các hiểm họa Internet nên việc đưa nó trở thành thành viên của miền Active Directory là một mối rủi ro bảo mật. Nếu ai đó có thể thỏa hiệp Edge Transport Server thì họ cũng có thể sử dụng nó để khai thác các thông tin về Active Directory.

Để tránh điều đó, Edge Transport Server cần không phải là một thành viên miền, cũng như không nắm giữ bất cứ Exchange Server role nào khác. Tuy nhiên do Edge Transport Server lại yêu cầu truy cập đến một số lượng nhỏ thông tin Active Directory để thực hiện công việc của mình. Đúng hơn là cần cung cấp cho máy chủ sự truy cập trực tiếp vào Active Directory, vì lý do này Microsoft đã thiết kế Edge Transport Server role nhằm sử dụng AD LDS.

Một trong số máy chủ Exchange Server backend sẽ đọc các thông tin cần thiết này từ Active Directory và gửi thông tin đến phân vùng AD LDS trên Edge Transport Server. Bằng cách đó, Edge Transport Server sẽ có các thông tin mà nó cần thiết mà không cần phải truy cập vào Active Directory. Tuy nhiên Edge Transport Server cũng có thể lưu các thông tin cấu hình của riêng nó trong phân vùng AD LDS như thể các Exchange Server role vẫn lưu các thông tin cấu hình trong Active Directory.

Kết luận

Cho đến đây chúng tôi đã giới thiệu được cho các bạn biết AD LDS là gì và nó được sử dụng để làm gì, tuy nhiên do muốn tập trung vào việc sử dụng dịch vụ này trong mỗi tổ chức riêng biệt nên phần 2 của loạt bài này sẽ được tiếp tục để cung cấp thêm các thông tin về yêu cầu phần cứng và phần mềm cho việc sử dụng AD LDS.