Download (direct link):
Configuring domain accounts
Although the Windows 2002 and 2000 Server exams cover this material in much greater detail, the more common domain user configuration chores include the following:
* User profile: As I discuss in more detail in Chapter 12, you can specify the location of a server-based roaming user profile for a domain account, so that the user's documents and settings follow them from PC to PC. Use the Profile tab of the property sheet for this setting.
* Logon hours: You can set a schedule for permitted domain logons; use the Account tab of the property sheet.
* Idle disconnect: You can kick a user off the network after a predetermined amount of idle time; set this on the Sessions tab.
* Group membership: Change the groups to which the domain user belongs in the Member Of tab.
* Dial-in permission: Control whether the user has permission to call up remote access servers with the Dial-In tab. You can also set a callback option here for better security; see Chapter 13.
You can also disable accounts, copy them (creating a new user based on an existing user's account), change passwords, move an account to a different organizational unit, delete, and rename accounts - all from the user's property sheet in the Active Directory Users and Computers console.
Troubleshooting domain accounts
The main domain account troubleshooting issue likely to pop up on the exam has to do with cached credentials. (Credentials assert a user's identity, and in Windows XP consist of a user name and password.) Two policy settings in the Local Security Policy control panel's Security Options area deal with this issue.
The first has to do with the logon screen, which normally displays the name of the last user to log on to the computer (that is, Windows caches the user name). You can override this behavior to improve security, at the expense of some convenience, by enabling the policy Interactive Logon: Do Not Display Last User Name In Logon Screen. (Follow the logic carefully here: If you enable a policy that says 'do not do something,' then Windows will not do that thing.)
The second issue has to do with the fact that Windows XP Professional users who belong to a domain may occasionally work away from the network - or need to work on the local PC when a domain controller is unavailable. In that case, XP lets the user log on with the domain account, but only a certain number of times, defined by the policy Interactive Logon: Number Of Previous Logons To Cache. The default value is 10 logons, the maximum is 50, and a value of 0 disables credential caching.
Tip One other aspect of credential caching doesn't have anything to do with domain accounts but is worth mentioning here. If you open the User Accounts control panel, click the Advanced tab, and then click the Manage Passwords button, you can add passwords for different services and sites (for example, Microsoft Passport) to your local password cache. You specify the server name (such as *.passport.com), the user ID, and the password for that server (see Figure 10-8). All such added credentials become part of your user profile.
Figure 10-8: Adding a Passport entry to the password credentials cache.
Know the following additional tips for troubleshooting access problems with domain accounts:
* A new domain account takes time to propagate to all the domain controllers in an organization. If you've just created a new account on one server, other domain controllers can't immediately authenticate the user and permit logon.
* If a user can't log on to a domain account, ensure that the user has chosen the correct domain from the list box at the logon window, and is not trying to log on to the local PC or a different domain. Also check the log on hours restriction and any security constraints that appear on the Account tab, such as Smart Card Is Required For Interactive Logon.
* Remote dial-in access is denied by default for a new account. If a domain user can't connect to a remote access server, change the access setting on the Dial-In tab of the account property sheet from Deny to Allow.
* Domain group policies override local group policies. In Active Directory Users and Computers, right-click the domain, choose Properties, and then click the Group Policy tab to inspect policy settings for the domain that may be countermanding locally set policies. (More on policies in Chapter 11.)
Auditing User Activities
If you're reading this chapter end to end, and you're not confused yet, either your mind is seriously warped or you've been doing this sort of thing for a while in the real world. Windows XP users and groups aren't radically different from Windows NT 4.0 users and groups, after all. Not that this tidbit is much help to those of you who never had the pleasure of wrestling with NT.
In either case, whether you're warped or simply experienced, I have to throw one more iron into the fire before I can be legitimately done with Windows XP users and groups: auditing. The good news is that unlike relatively abstract concepts such as user rights, auditing is pretty easy to understand. Chapter 11 explains how to use auditing to monitor user access to files, folders, and the Registry. All I want to do here is mention logon event auditing.