Making PFSENSE as DNS for Active Directory

edanpedragosa

This setup won't break anything!

The Active Directory still has DNS working on itself. I don't recommend uninstalling the DNS role from the AD, it can be left as ease.

What I just did is to allow PFSENSE to get the DNS role for the rest of the clients in our network. You can even set the AD as secondary DNS assigned by DHCP just in case PFSENSE is rebooting for maintenance.

The only advantage with this setup is, the AD no longer need to forward internet requests from clients as the main DNS is the PFSENSE gateway.

I just scoured the internet for people wanting this and found a lot so I think I'm just sharing this to help someone.

It is your choice to go this route and I opted to do it this way for now. If something's not right again, I can easily point the client to the AD as it's primary DNS again, via dhcp.

Have a nice day!

johnpoz

So what exactly is the advantage of pfsense forwarding or looking from roots vs your AD?? You do understand you could just have your AD forward to pfsense for the internet traffic.. Which is 1 click and done vs all this nonsense..

Sorry but this sort of suggestion with the vast majority of audience here is not going to help anyone, just confuse them and most likely have them break a working setup to try and get it working. Unless you CLEARLY understand what your doing, and understand DNS and even more how AD uses dns I would not suggest you have anything but your AD do dns and dhcp for your AD network.

People that might actually have reason to break dns away from their AD wouldn't need this forum for help ;)

Where is your over ride for the actual domain for when your clients might want to look up just say a normal box in your AD or Server in you AD from its fqdn? I see your AD sort of records.. But when I ask pfsense for just A record of server.mydomain.tld?

Oh I see this
"also add your-adhostname.your.domain to point to the assigned ip"

But what if I have more than 1 server.. So now need to edit that every single time I add a server.. What about say 100 client boxes? Are you going to enable dynamic registration?

if you going to point point people - you really need to point out all the aspects of what your suggesting.. Just saying!!

Derelict

Can't you just run BIND (or any other capable dns server) and slave the zone from the windows DNS server? Let billyg handle all the zone updates and just serve up a copy?

edanpedragosa

It may be different in your scenario but I always notice that when I point my client to the AD for DNS, when the internet goes down, some of the clients need to flush their dns to reconnect to some sites. The AD is forwarding the request to the PFSENSE gateway fine after flushing the DNS.

Here's what's happening in my case before:

CLIENT –-> AD ---> PFSENSE GATEWAY

if for some reasons the internet gets cut in the PFSENSE GATEWAY, the CLIENT needs to flush the DNS to resolve again properly.

My setting now is:

CLIENT ---> PFSENSE

\ |
AD

and is now working fine as expected.

Sorry if it causes some confusion for some but this works for me.

Just sharing...

johnpoz

Well what are the ttls on the stuff that not requesting? What is in your clients cache? What is our neg cache setting? By default 300 seconds I do believe.. Do you understand what a neg cache is?

eNORm

Hi,

I've been running this setup for a month now. It worked nicely, but when I needed to join a computer to the domain it would not work. I had to manualy change the dns-server on the computer that I wanted to join to point to AD-DNS. Did not help that AD-DNS was the secondary DNS-server that the pfsens dhcp-server gave out.

Is there something missing form the advance settings in pfsense unbound dns resolver?


server:
local-data: "_ldap._tcp.oslo.expology.no. 600 IN SRV 0 100 389 elektron.oslo.expology.no."
local-data: "_ldap._tcp.Default-First-Site-Name._sites.oslo.expology.no. 600 IN SRV 0 100 389 elektron.oslo.expology.no."
local-data: "_ldap._tcp.pdc._msdcs.oslo.expology.no. 600 IN SRV 0 100 389 elektron.oslo.expology.no."
local-data: "_ldap._tcp.gc._msdcs.oslo.expology.no. 600 IN SRV 0 100 3268 elektron.oslo.expology.no."
local-data: "_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.oslo.expology.no. 600 IN SRV 0 100 3268 elektron.oslo.expology.no."
local-data: "_ldap._tcp.f8f5a2da-93c9-414a-9347-426c5b294d2f.domains._msdcs.oslo.expology.no. 600 IN SRV 0 100 389 elektron.oslo.expology.no."
local-data: "177ea4ed-fe67-4a10-bd07-b021feeae604._msdcs.oslo.expology.no. 600 IN CNAME elektron.oslo.expology.no."
local-data: "_kerberos._tcp.dc._msdcs.oslo.expology.no. 600 IN SRV 0 100 88 elektron.oslo.expology.no."
local-data: "_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.oslo.expology.no. 600 IN SRV 0 100 88 elektron.oslo.expology.no."
local-data: "_ldap._tcp.dc._msdcs.oslo.expology.no. 600 IN SRV 0 100 389 elektron.oslo.expology.no."
local-data: "_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.oslo.expology.no. 600 IN SRV 0 100 389 elektron.oslo.expology.no."
local-data: "_kerberos._tcp.oslo.expology.no. 600 IN SRV 0 100 88 elektron.oslo.expology.no."
local-data: "_kerberos._tcp.Default-First-Site-Name._sites.oslo.expology.no. 600 IN SRV 0 100 88 elektron.oslo.expology.no."
local-data: "_gc._tcp.oslo.expology.no. 600 IN SRV 0 100 3268 elektron.oslo.expology.no."
local-data: "_gc._tcp.Default-First-Site-Name._sites.oslo.expology.no. 600 IN SRV 0 100 3268 elektron.oslo.expology.no."
local-data: "_kerberos._udp.oslo.expology.no. 600 IN SRV 0 100 88 elektron.oslo.expology.no."
local-data: "_kpasswd._tcp.oslo.expology.no. 600 IN SRV 0 100 464 elektron.oslo.expology.no."
local-data: "_kpasswd._udp.oslo.expology.no. 600 IN SRV 0 100 464 elektron.oslo.expology.no."
local-data: "_ldap._tcp.DomainDnsZones.oslo.expology.no. 600 IN SRV 0 100 389 elektron.oslo.expology.no."
local-data: "_ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.oslo.expology.no. 600 IN SRV 0 100 389 elektron.oslo.expology.no."
local-data: "_ldap._tcp.ForestDnsZones.oslo.expology.no. 600 IN SRV 0 100 389 elektron.oslo.expology.no."
local-data: "_ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.oslo.expology.no. 600 IN SRV 0 100 389 elektron.oslo.expology.no."
local-data: "oslo.expology.no. 600 IN A 192.168.123.1"
local-data: "oslo.expology.no. 600 IN A 192.168.123.2"
local-data: "DomainDnsZones.oslo.expology.no. 600 IN A 192.168.123.1"
local-data: "DomainDnsZones.oslo.expology.no. 600 IN A 192.168.123.2"
local-data: "ForestDnsZones.oslo.expology.no. 600 IN A 192.168.123.1"
local-data: "ForestDnsZones.oslo.expology.no. 600 IN A 192.168.123.2"
local-data: "gc._msdcs.oslo.expology.no. 600 IN A 192.168.123.1"
local-data: "gc._msdcs.oslo.expology.no. 600 IN A 192.168.123.2"

-eNORm-

johnpoz

Why would you do this??? Point your clients to your AD server!! If you want to use something other than MS AD for your dns - then use something like bind. Unbound is not really meant to be a authoritative server for any domain. Nor does it do any sort of zone transfers, etc.. etc..

It is not the correct choice to run active directory dns..

"Unbound is a validating, recursive, and caching DNS resolver"

Do you see authoritative listed there??

jahonix

People first have to fully understand the adjectives you listed before putting them into use. That's probably what most users lack.
I heard rumors that it's more than resolving a host name to an IP address. :o

gjaltemba

I would like to give this a try but my setup uses AD DHCP to register the leases into AD-DNS.

In this scenario, how does the AD-DNS get populated?

johnpoz

it DOESN'T there is NO POINT to this at ALL - NONE!! You have a freaking AD running with DC.. Run DNS on it - point your members to it.. There is ZERO benefit to trying to do with with a non authoritative caching resolver like unbound..

coachmark2

Agreed. Let AD do DNS. Seriously. There is no reason to have anything else doing DNS for your domain. AD relies HEAVILY on DNS to the point where it ceases to function without it. Adding computers to your domain, anything using netdom, any MMCs you use to manage things, and heck, even basic logons for your users! If you want to do this, you're introducing complexity where there is no reason.

The argument is slightly different for AD DHCP. That does integrate nicely with DDNS, but DDNS is not some special secret wizardry that only Microsoft can do.

jahonix

You're a bit late for the party but thanks for your contribution.

plaj

Great hackersoft !
You made my day.
I was googleing for a while for a way to authenticate AD sessions over an IPsec VPN with NAT-T, on a site without an AD DC.
Added the DNS lines in the Unbound DNS Resolver Advanced options as you described, and a Host Override for each of my DCs on their NATed IP address and it finally works !
My computers can now authenticate on a DC controller on the other side of my Ipsec tunnel…
Also tried to add a new computer to the domain, and it's working too.

Perhaps there's another way to perform that... but this way works great for me.
Why am I not fallen on it earlier ? :)
Many thanks for this sharing !