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

A s 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 CHAPTER 35 Managing Users, Groups, and Computers 1167 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.  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 although a user name can be 256 characters in length, a name of this length really isn’t practical in most cases. 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 although a user name can be 256 characters in length, a name of this length really isn’t practical in most cases. Chapter 35 1168 Chapter 35 Managing Users, Groups, and Computers Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 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 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 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. Managing Domain User Accounts 1169 Chapter 35 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 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 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 defi ned 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 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. 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 Some Security Options Are Also Obtained from the Default Domain Policy GPO Two policies in Computer Confi guration\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 defi ned and applicable. Chapter 35 1170 Chapter 35 Managing Users, Groups, and Computers Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 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 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- 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. Managing Domain User Accounts 1171 Chapter 35 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 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 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 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 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 Confi guration\Windows Settings\Security Settings\ Account Policies\Account Lockout Policy. When you are setting secondary account policy for a PSO, you confi gure these settings using similarly named object attributes. Chapter 35 1172 Chapter 35 Managing Users, Groups, and Computers Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 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 worksta- tions and servers have different local clock times. This setting allows you to con- 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. Managing Domain User Accounts 1173 Chapter 35 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 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 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: 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. Chapter 35 1174 Chapter 35 Managing Users, Groups, and Computers Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 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. Managing Domain User Accounts 1175 Chapter 35 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 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 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. 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. 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. Chapter 35 1176 Chapter 35 Managing Users, Groups, and Computers Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [...]... 2003, local user profiles are stored by default in the %SystemDrive%\Documents and Settings folder On Windows Vista and Windows Server 2008, local user profiles are stored by default in the %SystemDrive%\Users\ %UserName% folder Like Windows Server 2003, Windows Server 2008 saves roaming profiles to a server when a user logs off, even if an application has the Registry open When a user logs on to a domain... contents of the profile folders using Windows Explorer However, many of the folders are hidden from view by default To configure Windows Explorer so that you can view the additional folders, choose Folder Options from the Tools menu, and then click the View tab Under Advanced Settings, select Show Hidden Files And Folders and then click OK Chapter 35 On Windows XP and Windows Server 2003, local user profiles... a roaming or mandatory profile previously configured For Windows Vista and Windows Server 2008, this means that the contents of the %SystemDrive%\Users\ Default folder are copied to the new user’s profile folder This creates the user’s desktop and Start menu Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Chapter 35 In Windows Explorer, you must enable the Show Hidden Files... path on the user’s computer such as C:\Profiles\%UserName% or a path to a network share on a remote server If you choose to put the user profiles on a remote server, the path should be in the Uniform Naming Convention (UNC) form such as \\ServerName\ShareName\ %UserName% where ServerName is the name of the server, ShareName is the name of the share created for storing roaming profiles, and %UserName% is... field, such as Workstation18 or Workstation.cpandl.com Click Add Repeat this procedure to set other logon computers Chapter 35 Note Earlier releases of Windows required the NetBIOS protocol to restrict which computers a user can log on from In Windows Server 2008, this requirement has been phased out Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Managing Domain User Accounts... roam from server to server and not have to reconfigure the desktop each time you log on For instance, in your roaming profi le, Windows Explorer can be configured through the Default Domain Policy to show fi le details regardless of where you log on or whether it was the first time you logged on to a particular computer Mandatory Mandatory profiles are roaming profi les, originated by you and kept on a server, ... 1200 Chapter 35 Managing Users, Groups, and Computers Each new user has a unique path for the local user profi le that includes the user’s logon name as a subdirectory of the path For Windows Vista and Windows Server 2008, the default location for profiles is %SystemDrive%\Users\%UserName%\Ntuser.dat, such as C:\Users\wrstanek\Ntuser.dat Note In the user’s main subdirectory for his or her profile, there... 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... Open and Save As operations, helping users find their resources easily Home directories can be located on a user’s local hard drive or on a shared network drive If you don’t assign a home folder, Windows Server 2008 uses a default local home folder To specify a home folder, do either of the following: You specify a local home folder by clicking the Local Path option, and then typing the path to the home... value, the PSO with the lowest GUID is applied Typically, this means Active Directory will apply the PSO with the earliest creation date 1178 Chapter 35 Managing Users, Groups, and Computers In Windows Server 2008, some capabilities of accounts are built in The built-in capabilities of accounts are assigned to groups and include the group’s automatic capabilities Although built-in capabilities are predefined . 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. . 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