|
|
In order to gain access to Windows Server 2003, a user must have a valid user account. A user account determines three important factors: when a user may log on; where within the domain or workgroup the user can log on; and the privilege level he or she is assigned. Primary user account elements are logon name, password, group membership, and allowable logon hours.
Privilege level and access permissions are assigned to a user account with security credentials. When an account is created, it is given a unique access number known as a security identifier (SID). Every group to which the user belongs has an associated SID. The user and related group SIDs together form the user account's security token, which determines access levels to objects throughout the system and network. SIDs from the security token are mapped to the access control list (ACL) of any object the user attempts to access. (The ACL is discussed in Chapter 9.) The user is granted rights to the object based on the permissions or lack of permissions the ACL indicates are assigned to him and his groups (Figure 7.1).
NOTE
The security identifier is a unique number generated when a user account or group is created. If you delete a user account and attempt to recreate it with the same user name and password, the SID will be different. This means that all objects that use the old SID to assign permissions are useless to the new user. Permissions must be reassigned to the new user account SID. The same principle applies to groups: Deleting a group and recreating a group with the same name will not generate the same group SID.
Any object trying to access a resource must do so through a user account. In this case, an object can be a computer user or an application. For instance, the Internet Information Services Web server creates the IUSR_systemname user account to provide anonymous Web users access to the local system.
Windows Server 2003 allows two types of user account: local and domain. Local accounts are supported on all Windows Server 2003 systems except domain controllers. They are maintained on the local system and are not distributed to other systems. The local security database manages the user account information. The domain user account permits access throughout a domain and provides centralized user account administration using Active Directory components. Let's take a closer look at these accounts.
Local user accounts are supported on member servers participating in domains and on standalone systems participating in workgroups. The local user account authenticates the user for local machine access only. This authentication is handled through a local security database (Figure 7.2). Local accounts do not support access to resources on other computers and they require separate logons to access remote systems.
NOTE
It is best not to create local user accounts on member servers; they cannot be centrally administered and create added administrative headaches. However, they are useful when isolating applications from the rest of the domain. Local accounts on member servers or standalone servers can be added at any time.
NOTE
The new Credential Management feature of Windows Server 2003 provides a consistent single sign-on experience for users. This can be useful for roaming users who move between computer systems. The Credential Management feature provides a secure store of user credentials that includes passwords and X.509 certificates.
The Credential Management feature provides access to authorized applications. When the user first attempts to access a targeted application, the authentication mechanism prompts the user to supply a credential. After the credential is presented, it will be associated with the requesting application. The saved credential is reused without prompting the user when access to the application on the company network is requested. To activate this feature, action must occur on both client and server sides. Action by the client: Start 
Control Panel User Accounts; action by the server (using the Windows Server 2003 or Window XP Control Panel View): Start Control Panel Other Control Panel Options Windows Keyring. The Credential Manager is disabled through the Group Policies snap-in.
At a minimum, the Administrator and Guest accounts will already exist as local accounts. These are built in to the operating system. The Administrator account permits user account management, group management, and policies for the local systems. The Guest account is designed for temporary users who require limited system access.
User accounts comprise two mandatory pieces of information: user name and password. Other personal information is optionally tracked. Following are some restrictions and suggestions on the creation of user names and passwords.
User and logon names are interchangeable. Domain account names must be unique in the domain, although the same logon name can be used on several systems with local logon configurations. Logon names are not case-sensitive, must not contain more then 20 characters, and must not contain the following characters: +, *, ?, <, >, /, \, [, ], :, and ;.
Passwords should not contain such items as full words, family names, pop culture references, pets, and locations. They should contain both numeric and alphanumeric characters and should not be the same as the user name. The maximum number of characters is 128 and the minimum is determined by group policy. Password filtering is discussed in Chapter 11, "Additional Security Issues and Solutions."
Creating a local user account involves the steps that follow. As noted, local user accounts are available only on member servers and workstations. Domain controllers have no local accounts and creating them on member servers is not recommended. However, if there is a reason to provide temporary restricted user accounts, here is how:
Create a new user account on a workgroup server by selecting Start Programs Administrative Tools Computer Management (Figure 7.3).
From the Computer Management snap-in, click System Tools Local Users and Groups. Right-click Users, then select New Users. The New User dialog box should appear (Figure 7.4).
NOTE
Windows Server 2003 permits administrators to add computer accounts to security groups from the Local Users and Groups snap-in. This is useful for determining which computer accounts are admitted into the Session Directory Computers Group when administering Terminal Services.
The User name field will contain the user's logon name. The password properties are the same as those for the domain user discussed in the next section. User accounts are viewed in the details window of the Computer Management tool under the Users node.
Enter the user's user name, full name, and description. Click Create.
Windows 2000 Professional and Windows XP are designed either as a client system in a network environment or as a standalone workgroup computer. In this example, we illustrate the client setup for Windows 2000 Professional because it is a more complex process than setting up Windows XP. Setting up Windows XP user accounts is also achieved through the Control Panel, but it leads the user or administrator through a simplified set of wizard-based dialog boxes. Domain and local accounts that already exist may be assigned access to the local system using the following steps:
To permit existing user accounts access to the local system, select Start Settings Control Panel (Figure 7.5). From Control Panel, double-click the Users and Passwords icon. The Users and Passwords dialog box should now display all user accounts on the system (Figure 7.6).
To give another user access to the local system, click Add.
Choose a domain name and or local user account name and type it into the Domain box (Figure 7.7). If the account is a local one, enter the name of the local system. Click Next to continue.
On the next screen, enter a valid password for the user. Enter it also in the Confirm password box.
The next screen determines the permissions level for the user (Figure 7.8). There the option assigns the user to the Power Users group; the Restricted user selection assigns the user to the Users group. The user may become a member of any other security group using the Other option. These initial membership settings may be easily modified later.
Click Finish.
The account will have the access rights you have just assigned. Denying a user account access to the local system is accomplished by clicking Remove in the Users and Passwords dialog box (Figure 7.6).
A domain user account allows access to resources in a domain or domain tree. This account is created in a domain container in the Active Directory database and then propagated to all other domain controllers in the domain, permitting the user to log on to any of the domain's systems or resources. The domain model centralizes user account administration from all domain controllers or member servers in the domain.
Once the user has been authenticated against the Active Directory database using the Global Catalog, an access token is obtained. All resources in the domain will determine permissions based on the user's access token and ACL. The access token is dropped from the system when the user logs off.
The creation of a domain user account involves the assignment of a logon name, a password, group membership, and several optional steps. Windows Server 2003 default settings dictate that only a member of the Administrators group (like Domain Admins or Enterprise Admins) can add users to a domain; however, administrative privileges may be delegated.
The following steps should be taken to add a domain user account:
Log in with administrative privileges.
Select from the Start menu Programs Administrative Tools Active Directory Users and Computers to bring up the Active Directory Users and Computers snap-in (Figure 7.9). Select the appropriate Active Directory container to house the new user account. This may be a domain or an OU.
Next, click New User to create the new user account. This will bring up the New Object—User window (Figure 7.10).
Enter the user's first and last names in the First name and Last name boxes, respectively. Windows Server 2003 automatically enters the Full Name. Enter a user name in the box under User logon name. This name, along with the user's domain name (such as jengineer@Entcert2.com), uniquely identifies a user in a domain, tree, or forest. This is not to be confused with an external Internet DNS domain name. To access the domain from a client server that is not running Windows Server 2003, use the downlevel (e.g., Windows NT 4.0 and 3.51) logon name as the user account name. Click Next.
Enter a password for the user in the Password box (Figure 7.11). Retype the password in the Confirm password box. Check the appropriate boxes for the password options, as shown in Table 7.1.
Click Next to bring up the user account confirmation screen (Figure 7.12). This verifies the restrictions and the account name assigned to the new domain user account. Click Finish to finalize the new account and view the new user within her Active Directory container from the Active Directory Users and Computers snap-in.
|
Property |
Description |
|---|---|
|
User must change password at next logon |
Password just assigned will be changed the first time the new user logs on. |
|
User cannot change password |
Account's password can be changed only with Administrator privileges. |
|
Password never expires |
User is not required to change his or her password periodically. |
|
Account is disabled |
Deactivate an account when user does not need it; may be useful for extended leaves or when planning future accounts. |
As with all Windows Server 2003 objects, the user account has a number of associated properties or attributes. Once the domain user account has been created, these properties may be modified from the Active Directory Users and Computers snap-in. Set the appropriate tabs by using the following steps. An explanation of each tab setting is provided in subsequent sections.
From the Start menu, select Programs Administrative Tools Active Directory Users and Computers snap-in.
Right-click the desired user select Properties. Table 7.2 shows the default tabs in the basic Windows Server installation (with Terminal Server).
The General tab (Figure 7.13) contains the domain user's first and last names, description (usually a job title that will appear on the management console), office location, telephone number(s), e-mail address, and home page(s).
The Address tab (Figure 7.14) should contain a post office mailing address. It's helpful to have this information when you want to mail software upgrades, manuals, and other packages.
|
Tabs |
Description |
|---|---|
|
Member Of |
The user's defined group membership |
|
Dial-in |
Remote access and callback options |
|
General |
User's first name, last name, display name description, office location, telephone, e-mail, and Web pages |
|
Address |
User's post office mailing address |
|
Account |
Logon name, domain, logon hours, logon to server name, account options, and account expiration date |
|
Profile |
User profile path, profile script, home directory path and server, and shared document folder location |
|
Telephones/Notes |
Home, pager, and mobile phone numbers and comments on where to contact user |
|
Organization |
Job title, company, department, manager, and people who report to user Environment Applications to run from Terminal server client |
|
Sessions |
Timeouts for Terminal Services |
|
Remote Control |
Permissions for monitoring Terminal Service sessions |
|
Terminal Service Profile |
Location for Terminal Service home directory |
The Account tab (Figure 7.15) looks very similar to the screen used to create the domain user account. However, there are two new options here, listed in Table 7.3.
Clicking Logon Hours displays the days and times of the week that the domain user is permitted to log on to the domain (Figure 7.16), which is useful for preventing employees from logging on while backups are being performed. To prevent sharing violations, current user sessions with backup targets must be terminated before backups begin. Logon hour selections are made in two ways:
Select day and hour cells and click Logon Permitted to indicate the time "zone" during which a user is permitted to log on.
Select day and hour cells and click Logon Denied to create a time zone during which a user is not permitted to log on.
NOTE
Changes to the user account will not affect a user who is logged on to the system. The restrictions will apply during the next attempted connection.
|
Definition |
Description |
|---|---|
|
Save password as encrypted clear text |
Must be selected on Macintosh computers, which store passwords only in encrypted clear text. |
|
Account expires |
Takes precedence over the Password never expires selection. The Account expires date must be advanced to reenable the user account. |
Clicking Log On To from the Account properties tab displays the Logon Workstations window (Figure 7.17). This facility allows the administrator to restrict user from logging on to certain computers in the domain. The main issue here is that the computer name must be the NetBIOS name. Also, the NetBIOS protocol must be installed on all machines that use this account policy. Remember that a machine's NetBIOS name must be fewer than 16 characters.
The Telephones tab allows the storage of home, pager, mobile, fax, and IP phone numbers for quick reference (Figure 7.18). Entering information into the boxes of this tab is optional. Clicking Other allows you to enter alternative numbers. The Comments section provides room to track the user's schedule and availability at these numbers.
Member Of (Figure 7.19) is perhaps one of the most important user account properties tabs. Each domain user belongs by default to the domain users' group. To add the user to other security groups, click Add and choose a group from the directory. Group selection can be made from the current domain and trusted domains. As discussed in subsequent sections, the user inherits the appropriate permissions and rights associated with that group.
A user can be granted access to the domain through a telephone dial-in or virtual private network (VPN) connection only if Allow access is selected on the Dial-in tab (Figure 7.20). When the domain is switched to native mode, the Control Access through Remote Access Policy option is displayed instead.
There are three options for the treatment of dial-in authority. The default is to permit no callbacks; the user can dial directly into the domain through a Remote Access Service (RAS) server to gain access to the network. The second option permits a defined callback; the user can specify a callback telephone number that the RAS server will recognize in order to establish a remote session. This is good for traveling professionals and prevents large long-distance telephone bills. It also provides phone records of people who log on to the server. Finally, a single predefined number can be established for dial-in security. The RAS server will call back only the number designated in the Always Callback to field, so only someone at that telephone number can establish a RAS session.
A user's profile determines the desktop environment. This includes such items as the display type, applications available from the Start menu, shortcuts on the desktop, and desktop arrangement. Connections to remote computers are remembered and reestablished from the last logon session. Profiles offer consistent desktop settings and document management regardless of which system in the domain the user logs on to.
Every user has a profile that defines how, when, and where a logon is possible. The three types of user profile in Windows Server 2003 are:
Local user profiles are maintained on each system the user logs on to in the user's profile directory. If the user logs on to another system in the domain, the local profile does not apply. The first time the user logs on to a system, a profile is created if one does not already exist. It is copied from the \Document and Settings\Default User profile. In other words, the Default User folder is a template for the creation of the new local user profile, which is created in the Document and Settings\userid directory (unless otherwise specified in the user account Properties tab).
Roaming user profiles allow domain users to move from system to system and maintain one profile. It is placed in a shared directory on a server in the domain, and whenever a user starts a session on a system within that domain, the profile is copied from the shared server folder to local disk space. All the documents and environmental settings for the roaming user are stored locally on the system, and, when the user logs off, all changes to the locally stored profile are copied to the shared server folder. Therefore, the first time a roaming user logs on to a new system the logon process may take some time, depending on how large his profile folder is. A My Documents folder can be very large. However, the next time the user logs on to this particular system, the profile server will update the local profile only with files that have changed since the last session. If a roaming user is attempting to log on to a system that cannot establish a connection with the shared server folder, a new local profile is created based on the system's default profile. This new information is not copied to the shared server profile folder.
NOTE
Windows Server 2003 has added policies to govern roaming user behavior including the ability to disable roaming profiles and to prevent propagation of profiles made to the local system to the users shared profile folder.
Mandatory user profiles are read-only and cannot be changed. Modifications to the desktop are not saved to the user's profile once she logs off, so mandatory profiles are used when users must see the same desktop consistently. A user's profile is made mandatory by changing the file extension on the NTUSER.dat file to NTUSER.man.
Regardless of whether the user's profile is roaming or local, the profile directory has a common folder structure. Table 7.4 describes the standard Windows Server 2003 profile folders.
There are also some hidden profile directories (Table 7.5 and Figure 7.21) that can be viewed by selecting Tools Folder Options from Windows Explorer, clicking the View tab, and then selecting Show hidden files from the View tab's advanced settings.
|
Sub-Profile Directory |
Description |
|---|---|
|
Cookies |
Personalized data files stored on your system by Web sites that you visit; must be disabled/enabled at the browser level |
|
Desktop |
Shortcuts and files that comprise the user's desktop |
|
Favorites |
Files and folders used as Favorite pull-down options from My Computer, My Computer in Explorer mode, and Internet Explorer |
|
My Documents |
Default location for file storage of Microsoft Office products |
|
Start Menu |
All applications the user will have access to from the Start menu |
|
File |
Description |
|---|---|
|
Application Data |
Application-specific data such as preferences and licensing. |
|
Local Settings |
Contains a history of Web sites visited through the browser and all documents, applications, and Help pages accessed from My Computer, classified into today's, yesterday's, last week's, and two weeks' ago time frames. Application data, such as Outlook Express Inbox, is also stored here. |
|
NetHood |
Domains and file structures accessed from My Network Places. This is the system's current network neighborhood. |
|
PrintHood |
Printer data information and shortcuts. |
|
My Recent Documents |
Recently accessed files and folders. |
|
SendTo |
Shortcuts to common file storage areas. |
|
Templates |
Templates for Microsoft Office applications. |
Besides understanding the contents of folders in a user's profile, it is important to understand the \Document and Settings\All User profiles. Two program groups are supported under Windows Server 2003 (Figure 7.22): common and personal. The most effective profile is the individual user's profile combined with the All Users profile
Common program groups are applied to all users who log on to a system. Their profile is located in the \Document and Settings\All User folder and includes a subset of the folder structure previously discussed. For instance, the Start menu folder in the \Document and Settings\All User directory dictates program availability from the Start menu for all users who log on to the system. Each user's personal profile, locally located in \Document and Settings\username (user name varies), is then overlaid on this common profile to provide additional Start menu application access and custom desktop setups. The user's personal profile, with the information in Table 7.5, can be either locally stored on each system in the domain or defined as roaming.
NOTE
The \Document and Settings\All Users folder contains profile information that applies to all users. For example, say you wanted to restrict access to Microsoft Excel from the Start menu. The \Document and Settings\All Users\Start Menu\Program folder would contain the Microsoft Excel shortcut if it was installed for general access. To restrict some users from access to it from the Start Program menu, remove the shortcut from the All Users folder and place it in selected personal user profiles. Of course, the Microsoft Excel executable should be restricted to users intended to run the application. Distributing applications to specific users could also be handled using the assign and publish methods, which are discussed in Chapter 8.
Now that you have some background, we can apply the user profile to individual user accounts. The Profile tab (Figure 7.23) displays several fields in relation to a user's profile:
Profile path dictates where a user's profile will be stored. If no directory is entered, the default location is \Documents and Settings\username.
Logon script contains the path to an optional executable or batch file. Users who are logged on to Windows Server 2003 systems may take advantage of JavaScript (.js) and Visual Basic Scripting (.vbs) in addition to the traditional MS-DOS command scripts (.bat, .com, and .exe). Stick with the MS-DOS scripts for downlevel operating systems that may not support the Windows Scripting Host (WSH).
The home directory is specified on the local machine in the form Drive label:\directory path or targeted on a shared folder accessible through the network. The network connection requires a network drive letter (available from the pull-down menu), which identifies how the remote connection will be referenced from the local machine, a machine name, and a directory path. The To field should be in the form \\system name\directory path. The remote directory will be displayed from My Computer and will be the default directory within the command prompt. This is a good way to centralize your documents on a networked server for backup convenience and version control.
NOTE
The command prompt defaults to the home directory. However, if most administrative shell scripts, for example, are located in a directory called d:\scripts, you may want to make that directory your default instead. The home directory is also the default file storage directory for some applications such as Notepad. These applications will default to the home directory if it contains other files that match the application's type. Most Microsoft Office applications, however, default to the My Documents directory and ignore the home directory setting.
The following example illustrates how to set up a user profile. For example, create a new user account with the user ID 1user.
View existing user profiles by clicking Start Settings Control Panel. Double-click System. Click Advanced and click Settings (Figure 7.24).
Notice that Profiles stored on this computer does not list luser, because a profile for 1user has not been created yet.
Log off your system and log back on under the new account, luser. The profile for luser has now been created by copying \Document and Settings\Default User to \Document and Settings\luser.
NOTE
You may have to configure local system group policies to permit local log on. From a policy setting snap-in (see Chapter 8), add the luser to the policy setting list by invoking Computer Configuration Windows Settings Security Settings Local Policies User Rights Assignment Log on locally.
Right-click the desktop and select Properties. Choose a new theme from the Theme pull-down menu. Log off and log back on as Administrator.
Repeat step 1 and view the current user profiles. The account luser should now exist as a local profile.
Log off and log back on as luser. Notice that the user's screen background is preserved.
The roaming user profile is set up by the following steps:
Log on as Administrator and run mmc from the command prompt. Add the Active Directory Users and Computers snap-in and create a new domain user account named ruser.
Create a new share with Full Control permissions to the Everyone group on a network server called profiles. This will later be referenced as \\servername\profiles.
From the Active Directory Users and Computers snap-in for the domain, right-click ruser and select Properties. Select Profile and type the name of the roaming user folder in the Profile path box (Figure 7.25). Use the form \\servername\profiles\ruser to ensure that the correct network server path is accessed.
NOTE
When setting up a roaming user profile, it is extremely important to follow these steps precisely. Any deviation will cause permission problems.
Before we log on to the new account, a profile must be copied to the roaming profiles directory (\\servername\profiles\ruser) so that the roaming profile folder is used and a local one is not created. Open Control Panel and double-click the Systems icon. Click the Advanced tab and click User Profiles Settings.
Select the luser account created earlier and click Copy To.
Enter the roaming profile folder directory in the form \\servername\Profiles\ruser (Figure 7.26).
Under Permitted to use, click Change.
Type ruser in the Enter the object name to select field (Figure 7.27).
Click OK to create the new directory \\servername\profiles\ruser, copy the luser profile to the new location, and permit the new remote user, ruser, access to the directory and child directories.
Click OK on the Copy To dialog box.
Click OK on the User Profiles box. Click OK on the Systems Properties dialog box.
Permit local logon if system is a domain controller (see earlier note).
Close all applications and log off.
Log in as ruser. Notice that the desktop environment is initially the same as luser. Changes to the ruser environment will be saved on the shared \\server\ profiles directory. Try logging on from another server in the same domain. The ruser's profile should follow the user throughout the domain.
 |
|
|
| Top |