Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Establish Secure Administration Practices

Security configuration is useless without secure administration practices. An untrustworthy administrator can remove security, or worse, go around security settings and polices. There are two ways to reduce the risk of administrative abuse; both should be used:

Understand that administrators are people and resolve personnel issues.

Apply the security principles of least privilege and separation of duties to secure the administrative role.

Personnel Issues

Just because someone has network or systems administration skills is no guarantee that they know or have the best interests of the company at heart, that they share the company's ethical beliefs, or that they will not change their practices over time. In addition to forest-wide administrative groups such as Enterprise Admins and Schema Admins, each member of any Domain Admins group has potential access to every domain in the forest. Members of the local Administrators group hold the keys to sensitive server operation and data, and delegation of authority can provide ordinary users with elevated privileges. Therefore, all administrators, whether they have that official title or not, must be trusted individuals, and their activity must be audited. The degree of trust required is directly related to the administrative duties they will perform. A background check should be required for every new administrative hire and repeated periodically thereafter. Administrative access should also be audited, and not solely by administrators. Every person who will have elevated privileges on the network should have the following characteristics:

Understands the security policy

Applies the security policy to themselves

Is willing to enforce the security policy

Is a team player

Although most employees will not be involved in security policy enforcement, they should have the other three characteristics.

Securing the Administrative Role

In addition to hiring and monitoring trustworthy administrators who support and will implement and enforce your security policy, many technical and operational controls can be implemented. You can take steps to secure the administrative role. Two security principles will help you to structure administration in your network:

Least privilege
This principle says that, in every case, you should only give people the privileges they need to do their job. For administration, that means not giving everyone membership in every administrative group, as well as creating specific administrative groups and providing these groups with only the administrative rights they require. When delegating permissions in Active Directory OUs, it means not delegating full control over an OU when only user and group administration or some other smaller task is necessary and approved.

Separation of duties
This principle defines the parts of a job that should be done by different people to prevent one person from having the ability to cause harm. An earlier example, the separation of backup and restore rights, fulfills this principle.

Apply these principles to administrative duties to secure the administrative role. Several operations and functions that are native to Windows Server 2003 can be used to do so. Most of these processes, such as the use of groups and delegation of authority, are described in Chapter 7, "Active Directory's Role in Domain Security." Others, like SID filtering, are defined in Chapter 8, "Trust." An understanding of the concepts of isolation and autonomy and how to split administrative duties into service and data administrators will give you better control over the scope of any administrators privileges.

Service and Data Administrators

It is a mistake to make all administrators equal. The best approach is to narrowly define administrative practiceslike users, administrators should only be given the ability to do what they need to do. There are many different administrative roles that can be configured, but two broad categories exist: service administrators and data administrators.

Service administrators control Active Directory configuration and policy and have physical access to the domain controller and forest infrastructure. They can add DCs and new domains and have the ability to attack the entire forest. Service administrators are members of the Domain Admins, Enterprise Admins, or Schema Admins groups.

Data administrators play a role similar to NT domain admins. They support ordinary users and computers, add and remove users and groups, and modify group policy settings. They may also be administrators over single computers or computer roles such as file servers, database servers, and so on. Data administrators should not be given the right to manage administrator accounts. Data administrators are members of groups created to manage specific OUs or may be members of the local Administrators group on specific servers.

Skillful use of existing Windows groups, User rights, and delegation of authority can split administrative roles into service and data administrators. This not only fulfills the principle of least privileges but also enforces separation of duties to some extent. You can limit data administrators to the data administrator role. However, because of the nature of the service administrators group membership, and the inherit ability of an administrator to take ownership of any object, you cannot prevent service administrators from performing data administrative roles. You can, for example, delegate the user and group creation rights for a specific OU to a group designed to manage that data. Members of that group will only have the right to manage and create users and groups within that OU, and not within the domain. However, the domain administrator will have the ability to manage users and groups in the OU and will have to be limited by written policy, not by technical controls.

Autonomy and Isolation

In designing a secure Active Directory infrastructure, consider the need for autonomy and isolation. Autonomy means that areas of independent management are required. This ability can be gained by creating a single forest with multiple domains, and to some extent by creating OUs within the domain. Administrators of domains and OUs have the ability to manage the objects (users, groups, computers, etc.) that exist within their domain or OU. However, another administrator, one with authority over all domains, such as the Enterprise Admin, or over all OUs, such as the Domain Admin, can also manage those objects. A Schema Admin can modify the schema and impact all domains. Isolation, on the other hand, requires a complete security boundary. The Active Directory domain is not such a security boundary. In addition to forest-wide administrative groups, it may be possible for a member of the Domain Admins group to fraudulently obtain administrative access to other domains within the forest. Isolation is not possible within a forest. It can be accomplished by creating multiple forests. Only in separate forests can the interference or access to AD service or data by other administrators be prevented.

The article "Design Considerations for the Delegation of Administration in Active Directory" details the concept of isolation and autonomy. Read it at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/ad/windows2000/plan/addeladm.asp. Then, read Windows Server 2003specific documentation in the Windows Server 2003 Deployment Kit.

To decide which approach is best for an organization, the needs of the organization should be established. Because the forest is the security boundary, separate forest should be used where

An extranet will be established.

There is a legal requirement to provide isolation.

There is a lack of trust between divisions or other structures of the organization.

Secure Application and User Access to Domain Controllers

At a minimum, all users need the ability to remotely access the domain controller to authenticate. They do not require carte blanche access to all drives, files, and utilities on the DC or the ability to log on locally to the DC. Likewise, applications that run as services should not have unwarranted privilege to access resources on DCs. You can prevent unnecessary access by

Managing user rights

Managing membership in privileged groups

Managing share permissions

Managing file, folder, and registry permissions

Using domain controllers only as domain controllers and not installing additional services on them

Ensuring that the group Pre-Windows Compatibility Access has no members

The group Pre-Windows Compatibility is used to provide backward compatibility with legacy applications. These applications require elevated privileges and access to files, folders, and registry keys that go beyond what is assigned to the Domain Users group. It is populated by the group Everyone if the option to set Permissions Compatible with Pre-Windows 2000 Server Operating Systems is selected during dcpromo. It may have been selected by accident or may have been necessary at the time the domain was created, but it may no longer be necessary. You may be able to safely remove any members of this group and improve security on DCs, but first check to see if it is necessary . An example of applications that need this is using Routing and Remote Access Services on Windows NT 4.0 computers.