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?
As soon as the client has one good address, it's going to be able to connect, and at that point I think it reports back ALL of of its addresses. I am unaware of any way to change that behavior.
You can prevent the
NO_CLIENT_SITE ... 169
messages from being logged if you add a subnet for 169.254.0.0/16 to your sites configuration. Doesn't really matter what it points to.Or review the log a little differently. Something like:
Backslash Capital S Plus
is a regular expression that will match one or more non space characters, the client name in this case.