How does Windows decide which IP address to use with AD DC communication?
I have a weird problem.
I am working on setting up "Sites and Subnets" properly, so that my AD clients connect to proper DC (instead of one on opposite side of the globe).
To do this, I started filtering logs on DC for "NO_CLIENT_SITE" error - and, while most of the client addresses I can easily locate, there are some that are... impossible.
I use solely private IP addressing in my organization, some people are allowed to use VPN (also utilizing private IPs for tunnel interface). But in the logs, there are some clients that report public IP address, or APIPA address, for example:
05/24 16:28:45 APAC: NO_CLIENT_SITE: CN070E141 169.254.87.93
This is, quite frankly, impossible - I am 100% certain that client using APIPA will not be able to connect anywhere. Similarly client using public IP address will be unable to reach DC.
The only explanation that comes to my mind is that there are multiple interfaces on the client, one of which is working fine - and facilitating communication with DC, and another one has APIPA or public IP - and this address is reported to DC.
Which brings me to main question: how can I make sure that the address provided to DC is always the address of the interface used for communication?
Or perhaps someone can provide alternative explanation?
Как только у клиента будет один хороший адрес, он сможет подключиться, и в этот момент, я думаю, он сообщает ВСЕ свои адреса. Я не знаю, как изменить это поведение.
Вы можете предотвратить регистрацию сообщений NO_CLIENT_SITE ... 169 , если вы добавите подсеть для 169.254.0.0/16 в конфигурацию вашего сайта. Неважно, на что он указывает.
Или просмотрите журнал немного по-другому. Примерно так:
get-content netlogon.log | select-string -notmatch "NO_CLIENT_SITE: \S+ 169\.254"
Обратная косая черта Capital S Plus - это регулярное выражение, которое будет соответствовать одному или нескольким непробельным символам, в данном случае имени клиента.