Tạo VPN Site-to-site trên ISA 2006 (Phần 7)

Tạo VPN Site-to-site trên ISA 2006 (Phần 1)
Tạo VPN Site-to-site trên ISA 2006 (Phần 2)
Tạo VPN Site-to-site trên ISA 2006 (Phần 3)
Tạo VPN Site-to-site trên ISA 2006 (Phần 4)
Tạo VPN Site-to-site trên ISA 2006 (Phần 5)
Tạo VPN Site-to-site trên ISA 2006 (Phần 6)

Một số tác động của liên lạc RPC qua ISA Firewall.

Trong bài trước chúng ta đã các Enterprise Policy, cho phép đưa Domain Controller vào văn phòng chi nhánh. Chúng ta cũng đã được biết cách cấu hình tường lửa tự động, đặc biệt hữu ích khi triển khai các mảng ISA Firewall trên diện rộng.

Sau 6 phần đầu, đến giờ chúng đã đã tạo thành công và đưa vào hoạt động VPN Site-to-Site, đồng thời sẵn sàng triển khai Domain Controller branch office ở văn phòng chi nhánh. Tiếp đó là cài đặt Active Directory tích hợp DNS server trên DC và cấu hình ISA Firewall branch office sử dụng DNS server với vai trò như một server DNS chính. Điều này sẽ giúp loại bỏ phụ thuộc trên kết nối VPN Site-to-Site, tăng khả năng sẵn sàng cao cho dịch vụ DNS.

Trong bài trước chúng ta cũng xem xét tác động của các liên lạc RPC qua ISA Firewall. Ở bài này có một số điểm khác với nhiều câu hỏi khó trả lời hơn. Hy vọng, sau khi phân tích và “đưa vấn đề ra ánh sáng”, chúng ta có thể khai thác được thêm nhiều kiến thức và kinh nghiệm từ cộng đồng ISA Firewall qua các trả lời của họ.

Loại bỏ Strict RPC-compliancetrên quy tắc liên lạc nội miền

Một vấn đề phổ biến thường hay xảy ra từ khi các liên lạc thực hiện qua ISA Firewall là chức năng autoenrollment hoạt động không chính xác như mong muốn. Một vấn đề khác cũng liên quan mật thiết với nó là các chứng chỉ MMC snap-in không hoạt động được. Trước đây có một bài trong phần Hướng dẫn cơ bản (KB) của Microsoft chỉ ra rằng, nếu chúng ta loại bỏ strict RPC-compliance trên Access Rule thì hai chức năng này sẽ hoạt động bình thường.

Chúng ta cần chứng chỉ tự động thu hồi vì nó liên quan đến CA enterprise (cơ chế thẩm định doanh nghiệp) cài đặt trên Domain Controller của trụ sở chính. CA enterprise cho phép bạn đặt tự động chứng chỉ CA trong khu lưu trữ chứng chỉ máy Trusted Root Certificate Authorities của tất cả thành viên miền. Quả là rất tiện lợi, vì tất cả thành viên miền sẽ tự động tin tưởng tất cả chứng chỉ do PKI enterprise của chúng ta cấp.

Thực hiện các bước sau để loại bỏ Strict RPC-compliancetrên Access Rule của liên lạc nội miền:

1. Trong console ISA Firewall, mở rộng nút Enterprise, sau đó là nút Enterprise Policies. Chọn nút Branch Policy và kích phải chuột lên Branch DCs > Main DC Access Rule, bấm chọn Configure RPC protocol.

2. Trong hộp thoại Configure RPC protocol policy, bỏ dấu chọn ở ô Enforce strict RPC compliance. Kích OK.

3. Ấn Apply để ghi lại các thay đổi và update chính sách tường lửa. Bấm OK trong hộp thoại Apply New Configuration.

Nhiều người đặt ra câu hỏi là liệu chúng ta có nên cho phép sử dụng lại Strict RPC-compliance sau khi cài đặt DC branch office không. Thực ra chưa có câu trả lời thoả đáng nào cho vấn đề này, vì các chi tiết chính xác của thiết lập không được công bố rộng rãi. Để kiểm tra, bạn có thể giả sử rằng sẽ an toàn hơn khi cho phép sử dụng strict RPC-compliance. Nhưng liệu thành phần bảo mật này có phá vỡ một số chức năng cơ bản cốt yếu. Suy cho cùng, lựa chọn tốt nhất cho chúng ta là loại bỏ thành phần này.

Nói vậy nhưng, quyết định cuối cùng là tuỳ thuộc vào bạn. Nếu không cần chức năng autoenrollment, bạn có thể sử dụng strict RPC-compliance.

Nhưng chú ý là không có cái gì gọi là câu trả lời chính xác hay câu trả lời sai ở đây cả. Chỉ là sự lựa chọn trường hợp bảo mật nào phù hợp nhất với hoàn cảnh của bạn mà thôi.

Chạy CDPromo trên máy Domain Controller branch office

Bây giờ chúng ta đã sẵn sàng cài đặt Domain Controller tại văn phòng chi nhánh. Thực hiện công việc này như thế nào là tuỳ thuộc vào môi trường của bạn. Có nhiều công ty tạo môi trường thử nghiệm với lược đồ địa chỉ IP xây dựng lại tương tự như thực tế của văn phòng chi nhánh. Sau đó cài đặt, cấu hình DC ở văn phòng chính trước, rồi mới gắn với văn phòng chi nhánh sau. Một số công ty khác lại gắn máy DC tại văn phòng nhánh, sau đó cử chuyên viên IT ở trụ sở chính tới để cài đặt DC.

Mỗi cách thức trên đều có những điểm lợi thế và bất cập riêng. Cá nhân tôi thích gửi các chuyên viên IT tới văn phòng chi nhánh hơn. Vì triển khai DC là vấn đề cực kỳ quan trọng, và thường tốt nhất là nên có một người nào đó biết cách xử lý các vấn đề tiềm ẩn phát sinh trực tiếp tại nơi triển khai.

Thực hiện các bước sau để cài đặt DC trên máy Domain Controller branch office:

1. Vào Start > Run > nhập dcpromo trong ô Open. Kích OK.
   
2. Bấm Next trên trang Welcome to the Active Directory Installation Wizard.
   
3. Đọc thông tin trên trang Operating System Compatibility và kích Next.
   
4. Trên trang Domain Controller Type, chọn tuỳ chọn Additional domain controller for an existing domain và kích Next.

5. Trên trang Network Credentials, nhập thông tin thẩm định của người dùng có quyền cài đặt các Domain Controller mới. Kích Next.

6. Trên trang Additional Domain Controller, kích chuột vào nút Browse và ấn chọn tên miền của main office. Ở ví dụ này, tên miền là msfirewall.org. Nhập tên miền vào danh sách trong hộp thoại Browse for Domain. Bấm OK và kích Next để tiếp tục.

7. Trên trang Database and Log Folders, chấp nhận các thiết lập mặc định và bấm Next.
   
8. Trên trang Shared System Volume, chấp nhận khu vực mặc định và bấm Next.
   
9. Nhập mật khẩu và kiểm chứng mật khẩu trên trang Directory Services Restore Mode Administrator Password rồi kích Next.
   
10. Kích Next trên trang Summary, kích Next tiếp.
    
11. Chương trình Installation Wizard bắt đầu. Giữ nguyên cho đến khi nào bạn thấy trang hoàn thành xuất hiện.

12. Kích Finish trên trang Completing the Active Directory Installation Wizard.

13. Kích vào nút Restart Now trong hộp thoại Active Directory Installation Wizard.

Chương trình Dcpromo hoạt động khá tốt. Không có lỗi nào xuất hiện trong quá trình cài đặt. Sau khi khởi động lại máy, mọi thành phần xuất hiện và hoạt động ổn định. Nếu mở Certificates MMC ra, bạn sẽ thấy chứng chỉ CA enterprise được tự động đưa đến khu lưu trữ chứng chỉ Trusted Root Certification Authorities như chúng ta muốn. Bạn có thể thấy trong hình minh hoạ dưới đây.

Tuy nhiên, nếu mở Event Viewer ra, bạn sẽ thấy một số lỗi với các vấn đề thực sự xuất hiện. Hình minh hoạ bên dưới cho thấy chức năng autoenrollment không làm việc và Domain Controller branch office không nhận được một chứng chỉ DC nào. Đó có phải là lỗi thực, là vấn đề thực, là vấn đề liên quan đến ISA Firewall?

Hình 9

Hình bên dưới cho thấy một lỗi khác, có thể là đáng kể. Lỗi này chỉ ra rằng Domain Controller branch office không thể truy vấn danh sách nhóm đối tượng chính sách. Nghe giống như là một vấn đề lớn, nhưng có thực là như vậy không, có phải là vấn đề với ISA Firewall hay liên quan đến vấn đề khác?

Hình minh hoạ bên dưới thể hiện lỗi DCOM không liên lạc được với Domain Controller ở main office (Domain Controller.msfriewall.org). Đây có phải là lỗi liên quan đến ISA Firewall? Hay còn cái gì khác?

Hình 11

Các lỗi này có phải là thực? Có phải chúng được tạo ra trong quá trình khởi động trước khi VPN Site-to-Site được kích hoạt? Kiểm chứng lại thì điều này không chính xác.

Bạn có chắc chức năng tự động thu hồi không làm việc? Chúng ta đã thấy rằng chứng chỉ CA được tự động đưa vào khu lưu trữ chứng chỉ Trusted Root Certification Authorities. Có nên gán tự động một chứng chỉ DC? Hay chúng ta cần tạo một chính sách cho điều này?

Liệu bạn có chắc chắn Group Policy thực sự đang thực thi tiến trình của mình?

Để kiểm tra, hãy thực hiện một thay đổi nhỏ cho Domain Group Policy tại Domain Controller main office. Ví dụ, vào nút Desktop trong Administrative Templates ở User Configuration, như hình bên dưới.

Tiếp theo, kích đúp lên Remove Recycle Bin icon from desktop ở khung bên phải và bấm chọn khu vực Enable. Kích OK rồi chạy lệnh gpupdate /force trên Domain Controller main office. Sau khi hoàn thành, chạy lệnh gpupdate /force ở branch office. Chuyện gì xảy ra?

Bạn có thể thấy, Group Policy được ứng dụng ở cả văn phòng chi nhánh và trụ sở chính. Đối tượng Recycle Bin được loại bỏ trên màn hình desktop (bạn có thể phải Refesh lại desktop mới thấy được thay đổi này). Bởi vậy mà không phải lúc nào chúng ta cũng có thể tin tưởng được cái nhìn thấy trong Event Viewer.

Còn về Certificates MMC thì sao? Đáng tiếc, Certificates MMC không hoạt động. Tuy nhiên, có thể là do chúng ta không cấu hình ISA Firewall đáp ứng một số chi tiết cụ thể nào đấy. Dưới đây là một số hướng dẫn tham khảo đáng chú ý:

“Để yêu cầu một chứng chỉ cho máy tính ISA Server, xoá dấu chọn trong ô Enforce strict RPC compliance ở hộp thoại System Policy Editor. Để yêu cầu chứng chỉ cho máy tính client khi chế độ thẩm định chứng chỉ (Certification Authority) nằm trên mạng khác, bạn không phải chính sửa chính sách hệ thống trên máy ISA Firewall. Ở trường hợp này, bạn cần thay đổi các thiết lập quy tắc RPC-compliance strict hoặc các quy tắc cho phép lưu lượng được chuyển đổi giữa hai mạng. Để làm điều này, thực hiện theo các bước sau:

1. Khởi động chức năng ISA Server Management.
   
2. Mở rộng nút ServerName, kích chọn Firewall Policy.
   
3. Kích phải chuột lên quy tắc cho phép thực hiện lưu lượng giữa mạng có chế độ thẩm định Certification Authority và mạng máy tính client đang nằm trên.
   
4. Bấm chọn Configure RPC Protocol.
   
5. Loại bỏ dấu chọn trong ô Enforce strict RPC compliance và bấm OK.
   
6. Lặp lại từ bước 3 đến bước 5 để thay đổi các quy tắc trong system policy và cho phép các liên lạc DCOM giữa bất kỳ hai quy tắc khác nhau nằm trong hai mạng cụ thể.
   
7. Sau khi thay đổi xong các quy tắc chính sách (policy), bấm chọn Apply.

Hãy chú ý bước 6. Chính sách hệ thống (System Policy) sẽ như thế nào với bất kỳ hai quy tắc khác nhau nằm trong hai mạng cụ thể? Điều này có nghĩa là gì? Có phải tức là các quy tắc System Policy áp dụng cho các liên lạc giữa hai mạng ISA Firewall Network? Điều này có thể diễn ra như thế nào? System Policy chỉ kiểm soát các lưu lượng có nguồn hoặc từ ISA Firewall, hoặc được định hướng tới ISA Firewall. Tại sao System Policy Rule lại có thể kiểm soát lưu lượng giữa hai mạng được?

Liệu đây có phải là một bí mật nhỏ của nhóm phát triển ISA? Để kiểm tra, chúng ta hãy xem điều gì diễn ra nếu ngưng sử dụng RPC-compliance strict ở mức System Policy. Chỉ có một cách thực hiện là mở trình soạn thảo System Policy mức mảng ra.

Kích lên Firewall Policy ở khung bên trái console ISA Firewall và chọn tab Tasks trên Task Pane. Trong Task Pane, bấm chọn liên kết Edit System Policy. Kích lên Group Policy Authentication Services trong khung bên phải và bỏ dấu chọn trong ô Enforce strict RPC compliance. Kích OK. Thực hiện hoạt động này trên cả hai ISA Firewall.

Để kiểm tra, khởi động lại cả hai ISA Firewall, xem lại bảng trạng thái RPC để chắc chắn rằng các điểm vào đã được loại bỏ. Tôi không biết điều này có cần thiết không, nhưng đó là cách đáng tin cậy nhất để chắc chắn rằng các bảng đã được xoá sạch. Khởi động lại Domain Controller branch office, nhưng Certificates MMC bị lỗi kết nối với CA enterprise. Bạn sẽ thấy lỗi như hình bên dưới:

Cả hai lý do được đưa ra trong thông báo lỗi đều không chính xác. CA đang hoạt động trực tuyến và tài khoản người dùng đăng nhập là quản trị doanh nghiệp. Một số lý do thực sự ở đây là:

Hình 16

Các thông tin điểm vào file log này được ghi lại khi yêu cầu chứng chỉ được gửi từ branch office Domain Controller tới main office Domain Controller, cũng là một CA enterprise.

Tóm tắt

Trong bài này chúng ta đã kiểm tra lại một số hoạt động diễn ra sau khi cài đặt Domain Controller tại văn phòng chi nhánh. Đáng tiếc là số câu hỏi được đặt ra nhiều hơn so với phần trả lời nhận được. Một số hướng dẫn của Microsoft cho rằng tất cả vấn đề gặp phải ở đây nên xử lý bằng cách ngưng sử dụng strict RPC compliance, nhưng chúng ta vẫn thấy một số lỗi RPC liên quan đến hoạt động liên lạc xuất hiện trong Event Viewer. Liệu có nên tin tưởng vào tất cả thông báo sự kiện trong Event Viewer? Trình xem sự kiện này thông báo tiến trình Group Policy không hoạt động, nhưng thực tế Group Policy đã được ứng dụng. Còn về cơ chế thu hồi tự động (autoenrollment)? Có lẽ chúng ta cần tạo một policy trước. Sau đó là vấn đề Certificates MMC.

Hiện tại có nhiều câu hỏi hơn câu trả lời được đặt ra. Nhưng có thể nói rằng, trong hầu hết các phần, Domain Controller hoạt động khá ổn định. Chúng ta sẽ tiếp tục gặp lại nhau trong bài cấu hình lớp Active Directory cho văn phòng chi nhánh và cấu hình liên kết lớp. Chúng ta cũng sẽ tạo DNS server trên DC branch office và thay đổi thiết lập DNS trên ISA Firewall ở bài sau.

(Còn nữa)