Kế hoạch khôi phục thảm họa Active Directory

Chia sẻ: Thanh Cong | Ngày: | Loại File: PDF | Số trang:13

Thêm vào BST

Báo xấu

95
lượt xem 10
download

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

Kế hoạch khôi phục thảm họa Active Directory Ngăn chặn lỗi Active Directory chính là thành phần chủ yếu trong bất cứ kế hoạch khôi phục thảm họa nào. Tuy có nhiều cách có thể giảm được thảm họa cho Active Directory nhưng cách tốt nhất để tối thiểu thời gian chết của máy móc chính là cần phải có một kế hoạch phù hợp. Bạn cần khôi phục một domain controller? Muốn ngăn chặn việc xóa một số lượng lớn các đối tượng quan trọng do vô tình? Trong bài này chúng tôi sẽ giới thiệu cho các bạn cách...

Chủ đề:

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

Lưu

Nội dung Text: Kế hoạch khôi phục thảm họa Active Directory

Kế hoạch khôi phục thảm họa Active Directory
Ngăn chặn lỗi Active Directory chính là thành phần chủ yếu trong bất cứ kế hoạch khôi phục thảm họa nào. Tuy có nhiều cách có thể giảm được thảm họa cho Active Directory nhưng cách tốt nhất để tối thiểu thời gian chết của máy móc chính là cần phải có một kế hoạch phù hợp. Bạn cần khôi phục một domain controller? Muốn ngăn chặn việc xóa một số lượng lớn các đối tượng quan trọng do vô tình? Trong bài này chúng tôi sẽ giới thiệu cho các bạn cách lập kế hoạch cho những điều tồi tệ nhất và những gì bạn cần thực hiện để khôi phục Active Directory của mình và giúp nó chạy trở lại. Điều quan trọng là phải có một kế hoạch khôi phục thảm họa cho các thảm họa lớn, tuy nhiên có rất nhiều hành động bạn có thể thực hiện để ngăn chặn các thảm họa này – hoặc ít nhất cũng là tối thiểu cơ hội gây ra thảm họa Active Directory, chẳng bạn như việc xóa nhầm một số lượng lớn các đối tượng do vô tình. Một trong những hành động đó là tạo một lag site bản sao. Rất đơn giản, một lag site là một Active Directory site được dự trữ trong khoảng vài ngày trong một tuần ở sau phần còn lại của miền. Rõ ràng, có một số vấn đề phát sinh (gotchas) khi thực hiện điều này, tuy nhiên về cơ bản một lag site sẽ dự trữ được một backup “sống” cho Active Directory. Bạn tạo một lag site bằng cách đặt một domain controller từ một hub site vào một site riêng (chúng tôi gọi nó là site khôi phục thảm họa) với một liên kết site đến hub site. Cấu hình liên kết hub site khôi phục thảm họa để có tần xuất tái tạo là 96 giờ. Điều đó có nghĩa rằng một copy sẽ được thực hiện sau 96 giờ phía sau phần còn lại của forest.
Lúc này, cần nhớ rằng, nếu một quản trị viên nào đó do vô tình xóa một OU có 10.000 người dùng thì những gì bạn chỉ có thể làm lúc này là thực hiện một khôi phục thẩm định (và hy vọng thiết bị backup của mình hợp lệ). Điều đó có nghĩa rằng bạn phải thực hiện quá trình khôi phục thẩm định sau: 1. Cách ly một domain controller có copy thẩm định của Active Directory ra khỏi mạng. 2. Lấy lưu trữ backup trạng thái hệ thống thích hợp mà bạn đã thực hiện trước khi xóa. 3. Bảo đảm rằng lưu trữ này là hợp lệ và nó không bị “cũ” so với giới hạn (mặc định là 60 ngày). 4. Khởi động restore domain controller trong chế độ Directory Service Restore Mode (DSRM). 5. Thực hiện khôi phục trạng thái hệ thống cho domain controller này. Lưu ý rằng bạn cần phải thực hiện hai lần để khôi phục nhóm và người dùng đúng cách. Điều này không tầm thường chút nào. 6. Sát nhập domain controller vào mạng. 7. Bản sao sẽ thực thi các đối tượng Active Directory từ domain controller được khôi phục vào các domain controller khác trong mạng. Mặc dù vậy với lag site, bạn có một domain controller có chứa bản copy Active Directory trước khi hành động xóa vô tình xảy ra (giả định rằng bạn đã phát hiện thấy điều đó trong khoảng thời gian 4 ngày xuất hiện). Giả định rằng bạn đã phát hiện rằng một quản trị viên đã vô tình xóa mất 10.000 tài khoản ngày hôm qua. Khi đó bạn có thể vào domain controller trong lag site, nơi có một copy Active Directory trước khi xóa và thực hiện một hành động khôi phục thẩm định bằng copy domain controller của Active Directory.
Copy này phụ thuộc vào thời điểm lag site sao chép và thời điểm hành động xóa xảy ra. Nếu quá trình sao chép xảy ra vào hôm thứ Hai và thứ Sáu còn hành động xóa xảy ra vào tối thứ Ba thì bạn có chỉ có một cơ hội rất nhỏ. Kiểm soát những vấn đề phát sinh (gotchas) Điều quan trọng ở đây là bạn cần thực hiện các bước để ngăn chặn sự thẩm định từ các domain controller của lag site từ khi nó có dữ liệu bảo mật (tài khoản, mật khẩu, tài khoản bị khóa, thành viên nhóm,…) một tuần tuổi. Bạn có thể thực hiện điều này bằng cách định nghĩa một chính sách site cho lag site và định nghĩa thiết lập "DCLocator DNS Records Not Registered by the DCs". Trường Mnemonics được mô tả trong tab Explain. Bạn cần gộp tất cả Mnemonics ngoài trừ bản ghi CNAME (cần thiết cho bản sao). Tab Explain có đôi chút lộn xộn, tuy nhiên nó là một danh sách được phân định theo khoảng trống như thể hiện trong hình 1 bên dưới. Bản thân Mnemonics được liệt kê trong cột bên trái trên tab Explain.
Hình 1: Danh sách phân định theo khoảng trống trong một lag site Cấu hình tối thiểu để thực thi một Active Directory lag site là phải có một site có ít nhất một domain controller từ mỗi miền trong site. Cấu hình được ưa thích là phải có hai domain controller từ mỗi miền trong site. Thiết lập tần suất tạo bản sao là 168 giờ mỗi tuần và dao động lịch trình để chúng tạo bản sao cứ 3,5 ngày một lần. Như vậy bạn sẽ có hai copy cũ để có thể lựa chọn, vấn đề sẽ được giảm một cách rõ rệt. Bạn cũng có thể sử dụng Virtual Server như các domain controller của lag site để tiết kiệm chi phí phần cứng. Nếu có một cấu trúc phức tạp (cha/con), thì bạn có rất nhiều vấn đề không thấy rõ. Khi thử một khôi phục trên một miền, bạn sẽ thất bại trong việc khôi phục các thành viên nhóm trong toàn miền. Hewlett-Packard Co. là công ty
lần đầu tiên phát hiện ra vấn đề này và công ty này đã phát triển một công cụ mang tên Active Directory Link Replication Manager (ADLRM) để lưu các liên kết này trong một cơ sở dữ liệu SQL và khôi phục chúng khá tiện lợi. Công cụ này cũng có thể lưu và khôi phục các thuộc tính riêng lẻ. Cho ví dụ, nếu bạn có một ứng dụng quản trị nhân sự (HR) đã thay đổi thuộc tính của một người dùng nào đó, trong khi đó bạn cần khôi phục lại thuộc tính này về giá trị được thay đổi trước đó, ADLRM sẽ cho phép bạn thực hiện điều đó mà không yêu cầu một quá trình khôi phục thẩm định toàn bộ. Một trong những khía cạnh quan trọng đối với công việc của các quản trị viên là khả năng khôi phục hệ thống từ một lỗi không mong muốn nào đó – có thể do chủ tâm hoặc do vô tình. Khôi phục thảm họa Active Directory có nhiều khía cạnh cần phải bảo đảm và chắc chắn nó phải phức tạp hơn việc giữ một backup trong tay bạn. Cách tốt nhất để bảo đảm rằng bạn có thể khôi phục thành công từ bất kỳ một tình huống lỗi nào – phần cứng hay phần mềm – là phải đi tiên phong (proactive). Thực hiện những bước đi để bảo đảm rằng doang nghiệp sẽ chỉ phải chịu một khoảng thời gian ngừng hoạt động máy móc ở mức tối thiểu. Trong bài này, chúng tôi sẽ giới thiệu cho các bạn cách bảo đảm rằng một bản sao Active Directory sẽ vẫn được duy trì mặc dù có xảy ra lỗi các domain controller nghiêm trọng. Thay đổi mật khẩu, thay đổi bảo mật, chính sách bảo mật và một loạt các thiết lập cấu hình quan trọng đều được thực thi thông qua Group Policy, bản sao FRS Replication và bản sao Active Directory và chịu trách nhiệm cho việc bảo đảm tất cả các bộ điều khiển miền đều có các thiết lập chính sách giống nhau. Vì vậy, vấn đề quan trọng nhất của doanh nghiệp là bảo đảm
rằng bảo sao Active Directory thành công và được duy trì một cách không ngắt quãng. Các công ty vẫn tạo một site khôi phục thảm họa là cách thường được thực hiện. Nhiều mạng công ty được cấu hình theo một vài topo mạng giống như những gì thể hiện trong hình 1 bên dưới. Lưu ý rằng trong một số cấu hình, có nhiều hub tạo thành một lõi cho bản sao Active Directory. Có nhiều hub site lõi chứa cấu hình khôi phục thảm họa cố hữu. Do đó khi một site lõi gặp vấn đề sẽ có các site khác chia sẻ tải. Hình 1: Topo mạng đa hub và đơn hub Với các cấu hình hub đơn, khó khăn cho việc khôi phục thảm họa là tạo một Active Directory site trong một location được kết nối tốt trong mạng, ghép cặp với ít nhất một domain controller từ mỗi miền trong mỗi forest trong doanh nghiệp. Điều này gồm có ít nhất một máy chủ global catalog (GC), các máy chủ Exchange và cá máy chủ ứng dụng cũng như file/print khác, phụ thuộc vào cơ sở hạ tầng được yêu cầu để hỗ trợ cộng đồng người dùng.
Giả dụ rằng chúng ta đã chọn một site như vậy và có cơ sở hạ tầng máy chủ cần thiết, một trong những thứ mà chúng ta cần phải định rõ là những gì xảy ra trong việc tạo bản sao Active Directory khi hub site chính gặp sự cố. Nhớ rằng chúng ta sẽ không phải đợi cho đến khi gặp một tấn công khủng bố để thấy hiện tượng xảy ra – một lỗi mạng đơn giản hoặc hiện tượng mất điện cũng có thể dẫn đến lỗi này. Xem xét trường hợp nơi mạng có topo hub-and-spoke (trục bánh xe và nan hoa) có một hub đơn. Site khôi phục thảm họa được thiết kế tốt sẽ gánh tải trọng nếu hub site chính bị lỗi. Trong việc tạo dự phòng bản sao Active Directory phòng khi lỗi ở tất cả các domain controller tại hub site bị lỗi, mô hình được đưa ra là tạo các liên kết cho cả hub site chính và site khôi phục thảm họa (DR site) như thể hiện trong hình 2. Ở đây chúng ta thấy rằng các liên kết site đang kết nối các site từ xa với hub site chính có cost bằng 100, các liên kết kết nối các site từ xa đến site khôi phục thảm họa có cost bằng 200. Các liên kết dự trữ sẽ không được sử dụng khi các domain controller trong site chính hoạt động, điều này là vì đường dẫn có cost bé nhất sẽ ưu tiên các liên kết site chính hơn các các liên kết site từ xa. Mặc dù vậy, trong quá trình test, các domain controller của site chính bị vô hiệu hóa, chúng tôi vẫn phát hiện thấy rằng KCC đã ước tính một topo khác so với kiến trúc dự định, tạo ra các kết nối qua lại giữa các site từ xa thay cho trực tiếp đến site khôi phục thảm họa. Các cố gắng để sửa hầu như đều trở nên vô nghĩa. Khi nghiên cứu nhằm chỉ ra chính xác tại sao topo này lại được tính toán theo cách đó thì một đánh giá về các rule bản sao Active Directory đơn giản đã cho thấy rằng, vấn đề thực sự nằm ở thiết kế.
Hình 2: Cấu hình hub site đơn với site khôi phục thảm họa Bản sao Active Directory có tính năng dự trữ kèm theo (built-in) mang tên Site Link Bridge. Site Link Bridge cho phép KCC có thể xây dựng các liên kết ngoại động (transitive) trong sự kiện lỗi của một domain controller trong site đã cho nào đó, cho phép bản sao định tuyến xung quanh các domain controller bị lỗi mà không cần bất cứ sự can thiệp nào của con người. Điều này tỏ ra đặc biệt quan trọng trong trường hợp domain controller lỗi là domain controller duy nhất trong site (hay tất cả các domain controller trong site lỗi như kịch bản trong ví dụ của chúng ta). Xem xét trường hợp trong hình 3. Ở đây có 3 site - ATL, CHI, và NYC. Giả định rằng mạng vật lý kết nối tất cả ba site, liên kết site kết nối ATL và CHI, liên kết site kết nối CHI và NYC. Tuy nhiên không có liên kết site kết nối ATL và NYC. Chỉ cần domain controller nằm trong CHI còn sống thì bản sao là hoàn toàn không có gì phải lo ngại. Tuy nhiên điều gì sẽ xảy ra nếu domain controller của CHI bị lỗi? Có vẻ rằng bản sao giữa ATL và NYC sẽ lỗi – chắc chắn là như vậy – mà không có Site Link Bridge. Nếu Site Link Bridge được kích hoạt, khi đó ATL có thể tạo bản sao cho CHI và CHI có thể tạo bản sao cho NYC nên ATL có thể tạo bản sao với NYC. Sau đó một liên kết từ ATL đến NYC với một cost bằng cost được kết hợp giữa các liên kết CHI-NYC và ATL- CHI sẽ được tạo (xem trong hình 4).
Hình 3: Site ATL tạo bản sao cho site LA thông qua các bộ điều khiển miền CHI site Hình 4: Trong trường hợp CHI site bị lỗi, Site Link Bridge sẽ được kích hoạt, khi đó KCC sẽ tạo một liên kết transitive giữa ATL site và LA site để cho phép thực hiện sao chép. Cần lưu ý rằng KCC không thể thấy mạng vật lý và dựa vào quản trị viên để cấu hình các liên kết site sẽ kết nối các domain controller trong mạng vật lý. Trong trường hợp site CHI lỗi, KCC biết rằng có kết nối từ CHI-NYC và ATL-CHI, mạng vật lý kết nối ATL và NYC – tuy nhiên quản trị viên lại không tạo một liên kết site rõ ràng từ ATL-NYC. Do đó KCC sẽ giám sát và
chăm sóc bản sao này một cách liên tục giữa ATL và NYC, cho tới khi CHI hoạt động trở lại, trong trường hợp đó KCC bỏ rơi các kết nối ATL-NYC và thiết lập các kết nối gốc thông qua CHI. Chúng ta có thể quyết định vô hiệu hóa Site Link Bridge (mặc định nó vẫn được kích hoạt) và tạo liên kết ATL- NYC một cách đơn giản, tuy nhiên trong môi trường lớn, điều này có thể khó cho việc quản lý. Cần lưu ý rằng, Windows 2000 có một số hạn chế nhất định, ví dụ như trong một doanh nghiệp không được có quá 200 site có các domain controller được kích hoạt, không có quá 120 site bản sao cho một hub site. Hạn chế này dẫn đến tình trạng các quản trị viên thường phải vô hiệu hóa tính năng Sitel Link Bridge để giảm tải trên KCC và loại trừ một số vấn đề khác. Tuy nhiên Windows 2003 sử dụng một thuật toán hoàn toàn khác cho việc mở rộng cây, cho phép KCC có thể khắc phục các hạn chế và cho phép chúng ta có thể sử dụng Site Link Bridge. Vậy, tất cả những thứ mà Site Link Bridge phải thực hiện cho việc loại trừ các liên kết sao chép được tạo từ site khôi phục thảm họa cho các site từ xa trong trường hợp của ví dụ là gì? Nếu chúng ta sử dụng ví dụ trước với các site ATL, NYC và CHI thì chúng ta có thể thấy cách nó làm việc như thế nào. Trong ví dụ đó, hãy giả sử rằng CHI là một hub site và ATL là site khôi phục thảm họa. Tuy nhiên thay vì chỉ có NYC là site từ xa, chúng ta có nhiều site từ xa khác, và rõ ràng SLB được kích hoạt. Chúng ta đã thấy trong ví dụ, cách site từ xa NYC được tạo bản sao cho ATL khi các domain controller của CHI site bị lỗi như thế nào. Kich bản này có thể được áp dụng cho tất cả các site từ xa khác. Chính vì vậy nếu các domain controller trong CHI gặp lỗi, KCC sẽ chọn CHI không có domain controller để tạo bản sao
và sẽ tạo các liên kết đến ATL, cho phép các đối tượng kết nối được tạo giữa các site từ xa và ATL, hoàn tất quá trình chuyển đổi dự phòng. Một số điểm quan trọng khác:  Cần có liên kết site có cost thấp giữa hub site chính và site khôi phục thảm họa để bảo đảm sự cập kịp thời site khôi phục thảm họa với site chính. Điều này cũng ngụ ý rằng, mạng vật lý cần phải có liên kết tin cậy và tốc độ cao giữa hai site này.  Không tạo các liên kết site giữa site khôi phục thảm họa và các site từ xa.  Không tự tạo các đối tượng kết nối đến site khôi phục thảm họa.  Windows 2000 có nhiều nhược điểm trong việc dọn dẹp các đối tượng kết nối cũ khi site lỗi hoạt động trở lại, yêu cầu các quản trị viên phải tự thực hiện hành động này. Tuy nhiên Windows 2003 đã khắc phục được yếu điểm này.  Tất cả đều dựa vào việc có kết nối mạng vật lý giữa site khôi phục thảm họa và các site từ xa.  Cần test cẩn thận trong phòng lab trước khi đưa vào môi trường ứng dụng.  Trong trường hợp có nhiều hub site lõi, khi một hub site bị lỗi (và Site Link Bridge được kích hoạt), KCC sẽ định tuyến các kết nối đến các nút khác. Tất cả chúng trở thành các site khôi phục thảm họa cho nhau. Lưu ý cuối cùng là thiết kế một topo tạo bản sao đơn giản nếu có thể (topo hub-and-spoke cung cấp một đường dẫn đơn giản đến các site từ xa), sau đó
cho phép Site Link Bridge cung cấp dự phòng trong trường hợp hub site chính bị lỗi.