Granting Rights and Permissions Using Groups

Granting Rights and Permissions Using Groups

In Windows NT, Windows 2000, and Windows XP, the capabilities granted to accounts are comprised of two areas: rights and permissions. Rights are actions or operations that an account can or cannot perform. Permissions define which resources accounts can access and the level of access they have. Resources include Active Directory objects, file system objects, and registry keys. Although accounts are the central unit of security in Windows NT, Windows 2000, and Windows XP, assigning rights and permissions directly to accounts is difficult to manage and troubleshoot and frequently leads to misapplication of rights and permissions. Consequently, rights and permissions should not be assigned directly to accounts; rather, they should be assigned to groups, and accounts should be placed into groups. Creating a structure of groups to assign rights and permissions is an essential part of securing Windows NT, Windows 2000, and Windows XP.

User Rights and Permissions

The actions an account can perform and the degree to which a user can access information are primarily determined by user rights and permissions. Accounts receive rights and permissions either by having the right or permission assigned directly to the account, or through membership in a group that has been granted the right or permission.

User Rights

Administrators can assign specific rights to group accounts or to individual user accounts. These rights authorize users to perform specific actions, such as logging on to a system or backing up files and directories. User rights are different than permissions: user rights apply to accounts, and permissions are attached to objects (such as printers or folders). Two types of user rights exist:

• Privileges

  A right assigned to an account and specifying allowable actions on the network. An example of a privilege is the right to back up files and directories.

• Logon rights

  A right assigned to an account and specifying the ways in which the account can log on to a system. An example of a logon right is the right to log on to a system locally.

Privileges

Some privileges can override permissions set on an object. For example, a user logged on to a domain account as a member of the Backup Operators group has the right to perform backup operations for all domain servers. However, this requires the ability to read all files on those servers, even files whose owners have set permissions that explicitly deny access to all users, including members of the Backup Operators group. A user right in this case, the right to perform a backup takes precedence over all file and directory permissions. The following list shows the privileges that can be granted to an account by assigning user rights. These privileges can be managed with the user rights policy settings in Group Policy.

• Act As Part Of The Operating System

  Allows a process to authenticate as any user, and therefore gain access to resources under any user identity. Only low-level authentication services should require this privilege. The user or process that is granted this privilege might create security tokens that grant more rights than their normal security contexts provide. This could include granting the user or process access as an anonymous user, which defeats attempts to audit the identity of the token s user. Do not grant this privilege unless you are certain it is needed.

• Add Workstations To A Domain

  Allows the user to add computers to a specific domain, beyond the default limit of 10 in Active Directory and the default limit of 0 in Windows NT.

• Back Up Files And Directories

  Allows the user to circumvent file and directory permissions to back up the system. Specifically, this privilege is similar to granting the following permissions on all files and folders on the local computer: Traverse Folder/Execute File, List Folder/Read Data, Read Attributes, Read Extended Attributes, and Read Permissions.

• Bypass Traverse Checking

  Allows the user to pass through directories to which she otherwise has no access, while navigating an object path in any Windows file system or in the registry. This privilege does not allow the user to list the contents of a directory, only to traverse directories, which is often needed to successfully browse Web sites or file shares.

• Change The System Time

  Allows the user to set the time in the internal clock of the computer.

• Create A Token Object

  Allows a process to create a token that it can then use to gain access to local resources when the process uses NtCreateToken() or other token-creation APIs.

• Create Permanent Shared Objects

  Allows a process to create a directory object in the Windows 2000 Object Manager. This privilege is useful to kernel-mode components that plan to extend the Windows 2000 object namespace. Because components running in kernel mode already have this privilege assigned to them, it is not necessary to specifically assign this privilege.

• Create A Pagefile

  Allows the user to create and change the size of a pagefile. This is done by specifying a paging file size for a given drive in the Performance Options dialog box, which is accessible through the System Properties dialog box.

• Debug Programs

  Allows the user to attach a debugger to any process. Without this privilege, you can still debug programs that you own. This privilege provides powerful access to sensitive and critical system operating components you should not grant this permission to anyone unless you have clear business reasons to do so.

• Enable Trusted For Delegation On User And Computer Accounts

  Allows the user to select the Trusted For Delegation setting on a user or computer object. The user or object that is granted this privilege must have Write access to the account control flags on the user or computer object. A server process either running on a computer that is trusted for delegation or being run by a user who is trusted for delegation can access resources on another computer. The process uses a client s delegated credentials, as long as the client account does not have the Account Cannot Be Delegated account control flag set. Misuse of this privilege or of the Trusted For Delegation settings might make the network vulnerable to sophisticated attacks using Trojan horse programs that impersonate incoming clients and use their credentials to gain access to network resources.

• Force Shutdown Of A Remote System

  Allows a user to shut down a computer from a remote location on the network.

• Generate Security Audits

  Allows a process to generate entries in the security log for auditing of object access. The process can also generate other security audits. The security log is used to trace unauthorized system access.

• Increase Quotas

  Allows a process with Write access to another process to increase the processor quota assigned to that other process. This privilege is useful for system tuning but can be abused in a denial-of-service attack.

• Increase Scheduling Priority

  Allows a process with Write access to another process to increase the execution priority of that other process. A user with this privilege can change the scheduling priority of a process through the Task Manager.

• Load And Unload Device Drivers

  Allows a user to install and uninstall Plug and Play device drivers. Device drivers that are not Plug and Play are not affected by this privilege and can be installed only by administrators. Because device drivers run as trusted (highly privileged) programs, this privilege can be misused to install hostile programs and give these programs destructive access to resources.

• Lock Pages In Memory

  Allows a process to keep data in physical memory, preventing the system from paging the data to virtual memory on disk. Exercising this privilege might significantly affect system performance. This privilege is obsolete and is therefore never used by default.

• Manage Auditing And Security Log

  Allows a user to specify object access auditing options for individual resources such as files, Active Directory objects, and registry keys. Object access auditing is not performed unless you have enabled the audit policy settings that enable object auditing. A user with this privilege can also view and clear the security log from the Event Viewer.

• Modify Firmware Environment Values

  Allows modification of the system environment variables, either by a process or by a user through the System Properties dialog box.

• Profile A Single Process

  Allows a user to use Windows NT and Windows 2000 performance-monitoring tools to monitor nonsystem processes.

• Profile System Performance

  Allows a user to use Windows NT and Windows 2000 performance-monitoring tools to monitor system processes.

• Remove A Computer From Docking Station

  Allows a user to undock a portable computer through the user interface.

• Replace A Process-Level Token

  Allows a process to replace the default token associated with a subprocess that has been started.

• Restore Files And Directories

  Allows a user to circumvent file and directory permissions when restoring backed up files and directories, and to set any valid security principal as the owner of an object.

• Shut Down The System

  Allows a user to shut down the local computer.

• Take Ownership Of Files Or Other Objects

  Allows a user to take ownership of any securable object in the system, including Active Directory objects, files and folders, printers, registry keys, processes, and threads.

Logon Rights

Logon rights are assigned to users and specify the ways in which a user can log on to a system. The following list describes the various logon rights:

• Access This Computer From A Network

  Allows a user to connect to the computer over the network. By default, this privilege is granted to the Administrators, Everyone, and Power Users groups.

• Deny Access To This Computer

  Denies a user the ability to connect to the computer over the network. By default, this privilege is not granted to anyone. Use caution when setting this privilege because it is possible to lock yourself out of the system.

• Log On As A Batch Job

  Allows a user to log on using a batch-queue facility. By default, this privilege is granted only to Administrators.

• Deny Logon As A Batch Job

  Denies a user the ability to log on using a batch-queue facility. By default, this privilege is granted to no one.

• Log On As A Service

  Allows a security principal to log on as a service to establish a security context. The LocalSystem account always retains the right to log on as a service. Any service that runs under a separate account must be granted this right. By default, this right is not granted to anyone.

• Deny Logon As A Service

  Denies a security principal the ability to log on as a service to establish a security context. The LocalSystem account always retains the right to log on as a service. Any service that runs under the security context of a user account must be granted this right. By default, this right is not granted to any accounts.

• Log On Locally

  Allows a user to log on at the computer s keyboard via a Terminal Services session and through IIS. By default, this right is granted to the Administrators, Account Operators, Backup Operators, Print Operators, and Server Operators groups. Use caution when setting this privilege because it is possible to lock yourself out of the system.

• Deny Logon Locally

  Denies a user the ability to log on at the computer s keyboard. By default, this right is granted to no one. Use caution when setting this privilege because it is possible to lock yourself out of the system.

Active Directory, File, and Registry Permissions

Active Directory, file, and registry permissions are granted by using discretionary access control lists, or DACLs. You grant permissions to objects by creating an access control entry (ACE) for the account, or for a group that the account is a member of. File and registry permissions are discussed in depth in Chapter 7, Securing Permissions.

Group Types and Scope

Windows NT, Windows 2000, and Windows XP enable you to organize users and other domain objects into groups to manage rights and permissions. Defining security groups is a major requirement for securing a distributed network.

You can assign the same security permissions to large numbers of accounts in one operation by using security groups. This ensures consistent rights and permissions for all members of a group. Using security groups to assign rights and permissions also means that the access control lists (ACLs) on resources will remain fairly static and will be much easier to control and audit. User accounts that require access to a specific resource are added or removed from the appropriate security groups as needed so that the ACLs change infrequently, are smaller, and are easier to interpret.

Special Groups

There are some groups whose membership even administrators cannot manage these groups are called special groups. Membership in a special group is granted to accounts automatically, as a result of their activity on the machine or network. It is essential that you understand how these groups function because they are often misused and can seriously impact your network s security if not properly implemented. This next list describes all the special groups in Windows NT, Windows 2000, and Windows XP:

• Anonymous Logon

  Used for network logons for which credentials are not provided. Anonymous logons cannot be used interactively.

• Authenticated Users

  Any account, with the exception of the Guest and Anonymous accounts, that has been authenticated by a trusted domain controller or the local computer. This identity provides accounts with the rights necessary to operate the system as an end user.

• Creator Group

  Used as a placeholder in an inheritable ACE. When the ACE is inherited, the system replaces this SID with the SID for the primary group of the object s current owner.

• Creator Owner

  Used as a placeholder in an inheritable ACE. When the ACE is inherited, the system replaces this SID with the SID of the object s current owner.

• Dialup

  Used for accounts connected to the computer over a dial-up connection.

• Everyone

  Contains all users who access the computer, including Guests and Users from other domains. In Windows NT and Windows 2000, the Everyone group includes Authenticated Users, Guests, and Anonymous logons. In Windows XP, the Everyone group does not include Anonymous logons.

• Interactive

  Used for accounts that have logged on at console through Terminal Services or through IIS.

• Network

  Used for accounts that have logged on over the network.

• Remote Interactive Logon (Windows XP only)

  Used for users who have logged on to the computer by using a Remote Desktop connection.

• Terminal Server User

  Used for users who have logged on to the computer by using a terminal server session.

• Batch

  Batch processes that are accessing resources on the computer.

• Local Service (Windows XP only)

  Services that are local to the computer have no need for extensive local privileges and do not need authenticated network access. A service running as Local Service has significantly less authority than a service running as System (discussed in a moment), both locally and on the network. When services running as Local Service access local resources, they do so as members of the local Users group. When they access network resources, they do so as Anonymous users.

• Network Service (Windows XP only)

  Services that have no need for extensive local privileges but do need authenticated network access. A service running as Network Service has the same network access as a service running as System, but has significantly reduced local access. When services running as Network Service access local resources, they do so as members of the local Users group. When they access network resources, they do so using the SID assigned to the computer.

• Service

  Used by services.

• System

  Used to represent the operating system itself.

• Enterprise Domain Controllers (Windows 2000 only)

  All domain controllers in the forest.

• Restricted (Windows XP only)

  Used by a process that is executing in a restricted security context, such as running an application with the RunAs service. When code executes at the restricted security level, the Restricted SID is added to the user s access token.

• Self

  A placeholder in an ACE on a user, group, or computer object in Active Directory. When you grant permissions to Self, you grant these permissions to the security principal represented by the object. During an access check, the operating system replaces the SID for Self with the SID for the security principal represented by the object.

Special groups are used to manage the rights and restrictions that apply to users based on the type of logon session they have initiated. For example, suppose you want a user named Alice to have access to a certain file or share but only when she is logged on interactively. You can accomplish this by allowing Alice access to the resource but denying access to requests accompanied by access tokens that include the Dialup security principal.

Computer Local Groups

Computer local groups are security groups that are specific to a computer and are not recognized elsewhere in the domain or on other computers. These groups are a primary means of managing rights and permissions to resources on a local computer. Several types of built-in local groups exist by default on Windows NT, Windows 2000, and Windows XP computers. Figure 3-2 shows local accounts in the Computer Management Microsoft Management Console (MMC) in Windows 2000 Server.

Figure 3-2. Local accounts

No local accounts on domain controllers exist in Windows NT 4.0 and Windows 2000. Windows 2000 has a local administrator account called the Directory Services Restore Administrator. This account is stored in a normally inaccessible local SAM and can be viewed, used, and managed only when the computer is interactively booted into Directory Services Restore Mode.

The computer local groups follow:

• Administrators

  The built-in Administrator account is the only default member of this group. If the computer is added to a domain, the Domain Admins group is added to the local Administrators group, making all members of the Domain Admins group local administrators on all computers in the domain. Local administrators have complete control over all local resources, including accounts and files. Membership in the local Administrators groups should be limited to only those accounts that require this level of access.

• Backup Operators

  Members of the Backup Operators group can back up and restore files on the local computer, regardless of the permissions that protect those files, including files and folders encrypted using the EFS. Members of this group can also log on to the computer interactively and shut it down. However, Backup Operators cannot change security settings. By default, the Backup Operators group has no members.

• Guests

  By default, members of the Guests group are denied access to the application and system event logs. Otherwise, members of the Guests group have the same access rights as members of the Users group. Members of the Guests group can also shut down the computer on Windows 2000 and Windows XP client computers. By default, the only member of this group is the built-in Guest account, which is disabled by default.

• Power Users

  Although members of the Power Users group have less system access than Administrators but more than Users, they should be considered Administrators for security purposes because they can generally elevate their privileges to become Administrators.

  The default Windows 2000 and later security settings for Power Users are backward compatible with the default security settings for Users in the Windows NT 4.0 operating system. This allows Power Users to run legacy applications that are not certified for Windows 2000 and Windows XP Professional and therefore cannot be run under the more secure Users context. In a secure environment, you should investigate how to run applications under the Users context, rather than making all users members of the Power Users group. Power users can perform many systemwide operations, such as changing system time and display settings, and creating user accounts and shares. Power users also have Modify access to the following:

  • HKEY_LOCAL_MACHINE \Software

  • Program files

  • %windir%

  • %windir%\system32

    If nonadministrators gain permissions to modify files in the %windir%\system32 folder, they can take control of the operating system by replacing the operating system files with malicious files. This is one reason that members of the Power Users group must be considered local administrators for all intents and purposes.

• Replicator

  Members of the Replicator group are allowed to replicate files across a domain. This group is not used in Windows 2000 and Windows XP. By default, this group contains no members.

• Users

  Members of the Users group have limited access on the system. By default, members of the Users group have Read/Write permissions only to their own profiles. User security settings are designed to prohibit members of the Users group from compromising the security and integrity of the operating system and installed applications. Users cannot modify computerwide registry settings, operating system files, or program files, and they cannot install applications that can be run by other users. As a result, the Users group is secure to the extent that members cannot run viruses or Trojan horse applications that affect the operating system or other users of the operating system.

• HelpServicesGroup (Windows XP only)

  Members of the Help ServicesGroup group can use helper applications to diagnose system problems. This group, in conjunction with the Support and HelpAssistant accounts (whose names are appended with a random number to ensure their uniqueness on each computer), can be used by members of Microsoft Help and Support Center to access the computer from the network and to log on locally. The built-in Support account is the only default member of this group.

• Network Configuration Operators (Windows XP only)

  Members of the Network Configuration Operators group have limited administrative privileges that allow them to configure networking features, such as IP address configuration of the machine s network adapters. By default, this group contains no members.

• Remote Desktop Users (Windows XP only)

  The Remote Desktop Users group enables members to log on remotely by using Remote Desktop Services. By default, this group contains no members.

In addition to the built-in groups, you can create additional computer local groups that fit the security needs of your organization. You can add global groups from any trusted domain to local groups to grant rights and permissions to local resources. You cannot add computer local groups from one computer to computer local groups on another computer.

See Writing Secure Code, Second Edition by Michael Howard and David LeBlanc (Microsoft Press, 2003) for more information on determining the rights and permissions required to run applications.

Built-In Domain Groups

Just as built-in computer local groups exist on all computers, built-in groups also exist in Active Directory and Windows NT 4.0 domains. These built-in groups have predelegated rights and permissions. These are the built-in domain groups:

• Administrators

  Just as the computer local group Administrators has complete control over local resources, members of the built-in domain group Administrators have complete control over all resources in the domain. The Domain Admins global group (discussed momentarily) gets its rights and permissions by having membership in this group. When a computer joins the domain, the Domain Admins group is automatically added to this group. Similarly, in Windows 2000, the Enterprise Admins global group (also discussed momentarily) gets much of its authority because it is a member of this group on every domain controller in the forest.

• Backup Operators

  Members of the domain built-in Backup Operators group can back up and restore files and folders, regardless of permissions and encryption, on computers throughout the domain. Backup Operators can also log on locally and shut down servers, including domain controllers.

• Server Operators

  Members of the Server Operators group can manage resources on the local server, and they have the ability to perform the following tasks:

  • Log on locally and lock, unlock, and shut down the server

  • Create, manage, and delete shared folders

  • Create, manage, and delete printers

  • Back up and restore files and folders

• Account Operators

  Members of the Account Operators group can manage user accounts and groups but cannot manage accounts that are members of Administrators, Domain Admins, Server Operators, Backup Operators, Print Operators, and Account Operators. Nor can they change the membership of these groups. Account Operators can also log in locally and shut down servers, including domain controllers.

  Because of the ability to delegate authority on a granular level in Active Directory, the Server Operators and Account Operators groups should be used only for compatibility with Windows NT.

• Print Operators

  Members of the Print Operators group can manage printers and print jobs. Print Operators can also log in locally and shut down servers, including domain controllers.

• Pre-Windows 2000 Compatible Group (Windows 2000 only)

  The Pre-Windows 2000 Compatible group is granted permissions in ACLs on objects in Active Directory. When the first domain controller for each domain is promoted, the DCPROMO Wizard asks whether you want to use this group. If you enable pre-Windows 2000 compatibility, the Everyone group will be made a member of the Pre-Windows 2000 Compatible group. This setting is particularly relevant to a domain operating in mixed mode with Windows NT 4.0 backup domain controllers (BDCs) that are also Remote Access Service (RAS) servers. You should not place any members in this group unless you have a clear business or technical requirement to do so.

The domain built-in groups Replicator, Guests, and Users also exist in Active Directory and Windows NT 4.0 domains and function just as their computer local built-in groups, but with a scope that includes all computers in the domain.

Domain Local Groups

Domain local groups exist in the Windows 2000 domains group after the domain has been converted to native mode. These groups can contain members from anywhere in the forest, trusted forests, or a trusted pre-Windows 2000 domain. Domain local groups can be used only to grant permissions to resources on machines that are members of the domain in which they exist.

Global Groups

Global groups in Windows 2000 and Windows NT 4.0 domains can contain accounts from their own domain and can be used to populate ACLs in all trusted domains. In Windows 2000, once a domain is converted to native mode, global groups can be nested that is, they can contain other global groups from the same domain. Global groups never contain accounts or global groups from other domains, regardless of whether the domain is in mixed mode or native mode. Active Directory and Windows NT domains contain several built-in global groups:

• Domain Admins

  Members of the Domain Admins group have complete control over all objects in the domain. The Domain Admins group is also a member of the local Administrators group on all computers in the domain. Membership in this group should be kept to a minimum.

• Enterprise Admins (Windows 2000 only)

  Members of the Enterprise Admins group have complete control of all objects in the forest. Enterprise Admins are members of all the built-in domain local Administrators groups in each domain in the forest. Enterprise Admins can also manage all objects not associated with any single domain, such as the objects in the Configuration container. Membership in the Enterprise Admins group on most networks will contain from zero to five accounts. The Enterprise Admins group is changed from a global group to a universal group when the forest root domain is converted to native mode.

• Schema Admins (Windows 2000 only)

  Members of the Schema Admins group can create classes and attributes in the schema as well as manage the schema master flexible single-master operation (FSMO). By default, the Schema Admins group contains no members. Only members of the Enterprise Admins group can add and remove accounts from the Schema Admins group. The Schema Admins group is changed from a global group to a universal group when the forest root domain is converted to native mode.

• RAS and IAS Servers (Windows 2000 only)

  Members of the RAS and IAS Servers group can manage Remote Access policies, Routing and Remote Access Server (RRAS), and Internet Authentication Service (IAS) on all RRAS servers in the domain. By default, this group contains no members.

• Group Policy Creator Owners

  Members of the Group Policy Creator Owners group can fully manage all group policy in the domain. Because this group can control security policies by deploying or removing the deployment of Group Policy objects (GPOs), membership should be minimal to nonexistent. By default, this group contains no members.

Universal Groups

Once you convert an Active Directory domain to native mode, you can use universal security groups. As with global groups, you can use universal groups in any trusted domain. However, universal groups can have members from any domain in the forest. Because of this forestwide scope, membership in universal groups is stored in the Global Catalog. The Global Catalog is fully replicated throughout the forest, which means that universal group membership should be kept fairly static, especially on forests where convergence does not occur quickly.

Implementing Role-Based Security in Windows 2000

All rights and permissions in Windows NT, Windows 2000, and Windows XP are granted on a discretionary basis meaning that any account with Full Control, Change Permissions, or Take Ownership permissions can grant or deny permissions on the object to other security principals. In order to create a secure network, you should create a structure for granting rights and permissions that is scalable, flexible, manageable, and above all else, secure. By using a role-based structure for granting rights and permissions, you can control access to information in this manner. In a role-based structure, rights and permissions are never granted or denied to specific accounts, but instead to groups based on job roles or functions.

To implement role-based security for access control, each type of group is used for a specific purpose to create a discrete separation of the account and the assignment of permissions, based on the job function or role of the user. Create domain local groups or local groups, and assign them permissions to resources. Create global groups based on job function or role. Place the global groups in the appropriate domain local groups or local groups, and place users in the appropriate global group. This process is shown in Figure 3-3. A convenient way to remember this process is by using the mnemonic A-G-DL-P. Accounts are placed into global groups, global groups are placed into domain local groups, and permissions are assigned to domain local groups.

Figure 3-3. Implementing role-based security in Windows 2000

Domain local groups and local groups are assigned permissions to resources based on the permission needed on the resource. For example, a payroll server can use the following group payroll folders:

• Payroll_data_Read

• Payroll_data_Modify

• Payroll_data_FC

  Because the icon for domain local, local, and global groups is the same in the user interface, you need to use a meaningful naming convention for group names. Often, lowercase letters are used for domain local group names and local group names, and uppercase letters are used for global group names. Another strategy is to preface each group name with its type, such as DL_groupname and GG_groupname. Doing this will arrange the groups by type when they are alphabetized in the user interface.

Global groups are created based on job functions or roles. In Windows 2000, after converting to native mode, global groups can be placed in other global groups to further stratify the A-G-DL-P model into A-G-G-DL-P. For example, a payroll department could contain the following global groups:

• PAYROLL_MGRS

• PAYROLL_ADMINS

• PAYROLL_USERS

Now suppose all payroll managers require Modify rights on the payroll data. After ensuring that payroll managers are members of the PAYROLL_MGRS group, place the group in the Payroll_Modify domain local group. All payroll managers will have Modify access on the payroll information.

Universal Groups vs. Global Groups

Once in native mode, Active Directory adds the ability to use universal groups. When should you use universal groups for security purposes?

First, you can use universal groups when two resources with the same security needs exist in many domains in the forest and users for these resources exist in many domains in the forest. You cannot gracefully achieve this many-to-many mapping without using universal groups. For example, suppose a forest has an empty root domain and four child domains. Each of these domains has a payroll server for the payroll department that uses domain local groups to assign permission to payroll data. Each domain has a global group for payroll managers containing all the payroll managers from the domain. Instead of adding all four payroll manager groups to servers in all four domains, you create a universal group called All_Payroll_Managers and add the payroll managers global group from each domain into it. Place this group in the appropriate domain local groups on the payroll servers. By doing this, you will have significantly fewer groups to manage and simpler ACLs on resources. When using universal groups, the role-based security structure is A-G-U-DL-P.

Second, you can use universal groups when assigning permissions to Active Directory objects in a multiple domain forest. The role-based security structure to use in this scenario is A-G-U-P, or simply, A-U-P. You will need to do this because objects either will need to move between domains or will not be owned by any specific domain, such as objects in the Configuration container.

The benefits of using a role-based security structure include the following:

• Groups are segmented in discrete areas. Only domain local groups or local groups have permissions assigned to them and contain only global groups or universal groups. Moreover, global groups contain only accounts or other groups.

• Permissions are close to the resources, not the account. This enables resource administrators to be able to control security over the resource, without significant access to accounts.

• When users transfer jobs or are terminated, permissions are not tied to their user accounts, making permission reassignment or removal simpler.

• Permissions can be mapped and traced easily.

• Permissions are controlled by group management, not by changing permissions on resources, making audit logs much easier to read and manage.

• Permissions scale as the number of users increases and the frequency of changes to user accounts increases.

• Authorization can be implemented by assigning the resource owners the sole management of domain local groups or local groups with permission to the resources that they manage.