I’m restructuring a network that is routed and firewalled with pfSense, and have a goal of moving servers into their own subnet with rules that allow traffic targeting required ports. One of the servers is a domain controller, and clients need to be able to join the domain, use DNS, change passwords, etc.
The easy way to do this would be to have a rule that allows traffic on any port to the domain controller IP, with knowledge that it has its own Windows firewall running a default configuration for the installed roles and servicesl.
The more painful approach would be to add rules covering all of the ports that the various domain controller services use (LDAP, DNS, SMB, DCOM, etc) and hope that you have everything covered.
I’m curious what best practice is or what other admins currently doing.
You will need to relay things like DHCP just to get to the DC. An overlay tunnel might be a better choice, at least then the DC and clients can be on the same network.
Or move to Azure, but I would still strongly recommend having at least a read only DC on premises. It really sucks when the internet goes down, and your users can’t even log into their computers! Been there, watched my IT department struggle for two days because most things didn’t work. All because one drunk hits a pole.
typical install
How many users do you have at this location? Some of the mini-PC devices would probably run your read only DC very nicely if you only have 100 users at the location.
I have around 100 users at my site, and currently all servers are hosted here (on-prem). I’m starting a project of moving my critical servers out of this site into a data center, and am planning to connect the sites with an IPSec site-to-site tunnel.
I have the luxury of pretty much setting up things how I want them with regard to domain controllers, etc, so I’m exploring all of the possibilities.
Our usage model has changed. We recently added another 40 users at a different site, and we have added customer-facing services as well.
We recently had an incident where transmission lines feeding our substation failed during a storm and we (along with our local region) were out of power for 10 hours. The data center we are moving to has power from two different substations and a backup diesel generator. We just don’t have those facilities.
When I did this I stuck my DCs in my “server” vlan and routed clients to it from WIFI, wired, admin, staff(s), etc. I didn’t have a default allow all rule, it wasn’t hard to get all the ports that were needed.
I did not have my DC provide DHCP or DNS (except for the AD zone of course). It worked well but I did do a quick google search to see what best practices are given everybody here suggest otherwise. I’m sure you have done this as well in more detail than I just did. Anyway, looks like there are pros and cons to both approaches. I’d be curious if people here extrapolated on why this is a better approach. I can’t do the same for my setup, beyond just saying it worked for me back when I was doing it. I don’t like the idea of having my DC do everything.
Your DC is not REQUIRED to do everything, but it integrates more easily if it handles DHCP and DNS. The only real requirement is that a DNS server is present, and that AD has access to it.
My IT department runs DHCP and DNS on linux servers, but they also have to jump through a few more hoops when doing certain things. Ad in Azure and I bet it gets even more complex.
Getting the permissions to update DNS from an external DHCP is the harder part, probably easier if both DNS and DHCP are external to the AD.
My network is small, so I let my AD servers handle both, also gives load balancing and redundancy from failure. It’s also really easy to set up reservations, way easier than whatever my IT department runs on their network. Only thing that might be easier is that I read KEA now has a csv export and import for reservations, that would speed things up a lot.
I’ve gone to making reservations for all my desktops because we use a “remote” monitoring and control software for the classrooms. Lets the teacher see what students are doing, and also lets them project a student computer through the projector if there is something interesting to show the rest of the class. Called Veyon, really just a VNC system, but it has a user interface to make it easy for faculty to remember what they need to do. Reserving the desktops prevents the Veyon master from losing the desktops if an IP shifts.
This is a big no no here Tom!
It surprises me that you would encourage that as this is NOT a best practice at all as your firewall becomes blind to communication between clients and DC.
When securing a network like OP is trying to accomplish - called network segmentation and you already know that I’m sure Tom - you need a firewall rule that will allow communication over these ports:
53
TCP/UDP
DNS
88
TCP/UDP
Kerberos authentication
123
UDP
W32Time
135
TCP
RPC Endpoint Mapper
137/138 *
UDP
NetBIOS
139 *
TCP
NetBIOS
389
TCP/UDP
LDAP
445
TCP
SMB
464
TCP/UDP
Kerberos password change
636
TCP
LDAP SSL
3268/3269
TCP
LDAP Global Catalog / LDAP GC SSL
49152-65535
TCP
RPC Ephemeral Ports
And you probably need HTTP/HTTPS also for other stuff too on the DC. With that in place, you will be able to “see” who’s trying to reach the DC and block it if required.
Yea I’m going to have to agree here. If you are talking security wise, having dc’s segregated is not only ok but probably recommended (With correct firewalling rules)
Benefit of putting DCs (and Servers) on different subnets is to allow different firewall rules for DCs to Clients - DCs shouldn’t be doing anything much - but clients perhaps will - even the basics - https etc. DCs should only need access to Windows update, DNS (this maybe the router) but PCs …
I’ll echo the recommendations of segmenting DCs from the clients and pretty much everything else. There is plenty of documentation out there to do this properly and if you have issues, you can log all blocked traffic so you can figure out what other ports you might need to open.
It’s about what’s practical for your threat model, sure putting a firewall in between makes monitoring east west traffic between clients possible for the firewall but why stop there? Why not have a full allow list for each client and lock each switch port to the MAC of each connected device? Or let’s go further and not isolate all clients and use an overlay network for each one and force that as the only way for them to communicate?
How you set these up is about your risk tolerance and the threat model you are protecting against. Maybe better phrasing is it’s not “Common Practice” to segment DC controllers.
Most of the common modern threats today ARE NOT someone wandering around the network from an unknown device, it’s most often initiated by a trusted user on a trusted device clicking a phishing link. Hopefully that user is on a fully patched system, does not have admin rights, is on a system with proper logging to your SIEM solution, has some form of EDR softeware, and principles of least privilege were followed to narrow the access. Bonus if you have the time to setup and manage full application allow listing.
I will be doing some videos soon on both threat modeling and how we secure our clients.
You’re exaggerating his argument just a little. You do this a lot with the CLI, equating it to coding in assembly.
Routing DC traffic is easy security to implement & monitor.
Plus routing is more practical than your approach. Unless you have a flat network. Which is more practical than a segmented network I suppose. Otherwise you have to setup RODC in every network segment, which is not practical or secure. (not to mention the need to setup a firewall & monitoring on each DC.)
As much practical as you want it, having a flat network like your propose to “simplify” things is not how things are done today in a well managed and secured network. And those flat networks are what I fix at clients after they’ve gotten a ransomware that paralyzed their business for weeks. I can assure you they listen carefully about what are the real best practices afterward to secure their stuff.
Playing with ACLs on IP/MAC addresses is what we were doing 15+ years ago and things (aka networking and security) has evolved a lot since then because it is too easy to spoof your way out now.
Firewalls are what you use today in segmented networks to secure your landscape internally (aka segmentation to control East-West traffic). Switches, from some network vendors, are now able to isolate devices on the same VLAN and it shuts down any kind of spoofing or poisoning attacks as “listening” and “broadcasting” is not possible anymore.
And I will take back your example of the “threat within” from a trusted user when he/she clicks on a phishing or worse link (ransomware), what do you think will happen in your flat network that permit spoofing?
I know you are a pfsense avid user and reseller as a MSP, and this is probably why you do not seem aware of how things are done with modern NGFW and network equipment today. pfsense is good for periphery stuff, but for any other threats internally, it lack behind and is a reason I also remove it from clients to install more modern security equipment (true NGFW) that let you upgrade your security posture and have better visibility of what is going on the network.
If your clients need a local Domain Controller and other servers, they ought to be on their own network segment. And relying on patched system is as good until a new update comes out and you missed it. You can never rely on end devices being patched up.
