For those of you who missed the webinar I did yesterday on "Securing Desktops with Group Policy", you can register to view the on-demand version here. If you did attend, thanks for listening! We had a good crowd and lots of good questions!
Under the category of "you learn something new every day" I was playing around with some stuff yesterday and finally got a chance to confirm something that someone had posted on the ActiveDir mailing list. We all know about how some policies tattoo the registry. Security policies are typically one of those areas where, if you remove a setting, the systems applying that policy are not necessarily reverted back to the prior setting because, well, the system doesn't necessarily know what the prior setting is. You can imagine that this may be a good idea if by accident you remove a policy that hardens your servers and suddenly the servers decide to revert back to a less restrictive setting.
However, one area that does not follow this model is Restricted Group policy, as I came to discover yesterday. Namely, if I use the part of Restricted Groups called "Members of this Group" to exclusively control the membershp of a particular group, and then remove that policy, the next time that policy is refreshed on the target computer that holds the group, that group's membership is reverted to the list of members that were there before the policy applies. This is probably documented somewhere but its one of those myriad of things that I hadn't looked at specifically before and so I thought it was interesting.
Not content with stopping there, I tried one more test. I tried applying the restricted groups policy to an AD group and then removed it to see what the effect would be. Now, I've blogged in the past about why using Restricted Groups polciy against AD groups was a bad idea, but this experiment was all about knowledge, so I figured I could break my rules a bit. And what was the result? Well if you guessed that after removing the Restricted Groups policy on an AD group, that the membership would be reverted back to the old one as well, you'd be wrong! Its not too surprising really. First off, I imagine that on computer-based groups, that the membership is probably stored in the local SAM and remains there even when Restricted Groups policy is in place. Its cached, if you will. There is no place for AD to cache group memberships and I'm sure doing so would cause all kinds of issues.
Tag:
This topic came up on a newsgroup the other day, prompting me to look around a bit. Basically, MS added support for the newer WPA2 encryption protocol for wireless networks in XP, SP2. This KB article describes the Wireless Client update that you can apply to your XP systems to get them to process those WPA2 policies. But here's the catch--this update only allows these systems to process the wireless policies. It does not allow them to actually edit those policies. In fact, a search around the web reveals that the only way you can define WPA2 encryption in your wireless GPOs is to use Vista or Longhorn as your GP editing client! That's right, there is no support in GP Editor on XP, SP2 or even Server 2003, SP2 to get at those new WPA2 options. XP, I'm not surprised about. MS doesn't even expose the wireless policy node in XP without some major tweaking. I'm not sure why they didn't provide this in 2003, SP2 however, since it was released pretty recently. In any case, if you want to use WPA2 and want to control it via policy, you will have to use Vista (or Longhorn) to define those policies.
Technorati Tags
