Windows Firewall + PowerShell + Group Policy = Wonderful

Last year I did some work around putting together a group policy for the UWWI servers that restricts who can access them to the current definition of the UW Network.

Group policy allows you to define configuration settings once and apply them broadly. And what better application than the Windows Firewall rules that are so crazily detailed and finicky? Who likes to set local Windows Firewall rules? Yuck.

James Morris tipped me off that there were some PowerShell cmdlets that would help me. And he was absolutely right … there was one which really saved a massive amount of time in defining the rules that went in the GPO.

Here are some breadcrumbs that should allow you to put something similar together yourself.

The UW-IT NOC has this document defining the UW Networks:

Note that includes both IPv4 and IPv6. And Windows Firewall handles both. 🙂

So then you do something like this:

PS C:\Windows\system32> $IPs = @(“″,”″,”″,”″,”″,”″,”″,”″,”″,”″,”2607:4000::/32″,”fd73:a9bd:11bb::/48”)

Then you create your group policy object. Let’s say I created mine in the Dogfood domain, with a name of “uwit: UWWI firewall test”.

You then do something like this:

PS C:\Windows\system32> set-netfirewallrule -DisplayName “Windows Remote Management – Compatibility Mode (HTTP-In)” -RemoteAddress $IPs -PolicyStore “\uwit: uwwi firewall test”

This adds a firewall rule to the GPO for WinRm that restricts traffic to the IP networks in the $IPs variable.

If you pull up the GPO in the GUI, you’ll now see that firewall rule in the GPO. Nice! 🙂

The next trick is figuring out which rules you need to add, and that really depends on the box and how tight you want to configure it. On thing to consider: you might go with a course grain approach, restricting TCP & UDP & ICMP traffic, and skip the fine grain approach of delineating all the individual services.

Want to read up on the Windows Firewall with Advanced Security? See If you do dig into it and go the more fine grain route, make sure you understand the Windows Service Hardening type of firewall rules. These are rules defined by the product team (or 3rd party apps/services) and can’t be removed easily. In other words, they are on every box that has the Windows Firewall service installed, and **regardless of whether you have the Windows Firewall on or off**, they exist and are active. And yes, you read that right–there are firewall rules which are active even with Windows Firewall disabled. These
Windows Service Hardening rules are designed to only allow the services to accept traffic from the network sources the service is designed for.

Presentation decks for NTLMv1/Turning off Legacy Stuff and Azure AD

I’ve given a couple presentations over the last couple months. Here are links to the slide decks and webinar:

Turning Off NTLMv1 or How to Approach Turning off  Legacy Technology given at Microsoft Redmond campus for Windows HiEd 2014 Conference. Or see the archived Webinar (requires installation of Adobe Connect add-in) given for the Internet2 IAM Online forum.

Office 365 Identity aka Azure Active Directory given at Puget Sound SharePoint Users Group.

Turning off NTLMv1

Some of you may be stuck in the uncomfortable position I was in (until recently) of having an AD environment that still permits NTLMv1. If so, you probably have done a little research to figure out what might break if you turned it off, but having been there, I know that you have found very little online that is detailed or even much in the way of resources that would allow you to move forward.


To be clear, having any NTLM turned on is not recommended–see, where Microsoft says ““applications are generally advised not to use NTLM.” But many of us can’t completely turn off NTLMv2 quite yet (mostly because of Microsoft applications that don’t follow Microsoft’s own advice), but probably can get rid of NTLMv1, which is more heinous (than NTLMv2) in terms of the risk it poses. If you need any additional motivation, take a peek at, with its NTLMv1 rainbow tables available for any individual to use to crack a NTLMv1 hash in milliseconds.


I’ve got two resources to share with folks who want to turn off NTLMv1 but aren’t sure how to proceed.


First, I’ve got a document that lists known problems and potential workarounds. See for that.


There’s a bit of background reading noted at the top of that document which is recommended for understanding the architecture and relevant settings. The NTLM referrals bit noted there is particularly important to understand, and it has a significant consequences on where NTLMv1 events are logged (hint: only at the initial server the client contacts), as well as where the LMCompatibilityLevel settings actually matter (hint: for the “server” aspect, turning off NTLMv1 on a domain joined computer doesn’t mean anything except to the local user accounts of that computer). If you don’t understand that bit, you will make the mistake I made in the summer of 2013 when I turned off NTLMv1 on our domain controllers because there were no NTLMv1 events on our domain controllers, and then had to roll that change back when lots of people still dependent on NTLMv1 couldn’t access various services.


Also let me highlight a couple significant potential gotchas within the known problems list:

  • Non-Windows browsers don’t support NTLMv2. To my knowledge, there is only a single exception to this statement: Safari on MacOS with an obscure Samba setting. You can find more details in the document above, as well as various workarounds we came up with. This led me to realize that for IIS, Integrated Windows Authentication is a dead end (b/c very few folks actually get Kerberos working on those non-Windows clients) that I should actively discourage within my organization.
  • IAS/RRAS/MS-CHAPv2 & the native MacOS VPN client. The native MacOS VPN client doesn’t support NTLMv2. Only known workaround is a 3rd party VPN client.


If anyone has additional known problems/workarounds they’d like to contribute to this document, please let me know & I’ll add them.


Second, we have a PowerShell script we created to parse the security event log for the important bits from NTLMv1 events. It can be used remotely. See for that. We leveraged this extensively to identify misconfigured clients which we then contacted.


I hope this info is helpful—I know I would have really appreciated this kind of info back when I first started down this road. 🙂

Microsoft’s JIT approach revealed

Below you’ll find a link to a TechEd Europe session earlier this week.


I just finished watching the 2nd half, which is much more interesting than the 1st half (which presents all the problems we all know about). Microsoft has finally revealed their planned just in time administration (JIT) approach in broad strokes.


Some of the major points:

  • Next version of Windows will have capability where group members can have a TTL that AD automatically respects (AD has had TTL capability for a long time, but this is the first time I think anything has used it)
  • There is a new forest trust type for admin access. Very little said about this
  • There is a concept of a bastion forest. The purpose here is twofold:

a) isolate your elevated account risk

b) have a known place of goodness (i.e. you may already have bad actors in your forest that you don’t know about)

  • There is some newly extended capability leveraging sidHistory such that you can now stick the SID of well-known groups on objects (this is key to allowing the bastion forest accounts/groups to “own” objects in your existing forest)
  • Next version of Windows will know that when it goes to issue a logon token, the TTL of that token should be constrained by the smallest TTL of your security group memberships
  • There are capabilities in MIM.vNext (was FIM) that permit workflow behaviors such that pre-defined “candidates” can self-elevate themselves subject to approval workflows you design and TTLs you specify
  • A key point: you don’t need to move any of your existing environment to Windows 10 to take advantage of this new goodness. You deploy a new Windows 10 forest, setup the elements required to support the stronger access management scenario you need (in that new forest), map them to your existing groups, and empty those existing groups. At that point, no one has access by default, and everyone has to use the JIT mechanism.


I’ve gotten a couple “huh?” sorts of inquiries related to my parenthetical comment above about how AD has had TTL capability for a long time. Mostly about how Microsoft might get something like this to work and whether this TTL stuff happens in AD or MIM. My educated guess is the TTL stuff happens in AD, not MIM.

Here are a few breadcrumbs to allow you to get a handle on this yourself. 

entry-TTL attribute

dynamicObject (auxiliary) object class

If you aren’t really into schema, I can’t say I blame you, but you are missing out on understanding a bunch of details. An auxiliary class is one that can be added to an existing directory object. In contrast, a structural class is the class that must be specified at the time of creation of the object. The structural class determines a bunch of things e.g. what defaultSecurityDescriptor the object has. An auxiliary class is typically used to “add” capability without the permanent overhead of modifying an existing structural class. Another important detail here is that you can “layer” (or inherit) structural classes on top of each other—the most common example of that is the computer object class layered on top of the user object class (and you can layer many times, e.g. the gMSA class is layered on top of the computer class).

Now, with those breadcrumbs, the only real mystery to me here is how Microsoft managed to take these existing mechanisms and get them to apply the “automatic deletion” not at the object level as is currently the limit of this existing AD mechanism, but at the attribute level.

In other words, today, you could add a dynamicObject class to any group object and set an entryTtl value. When that TTL expired, the group would be deleted. And there are likely use cases for that scenario (automated clean-up of the group sprawl if the owners don’t “re-authorize” keeping the group around), but that’s different than the use case here where one value of a multivalued attribute (member) on a group object gets deleted when a TTL reaches zero.

So put another way, assuming my educated guess that AD is performing this new group member TTL capability, then there’s some real neat stuff here under the covers. And that neat stuff may be highly relevant to a bunch of other use cases. I’d have to reflect on this, but I can imagine there are use cases where you’d want some other attribute’s value to expire after a period of time.



markwahl (@markwahl)
10/29/14 3:42   AMTechEd Europe: Privileged Access Management for Active   Directory (Channel 9 recording)…   #tee14