Active Directory DNS
-
So why are you looking for something else to do DHCP or DNS?
-
These servers are located on different area in the office but since the building is very old power keeps on flactuating and server goes down. The area where I will put the pfsense box is the most stable power supply however it cannot handle a lot of server. Thats why as much if it is possible that I can use the pfsense as DHCP and the DNS will be on the DC. Currently we mikrotik router but since it is old I will switch to pfsense. 10.10.0.6, 10.10.0.7 (DC) and 10.10.0.1 (router) are configured under DHCP -> DNS and it works well, however when I tried to configured it in PFsense the host are getting hard time to pick up ip address to the pfsense box.
-
Effing fix your power or move your DCs. Christ.
-
^ yeah that would be my suggestion as well.. WTF???
-
I use the same configuration because I have multiple independent domain names (forests) on my network.
You should be able to configure the DHCP to work in this way, although it's designed by default to point the WAN toward your gateway.
In your scenario, I would use the following:
DNS Entries
10.10.0.6
10.10.0.7Gateway
10.10.0.1I found I also needed to add the DNS entries to System -> General for pfSense to resolve machine names.
 -
I'll be the odd one out. This is how I've always done it and it's never been an issue. Keep in mind pfSense becomes a single point of failure.
Under Services > DNS Forwarder or Services > DNS Resolver (depending on what version of pfSense was originally installed, unless you've manually switched to DNS Resolver) create a domain override:
-
And still no actual answer to what point is using pfsense when you have AD that requires DNS and has it right there running anyway.. Why would you point member clients of AD to anything other than your AD dns and dhcp, one good reason??
Having multiple forests sure and the F is not a valid reason.. Or do you think it is? Please explain..
"Keep in mind pfSense becomes a single point of failure."
So sure you create a domain override - but for what Freaking reason? As you state you no create failure point..
-
I'm new to pfSense 2.3 and as with some others I like to setup DHCP and DNS on my routing appliances and not Windows Server. Joako is right on the money. By doing what he suggests it works great. No AD or Group Policy errors on workstations authenticating to the DC/AD Server. Works for me.
-
And still no actual answer to what point is using pfsense when you have AD that requires DNS and has it right there running anyway.. Why would you point member clients of AD to anything other than your AD dns and dhcp, one good reason??
Having multiple forests sure and the F is not a valid reason.. Or do you think it is? Please explain..
"Keep in mind pfSense becomes a single point of failure."
So sure you create a domain override - but for what Freaking reason? As you state you no create failure point..
I thought in order to use DNSBL in pfBlocker you HAD to run DNS through pfSense?
Jason
-
"I thought in order to use DNSBL in pfBlocker you HAD to run DNS through pfSense?"
What does that have to do with your AD dns??? You point your clients to your AD dns.. You then have your AD dns ask pfsense that is running unbound and using pfblocker For stuff it is not authoritative for, simple forward setup in AD dns..
-
"I thought in order to use DNSBL in pfBlocker you HAD to run DNS through pfSense?"
What does that have to do with your AD dns??? You point your clients to your AD dns.. You then have your AD dns ask pfsense that is running unbound and using pfblocker For stuff it is not authoritative for, simple forward setup in AD dns..
I see your point, and I agree your technically correct. I chose to do DHCP in pfSense instead of my DCs because I have a lot of other non-AD subnets and choose not to DHCP relay. So if I'm going to use DHCP for the non-Windows subnets in pfSense, I might as well do it all there so I don't have to manage DHCP 2 different places - even though I admit that makes the AD subnet DHCP configuration less robust/reliable.
Jason
-
"I might as well do it all there so I don't have to manage DHCP 2 different places"
Well depends on how many clients you have in AD and nonAD.. I personally would let AD clients get dhcp from AD.. This is how MS designed it ;)
But where dhcp comes from has little to do with dns.. Be it you point your nonAD to pfsense for dns would depend on if they need to resolve lots of stuff in AD dns..
Your clearly running 2 dns setups now.. Not sure what you have against dhcp relay? This would allow all dns to be in AD for all your clients, and since they would be getting dhcp from there it would be a cleaner setup.
If you want pfsense itself to resolve your AD stuff then sure it needs to know where to go ask for dns via a domain override.
-
And still no actual answer to what point is using pfsense when you have AD that requires DNS and has it right there running anyway.. Why would you point member clients of AD to anything other than your AD dns and dhcp, one good reason??
Having multiple forests sure and the F is not a valid reason.. Or do you think it is? Please explain..
"Keep in mind pfSense becomes a single point of failure."
So sure you create a domain override - but for what Freaking reason? As you state you no create failure point..
If I use Windows DHCP then I have to buy a CAL for each iPhone an employee connects to the wifi.
-
"If I use Windows DHCP then I have to buy a CAL for each iPhone an employee connects to the wifi."
Says freaking who??? You sure and the F do not need a cal to handout dhcp lease… There is nothing in MS that checks for this..
Does your user not have a cal already?? Your doing device cal licensing??
If your doing user based cals the user could have 100 devices using server resources.. If your using device licensing then sure legally this would be a requirement but who does device licensing this never makes sense..
Also I have never seen a company actually pay that close attention to MS licensing from hell.. If your going to take it to the letter of the MS requirement then pretty much every single business on the planet that has a windows machine would fail ;)
-
"If I use Windows DHCP then I have to buy a CAL for each iPhone an employee connects to the wifi."
Says freaking who??? You sure and the F do not need a cal to handout dhcp lease… There is nothing in MS that checks for this..
Does your user not have a cal already?? Your doing device cal licensing??
If your doing user based cals the user could have 100 devices using server resources.. If your using device licensing then sure legally this would be a requirement but who does device licensing this never makes sense..
Also I have never seen a company actually pay that close attention to MS licensing from hell.. If your going to take it to the letter of the MS requirement then pretty much every single business on the planet that has a windows machine would fail ;)
Johnpoz is right on the head with this one. I can cleary tell, [insert sarcasm font here] he's got just a little bit of Windows licensing/DHCP/DNS experience [end sarcasm font]. ;)
But Johnpoz, I'm a Windows guy too and a hold out for using Domain overrides in my routing devices and letting my routers handle both DHCP and DNS. I've seen quirky problems happen with Windows DHCP and some devices especially VOIP phones that won't release their DHCP lease and we get IP conflicts (particularly with LG VOIP phones). I don't see these problems with using Linux/Unix based DHCP Servers. So I've got my reasons. But some reasons I have may be unfounded. So, I'd like to display my ignorance on the matter and have you set me straight. Keep in mind, I'll probably be setting up a Hyper-V AD lab this weekend to test the things you state.
Here's one of my scenarios:
What happens when your DC handling DHCP and DNS goes down? And no, with the VMs I run I do NOT have a backup DC. I just have really good backups that I should be able to quickly mount on a Loaner Hyper-V Server if I need to. But for simplicity sake, let's just say I don't have a VM I can quickly restore. Let's just entertain me here. When devices pull DHCP leases from Windows Server and a client machine (or VOIP phone) is rebooted it won't pull a DHCP lease because obviously the Windows DCHP Service is down. So it's bad enough they can't get to any LAN resources (printers, fileservers, etc) but even worse they can't get out to the Internet in this cloud based world we now live in. I'm a consultant and have countless issues with poorly executed DC environments that I have to take over and I simply trust a Linux/Unix type device like DD-WRT or pfSense to be a better more stable DHCP/DNS device.
Johnpoz, Why is my thinking wrong here? Why is your scenario for always running DHCP/DNS on the DC better? Looking forward to your post.
-
Dude your talking different things.. Your saying you don't want to run your dns/dhcp services on your DC because your DC might go down?
IF your DC goes down your going to have lots of issues, how you going to access any resources anyway? How you going to auth? Be it your machine has an IP or not? Even with an override to your AD dns, if your DC is down your not going to be able to resolve anything in your AD anyway. Be it pfsense is up or not.
If your worried about loss of services on single machine be it physical or virtual failing then you need to plan for that, and have more than 1.. You could have multiple machines providing dns and dhcp..
Your never going to find anywhere other than the smallest of smbs where there is only 1 DC in the setup. And you don't have to be DC to provide dhcp and dns for AD, any other windows server can provide these services to the AD.. it doesn't have to be DC.
A dhcp server going down is not always that big of an issue.. Your clients should maintain their leases until they expire.. Now if you have really short leases your not going to have a lot of time to recover, but lets say you have 2 or 4 day lease.. That gives you plenty of time to recover or bring up a new dhcp server. Just don't reboot stuff if your dhcp server is down ;)
As to dns.. AD kinds of needs that to function.. So having it in only 1 place is a BAD idea out of the gate.. Be it an override in pfsense pointing to your domain or not.. If the AD dns goes down your going to have issues. If you need still resolve public stuff in a scenario when your AD is down, its very simple to point a client to a different DNS that can resolve public, be it pfsense, be it googledns, opendns, level 3 at 4.2.2.2 etc.. To allow you to have internet access.
I really am not following your logic that you don't want to point your clients to your AD dns/dhcp because it might go down as any sort of reasoning to point to pfsense with an override to your AD dns.. Your AD dns could still go down.. Which is going to be a bigger issue than if your clients can not get to facebook.com
-
Johnpoz,
Thanks man for replying back. Really appreciate you taking the time. :)
Well guess what? Those “smallest of smbs where there is only 1 DC in the setup” that’s what I do…for a living. Been in business over 15+ years and the smallest clients I support may be a 5 person shop. The largest may be 50. So, you’re talking to me when you make that statement.
What you’ve done is tell me, I’m doing things that are the best for the environments that I manage. And I appreciate that.
I have several clients that use Cloud based apps for billing, client tracking, even printing where they are hitting Cloud based services sometimes through VPNs. So it ain’t about facebook.com at all. If they don’t have Internet they’re screwed. Doesn’t matter much that they can authenticate to that DC. If they can’t get out to the net, we’re done. If one of my routers goes down using DD-WRT it would take me about 20-25 minutes to have them back up and running. Flash the firmware on a new router, load up their last config file, plug it in, we’re back in business. How do I know that? Because I've tested it and had to implement in before. If a Windows DHCP controller goes down, best case scenario, I’ve got a VM backup, no way I can have them back up in running in 25 minutes. Why? Cause it always takes longer than you think.
If clients can’t authenticate to AD for Group Policy what’s gonna happen? Gonna take them about 2 minutes to get past that “Welcome” screen because the client is going to look for the AD controller and never find it. However, since I have something else handling my DHCP and DNS they’ll easily be able to get out to the net. Which is EXACTLY what I want to happen.
Lastly, got a kick out of your “Just don't reboot stuff if your dhcp server is down”. ;D Yeah, what do the end users do, “Internet’s not working, Ahhh, I’ll just reboot cause that always fixes everything. DOH!!”
I really do appreciate your response though. I was afraid I wasn’t thinking of something. You came down pretty hard on that dude that originally posted. Granted, he did have two DCs and I get your point! I’ve been burned once when a single DC went down running the whole show. Let’s just say I significantly changed my disaster recovery for all clients once that happened. Live and learn man.
-
I've been on this boat at some point…
On these cases, I have configured both pfSense and the DC as primary and secondary DNS servers on every workstation, respectively. Then forward the AD zone from pfSense to the DC, and also forward everything else from the DC to pfSense.
It's not pretty, but this way if pfSense goes down, you still have AD, and if the DC goes down, you still have internet. And both DNS resolve everything when everything works fine.
-
Thanks for jumping in on this georgeman! Different strokes for different folks I guess. So I assume that you are going around to each workstation individually and setting those Static DNS entries. Seems like that could take a lot of time and heaven forbid your DC IP address or pfsense box changes IPs. Could be a mess. For that matter, may as well give everyone static IPs and ditch the DHCP server altogether. Ah, anyone remember those days?
I can't tell you the number of times I've had to take over networks and not get things to resolve. Sometimes I just say "Screw It". I'll just set the static DNS on the NIC to the DC and move forward knowing I'll have to fix it later. Or in some cases simply hacking the hosts file.
I think joako has the best solution here as pfSense does the job of telling all the clients when and where to go for DNS requests. Plus, it's super easy to do (unlike my alternative DD-WRT). Just my $.02.
-
I mean, that's how I handled the DNS part a couple of times, regardless whether the DNS servers are assigned statically on every PC or through DHCP. Still, I always let pfSense handle DHCP
