GPMC will be removed if you install Vista Service Pack 1 (follow up post)
September 23, 2007 7 Comments
As I discussed in a previous post, I thought that the removal of the Group Policy Management Console from Vista when installing service pack 1 was a pretty bad idea. David Overton asked if anyone cared about GPMC being pulled out of Vista with sp1, while others claim it really is a good step for a variety of reasons, and I wanted to follow up on this.
There were various articles announcing Vista sp1, including one on the official Vista team blog which managed to say lots about all the good stuff and conveniently forget some things like the removal of the very useful GPMC, which is only mentioned in the whitepaper (and later reported on by various bloggers and journalists of varying degrees of credibility).
I have to admit that reading whitepapers can sound pretty dull, particularly when they relate to something I can’t download yet. I tend to think “I’ll read it nearer the time, once I have actually downloaded <whatever> and can apply what I am reading”. On this basis it is easy for people to overlook this announcement amid the other marketing hype.
In my mind there are two key questions here:
Firstly, I know there is supposed to be a new enhanced version of GPMC available at some point, but will it be available in time for the Beta testers? Or even for the final release of sp1? This remains unanswered at the moment, and is crucial. If it is available, it lessens the impact considerably.
Secondly, why take a retrograde step to remove something which is already in there? This second question is the one which most other commentators have addressed.
Jeremy Moskowitz, MVP for Group Policy makes some valid points on a post entitled “Vista + SP1 = Gbye GPMC” in his blog (sorry but I can’t find a way to link to the specific post):
Today, the GPMC is part of Vista. That’s great. One less thing to load.
But what’s also (now) true is that if you install SP1 for Vista (not yet available) the GPMC will be uninstalled. Why?
Because this allows for something that I’ve personally advocated for. That is, when new goodies are ready to be launched in Group Policy land, let’s GET IT OUT THE DOOR. And it used to be this way. The GPMC was a simple download and simple install. When bugs were found in the GPMC, that meant it was a quick fix to jam the fixes in, and re-upload the file for the masses.
But now (today) the GPMC is part of the Longhorn and Vista operating systems. Is this good? Not really, in this one dude’s opinion. Because what if some new whiz bang feature is suddenly available? Then you’ll have to wait until MAYBE an operating system service pack, or at worst a full operating system revision until it’s updated.
Darren Mar-Elia (another GP MVP) wrote a very extensive post about the Vista sp1 release, specifically pointing out lots of errors in one of the many articles about sp1. In it he takes up the same idea as Jeremy:
Back when GPMC first shipped, out-of-band of the OS, I’m sure Microsoft heard complaints that it should be in the OS, since it became such a crucial part of managing GP for many shops. So, they went and did the most logical thing – they put it in the box in Vista.
But to do that resulted in GPMC having to become part of the behemoth that is the Operating System release cycle at MS. This has obvious limitations if you know how glacially things move within MS when it comes to OS revs. Once inside the OS, they could no longer rev the GPMC and make enhancements to it on their own schedule.
However, I can’t see that the GPMC is so tightly integrated to the operating system as to prevent an update independently of the service pack cycle. The GP processing engine, sure (although making that its own process in Vista outside of winlogon should help with any patches that are needed). But the GPMC is an application. It does nothing until invoked by the user. I realise that it can still use shared code, but does it, in fact?
Anyway, if the GPMC so woven into the fabric of the OS that it can’t be independently tested and upgraded, how are they managing to take it out so easily? Surely that is contradictory?
Other OS components installed by default have upgrades made available periodically, the most obvious being Internet Explorer and Media Player. MS have claimed for a long time that both of these are fundamental components of the OS and it would not be possible to ship Windows without them unless it was severely crippled. This has been the basis of its defence in previous anti-competitive practices (antitrust) lawsuits. Microsoft just spent three years appealing a decision by the EU courts that ruled they had to produce a version of Windows XP without Media Player (which they have subsequently done for both XP and Vista)
Darren goes on to say:
But, with GPMC installed on every desktop, any joe user with normal non-administrative rights in the domain can open GPMC and view the settings on any GPO they have read access to! Further, they can also backup all GPOs that they have read permissions on, to, say, their USB keys
Technically true, and echoed by others. However, this overlooks the fact that to run GPMC on Vista in a default configuration the user requires local admin rights on their domain account (the local admin account won’t be able to access the domain policies, only the local ones). So yes, if you have domain users with local admin rights on their machines, they could run GPMC as described and take a copy of your policies. I’ll ignore for a moment the lack of security inherent with that model (because I accept there may be users who have a second account for doing admin things occasionally via a runas or UAC).
My question is this: surely a user sophisticated and malicious enough to do what Darren suggests would also be able to take the trivial step of installing GPMC if it was not already on their machine?
If they don’t have local admin rights they could still take a copy of the files for the policies they have read access to by going directly into the sysvol share. This would then take more effort to interpret than a GPMC report but they could easily restore them into another domain (in a virtual machine, say) in the same way you would have done before GPMC.
As a counter to this, surely we should be advising people to take more care in the creation of their Group Policies? It is very easy to ignore the security filtering for most purposes if you have designed your AD to enable you to target your policy links exactly where you need them. However, it may be prudent to remove “authenticated users” from the security filter (or via the delegation tab) and add back in only those groups who actually need to receive each policy.
You could start by having a security group for all computer accounts and another for users if you are following recommended practice of keeping the two types of settings separated and only enabling one ‘half’ of the policy. This would immediately secure your computer policies against the sort of access that we are concerned with here, including via sysvol. More granular groups would be ideal, but would increase the overhead of managing things.
So, I remain to be convinced that having GPMC pre-installed actually makes anything less secure than it already is. I am also unconvinced that it needs to be removed in order for independent updates to take place, as that would imply it was very tightly integrated in the OS, which would imply it could be quite hard to take out of the codebase, which seems to me a little contradictory.
I’ll just have to live without it, or install the enhanced version as long as it is available soon enough. It just still seems illogical.