Section 2.3. Managing Users, Computers, and Groups
2.3. Managing Users, Computers, and GroupsWindows computers can be organized into the following:
Managing domain accounts for users, computers, and accounts is a key part of most administrator's job and an important part of the 70-290 exam. Knowing troubleshooting techniques for accounts is also essential. Tip: Exams 70-290, 70-291, 70-293, and 70-294 (and by association Exams 70-292 and 70-296) all expect you to have familiarity with Active Directory. Exam 70-294 (70-296 for those upgrading their certification) is where the detailed knowledge of Active Directory is tested. If you are unfamiliar with the concepts of domains, domain trees, domain forests, and how objects are stored within Active Directory, you should review the introductory materials provided at the beginning of the Exam 70-294 study guide in this book before continuing. 2.3.1. Understanding User, Computer, and Group NamingNames assigned to users, computers, and groups are used for assignment and reference purposes. You assign access permissions to a user, computer, or group using the associated account name. You make references to a user, computer, or group using the associated account name. In a workgroup, each computer must have a unique name, and other names are maintained on a per-machine basis. This means each local user and local group defined on a computer must be unique. In Active Directory, all user, computer, and group names must be unique on a per-domain basis. There is a specific set of rules that must be adhered to, which require that:
2.3.2. Managing Computer Accounts in an Active Directory EnvironmentBefore a user can log on to a computer with a domain account, the computer must be a member of the domain, which means the computer must have a domain account and be joined to the domain using that account. Computer accounts, like user accounts, have an account name, password, and security identifier (SID). In Active Directory, these properties of computer accounts are stored along with many other properties in the related objects, and these objects in turn are stored in the directory itself. 2.3.2.1. Creating computer accountsComputer accounts can be created in several ways:
The key advantage of prestaging computer accounts is that you can specify the Active Directory container within which the computer account will be stored. If you do not prestage the computer account, Active Directory creates the computer account in the default container for computer objects. Typically, this is the computer's organizational unit (OU). If a Windows Server 2003 computer is later made a domain controller (using DCPROMO), the computer object is moved to the default container for domain controllers, which typically is the Domain Controllers OU. Permissions for who can prestage computer accounts and who can join computers to a domain are somewhat convoluted:
Computer accounts can be created using a variety of tools. The two you'll use the most are:
Regardless of which tool you are using, you should think about which container or OU the computer account will be placed in before creating the account. Ideally, you'll place the computer account in the container or OU where it can best be managed in terms of administration, delegation, and policy application. To create a computer account using Active Directory Users And Computers (dsa.msc), follow these steps:
To create a computer account using DSADD, you'll need to have a strong understanding of Active Directory service path strings. Essentially, path strings describe the computer object's location in the directory from its most basic component, the computer name, to its most widely scoped components, the actual containers in which it is stored. Consider the following example:
Tip: Although quotation marks are only required if the path string contains a space, it is a good idea to use them whenever specifying path strings. This way, you will remember to use them when they are required and won't get an error. In this example, CN= is used to specify the common name of an object and DC= is used to specify a domain component. With Active Directory path strings, you will also see OU=, which is used to specify the name of an organizational unit object. For the full syntax and usage, type dsadd computer /? at a command prompt. 2.3.2.2. Joining computer accounts to domainsAny authenticated user can join a computer to a domain, provided the account for the computer hasn't been prestaged. If it has been prestaged, only a user specifically delegated permission or an administrator can join a computer to a domain. Users must also have local administrator permissions on the computer. Computer can be joined to a domain using:
Before joining a computer to a domain, I recommend that you check the computer's network configuration. In Control Panel, access Network Connections Tip: Typing ipconfig /all at a command prompt is the fastest way to check a computer's network configuration. To join the computer to the domain, follow these steps:
When a computer joins a domain, the computer establishes a trust relationship with the domain. The computer's SID is changed to match that of the related computer account in Active Directory, and the computer is made a member of the appropriate groups in Active Directory. Typically, this means the computer is made a member of the Domain Computers group. If the computer is later made a domain controller, the computer will be made a member of the Domain Controllers group instead. A command-line tool for joining computers to a domain is NETDOM. NETDOM is available when the Windows Support tools are installed on a computer. You can use NETDOM to simultaneously join a computer to a domain and create a computer account in the domain. Use the following command syntax: netdom add ComputerName /domain:DomainName /userD:DomainUser /password:UserPassword where ComputerName is the name of the computer, DomainName is the name of the Active Directory domain to join, DomainUser is the name of a domain user account authorized to join the computer to the domain (and create the related computer account if necessary), and UserPassword is the password for the user account. Optionally, you can use the /ou switch to specify the distinguished name of the OU into which the computer account should be placed. Consider the following example:
2.3.2.3. Maintaining computer accountsIn Active Directory, computer accounts are stored by default in the Computers container, and domain controller accounts are stored in the Domain Controllers OU. When you create computer accounts, you can place them in a specific container. All computer accounts have manageable properties and passwords, and there is a trust between computers and the domain in which they are located. You can maintain computer accounts and manage related properties in several ways. Use Active Directory Users And Computers by right-clicking the account name, you'll see a shortcut menu with the following options:
The directory services commands can also be used to perform these tasks. Use the commands as described here:
On the exam, you'll need to know how to resolve computer account problems by:
However, the Reset Account feature is not the best technique to use with member servers and domain controllers. With member servers and domain controllers, you should use NETDOM RESETPWD. You can reset the computer account password of a member server or domain controller by completing the following steps:
2.3.2.4. Troubleshooting computer accountsAs an administrator, you'll see a variety of problems related to computer accounts. When you are joining a computer to a domain, you may experience problems due to:
Once a computer is joined to a domain, you may occasionally see problems with the computer password or trust between the computer and the domain. A password/trust problem can be diagnosed easily: if you try to access or browse resources in the domain and are prompted for a username and password when you normally are not, you may have a password/trust issue with the computer account. For example, if you are trying to connect to a remote computer in Computer Management, and you are prompted for a username and password where you weren't previously, the computer account password should probably be reset. You can verify a password/trust problem by checking the System event log. Look for an error with event ID 3210 generated by the NETLOGON service. The related error message should read:
If the related computer account is disabled or deleted, you will be denied access to remote resources when connecting to those resources from this computer. For example, if you are trying to access CorpSvr23 from CorpPc18, you will be denied access if the computer account is disabled or deleted. The system event log on the remote computer (CorpSvr23) should log related NETLOGON errors specifically related to the computer account, such as the following with event ID 5722:
Because of this, you should always check the status of the account in Active Directory Users And Computers as part of the troubleshooting process. A disabled account has a red warning icon. A deleted account will no longer be listed and you won't be able to search for and find it in the directory. If a user is trying to connect to a resource on a remote computer, the computer to which she is connecting should have a related error or warning event in the event logs. Check the storage location of the computer and its group membership as well. Computer accounts, like user accounts, are placed in a specific container in Active Directory and can be made members of specific groups:
Tip: With Kerberos authentication, a computer's system time can affect authentication. If a computer's system time deviates outside the permitted norms set in group policy, the computer will fail authentication. 2.3.3. Managing Groups in an Active Directory EnvironmentGroup accounts are used in both workgroups and domains to help manage access to resources. Depending on the group type and scope, a group can have as its members other groups, computers, users, or any permitted combination of the three. By designating Group A as a member of Group B, you grant all users and computers in Group A the permissions of Group B. By making a user or computer a member of Group A, you grant the user or computer all the permissions of Group A. 2.3.3.1. Understanding group types and scopesIn workgroups, computers have only one type of group: local groups . These are used to help manage local machine permissions and access to local machine resources. You manage local groups using the Local Users And Groups snap-in, which is installed by default in the Local Users And Groups console (lusrmgr.msc) and in the Computer Management console (compmgmt.msc). Warning: You cannot manage local users or local groups on domain controllers. Domain controllers do not have local users or local groups. In Active Directory domains, computers have local groups as well. As with workgroups, local groups are used to help manage local machine permissions and access to local machine resources. However, that being said, the primary types of groups you'll work with in domains are:
Tip: Distribution groups are designed to make email services and server management easier by allowing administrators to add existing user accounts to email distribution lists. Although security groups can be used for email distribution purposes, distribution groups cannot be used to manage access to network resources. When you create a distribution group or security group, you assign the group a specific scope: either domain local, global, or universal. As Table 2-4 shows, the scope determines how the group can be used and what members it can include.
Tip: Active Directory domains also have built-in local groups. These groups are created during setup of the operating system and installation of Active Directory. Built-in local groups are a special scope. Because they are managed in the same way as domain local groups, they are often included in the definition of domain local groups. However, you cannot create or delete built-in local groups. Domain functional level affects which group scopes are available and how group scopes are used. Specifically, when the domain functional level is set to Windows 2000 Mixed or Windows Server 2003 interim, universal groups are not available and domain local groups function as local groups. In any other domain functional level, universal groups are available and domain local groups have domain-wide scope. Table 2-5 summarizes the modifications to how groups can be used based on the domain functional level. Note that only in Windows 2000 Native or Windows Server 2003 mode can the same type of group be nested within a group. In Windows 2000 Native or Windows Server 2003 mode, domain local groups can contain other domain local groups, global groups can contain other global groups, and universal groups can contain other universal groups.
Group scope is set when you create a group. Although you cannot change the scope of built-in local groups, you can change the scope of domain local groups, global groups, and universal groups. The following rules apply:
2.3.3.2. Creating groupsGroups can be created using a variety of tools. The two you'll use the most are:
Regardless of which tool you are using, you should think about which container or OU the group will be placed in before creating the group. Ideally, you'll place the group in the container or OU where it can best be managed. You must either be a member of the Enterprise Admins, Domain Admins, or Account Operators groups to create groups, or you must have been delegated this permission. To create a group using Active Directory Users And Computers (dsa.msc), follow these steps:
To create a group using DSADD, you'll need to be able to set the Active Directory service path string for the group. For groups, path strings describe the group's location in the directory from the group name to the actual containers in which it is stored. You specify whether the group is a security group using -secgrp yes or that a group is a distribution group using -secgrp no. Specify the scope of the group using -scope u for universal, -scope g for global, and -scope l for domain local. Consider the following example: you want to create a global security group called NYSales in the Sales OU for the williamstanek.com domain. The full path to this group object is CN=NYSales,OU=Sales,DC=williamstanek,DC=com. When creating the group object using DSADD, you must specify this path as follows: dsadd group "CN=NYSales,OU=Sales,DC=williamstanek,DC=com" -secgrp yes -scope g Tip: Although quotation marks are only required if the path string contains a space, it is a good idea to use them whenever specifying path strings. This way you will remember to use them when they are required and won't get an error. For the full syntax and usage, type dsadd group /? at a command prompt. 2.3.3.3. Setting and determining group membershipDepending on type and scope, a group can have accounts, groups, or both as its members. When you work with groups, you'll often need to manage membership by adding or removing members. You'll also frequently need to determine and manage which groups a particular group is a member of. You can manage group members using Active Directory Users And Computers by following these steps:
You can determine and manage the groups that a group is a member of by using Active Directory Users And Computers and following these steps:
These tasks can also be performed using the directory services commands, including DSGET GROUP and DSMOD GROUP. By using DSGET GROUP at a command prompt, you can:
By using DSMOD GROUP at a command prompt, you can:
Tip: All the previously discussed rules for changing group type and scope apply. See "Understanding group types and scopes," earlier in this chapter for details. 2.3.3.4. Maintaining groupsIn Active Directory, groups are stored in a particular container, such as Users, or in a particular organizational unit. When you create groups, you can place them in a specific container and mmove them later if necessary. Using Active Directory Users And Computers, you can maintain groups by right-clicking the group name. A shortcut menu will appear with the following options:
The directory services commands can also be used to perform these tasks. Use DSMOD GROUP to set properties and manage membership. Use DSMOVE GROUP to move groups to a new container or OU. Use DSRM GROUP to remove the group. 2.3.3.5. Understanding implicit groups and special identitiesAs discussed previously, built-in groups are a special type of group. Implicit built-in groups are another special type of group. As the name implies, membership in implicit groups is implicitly applied according to a particular situation or circumstance. Implicit groups cannot be created or deleted. Group scopes do not apply to implicit groups, nor can you change the membership of implicit groups. You can, however, apply user rights and assign security permissions to implicit groups. Another term for an implicit group is special identity group, or simply, special identity. Tip: Although most special identities, such as Authenticated User, Creator Owner, and Everyone, are visible in Active Directory Users And Computers and in other computer management tools, some others are not. Special identities include:
2.3.4. Managing User Accounts in an Active Directory EnvironmentNamed user accounts are used to control access to resources. In Windows environments, there are two types of user accounts:
User accounts have account names, passwords, and security identifiers (SIDs) associated with them. In workgroups, these properties are stored in the Security Accounts Manager (SAM) database on a per account basis. In Active Directory, these properties of user accounts are stored along with many other properties in the related objects, and these objects in turn are stored in the directory itself. 2.3.4.1. Creating user accountsUser accounts have display names and logon names associated with them. The display or full name is the name displayed in the graphical interface. The logon name is used for logging on to the domain. A standard logon name and a pre-Windows 2000 logon name are required for each user account, and either can be specified at logon. Regardless of which tool you are using, you should think about which container or OU the user account will be placed in before creating the account. Ideally, you'll place the user account in the container or OU where it can best be managed in terms of administration, delegation, and policy application. You must be a member of the Enterprise Admins, Domain Admins, or Account Operators groups to create user accounts. Or you must have been delegated this permission. You can create a user account using Active Directory Users And Computers (dsa.msc) by following these steps:
You can create a user account using DSADD USER as well. When you do this, the DN for the account is used to set the account's full name. For example, suppose you want to create a user account with the display name "William Stanek" in the Engineering OU for the domain.local domain. When creating the user object using DSADD, you must specify the path as follows: dsadd user "CN=William Stanek,OU=Engineering,DC=domain,DC=local" If you create an account in this manner, the other properties of the account are set automatically, and the account is configured so that it is disabled. To resolve this, you need to create a password for the account and then enable the account. In most cases, rather than have some properties set automatically, you'll want to define them. This gives you more control and allows you to create the account so that it is enabled for use. Use the following parameters:
Thus, a better way to define the previous account would be to use the following command line: dsadd user "CN=William Stanek,OU=Engineering,DC=domain,DC=local" -fn William -mi R -ln stanek -Display "William Stanek" -samid williamstanek -pwd R496Stra@$! Tip: Quotation marks are only required if a path or value string contains a space. For the full syntax and usage, type dsadd user /? at a command prompt. 2.3.4.2. Maintaining user accountsIn Active Directory, user accounts are stored in a particular container, such as Users, or in a particular organizational unit. When you create users, you can place them in a specific container and move them later if necessary. Using Active Directory Users And Computers, you can maintain user accounts by right-clicking the user name, which displays a shortcut menu with the following options:
When you right-click a user account and select Properties in Active Directory Users And Computers, you'll see a properties dialog box similar to the one shown in Figure 2-10. Figure 2-10. Use the user account properties dialog to configure a user's account. Tip: Multiple accounts can be selected for editing by holding Shift or Ctrl when selecting account names before right-clicking and selecting Properties. Only a select subset of properties can be managed simultaneously for multiple users. On the General tab, you can modify Description, Office, Telephone Number, Fax, Web Page, and E-mail. On the Account tab, you can modify UPN Suffix, Logon Hours, Computer Restrictions, Account Options, and Account Expires. On the Profile tab, you can modify Profile Path, Logon Script, and Home Folder. Although the exact number and type of tabs available will depend on the configuration of your Windows environment, the most common tabs and their uses are summarized in Table 2-6.
The tab you'll work with the most is the Account tab. For the exam, you'll be expected to know how to configure logon hours, account expiration, and more. Here's an overview the main Account tab options:
The directory services commands can also be used to perform these tasks. 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. Common user management tasks that you may want to perform from the command line include:
2.3.4.3. Importing and exporting user accountsMicrosoft provides the Comma-Separated Value Directory Exchange (CSVDE) command-line utility for importing and exporting Active Directory objects. For imports, CSVDE uses a comma-delimited text file as the import source, and you can run it using these general parameters:
For imports, the source file's first row defines the list of LDAP attributes for each object defined. Each successive data line provides the details for a specific object to import, and must contain exactly the attributes listed. Here is an example: DN,objectClass,sAMAccoutName,sn,givenName,userPrincipalName "CN=WilliamStanek,OU=Eng,DC=domain,DC=local", user,williams,William,Stanek,williams@domain.local Given this listing, if the import source file is named current.csv, you could import the file into Active Directory using: csvde -i -f current.csv For exports, CSVDE writes the exported objects to a comma-delimited text file. You can run CSVDE using the general parameters listed previously as well as by using export-specific parameters, which include:
To create an export file for the current naming context (the default domain), you could type: csvde -f current.csv However, this could result in a very large export dump. Thus, in most cases, you'll want to specify at a minimum, the RootDN and an object filter, such as: csvde -f current.csv -d "OU=Sales,DC=domain,DC=local" -r "(objectClass=user)" 2.3.5. Managing Local, Roaming, and Mandatory User ProfilesEvery time a user logs on to a local machine or the domain, a profile is created or retrieved for use during the user's logon session. User profiles are meant to provide a consistent environment for users. 2.3.5.1. Understanding local user profilesProfiles track user environment settings. Settings tracked include:
Every computer has a default profile stored locally in the %SystemDrive%\Documents and Settings\Default User folder. By default, if a user logs on to a system and doesn't have an existing profile on that system, Windows creates a copy of the default profile and stores it as the user's new profile in the %SystemDrive%\Documents and Settings\%UserName% folder on that computer. A user's environment settings are extended by the All Users profile on the local computer. The All Users profile contains system-specific settings, such as common Start Menu and desktop shortcuts, application data, and Network Places. Settings from the All Users profile are combined with a user's profile to create the user's environment. By default, only administrators can modify the All Users profile. Tip: The profile path for Windows NT is %Windir%\Profiles\%UserName%. If a computer was upgraded from Windows NT, the profile path will remain in this location. For a user that logs on to a single computer, the standard local user profile works well. However, if a user logs on to multiple machines, the standard local profile doesn't work so well. Local machine profiles are separate from domain profiles, so a user who logs in to the local machine and to the domain would have separate profiles for each. If a user logs on to multiple machines, she would have different local machine and domain profiles on each machine. 2.3.5.2. Working with local user profilesWindows computers have Default User, All Users, and user-specific local profiles. The Default User profile is the template from which new user profiles are created when needed. The All Users profile extends the user's environment based on the local configuration and applications installed. The user profile itself provides the base environment settings for the user's logon session. You can view the contents of any user profile by right-clicking Start on the taskbar and selecting Explore All Users. This opens Windows Explorer with the folder path opened to the Start Menu for the All Users profile. Using the folders provided, you can then browse the settings associated with the All Users profile. Typically, you would not change any settings, since any changes you make would affect all users who log on to the computer. To browse default user settings, access %SystemDrive%\Documents and Settings\Default User. Don't make changes to the Default User folders. Instead, you should preconfigure the user environment by creating a local user profile and then copying this profile to the Default User profile. To create a preconfigured local user profile, follow these steps:
Now that you've preconfigured the user environment, any user logging on to the computer will get the default environment, providing he has a local user profile rather than a roaming user profile. 2.3.5.3. Working with roaming user profilesHaving a different profile for each logon machine makes it difficult to ensure a user has a consistent environment. To help mitigate problems that a user may experience when logging on to multiple machines, Windows allows administrators to configure a user's account with a roaming profile. Unlike a standard local profile, a roaming profile allows user settings to move with a user from computer to computer. When a user has a roaming profile, the profile is stored on a server and downloaded to a computer upon logon. When a user with a roaming user profile logs on to a new system for the first time, the system does not create a copy of the default profile for the user. Instead, the computer downloads the user's roaming profile from the server on which it is stored. Changes to roaming user profiles are tracked on a per-file basis. When a user logs off, any changes to the user's environment settings are uploaded to the server. Thus, rather than downloading the entire profile data on subsequent logons to a computer, only changes to the user profile are downloaded. You can specify that a user should have a roaming user profile using Active Directory Users And Computers or DSMOD USER. Before you set the path, however, you should configure the shared folder on a server that will be used to host the profiles. This folder should be configured so that the group Everyone has at least Change access to the shared folder. You do not need to create the individual profile folders for each user. Windows will create a user's profile folder for this when a user logs on for the first time after you've configured his account to use a roaming profile. The permissions on this folder will be set so that only the user has access. The best time to specify which users should have a roaming profile is when you create the user account. This makes configuring a roaming user profile very easy. In this case, with Active Directory Users And Computers, you can just as easily set the profile path for a group of users as you can for an individual user. To set the profile path for an individual user, follow these steps:
Tip: As part of standard account configuration, you can also specify logon scripts and home folders for users on the Profile tab. Logon scripts can contain a series of commands that should be executed whenever a user logs on. Home folders set the folder the user should use for storing files. To set the profile path for multiple users, follow these steps:
Tip: In this procedure, %UserName% is an environment variable for the user's logon name. This lets Windows create the profile folder using the logon name as the folder name. You can use DSMOD USER to specify the profile path for a user or group of users as well. Use the syntax: dsmod user UserDN -profile ProfilePath For example: dsmod user "CN=William Stanek,OU=Engineering,DC=domain,DC=local" -profile -b \\FileSvr08\Profiles\williams When a user already has an existing local user profile, and you need to move her to a roaming user profile, you should copy her existing local profile to the profile share prior to configuring her account to have a roaming profile by following these steps:
2.3.5.4. Working with mandatory user profilesIn some environments, such as classrooms or when users share computers, you might want to prevent users from making permanent changes to the desktop. You can do this using a mandatory user profile. When a user has a mandatory profile, they can log on to different computers and get the same desktop settings and change desktop settings as permitted by policy on the local computer. However, changes are not saved to in the profile and thus are lost when a user logs off. To configure a mandatory user profile, you simply change the name of the user's primary profile data file from Ntuser.dat to Ntuser.man. The Ntuser.dat file is stored in the root of the user's profile folder: either on the local machine for local profiles or on a server for roaming profiles. As profiles are hidden system files, Ntuser.dat isn't automatically displayed in Windows Explorer. To display hidden files, you must choose Tools Mandatory profiles must be available for a user to log on. If for some reason the user profile becomes unavailable, the user will not be able to log on. 2.3.6. Managing User Access and AuthenticationA key part of managing user access and authentication is to ensure that user accounts are properly configured and have valid passwords. NTFS permissions and policy settings must also be properly managed to ensure that the appropriate level access to resources is granted and that authentication works as expected. 2.3.6.1. Understanding user access and authenticationA user's access to a local computer, the domain, and the network is dependent on her logon and the policies in place to safeguard access. Authentication is the key to access. Whenever a user attempts to log on or access resources, the user's credentials are authenticated. If the user's credentials are invalid, the user will be denied logon or access to resources. If the user's credentials are valid and the user has sufficient permissions, the user will be granted logon and access to resources as appropriate for the level of permissions the user has been assigned. The most basic components of access and authentication are the user's credentials, which include the user's account configuration and the user's password. If the user's account is misconfigured, disabled, or locked out, the user will not be authenticated and will not be able to access to the computer, the domain, or network resources. Similarly, if the user's password has expired, the user will not be authenticated and will not be able to access to the computer, the domain, or network resources. The most advanced components of access and authentication are the NTFS permissions set on resources and the policy settings set in Active Directory. Managing resource access using NTFS permissions is discussed in "Managing and Maintaining Access to Network Resources," later in this chapter. The primary policy settings that affect user access and authentication are:
Unlike most other areas of Group Policy, you should manage password policy, account lockout policy, and Kerberos policy using the highest precedence Group Policy Object (GPO) linked to a domain. By default, the highest precedent GPO linked to a domain is the Default Domain Policy GPO. 2.3.6.2. Setting password policyPassword policies control how passwords are managed, whether they expire, and when they expire. Table 2-7 provides an overview of available password policies. In Group Policy, you'll find password policies under Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy.
2.3.6.3. Setting account locking policyAccount lockout policy controls whether and how accounts are locked out if successive invalid passwords are provided. Table 2-8 provides an overview of available account lockout policies. In Group Policy, you'll find password policies under Computer Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policy.
2.3.6.4. Diagnosing and resolving user account problemsAccounts can be disabled by administrators or locked out due to Account Lockout Policy. When a user tries to log on using an account that is disabled or locked out, a prompt will notify her that she cannot log on because her account is disabled or locked out. The prompt also tells her to contact an administrator. Active Directory Users And Computers shows disabled accounts with a red warning icon next to the account name. To enable a disabled account, right-click the account in Active Directory Users And Computers, and then select Enable Account. You can also search the entire domain for users with disabled accounts by typing dsquery user -disabled at a command prompt. To enable a disabled account from the command line, type dsmod user UserDN -disabled no. Once a user account has been locked out by the Account Lockout Policy, the account cannot be used for logging on until the lockout duration has elapsed or the account is reset by an administrator. If the account lockout duration is indefinite, the only way to unlock the account is to have an administrator reset it. You can unlock an account by completing the following steps:
Logon success and failure can be recorded through auditing. When account logon failure auditing is enabled, logon failure is recorded in the security log on the login domain controller. Auditing policies for a site, domain, or OU GPO are stored under Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy. 2.3.6.5. Diagnosing and resolving user authentication problemsWhen a user logs on to the network using his domain user account, the account credentials are validated by a domain controller. By default, a user can log on using his domain user accounts even if the network connection is down or there is no domain controller available to authenticate the user's logon. The user must have previously logged on to the computer and have valid, cached credentials. If the user has no cached credentials on the computer and network connection is down, or there is no domain controller available, the user will not be able to log on. Each member computer in a domain can cache up to 10 credentials by default. When a domain is operating in Windows 2000 native or Windows Server 2003 mode, authentication can also fail if the system time on the member computer deviates from the logon domain controller's system time more than is allowed in the Kerberos Policy: Maximum Tolerance For Computer Clock Synchronization. The default tolerance is five minutes for member computers. |
Computer. This starts the New Object - Computer wizard as shown in Figure 2-6.
Group. This opens the New Object - Group dialog box shown in Figure 2-8.
EAN: 2147483647
Pages: 95