S 4.318 Implementation of secure administration methods for Active Directory

Initiation responsibility: Head of IT

Implementation responsibility: Administrator

The responsibilities and fields of activity for the administration of a domain are divided into subgroups. Since the user accounts in the Service Administrators (who are responsible for performing the tasks to be performed to prepare for the directory service) and in the Data Administrators (responsible for administration of the content stored in Active Directory or protected by Active Directory) administrative groups have extensive access rights, corresponding precautions must be taken to protect these accounts:

Service Administrator accounts

The default Administrator account is created during installation on every domain in the overall structure. Since it is a default account, this user account is particularly vulnerable to attack. Since the administrator account cannot be disabled or deleted, it should be renamed as a precaution. When renaming this account, it must be ensured that the description of the administrator account is changed as well. After the account has been renamed, a new account with the name "Administrator" with no privileges and that cannot be used in daily operations should be created. This makes it possible to determine if there were any successful or unsuccessful attempts to log in to this unprivileged user account by evaluating the log files. Such attempts are an indication of a potential attack.

The number of service and data administrators should be restricted to a minimum. Routine administration and management tasks that do not have an impact on the configuration of the Active Directory itself, for example the administration of the domain users, should not be performed by service administrators and should be delegated to data administrators instead.

The administrator accounts should be used as sparingly as possible. Unnecessary logins to the domain with administrative rights should be avoided. For this reason, the administrators of an organisation should use unprivileged user accounts for routine, non-administrative tasks, e.g. for obtaining information from the Internet.

The administration of service administrator accounts may only be performed by members of the Service Administrator group. In particular, users with fewer privileges, such as data administrators, must not be allowed to make any changes to service administrator accounts because otherwise it would be possible to grant extended rights to less privileged users.

For this reason, a separate organisational unit, e.g. Service Admins, should be created in the user administration of the Active Directory for the administration of the service administrator accounts. The authorisations for this substructure must be selected as follows:

The service administrator groups (Domain Admins, Enterprise Admins, and Schema Admins) are then moved to the new substructure. Furthermore, the administrative user accounts of the Domain Admins must be moved to the User and Groups organisational unit, and the accounts of the workstations must be moved to the Admin Workstations organisational structure of the new substructure. It must be noted in this case that domain controller accounts may not be moved.

In addition, it is necessary to monitor the logging of changes, deletions, and the creation of service administrator accounts and workstations as well as changes to the policies.

Since some of the built-in service administrator accounts cannot be moved to the substructure created, these accounts require special protection.

The protected service administrator accounts in the Active Directory are checked regularly. During a check, the security settings of the protected accounts are overwritten using the security descriptors of the AdminSDHolder object (in the system container "CN=AdminSDHolder, CN=System, DC=domain name"). The corresponding process that is used to trigger the overwrite starts after a fixed default interval (15 minutes after a system start and every half hour after that).

On Windows 2000 Server systems, this mechanism applies to the Administrators, Domain Admins, Enterprise Admins, and Schema Admins user groups. In the Windows Server 2003 version of the operating system, the mechanism was expanded to include the Server Operators, Account Operators, Backup Operators, Print Operators, and Certificate Publishers groups.

Detailed information on the authorisations to be specified for the AdminSDHolder object can be found in the Resources for IT-Grundschutz (see Authorisations for the AdminSDHolder object in Resources for the Active Directory).

The people in the service administrator groups must be trustworthy and must have sufficient in-depth knowledge of the Active Directory administration. In order to guarantee strict implementation of the security policies of the organisation, the service administrators must be familiar with the corresponding policies.

Only users in the local overall Active Directory structure may be entered in the member lists of the service administrator groups. If service administrators from remote domains are trusted, then the organisation automatically also trusts the security safeguards of the remote organisation. Since it is generally impossible for an organisation to influence these security safeguards, a user account should be set up in the organisation's own overall structure for users from outside the organisation. This enables better regulation of access to the organisation's own domain and prevents users whose rights are unknown because of the automatic trust relationships from obtaining access to the domain.

Due to their extensive authorisations, the service administrator accounts are preferred targets of attack. For this reason, it is not recommend to allow unprivileged users to obtain information on the membership of all service administrator groups when the security requirements are high.

It must be noted in this case, though, that some server applications require read access to the lists of the members of the service administrator groups for proper operation. For this reason, the first step is to determine if such server applications will be used in the organisation.

The user accounts used to start the server processes identified should be placed in a separate group, e.g. Server Applications. Afterwards, the following authorisations should be assigned to this group in the ACL of the AdminSDHolder object:

It is therefore possible to restrict access to those authenticated users who require read access to the member lists.

Since hiding the group membership information of the service administrator groups can have an impact on operations, it is urgently recommended to check the potential effects of the changes to the AdminSDHolder object described above in advance.

The members of the Active Directory Backup Operators group must be considered service administrators because they are able to restore system files on the domain controllers. The number of members of this user groups should be limited to the minimum number required. For this reason, administrators who are responsible for backing up and restoring application servers in the Active Directory should not be entered in the Active Directory Backup Operators group. The corresponding user accounts should be entered instead in the local Backup Operators groups of the application server.

The Active Directory Account Operators group should not be used for data administration, e.g. for account administration, because its members have the ability to grant themselves more extensive rights. For security reasons, the Account Operators group should not have any members.

This also applies to the Schema Admins group of the Active Directory. Since changes to the schema of the Active Directory are usually very rare, trustworthy administrators should only be added to the Schema Admins group for the time they actually need the corresponding authorisations. As soon as the changes have been made to the schema, these members should be deleted from the group.

The user accounts in the Enterprise Admins and Domain Admins groups in the root domain of the overall Active Directory structure of an organisation require special protection due to their extensive authorisations. For this reason, two administrators should be assigned to each of these accounts and the password split in half. Each of the two administrators should only know one half of the password so that it is only possible to work with the user account by applying the two-person rule. This prevents the use of the service administrator accounts in the root domain from going unnoticed in the overall structure of the Active Directory.

Alternative methods for enforcing the two-person rule, for example the use of smart cards (in which case the PIN and smart card must be given to two different people) can also be considered as well.

In addition to securing the service administrator and data administrator accounts, it is also necessary to secure the workstations of the administrators as follows:

Only protocols that allow the data traffic to be encrypted should be used for the remote administration of domain controllers.

Data administrator accounts

In general, the structures and authorisations of the data administrator accounts depend highly on the structure of the particular organisation. It is therefore necessary to verify if the aspects listed in the following can be made to conform to the requirements of the organisation.

The administration of the data is delegated using groups, and these groups must be assigned the corresponding user rights. The group policy settings are then applied to the members of these groups. After this has been done, these user accounts just need to be added to the groups created in order to delegate the tasks. This guarantees the best possible security and also allows the administrators to continue to perform the tasks assigned to them.

Access to the group policies must be restricted to trustworthy persons. Users whose accounts allow them to create and change group policy settings can grant other user accounts higher authorisations using these policies and must be trustworthy as a consequence.

Data administrators are also simultaneously the owners of objects they have created. In the Windows Server 2003 access control model, the owner of an object also has full access to the object. This also includes the ability to change the ACL of the object. The owner of an object also has full access to all objects below this object. Furthermore, the owner can also block ACL inheritance from parent objects as well as to block access by service administrators to this object.

It must be ensured that the Administrators and Domain Administrators groups in the individual domains are also the owners of the domain root object for the corresponding domain partition. The owners of these partition root objects can change the security settings of all other objects in this partition using inheritable Access Control Entries (ACEs).

It must be ensured when planning the account administration tasks that only one data administrator changes the group memberships in a delegated area or that this task is coordinated and performed by just a few data administrators. If two different domain controllers detect a conflict between two simultaneous changes to group memberships in the context of replication, then the most recent change to an account has priority. The changes made on the corresponding servers remain valid until these servers are replicated

The use of domain local groups to control the read privileges of object attributes that are replicated in the global catalogue should be avoided because this can result in object accesses being incorrectly granted or denied. To control access to the data of the global catalog in spite of this, global or universal groups should be used instead.

Review questions:

© Federal Office for Information Security. All rights reserved.