I honestly believe that questions like this one: Using GPO in Active Directory domain to force workstations Windows Firewall to disabled - how? existed because Windows Admins in general were taught long ago that:

"the easiest thing to do when dealing with a domain computer is to just have a GPO on the domain to disable the Windows Firewall...it will cause you much less heartache in the end." - random IT instructors/mentors from years gone by

I can also say that at MOST companies I've done side work for this has been the case, where a GPO at a minimum disabled the Windows Firewall for the domain profile and at WORST disabled it also for the public profile.

Even further, some will disable it for the servers themselves: Disable firewall for all network profiles on Windows Server 2008 R2 through GPO

A Microsoft Technet Article on the WINDOWS FIREWALL recommends you DO NOT disable the Windows Firewall:

Because Windows Firewall with Advanced Security plays an important part in helping to protect your computer from security threats, we recommend that you do not disable it unless you install another firewall from a reputable vendor that provides an equivalent level of protection.

This ServerFault question asks the real question: Is it alright to turn off firewall in a LAN using Group Policy? -- and the experts here are even mixed in their view.

And understand I'm not referring to disabling/enabling the SERVICE: How can I back up my recommendation to NOT disable the Windows Firewall service? -- so as to be clear that this is about whether or not the firewall service enables the firewall or disables it.


So I get back to the Title of this question...what can be done to properly re-enable the Windows firewall on a domain? Specifically for client workstations and their domain profile.

Before simply switching the GPO from Disabled to Enabled, what planning steps should be taken to ensure that flipping the switch doesn't cause critical client/server applications, allowable traffic, etc. to suddenly fail? Most places won't tolerate the "change it and see who calls the Helpdesk" mindset here.

Are there checklists/utilities/procedures available from Microsoft to handle such a situation? Have you been in this situation yourself and how did you deal with it?

  • 3
    windows server by default disables the firewall. (i suppose assuming it will always be behind a good corporate firewall). domain workstations typically have them disabled because the windows firewall is a PITA to work with and maintain. Every application needs some special ports, the DC vomits up data on a bunch of ports, etc etc. There's so much stuff going on, that enabling the windows firewall usually leads to a lot of time spent "fixing" it so normal apps work. Then as soon as you walk away, you'll have to come back and fix it again.
    – SnakeDoc
    Jan 23, 2014 at 19:59
  • 10
    @SnakeDoc windows server by default disables the firewall This is not true. domain workstations typically have them disabled because the windows firewall is a PITA to work with and maintain also, not true- have you looked at the GPOs available for managing it in the last 6 years? It's not 2003 anymore the DC vomits up data on a bunch of ports, etc etc. There's so much stuff going on, that enabling the windows firewall usually leads to a lot of time spent "fixing" it so normal apps work When you install AD DS, the exceptions needed for all of that are pre-configured on the DCs
    – MDMarra
    Jan 24, 2014 at 14:35
  • 12
    I have literally no idea how that comment is +3 right now when every single point made in it is factually incorrect. This feel like /r/sysadmin right now.
    – MDMarra
    Jan 24, 2014 at 14:36
  • 3
    @MDMarra: I was thinking exactly the same thing re: the "+3" on that comment. I wish I could downvote that comment. (I don't feel like flagging is the right thing to do but I'm really tempted...) Jan 24, 2014 at 16:13

4 Answers 4


What can be done to properly re-enable the Windows firewall on a domain?

Well, the short answer is that it's going to be a lot of work if you decide to forge ahead, and for the record, I'm not sure I would.

In the general case, client firewalls don't provide much security in a corporate network (which typically has hardware firewalls and controls this type of thing at the edge), and malware authors these days are smart enough to use port 80 for their traffic, because virtually no one blocks that port, so you get a lot of effort putting something in place to provided limited security benefit.

Having said that, the long answer is:

  1. Inventory applications and their connectivity needs as best you can.
    • If you can safely enable the Windows Firewall with an allow all rule and set logging, this will be a treasure trove of data for determining what apps you have that need firewall exculsions.
    • If you can't collect logging data non-intrusively, you'll have to make do with a simple inventory, or do your logging on users who can handle disruption and intrusive IT activity (like yourself and other techs, for example).
  2. Think about your troubleshooting needs.
    • There are things that probably won't come up in a software audit that you need to think about. For example:
      • You might want to allow ICMP (or ICMP from approved address spaces) to make troubleshooting and IP address management not horrible.
      • Likewise, exclusions for any remote management applications you guys use.
      • You'll also probably want to set firewall logging by policy
  3. Create a baseline GPO and deploy it to a test group, or multiple test groups.
    • While you can't just do it and let the helpdesk sort it out for everyone, management is going to be a lot more open to piloting the changes with a select group of hand-picked employees, especially if they think there's a valid security concern.
    • Pick your test group carefully. It might be wise to use IT folk first, then widen the group to include people from other departments.
    • Obviously, monitor your test group and stay in constant communication with them to quickly resolve issues you didn't catch the first time around.
  4. Roll out the change slowly, and in stages.
    • Once you've tested it to your satisfaction, you should still exercise caution, and not just push it out to the whole domain at once. Roll it out to smaller groups, which you'll have to define according to your organization's structure and needs.
  5. Make sure you have something in place to handle future changes.
    • Just making it work for what you have in your environment now isn't going to be enough, because you will end up with new applications on your domain, and you'll have to make sure the firewall policy is updated to accommodate them, or someone above you will decide the firewall is more trouble than it's worth and will have the policy removed, eliminating and the work you've put into it so far.

Edit: I would just like to state that there is nothing inherently wrong with Windows Firewall. It is a perfectly acceptable part of an overall defense-in-depth strategy. The fact of the matter is, most shops are too incompetent or too lazy to be bothered to figure out what firewall rules are needed for the applications that they run, and so they just force it off ubiquitously.

If Windows Firewall, for instance, prevents your domain controllers from doing their job, it's because you didn't know what ports Active Directory needed before you turned the firewall on, or because you configured the policy incorrectly.

That's the bottom line of the matter.

First, communicate with your project managers, your bosses, your stake holders, your change advisory cabinet, whatever the process is in your company, and inform them all that you will be undergoing a gradual remediation involving the Windows Firewall in order to increase the overall security posture of your environment.

Make sure that they understand that there are risks. Yes, of course we'll do everything we can, all the planning that we can, to ensure that there will be no interruptions, but don't make any promises. Trying to whip an old domain into shape is hard work.

Next, you have to inventory applications that are in use in your environment and what ports they require. Depending on the environment, this can be very difficult. But it has to be done. Monitoring agents? SCCM agents? Antivirus agents? The list goes on.

Develop a Windows Firewall GPO that includes custom rules for your enterprise applications. You may require multiple policies with different scopes that apply to different servers. For instance, a separate policy that applies only to web servers for ports 80, 443, etc.

The built-in Windows Firewall policies will be very helpful to you, as they are perfectly scoped to accommodate most common Windows activities. These built in rules are better because they don't just open or close a port to the entire system - they're scoped to very specific process and protocol activity taking place on the machine, etc. But they don't cover your custom applications, so add those rules to the policies as auxiliary ACEs.

Roll out in a test environment first if possible, and when rolling out to production, do so in limited chunks first. Don't just plop the GPO on the entire domain on your first go.

That last statement is probably the best piece of advice that I can give you - roll out your changes in very small, controlled scopes.

  • 1
    Next comment not relating to this answer gets 24 hours in the box. >=[
    – Chris S
    Jan 24, 2014 at 16:37
  • 6
    @ChrisS So, what are you up to this weekend?
    – MDMarra
    Jan 24, 2014 at 16:43

Okay, I'm about to suggest something that may or may not get you in trouble, but it's what I use when I'm turning on the firewall.

Nmap. (Any port scanner would do.) I fear I don't trust documentation of what ports are in use. I want to see for myself.

Background: I'm from an academic environment where student laptops rubbed elbows with our servers (Ugh!). When I started using nmap on my own servers, we had no IDS, either, so I could nmap at will and no one would notice. Then they implemented IDS and I'd get emails forwarded to me that basically said, "NETWORK PORT SCAN ATTACK ON YOUR SERVER FROM YOUR WORKSTATION!!!!!" and I'd reply and say, "Yep, that's me." Heh. After awhile they developed a sense of humor about it. ;)

I also used nmap on workstations, for example, to look for conficker. Nmap would likely turn up the AV management ports, any other management software ports, etc. (Desktop will be very crabby if you break their management software.) It might also turn up unauthorized software, depending on your environment.

Anyway. Some environments will freak out about nmap and some won't even notice. I generally only nmap my own servers, or workstations for a specific purpose, which helps. But yes, you probably want to clear that you're going to be running a port scan with anyone who might freak out on you.

Then, you know. What Ryan Ries said. Management/change management/group policy/etc.

  • Any good network should freak out at network port scans. Especially if they are internal.
    – SnakeDoc
    Jan 23, 2014 at 20:24
  • Well, sure, it looks ominous, which is why I disclaimed. That said, you'd be surprised at who'd let you do it/wouldn't notice. Jan 23, 2014 at 20:36
  • lol, which is why I said "good". Although "good" has different meaning depending on which side of the network you are sitting at... hehe
    – SnakeDoc
    Jan 23, 2014 at 20:41
  • 3
    If done with care, this is sound advice, if not a must-have in planning for firewall deployments. nmap can be targeted and throttled. If you are already responsible for or otherwise involved in network operations, you simply communicate to all stakeholders that you are surveying the network, and no one needs to "freak out". Jan 23, 2014 at 23:38
  • 3
    (shouting over cube walls) "Hey, Tim?" "Yeah?" "I'm about to upset the IDS again." "(laugh) Okay." Jan 24, 2014 at 13:05

I don't believe there's any utilities available from Microsoft on this, but if I were to use Windows Firewall on our domain (it's enabled where I work) I would ensure the following:

  1. Exceptions exist for all remote administration tools (WMI, etc etc)
  2. Create IP range exceptions on domain workstations to allow administrative servers (such as SCCM/SCOM, if you have them) to allow all traffic.
  3. Allow end users to add exceptions to the domain profile only for software in case you miss some things (and you will).

Servers are a bit of a different beast. I currently have the firewall disabled for our servers because enabling it caused many problems even with exceptions in place. You basically have to apply a blanket "skeleton" policy for all servers (disallowing unsafe ports, for example) then going to each server and individually customizing settings. Because of this, I can see the reason a lot of IT folk just disable the firewall. Your perimeter firewall should protect these machines enough without their own firewalls. However, sometimes it's worth the effort to individually configure servers for high-security environments.

As a side note, Windows Firewall also governs use of IPsec, so if that's used you need the firewall anyway.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.