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 WinntSystem32 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.
Windows 2000
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 WINNTTemp. 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 WINNTTemp, 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.
The Solution
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%securitytemplates
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.