- 1 VMware Takes the Wraps Off vRealize Automation and vRealize Business
- 2 Microsoft Previews Hyper-V Containers for Windows Server 2016
- 3 Mirantis Led FUEL Project Gets Installed Under OpenStack Big Tent
- 4 Red Hat Enterprise Linux 7.2 Adds Security, DR Features
- 5 Docker Reaches Across Universes at Dockercon EU
Default Security Settings in Windows 2000 May Cause Legacy Applications to Fail.
by John Loomes
The default access permissions in Windows 2000 have changed significantly from those we're all used to in NT4. The operating system has been made much more secure, and whilst this is obviously a good thing, it does present a few potential problems in drawing that fine line between giving users a level of access sufficient to meet their needs, and having a mangeable, stable system with the resulting lower Total Cost of Ownership. In a previous article I spoke about how Windows File Protection System stops even administrator from installing unauthorised system files. This article addresses the default file and registry permissions in Windows 2000, how they might affect applications and what you can do to get around them.The default access permissions in Windows 2000 have changed significantly from those we're all used to in NT4. The operating system has been made much more secure, and whilst this is obviously a good thing, it does present a few potential problems...
NT 4 Security
In Windows NT4, by default everyone could write to all directories, and to a large part of the registry, meaning that your average user, had sufficient rights over the system to install all but the most awkward of applications. Some security was there, preventing users from changing systems settings etc, but as a whole, the user was free to make roam around the system, making potentially damaging changes. Ive seen various attempts at preventing this, by modifying the default acl's in a standard build, such that users are prevented from accessing various areas, such as the Winnt\System32 directory and so on. Getting this security right, whilst allowing applications to function properly, is a bit of a black art, as there is always some application that simply must write a temporary file to some directory or other, that youve locked down, and then the whole model falls over.
In Windows 2000, those nice Microsoft people have done all this work for you! The default security settings are very tight - users only have full control to 2 places - the HKEY_Current_User registry key and the directory represented by %userprofile% - the users own profile. In addition to this, users can write (but not delete) to WINNT\Temp. In general every other part of the system is READ-ONLY to users.
Not only does this prevent user from installing pretty much ANYTHING, it will also cause many legacy applications to fail at run time - if an application needs to create a temporary file in a directory other than WINNT\Temp, or need to write to HKEY_LOCAL_MACHINE, to store a configuration change etc, then basically youve had it! True Windows 2000 applications function within this model, but until the day comes when all popular applications are Win2K Compliant, we're going to see problems.
There are two way suggested for overcoming this problem, both involve granting users more rights over the system than is the default.
1) Utilise the 'Power Users' group.
In Windows 2000 the 'Power Users' group gives you pretty much the same rights as a regular user in NT4. In fact if you upgrade an NT4 Workstation to Windows 2000 Professional, then by default Authenticated Users will belong to this group, in order to maintain this previous functionality prior to the upgrade. You could therefore add your users to the local Power Users group on each machine, which would give them sufficient rights over the workstation to run applications in much the same way as they did with NT4 Workstation. The only problem with this approach is that it also grants users some additional rights which you may not want them to have, such as the right to change system time, create local file shares, create local users and groups. This is a bit of a step backwards, as it allows users to make changes that could compromise system integrity and security. Its a 'quick and dirty' fix to the problem.
2) Modify the Dafault ACL's
A better appraoch to the problem is to modify the default ACL's in Windows 2000 such that legacy applications can function normally. The file and registry permissions need to be relaxed sufficiently to allow users to right to certain parts of HKLM and to the Program Files directory etc. Then legacy, non-Windows 2000 compliant applications can quite happily write to HKLM and Program File in the security context of the user, but we havent given users rights to do any fancy stuff such as the ability to create shares and local users, which is frankly just not on!
Again, Microsoft have done a large part of the work for you. By using the Security Configuration Tool Set you can modify the Windows2000 ACL's such that they are compatible with the default ACL's in Windows NT4, thus providing backwards compatability for NT4 applications.
Microsoft provide a template with which to achieve this. The template is called compatws.inf and can be found under %windir%\security\templates on Windows 2000.
To apply the template from the command line issue the following command:
secedit /configure /cfg compatws.inf /db compatws.sdb
This will allow applications that ran under NT4 to function under Windows 2000 without the security risk of making everyone a member of the Power Users group.
In my experience so far with Windows 2000, use of this template becomes almost mandatory, as there are, as yet only a small number of applications that fully comply to the Windows 2000 security model.