Making PFSENSE as DNS for Active Directory

[edanpedragosa]

Hi!

I just tried this again in PFSense 2.2 64-bit using the DNS Resolver (Unbound) and it worked fine now.

The AD still has the DNS functionality on its own, but all clients are now pointed to the pfsense gateway for DHCP and DNS resolution.

Here's what I did:

1. I copied the netlogon.dns file from    %systemroot%\System32\config\netlogon.dns    to my desktop for later use.

2. I Added host overrides to resolve your.domain to your assigned ip (in my case it's 172.16.0.10), also add your-adhostname.your.domain to point to the assigned ip

3. I then edited the file I copied from the Active Directory and made it look like:

server:
local-data: "_ldap._tcp.your.domain 600 IN SRV 0 100 389 your-adhostname.your.domain"
local-data: "_ldap._tcp.Default-First-Site-Name._sites.your.domain 600 IN SRV 0 100 389 your-adhostname.your.domain"
local-data: "_ldap._tcp.pdc._msdcs.your.domain 600 IN SRV 0 100 389 your-adhostname.your.domain"
local-data: "_ldap._tcp.gc._msdcs.your.domain 600 IN SRV 0 100 3268 your-adhostname.your.domain"
local-data: "_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.your.domain 600 IN SRV 0 100 3268 your-adhostname.your.domain"
local-data: "_ldap._tcp.30e36ab8-a6ac-4c64-85aa-0fbeb612a33b.domains._msdcs.your.domain 600 IN SRV 0 100 389 your-adhostname.your.domain"
local-data: "d4f866aa-a210-4c29-81a2-ebb256bdef7d._msdcs.your.domain 600 IN CNAME your-adhostname.your.domain"
local-data: "_kerberos._tcp.dc._msdcs.your.domain 600 IN SRV 0 100 88 your-adhostname.your.domain"
local-data: "_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.your.domain 600 IN SRV 0 100 88 your-adhostname.your.domain"
local-data: "_ldap._tcp.dc._msdcs.your.domain 600 IN SRV 0 100 389 your-adhostname.your.domain"
local-data: "_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.your.domain 600 IN SRV 0 100 389 your-adhostname.your.domain"
local-data: "_kerberos._tcp.your.domain 600 IN SRV 0 100 88 your-adhostname.your.domain"
local-data: "_kerberos._tcp.Default-First-Site-Name._sites.your.domain 600 IN SRV 0 100 88 your-adhostname.your.domain"
local-data: "_gc._tcp.your.domain 600 IN SRV 0 100 3268 your-adhostname.your.domain"
local-data: "_gc._tcp.Default-First-Site-Name._sites.your.domain 600 IN SRV 0 100 3268 your-adhostname.your.domain"
local-data: "_kerberos._udp.your.domain 600 IN SRV 0 100 88 your-adhostname.your.domain"
local-data: "_kpasswd._tcp.your.domain 600 IN SRV 0 100 464 your-adhostname.your.domain"
local-data: "_kpasswd._udp.your.domain 600 IN SRV 0 100 464 your-adhostname.your.domain"
local-data: "_ldap._tcp.ForestDnsZones.your.domain 600 IN SRV 0 100 389 your-adhostname.your.domain"
local-data: "_ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.your.domain 600 IN SRV 0 100 389 your-adhostname.your.domain"
local-data: "_ldap._tcp.DomainDnsZones.your.domain 600 IN SRV 0 100 389 your-adhostname.your.domain"
local-data: "_ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.your.domain 600 IN SRV 0 100 389 your-adhostname.your.domain"
local-data: "your.domain 600 IN A 172.16.0.11"
local-data: "your.domain 600 IN A 172.16.0.10"
local-data: "gc._msdcs.your.domain 600 IN A 172.16.0.11"
local-data: "gc._msdcs.your.domain 600 IN A 172.16.0.10"
local-data: "ForestDnsZones.your.domain 600 IN A 172.16.0.11"
local-data: "ForestDnsZones.your.domain 600 IN A 172.16.0.10"
local-data: "DomainDnsZones.your.domain 600 IN A 172.16.0.11"
local-data: "DomainDnsZones.your.domain 600 IN A 172.16.0.10"

4. Now, copy the code DNS Resolver | General Settings | Advanced

5. Save then verify that unbound service is running from your services dashboard

Your clients should now resolve it's AD requests from PFSENSE.

You can now take out the AD as DNS in your DHCP settings or make it as a secondary DNS.

Hope this can help someone out there!

Thank you PFSENSE Team for making unbound integrated by default.

Have a nice day all!

[ZPrime]

This is a bad bad bad bad BAD idea, in most Windows domains.  AD is extremely dependent on DNS, and trying to use something else as the main DNS server is a recipe for disaster.

Why not just use the AD server as your DHCP / DNS server, and simply set pfSense as the default gateway in there?  If you still want to use pfSense's DNS, setup an override for the internal domain that points back to the AD server(s), and then you can use pfSense/Unbound as a secondary or tertiary server.

[doktornotor]

There are some proper howtos out there for integrating Bind with AD, Google it. Manual setup is NOT the way to go.

@bradenmcg:

If you still want to use pfSense's DNS, setup an override for the internal domain that points back to the AD server(s)

^That.

[jahonix]

Dumb question:
Is it mandatory to hand out DHCP leases by AD as well or can this be handled by pfSense without confusing AD?

I'm doing it this way (with DNS pointing to DCs from DHCP server) but my AD isn't running as smooth as I'd like it to. Now I'm looking for reasons.

[KOM]

If you do Active Directory and you don't let Windows handle DNS and DHCP, you're going to have a bad time.

[jahonix]

I do DNS from AD, just not DHCP.
Why does AD need to serve DHCP leases, the relevant stuff is semi-static anyways.

[cogumel0]

@jahonix:

I do DNS from AD, just not DHCP.
Why does AD need to serve DHCP leases, the relevant stuff is semi-static anyways.

It doesn't, the only requirement that AD has is DNS and even then there are plenty of companies out there using non-MS DNS servers even on their AD servers and everything works fine. I've worked with Infoblox for example to completely replace MS DNS/DHCP/etc.

Anyway, think about it, why should DHCP have anything to do with AD? What about clients on static addresses which pretty much all servers have? Does it mean that because they didn't get an IP allocated from DHCP they can't communicate with AD properly?

AD doesn't even need to resolve the names of the clients at all, it doesn't care if they are registered in DNS because the communication is always initiated by the client.

[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 !