Làm thế nào để một hệ thống máy khách trong mạng Active Directory tìm thấy nó nằm ở vị trí nào?


21

Khi tôi tập hợp một bài thuyết trình để bắt đầu quản trị Windows, tôi đã bị bất ngờ với một câu hỏi mà tôi ngạc nhiên rằng tôi đã không hỏi sớm hơn.

Tôi biết điều đó:

  • AD được thiết lập một cách hợp lý trong các trang web để hỗ trợ sao chép và giảm độ trễ của truyền thông cần thiết giữa các máy khách và dịch vụ miền.
  • Các trang web được xác định bởi các mạng con được áp dụng cho chúng
  • tên miền phụ _msdcs chứa một hệ thống phân cấp các bản ghi SRV để tra cứu chung (_tcp) và cho tra cứu cụ thể theo trang web (_sites)
  • Máy tính bằng cách nào đó biết họ đang ở trang web nào, hoặc bộ điều khiển miền quyết định minh bạch trong một số phép thuật của DNS ... hay không?

Bài đăng trên blog này gợi ý rằng các máy khách trong mạng AD có thể "biết" trang web nào chúng là thành viên. Câu hỏi của tôi là, nếu đây là trường hợp, làm thế nào để họ tìm ra nó?

Nếu chính máy khách không biết, DC sẽ hỗ trợ máy như thế nào trong quá trình chọn dịch vụ AD gần nhất với máy khách đó?

Câu trả lời:


29

Câu trả lời là lần đầu tiên khách hàng xác thực Active Directory, nó không biết nó đang ở trang nào.

Khi lần đầu tiên gia nhập miền, khách hàng thực hiện các truy vấn DNS và LDAP chung và nhận danh sách tất cả các bộ điều khiển miền trong miền và nó đi xuống danh sách, thử liên kết LDAP và DC thành công đầu tiên mà nó liên kết với - đó là DC đầu tiên nó xác thực với.

Sau khi máy khách đã tham gia miền, Active Directory sẽ cho khách hàng biết nó thuộc về trang nào. Active Directory biết điều này bởi vì quản trị viên đã đặt mạng con IP của máy khách vào Trang web & Dịch vụ của AD và liên kết nó với Trang web.

Active Directory cho khách hàng biết trang web AD của nó là gì và khách hàng lưu trữ trong sổ đăng ký của chính nó trong HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DynamicSiteNamegiá trị đăng ký. Bằng cách đó, lần sau khi máy khách khởi động, nó sẽ biết truy vấn DNS dành riêng cho trang web nào để chỉ nhận các DC có trong trang web đó.

Tất nhiên hành vi đầy đủ được ghi lại trong KB247811 , nhưng nếu bạn muốn tự mình xem, bạn có thể chạy Wireshark hoặc NetMon và thực hiện theo dõi gói tin, sau đó tham gia một tên miền trong khi dấu vết đang chạy. Bạn sẽ thấy trình tự chính xác của các truy vấn DNS và liên kết LDAP. Các truy vấn DNS và liên kết LDAP tiếp theo được thực hiện cho các phân vùng cụ thể theo trang web bởi vì máy khách đã được AD cho biết trang web đó thuộc về trang web nào.

Dịch vụ Netlogon sẽ định kỳ làm mới thông tin trang web AD của nó, vì vậy nếu bạn chuyển sang một mạng khác, khách hàng của bạn sẽ tự động nhận được trang web mới. Điều này có thể được điều chỉnh trong HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\SiteNameTimeoutgiá trị đăng ký. ( Liên kết )


GAH! Bạn đánh bại tôi vào nó!
MDMarra

4
@MDMarra Đó là một sự cố hiếm gặp.
Ryan Ries

Vì tò mò, kiểm tra netlogon có bao giờ được thực hiện lại không? Chẳng hạn, nếu tôi có một hệ thống trong Site1 và sau đó chuyển người và thiết bị sang Site2, liệu máy có còn nhận dạng và tiếp tục nói chuyện với Site1 không?
Peter Grace

Thật ra tôi lấy lại cái đó. Netlogon có thể cập nhật tên trang web động mà không cần khởi động lại: technet.microsoft.com/en-us/l Library / cc958488.aspx
Ryan Ries

@RyanRies nếu bạn muốn đưa nó vào văn bản câu trả lời của bạn, điều đó thật tuyệt vời, nếu không tôi sẽ chỉnh sửa câu trả lời để kết hợp nó.
Peter Grace

8

Thực tế có một số chức năng / API liên quan đến nhau. Mặc dù chúng dài, nhưng đây thực sự là một số cách đọc Active Directory thú vị hơn.

Bất kể lời giải thích dưới đây, có hai điều bạn cần lưu ý:

  • Nếu một DC trong trang web cục bộ không phản hồi vì bất kỳ lý do gì, dự kiến ​​khách hàng sẽ liên hệ với bất kỳ bộ điều khiển miền nào trong miền. Điều này là bình thường và nó luôn là hành vi mặc định. Đôi khi không rõ tại sao nó lại xảy ra.

  • Đó có thể là tối ưu. Hãy xem xét kịch bản sau: Ba trang web: Thành phố New York (trung tâm / trung tâm dữ liệu - nhanh), Los Angeles (đã nói với NYC - nhanh) và Kazakhstan (đã nói với NYC - chắc chắn không nhanh). Nếu khách hàng của bạn trong trang LA không thể liên hệ với DC địa phương vì bất kỳ lý do gì, không thể tin được rằng nó sẽ xác thực với Kazakhstan.

Có một vài giải pháp. Bạn có thể làm một hoặc cả hai.

  • Microsoft đã tạo cài đặt Chính sách nhóm / đăng ký một cách thông minh có tên là TryNextClosestSite. Điều đó có nghĩa là khách hàng LA nên thử NYC trước khi chuyển vùng trên hành tinh tìm kiếm DC. Rực rỡ! Phải mất tám năm, nhưng cuối cùng chúng tôi đã có được điều đó với Vista / 2008. Hãy nhớ rằng, không được bật theo mặc định, bạn cần tạo GPO để kích hoạt tính năng này.

  • Đối với các trang web nói mà bạn thực sự không muốn DC phục vụ khách hàng trong các trang web khác, bạn có thể tạo cài đặt đăng ký / Chính sách nhóm chỉ định bản ghi DNS nào không nên đăng ký. Điều này được gọi là DNS Mnemonics.


Tìm bộ điều khiển miền trong trang web gần nhất (API DsGetSiteName) http://technet.microsoft.com/en-us/l Library / cc978016.aspx

Ánh xạ địa chỉ IP thành tên trang web

"Trong quá trình khởi động Net Logon, dịch vụ Đăng nhập Net trên mỗi bộ điều khiển miền liệt kê các đối tượng trang trong bộ chứa Cấu hình. Đăng nhập Net trên mỗi bộ điều khiển miền cũng được thông báo về bất kỳ thay đổi nào được thực hiện cho các đối tượng trang. Net Logon sử dụng thông tin trang web để xây dựng một cấu trúc trong bộ nhớ được sử dụng để ánh xạ địa chỉ IP thành tên trang web.

"Khi một máy khách đang tìm kiếm bộ điều khiển miền nhận được danh sách các địa chỉ IP của bộ điều khiển miền từ DNS, máy khách sẽ bắt đầu truy vấn bộ điều khiển miền để tìm ra bộ điều khiển miền nào khả dụng và phù hợp. Active Directory chặn truy vấn, chứa Địa chỉ IP của máy khách và chuyển nó đến Net Logon trên bộ điều khiển miền. Net Logon tìm địa chỉ IP của máy khách trong bảng ánh xạ mạng con đến trang web của nó bằng cách tìm đối tượng mạng con phù hợp nhất với địa chỉ IP của máy khách và sau đó trả về các thông tin sau:

  • Tên của trang web nơi khách hàng được đặt hoặc trang web phù hợp nhất với địa chỉ IP của khách hàng.

  • Tên của trang web trong đó bộ điều khiển miền hiện tại được đặt.

  • Một bit cho biết bộ điều khiển miền tìm thấy được đặt (bit được đặt) hay không được đặt (bit không được đặt) trong trang web gần máy khách nhất.

"Bộ điều khiển miền trả về thông tin cho máy khách. Phản hồi cũng chứa nhiều thông tin khác mô tả bộ điều khiển miền. Máy khách kiểm tra thông tin để xác định xem có nên tìm bộ điều khiển miền tốt hơn hay không. Quyết định được đưa ra như sau:

"Nếu bộ điều khiển miền trả về nằm trong trang gần nhất (bit được trả về được đặt), máy khách sẽ sử dụng bộ điều khiển miền này.

"Nếu máy khách đã cố gắng tìm bộ điều khiển miền trong trang web mà bộ điều khiển miền xác nhận máy khách được đặt thì máy khách sẽ sử dụng bộ điều khiển miền này.

"Nếu bộ điều khiển miền không ở trong trang gần nhất, máy khách sẽ cập nhật thông tin trang của nó và gửi truy vấn DNS mới để tìm bộ điều khiển miền mới trong trang. Nếu truy vấn thứ hai thành công, bộ điều khiển miền mới sẽ được sử dụng. Nếu truy vấn thứ hai không thành công, bộ điều khiển miền gốc được sử dụng.

"Nếu tên miền được máy tính truy vấn giống như miền mà máy tính được nối, thì trang web mà máy tính cư trú (như được báo cáo bởi bộ điều khiển miền) được lưu trữ trong sổ đăng ký máy tính. tên trang web trong mục đăng ký DynamicSiteName trong HKEY_LOCAL_MACHINE \ HỆ THỐNG \ CurrentControlSet \ Services \ Netlogon \ Paramameter. Do đó, API DsGetSiteName trả về trang web đặt máy tính. "

Hàm DsGetDcName http://msdn.microsoft.com/en-us/l Library / ms675983% 28VS85% 29.aspx

Các loại Trình định vị http://technet.microsoft.com/en-us/l Library / cc978019.aspx

Chức năng dịch vụ thư mục
http://technet.microsoft.com/en-us/sub mô tả / ms675900% 28v = vs85% 29.aspx

Cách DNS hỗ trợ cho Active Directory hoạt động
http://technet.microsoft.com/en-us/l Library / cc759550% 28v = ws.10% 29.aspx

Cách tối ưu hóa vị trí của bộ điều khiển miền nằm bên ngoài trang web của khách hàng
http://support.microsoft.com/kb/306602

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.