Windows Server 2008 Inside Out- P25

Chia sẻ: Thanh Cong | Ngày: | Loại File: PDF | Số trang:50

0
45
lượt xem
9
download

Windows Server 2008 Inside Out- P25

Mô tả tài liệu
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

Tham khảo tài liệu 'windows server 2008 inside out- p25', công nghệ thông tin, quản trị mạng phục vụ nhu cầu học tập, nghiên cứu và làm việc hiệu quả

Chủ đề:
Lưu

Nội dung Text: Windows Server 2008 Inside Out- P25

  1. CHAPTER 35 Managing Users, Groups, and Computers Managing Domain User Accounts . . . . . . . . . . . . . . . . 1167 Maintaining User Accounts . . . . . . . . . . . . . . . . . . . . . . 1210 Managing User Profiles . . . . . . . . . . . . . . . . . . . . . . . . . 1195 Managing Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1215 Managing User Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 1203 Managing Computer Accounts . . . . . . . . . . . . . . . . . . 1225 A s an administrator, managing users, groups, and computers will probably be a sig- nificant 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 efficient 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 first part of the chapter, I will describe the types of users Microsoft Windows Server 2008 defines. 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 configurations. 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. 1167
  2. 1168 Chapter 35 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 identifier (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 configured 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. Chapter 35 Small organizations commonly use a person’s first 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 although a user name can be 256 characters in length, a name of this length really isn’t practical in most cases.
  3. Managing Domain User Accounts 1169 Configuring 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 fine-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 define 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 Pass- word Settings Objects and Applying Secondary Settings” on page 1173. Local Account Policy Is Used for Local Log On Local account policies can be different from the domain account policy, such as when you specifically define an account policy for local accounts in a computer’s local GPO (LGPO). For example, if you configure 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 Chapter 35 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 configured through the policy editors accessible from the Group Policy Management Console (GPMC). When you are editing policy settings, you’ll find account policies under Computer Configuration\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.
  4. 1170 Chapter 35 Managing Users, Groups, and Computers 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 Configuration\Windows Settings\Security Settings\Local Poli- 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 defined and applicable. Enforcing Password Policy Password policies for domain user accounts and local user accounts are very impor- 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 Configuration\Windows Settings\Security Settings\Account Policies\Password Policy (see Figure 35-1). When you are setting secondary account policy for a PSO, you config- ure these settings using similarly named object attributes. Chapter 35 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 deter- mines how many old passwords will be maintained and associated with each user. The maximum value is 24. If you enter zero (0), a password history is not
  5. Managing Domain User Accounts 1171 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 configured 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 mini- 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- Chapter 35 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 applica- 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.
  6. 1172 Chapter 35 Managing Users, Groups, and Computers Figure 35-2 Configuring domain user Minimum Password Length in the Default Domain Policy. Configuring 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 deter- 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 indefinitely 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 Chapter 35 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 Thresh- 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 Configuration\Windows Settings\Security Settings\ Account Policies\Account Lockout Policy. When you are setting secondary account policy for a PSO, you configure these settings using similarly named object attributes.
  7. Managing Domain User Accounts 1173 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 five 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 Configuration\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 configured 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 configures the maximum amount of time the ticket may be used. The default is seven days. Maximum Tolerance For Computer Clock Synchronization Sometimes worksta- tions and servers have different local clock times. This setting allows you to con- figure 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 Chapter 35 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 fine-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.
  8. 1174 Chapter 35 Managing Users, Groups, and Computers Afterward, you have to create a Password Settings object with attributes that define 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 reflect the organizational structure of your OUs. You can create the Password Settings group and defi ne its members using Active Direc- 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: Chapter 35 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.
  9. Managing Domain User Accounts 1175 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 Chapter 35 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.
  10. 1176 Chapter 35 Managing Users, Groups, and Computers 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 defined. 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 specified 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 msDS- 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. Chapter 35 Note You can link a PSO to other types of groups in addition to global security groups. How- 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.
  11. Managing Domain User Accounts 1177 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 Chapter 35 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 specific capabilities, privileges, and rights. When you create a user account, you can grant the user specific 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.
  12. 1178 Chapter 35 Managing Users, Groups, and Computers In Windows Server 2008, some capabilities of accounts are built in. The built-in capa- bilities of accounts are assigned to groups and include the group’s automatic capa- bilities. Although built-in capabilities are predefined and unchangeable, they can be granted to users by making them members of the appropriate group or delegated by granting the capability specifically, 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 define 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 specific 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 permis- 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. Table 35-1 Default Privileges Assigned to Groups Groups Assigned by Privilege Description Default in Domains Act As Part Of The Allows a process to authenticate as any None Operating System user. Processes that require this privilege must use the LocalSystem account, which already has this privilege. Add Workstations To Allows users to add new computers to an Authenticated Users Domain existing domain. Chapter 35 Adjust Memory Allows users to set the maximum amount Administrators, Local Quotas For A of memory a process can use. Service, and Network Process Service Back Up Files And Allows users to back up the system Administrators, Directories regardless of the permissions set on files Backup Operators, and directories. and Server Operators Bypass Traverse Allows users to go through directory trees Administrators, Checking even if a user doesn’t have permissions Authenticated Users, to access the directories being passed Everyone, Local through. The privilege doesn’t allow the Service, and Network user to list directory contents. Service
  13. Managing Domain User Accounts 1179 Groups Assigned by Privilege Description Default in Domains Change The System Allows users to set the time for the Administrators, Server Time computer’s clock. Operators, and Local Service Change The Time Allows users to set the time zone for the Administrators, Server Zone system clock. Operators, and Local Service Create A Pagefile Allows users to create and modify the Administrators paging file size for virtual memory. Create A Token Allows processes to create token objects None Object 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. Create Global Allows a process to create global directory Administrators, Objects objects. Most components already have Service, Local Service, this privilege and it’s not necessary to and Network Service specifically assign it. Create Permanent Allows processes to create directory objects None Shared Objects in the Windows object manager. Most components already have this privilege and it’s not necessary to specifically assign it. Create Symbolic Link Allows an application that a user is running Administrators to create symbolic links. Symbolic links make it appear as if a document or folder is in a specific location when it actually resides in another location. Use of symbolic links is restricted by default to enhance security. Debug Programs Allows users to perform debugging. Administrators Enable User And Permits users and computers to change or Administrators Computer Accounts apply the trusted account for delegation Chapter 35 To Be Trusted For setting, provided they have write access to Delegation the object. Force Shutdown Of Allows users to shut down a computer from Administrators and A Remote System a remote location on the network. Server Operators Generate Security Allows processes to make security log Local Service and Audits entries for auditing object access. Network Service Increase A Process Allows an application that a user is running Users Working Set 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.
  14. 1180 Chapter 35 Managing Users, Groups, and Computers Groups Assigned by Privilege Description Default in Domains Increase Scheduling Allows processes with write access to a Administrators Priority process to increase the scheduling priority assigned to those processes. Load And Unload Allows users to install and uninstall Plug Administrators and Device Drivers and Play device drivers. This doesn’t Printer Operators affect device drivers that aren’t Plug and Play, which can only be installed by administrators. Lock Pages In In Windows NT, allowed processes to keep Not used in Windows Memory data in physical memory, preventing the 2000 or later system from paging data to virtual memory on disk. Manage Auditing Allows users to specify auditing options Administrators And Security Log and access the security log. You must turn on auditing in the group policy first. Modify An Object Allows a user process to modify the None Label integrity label of objects, such as files, 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. Modify Firmware Allows users and processes to modify Administrators Environment Values system environment variables (not user environment variables). Perform Volume Allows administration of removable Administrators Maintenance Tasks storage, disk defragmenter, and disk management. Profile A Single Allows users to monitor the performance of Administrators on Process non-system processes. domain controllers; Chapter 35 on member servers and workstations, Administrators and Users Profile System Allows users to monitor the performance of Administrators Performance system processes. Remove Computer Allows undocking a laptop and removing Administrators and From Docking from network. Users Station Replace A Process Allows processes to modify the default Local Service and Level Token token for subprocesses. Network Service
  15. Managing Domain User Accounts 1181 Groups Assigned by Privilege Description Default in Domains Restore Files And Allows restoring backed-up files and Administrators, Directories directories, regardless of the permissions Backup Operators, set on files and directories. and Server Operators Shut Down The Allows shutting down the local computer. Administrators, System Backup Operators, Print Operators, and Server Operators Synchronize Allows users to synchronize directory None Directory Service service data on domain controllers. Data Take Ownership Allows users to take ownership of any Administrators Of Files Or Other Active Directory objects. Objects Table 35-2 Default Logon Rights Assigned to Groups Groups Assigned by Logon Right Description Default in Domains Access Credential Grants permission to establish a trusted None Manager As A connection to Credential Manager. Trusted Caller Credentials, such as a user name and password or smart card, provide identification and proof of identification. Access This Permits remote access to the computer. Administrators, Computer From The Authenticated Users, Network and Everyone Allow Logon Locally Grants permission to log on to the Administrators, computer interactively at the console. Account Operators, Backup Operators, Print Operators, and Server Operators Chapter 35 Allow Logon Allows access through Terminal Services; None Through Terminal necessary for remote assistance and Services remote desktop. Deny Access To This Denies remote access to the computer None Computer From The through network services. Network Deny Logon As Batch Denies the right to log on through a batch None Job job or script. Deny Logon As Denies the right to log on as a service. None Service
  16. 1182 Chapter 35 Managing Users, Groups, and Computers Groups Assigned by Logon Right Description Default in Domains Deny Logon Locally Denies the right to log on to the None computer’s keyboard. Deny Logon Through Denies right to log on through Terminal None Terminal Services Services. Log On As A Batch Grants permission to log on as a batch job Administrators, Job or script. Backup Operators, and Performance Log Users Log On As A Service Grants permission to log on as a server. None LocalSystem account has this right. Services that run under separate accounts should be assigned this right. Assigning User Rights The most efficient 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: Chapter 35 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 Configuration, Windows Settings, Security Settings, Local Policies, and User Rights Assignment, as shown in Figure 35-3.
  17. Managing Domain User Accounts 1183 Figure 35-3 Configuring user rights in Group Policy. 2. To configure 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 defined, select Define 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. Chapter 35 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 field provided, and then click Check Names. By default, the search is configured to find 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 reflect 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.
  18. 1184 Chapter 35 Managing Users, Groups, and Computers Assigning User Rights on a Specific Computer User rights can also be applied to a specific 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 Configuring Domain User Accounts As a member of the Account Operators, Enterprise Admins, or Domain Admins group, Chapter 35 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. You can now create the user account. Right-click the container in which you want to create the user, point to New, and then select User. This will start the New Object–User Wizard.
  19. Managing Domain User Accounts 1185 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 Chapter 35 Figure 35-6 Set the user’s password and account options.
  20. 1186 Chapter 35 Managing Users, Groups, and Computers 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 auto- 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. Often, rather than have some properties set automatically, you’ll want to define them with specific values. This gives you more control and allows you to create the account so that it is enabled for use. Use the following parameters: -FN to set the first name -MI to set the middle initials -LN to set the last name -Display to set the display name -samid to set the logon name -pwd to set the password 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 user -disabled. Chapter 35 Using dsmod user UserDN to set account flags -mustchpwd (yes | no), -canchpwd (yes | no), -pwdneverexpires (yes | no), -disabled (yes | no). Determining all users who have not changed their passwords in a specified num- ber of days by typing dsquery user -stalepwd NumDays where NumDays is the number of days. Determining all users who have not logged on in a specified 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 f the inferred group memberships based on the group of which other groups are members.
Đồng bộ tài khoản