Management of Department Computers

Murat Yildirimoglu, April 25 2005

One important problem is the management of the department computers. There
is no easy solution to this. But first, a little explanation.

NT-based operating systems (Windows NT, Windows 2000, Windows XP, and
Windows 2003) are secure systems. Number one criteria for a secure system is
it is compulsory to authenticate in order to use the resources of these
systems. To facilitate the authentication, these OSs have local security
database, SAM. Even the DCs have SAMs together with the Active Directory
(AD) database.

The administrators of a computer (the people that have permissions and
rights to do everything on that computer) are the ones that are members of
the Administrators group in that computer’s SAM. Hence, if somebody is to
administrate a computer, that body must be a member of the Administrators
group in the computer’s SAM.

When a computer joins a domain, Domain Admins group is added to the members
list of the Administrators group in the SAM of the computer. Because of
this, members of the Domain Admins group have the authority to administrate
that computer (and all the other computers) in the domain, unless the Domain
Admins group is removed from members list of the Administrators.

It is frequently necessary to assign some people other than the Domain
Admins group, to manage some computers (managing means stopping and starting
the services, changing the time and date, formatting the disks, installing
and sharing of the printers, installing and removing the programs, etc.),
because the domain admins are few and the computers and users so abound. In
these cases, we determine some people responsible from the computers in some
departments and request from them the managing of the computers. But, how
can we assign these people responsible from some machines?

You can think of the delegation of the Organizational Units (OU): You
collect machines and their users in the relevant OUs, and then you delegate
the control of these OUs to the specified person or preferably, group. But
it does not solve the problem because delegation of control mechanism does
not add the person or group to the member list of the Administrators group
in the SAMs of the machines in those OUs (I wish it could).

So, you must find a way to add the user or the group to the Administrators
group.

One easy (and burdensome) solution is the adding of the user or the group to
the Administrators group using the Computer Management console. This
console, like the other management consoles, has a nice feature to connect
to a remote computer. Using this feature, you can connect to the remote
computers and one by one, add the user or group to the Administrators group
of that machine.

The other and preferable solution is to use Group Policies on the OUs.
Security Settings under the Computer Configuration of a Group Policy has a
node as Restricted Groups. This setting determines the membership of a group
in the SAMs of the computers in the OU. First, you create groups that
administrate the machines. Second, add the related users to these groups.
Lastly, specify that group as the member of the Administrators group in the
Restricted Groups section. When the machines restarted this setting will be
applied to the computers.

In the future, Microsoft can solve this problem, adding a feature to the
delegation of control wizard that will enable us add the user or group to
the machines’ Administrators group.