DSNBL with Active Directory
-
Hi, hope you're having a great day
How do i setup the DNSBL in a network that works totaly around the Active Directory Domain Services?
Can i foward all trafic from both domain controllers to the PfSense? Doing this there's a chance of broke anything related to the AD?
For example, if i forward the trafic to PfSense, can i resolve the names, accounts and the applications that are hosted on my Domain Controller?
-
@luquinhasdainfra said in DSNBL with Active Directory:
Hi, hope you're having a great day
How do i setup the DNSBL in a network that works totaly around the Active Directory Domain Services?
Can i foward all trafic from both domain controllers to the PfSense? Doing this there's a chance of broke anything related to the AD?
For example, if i forward the trafic to PfSense, can i resolve the names, accounts and the applications that are hosted on my Domain Controller?
In an AD environment you should let all clients recieve DHCP/DNS from and on the domain controllers (so dynamic registrations and service records works as normal.
Change the AD DNS servers from their default root-hint mode, to forwarding mode, and have them both ask your pfBlocker augmented Unbound DNS server on pfSense (That runs in resolver mode).
That also allows you to let guest clients (non-AD) get the DNS server on pfSense instead of the AD DNS servers. Thus they cannot resolve anything internal - and if you want them to resolve an internal name or two, create a host-override for those names in pfSenses DNS Resolver. -
I have DNS running on the AD, both of these systems can resolve any missing queries outside as they have always done. Then on my DHCP system I give each client the Netgate as the DNS. (my DHCP is not running on the NG either, historical reasons and no real reason to move)
on the NG - DNS Resolver is set for, Network Interfaces LAN, Outgoing Network Interfaces LAN, it it doesn't go directly outside for anything.
Under System -> General Setup - DNS Servers are set to the two internal AD DNS servers.
Client DNS request goes, NG (DNSBL via pfBlockerNG, gets dumped if needed by DNSBL) -> internal DNS, usually hits from cache, but can still reach out if they can't resolve the address)
works like a charm - blazing fast DNS response times.
Does that help?
-
@luquinhasdainfra said in DSNBL with Active Directory:
Can i foward all trafic from both domain controllers to the PfSense? Doing this there's a chance of broke anything related to the AD?
For example, if i forward the trafic to PfSense, can i resolve the names, accounts and the applications that are hosted on my Domain Controller?Agree with both of the above. If you needed pfSense to resolve the internal domain you could always set a Domain Override to point the internal domain and/or your subnet .in-addr.arpa domain to AD DNS.
We set up all our clients AD DNS to forward to pfSense and/or Quad9.
Do note, Windows PCs cannot use any DNS that doesn't resolve the internal domain name. Windows does not use DNS in order, it uses the last known good DNS server first.
-
Thank you for the tip, i'm going to test it by forwarding the AD DNS servers to PfSense,
Best whises
-
Understood,
So, the request first goes to PfSense and them they are forwarded to the AD DNS servers?
Looks pretty reliable, going to test it,
-
@luquinhasdainfra You can do it either way (pfSense forward local domain to AD, or AD forward to pfSense). I would say probably the latter is more straightforward, plus if pfSense is down then internal DNS still works.
-
@steveits said in DSNBL with Active Directory:
plus if pfSense is down
bite your tongue -- pfSense never goes down - LOL
if it ever did that would be the bigger problem, at least for us.
JR -
@jrey :) can be solved/prevented either way...backup AD/DNS, pfSense in HA...
-
@luquinhasdainfra
I'd say for the sake of an AD network, I'd actually go with the first route with AD clients pointing DHCP/DNS to the domain controllers and them fowarding to pfSense instead of pointing all clients to pfSense itself. Reason is explained by @keyser@keyser said in DSNBL with Active Directory:
That also allows you to let guest clients (non-AD) get the DNS server on pfSense instead of the AD DNS servers. Thus they cannot resolve anything internal - and if you want them to resolve an internal name or two, create a host-override for those names in pfSenses DNS Resolver.
That is a valid concern, as it gives you the ability based on the DHCP response to hand out DNS server(s) with or without internal information to your clients. A guest network, IoT things or even a few WiFi setups don't need internal information about your network, your server/client naming, your internal domain etc. So just hand them pfSense as DNS withtout having a domain override/forwarding there, you get the DNS resolving without leaking internal information.
Cheers
-
This is one of the main reasons I finally decided to setup vlans. Using Windows server DHCP, you can set the IOT and guest network to use PFSense for DNS, and hand your AD DNS server info to the domain joined clients. Then just forward to PFSense DNS from the domain DNS servers so that you get the benefit of PFBlocker and any other security settings you enabled in the router. You can even create NAT redirects to redirect the hard coded IOT DNS back to PFSense DNS, and not open port 53 to the internet. You can even use public DNS server lists with PFBlocker to block IOT from using whatever DNS they are hard coded to use even when using DOH (my kindles are hard coded for 8.8.8.8 which would skip PFBlocker if used). It took me a bit to put the pieces together and get it working but I can't stand these crap devices doing whatever they want.
