As an administrator, managing users, groups, and computers will probably be a significant part of your duties and responsibilities. Managing users, groups, and computers encapsulates the important duties of a system administrator because of the way convenience, performance, fault tolerance, and security must be balanced.
Microsoft Windows operating systems have come a long way from Microsoft Windows NT 4 when all you had was User Manager for Domains, two default users on installation, and only global and local groups. Managing users in Windows Server 2003 can be a daunting task for Windows NT administrators. Yet, when moving from Microsoft Windows 2000, there is little difference in the handling of users. The next part of this chapter is dedicated to helping you plan, manage, and administer user accounts in a secure and efficient manner.
It is a good idea to have a solid grasp of fundamental concepts that underpin the managing of users. In the first part of the chapter, I will describe the types of users Microsoft Windows Server 2003 defines.
User In Windows Server 2003, 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 username, password, the groups of which the user is a member, and other descriptive information, such as address and phone numbers, as well as many other user descriptions and attributes, such as security and remote control configurations.
InetOrgPerson InetOrgPerson is a new type of user 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 Lightweight 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 security principal. The InetOrgPerson is compatible with X.500 and LDAP directory services.
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 ID (SID). There are neither passwords 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 2003 installation or stand-alone server is configured to be a domain controller and Active Directory is installed. It is a good idea to rename the Administrator account for security reasons. The default user accounts are found by opening Active Directory Users And Computers, then examining the contents of the Builtin and Users containers. They include the following accounts:
Administrator—This is the account that has full control over the computer or domain. You should have a very strong password for this account. The Administrator is a member of these groups: Administrators, Domain Admins, Domain Users, and Group Policy Creator Owners. In a forest root domain, the Administrator is also a member of the Enterprise Admins and Schema Admins groups. The Administrator account can never be deleted. However, you can disable it (which is a new feature for Windows Server 2003) or rename it. Either of these actions is a good practice to ensure a secure domain and network.
Guest—The Guest account does not require a password and 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 2003 server a domain controller.
HelpAssistant—This account is a dynamic object created when a Remote Assistance session is started, and is deleted by the Remote Desktop Help Session Manager service when there is no session pending or active.
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 account policy for domain accounts. The one account policy allowed by domain accounts must be defined in the Default Domain Policy. The account policy is then enforced by the domain controllers in the domain. Domain controllers always obtain the account policy from the Default Domain Policy Group Policy Object (GPO), even if there is a different account policy applied to the organizational unit (OU) that contains the domain controller.
By default, computers joined to a domain will also receive the same account policy for their local accounts. However, local account policies can be different from the domain account policy, such as when you specifically define an account policy for local accounts. For example, if you configure an account policy for a GPO linked to the Boston OU, when users in Boston log on to Active Directory they'll obtain their account policy from the Default Domain Policy instead of the GPO linked to their OU. The only exception is when users in Boston log on locally to their machine instead of logging on to Active Directory, in that case any account policy in their OU GPO is applied to their machine's local GPO and enforced.
Tip
Some security options are also obtained from the Default Domain Policy GPO
Two policies in Computer ConfigurationWindows SettingsSecurity Settings Local PoliciesSecurity 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 only obtained from the Default Domain Policy GPO. For local accounts, the settings for these policies can come from a local OU GPO if one is defined and applicable.
Account policies in a domain are configured through the Group Policy Editor (GPE) in Active Directory Users and Computers. Right-click the domain name, select Properties, and then click the Group Policy tab, as shown in the following screen. Afterward, double-click the Default Domain Policy GPO. The account policies are located in Computer ConfigurationWindows SettingsSecurity SettingsAccount Policies.
For local accounts, you can configure alternate account polices for an OU. Right-click the OU name, select Properties, and then click the Group Policy tab. By default, user policies for an OU are inherited from domain policy. You can define a specific OU policy by clicking New. The Account Policies are located in Computer ConfigurationWindows SettingsSecurity SettingsAccount Policies.
To change group policies, you must be a member of the Domain Admins group or Enterprise Admins group in Active Directory. Group policy is configured with the Group Policy Editor. You edit group policies for the account policies by double-clicking a policy, and then defining the policy setting. The account policies for a domain contain three subsets—Password Policy, Account Lockout Policy, and Kerberos Policy. While account policies for OUs include Password Policy and Account Lockout Policy, they do not include Kerberos Policy. Kerberos Policy can only be set at the domain level.
Password policies for domain user accounts and local user accounts are very important in preventing unauthorized access. There are six settings for password policies that enable you to control how passwords are managed. As shown in Figure 37-1, these policies are located in Computer ConfigurationWindows SettingsSecurity SettingsAccount Policies Password Policy.
The settings are as follows:
Enforce Password History When users change their passwords, this setting determines how many old passwords will be maintained and associated with each user. 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 controllers 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 environment 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 password 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 environment where security is critical, you would probably set this to a shorter time, and to a longer time where security not as tight. This setting must be configured to be less than the Maximum Password Age policy. The default is 1 day on a domain controller and 0 days on standalone servers.
Minimum Password Length This is the number of characters that sets the minimum requirement for the length of the password. Again, a more critically secure environment may require longer password lengths than one with reduced security requirements. As shown in Figure 37-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 defined, 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 characters, such as the percentage sign (%) and the asterisk (*). (Complexity requirements are enabled by default on domain controllers and disabled by default on stand-alone servers for Windows Server 2003.)
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 2003. Enabling this policy is basically the same as storing passwords as plain text and is used when applications 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.
The Account Lockout Policy is invoked after a local user or a domain user has been locked out of his or her account. There are three settings for account lockout policies, located in Computer ConfigurationWindows SettingsSecurity SettingsAccount PoliciesAccount Lockout Policy. They are the following:
Account Lockout Duration If a user does become locked out, this setting determines how long the user will be locked out before the user account is unlocked. There is no default setting, because this setting is dependent on the account lockout threshold setting. The range is from 0 through 99,999 minutes. The account will be locked out indefinitely when this is set to 0 and therefore will require an administrator to unlock it.
Account Lockout Threshold This setting determines how many failed attempts at logon 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 Threshold policy is enabled.
Kerberos is an authentication system designed for secure exchange of information as discussed in the section entitled "NTLM and Kerberos Authentication". Windows Server 2003 has five settings for Kerberos Policy, which are applied only to domain user accounts. The policies are located in Computer ConfigurationWindows SettingsSecurity SettingsAccount PoliciesKerberos Policy. They are as follows:
Enforce User Logon Restrictions If you want to validate every ticket session request against the user rights, keep the default setting enabled.
Maximum Lifetime For Service Ticket The default is 600 minutes, but this setting must be greater than 10 minutes, and also must be less than or equal to what is configured for the Maximum Lifetime For User Ticket setting. The setting does not apply to sessions that have already been validated.
Maximum Lifetime For User Ticket This is different from the Maximum Lifetime For Service Ticket setting. Maximum Lifetime For User Ticket sets the maximum 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 Service Ticket setting is used to access a particular service. The default is 10 hours.
Maximum Lifetime For User Ticket Renewal This user account security policy object configures the maximum amount of time the ticket may be used. The default is seven days.
Maximum Tolerance For Computer Clock Synchronization Sometimes workstations and servers have different local clock times. This setting allows you to configure a tolerance level (defaults to 5 minutes) for this possible difference so that Kerberos authentication does not fail.
Note
In Windows Server 2003 Standard and Enterprise editions using Active Directory with all Password Policies disabled, if you change the Minimum Password Length setting to less than seven characters (the default), you will 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.
All user accounts have specific capabilities, privileges, and rights. When you create a user account, you can grant the user specific capabilities by making the user a member of one or more groups. This gives the user the capabilities of these groups. You then assign additional capabilities by making a user a member of the appropriate groups or withdraw capabilities by removing a user from a group.
In Windows Server 2003, 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 and unchangeable, they can be granted to users by making them members of the appropriate group or delegated by granting the capability specifically, for example, the ability to create, delete, and manage user accounts. This capability is assigned to administrators and account operators. Thus, if a user is a member of the Administrators group, the user can create, delete, and manage user accounts.
Other capabilities of accounts, such as permissions, privileges and logon rights, can be assigned. The access permissions for accounts define the operations that can be performed on network resources. For example, permissions control whether a user can access a particular shared folder. You can assign access permissions to users, computers, and groups as discussed in Chapter 21. The privileges of an account grant permissions to perform specific tasks, such as the ability to change the system time. The logon rights of an account grant logon permissions, such as the ability to log on locally to a server.
An important part of an administrator's job is being able to determine and set permissions, privileges, and logon rights as necessary. Although you can't change a group's built-in capabilities, you can change a group's default privileges and logon rights. For example, you could revoke network access to a computer by removing a group's right to access the computer from the network. Table 37-1 provides an overview of the default privileges assigned to groups. Table 37-2 provides an overview of the default logon rights assigned to groups.
Table 37-1. Default Privileges Assigned to Groups
Privilege | Description | Groups Assigned by Default in Domains |
|---|---|---|
Act As Part Of The Operating System | Allows a process to authenticate as any user. Processes that require this privilege must use the LocalSystem account, which already has this privilege. | None |
Add Workstations To Domain | Allows users to add new computers to an existing domain. | Authenticated Users on domain controllers |
Adjust Memory Quotas For A Process | Allows users to set the maximum amount of memory a process can use. | Administrators, Local Service, and Network Service |
Back Up Files And Directories | Allows users to back up the system regardless of the permissions set on files and directories. | Administrators, Backup Operators, and Server Operators |
Bypass Traverse Checking | Allows users to go through directory trees even if a user doesn't have permissions to access the directories being passed through. The privilege doesn't allow the user to list directory contents. | Authenticated Users and Administrators on domain controllers; on member servers and workstations, Administrators, Backup Operators, Power Users, Users, and Everyone |
Change The System Time | Allows users to set the time for the computer's clock. | Administrators and Server Operators on domain controllers; on member servers and workstations, Administrators and Power Users |
Create A Pagefile | Allows users to create and modify the paging file size for virtual memory. | Administrators |
Create A Token Object | Allows processes to create token objects that can be used to gain access to local resources. Processes that require this privilege must use the LocalSystem account, which already has this privilege. | None |
Create Global Objects | Allows a process to create global directory objects. Most components already have this privilege and it's not necessary to specifically assign it. | None |
Create Permanent Shared Objects | Allows processes to create directory objects in the Windows object manager. Most components already have this privilege and it's not necessary to specifically assign it. | None |
Debug Programs | Allows users to perform debugging. | Administrators |
Enable User And Computer Accounts To Be Trusted For Delegation | Permits users and computers to change or apply the trusted account for delegation setting, provided they have write access to the object. | Administrators on domain controllers |
Force Shutdown Of A Remote System | Allows users to shut down a computer from a remote location on the network. | Administrators and Server Operators on domain controllers; on member servers and workstations, Administrators |
Generate Security Audits | Allows processes to make security log entries for auditing object access. | Local Service and Network Service |
Increase Quotas | Allows processes with write access to a process to increase the processor quota assigned to those processes. | Administrators |
Increase Scheduling Priority | Allows processes with write access to a process to increase the scheduling priority assigned to those processes. | Administrators |
Load And Unload Device Drivers | Allows users to install and uninstall Plug and Play device drivers. This doesn't affect device drivers that aren't Plug and Play, which can only be installed by administrators. | Administrators and Printer Operators |
Lock Pages In Memory | In Windows NT, allowed processes to keep data in physical memory, preventing the system from paging data to virtual memory on disk. | Not used in Windows 2000 or Windows Server 2003 |
Manage Auditing And Security Log | Allows users to specify auditing options and access the security log. You must turn on auditing in the group policy first. | Administrators |
Modify Firmware Environment Values | Allows users and processes to modify system environment variables (not user environment variables). | Administrators |
Perform Volume Maintenance Tasks | Allows administration of removable storage, disk defragmenter, and disk management. | Administrators |
Profile A Single Process | Allows users to monitor the performance of non-system processes. | Administrators on domain controllers; on member servers and workstations, Administrators and Power Users |
Profile System Performance | Allows users to monitor the performance of system processes. | Administrators |
Remove Computer From Docking Station | Allows undocking a laptop and removing from network. | Administrators, Power Users, and Users |
Replace A Process Level Token | Allows processes to modify the default token for subprocesses. | Local Service and Network Service |
Restore Files And Directories | Allows restoring backed-up files and directories, regardless of the permissions set on files and directories. | Administrators, Backup Operators, Server Operators on domain controllers; on member servers and workstations, Administrators and Backup Operators |
Shut Down The System | Allows shutting down the local computer. | Administrators, Backup Operators, and Server Operators on domain controllers; on member servers, Administrators, Backup Operators, and Power Users; on workstations includes Users |
Synchronize Directory Service Data | Allows users to synchronize directory service data on domain controllers. | None |
Take Ownership Of Files Or Other Objects | Allows users to take ownership of any Active Directory objects. | Administrators |
Table 37-2. Default Logon Rights Assigned to Groups
Logon Right | Description | Groups Assigned by Default in Domains |
|---|---|---|
Access This Computer From The Network | Permits remote access to the computer. | Administrators, Authenticated Users, Everyone on domain controllers; on member servers and workstations, Administrators, Backup Operators, Power Users, Users, and Everyone |
Allow Logon Locally | Grants permission to log on to the computer interactively at the console. | On domain controllers, Administrators, Account Operators, Backup Operators, Print Operators, and Server Operators; on member servers and workstations, Administrators, Backup Operators, Power Users, Users, and Guest |
Allow Logon Through Terminal Services | Allows access through Terminal Services; necessary for remote assistance and remote desktop. | Administrators on domain controllers; on member servers and workstations, Administrators, Remote Desktop Users |
Deny Access To This Computer From The Network | Denies remote access to the computer through network services. | None |
Deny Logon As Batch Job | Denies the right to log on through a batch job or script. | None |
Deny Logon As Service | Denies the right to log on as a service. | None |
Deny Logon Locally | Denies the right to log on to the computer's keyboard. | None |
Deny Logon Through Terminal Services | Denies right to log on through Terminal Services. | None |
Log On As A Batch Job | Grants permission to log on as a batch job or script. | Local Service |
Log On As A Service | Grants permission to log on as a server. LocalSystem account has this right. Services that run under separate accounts should be assigned this right. | Network Service |
The most efficient way to assign user rights is to make the user a member of a group that already has the right. In some cases, however, you might want a user to have a particular right but not have all the other rights of the group. One way to resolve this problem is to give the user the rights directly. Another way to resolve this is to create a special group for users that need the right. This is the approach used with the Remote Desktop Users group, which was created by Microsoft to grant Allow Logon Through Terminal Services to groups of users.
You assign user rights through the Local Policies node of Group Policy. Local policies can be set on a per-computer basis using a computer's local security policy or on a domain or OU basis through an existing group policy for the related domain or OU. When you do this, the local policies apply to all accounts in the domain or OU.
You can assign user rights for a domain or OU by completing the following steps:
User policies in a domain are configured through the Group Policy Editor in Active Directory Users And Computers. Right-click the domain or OU name, select Properties, and then click the Group Policy tab.
Select the policy you want to work with, and then click Edit. Access the Local Policies node by working your way down the console tree. Expand Computer Configuration, Windows Settings, Security Settings, Local Policies, and User Rights Assignment, as shown in Figure 37-3.
To configure a user right, double-click a user right or right-click it and select Security. This opens a Properties dialog box, as shown in Figure 37-4. If the policy isn't defined, select Define These Policy Settings. To apply the right to a user or group, click Add User Or Group. Then, in the Add User Or Group dialog box, click Browse. This opens the Select Users, Computers, Or Groups dialog box.
Type the name of the user or group you want to use in the field provided, and then click Check Names. By default, the search is configured to find built-in security principals, groups, and user accounts. After you select the account names or groups to add, click OK. The Add User Or Group dialog box should now show the selected accounts. Click OK again.
The Properties dialog box is updated to reflect your selections. If you made a mistake, select a name and remove it by clicking Remove. When you're finished granting the right to users and groups, click OK.
User rights can also be applied to a specific computer. However, remember that domain and OU policy take precedence over local policy. This means that any settings in these policies will override settings you make on a local computer.
You can apply user rights locally by completing the following steps:
Start Local Security Policy by clicking Start, Programs or All Programs, Administrative Tools, Local Security Policy.
Under Security Settings, expand Local Policies and then User Rights Assignment.
Double-click the user right you want to modify. The Properties dialog box shows current users and groups that have been given the user right.
You can apply the user right to additional users and groups by clicking Add User Or Group. This opens the Select Users Or Groups dialog box, which you can use to add users and groups.
Click OK twice to close the open dialog boxes.
As a member of the Account Operators, Enterprise Admins, or Domain Admins group, you can use Active Directory Users And Computers to create user accounts. Follow these steps:
Click Start, Programs or All Programs, Administrative Tools, and Active Directory Users And Computers. This starts Active Directory Users And Computers.
By default, you are connected to your logon domain. If you want to create OUs in a different domain, right-click the Active Directory Users And Computers node in the console tree, and then select Connect To Domain. In the Connect To Domain dialog box, type the name of the domain to which you want to connect, and then click OK. Alternatively, you can click Browse to find the domain to which you want to connect in the Browse For Domain dialog box.
You can now create the user account. Right-click the container in which you want to create the user, point to New, and then select User. This will start the New Object– User Wizard.
When you create a new user, you're prompted for the first name, initials, last name, full name, and logon name, as shown in Figure 37-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.
When you click Next, you can set the user's password and account options. The password must meet the complexity requirements set in the group policy. As shown in Figure 37-6, these options are as follows:
User Must Change Password At Next Logon
User Cannot Change Password
Password Never Expires
Account Is Disabled
Click Next, and then click Finish. If you use a password that doesn't meet the complexity requirements of group policy, you'll see an error and you'll have to click Back to change the user's password before you can continue.
If you double-click a user account in Active Directory Users And Computers, a Properties dialog box appears, with tabs allowing you to configure the user's settings. Table 37-3 lists the user account properties.
Table 37-3. User Account Properties
Account Tab | Description |
|---|---|
General | Used to manage the account name, display name, e-mail address, telephone number, and Web page |
Address | Used to manage geographical address information |
Account | Used to manage logon name, account options, logon times, and account lockout |
Profile | Used to manage the user profile configuration (profile path, logon script) and Home Folder |
Telephones | Used to manage home phone, pager, fax, IP phone, and cellphone numbers |
Organization | Used to manage the user's title and corporate information (department, manager, direct reports) |
Environment | Used to manage the Terminal Services startup environment |
Sessions | Used to manage Terminal Services timeout and reconnection settings |
Remote Control | Used to manage remote control settings for Terminal Services |
Terminal Services Profile | Used to manage the user profile for Terminal Services |
COM+ | Used to select the user's COM+ partition set |
Published Certificates | Used to install or remove user's X.509 certificates |
Member Of | Used to add the user to or remove the user from selected groups |
Dial-in | Used to set the user's dial-in or virtual private network (VPN) access controls as well as callback, IP address, and routing options for dial-in or VPN |
Object | Displays the canonical name of the user object with dates and Update Sequence Numbers |
Security | Used to configure advanced permissions for users and groups that can access this user object in Active Directory |
Note
The number of tabs in a user's Properties dialog box will vary depending upon the software installed. For example, adding Exchange mail services will add multiple property sheets (tabs) to each user's Active Directory account. Also, to view the Published Certificates, Objects, or Security property sheets, you must be in Advanced view. To access Advanced view, select Advanced Features from the View menu in Active Directory Users And Computers.
Most of the time, as the administrator, you will use a number of the account settings regularly. The General tab has the name and e-mail for the user. The Account tab has the user name and lets you configure logon hours or logon settings. There is also an area on the Account tab that allows the account to be unlocked. This latter setting is a quick way to unlock an account when a user has forgotten a password or is locked out of the account for some other reason. The Profile tab lets you set a user profile, logon script, and home folder. The Member Of tab lets you add the user to various groups. The Security tab lets you set the way permissions for groups or users are configured and provides access to the Effective Permissions tool via the Advanced Button.
In Active Directory, user accounts are defined as objects—as are group and computer accounts. This means that user accounts have security descriptors that list the users and groups that are granted access. Security descriptors also define ownership of the object and specify the permissions that those users and groups have been assigned with respect to the object.
Individual entries in the security descriptor are referred to as access control entries (ACEs). Active Directory objects can inherit ACEs from their parent objects. This means that permissions for a parent object can be applied to a child object. For example, all members of the Account Operators group inherit permissions granted to this group.
Because of inheritance, sometimes it isn't clear whether a particular user, group, or computer has permission to work with another object in Active Directory. This is where the Effective Permissions tool comes in handy. The Effective Permissions tool allows you to examine the permissions that a user, group, or computer has with respect to another object. For example, if you wanted to determine what permissions, if any, a user who has received delegated control has over another user or group, you could use Effective Permissions to do this.
The Effective Permissions tool is available in Active Directory Users And Computers—but only if you are in the Advanced view. Select Advanced Features from the View menu if necessary, and then double-click a user, group, or computer name to display the related Properties dialog box. In the Properties dialog box, click the Advanced button on the Security tab, and then select the Effective Permissions tab. Next click Select, type the name of the user or group for which you want to see the effective permissions, and then click OK.
The Effective Permissions for the selected user or group with relation to the previously selected object appear, as shown in Figure 37-7. The Effective Permissions window will have check marks showing which permissions are in effect. If there are no effective permissions, none of the permissions will be selected.
Every user account created in Active Directory has account options that control logon hours, the computers to which a user can log on, account expiration, and so on. To manage these settings for a user, double-click the user account in Active Directory Users And Computers, and then select the Account tab, as shown in Figure 37-8.
Below the general account name fields, the account options areas are divided into three main areas. The first area that you can configure controls the Logon Hours and Log On To computer options.
Setting Logon Hours Click Logon Hours to configure when a user can log on to the domain. By default, users can log on 24 hours a day, seven days a week. To deny a user a specific day or time, select the area that you want to restrict them from logging on, and then select the Logon Denied option, as shown in the following screen. For example, this option can be used to restrict shift workers to certain hours or to restrict working days to weekdays.
Configuring Logon Computer When you click Log On To, you can restrict which computers a user can log on from. The NetBIOS protocol is required for this functionality, as well as a computer name from an operating system earlier than Windows 2000. The default setting allows users to log on from all computers. To restrict which computers a user can log on from, click The Following Computers, as shown in the following screen. Type a computer name in the Computer Name field, and then click Add. Repeat this procedure to set other logon computers.
Below the Logon Hours and Log On To buttons is a check box called Account Is Locked Out. It will be dimmed if the account is not locked out. If the user has locked herself or himself out by trying to log on with the wrong password too many times, you can unlock the account here. Next is the Account Options list, which includes a number of account options you can configure. These options include the following:
User Must Change Password At Next Logon This is the default setting when a user is created. It requires the user to change the password the first time he or she logs on. This allows the user to be the only person with the knowledge of the password, though you as the administrator can change it.
User Cannot Change Password This setting prevents the user from changing the password and gives the administrator more control over accounts like the Guest account. This is a good setting for service and application accounts.
Password Never Expires This prevents passwords from ever expiring. It is a good idea to use this on service accounts. This is another good setting for an application or service account where a password is hard-coded into an application or service.
Store Password Using Reversible Encryption Saves the user password as encrypted clear text. Check this box if you have computers from Apple Computer, Inc., in your domain, because they store passwords as plaintext.
Account Is Disabled This prevents a user from logging on to his or her account. It enables network administrators to immediately disable an account for security reasons.
Smart Card Is Required For Interactive Logon To ensure higher security on a network, smart card technology can be implemented. Enabling the setting requires all users to use a smart card and reader to log on and to be authenticated. This domain setting also requires a personal identification number (PIN) configured on the smart card. This option also sets the Password Never Expires option to be enabled.
Account Is Trusted For Delegation If a service is running under a user account rather than as a local system, you can set a user account to execute procedures on behalf of a different account on the network. By enabling this option, you can mimic a client to gain access to network resources on the local computer. This is only available on Windows Server 2003 domain controllers where domain functionality has been set to Windows 2000 mixed or Windows 2003 native mode.
Account Is Sensitive And Cannot Be Delegated Select this option if this account cannot be assigned for delegation by another account. This is the opposite of the above setting, and could be used in a high-security network environment.
Use DES Encryption Types For This Account Data Encryption Standard (DES) is used for many encryption protocols, including Microsoft Point-to-Point Encryption (MPPE) and Internet Protocol Security (IPSec) and supports up to 128-bit strong encryption. Enable this option if you want to use DES encryption.
Do Not Require Kerberos Preauthentication You should enable this if the account uses a different implementation of the Kerberos protocol.
Finally, the Account Expires panel lets you set expiration options for the account. The default is Never, but some users may need to have this setting configured. For example, temporary, contract, summer help, or consultants may be working on your network for only a specified amount of time. If you know how long they need access to resources in your domain, you can use the Account Expires settings to automate the disabling of their account.
Tip
Disabling accounts
In most network environments, administrators to whom managing users has been delegated will not be able to remove users immediately upon their leaving the company, creating a window of vulnerability. Yet, when accounts have scheduled end points, you can schedule them to be disabled on a specific date. So, it is good idea to schedule accounts to be disabled if you are sure that the user will no longer be working. If the account is automatically disabled, but the user needs access, he or she will let you know. But, if the account is not disabled automatically, it can represent a big security problem. To handle this on an enterprise level, many businesses are reviewing (or implementing) provisioning applications to automate the process of taking away access to company resources when employees leave the company.
User accounts can also have profiles, logon scripts, and home directories associated with them. To configure these options, double-click a user account in Active Directory Users And Computers, and then select the Profile tab, as shown in the following screen:
As the screen shows, you can set the following options in the Profile tab:
Profile Path Profiles provide the environment settings for users. Each time a user logs on to a computer, that user's profile is used to determine desktop and Control Panel settings, the availability of menu options and applications, and so on. Setting the profile path and working with profiles is covered in the section entitled "Managing User Profiles" later in this chapter.
Logon Script As the name implies, logon scripts are accessed when users log on to their accounts. Logon scripts set commands that should be executed each time a user logs on. One user or many users can use a single logon script, and, as the administrator, you control which users run which scripts. You can specify a logon script to use by typing the path to the logon script in the Logon Script field. Be sure to set the full path to the logon script, such as \Corpdc05LogonScriptseng.vbs.
Note
You shouldn't use scripts to set environment variables. Environment settings used by scripts aren't maintained for subsequent user processes. Also, you shouldn't use logon scripts to specify applications that should run at startup. You should set startup applications by placing the appropriate shortcuts in the user's Startup folder.
Home Folder A home folder can be assigned to each user account. Users can store and retrieve their personal files in this directory. Many applications use the home folder as the default for File 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 2003 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 button, and then typing the path to the home folder on the user's computer. Here's an example: C:Home\%UserName%.
You specify a network home folder by clicking the Connect option button in the Home Folder section, and then selecting a drive letter for the home folder. For consistency, you should use the same drive letter for all users. Also, be sure to select a drive letter that won't conflict with any currently configured physical or mapped drives. To avoid problems, you might want to use Z as the drive letter. After you select the drive letter, type the complete path to the home folder, using the Universal Naming Convention (UNC) notation, such as: \Corpdc09Home\%UserName%.