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

Default Operating System User Roles

It is much easier to administer users on a system if the roles that a user may perform on the system are defined, and each user is provided membership in a role. It is easier because it reduces the number of different access definitions that must be managed and because it removes these definitions from the dynamics of employee changes. When roles are defined and used, it is easy to provide the required access to a new employee; he can simply be given that role. It is also simple to remove someone's access by removing him from that role. Auditors can also more easily determine if access is defined correctly (the right access is granted for each role) and assigned correctly (the right individuals are given the correct access). Finally, roles can be more easily modified (granted or denied access) because there are fewer of them.

In addition to user roles, computer roles can also be defined. Just as a user role defines the rights and permissions a user has on a system, computer roles define these things for computers.

Windows Server 2003 roles are defined by creating groups and assigning them user rights and adding them to the ACLs on objects. Default operating system user and computer roles exist. The following information further defines default user and computer roles:

A few of these default roles are explicitly assigned to a user account, while most of them are defined by default groups.

These users and groups have inherent rights.

You can use these groups and users to assign administrative roles.

Some default rights that these roles have can be removed or assigned to other users. Other default rights, such as the right for an administrator to take ownership, can be assigned to other users but cannot removed from the Administrator account.

Some groups exist only after a Windows Server 2003 is promoted to domain controller or after a specific service is installed.

Before creating custom groups, examine the default groups to determine if they fit the required need. However, before using default groups, review the rights and permissions granted to group members. Best practices dictate that you assign only the rights and permissions necessary for a user to fulfill her duties. If a default group gives her more power than she needs, create a custom group and use that instead. Follow the model provided by default groupscustom groups do not have to exist in every domain in the forest, and they do not have to exist on every computer in the domain if they are local groups.

Default User Accounts

Default user accounts on a Windows Server 2003 server are as follows:

The Administrator account is the most powerful user accessible account on the system.

The Guest account is the least privileged account on the system. If enabled, the guess account can be used by anyone to log on to the server. Authorized users whose accounts are locked out but not disabled could also use it. By default, this account is disabled.

System User Accounts

In addition to default user accounts and built-in groups, three system user accounts are provided that can be used as logon accounts for services. These accounts are not listed in the Users list in the Computer Management console, but, like implicit groups, they are available for assignment as the logon account for a service. Two of them, Network Service and Local Service, are accounts with limited system access. The three system user accounts are as follows:

The Network Service account has limited access to the local computer and access rights to the network using the computer account for authorization. If assigned as the logon account for a service, you can restrict its access to other network resources by adding the computer account to the right Deny Access to this computer from the network on the remote computer.

The Local Service account has limited access to the local computer and can only access network resources that can be accessed anonymously.

The Local System account is a very powerful account. It can do anything the operating system can do with its own server processes. Do not use this account when selecting an account to use for service logon; however, if this account is assigned to an operating system service, do not change it.

TIP: Do Not Change Default Service Account Assignments

Many default Windows Server 2003 services use the more restrictive accounts. However, some use the Local System account. It is recommended that you not change the service accounts assigned to default services because you may cause them not to start, to stop, to hang, or to otherwise become unstable. Likewise, if more limited accounts are assigned, do not replace them with the Local System account.

Groups

Managing large numbers of anything is difficult, which is why it is intuitive to classify similar objects and then work with the object definition instead of the individual. This is the only practical way to provide access control for complex systems. Even smaller institutions will benefit from an organized approach. This approach is possible in Windows Server 2003 by using built-in and custom groups. Instead of addressing each user's needs, define typical user roles in the organization and create a set of access rights and object permissions for each role. Create a user group to represent the role and then give that group the defined rights and object permission. Assign users to group memberships that represent the roles they have been assigned.

Group Types and Membership

Group types are the group roles that exist on the server. On a standalone server, a server that is not joined in a domain, all groups are local groups and can only give rights and privileges on the local server. Groups created on a standalone server or as local groups on a member server are also local groups. The local group account is stored in the local Security Account Manager (SAM). The following group types are found in Windows Server 2003:

Default or built-in groups are those groups that exist on the server when it is installed.

Service-related groups are those that are created when a service is added, such as the DNSProxy group, which is added when the DNS service is installed.

Domain groups are groups such as Domain Admins and Enterprise Admins that are added when a server is promoted to domain controllers. They can contain domain accounts.

Local groups are groups whose accounts lie in the local SAM of a server. They are local to that server.

Universal groups are groups that can only be created in a forest and may contain accounts from any domain in the forest.

Special identities or implicit groups are those groups that represent some activity. For example, the Network group is composed of all users who are connected to the computer over the network, while the Interactive group is the group composed of all users logged on at the console.

Group scope defines where a group may be granted access and what user and group types may be granted group membership. Group scope and group membership type can change based on the domain functional mode. The domain functional mode defines the operating system type allowed for domain controllers. More information on domain functional mode is available in Chapter 8, "Trust."

Built-In Groups on a Standalone Server

On a standalone server, the built-in group accounts divide the administrative role on the computer. Each group has its own assigned user rights. Table 3-4 lists and defines user groups.

Implicit Groups

Implicit groups are those groups that are composed of users or computers that are performing some function on a system. A user becomes a member of one of these groups, not because he explicitly has his account entered in the group by an administrator, but because of his current activity. Many of these groups are present in all versions of Windows based on NT technologies, and their membership is defined the same. However, the Windows Server 2003 Everyone group no longer contains the anonymous user. In Windows Server 2003, however, while not recommended, it is possible to add the Anonymous user to the Everyone groups. Adding the Anonymous group to the Everyone group provides access that should not be given to an entity that has been able to access the computer without credentials. Implicit groups are defined in Table 3-5.

NOTE: EVERYONE Includes ANONYMOUS

Earlier versions of Windows included the EVERYONE group in the access token created for the ANONYMOUS logon. This created a security vulnerability because many folder, file, and other object permissions are granted to the group EVERYONE. Windows Server 2003 does not include the ANONYMOUS logon in the EVERYONE group and therefore reduces the attack surface. However, because some legacy application may require this setting, you can change it by using a Security Option or editing the registry. If you need to evaluate this setting, you can access it by viewing the registry value HKLM\SYSTEM\CurrentControlSet\Control\LSA EveryoneIncludesAnonymous. If this value is set to 0 (the default), the EVERYONE SID is not included in the ANONYMOUS access token. If the value is set to 1, it is.

Group Scope

Group scope determines where the group can be given authority and what type of membership it can have. On a single, standalone Windows Server 2003 server, all groups have local scope. That is, they can only be assigned user rights and access to local objects, and only user accounts that are local to the server can be added to these groups. A local user account on one computer cannot be given rights or granted access to objects on another computer. To access resources on a remote computer, a user needs an account on that remote computer.Chapters 7 and 8.

Figure 3-15 shows the Locations dialog box reached from the Security tab on a folder of a standalone server. The Security tab is used to assign access to users and groups. You can only choose the local computer as the source for groups and users on a standalone server. If, however, the server is joined to a domain and the Security tab is reviewed, the Locations box can be changed to show the local server or the domain as the source for groups and users who may be granted access.

Managing Users and Groups

On a standalone server, users and groups are managed from the Computer Management console. Users and groups can be added, modified, and removed. Users can be granted group membership and can have their passwords reset, and user account properties can be modified.

User and Group Procedures

Performing modifications to users and groups is simple. Understanding when to add, remove, or edit groups and users is not. While it is important to know how to work with users and groups, it is more important that you understand how to use them properly.

Create a New Group

To create a new group, follow these steps:

Adding a New User

To add a new user, follow these steps:

To change account information, make changes to the General page of the user account property pages.

Removing a User or Group

To remove a user or group, complete the following steps:

Restricting and Provisioning a User Account Using a Logon Script

A logon script can be written to further restrict a user's actions, to configure registry settings on the computer, or to provide additional access by mapping drives or printers. When properly configured, the logon script will run when a user logs on to a computer using a local account. (When a domain account is used, the local account logon script does not run because there is no association with the local account. Local and domain accounts are separate entities.) To utilize logon scripts, configure the user's profile and logon script location on the server.

In a domain, logon scripts must be stored in the shared NETLOGON folder or in subfolders beneath that share. When logon scripts are implemented using GPOs, the scripts are stored in the NETLOGON share located at Windows\SYSVOL\sysvol\domainname\SCRIPTS.