07.22.10
Posted in General Stuff, Microsoft-Related, Security Policy, Security-related at 10:02 pm by Administrator
Some of you may have seen a twitter post I did a while back letting folks know about the Security Compliance Manager, which is a tool from Microsoft that lets you manage, edit, report, search and export security templates and baselines. This tool is pretty cool, but it also has a hidden gem in it. When you install the SCM, you will notice a folder within its program group called “LocalGPO”, which contains a package called localgpo.msi. When you run that MSI it installs some files within a folder on your hard drive, and one of those files is a script called localgpo.wsf. What this script can do is pretty cool. It can do 3 things against your local GPO that I really like:
- It can backup your local GPO to a GPMC formatted backup. Which means you could backup a local GPO and then use GPMC to import it into a domain-based GPO.
- It can take a GPMC backup of GP settings and import them into a local GPO on a machine.
- It can restore a local GPO to its default state.
These are three great features for managing the local GPO. Let’s take a look at how to use each. For backing up the local GPO, the syntax is simple:
From a command shell, I simply type:
cscript LocalGPO.wsf /path:c:\gpbackups /export
Where c:\gpbackups is a path to where I want to store my backup and /export tells the script to export my local GPO settings.
Now if I want to import a GPMC backup into my local GPO, the syntax is even easier. I simply provide the path to the GUID-Named folder that GPMC creates under the backup directory when you back up a GPO, like this:
cscript LocalGPO.wsf /path:C:\gpbackups\{42ADD8FE-EDF6-479B-92C6-557343D8D091}
And, to restore a local GPO to its default config:
cscript LocalGPO.wsf /restore
Pretty easy to use and this script seems to support every OS from XP to Win7. A couple of caveats however. In looking at the script, Microsoft is only supporting Administrative Templates and Security Policy within these backup and restore operations (understandable given the ship vehicle for this thing). So if you have other policies like Scripts or IE Maintenance within your local GPO, it won’t be captured. Also, the script does not appear to deal with the multiple local GPOs feature supported in Win Vista and above. So if you have per-user local GPOs, they are not captured–only the default local GPO.
That being said the script does provide some good basic functionality as well as a good instructional document on how to capture and reset security settings from the local GPO (which are essentially stored in the local SAM rather than on the file system as in domain-based GPOs).
Hope this proves useful to you!
Darren
Permalink
05.30.08
Posted in Security Policy at 2:43 pm by Administrator
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!
Permalink
10.05.07
Posted in Security Policy at 9:46 am by Administrator
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:
Group Policy, Restricted Groups, Security Policy
Permalink
06.29.07
Posted in Security Policy at 8:32 pm by Administrator
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
WPA2,Group Policy,Wireless Policy
Permalink
