On the second Tuesday of the month Microsoft introduces updates for it's products. As a system administrator you might keep distance from it the first week because of all the bad things that could happen to your systems. When you have changed permissions on the WinNT and Windows directories of your servers and workstations this should be a sure concern to you. I'll explain why you might find yourself or any predecessor changing permissions and of course how to solve this situation.
1. The Principle of least administrative privilege
When you administrator large environment you’re probably familiar with the Principle of Least Privilege, which states that a user should be given only the privileges necessary to accomplish his or her task. I personally consider it to be a rule of thumb. When you apply this principle you'll end up with Least-priviledged User Accounts, als known by its abbreviation "LUA" and referenced to as "Limited User Accounts" by your users, because that's exactly what you're doing to them: limiting them to do their daily chores: nothing more, nothing less. A more official definition of a Least-priviledged User Account is an user account that can't change settings that affect other user accounts or the system.
Aaron Margosis, a Senior Consultant with Microsoft Consulting Services, is considered to be the authority on Least-priviledged User Accounts (Mark Russinovich refers to him as "the God of non-admin") and the 'Problems of Privilege' that come with it. He named some of these problems "LUA Bugs". Other problems that systems administrators encounter are not considered to be "LUA Bugs". In this post Aaron Margosis distinctively explains what a LUA Bug is. (and what it's not)
In the two posts that Aaron Margosis wrote on fixing LUA bugs the first one makes the most sense by offering several troubleshooting steps like addressing the developer to fix it, using the Application Compatibility Toolkit (ACT) and several little Windows tips and tricks like copying parts of the registry and "inifilemapping". The second post however offers troubleshooting steps in the field of loosening Access Control Lists (ACL's) and running applications with elevated privileges. Although Aaron Margosis points out not to loosen Access Control Lists (ACL's) on system wide folders my experience tells me many systems administrators actually changed the Access Control list of the Windows directory and this is exactly where the core of the problem resides…
2. Converted Partitions
There are also some other occurances where you might be confronted with the same problems that are described in the KnowledgeBase Articles referenced above. One of these is when you installed Windows 2000 on a FAT or FAT32 partition and converted it to NTFS after installation. It is covered in KnowledgeBase article 237399:
When you install Windows 2000 to an NTFS file system partition, part of the set up process is to apply default security settings to the system files and folders located on the boot partition.
If you initially installed Windows 2000 to a FAT or FAT32 partition, and then later used the Convert.exe utility to convert the partition to NTFS, default security settings are not applied.
This might even pose a bigger risk for your Windows servers and possibly some Windows desktops within your organization. (but when your servers are at risk who gives a **** about some desktops…)
In the last couple of years we were confronted with Hotfixes that caused problems on systems where the default Access Control List (ACL) in (parts of) the Windows directory, also known as %windir% was changed. KnowledgeBase article 909444 is one of the most recent knowledgebase articles that shows incompatibilities with a Microsoft hotfix. It also links to knowledgebase article 823659 that I consider to be the authority on incompatibilities when you modify security settings and user right assignments.
Resetting default permissions
Now that I've showed you the problems that might arise when working with changed NTFS permissions on the Windows directories and Aaron Margosis showed you three ways of circumventing loosening these permissions I guess you think you're in a deep hole filled with a certain brown substance. Well, you're not! There's a simple way of resetting the permissions on all of your directories with a simple command. The steps to make your specific problems disappear can also be scripted or facilitated by Group Policy Objects (GPO's) so there's an easy way to test and solve these problems within a few hours for your whole enterprise environment.
KnowledgeBase Article 313222 shows you how to reset the default permissions on a Microsoft Windows XP system easily and with a granularity that lets you easily make your pick of permissions to reset, including registry keys, NTFS permissions, services and user rights assignment. For Microsoft Windows 2000 you can read KnowledgeBase Article 266118.
Since Aaron Margosis pioneered the field of Least-privileged User Accounts and non-Admin issues systems administrators have a wide range of troubleshooting steps to avoid errors on one side and changing permissions on registry keys and NTFS permissions on the other side. It's a thin line, but at least there's a fast way to undo any damage done by previous troubleshooting actions.
Aaron Margosis' Weblog
How to reset security settings back to the defaults in Windows XP (KB313222)
How to restore the default NTFS permissions for Windows 2000 (KB266118)
Default NTFS Permissions in Windows 2000 (KB244600)