How I fixed my Active Directory problems

Many people would say that running Active Directory at home is overkill, and normally I’d agree with you. However, I reinstall Windows frequently and also have a laptop that I’d like to have the same group policies as my desktop. It also allows for all of the drives on my NAS to be automatically mapped instead of having to add them all manually, which is a huge timesaver. However, there were two nagging problems with the setup. Firstly, all traffic on my Pi-hole instance was showing as coming from my NAS on domain joined computers. Secondly, I had to manually set the DNS to 10.10.10.5. This is a problem on laptops where you’re on the go and may not always have a connection to AD.

So, for some more context, here is how my home network used to be setup. I had Pi-hole setup on 10.10.10.2 and my NAS was on 10.10.10.5. All devices on the network go through 10.10.10.2. However, domain joined computers need to go through 10.10.10.5 so that AD can work properly. The solution seems obvious, have the domain joined computers go through 10.10.10.5 and then simply forward the request to 10.10.10.2 if it isn’t AD specific. However, this introduces our main problem. By doing this, all requests from all domain joined computers appear to be coming from 10.10.10.5. This makes it impossible to tell apart if a query is coming from my laptop or desktop for example.

A visual representation of how the network was setup for normal computers and domain joined computers

You might think, just reverse it then. Have every device on the network go through 10.10.10.2 and then forward it to 10.10.10.5. However, this introduces another point of failure for the entire network. If my NAS were to go down, no devices would be able to use the internet. With the current setup, a normal device on the network did not need to rely on my NAS. Only domain joined computers needed to rely on the NAS, but this would be much less of an issue.

So how did I fix it? AdGuard Home. One of the features AdGuard Home has is that it lets you specify custom upstream DNS for each client. This immediately solved my second problem. Now, every device was able to use the default 10.10.10.2 and I did not have to manually tell it on the computer to use 10.10.10.5. For the domain joined computers, I set the upstream DNS to 10.10.10.5, but every other device would be using a public DNS server.

For extra safety though, I setup a custom rule on AdGuard so that only requests for the AD domain would be forwarded to 10.10.10.5. Every other URL would simply use a public DNS server just like the rest of the clients. This means that, even if the NAS goes down, domain joined computers will still be able to access almost every URL on the internet. And for a regular device on the network, it had no effect at all since it has no idea about 10.10.10.5 in the first place.

A visual representation of the new setup for normal computers and domain joined computers

Here’s the AdGuard rules I use for the domain joined computers with contoso.net being your own domain.

[/*.contoso.net/]10.10.10.5
https://dns10.quad9.net/dns-query
https://dns.google/dns-query
https://dns.cloudflare.com/dns-query

This may seem fairly obvious, but the obvious solution to me was to try to setup DHCP on the Synology NAS. Using AdGuard is a much cleaner solution as it solves both problems and has no impact on the regular devices on the network. In fact, it actually benefits domain joined computers because manual DNS settings no longer have to be set.

When domain joining a new computer, it still needs to be manually setup in AdGuard Home. However, this is easier than doing it on the actual computer itself. It also is a potential security benefit so that random computers on the network can’t even attempt to join AD in the first place.


Posted

in

,

by