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

Managing Computers and Users Using Active Directory

Unmanaged users and computers put the organization at risk. Managed users can be provided just the privileges and permissions required to do their jobs and prevented from inadvertently compromising security. Managed computers can be hardened against attack and provide platforms on which the integrity of data can be guaranteed to a reasonable degree. In addition, managed users and computers require less manpower to maintain and secure. Active Directory is designed to provide a sound management base, and tools are available to automate the process.

Users and computer accounts are created and placed within a specific Active Directory container and can be managed via Group Policy, Windows Management Instrumentation, direct configuration, and other administrative tools. Much of the direct configuration operations can be scripted and coupled with Group Policy processing to provide a largely automated environment. In addition, the administration of management processes for specific collections of users and computers can be delegated.

The simple act of adding an account places it in an environment that already has some management in place. Default GPOs provide minimum management and security for new accounts. The first step in providing a customized, managed environment is to understand the default configuration specifics and the available tools and account properties. Understanding the direct configuration tools will aid you in developing and using scripted tools.

The Impact of Default GPOs

When a new domain is created, two default GPOs are established that set the initial security policy via the Domain Security Policy and the policy for DCs in the domain via the Domain Controller Security Policy. These policies affect the security settings of every new computer and user account. As additional domain and OU GPOs are created and linked to SOMs, their settings can modify some of the default security provided by the default GPOs. Other changes must be made by directly configuring the default GPOs; some settings, made at the domain and domain controller level, cannot be overridden by OU-linked GPOs.

The Account Policy portion of the Domain Security Policy sets the Account policy (Kerberos, Password, and Account Lockout Policies) for the domain. If a new GPO is created and linked to an OU, and that GPO has its own Account Policy configured, it will have no impact on domain users when they use domain accounts to log on. (OU Policies of this type will impact local user accounts on the computers whose accounts reside in the OU. If a local account is used to log on to the computer, then the OU policy will be in effect.) Figure 7-7 displays the default domain policy Account Policy and the details of the Password Policy portion.

The Domain Controller Policy only affects the domain controllers whose accounts reside in the Domain Controller OU. This policy sets the Audit Policy and Security Options for all domain controllers. In addition, the User Rights Portion of the Domain Controllers GPO affects all domain user and computer accounts and groups. If User rights are set in another GPO linked in any other SOM, they will only affect local user, computer, and group accounts. The practical end result is that a domain user can obtain domain-based users rights and may also obtain additional rights on the computer at which he is interactively logged on. In addition, the following Group Policy components contain settings used to manage computers and users:

Security Options
Allow the setting of multiple registry entries by using a GUI. Many of them affect users and groups.

Restricted Groups
Allow management of group membership by policy. Adding groups to the Restricted Groups container turns the control of membership over to the Restricted Groups policy. If users are added to the group account in Active Directory but not in its representation in Restricted groups, the account will be removed upon the next policy refresh. Likewise, if a user is added to a restricted group within the security settings of the GPO, the account, if not present in the Active Directory group, will be added.

Registry and File System Permissions
Provide a way to deny or allow users, groups, and computers to access these resources.

System Services
Provide the ability to disable or set startup function of services and control over who can modify these settings. Permissions determine which users and groups can enable, disable, start, stop, or set the startup function of services. The presence of an enabled or disabled service may impact what a user can do. For example, the Domain Users group may have permission to remotely access the network, but if the Remote Access service is stopped or disabled, they will not be able to do so.

Public Key Policies
Indicate whether or not certificates will be issued and whether they can be used for certain purposes.

Software Restriction Policies
Indicate who can run or not run specific software.

IP Security Policies
IPSec policies implemented in Group Policy manage communications with and between computers affected by the Group Policy.

Wireless Network Policies
Manage wireless network policy for affected computers.

Administrative Templates
Provide hundreds of configuration parameters affecting many operating system functions, programs, and software as well as the user interface.

Creating and Configuring Users, Groups, and Computers in Active Directory Domains

When user and computer accounts are created, their rights and privileges on the network are determined by their account location within the OU structure, by default domain security policy, by their account properties, and by the access they are granted either directly or by membership in Windows groups. Some default groups exist, and custom groups can be created to simplify management of and access to resources and the management of privileges through the domain. Within the forest, groups can also be used to grant access to resources in one domain to users whose accounts reside in another domain. Access can be granted directly to user or computer accounts; however, this is not recommended because it is too difficult to manage and audit. Assigning rights and privileges to groups simplifies the management of resources. Using domain-based groups and accounts eliminates the need for users to maintain user accounts in multiple computers and domains. In a single domain, forest rights and privileges on computers joined in the domain are assigned to domain users and computers via membership in domain groups.

Using Groups to Manage Access and Rights

On a single standalone Windows NT and above computer, local computer user groups are assigned rights and privileges on that computer. Group member accounts placed in the groups receive those rights and privileges. In a domain, one additional step may be practicedcreating domain-wide groups. Domain user and computer accounts are placed in the domain group. Some domain groups are used to grant domain privileges to users. Others are used to give users privileges and rights on computers joined in the domain by adding domain groups to local groups on the member computer. In a Windows 2000 or Windows Server 2003 domain, computer accounts can also be added to domain computer groups. The rights and privileges of the domain computer groups are assigned to group member computers.Chapter 8.

Group Types
These include Security, groups that can be granted access to objects by adding their SIDs to the discretionary access control list, and Distribution, groups used solely for creating email lists at this time. Distribution groups cannot be used to grant access to objects.

Forest functional mode
A classification that can be set when the types of domain controllers in the domain move from mixed to Windows 2000 and above to Windows Server 2003. Each mode provides specific benefits, additional functionality, and options.

Group Scope
Rules that define where groups can be created and where they can be used. Group scope changes with functional mode. In a single domain forest, group scope consists of the following:

Global groups and Domain local groups can be created only on domain controllers.

Local machine groups can be created only on Windows NT and above computers.

Global groups can be nested either in local groups on domain member computers or in Domain local groups.

Global groups and Domain local groups can be granted privileges and rights on domain controllers.

Global groups, local groups, and Domain local groups can be nested in Domain local groups and Groups that are local to a specific computer.

Local groups can be created only on a single computer.

Local user accounts can be added only to local groups.

Impact of Global Catalog Server (GC) on group
Information on membership in Universal groups, which can only be created in Windows 2000 or Windows Server 2003 functional-mode domains, must be available at logon. This can mean logon issues for those logging on remotely across the WAN. A GC and DC must be located and used during the logon process or a DC must be available and group caching must be enabled. (When group caching is enabled, the membership of Universal groups is cached on the local domain controller.)

SID History/SID Filtering
SIDs are unique user identification numbers. If a user account is moved from one domain to another, that user's SID changes, and thus that user's ability to access resources changes. Maintaining SID History is a way to ensure access to objects based on SIDs.

Basic Account and Group Management Operations

The basic operations for account and group management remain similar to that done on a standalone computer. The advantages in a domain and in a forest are single sign-on (only one account and password needs to be known) and the capability to manage resources and privileges across multiple computers.

In the domain, User and Computer accounts can be created from the Active Directory Users and Computers (ADUC) console or via scripts. Domain user accounts have a larger variety of configuration properties than local user accounts do. During or after account creation, they can be added to groups.

Creating and Configuring Users and Groups

User accounts can be created initially by simply adding an account name and password, but there are many attributes that can be configured. If additional Active Directory-aware services such as Exchange Server are added to the domain, additional attributes are added, too.

Create a User Account Using ADUC

User must change password at next logon (only default checked box)
User cannot change password
Password never expires
Account is disabled

User, computer, and group accounts can also be created using the dsadd command. When large numbers of user accounts need to be created, it is more useful to use this command in a script or to use utilities developed specifically for this purpose than to use the GUI.

Configure a User Account

Multiple property pages are available for use in configuring the user account. On the General page, basic information about the account including office, telephone number, email address, and web page can be added. Additional account properties are located on other pages. The most important account information is located on the Account property page, as shown in Figure 7-10. This information can be modified to increase security in several ways.

To restrict logon hours, click the Logon Hours button. Setting a schedule here, as shown in Figure 7-11, controls the hours of the week the user may log on. Restricting logon hours prevents the user or someone with their account credentials from using domain resources when they are not authorized to do so. This can reduce the number of potential attacks because an attack during normal business hours might be more easily noticed, and if fewer accounts have access, there are fewer opportunities for misuse of domain user credentials. If users are not authorized for remote access, restricting access to normal business hours prevents individuals who have evening or night access, such as cleaning crews, from using employee's credentials for system access. Any attempt to use the restricted account outside of the hours authorized for use will fail, and if auditing is configured, the attempt will be logged.

To restrict users to specific computers, click the Log On To button. Figure 7-12 displays the Logon Workstations dialog box. When users are limited to the use of specific computers, the possibility that they will gain access to resources in other areas or that their credentials will be used for attacks is reduced. It may also prevent unauthorized access from intruders because they must know where the account can be used and must be able to access that computer.

In addition to restricting logon hours and logon computers, domain user accounts can be as follows:

Required to use a smart card

Trusted to delegation

Prevented from being delegated

Required to use DES encryption types

Prevented from requiring Kerberos pre-authentication

Create a Group and Add Members

Groups should be used to assign access to resources and operating system rights. Users can obtain these privileges by becoming group members. To create a group, follow these steps:

User and computer accounts are added to groups by adding the account to the user or computer Member Of property page or by adding the user or computer account to the group's Member page. Membership is restricted by using group scoping rules.

Adding and Managing Computers

Computers can be joined to the domain to centralize computer management and centralize control over computer-based resources. Member computers can be remotely managed using domain administration tools such as the Computer Management console and can be controlled via Group Policy.

Making a computer a domain member is a two-step process. First, the computer account is created in the AD, and then the computer is joined to the domain. The joining process includes the creation of a password and the establishment of a secure channel. By default, the new computer account is created in the Domain Computers container. This container is not an OU, and a GPO cannot be linked to it. Because its location is within the domain container, computers in this container will, however, receive the Default Domain GPO. Move computer accounts to OUs to do the following:

Delegate authority for their management to another user or group

Delegate some part of their management to another user or group

Configure and apply a unique security policy to these computers by creating or linking a GPO to the OU that they reside within

Creating and Configuring Computer Accounts

Computer accounts can be created when a computer is joined to a domain. The computer account can also be prestaged or created directly in the Active Directory without actually joining a computer to the domain. The account can then be used when a computer is joined to the domain. The advantage of prestaging is that the SOM for the computer account can be preselected, and the user account with the privilege to create the account can be designated. To prestage a computer account, follow these steps:

NOTE: GUID Discovery

The computer GUID is a unique number (sometimes referred to as a Universally Unique ID, or UUID) assigned by the computer manufacturer. It may be provided on a label on or inside the computer case. It may also be discovered by using WMI to obtain it from the computer BIOS. Another way is to use a sniffer and identify the DHCP discover packet sent by the computer when it attempts to obtain an IP address. This packet will include the computer GUID.

Management via the Computer Management Console

After a computer is joined to the domain, the Computer Management console can be used to remotely manage it. Security items such as Local Users, Groups, Shares, Services, and Event Logs can be accessed via this tool, as can drives and volumes. The Computer Management console is accessible via Active Directory Users and Computers. To open it, right-click the computer account and select Manage from the menu. The Computer Management console for the remote computer will be opened, as shown in Figure 7-16.

Management and Control via Group Policy

New computer accounts are created by default in the Domain Computers container. This container is not an OU, and a GPO cannot be linked to it. Assigning a GPO to a select group of computers within the domain requires moving the location for their computer account creation to a specific OU and then linking the computer-specific GPO to the OU. Any number of OUs can be created and computer accounts moved to them. It is also possible in a Windows Server 2003 functional level domain to redirect default computer account creation to a specific OU. To do so, an attribute of the PDC emulator must be modified. The primary advantage to doing this is that when computer accounts are created, they are immediately placed in an OU, and the GPO linked to the container will be applied to the computer. This means that current security configuration and any additional Group Policy directives will be applied to the computer more quickly. If the default container for computer account creation is not changed, only the domain GPOs are applied to new domain member computers. During all computer joining processes, whether initiated from the computer using the System applet or using command-line utilities such as net user, net computer, net group, or netdom, there is no opportunity to specify an OU.

If the functional level of the domain is Windows Server 2003, two tools, redircmp.exe and redirusr.exe, can be used to change the default container for new computer and user accounts, respectively. Both utilities are native Windows Server 2003 utilities. The command syntax is as follows:

Redircmp OU=container_distinguished_name and Redirusr OU=container_distinguished_name

The container_distinguished_name represents the distinguished name of the OU desired. For example, the following statement will assign the BaseComp OU in the Chicago.local domain to be the default location where computer accounts created in the chicago.local domain will be created.

Redircmp ou=BaseComp,dc=chicago,dc=local

The BaseComp OU must exist before the command is run. As an added precaution, you must rename the default Computers and Users containers. You can do so by using ldp.exe.

To learn more about these utilities, read the "Redirecting the Users and Computer Containers in Windows Server 2003 Domains" knowledge base article 324949 at http://support.microsoft.com/default.aspx?scid=kb;en-us;324949.

Delegation of AdministrationUsing the Delegation of Control Wizard

The Delegation of Control Wizard can be used to assign administrative authority to non-administrative groups over collections of users and groups. This control empowers the non-administrative group members to perform their required administrative duties without giving them full Domain Admin privileges. The scope of their authority is limited by granting control over a specific subcontainer (site, domain, OU) within Active Directory and by granting them only specific rights over objects in that container. The Help Desk group, for example, can be given reset password rights for several OUs of user accounts without giving them reset password rights for accounts that are members of domain or local computer administrative groups.

The process is simple because a wizard is provided; however, it may be difficult to obtain exactly the results required. Delegation is accomplished by assigning groups permissions on Active Directory objects. It may be difficult to determine which objects to grant which permissions to because there are almost infinite combinations of objects and permissions that can be assigned, and it is difficult to determine exactly which of the ACLs to select to grant a specific privilege.

Distributed administrative authority is not a good idea if you do not have clear goals in mind and if some required information is difficult to ascertain. There are, however, some well-defined tasks, such as complete control over user accounts in a target OU or password reset, that can and should be delegated. Additional, less well-known tasks can be delegated after research and testing.

If the role the user needs to fill can be defined, and the ACLs on Active Directory objects that need to be set are well defined, the Delegation of Control Wizard can be used to perform the delegation. A small selection of common roles and tasks is defined by the wizard, and it also allows selection from the available ACLs on a selected container. The following step-by-step procedures detail how to use the wizard to assign administrative roles and privileges. Two procedures are provided. First, the ability to easily select predefined tasks is listed. Then an example of a common use of delegation of authoritythe creation of a Help Desk roleis detailed.

TIP: How To Expose More Permissions

Not all permissions that can be assigned to objects are exposed via the wizard or through the ACL editor. A special file in the %windir%\System32 folder, the dssec.dat file, contains a list of these permissions. The items are marked with the number 7. The file can be edited by changing the 7 to a 0, and the permission will be displayed in the wizard. However, this is not necessary in most cases and should only be done if a unique need to allow or deny a specific permission is required.

Granting Standard Tasks

Developing the Help Desk Role

When the task that must be delegated is not preconfigured, custom tasks can be created for any role. The role of help desk operator requires a unique assortment of privileges and rights that are defined by an organization's policy. Within the organization, specific groups of computers and users may be managed and assisted by placing their accounts in OUs and then delegating administrative rights over objects in these OUs to a custom Windows group. To create the role, follow these steps:

Create the custom user group for Help Desk.

Determine which objects, such as users and computers, the Help Desk group should control.

Determine which permissions on these objects should be granted.

Use the Delegation of Control Wizard to assign these permissions to the Help Desk group.

Add Help Desk employee user accounts to the Help Desk group.

The following instructions provide an example of how to assign a common Help Desk task. To complete the Help Desk role, assign all of the permissions required by your organization.

Understanding Active Directory ACLs

When the Delegation of Control wizard is used to assign tasks to users and groups, it does so by assigning ACLs to objects in the Active Directory. The permissions can also be assigned directly. Just as access control lists on files, folders, printers, and registry keys must be understood before you can appropriately apply them, you should understand Active Directory permissions, or rights, before attempting to apply them. Unfortunately, it's not an easy task. Object permissions are different from file or registry permissions, and each object within the Active Directory also has its own set of permissions based on the unique properties or attributes of the object. There are so many unique permissions that it would be nearly impossible to list all of them, and it would be impossible for mere mortals to remember what each one of them means by itself, let alone what they might mean if granted on a specific object or if used in combination with other permissions.

However, it is possible to define the types of permissions that it is possible to set and in that way at least obtain an introduction into the miasma that is object rights in Active Directory. To do so, first examine standard and extended rights as they can be programmatically defined, and then match these rights with the specific permissions displayed through the Delegation of Control Wizard and through the ACL editor.

Standard and Extended Rights

Standard rights are those generic rights that can be applied to every object. These include the following:

DELETE
Delete the object.

READ_CONTROL
Read data from the security descriptor, but not the SACL.

WRITE_DAC
Modify the DACL.

WRITE_OWNER
Assume ownership of the object.

SYNCHRONIZE
Use the object for synchronization. A thread can wait until the object is in the signaled state.

ACCESS_SYSTEM_SECURITY
Read or set the SACL.

GENERIC_READ
Read permissions and all properties on the object, and list the object name if the parent container is listed. Alternatively if this object is a container, list its contents.

GENERIC_WRITE
Read permissions, write properties, and perform validated writes to the object.

GENERIC_EXECUTE
Read permissions and list contents of a container object.

GENERIC_ALL
Create or delete children, delete subtree, read and write properties, examine children and the object, add and remove object from the directory, and read or write an extended right.

DS_CREATE_CHILD
Create children. The ACE ObjectType member can contain a GUID, which IDs the type of child object that can be created. If there is no GUID in the ObjectType, all child object types can be created.

DS_DELETE_CHILD
Delete children of the object. The ACE ObjectType member can contain a GUID, which identifies the type of child object that can be deleted. If there is no GUID in the ObjectType, all child object types can be deleted.

ACTRL_DS_LIST
The right to list children of this object. For more information about this right, see Controlling Object Visibility.

DS_SELF
Perform an operation controlled by validated write access right. The ACE member ObjectType can contain a GUID identifying the validated write. If noGUID is in the ObjectType, all validated write operations possible for this object can be performed.

DS_READ_PROP
Read the object properties. A property set or property can be defined by a GUID in the ObjectType member of the ACE. If no GUID is present, all object properties can be read.

ADS_RIGHT_DS_WRITE_PROP
Write object properties. A property set or property can be defined by a GUID in the ObjectType member of the ACE. If no GUID is present, all object properties can be written.

DS_DELETE_TREE
Delete all children of this object. (Permissions on the children do not matter; that is, a user with this right can delete a child object even if the child object denies deletion.)

DS_LIST_OBJECT
List this object. Without this right or the ACTRL_DS_LIST right, the object is hidden from the user. However, this right is ignored if the dsHeuristics property is not set or set so that its third character is "0."

DS_CONTROL_ACCESS
Perform an operation that is controlled by an extended access right. The ObjectType member of the ACE may contain a GUID that identifies the extended right. If it does not, all of the extended right operations that are associated with the object can be performed.

Extended rights are those rights that are specific to only some objects within the Active Directory. This list is very long; however, Chapter 9.