Windows Active Directory đặt tên thực hành tốt nhất?

Đây là một câu hỏi Canonical về đặt tên miền Active Directory.

Sau khi thử nghiệm với các miền Windows và bộ điều khiển miền trong môi trường ảo, tôi nhận ra rằng có một miền thư mục hoạt động được đặt tên giống hệt với miền DNS là ý tưởng tồi (Có nghĩa là có example.commột tên Active Directory là không tốt khi chúng ta có example.comtên miền đăng ký sử dụng như trang web của chúng tôi).

Câu hỏi liên quan này dường như ủng hộ kết luận đó , nhưng tôi vẫn không chắc chắn về những quy tắc khác có xung quanh việc đặt tên miền Active Directory.

Có cách thực hành tốt nhất nào về tên Active Directory nên hay không nên là gì không?

Đây là một chủ đề thảo luận thú vị về Server Fault. Dường như có nhiều "quan điểm tôn giáo" khác nhau về chủ đề này.

Tôi đồng ý với khuyến nghị của Microsoft : Sử dụng tên miền phụ của tên miền Internet đã đăng ký của công ty.

Vì vậy, nếu bạn sở hữu foo.com, sử dụng ad.foo.comhoặc một số như vậy.

Điều tệ hại nhất, như tôi thấy, là sử dụng tên miền Internet đã đăng ký, nguyên văn, cho tên miền Active Directory. Điều này khiến bạn buộc phải sao chép thủ công các bản ghi từ Internet DNS (như www) vào vùng DNS của Active Directory để cho phép các tên "bên ngoài" giải quyết. Tôi đã thấy những thứ hoàn toàn ngớ ngẩn như IIS được cài đặt trên mọi DC trong một tổ chức đang chạy một trang web thực hiện chuyển hướng sao cho ai đó truy cập foo.comvào trình duyệt của họ sẽ được chuyển hướng đến www.foo.comcác cài đặt IIS này. Utter silliness!

Sử dụng tên miền Internet giúp bạn không có lợi thế, nhưng tạo ra "công việc" mỗi khi bạn thay đổi địa chỉ IP mà tên máy chủ bên ngoài đề cập đến. (Thử sử dụng DNS cân bằng tải theo địa lý cho các máy chủ bên ngoài và tích hợp điều đó với tình huống "DNS bị phân tách" như vậy! Gee-- điều đó sẽ rất vui ...)

Sử dụng một tên miền phụ như vậy không có tác dụng đối với những thứ như hậu tố email Exchange hoặc Tên gốc của người dùng (UPN), BTW. (Tôi thường thấy cả hai đều được trích dẫn là lý do để sử dụng tên miền Internet làm tên miền AD.)

Tôi cũng thấy cái cớ "rất nhiều công ty lớn làm điều đó". Các công ty lớn có thể đưa ra quyết định xương đầu dễ dàng (nếu không phải là moreso) so với các công ty nhỏ. Tôi không mua nó chỉ vì một công ty lớn đưa ra một quyết định tồi tệ mà bằng cách nào đó khiến nó trở thành một quyết định tốt.

Chỉ có hai câu trả lời đúng cho câu hỏi này.

1. Một tên miền phụ không được sử dụng của một tên miền mà bạn sử dụng công khai. Ví dụ: nếu sự hiện diện web công khai của bạn là example.comAD nội bộ của bạn có thể được đặt tên giống như ad.example.comhoặc internal.example.com.

2. Tên miền cấp hai không được sử dụng mà bạn sở hữu và không sử dụng ở bất kỳ nơi nào khác. Ví dụ: nếu sự hiện diện web công khai của bạn là example.comAD của bạn có thể được đặt tên example.net miễn là bạn đã đăng ký example.netvà không sử dụng nó ở bất kỳ nơi nào khác!

Đây là hai lựa chọn duy nhất của bạn. Nếu bạn làm điều gì khác, bạn sẽ để lại cho mình nhiều đau khổ và đau khổ.

Nhưng mọi người đều sử dụng .local!
Không quan trọng. Bạn không nên. Tôi đã viết blog về việc sử dụng .local và các TLD được tạo thành khác như .lan và .corp . Trong mọi trường hợp bạn không bao giờ nên làm điều này.

Nó không an toàn hơn. Đó không phải là "thực hành tốt nhất" như một số người tuyên bố. Và nó không có bất kỳ lợi ích nào trong hai lựa chọn mà tôi đã đề xuất.

Nhưng tôi muốn đặt tên giống như URL của trang web công cộng của mình để người dùng của tôi example\userthay vìad\user
Đây là mối quan tâm hợp lệ nhưng sai lầm. Khi bạn quảng cáo DC đầu tiên trong một tên miền, bạn có thể đặt tên NetBIOS của tên miền thành bất cứ thứ gì bạn muốn. Nếu bạn làm theo lời khuyên của tôi và thiết lập tên miền của bạn thành ad.example.com, bạn có thể định cấu hình tên NetBIOS của tên miền để examplengười dùng của bạn sẽ đăng nhập example\user.

Trong Active Directory Forests and Trust, bạn cũng có thể tạo thêm hậu tố UPN. Không có gì ngăn bạn tạo và đặt @ example.com làm hậu tố UPN chính cho tất cả các tài khoản trong miền của bạn. Khi bạn kết hợp điều này với khuyến nghị NetBIOS trước đó, sẽ không có người dùng cuối nào thấy FQDN của tên miền của bạn ad.example.com. Tất cả mọi thứ mà họ nhìn thấy sẽ là example\hoặc @example.com. Những người duy nhất sẽ cần làm việc với FQDN là các quản trị viên hệ thống làm việc với Active Directory.

Ngoài ra, giả sử rằng bạn sử dụng không gian tên DNS tách đôi, có nghĩa là tên AD của bạn giống với trang web công khai của bạn. Bây giờ, người dùng của bạn không thể truy cập example.comnội bộ trừ khi bạn có tiền tố www.của họ trong trình duyệt của họ hoặc bạn chạy IIS trên tất cả các bộ điều khiển miền của bạn (điều này rất tệ). Bạn cũng phải quản lý haicác vùng DNS không giống nhau có chung một không gian tên rời rạc. Nó thực sự rắc rối hơn giá trị của nó. Bây giờ hãy tưởng tượng rằng bạn có quan hệ đối tác với một công ty khác và họ cũng có cấu hình DNS chia đôi với AD và sự hiện diện bên ngoài của họ. Bạn có một liên kết sợi riêng giữa hai người và bạn cần tạo niềm tin. Giờ đây, tất cả lưu lượng truy cập của bạn đến bất kỳ trang web công cộng nào của họ đều phải truy cập liên kết riêng thay vì chỉ truy cập Internet. Nó cũng tạo ra tất cả các loại đau đầu cho các quản trị viên mạng ở cả hai bên. Tránh điều này. Tin tôi đi

Nhưng nhưng ...
Nghiêm túc mà nói, không có lý do gì để không sử dụng một trong hai điều mà tôi đã đề xuất. Bất kỳ cách nào khác đều có cạm bẫy. Tôi không bảo bạn vội vàng thay đổi tên miền nếu nó hoạt động và tại chỗ, nhưng nếu bạn đang tạo một AD mới, hãy thực hiện một trong hai điều mà tôi đã đề xuất ở trên.

Để hỗ trợ câu trả lời của MDMarra:

Bạn KHÔNG BAO GIỜ nên sử dụng tên DNS một nhãn cho tên miền của mình. Điều này đã / có sẵn trước Windows 2008 R2. Lý do / giải thích có thể được tìm thấy ở đây: Triển khai và vận hành các miền Active Directory được cấu hình bằng cách sử dụng tên DNS nhãn đơn | Hỗ trợ của Microsoft

Đừng quên KHÔNG sử dụng các từ dành riêng (một bảng được bao gồm trong liên kết "Quy ước đặt tên" ở cuối bài này), chẳng hạn như HỆ THỐNG hoặc THẾ GIỚI hoặc GIỚI HẠN.

Tôi cũng đồng ý với Microsoft rằng bạn nên tuân theo hai quy tắc bổ sung (không được đặt ra, nhưng vẫn):

1. Bạn KHÔNG nên đặt tên miền của mình dựa trên thứ gì đó sẽ thay đổi hoặc trở nên lỗi thời. Ví dụ bao gồm đặt tên miền của bạn theo dòng sản phẩm, hệ điều hành hoặc bất kỳ thứ gì khác có khả năng thay đổi theo thời gian. Gắn bó với một cái gì đó hoặc theo địa lý hoặc cụ thể đủ để có ý nghĩa 5 hoặc thậm chí 10 năm sau.
2. Gắn với tên ngắn từ 15 ký tự trở xuống, điều này sẽ cho phép tên NETBIOS dễ dàng giống với tên miền.

Cuối cùng, tôi khuyên bạn nên suy nghĩ lâu dài càng nhiều càng tốt. Các công ty thực hiện thông qua sáp nhập và mua lại, ngay cả các công ty nhỏ. Cũng nghĩ về việc nhận được sự giúp đỡ / tư vấn bên ngoài. Sử dụng tên miền, cấu trúc AD, v.v ... sẽ có thể giải thích được cho các chuyên gia tư vấn hoặc người dân ở đây trên SF mà không cần nỗ lực nhiều.

Liên kết kiến ​​thức:

http://technet.microsoft.com/en-us/l Library / cc731265% 28v = ws.10% 29.aspx

http://support.microsoft.com/kb/909264

http://support.microsoft.com/kb/300684/vi-us

Trang đề xuất hiện tại (W2k12) của Microsoft cho tên miền rừng gốc

Tôi không đồng ý với việc sử dụng:

• example.com - vì những lý do đã được nêu trong các câu trả lời khác

Tôi có thể chấp nhận sử dụng:

• ad.example.com - - vì những lý do đã được nêu trong các câu trả lời khác

Nhưng tôi sẽ không tự làm hoặc giới thiệu nó. Trong quá trình tiếp quản công ty, việc xây dựng lại thương hiệu tất cả sẽ phá vỡ đặc biệt là khi quản lý tại thời điểm đó muốn mọi thứ thay đổi ngay lập tức. Đổi tên di cư, thay đổi là rất khó khăn hoặc tốn kém.

Cách tốt nhất tôi muốn giới thiệu là mua tên miền không liên quan đến tên công ty và cũng không liên quan đến thương hiệu của công ty. SIMPLE.CLOUD hoặc tương tự sẽ hoạt động tốt miễn là bạn có thể sở hữu nó.

Tôi đã thấy các công ty lớn với 150 nghìn người dùng sử dụng AD vẫn tham khảo công ty cũ mà họ đã mua cách đây nhiều năm hoặc các công ty đã thay đổi tên và mặc dù về lâu dài bạn không sử dụng \ login (nếu bạn không thể sử dụng UPN) nó vẫn trông tệ trước mặt quản lý, người không hiểu tại sao việc thay đổi nó không tầm thường.

Tôi luôn luôn làm mydomain.local.

local không phải là một TLD hợp lệ, vì vậy nó không bao giờ cạnh tranh với một mục nhập DNS công cộng thực tế.

Ví dụ, tôi muốn có thể biết rằng nó web1.mydomain.localsẽ phân giải IP bên trong của máy chủ web, trong khi web1.mydomain.comsẽ phân giải thành IP bên ngoài.