S 2.364 Planning of administration for Windows 2003 and higher

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Head of IT, Administrator

Before installing a Windows server in Version 2003 and higher, extensive plans must be produced to ensure proper and secure introduction and, subsequently, to enable secure operation. Requirements for planning the administration are obtained from the description of the application scenario and the definition of the purpose of the server. The administration must be planned based on the specifications in the security policy (see S 2.316 Defining a security policy for a general server) and documented. The security policy must point out, among other things, that the server is not to be used as a user workstation. Administrative changes performed during actual operation can have security-related side effects and therefore need to be implemented with great care.

Administration can be performed on-site by accessing the server from its console, from another computer in the LAN, or from outside, for example over a VPN. When planning the tasks and authorisations of the administrators, regulations for access to the site must be created (see S 2.6 Granting of site access authorisations). During planning, the separation of functions worked out beforehand (see S 2.5 Division of responsibilities and separation of functions must be taken into account. The granting of unnecessary site and data access rights to the server is to be avoided. The task areas of the Windows Server administrators must be documented and coordinated with the organisation's security policies.

Typical administration tasks

Administrators must regularly perform various actions in order to update and maintain the IT systems and to keep them functioning. This includes the following tasks, among others:

Built-in standard groups for administration

Due to the wide-ranging authorisations required to administer a Windows server, a suitable authorisation concept must be developed. The following local security groups for administration are available by default in a standard installation:

System-defined security groups

Group Server 2003 Server 2008 Description
Administrators X X Full access to all areas, very critical to security
Power Users X X Wide-ranging access to system settings with some restrictions: For example, power users cannot take over ownership of someone else's files, load or unload device drivers, manage security and system logs, or install services
Backup Operators X X Read and write access to all files
Remote Assistance Group X X Only available in the Active Directory environment, may attend a console session from remote ("Shared Desktop"), thus obtain the rights of the user currently logged in. Unsuitable for remote administration, Remote Desktop is more suitable for this purpose.
Help Services Group X   With the help of this group, administrators can define a set of shared rights for all support applications; can pose a high security threat.
Network Configuration Operators X X Administer the properties of connections in the Network connections folder
Print Operators X   Administration of printers and printer queues
Performance Log Users X X Administration of the Performance console (perfmon.exe)
Distributed COM Users X X Administration of the Component Services console
System Monitor Users X X Read access to performance counters and logs
User X X Permits login to member servers and stand-alone servers
Remote Desktop Users X X Group for controlling the remote desktop dial-in capability
Telnet Clients X   Group for controlling the Telnet dial-in capability
Replicators X X A group used by the operating system.
Guests X X Control of access to resources for guest users (login not required).
Cryptography operators   X Members of this group are authorised to execute cryptographic operations.
IIS_IUSRS   X This is an integrated group used by Internet Information Services (IIS).

Note:

The default groups available on a domain controller differ from the groups named above.

To fulfil the administration tasks, there are security groups available in the operating system which have full administrative access to all areas of the server and therefore can significantly influence the security (for example, the group of Administrators). For defined uses, e.g. use as a file server, security groups not possessing full administrative rights must be planned. This allows administrative tasks such as creation of a data backup using the Backup Operators group, as well as the threats arising in conjunction with these tasks, to be limited to the corresponding section of the server. For user groups and their members, the principle of granting the minimum combination of rights must always be abided by. For example, it should be examined if the lesser rights available to the Power Users security group are sufficient to perform the administration tasks (see S 5.10 Restrictive granting of access rights). If a network is available, then it must be determined if it is possible to perform the specified tasks using the security groups available in the Active Directory or on the local server (T 2.115 Inappropriate handling of standard security groups in Windows server 2003 and higher must be taken into account).

The installation of additional components means that the selection of possible default groups for administration must be expanded. An example of such a case is the Terminal Server Users security group needed when terminal server services are installed or the DHCP Administrators group when the DHCP service is installed. Using the existing security groups is not always the best solution, though, since their rights cannot be adapted. For this reason, a special security group is to be used to perform the administration tasks specified.

To avoid making a mistake, you must precisely specify for which administrative tasks the authorisations of the Administrators group are really necessary. For example, only members of the Administrators group are permitted to make changes to the file system to enable full access by default (for additional information, see S 4.149 File and share authorisation under Windows). On the other hand, the Administrators group always has access to every server via Remote Desktop, independent from the Remote Desktop Users group. In large-scale environments, the groups with the lowest level of administrative access should always be preferred. If necessary, rights can be added to groups to obtain a higher level of access.

Self-defined groups

Furthermore, self-defined security groups can be designed that contain the authorisations necessary for a defined administrative task. Some groups can be added to the list provided above according to their level of access.

The planning phase must ensure that programs cannot be inadvertently called up with wide-ranging administrative privileges, in order to prevent that the programs could then gain access to critical areas of the server and put the security of the server at risk.

User accounts for administration

When you examine the tasks performed by someone with an authorised user account in an IT environment, a line must be drawn separating the administrators from the users:

It is highly recommended to apply this approach and create two separate accounts for each administrator. Since the default groups built in to Windows servers do not differentiate between administrator or user accounts, a normal user account should be available and used accordingly for routine daily work and an administration account for administrative tasks.

It is important to implement a defined and documented process for the configuration and deletion of all types of user accounts. This is especially important for administrative accounts.

The goal is to ensure that users log in to user sessions on a Windows server or Windows administration computer with the lowest possible level of authorisation, which means with normal user rights whenever possible. Several basic approaches to accomplish this are possible:

It is recommended to note the particular strategies in a policy for the Windows server environment.

Configuration changes

It must be taken into account during the planning phase that administrative changes during live operation are to be considered critical in terms of availability and reliability (see S 4.78 Careful modifications of configurations). When planning the administrative tasks, you must decide which tasks can be performed during live operation and which tasks can only be performed in special maintenance windows. These decisions depend highly on the server configuration, the other server applications used, and the availability requirements. Configuration changes should only be performed in special maintenance windows since such changes may require a restart of the server during live operation under some circumstances.

Administration tools

Another important aspect is the selection of suitable administration tools for the particular server. The tools supplied provide very good capabilities for integration into the security mechanisms of the operating system as well as a uniform operating design. The tools used must meet the requirements of the organisation's security policy.

The main components supplied for administration are:

External service providers

The special requirements for outsourcing (see module 1.11 Outsourcing) as well as any contractual agreements with external service providers must be integrated into the authorisation concept described above. Separate security groups that are only authorised to use the components needed should be developed for external service providers. The default groups available are not suitable for this purpose. For example, you should check if the authorisations of the Backup Operators group are too wide-ranging for a service provider who only provides backup services.

It is especially difficult to transfer login data for administrative accounts and enforce password guidelines when the employee of the service provider does not work on-site (see also T 2.111 Exposure of login data relating to change of service providers). When Active Directory is used, it is only possible for external service providers to enforce different sets of password guidelines within a single domain if Windows Server 2008 or higher is installed. For this reason, this needs to be regulated at the organisational level and defined in an IT guideline, when Windows Server 2003 is used.

Installing patches and updates

Windows servers permit the regular and automatic installation of updates. The risk of service interruptions due to automatic restarts and incompatibilities with programs installed should be weighed against the requirement of closing security gaps promptly.

This function should be deactivated for servers with a high protection requirement. The decision whether or not to allow automatic updates on servers with normal protection requirements is to be made on a case-by-case basis.

Automatic updates should not be downloaded directly from the Internet, but should be managed and released for installation via a software distribution system such as Windows Server Update Service (WSUS) (see S 4.417 Patch Management with WSUS under Windows Server 2008 and higher). In this case, rules must be defined specifying which types of updates and patches can be installed automatically and which need to be released by an administrator. In any case, implementation of safeguard S 2.273 Prompt installation of security-relevant patches and updates must be ensured.

Before installing Service Packs, a rollout strategy (order of the servers, any eventual rollbacks) must be specified. In this case, it must also be taken into account that Service Packs can contain new functions that need to be installed first on servers assuming certain roles. An example of this is the Distributed COM Users safety group added by Service Pack 1 of Windows Server 2003.

Documentation

The administration concept planning phase must also include the design of a suitable documentation concept. This concept should be closely based on the change management (S 2.221 Change management).

The tasks defined for the administrators of a server, the corresponding authorisations (including resource authorisations), and the administrator tools to be used are to be included in the documentation to ensure smooth operation in case of a loss of personnel (see T 1.1 Loss of personnel and S 2.31 Documentation on authorised users and on rights profiles).

A suitable concept for documenting the service account passwords must be developed. These passwords are highly critical and must be subject to strict access controls (e.g. stored in a safe, multiple encryption, and application of the two-person rule).

When administrative scripts are used, additional documentation must be prepared. The configurations and operation scenarios to be documented can be taken from the documentation for the script test environment (see S 4.240 Setting up a testing environment for servers).

Review questions:

© Federal Office for Information Security. All rights reserved.