Bài toán đặt ra:
Hệ thống domain của tổ chức Doanh nghiệp thông thường được tạo theo cấu trúc nội bộ, không liên quan tới hệ thống dịch vụ trên Internet. Nhưng vì một số lý do rất cơ bản, tổ chức doanh nghiệp lớn, nằm dải khắp các quốc gia khác nhau.
Khi dùng chung cấu trúc và tên 1 domain,
Ví dụ: Robusta.org , các đơn vị, tổ chức thành viên sẽ dùng lại đúng domain này cho hệ thống nội bộ tại quốc gia thành viên, đây là cách truyền thống, đơn giản, tiết kiệm thời gian.
Sau khi xây dựng các hạ tầng mới tài chi nhánh hoặc các tổ chức doanh nghiệp tại các quốc gia thành viên như: Ảo hóa VMware vCenter, Private Cloud…
Các chi nhánh và tổ chức danh nghiệp thành viên sẽ nảy sinh vấn đề mới đó là:
- Không thể copy sao chép giống y nguyên domain name của Head quarter do vấn đề conflic về tên miền, quản lý tên miền khi các chi nhánh có nhu cầu Public các dịch vụ Web Portal, Intranet, Private Cloud, Mobile Application cần có chữ ký số thuê của các hãng Cert Sign, Godaddy…
- Tên miền quản lý do Head quarter quản lý do vậy, khi đăng ký SSL/TLS sẽ phải do Admin IT của Head quarter control rất mất thời gian hoặc không chủ động điều khiển được từ phía chi nhánh, tổ chức thành viên.
- Các chi nhánh, tổ chức thành viên khi có đầu tư hạ tầng thường sẽ có các cơ cấu nhân sự, quản lý tài nguyên chủ động, độc lập thậm chí cấu trúc kỹ thuật CNTT khác đi so với cấu trúc ở trên:
Theo như mô hình trên đây thì chúng ta sẽ:
– Dễ dàng quản lý từng domain name cho các chi nhánh hoặc tổ chức doanh nghiệp thành viên mà không bị phụ thuộc vào việc xét duyệt
đợi điều khiển từ phía Head quarter mỗi lần có phát sinh từ đơn vị chi nhánh.
– Chủ động quản lý các tên miền, máy chủ, máy trạm, tài khoản người dùng, phân nhóm và đặc biệt là các dịch vụ SSL/TLS đăng ký để public intranet/extranet/internet.
Các phương án thay đổi:
1. Phương án 1: Xóa Domain tại các chi nhánh hoặc tổ chức Doanh nghiệp thành viên ( demote AD-DC, sau đó restart và dcpromo lại AD-DC với tên mới)
- Phương án này đơn giản lặp lại các bước đã làm, mất thời gian làm lại, nhưng có thể sẽ không phù hợp với các máy chủ dịch vụ đã cài và đang vận hành như: UC Voice Lync Conferencing, Exchange Server 2013 on-primise, MS SQL server enterprise, MS SharePoint farm, MS BizTalk Server Enterprise…
- Do tất cả các máy chủ trên được cài, cấu hình trên nền tảng Windows Authentication, cần Join Domain với tên domain chuẩn ban đầu có sẵn. Nếu hủy domain hiện thời sẽ dẫn tới mất Windows Authentication và WFC Platform cho phép các máy chủ dịch vụ chạy.
- Phương án này có thể gây sự cố không dùng lại được do các dịch vụ, cấu hình của những ứng dụng phức tạp, ứng dụng đã cấu hình theo tên miền cũ không tương thích, không phù hợp với cấu hình mới.
2. Phương án 2: Thay đổi tên miền (rename domain, sau đó join domain lại ở các máy chủ, máy trạm)
– Phương án này đơn giản trải qua hơn 28 bước thay đổi tên miền và join lại cho các máy trong tên miền của chi nhánh.
– Phương án này sẽ mất thời gian join domain lại các máy chủ dịch vụ, máy trạm với tên miền và tài khoản join domain admin mới.
– Phương án này sẽ không phải cấu hình lại toàn bộ các ứng dụng dịch vụ đang có, chỉ lưu ý các thông số của các trường hợp sau:
1. UC Server sẽ phải kiểm tra lại các tài khoản login dịch vụ theo kiểu UPN@domain và sau đó kiểm tra dịch vụ có dùng account domainusername.
Chứng chỉ CTL sẽ phải xóa bớt chứng chỉ gốc hoặc renew lại chứng thư số mới
2. MS SQL Server enterprise phải cấu hình quyền access login server và có thể cả quyền DB Admin theo dạng Mixed mode (cho phép account SQL Local “sa”) được phép truy cập MS SQL
khi gặp sự cố về Domain Controller hoặc thay đổi Domain name dẫn tới các account của domain name cũ điều khiển được MS SQL Server…
3. MS Exchange server sẽ phải chạy lại Exchange Configuration Wizard để re-buil lại cấu hình domain mới cho Mail Server re-configure
4. MS SharePoint server sẻ phải chạy lại SharePoint Server Configuration Wizard để re-buil Farm Server và một số cấu hình khác.
5. Phải backup các GPO của máy chủ AD-DC trước khi rename domain
3. Phương án 3: Không thay đổi tên miền, chỉ thêm các bí danh cho tên miền trên DNS Server (thêm các DNS Zone, bản ghi A (Host), CNAME, PTR, TXT, SRV)
– Phương án này đơn giản trải qua hơn 3 bước thay đổi các thông số tên máy chủ dịch vụ, mapping IP nội bộ các máy của chi nhánh.
– Phương án này sẽ mất ít thời gian kiểm tra máy trạm , máy chủ dịch vụ từ ngoài truy cập và hệ thống nội bộ để xác định các hạng mục có chạy ổn định hay không ?
– Phương án này có thể không phù hợp với toàn bộ hạ tầng ứng dụng của chi nhánh khi có nhiều chuẩn HĐH khác nhau, nhiều chuẩn kết nối dữ liệu người dùng khác nhau, ứng dụng đã fix code gọi LDAP/ADFS…
– Phương án này chỉ phù hợp với hạ tầng đã hoặc đang triển khai Private Cloud, giúp các các web portal intranet, các ứng dụng Windows Form… có thể kết nối và truy cập qua Internet bằng các trình duyệt web HTML5 smartphone, mobile device mà không cần thiết lập VPN kết nối Site – to – site.
Tóm lại, phương án 2 là hợp lý nhất.
Chi tiết các bước, các bạn nên tham khảo:
Các bước thay đổi tên miền: https://mizitechinfo.wordpress.com/2013/06/10/simple-guide-how-to-rename-domain-name-in-windows-server-2012/
Tham khảo các ghi chú về kỹ thuật thay đổi tên miền: http://technet.microsoft.com/en-us/library/cc738208(v=ws.10).aspx
Tham khảo support tình huống đăng ký lại chữ ký số mới cho UC: http://support.microsoft.com/kb/2464556/
Tham khảo cách đăng ký chữ ký số cho IIS8, IIS8.5: https://www.digicert.com/ssl-support/ssl-host-headers-iis-8.htm
Tham khảo cách đăng ký chữ ký số cho Exchange 2013: http://exchangeserverpro.com/exchange-server-2013-ssl-certificates/