How Domain Controllers Are Located in Windows

This article describes the mechanism used by Windows to locate a domain controller in a Windows-based domain.

This article applies to Windows 2000. Support for Windows 2000 ends on July 13, 2010. The Windows 2000 End-of-Support Solution Center is a starting point for planning your migration strategy from Windows 2000. For more information, see the Microsoft Support Lifecycle Policy.

Original product version: В Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: В 247811

Summary

This article details the process of locating a domain by its DNS-style name and its flat-style (NetBIOS) name. The flat-style name is used for backward compatibility. In all other cases, DNS-style names should be used as a matter of policy. This article also addresses troubleshooting the domain controller location process.

More information

This sequence describes how the Locator finds a domain controller:

On the client (the computer that is locating the domain controller), the Locator is initiated as a remote procedure call (RPC) to the local Netlogon service. The Locator DsGetDcName application programming interface (API) call is implemented by the Netlogon service.

The client collects the information that is needed to select a domain controller and passes the information to the Netlogon service by using the DsGetDcName call.

The Netlogon service on the client uses the collected information to look up a domain controller for the specified domain in one of two ways:

For a DNS name, Netlogon queries DNS by using the IP/DNS-compatible Locator—that is, DsGetDcName calls the DnsQuery call to read the Service Resource (SRV) records and «A» records from DNS after it appends the domain name to the appropriate string that specifies the SRV records.

A workstation that is logging on to a Windows-based domain queries DNS for SRV records in the general form:

Active Directory servers offer the Lightweight Directory Access Protocol (LDAP) service over the TCP protocol. Therefore, clients find an LDAP server by querying DNS for a record of the form:

For a NetBIOS name, Netlogon performs domain controller discovery by using the Microsoft Windows NT version 4.0-compatible Locator (that is, by using the transport-specific mechanism (for example, WINS).

In Windows NT 4.0 and earlier, «discovery» is a process for locating a domain controller for authentication in either the primary domain or a trusted domain.

The Netlogon service sends a datagram to the computers that registered the name. For NetBIOS domain names, the datagram is implemented as a mailslot message. For DNS domain names, the datagram is implemented as an LDAP User Datagram Protocol (UDP) search. (UDP is the connectionless datagram transport protocol that is part of the TCP/IP protocol suite. TCP is a connection-oriented transport protocol.)

Each available domain controller responds to the datagram to indicate that it is currently operational and returns the information to DsGetDcName.

UDP allows a program on one computer to send a datagram to a program on another computer. UDP includes a protocol port number, which allows the sender to distinguish among multiple destinations (programs) on the remote computer.

• Each available domain controller responds to the datagram to indicate that it is currently operational and returns the information to DsGetDcName.
• The Netlogon service caches the domain controller information so that subsequent requests need not repeat the discovery process. Caching this information encourages consistent use of the same domain controller and a consistent view of Active Directory.

When a client logs on or joins the network, it must be able to locate a domain controller. The client sends a DNS Lookup query to DNS to find domain controllers, preferably in the client’s own subnet. Therefore, clients find a domain controller by querying DNS for a record of the form:

After the client locates a domain controller, it establishes communication by using LDAP to gain access to Active Directory. As part of that negotiation, the domain controller identifies which site the client is in based on the IP subnet of that client. If the client is communicating with a domain controller that is not in the closest (most optimal) site, the domain controller returns the name of the client’s site. If the client has already tried to find domain controllers in that site (for example, when the client sends a DNS Lookup query to DNS to find domain controllers in the client’s subnet), the client uses the domain controller that is not optimal. Otherwise, the client performs a site-specific DNS lookup again with the new optimal site name. The domain controller uses some of the directory service information for identifying sites and subnets.

After the client locates a domain controller, the domain controller entry is cached. If the domain controller is not in the optimal site, the client flushes the cache after fifteen minutes and discards the cache entry. It then attempts to find an optimal domain controller in the same site as the client.

After the client has established a communications path to the domain controller, it can establish the logon and authentication credentials and, if necessary for Windows-based computers, set up a secure channel. The client then is ready to perform normal queries and search for information against the directory.

The client establishes an LDAP connection to a domain controller to log on. The logon process uses Security Accounts Manager. Because the communications path uses the LDAP interface and the client is authenticated by a domain controller, the client account is verified and passed through Security Accounts Manager to the directory service agent, then to the database layer, and finally to the database in the Extensible Storage engine (ESE).

Troubleshooting the Domain Locator Process

To troubleshoot the domain locator process:

Check Event Viewer on both the client and the server. The event logs may contain error messages indicating that there is a problem. To view Event Viewer, click Start, point to Programs, point to Administrative Tools, and then click Event Viewer. Check the System log on both the client and the server. Also, check the Directory Service logs on the server and DNS logs on the DNS server.

Check the IP configuration by using the ipconfig /all command at a command prompt.

Use the Ping utility to verify network connectivity and name resolution. Ping both the IP address and the server name. You may also want to ping the domain name.

Use the Netdiag tool to determine whether networking components are working correctly. To send detailed output to a text file, use the following command:

netdiag /v >test.txt
Review the log file, looking for problems, and investigate any implicated components. This file also contains other network configuration details.

To fix minor problems, use the Netdiag tool with the following syntax: netdiag /fix .

Use the nltest /dsgetdc:domainname command to verify that a domain controller can be located for a specific domain.

Use the NSLookup tool to verify that DNS entries are correctly registered in DNS. Verify that the server host records and GUID SRV records can be resolved.

For example, to verify record registration, use the following commands:
nslookup servername. childofrootdomain. rootdomain.com
nslookup guid._msdcs. rootdomain.com

If either of these commands does not succeed, use one of the following methods to reregister records with DNS:

• To force host record registration, type ipconfig /registerdns.
• To force domain controller service registration, stop and start the Netlogon service.

To detect domain controller problems, run the DCdiag utility from a command prompt. The utility runs a number of tests to verify that a domain controller is running correctly. Use this command to send the results to a text file: dcdiag /v >dcdiag.txt

Use the Ldp.exe tool to connect and bind to the domain controller to verify appropriate LDAP connectivity.

If you suspect that a particular domain controller has problems, it may be helpful to turn on Netlogon debug logging. Use the NLTest utility by typing this command: nltest /dbflag:0x2000ffff . The information is then logged in the Debug folder in the Netlogon.log file.

If you still have not isolated the problem, use Network Monitor to monitor network traffic between the client and the domain controller.

References

For more information, see the Windows Resource Kit, Chapter 10, «Active Directory Diagnostic, Troubleshooting, and Recovery.»

Network Controller: программно-определяемые сети в Windows Server 2016. Часть 1: возможности и службы

В прошлом году мы рассказывали о Storage Spaces Direct — программно-определяемом хранилище в Windows Server 2016. Сегодня поговорим еще об одной новинке Microsoft, на этот раз из области программно-определяемых сетей (SDN). Network Controller — это служба управления сетевой инфраструктурой в Windows Server 2016.

Откуда пошли виртуальные сети?

VLAN. Первые виртуальные сети появились в 1998 году. Это были локальные виртуальные сети VLAN, работающие по протоколу IEEE 802.1Q. Технология позволяет разделять одну L2-сеть на множество логических L2-сетей. Но VLAN имеет ограничение, которое оказалось существенным с ростом количества сетей: максимальное количество соединений на одной L2-сети — 4096. Для его преодоления производители начали разрабатывать новые протоколы с большей масштабируемостью, например: IEEE 802.1ad и IEEE 802.1ah. Мы не будем останавливаться на них подробно и пойдем дальше.

VXLAN, STT и NVGRE. В 2011 году компании VMware, Arista и Cisco выпускают протокол VXLAN, позволяющий создавать до 16 миллионов логических L2-сегментов в одной сети. Параллельно с ними Microsoft создает протокол NVGRE похожей спецификации, который начинает развиваться в Windows Server 2012. Компания Nicira предлагает протокол STT. Вопрос с ограниченной масштабируемостью решен, можно создавать сколь угодно много сетей. С ростом сетей инфраструктура становится сложной в управлении, и появляется необходимость централизованной консоли для настройки виртуального и физического оборудования. Так возникает концепция программно-определяемых сетей (SDN) с централизованным управлением сетевой инфраструктурой.

SDN. Подход к управлению сетью при помощи унифицированных программных средств. Одной их первых технологию SDN представила компания Nicira. После покупки Nicira компания VMware создает продукт VMware NSX, используя протокол VXLAN.

В 2013 году Microsoft предлагает свою версию программно-определяемой сети в редакции Windows Server 2012R2 на базе протокола NVGRE. У протокола NVGRE было несколько недостатков:

• управление виртуальными сетями в Windows Server 2012R2 осуществлялось только через Virtual Machine Manager (VMM). Он был точкой хранения всех конфигураций виртуальной инфраструктуры и единой точкой отказа.
• производители оборудования в качестве основного протокола использовали VXLAN, и лишь немногие внедрили поддержку NVGRE.

В редакции Windows Server 2016 компания Microsoft представила новую реализацию программно-определяемых сетей уже на базе протокола VXLAN – Network Controller (NC). Доступна данная служба только в редакции Windows Server 2016 Datacenter. Давайте рассмотрим особенности Network Controller.

Windows Server 2016: Network Controller

Network Controller — единая точка управления и мониторинга для всех физических и виртуальных сетей домeна. С помощью него настраивается IP-подсети, VLAN, маршрутизаторы и межсетевые экраны. NС хранит информацию о топологии сети, балансирует трафик и задает правила NAT.

Глоссарий

• Virtual Network Management — служба управления виртуализованными сетями.
• Software Load Balancer Management — служба балансировки трафика и правил NAT.
• Firewall Management — служба настройки межсетевых экранов и листов контроля доступа к ВМ.
• RAS Gateway Management — служба организации VPN-туннелей.
• iDNS — служба создания виртуальных DNS-серверов.

Сети:

• Backend Network (provider addresses, PA) — сеть с провайдерскими адресами. Здесь создаются виртуальные туннели и проходит трафик.
• Management Network — сеть управления, через нее проходит трафик между компонентами SDN.
• VM network (customer addresses, CA) — виртуализованная сеть, к которой подключены виртуальные машины.
• Transit Network — транзитная сеть. По ней идет обмен трафиком между BGP и SLB Multiplexer/Gateway. По транзитной сети публикуются маршруты на BGP.

Службы на хосте:

• Azure VFP Switch Extension — расширение свитча Hyper-V. Добавляет виртуальному свитчу функционал L3-коммутатора. Включает в себя distributed load balancer(DLB) и Distributed firewall (DFW).
• Distributed load balancer — балансировщик трафика.
• Distributed firewall — межсетевой экран, отвечает за выполнение правил доступа к ВМ.
• Distributed router (vSwitch) — виртуальный маршрутизатор.
• NC Host Agent — получает от NC информацию о виртуальных сетях и правилах Firewall.
• SLB Host Agent — получает от NC правила балансировки.

Служебные виртуальные машины:

• SLB multiplexer (MUX) — виртуальные машины Windows Server с ролью Software Load Balancing. На них содержится информация о правилах балансировки трафика. MUX публикуют маршруты на BGP и обрабатывают входящие пакеты.
• Gateway — виртуальный шлюз.

В целом принцип архитектуры Network Controller такой: узлы контроллера размещаются на отдельных ВМ, а службы маршрутизации, балансировки трафика и межсетевого экрана — на серверах виртуализации.

Архитектура Network Controller.

Network Controller создан на базе программного коммутатора Open vSwitch. Этот коммутатор также используется в программно-определяемых сетях VMWare NSX и OpenStack Neutron. Он поддерживает протокол управления OVSDB (Open vSwitch Database), отвечающий за обмен информацией между сетевым оборудованием.

Разберем, как работает Network Controller. Серверы, виртуальные машины, виртуальные коммутаторы гипервизоров регистрируются в NC. После регистрации и настройки серверы устанавливают соединение с Network Controller и получают от него всю необходимую информацию о сетях виртуальных машин, правилах балансировки и VPN-туннелях.

Виртуальные сети на хостах подключены к виртуальному коммутатору Hyper-V с расширением Azure VFP Switch Extension. Через него происходит управление виртуальными портами, к которым подключены ВМ:

• включение и отключение портов;
• управление полосой пропускания в обе стороны;
• назначение приоритетов пакетам по классам (COS);
• назначение целей: ведение статистики и управление ACL на портах виртуального коммутатора.

Службы Network Controller

Разберем подробно, какие службы входят в Network Controller и чем они управляют.

Virtual Network Management. Это служба создания виртуальных сетей и управления ими. Она управляет виртуальными коммутаторами Hyper-V и виртуальными сетевыми адаптерами на виртуальных машинах. Virtual Network Management содержит настройки виртуальной сети, которые применяются другими службами Network Controller.

Firewall Management. Эта служба упрощает организацию межсетевого экранирования: не нужно настраивать межсетевые экраны на каждой ВМ вручную и запоминать конфигурации. Network Controller хранит все настройки Access Control Lists (ACL) для виртуальных машин и сетей. Distributed Firewall на хостах запрашивает у него информацию и применяет правила к нужным сетям и виртуальным машинам. Настройка на стороне виртуальных машин не требуется.

Ниже схема принципа работы межсетевого экранирования в Network Controller. На ней Northbound – интерфейс, через который производится управление Network Controller с использованием REST API. Southbound служит для связи с сетевыми устройствами, SLB-мультиплексорами, шлюзами и серверами, для сетевого обнаружения и других служб. Шлюзы определяют, для какой виртуальной сети требуется построить туннели. Затем они пересылают пришедшие пакеты по туннелю на серверы с виртуальными машинами, подключенными к нужной виртуальной сети.

Так устроена служба межсетевого экранирования в Network Controller.

Software Load Balancer Management. Служба работает на уровне виртуализованных сетей и балансирует трафик на уровне L4. Балансировка трафика происходит с помощью служебных виртуальных машин SLB Multiplexer (MUX) и BGP-маршрутизаторов. На один NC можно сделать 8 MUX. От Network Controller MUX получают правила маршрутизации. Мультиплексоры анонсируют маршруты /32 для каждого VIP через BGP-маршрутизаторы.

1. На BGP-маршрутизатор приходит пакет для определенного виртуального IP-адреса.
2. BGP-маршрутизатор проверяет, какой у пакета следующий узел. В данном случае это MUX.
3. По таблицам правил балансировки, полученным от Network Controller, MUX определяет назначение пакета: виртуализованную сеть, хост и виртуальную машину.
4. Далее MUX формирует VXLAN пакет и отправляет его хосту в сеть Backend.
5. Хост принимает пакет и передает это виртуальному коммутатору (vSwitch), который определяет виртуальную машину для получения пакета.
6. Пакет декапсулируется, анализируется и отправляется виртуальной машине.
7. Виртуальная машина обрабатывает пакет. Адрес отправителя не изменяется после прохождения пакета через MUX. Поэтому виртуальная машина не видит за ним MUX балансировщика и считывает, что пакет пришел напрямую из интернета. Такая балансировка называется прозрачной (transparent load balancing).
8. ВМ посылает ответ.
9. Виртуальный коммутатор на хосте определяет, что это ответ на пакет, пришедший с балансировщика, и отправляет его обратно в Интернет. Причем не по той же цепочке, а переписывает адрес отправителя на IP балансировщика и отправляет его сразу в Интернет. Данный подход называется Direct Server Return (DSR). Это значительно ускоряет процесс обработки пакетов.

Балансировка трафика в Network Controller.

В Windows Server 2016 правила NAT теперь также задаются через Software Load Balancer Management. Network Controller знает, для какой сети организован NAT. MUX содержит информацию о хостах и виртуальных машинах, подключенных к сети, для которой организуется NAT.
NAT в Network Controller реализован путем балансировки трафика для группы из одного хоста. На данный момент поддерживается балансировка только TCP- и UDP-трафика.

RAS Gateway Manager. Эта служба создания VPN-туннелей для связи облачной инфраструктуры с физической. В Network Controller можно строить VPN любым удобным способом:

• через IPsec, который теперь работает и с IKEv1, и с IKEv2;
• создавать SSTP-туннели;
• создавать GRE-туннели.

Конечной точкой туннеля выступает виртуальный шлюз Gateway. Он организует туннель, инкапсулирует трафик в VXLAN-пакеты и пересылается его хостам.

Служба создания VPN-туннелей RAG Gateway Management.

iDNS: Internal DNS. Служба позволяет создавать виртуальные DNS-сервера. На данный момент существует как реализация концепции и поддерживает работу только с одной DNS-зоной, что неудобно для клиентов. Мультитенантный режим будет добавлен в следующей редакции Windows Server 2016.

Рассмотрим, как работает служба iDNS. Организуется DNS-зона, в которой будут создаваться клиентские зоны. Настраивается Network Controller: указывается обслуживаемая DNS-зона и вышестоящие DNS-серверы, которые будут обрабатывать запросы, приходящие от клиентов.
После настройки iDNS Network Controller распространяет информацию по хостам. Служба iDNS proxy на хостах обрабатывает DNS-запросы от клиентов. Работает это так:

1. Клиент посылает запрос на разрешение имени.
2. iDNS-proxy смотрит, обслуживает ли он запросы, исходящие из данной виртуальной сети. Это определяется по первичному DNS-суффиксу у сетевого адаптера. Он должен совпадать с зоной, обслуживаемой iDNS. Если iDNS-proxy обслуживает запросы из этой сети, то отправляет запрос вышестоящему DNS-серверу.
3. DNS-сервер проверяет, относится ли запрос к внутренним зонам. Если клиент пытается разрешить внутреннее имя, то DNS-сервер его обрабатывает. Если нет – отправляет запрос дальше.

Принцип работы службы iDNS в Network Controller.

Есть виртуальная сеть, для которой доступна служба iDNS. При подключении виртуальных машин к этой сети, в корневой зоне DNS, указанной при настройке, будет создана зона с именем, совпадающим с ID виртуальной сети. В этой зоне будут создаваться А-записи для виртуальных машин.

А-записи виртуальных машин в службе iDNS.

Все, о чем мы подробно рассказали выше, — это службы Network Controller, которые вошли в официальный релиз Windows Server 2016. Нам также удалось протестировать службы, вошедшие в Technical Preview, но изъятые из релиза. Одна из таких служб — Canary Network Diagnostics для мониторинга производительности сети, сбора статистики по работе физического и виртуального сетевого оборудования и обнаружения ошибок. Дополнения должны войти в релиз Windows Server 2016R2, и о них мы поговорим в будущем.

В следующей части мы расскажем, как развернуть Network Controller и о некоторых интересных «подводных камнях», которые мы обнаружили в ходе тестирования.