Tài liệu Windows Server 2008 Inside Out- P25 pptx

In Active Directory, the domain user account contains user name, password, the groups of which the user is a member, and other descriptive information, such as address and phone numbers,

As an administrator, managing users, groups, and computers will probably be a sig-nifi cant part of your duties and responsibilities Managing users, groups, and com-puters encapsulates the important duties of a system administrator because of the way you must balance convenience, performance, fault tolerance, and security

Managing Domain User Accounts

The next part of this chapter is dedicated to helping you plan, manage, and administer user accounts in a secure and effi cient manner Microsoft Windows operating systems have come a long way since the early days of Windows Server and you have many options for managing users in Windows Server 2008

Types of Users

It is a good idea to have a solid grasp of fundamental concepts that underpin the managing of users In the fi rst part of the chapter, I will describe the types of users Microsoft Windows Server 2008 defi nes

User In Windows Server 2008, you can have local user accounts or domain user accounts On a domain controller, local users and groups are disabled In Active Directory, the domain user account contains user name, password, the groups of which the user is a member, and other descriptive information, such as address and phone numbers, as well as many other user descriptions and attributes, such

as security and remote control confi gurations

InetOrgPerson InetOrgPerson is a type of user introduced in Windows Server

2003 InetOrgPerson has attributes based on Request for Comments (RFC) 2798, such as vehicle license number, department number, display name, employee number, JPEG photograph, and preferred language Used by X.500 and Light-weight Directory Access Protocol (LDAP) directory services, the InetOrgPerson account is used when you migrate non-Microsoft LDAP directories to Active Directory Derivative of the user class, the InetOrgPerson can be used as a secu-rity principal The InetOrgPerson is compatible with X.500 and LDAP directory services

Managing Domain User Accounts 1167

Managing User Profiles 1195

Managing User Data 1203

Maintaining User Accounts 1210

Managing Groups 1215

Managing Computer Accounts 1225

Managing Users, Groups, and Computers

Contact Sometime you may want to create an account that will only be used as

an e-mail account This is when you would create a contact It is not a security principal and does not have a security identifi er (SID) There are neither pass-words nor logon functionality available with a contact account However, it can

be a member of a distribution group

Default user accounts These are the built-in user accounts created when a Windows Server 2008 installation or stand-alone server is confi gured to be a domain controller and Active Directory is installed It is a good idea to rename the Administrator account for security reasons The default user accounts are found by opening Active Directory Users And Computers, then examining the contents of the Builtin and Users containers They include the following accounts:

Administrator This is the account that has full control over the computer

or domain You should have a very strong password for this account The Administrator is a member of these groups: Administrators, Domain Admins, Domain Users, and Group Policy Creator Owners In a forest root domain, the Administrator is also a member of the Enterprise Admins and Schema Admins groups The Administrator account can never be deleted However, you can disable it or rename it Either of these actions is a good practice to ensure a secure domain and network

Guest The Guest account can be used by users who don’t have an account

in the domain It is a member of the Guests domain local group and the Domain Guests global group The Guest account is disabled by default when you make a stand-alone Windows Server 2008 server a domain controller

Naming User Accounts

Think about the naming scheme you plan to use for user accounts As the organization changes and grows, the original naming scheme may need to change but not the need for a naming scheme of some kind Although account names for operating systems ear- lier than Windows 2000 are limited to 20 characters for a user name, Windows Server

2003 and Windows Server 2008 have a 256-character limitation for a user name

Small organizations commonly use a person’s fi rst name and last name initial for their user account In a larger organization, it may be a better idea to use their full name for their user account name For example, in a small organization, John Smith could have a user name of JohnS However, in a larger organization, John Smith should have a user- name of JohnSmith

This becomes a problem when an organization has more than one John Smith who needs a user account Full names are likely to be an issue; using middle name initials can solve it However, administrators may implement a numbering system For exam- ple: JSmith1, Jsmith2 Another naming system uses a dot-delimited scheme, such as John.W.Smith@cpandl.com Regardless of the naming scheme you choose, the key is

to be as consistent as possible and to allow for exceptions as needed Keep in mind that

Naming User Accounts

Think about the naming scheme you plan to use for user accounts As the organization changes and grows, the original naming scheme may need to change but not the need for a naming scheme of some kind Although account names for operating systems ear- lier than Windows 2000 are limited to 20 characters for a user name, Windows Server

2003 and Windows Server 2008 have a 256-character limitation for a user name.

Small organizations commonly use a person’s fi rst name and last name initial for their user account In a larger organization, it may be a better idea to use their full name for their user account name For example, in a small organization, John Smith could have a user name of JohnS However, in a larger organization, John Smith should have a user- name of JohnSmith.

This becomes a problem when an organization has more than one John Smith who needs a user account Full names are likely to be an issue; using middle name initials can solve it However, administrators may implement a numbering system For exam- ple: JSmith1, Jsmith2 Another naming system uses a dot-delimited scheme, such as John.W.Smith@cpandl.com Regardless of the naming scheme you choose, the key is

to be as consistent as possible and to allow for exceptions as needed Keep in mind that

Confi guring User Account Policies

Because domain controllers share the domain accounts database, user account policies must be consistent across all domain controllers The way consistency is ensured is by having domain controllers obtain user account policies only from the domain container and only allowing one top-level account policy for domain accounts The one top-level account policy allowed for domain accounts is determined by the highest precedence Group Policy object (GPO) linked to the domain container This top-level account policy is then enforced by the domain controllers in the domain Domain controllers always obtain the top-level account policy from the highest precedence GPO linked to the domain container By default, this is the Default Domain Policy GPO

When a domain is operating at the Windows Server 2008 functional level, two new object classes in the Active Directory schema allow you to fi ne-tune the way account policy is applied:

Password Settings container Password Settings object The default Password Settings container (PSC) is created under the System container

in the domain, and it stores the Password Settings objects (PSOs) for the domain

Although you cannot rename, move, or delete the default PSC, you can add PSOs to this container that defi ne the various sets of secondary account policy settings you want to use in your domain You can then apply the desired secondary account policy settings

to users, inetOrgPersons, and global security groups as discussed in “Creating word Settings Objects and Applying Secondary Settings” on page 1173

Pass-Local Account Policy Is Used for Pass-Local Log On

Local account policies can be different from the domain account policy, such as when you specifi cally defi ne an account policy for local accounts in a computer’s local GPO (LGPO) For example, if you confi gure an account policy for a computer’s LGPO, when users log on to Active Directory they’ll obtain their account policy from the Default Domain Policy instead of the LGPO The only exception is when users log on locally to their machines instead of logging on to Active Directory; in that case any account policy applied to their machine’s local GPO is applied and enforced

As discussed in Chapter 36, “Managing Group Policy,” account policies in a domain are confi gured through the policy editors accessible from the Group Policy Management Console (GPMC) When you are editing policy settings, you’ll fi nd account policies under Computer Confi guration\Windows Settings\Security Settings\Account Poli-cies To change group policies, you must be a member of the Domain Admins group

or Enterprise Admins group in Active Directory Members of the Group Policy Creator Owners group can also modify group policy for the domain

Local Account Policy Is Used for Local Log On

Local account policies can be different from the domain account policy, such as when you specifi cally defi ne an account policy for local accounts in a computer’s local GPO (LGPO) For example, if you confi gure an account policy for a computer’s LGPO, when users log on to Active Directory they’ll obtain their account policy from the Default Domain Policy instead of the LGPO The only exception is when users log on locally to their machines instead of logging on to Active Directory; in that case any account policy applied to their machine’s local GPO is applied and enforced.

The account policies for a domain contain three subsets—Password Policy, Account Lockout Policy, and Kerberos Policy Although secondary account policies include Pass-word Policy and Account Lockout Policy, they do not include Kerberos Policy Kerberos Policy can only be set at the domain level for the top-level account policy

Some Security Options Are Also Obtained from the Default Domain Policy GPO

Two policies in Computer Confi guration\Windows Settings\Security Settings\Local cies\Security Options also behave like account policies These policies are Network Access: Allow Anonymous SID/NAME Translation and Network Security: Force Logoff When Logon Hours Expire For domain accounts, the settings for these policies are obtained only from the Default Domain Policy GPO For local accounts, the settings for these policies can come from a local OU GPO if one is defi ned and applicable

Poli-Enforcing Password Policy

Password policies for domain user accounts and local user accounts are very tant in preventing unauthorized access These settings should help enforce your organization’s written computing policies There are six settings for password policies that enable you to control how passwords are managed When you are setting top-level account policy for the Default Domain Policy, these policies are located in Computer Confi guration\Windows Settings\Security Settings\Account Policies\Password Policy (see Figure 35-1) When you are setting secondary account policy for a PSO, you confi g-ure these settings using similarly named object attributes

impor-Figure 35-1 Managing Password Policy in the Default Domain Policy

The settings are as follows:

Enforce Password History When users change their passwords, this setting mines how many old passwords will be maintained and associated with each

deter-Some Security Options Are Also Obtained from the Default Domain Policy GPO

Two policies in Computer Confi guration\Windows Settings\Security Settings\Local cies\Security Options also behave like account policies These policies are Network Access: Allow Anonymous SID/NAME Translation and Network Security: Force Logoff When Logon Hours Expire For domain accounts, the settings for these policies are obtained only from the Default Domain Policy GPO For local accounts, the settings for these policies can come from a local OU GPO if one is defi ned and applicable.

kept On a domain controller, the default is 24 passwords, on a stand-alone server,

it is zero passwords

Maximum Password Age This determines when users are required to change their passwords For example, if this is set to 90 days, on the 91st day the user will be required to change his or her password The default on domain control-lers is 42 days The minimum number of days is 0, which effectively means that the password never changes The maximum number of days is 999 In an envi-ronment where security is critical, you probably want to set the value low—in contrast, for environments where security is less stringent, you could set the pass-word age high (rarely requiring users to change passwords)

Minimum Password Age How long users must use passwords before they are allowed to change the password is determined by this setting It must be more than zero days for the Enforce Password History Policy to be effective In an envi-ronment where security is critical, you would probably set this to a shorter time, and to a longer time where security not as tight This setting must be confi gured

to be less than the Maximum Password Age policy The maximum value is 998

If you enter zero (0), a password can be changed immediately The default is 1 day on a domain controller and 0 days on stand-alone servers This setting helps

to deter password reuse by making a user keep a password for at least a certain amount of time

Minimum Password Length This is the number of characters that sets the mum requirement for the length of the password Again, a more critically secure environment might require longer password lengths than one with reduced secu-rity requirements The maximum value is 14 If you enter zero (0), a password is not required As shown in Figure 35-2, the default length is seven characters on domain controllers The default is zero characters on stand-alone servers

Password Must Meet Complexity Requirements Complexity requirements for passwords for the domain user accounts are set at a higher requirement than previously in Windows 2000 If this policy is defi ned, passwords can’t contain the user account name, must contain at least six characters, and must consist of uppercase letters, lowercase letters, numerals, and special non-alphabetical char-acters, such as the percentage sign (%) and the asterisk (*) (Complexity require-ments are enabled by default on domain controllers and disabled by default on stand-alone servers for Windows Server 2008.)

Store Passwords Using Reversible Encryption This is basically an additional policy that allows for plain text encryption of passwords for applications that may need it By default, it is disabled on Windows Server 2008 Enabling this policy

is basically the same as storing passwords as plain text and is used when tions use protocols that need information about the user’s password Because this policy degrades the overall security of the domain, it should be used only when necessary

Figure 35-2 Configuring domain user Minimum Password Length in the Default Domain Policy

Confi guring Account Lockout Policy

The Account Lockout Policy is invoked after a local user or a domain user has been locked out of his or her account These settings are designed to help protect user accounts from attacks that involve password guessing or other types of attacks where random passwords are repeatedly entered to try to gain access to an account There are three settings for account lockout policies They are the following:

Account Lockout Duration If a user does become locked out, this setting mines how long the user will be locked out before the user account is unlocked There is no default setting, because this setting is dependent on the Account Lockout Threshold setting The range is from 0 through 99,999 minutes The account will be locked out indefi nitely when this is set to 0 and therefore will require an administrator to unlock it

Account Lockout Threshold This setting determines how many failed attempts

at logon Windows Server 2008 permits before a user will be locked out of the account The range is from 0 to 999 If this setting is 0, the account will never be locked out and the Account Lockout Duration security setting is disabled The default setting is 0

Reset Account Lockout Counter After This setting is the number of minutes after

a failure to log on before the logon counter is reset to zero This must be less than

or equal to the Account Lockout Duration setting if the Account Lockout old policy is enabled The valid range is from 1 to 99,999 minutes

When you are setting top-level account policy for the Default Domain Policy, these policies are located in Computer Confi guration\Windows Settings\Security Settings\Account Policies\Account Lockout Policy When you are setting secondary account

Setting Kerberos Policy

Kerberos is an authentication system designed for secure exchange of information as discussed in “NTLM and Kerberos Authentication” on page 1023 Windows Server

2008 has fi ve settings for Kerberos Policy, which are applied only to domain user accounts The policies can only be set for top-level account policy and are located in Computer Confi guration\Windows Settings\Security Settings\Account Policies\Kerbe-ros Policy They are as follows:

Enforce User Logon Restrictions If you want to validate every ticket session request against the user rights, keep the default setting enabled

Maximum Lifetime For Service Ticket The default is 600 minutes, but this setting must be greater than 10 minutes, and also must be less than or equal to what is confi gured for the Maximum Lifetime For User Ticket setting The setting does not apply to sessions that have already been validated

Maximum Lifetime For User Ticket This is different from the Maximum Lifetime For Service Ticket setting Maximum Lifetime For User Ticket sets the maxi-mum amount of time that a ticket may be used before either a new one must be requested or the existing one is renewed, whereas the Maximum Lifetime For Ser-vice Ticket setting is used to access a particular service The default is 10 hours

Maximum Lifetime For User Ticket Renewal This user account security policy object confi gures the maximum amount of time the ticket may be used The default is seven days

Maximum Tolerance For Computer Clock Synchronization Sometimes tions and servers have different local clock times This setting allows you to con-

worksta-fi gure a tolerance level (defaults to 5 minutes) for this possible difference so that Kerberos authentication does not fail

Note

If you change the Minimum Password Length setting to less than seven characters (the default), you may not be able to create a new user or change a user’s password To work around this limitation, set the password length to seven or higher

Creating Password Settings Objects and Applying Secondary Settings

When you want to fi ne-tune the way account policy is applied, you need to create a Password Settings group and add users, inetOrgPersons, and global security groups as members of the Password Settings group A Password Settings group is simply a global security group that applies the desired secondary PSO rather than the default PSO

Note

If you change the Minimum Password Length setting to less than seven characters (the default), you may not be able to create a new user or change a user’s password To work around this limitation, set the password length to seven or higher.

Afterward, you have to create a Password Settings object with attributes that defi ne the desired policy settings and then link this object to the Password Settings group Before you start, you should consider how you will organize your Password Settings groups In most cases, you’ll want to create Password Settings groups that closely resemble the OUs in your domain To do this, you’ll create Password Settings groups with the same names as your OUs and then add users, inetOrgPersons, and global security groups as members of these groups as appropriate to refl ect the organizational structure of your OUs

You can create the Password Settings group and defi ne its members using Active tory Users And Computers, as discussed in “Managing Groups” on page 1215 By default, only members of the Domain Admins and Schema Admins groups can create PSOs You can create a PSO and set its attributes by completing these steps:

1 Start ADSI Edit by clicking Start, clicking Administrative Tools, and then clicking

ADSI Edit

2 Right-click the ADSI Edit node in the MMC and then select Connect To This

displays the Connection Settings dialog box as shown in the following screen:

3 Choose Default Naming Context in the Select A Well Known Naming Context list

and then click Advanced This displays the Advanced dialog box

4 Select the Specify Credentials check box In the Credentials panel, type the user

name and password of an account that is a member of Schema Admins

5 Click OK to close both open dialog boxes

6 In ADSI Edit, select and then expand the Default Naming Context node, and then

select and expand the CN=System node

7 In the left pane, select the CN=Password Settings Container entry A list of any

previously created Password Settings objects appears in the details pane

8 Right-click the CN=Password Settings Container entry, point to New and then

select Object This starts the Create Object wizard as shown in the following screen:

9 On the Select A Class page, choose msDS-PasswordSettings and then click Next

msDS-PasswordSettings is the internal directory name for PSOs

10 In the Value text box, type the name of the Password Settings group and then

click Next If you are naming your Password Settings groups after your OUs, this should be the name of an OU in your domain

11 In the Value text box, type the precedence order for the group and then click

Next When multiple Password Settings objects apply to a user, the precedence of the group determines which account policy settings are applied A group with a precedence of 1 always has precedence over a group with a lower precedence

12 Set the reversible encryption status for passwords as either false or true and then

click Next In most cases, you’ll want to turn this feature off to ensure passwords are stored with strong encryption

13 Set the password history length and then click Next The maximum value is 24 If

you enter zero (0), a password history is not kept

14 Set the password complexity status for passwords as either false or true and then

click Next In most cases, you’ll want to turn this feature on to ensure users enter complex passwords

15 Set the minimum password length for user accounts and then click Next The

maximum value is 14 If you enter zero (0), a password is not required

16 Set the minimum password age and then click Next The age must be set in

duration format as DD:HH:MM:SS The maximum value is 998:00:00:00 (998 days) If you enter zero (0), a password can be changed immediately

17 Set the maximum password age and then click Next The age must be set in

duration format as DD:HH:MM:SS The maximum value is 999:00:00:00 (999 days) If you enter zero (0), passwords never expire

18 Specify how many failed attempts at logon before a user is locked out and then

click Next The maximum value is 999 If you enter zero (0), accounts will never

be locked

19 Specify the number of minutes after a logon failure before the logon counter is

reset and then click Next The counter time must be set in duration format as DD:HH:MM:SS The maximum value is 69:10:39:00 (99,999 minutes) The valid range is from 1 to 99,999 minutes

20 Specify how long a user will be locked out before the account is unlocked

automatically and then click Next The counter time must be set in duration format as DD:HH:MM:SS The maximum value is 69:10:39:00 (99,999 minutes) The valid range is from 1 to 99,999 minutes

21 Click Finish to create the object with the attributes you’ve defi ned If you’ve made

any mistakes in setting the attribute values, you’ll see an error message regarding this and you can use the Back function to make changes to the previously specifi ed values

22 In ADSI Edit, right-click the PSO you just created and select Properties In the

Properties dialog box, scroll through the list of attributes until you see PSOAppliesTo Select this attribute and then click Edit This opens the Multi-Valued Distinguished Name With Security Principal Editor dialog box

23 Click Add Windows Account This displays the Select Users, Computers, Or

Groups dialog box Type the name of the Password Settings group you previously created using Active Directory Users And Computers and then click Check Names

24 Click OK three times to close all open dialog boxes

Note

You can link a PSO to other types of groups in addition to global security groups ever, when the resultant set of policy is determined for a user or group, only PSOs that are linked to global security groups, user objects, and inetOrgPerson objects are con- sidered PSOs that are linked to distribution groups or other types of security groups are ignored

How-Note

You can link a PSO to other types of groups in addition to global security groups ever, when the resultant set of policy is determined for a user or group, only PSOs that are linked to global security groups, user objects, and inetOrgPerson objects are con- sidered PSOs that are linked to distribution groups or other types of security groups are ignored.

A user, inetOrgPerson, or global security group can have multiple PSOs linked to it This can occur either because of membership in multiple groups that each have different PSOs applied to them or because multiple PSOs are applied directly to the object How- ever, only one PSO is applied as the effective policy and only the settings from that PSO affect the user, inetOrgPerson, or group The settings from other PSOs do not apply and cannot be merged in any way

Active Directory determines the applicable PSO according to the precedence value assigned to its msDS-PasswordSettingsPrecedence attribute This attribute has an integer value of 1 or greater A lower value for the precedence attribute indicates that the PSO has a higher priority than other PSOs For example, suppose an object has three PSOs linked to it One PSO has a precedence value of 5, one has a precedence of 8, and the other PSO has a precedence value of 12 In this case, the PSO that has the precedence value of 5 has the highest priority and is the one applied to the object

If multiple PSOs are linked to a user or group, the PSO that is applied is determined as follows:

1 A PSO that is linked directly to the user object is applied If more than one PSO

is linked directly to the user object, the PSO with the lowest precedence value is applied

2 If no PSO is linked directly to the user object, all PSOs that are applicable to the

user based on the user’s global group memberships are compared and the PSO with the lowest precedence value is applied

3 If no PSO is linked directly or indirectly to the user object, the Default Domain

Policy is applied

Microsoft recommends that you assign each PSO in the domain a unique precedence value However, you can create multiple PSOs with the precedence value If multiple PSOs have the same precedence value, the PSO with the lowest GUID is applied Typically, this means Active Directory will apply the PSO with the earliest creation date

The user object has three attributes that override the settings that are present in the applicable PSO: Reversible Password Encryption Required, Password Not Required, and Password Does Not Expire You can set these attributes in the userAccountControl attri- bute of the user object in Active Directory Users And Computers

Understanding User Account Capabilities, Privileges, and Rights

All user accounts have specifi c capabilities, privileges, and rights When you create a user account, you can grant the user specifi c capabilities by making the user a member

of one or more groups This gives the user the capabilities of these groups You then assign additional capabilities by making a user a member of the appropriate groups or withdraw capabilities by removing a user from a group

SIDE OUT Understanding PSO precedence

A user, inetOrgPerson, or global security group can have multiple PSOs linked to it This can occur either because of membership in multiple groups that each have different PSOs applied to them or because multiple PSOs are applied directly to the object How- ever, only one PSO is applied as the effective policy and only the settings from that PSO affect the user, inetOrgPerson, or group The settings from other PSOs do not apply and cannot be merged in any way.

Active Directory determines the applicable PSO according to the precedence value assigned to its msDS-PasswordSettingsPrecedence attribute This attribute has an integer value of 1 or greater A lower value for the precedence attribute indicates that the PSO has a higher priority than other PSOs For example, suppose an object has three PSOs linked to it One PSO has a precedence value of 5, one has a precedence of 8, and the other PSO has a precedence value of 12 In this case, the PSO that has the precedence value of 5 has the highest priority and is the one applied to the object.

If multiple PSOs are linked to a user or group, the PSO that is applied is determined as follows:

1 A PSO that is linked directly to the user object is applied If more than one PSO

is linked directly to the user object, the PSO with the lowest precedence value is applied.

2 If no PSO is linked directly to the user object, all PSOs that are applicable to the user based on the user’s global group memberships are compared and the PSO with the lowest precedence value is applied

3 If no PSO is linked directly or indirectly to the user object, the Default Domain Policy is applied.

Microsoft recommends that you assign each PSO in the domain a unique precedence value However, you can create multiple PSOs with the precedence value If multiple PSOs have the same precedence value, the PSO with the lowest GUID is applied Typically, this means Active Directory will apply the PSO with the earliest creation date.

The user object has three attributes that override the settings that are present in the applicable PSO: Reversible Password Encryption Required, Password Not Required, and Password Does Not Expire You can set these attributes in the userAccountControl attri- bute of the user object in Active Directory Users And Computers.

In Windows Server 2008, some capabilities of accounts are built in The built-in bilities of accounts are assigned to groups and include the group’s automatic capa-bilities Although built-in capabilities are predefi ned and unchangeable, they can be granted to users by making them members of the appropriate group or delegated by granting the capability specifi cally, for example, the ability to create, delete, and man-age user accounts This capability is assigned to administrators and account operators Thus, if a user is a member of the Administrators group, the user can create, delete, and manage user accounts

Other capabilities of accounts, such as permissions, privileges, and logon rights, can

be assigned The access permissions for accounts defi ne the operations that can be performed on network resources For example, permissions control whether a user can access a particular shared folder You can assign access permissions to users, comput-ers, and groups as discussed in Chapter 17, “File Sharing and Security.” The privileges

of an account grant permissions to perform specifi c tasks, such as the ability to change the system time The logon rights of an account grant logon permissions, such as the ability to log on locally to a server

An important part of an administrator’s job is being able to determine and set sions, privileges, and logon rights as necessary Although you can’t change a group’s built-in capabilities, you can change a group’s default privileges and logon rights For example, you could revoke network access to a computer by removing a group’s right to access the computer from the network Table 35-1 provides an overview of the default privileges assigned to groups Table 35-2 provides an overview of the default logon rights assigned to groups

permis-Table 35-1 Default Privileges Assigned to Groups Privilege Description Groups Assigned by Default in Domains

Act As Part Of The Operating System Allows a process to authenticate as any user Processes that require this privilege

must use the LocalSystem account, which already has this privilege

None

Add Workstations To Domain Allows users to add new computers to an existing domain Authenticated Users Adjust Memory

Quotas For A Process

Allows users to set the maximum amount

of memory a process can use Administrators, Local Service, and Network

Service Back Up Files And

Directories Allows users to back up the system regardless of the permissions set on fi les

and directories

Administrators, Backup Operators, and Server Operators Bypass Traverse

Checking Allows users to go through directory trees even if a user doesn’t have permissions

to access the directories being passed through The privilege doesn’t allow the user to list directory contents

Administrators, Authenticated Users, Everyone, Local Service, and Network Service

Privilege Description Groups Assigned by Default in Domains

Change The System Time Allows users to set the time for the computer’s clock Administrators, Server Operators, and Local

Service Change The Time

Zone Allows users to set the time zone for the system clock Administrators, Server Operators, and Local

Service Create A Pagefi le Allows users to create and modify the

paging fi le size for virtual memory Administrators Create A Token

Object Allows processes to create token objects that can be used to gain access to local

resources Processes that require this privilege must use the LocalSystem account, which already has this privilege

None

Create Global Objects Allows a process to create global directory objects Most components already have

this privilege and it’s not necessary to specifi cally assign it

Administrators, Service, Local Service, and Network Service

Create Permanent Shared Objects Allows processes to create directory objects in the Windows object manager Most

components already have this privilege and it’s not necessary to specifi cally assign it

None

Create Symbolic Link Allows an application that a user is running

to create symbolic links Symbolic links make it appear as if a document or folder

is in a specifi c location when it actually resides in another location Use of symbolic links is restricted by default to enhance security

Permits users and computers to change or apply the trusted account for delegation setting, provided they have write access to the object

Working Set Allows an application that a user is running to increase the memory that the related

process working set uses A process working set is the set of memory pages currently visible to a process in physical memory Allowing for increases in memory pages reduces page faults and enhances performance

Privilege Description Groups Assigned by Default in Domains

Increase Scheduling Priority Allows processes with write access to a process to increase the scheduling priority

assigned to those processes

Administrators and Printer Operators

Lock Pages In Memory In Windows NT, allowed processes to keep data in physical memory, preventing the

system from paging data to virtual memory

on disk

Not used in Windows

2000 or later

Manage Auditing And Security Log Allows users to specify auditing options and access the security log You must turn

on auditing in the group policy fi rst

Administrators

Modify An Object Label Allows a user process to modify the integrity label of objects, such as fi les,

Registry keys, or processes owned by other users This privilege can be used to lower the priority of other processes Processes running under a user account can modify the label of any object the user owns without requiring this privilege

None

Modify Firmware Environment Values Allows users and processes to modify system environment variables (not user

environment variables)

Administrators

Perform Volume Maintenance Tasks Allows administration of removable storage, disk defragmenter, and disk

management

Administrators

Profi le A Single Process Allows users to monitor the performance of non-system processes Administrators on domain controllers;

on member servers and workstations, Administrators and Users

Profi le System Performance Allows users to monitor the performance of system processes Administrators Remove Computer

From Docking Station

Allows undocking a laptop and removing from network Administrators and Users

Replace A Process Level Token Allows processes to modify the default token for subprocesses Local Service and Network Service

Privilege Description Groups Assigned by Default in Domains

Restore Files And Directories Allows restoring backed-up fi les and directories, regardless of the permissions

set on fi les and directories

Administrators, Backup Operators, and Server Operators Shut Down The

System Allows shutting down the local computer. Administrators, Backup Operators,

Print Operators, and Server Operators Synchronize

Directory Service Data

Allows users to synchronize directory service data on domain controllers None

Take Ownership

Of Files Or Other Objects

Allows users to take ownership of any Active Directory objects Administrators

Table 35-2 Default Logon Rights Assigned to Groups Logon Right Description Groups Assigned by Default in Domains

Access Credential Manager As A Trusted Caller

Grants permission to establish a trusted connection to Credential Manager

Credentials, such as a user name and password or smart card, provide identifi cation and proof of identifi cation

None

Access This Computer From The Network

Permits remote access to the computer Administrators,

Authenticated Users, and Everyone Allow Logon Locally Grants permission to log on to the

computer interactively at the console Administrators, Account Operators,

Backup Operators, Print Operators, and Server Operators Allow Logon

Through Terminal Services

Allows access through Terminal Services;

necessary for remote assistance and remote desktop

None

Deny Access To This Computer From The Network

Denies remote access to the computer through network services None

Deny Logon As Batch Job Denies the right to log on through a batch job or script None Deny Logon As

Service Denies the right to log on as a service. None

Logon Right Description Groups Assigned by Default in Domains

Deny Logon Locally Denies the right to log on to the

computer’s keyboard None Deny Logon Through

Terminal Services Denies right to log on through Terminal Services None Log On As A Batch

Job Grants permission to log on as a batch job or script Administrators, Backup Operators,

and Performance Log Users

Log On As A Service Grants permission to log on as a server

LocalSystem account has this right

Services that run under separate accounts should be assigned this right

None

Assigning User Rights

The most effi cient way to assign user rights is to make the user a member of a group that already has the right In some cases, however, you might want a user to have a particular right but not have all the other rights of the group One way to resolve this problem is to give the user the rights directly Another way to resolve this is to create a special group for users that need the right This is the approach used with the Remote Desktop Users group, which was created by Microsoft to grant Allow Logon Through Terminal Services to groups of users

You assign user rights through the Local Policies node of Group Policy Local policies can be set on a per-computer basis using a computer’s local security policy or on a domain or OU basis through an existing group policy for the related domain or OU When you do this, the local policies apply to all accounts in the domain or OU

Assigning User Rights for a Domain or OU

You can assign user rights for a domain or OU by completing the following steps:

1 In the Group Policy Management Console, select the policy you want to work

with, and then click Edit Access the User Rights Assignment node by working your way down the console tree Expand Computer Confi guration, Windows Settings, Security Settings, Local Policies, and User Rights Assignment, as shown

Figure 35-3 Configuring user rights in Group Policy

2 To confi gure a user right, double-click a user right or right-click it and select

Properties This opens a Properties dialog box, as shown in Figure 35-4 If the policy isn’t defi ned, select Defi ne These Policy Settings To apply the right to a user or group, click Add User Or Group Then, in the Add User Or Group dialog box, click Browse This opens the Select Users, Computers, Or Groups dialog box

Figure 35-4 Define the user right, and then assign the right to users and groups

3 Type the name of the user or group you want to use in the fi eld provided, and

then click Check Names By default, the search is confi gured to fi nd built-in security principals, groups, and user accounts After you select the account names

or groups to add, click OK The Add User Or Group dialog box should now show the selected accounts Click OK again

4 The Properties dialog box is updated to refl ect your selections If you made a

mistake, select a name and remove it by clicking Remove When you’re fi nished granting the right to users and groups, click OK

Assigning User Rights on a Specifi c Computer

User rights can also be applied to a specifi c computer However, remember that domain and OU policy take precedence over local policy This means that any settings in these policies will override settings you make on a local computer

You can apply user rights locally by completing the following steps:

1 Start Local Security Policy by clicking Start, Programs or All Programs,

Administrative Tools, Local Security Policy All computers, even domain controllers, have Local Security Policy Settings available in the Local Security Policy console are a subset of the computer’s local policy

2 Under Security Settings, expand Local Policies and then select User Rights

Assignment

3 Double-click the user right you want to modify The Properties dialog box shows

current users and groups that have been given the user right

4 You can apply the user right to additional users and groups by clicking Add User

Or Group This opens the Select Users, Computers, Or Groups dialog box, which you can use to add users and groups

5 Click OK twice to close the open dialog boxes

Note

If the options in the Properties dialog box are dimmed, it means the policy has been set

at a higher level and can’t be overridden locally

Creating and Confi guring Domain User Accounts

As a member of the Account Operators, Enterprise Admins, or Domain Admins group, you can use Active Directory Users And Computers to create user accounts Follow these steps:

1 Click Start, Administrative Tools, and Active Directory Users And Computers

This starts Active Directory Users And Computers

2 By default, you are connected to your logon domain If you want to create OUs in

a different domain, right-click the Active Directory Users And Computers node in the console tree, and then select Change Domain In the Change Domain dialog box, type the name of the domain to which you want to connect, and then click

OK Alternatively, you can click Browse to fi nd the domain to which you want to connect in the Browse For Domain dialog box

3

Note

If the options in the Properties dialog box are dimmed, it means the policy has been set

at a higher level and can’t be overridden locally.

When you create a new user, you’re prompted for the fi rst name, initials, last name, full name, and logon name, as shown in Figure 35-5 The pre–Windows

2000 logon name then appears automatically This logon name is used when a user logs on to Windows NT, Microsoft Windows 95, or Microsoft Windows 98

Figure 35-5 Creating a user account

4 When you click Next, you can set the user’s password and account options The

password must meet the complexity requirements set in the group policy As shown in Figure 35-6, these options are as follows:

User Must Change Password At Next Logon User Cannot Change Password

Password Never Expires Account Is Disabled

Figure 35-6 Set the user’s password and account options

At the command line, you can create a user account using DSADD USER For users, the distinguished name (DN) for the account is used to set the account’s full name For example, you want to create a user account with the display name William Stanek in the Technology OU for the cpandl.com domain When creating the user object using DSADD, you must specify the path as follows:

dsadd user "CN=William Stanek,OU=Technology,DC=cpandl,DC=com"

When you create an account in this way, the other properties of the account are set matically and the account is disabled by default To resolve this, you would need to cre- ate a password for the account and then enable the account

auto-Often, rather than have some properties set automatically, you’ll want to defi ne them with specifi c values This gives you more control and allows you to create the account so that it is enabled for use Use the following parameters:

To see how these parameters are used, consider the following example:

dsadd user "CN=William Stanek,OU=Technology,DC=cpandl,DC=com" -fn William -mi R -ln stanek -Display "William Stanek" -samid williamstanek -pwd TradeWinds45!

For the full syntax and usage, type dsadd user /? at a command prompt The directory services commands can also be used to manage user accounts Use DSMOD USER to set properties, including passwords and group membership Use DSMOVE USER to move users to a new container or OU Use DSRM USER to remove user accounts Tasks that you might want to perform from the command line include:

Searching the entire domain for users with disabled accounts by typing dsquery

num-Determining all users who have not logged on in a specifi ed number of weeks by typing dsquery user -inactive NumWeeks where NumWeeks is the number of weeks

Determining all the groups of which a user is a member by typing dsget user

UserDN -memberof and using the optional -expand parameter to determine all

the inferred group memberships based on the group of which other groups are

SIDE OUT Creating group accounts at the command line

At the command line, you can create a user account using DSADD USER For users, the distinguished name (DN) for the account is used to set the account’s full name For example, you want to create a user account with the display name William Stanek in the Technology OU for the cpandl.com domain When creating the user object using DSADD, you must specify the path as follows:

dsadd user "CN=William Stanek,OU=Technology,DC=cpandl,DC=com"

When you create an account in this way, the other properties of the account are set matically and the account is disabled by default To resolve this, you would need to cre- ate a password for the account and then enable the account.

auto-Often, rather than have some properties set automatically, you’ll want to defi ne them with specifi c values This gives you more control and allows you to create the account so that it is enabled for use Use the following parameters:

To see how these parameters are used, consider the following example:

dsadd user "CN=William Stanek,OU=Technology,DC=cpandl,DC=com" -fn William -mi R -ln stanek -Display "William Stanek" -samid williamstanek -pwd TradeWinds45!

For the full syntax and usage, typedsadd user /? at a command prompt The directory

services commands can also be used to manage user accounts Use DSMOD USER to set properties, including passwords and group membership Use DSMOVE USER to move users to a new container or OU Use DSRM USER to remove user accounts Tasks that you might want to perform from the command line include:

Searching the entire domain for users with disabled accounts by typing dsquery

user -disabled.

Usingdsmod user UserDN to set account fl ags -mustchpwd (yes | no),

-canchpwd (yes | no), -pwdneverexpires (yes | no), -disabled (yes | no).

Determining all users who have not changed their passwords in a specifi ed ber of days by typingdsquery user -stalepwd NumDays where NumDays is the

num-number of days.

Determining all users who have not logged on in a specifi ed number of weeks by typing dsquery user -inactive NumWeeks where NumWeeks is the number of weeks.

Determining all the groups of which a user is a member by typingdsget user UserDN -memberof and using the optional -expand parameter to determine all f

the inferred group memberships based on the group of which other groups are

5 Click Next, and then click Finish If you use a password that doesn’t meet the

complexity requirements of group policy, you’ll see an error and you’ll have to click Back to change the user’s password before you can continue

Viewing and Setting User Account Properties

If you double-click a user account in Active Directory Users And Computers, a ties dialog box appears, with tabs allowing you to confi gure the user’s settings Table 35-3 lists the tabs you see in the Properties dialog box

Proper-Table 35-3 User Account Properties Account Tab Description

Account Used to manage logon name, account options, logon times, and

account lockout Address Used to manage geographical address information Attribute Editor Used to edit the attributes of the related user object COM+ Used to select the user’s COM+ partition set Dial-In Used to set the user’s dial-in or virtual private network (VPN) access

controls as well as callback, IP address, and routing options for

dial-in or VPN Environment Used to manage the Terminal Services startup environment General Used to manage the account name, display name, e-mail address,

telephone number, and Web page Member Of Used to add the user to or remove the user from selected groups Object Displays the canonical name of the user object with dates and

Update Sequence Numbers Organization Used to manage the user’s title and corporate information

(department, manager, direct reports) Profi le Used to manage the user profi le confi guration (profi le path, logon

script) and home folder Published

Certifi cates Used to install or remove user’s X.509 certifi cates Remote Control Used to manage remote control settings for Terminal Services Security Used to confi gure advanced permissions for users and groups that

can access this user object in Active Directory Sessions Used to manage Terminal Services timeout and reconnection

settings Telephones Used to manage home phone, pager, fax, IP phone, and cell phone

numbers Terminal Services

Profi le Used to manage the user profi le for Terminal Services

The number of tabs in a user’s Properties dialog box will vary depending upon the ware installed For example, adding Exchange mail services will add multiple property sheets (tabs) to each user’s Active Directory account Also, to view the Published Cer- tifi cates, Objects, or Security property sheets, you must be in Advanced view To access Advanced view, select Advanced Features from the View menu in Active Directory Users And Computers

soft-Most of the time, as the administrator, you will use a number of the account settings regularly The General tab has the name and e-mail for the user The Account tab has the user name and lets you confi gure logon hours or logon settings There is also an area on the Account tab that allows the account to be unlocked This latter setting is a quick way to unlock an account when a user has forgotten a password or is locked out

of the account for some other reason The Profi le tab lets you set a user profi le, logon script, and home folder The Member Of tab lets you add the user to various groups The Security tab lets you set the way permissions for groups or users are confi gured and provides access to the Effective Permissions tool via the Advanced button

Obtaining Effective Permissions

In Active Directory, user accounts are defi ned as objects—as are group and computer accounts This means that user accounts have security descriptors that list the users and groups that are granted access Security descriptors also defi ne ownership of the object and specify the permissions that those users and groups have been assigned with respect to the object

Individual entries in the security descriptor are referred to as access control entries (ACEs) Active Directory objects can inherit ACEs from their parent objects This means that permissions for a parent object can be applied to a child object For example, all members of the Account Operators group inherit permissions granted to this group Because of inheritance, sometimes it isn’t clear whether a particular user, group, or com-puter has permission to work with another object in Active Directory This is where the Effective Permissions tool comes in handy The Effective Permissions tool allows you to examine the permissions that a user, group, or computer has with respect to another object For example, if you wanted to determine what permissions, if any, a user who has received delegated control has over another user or group, you could use Effective Permissions to do this

The Effective Permissions tool is available in Active Directory Users And ers—but only if you are in the Advanced Features view Select Advanced Features from the View menu if necessary, and then double-click the user, group, or computer for which you are trying to determine the effective permissions of another user or group

Comput-In the Properties dialog box, click the Advanced button on the Security tab to open the

Note

The number of tabs in a user’s Properties dialog box will vary depending upon the ware installed For example, adding Exchange mail services will add multiple property sheets (tabs) to each user’s Active Directory account Also, to view the Published Cer- tifi cates, Objects, or Security property sheets, you must be in Advanced view To access Advanced view, select Advanced Features from the View menu in Active Directory Users And Computers.

The effective permissions for the selected user or group in relation to the previously selected object appear, as shown in Figure 35-7 The Effective Permissions box will have check marks showing which permissions are in effect If there are no effective permis-sions, none of the permissions’ check boxes will be selected

Figure 35-7 Obtaining effective permissions for a user, group, or computer

Confi guring Account Options

Every user account created in Active Directory has account options that control logon hours, the computers to which a user can log on, account expiration, and so on To manage these settings for a user, double-click the user account in Active Directory Users And Computers, and then select the Account tab, as shown in Figure 35-8

Figure 35-8 Display of logon settings in the user account Properties dialog box

Below the general account name fi elds, the available options are divided into three main areas The fi rst area that you can confi gure controls the Logon Hours and Log On

To options

Setting logon hours Click Logon Hours to confi gure when a user can log on to the domain By default, users can log on 24 hours a day, seven days a week To deny a user a specifi c day or time, select the area that you want to restrict them from logging on, and then select the Logon Denied option, as shown in the fol-lowing screen For example, this option can be used to restrict shift workers to certain hours or to restrict working days to weekdays

Confi guring logon computer When you click Log On To, you can restrict which computers a user can log on from The default setting allows users to log on from all computers To restrict which computers a user can log on from, click The Fol-lowing Computers, as shown in the following screen Type a host name or a fully qualifi ed domain name in the Computer Name fi eld, such as Workstation18 or Workstation.cpandl.com Click Add Repeat this procedure to set other logon computers

Below the Logon Hours and Log On To buttons is a check box called Unlock Account If the user has locked herself or himself out by trying to log on with the wrong password too many times, you can unlock the account by clearing this check box Next is the Account Options list, which includes a number of account options you can confi gure

These options include the following:

User Must Change Password At Next Logon This is the default setting when a user is created It requires the user to change the password the fi rst time he or she logs on This allows the user to be the only person with the knowledge of the password, though you as the administrator can change it

User Cannot Change Password This setting prevents the user from changing the password and gives the administrator more control over accounts like the Guest account This is a good setting for service and application accounts

Password Never Expires This prevents passwords from ever expiring It is a good idea to use this on service accounts This is another good setting for an applica-tion or service account where a password is hard-coded into an application or service

Store Password Using Reversible Encryption Saves the user password as encrypted clear text Select this check box if you have computers from Apple Computer, Inc., in your domain, because they store passwords as plain text

Account Is Disabled This prevents a user from logging on to his or her account

It enables network administrators to immediately disable an account for security reasons