Creating and Managing User Accounts


Objective:

Create and manage user accounts

User accounts are created so that people can identify themselves and receive access to the local and network resources they need. In Windows Server 2003 with Active Directory enabled, user accounts (often called user IDs) are assigned using the Active Directory Users and Computers management console. On standalone Windows Server 2003 computers, user accounts are created using the Local Users and Groups snap-in in the Computer Management Microsoft Management Console (MMC).

A user account is a record stored in a databaseeither the Security Accounts Manager (SAM) database stored on a workstation or server, or the Active Directory database stored on your domain controllers. The user account contains the user ID, password, Security Identifier, and other information pertaining to that user. A user account is similar to the electronic door cards that some of us use for access to our offices. Like the door cards, our user account contains information on who we are, what we do, and what doors (network resources) we have access to. Also, like the door cards, the system administrator has a record of what doors (network resources) you accessed and when.

When users log on to a PC or server, they are identified by their Security Identifier (SID). This SID is a unique number that is used to identify the user. Although we use a name to identify a user, Windows uses the SID. The user name (a.k.a. User ID) can be changed, but the SID stays the same. If you delete a user account and create a new one with the same name, it will receive a different SID. SIDs are never reused.

Note: Smart Cards

Because we're using door cards as an analogy, it should be pointed out that Windows Server 2003 supports the use of Smart Cards. These cards have the user identity information encoded on them and allow the user to log on by swiping the card in a reader and entering a personal identification number.


Having a unique user account for each user allows the system administrator to selectively grant access to the resources on the server or network. If, for example, you store salary information on a server, you wouldn't want all the users to have access to that information!

Every user should have a separate account. If there are problems with system usage or a security breach, it's necessary that the administrator be able to tell who was acting incorrectly. If all the engineers in a department logged on using a single account called "Engineer," it would be impossible to tell which one of the engineers was accessing the resources. Allocating separate accounts also allows each user to have access to exactly the resources needed and no more. Also, each user account can have its own private home directorymultiple users sharing a single account would have no such private storage.

The following subsections discuss the methods of creating and managing user accounts:

  • Creating and modifying local user accounts

  • Creating and managing accounts with the Active Directory Users and Computers management console

  • Creating a user account template

  • Creating and managing accounts with automated processes

  • Creating and managing accounts using bulk Import/Export tools

Creating and Modifying Local User Accounts

Each Windows Server 2003 server that is a member server or a standalone server can have local accounts. Local accounts are accounts that are stored in the SAM database on that server. Local accounts can be used to access resources only on that server; they cannot be used to access resources on other servers or on the network, if present.

Note: Log on Locally

We should clarify that typically a local account is used to grant access over the network to users located at other PCs in a workgroup situation. For example, if a shared folder or printer is attached to a workgroup server, users at their PCs would access this resource over the network. Although a local user can log on locally to a workgroup server, that is not recommended. After a server is added to a domain, the log on locally permission for anything other than administrators is restricted.


Each Windows Server 2003 server contains the following built-in user accounts:

  • Administrator The local Administrator account has complete authority over the resources on the server. It can be used to grant or deny access to other users. You cannot delete the Administrators account, but you can rename it or disable it. This account was used for the first logon to the server.

  • Guest The Guest account does not require a password and is used for users who do not have a user account. However, by default it has limited access to resources and is disabled. You can enable it and grant it access to resources, if needed, but this is not recommended.

  • Support_388945a0 This account is used to allow ordinary users to run scripts from within the Help and Support Service. This capability must be delegated by the administrator.

  • HelpAssistant This account will not be created until you start a Remote Assistance session.

You will need to create user accounts for users other than the Administrator so they have access to resources on the server. Local user accounts are created using the Local Users and Groups snap-in, in the Computer Management MMC.

Usernames must be unique; they cannot be identical to any other user or group name on the computer. The name can contain up to 20 characters, except for the following: " / \ [ ] : ; | = , + * ? < >. The username cannot consist solely of periods or spaces. The password cannot be longer than 127 characters.

To create a local user account, follow Step by Step 2.1:

Step by Step

2.1 Creating a local user account

1.

Open the Computer Management MMC by selecting Start, All Programs, Administrative Tools, and then click Computer Management.

2.

In the left pane of the Computer Management MMC, expand System Tools, and then select Local Users and Groups.

3.

Right-click the Users folder and select New Users from the action menu.

4.

In the New User dialog box, as shown in Figure 2.1, enter the User Name and Password. If desired, you can enter a Full Name and Description.



Figure 2.1. The username must be unique.


5.

Click the Create button to save the user account.

6.

Click the Close button to quit.

In the New User dialog box, there are four options that we didn't discuss. Three of the four relate to password management.

They are the following:

  • User Must Change Password at Next Logon This option is useful when creating user accounts for new users or resetting the password of a user account. This allows the administrator to initially set the password to a known value, and the next time the user logs on, that user is prompted to create a new password. This way, only the users know what their password is.

  • User Cannot Change Password This option is useful for shared accounts, where if a user changes the password, the other people using the account will be locked out. (Remember, account sharing is not a good practice).

  • Password Never Expires This option is typically used for service accounts, where the password should be changed only by the application that is using it, or where an expired password would keep the application from running.

  • Account Is Disabled This option disables the account, which prevents the user from logging on.

Challenge

You are a system administrator who is responsible for managing the security for a Windows Server 2003 server that contains all the information used to run your company.

Because of an upswing in business, management has purchased a new application and has hired four new people. Two of these people are going to be receptionists. They are both part-timers and will be sharing a PC. They both need access to a calendar and printer on the server, but won't need any other access.

The other two new hires are engineers. They are working in two different departments, so their server access needs will be different. In addition, the new application must run as a background application, so it will need a dedicated service account.

Your task is to create the necessary user accounts for both the new users and the new application. Make sure that everything is configured so that the end user has the correct access while maintaining a comfortable level of security. Draw up a plan for creating these accounts while adhering to these specifications.

Try to complete this exercise on your own, listing your conclusions on a sheet of paper. After you have completed the exercise, compare your results to those given here.

  1. The two receptionists can share a user account because they won't have any access to secure resources. Configure their account with a password that doesn't expire, so that one user won't change the password and lock the other out.

  2. Because the engineers are working in different departments, give each of them a unique account. Set the account to require the users to change the password when they first log on.

  3. Configure the service account password for the new application to never expire.


Creating and Modifying User Accounts Using Active Directory Users and Computers

Objective:

Create and modify user accounts by using the Active Directory Users and Computers MMC

In the previous section, you learned how to create local accounts; however, when a server is located in a domain, it is more practical to use domain accounts. A domain account allows a user to sign on with a single account and access resources on any machine in the domain that the user has been granted access to. As your network gets larger, you will see that domain accounts are a good thing, because you will no longer have to maintain a local account on each server.

Before you can use and create domain accounts, you need to create a domain controller. A domain controller is used to store the user accounts, computer accounts and other objects contained in a Windows domain. Similar to the SAM that is contained on each server, a domain controller has a database called the Active Directory. Because this database is designed for use in larger environments, it is far more robust that the simple server SAM, and the changes to the Active Directory on one domain controller are automatically replicated to all the other domain controllers in the domain.

Exam Alert: Have a Very Basic Understanding of Active Directory

Understand when, how, and why you would use a domain controller versus a standalone server in a workgroup. However, the intricacies of Active Directory and replication are reserved for the 70-294 exam.


Before you can work with Active Directory, you must install it. An Active Directory domain controller is created by promoting a member server to a domain controller using the DCPromo utility.

Exam Alert: Multiple Methods

Recall from Chapter 1, "Windows Server 2003 Environment," that you can also use the Manage Your Server Wizard to change the role of your server to a domain controller. You should understand how to do it both ways for the exam.


In Step by Step 2.2, we will take the Windows Server 2003 member server that we created in the previous chapter and promote it to a domain controller.

Step by Step

2.2 Promoting a member server to a domain controller

1.

Log on to your Windows Server 2003 server as an administrator.

2.

Load your Windows Server 2003 CD, click Start, Run, and enter dcpromo in the dialog box. Click the OK button to start the process.

3.

On the Welcome to the Active Directory Installation Wizard screen, click the Next button.

4.

On the Operating System Compatibility screen shown in Figure 2.2, make sure that you read about the new security settings in Windows Server 2003 and how they affect older operating systems. After you have reviewed the screen, click the Next button.



Figure 2.2. Most of the older operating systems are not supported in a Windows Server 2003 domain.


5.

On the domain controller Type screen, select Domain Controller for a New Domain because this is going to be the first domain controller in our new domain. Click the Next button.

6.

On the Create New Domain screen, select Domain in a New Forest. Click the Next button.

7.

On the New Domain Name screen, you are prompted to enter the name of the new domain. Type in 70-290.int. Click the Next button.

8.

On the NetBIOS Domain Name screen, you are prompted to enter the NetBIOS name for the domain. Accept the default and click the Next button.

9.

On the Database and Logs folders shown in Figure 2.3, you are prompted for the location where you want to store the Active Directory database and its transaction log. For our lab, the default locations are fine. Click the Next button to continue.

Figure 2.3. Like any other database, Active Directory requires storage space for both the database and the transaction log.


10.

On the Shared System Volume screen, you are prompted for the location of the SYSVOL, a folder that is replicated to each domain controller in your domain. It is used to store login scripts and Group Policies. Accept the default. Click the Next button to continue.

11.

If your server fails to contact a DNS server, you will be presented with the DNS Registration Diagnostics screen, as shown in Figure 2.4. Here you have the choice of reconfiguring your TCP/IP setting to use an existing DNS server, then running the diagnostics again, ignoring the error and moving on, or letting Windows install a DNS server on your server. Select the option to install and configure DNS on your server, and then click the Next button.

Figure 2.4. In most cases, it's best to host your DNS server on your domain controller.


12.

On the Permissions screen, you have the option of loosening your security so that certain functions of older servers will operate. Unless you are running a Windows NT 4.0 Remote Access Server, you would normally select the default setting of Permissions Compatible Only with Windows 2000 or Windows Server 2003 Operating Systems. Click the Next button to continue.

13.

On the next screen, you are prompted to enter the Directory Services Restore mode password. This is not the same as the Administrator password. This password is used only during disaster recovery of the Active Directory database. This will be covered in Chapter 16, "Implementing Administrative Templates and Audit Policy." For now, enter a password, and then click the Next button.

14.

On the Summary screen, review your selections, and then click the Next button.

15.

The Active Directory Installation Wizard will run for the next 10 to 15 minutes. When it is completed, click the Finish button.

16.

When prompted, select the option to reboot. Active Directory is installed.

Choosing a Domain Name

In the previous exercise, you might have noticed that we used the suffix .int when naming the Active Directory domain. This is to ensure the uniqueness of our domain name, since a domain name with the .int extension cannot be registered and used as a valid domain on the Internet. You should avoid using a domain name with any registerable extensions such as .com, .net., or .org because the domain name might already be in use. More information on how and why to choose domain names will be covered on the 70-294 exam.


Logging On to a Windows Server 2003 Domain Controller

Now that you've promoted your member server to a domain controller, you need to log on. Like you did before, press Ctrl+Alt+Del to present the logon dialog box. Do you notice anything different? Note: You might have to click the Options button. Take a close look at Figure 2.5.

Figure 2.5. The name of the domain is displayed on the logon dialog box.


There is now an additional field on the logon dialog box, the Log On To field. The name of the domain is now displayed when you log on to your domain controller. Before, you were logging on to a standalone server, and the only method of authentication was from the local SAM. In our case, now that our server is a domain controller, the only method of authentication is via the Active Directory (AD) database. When AD is installed, the SAM is removed. However, if this was a member server or a workstation, the Log On To field would let you select from logging on via the local SAM or to the domain. If you log on via the SAM, you have access to resources only on that machine, versus logging on to a domain where you could potentially have access to resources throughout the domain!

Using the Active Directory Users and Computers Console

Now that we've logged on to our freshly built domain controller, let's talk about another difference between it and the standalone server we worked with earlier in the chapter. We've already pointed out that when Active Directory is installed, the local SAM is removed. This also means that we can no longer create user accounts using the Local Users and Groups snap-in, because there are no longer any local users or groups!

Each Windows Server 2003 domain controller contains the following built-in user accounts:

  • Administrator The domain Administrator account has complete authority over the resources in the domain. It can be used to create and modify user accounts or to grant or deny access to other users. You cannot delete the Administrators account, but you can rename it or disable it. This account was used for the first logon to the server.

  • Guest The Guest account is used for users who do not have a user account, and it doesn't require a password. However, by default it has limited access to resources and is disabled. You can enable it and grant it access to resources, if needed, but this is not recommended.

  • Support_388945a0 This account is used to allow ordinary users to run scripts from within the Help and Support Service. This capability must be delegated by the administrator.

  • HelpAssistant This account will not be created until you start a Remote Assistance session.

Exam Alert: Log on Locally

Unlike a standalone server, by default, only the Administrator has log on locally rights on a domain controller. This will probably come up in a question on the exam.


Creating Domain Accounts

Now that we're in a domain, we have to create domain accounts to give users access to the resources in our domain. The Active Directory Users and Computers (ADUC) console is the most straightforward way to create and modify domain user accounts. It is accessible from Start, Administrative Tools, Active Directory Users and Computers; from the Manage Your Server Wizard; or by using Start, Run and typing dsa.msc into the Run dialog box.

When you start Active Directory Users and Computers, as shown in Figure 2.6, you will see a familiar Explorer-like display. In the left pane is a folder containing saved queries (we'll talk about queries later in the chapter) and an icon showing the name of the domain the managing computer is attached to (70-290-int, in this case). The right pane shows the contents of the container selected in the left pane. Because we have the Builtin container selected in the figure, we see the contents of that container in the right pane.

Figure 2.6. Selecting a container on the left pane displays its contents in the right pane.


Note: Containers??

If you look closely in the left pane of the Active Directory Users and Computers MMC, you will notice that all the folder icons are not the same. Some icons are plainthese are containers. The other icons have an open folder label on themthese are OUs. Most of the containers are automatically created by the operating system, and control of some of them cannot be delegated.


Let's assume we're the network administrators for the Kansas City location of our organization, and we need to create some user accounts. Because the Kansas City Organizational Unit (OU) hasn't yet been created, we will need to do that. OUs are used in Active Directory to store users, groups, and resources. We'll create that OU and two more subordinate OUs below it in Step by Step 2.3.

Exam Alert: Be Familiar with OUs

OUs are containers that the administrator creates to contain users, groups, and resources, such as computers and file shares. The administrator can then delegate authority over or assign a Group Policy to the items contained in the OU. You must have a good understanding of this for the exam. OUs will be covered at length in Chapter 8, "Managing Access to Objects in Organizational Units."


Step by Step

2.3 Creating OUs

1.

In the left pane of the Active Directory Users and Computers console, select the top-level container in which you want to create the OU. In our example, the top-level container is 70-290.int.

2.

Right-click the container and choose New, Organizational Unit. Type the name Kansas City for the OU into the Name box.

3.

Right-click the Kansas City OU and choose New, Organizational Unit. Type Users.

4.

Repeat step 3, calling this OU Workstations.

We now have the organizational structure we want. This basic structure will be used in the exercises in this chapter, and later in the book.

Creating Domain User Accounts

Now that we have our organizational structure in place, we can create a user account. Follow the procedure in Step by Step 2.4 to create a user account.

Step by Step

2.4 Creating a User Account

1.

In the left pane of the Active Directory Users and Computers console, select the top-level container in which you want to create the users. In our example, the top-level container is 70-290.int.

2.

Right-click the Kansas City\Users container and select New, User.

3.

Type the first and last names and the user logon name, as in Figure 2.7. In this organization, the default rule for creating the user logon name is the initial letter of the first (given) name, followed by the full last name (surname).

Figure 2.7. Fill in the name of the person for whom you are creating the user account.


4.

Type the initial password for the user and repeat it in the confirmation field (see Figure 2.8). Accept the default password options.

Figure 2.8. In most organizations, the default password settings for a new user are acceptable.


5.

Review the information in the confirmation dialog box and select Finish to create the user object.

Note: User Account Settings

In the New User Creation Wizard, the default password settings (shown in Figure 2.8) force the new user to change the password at the first successful logon. This ensures that the administrator does not know the user's credentials and therefore cannot impersonate the user. Also, forcing the user to change his password immediately makes him aware of any password complexity rules the organization has chosen, because if the password is too short or not complex enough, Windows Server 2003 will reject it and force the user's new password to comply with the complexity rules.

The second password setting is User Cannot Change Password. Typically, an organization wants users to be able to change their own passwords, but occasionally (as for a visitor account) the password should not be changed.

Next is a setting that allows the administrator to exempt this account from the password-expiration rule. Most organizations want their users to change their passwords regularly (every 60 days, for example), so that if a password has been compromised, its useful period to gain access to the network is limited. The exception to this rule is for service accounts. A service account is used so that applications, such as Microsoft Exchange and Microsoft SQL Server, have access to network resources. These applications expect the password to never be changed, or if it is changed, the change must be performed using the management tool for the application and not through the ADUC.

Finally, the account can be disabled with the last check box, Account Is Disabled. This feature is generally used in one of two cases: when the account is created before the user is physically onsite or when the user is temporarily or permanently gone from the organization. In both cases, no one should be able to use the account, so disabling it is an appropriate security precaution.


The account has now been created, and at this point the user could log in. However, there are many properties of the account that we have not yet set, so let's look at how to modify a user account with Active Directory Users and Computers.

After the user object has been created, you can select it and review or set its properties. Double-clicking the object in the right panel of ADUC opens a Properties dialog box, as shown in Figure 2.9.

Figure 2.9. Change any of the properties on the General tab of the user account dialog box.


Larger organizations generally have a list of the required information that must be entered for each user account. For example, it might be mandatory to fill in the Office Location field, and there might be a fixed list of allowable entries. Like all fields in a user object, it is possible to search on the contents of the Office Location field. However, if one administrator enters Salt Lake, another enters SLC, and a third enters Salt Lake City, how are users to search for that location? Requiring administrators to use office location names from a published list will resolve that problem.

More About Directories

The Active Directory is, in effect, a directory for the company, so rather than relying on a printed booklet, the users can pull all organization and contact information right from AD. Also, entry of organizational info (but not account creation) is often given to the Human Resources department because it often has the rights to update certain properties because of changes that are happening. (For example, Bob just got promoted; he will be moving to a new office.) There are also some companies that leave it to the users to update themselves. (For example, if their extension changes, they can update that info in AD.) Microsoft is hoping that this will do away with some other internal directories that are in use (for example, printed books, email systems, databases used for printing, departmental phone lists, and so on).


The Address tab is available so that Active Directory can hold personal and business address information about the user. Most large organizations have personnel systems that carry this information, however, and these systems can use Active Directory or other database systems to store the data. Even if Active Directory is the directory system used to hold this employee data, the personnel system would update the directory programmatically, not via the Active Directory Users and Computers console.

The Account tab contains several useful entry areas. The Logon Hours button allows you to specify which hours during the week the user is permitted to log on to the system. The Log On To button lets you specify the NetBIOS or the fully qualified domain name (FQDN) of the computers the user is permitted to log on to. Among the Account options is the setting Smart Card Is Required for Interactive Logon, which, if activated, requires the user to present a smart card to log on directly to a server or workstation. For this to work, this smart card must be encoded with a certificate issued to the user, and a smart card reader must be installed on the computer. The smart card eliminates the need for a username and password; the user just needs the smart card and a personal identification number (PIN).

Note: Beware of Interactive Logons

An interactive logon is a logon performed at the console of the server or via a Terminal Services session. A user who can log on directly to a server is more of a risk than a user who is logged on across the network, because when someone has physical access to the server, there is very little the OS can do to protect itself.


Account Expiration Date is the final entry area on the Account tab. Although we would expect most accounts to be valid indefinitely, for temporary employees, such as summer students, interns, or contractors, it is wise to specify the last date an account can be used (see Figure 2.10).

Figure 2.10. Use the End Of option button to select a date after which the account will no longer be valid.


Note: Managing Your Server Remotely

Remember from Chapter 1 that you can install the Administrative Tools for Windows Server 2003 on a Windows XP workstation so that you don't have to be logged on to the server console to manage it.

If you want to manage a computer running Windows Server 2003 from a workstation that is not running Windows XP, the only available method is to start a Terminal Services session. Fortunately, Terminal Services clients are available for all Windows operating systems from Windows 95 on.


On the Profile tab, shown in Figure 2.11, in the User Profile section you can specify where the user's profile data will be stored. We'll discuss profiles in depth later in this chapter, in the "Managing Local, Roaming, and Mandatory User Profiles" section. Also on the Profile tab, you can specify the name of the logon script (the scripted commands that will run on the user's behalf) when the user logs on.

Figure 2.11. Enter values for profile path, logon script, and home directory location on this tab.


In the Home Folder section of the Profile tab, you can specify the path where the user's home folder will be located. This can either be a path on the local computer or a network drive mapped to a shared folder on a server.

Note: Group Policy Is Preferred

These methods of specifying profile, logon script, and home folder information have generally been superseded by Group Policies in Windows 2000 and Windows Server 2003. They were retained for consistency with previous versions of the operating system.

The Help and Support Center for Windows Server 2003 describes managing user profiles with Group Policies as a best practice. See "Managing Terminal Services Users with Group Policy" in Help and Support.


The next tabs all concern how the user interacts with Terminal Servicesa method for having multiple users run programs in sessions that actually operate on a network server. The user can work at a low-function workstation (even one running Windows 95) and run programs that need the power and resources of a computer running Windows Server 2003.

The Remote Control tab allows the administrator to control whether a user's session can be controlled remotely. If Remote Control is enabled, the administrator can choose whether the user's permission is needed before the administrator can see the user's session. The administrator can also choose whether a session being controlled remotely can be operated by the administrator or merely viewed. Terminal Services is covered in Chapter 11, "Managing and Maintaining Terminal Services."

Remote Control can be a very helpful facility for help desk staff. With the appropriate authorization, a help desk analyst can connect to a user's Terminal Services session and see what the user is seeing or is having difficulties with. If needed, the analyst can take control of the session to demonstrate how a task is to be performed or to investigate program settings. This is much more efficient than having the user describe to the analyst what is on the screen, and it's much faster than having the analyst go to the user's desk to see the problem.

Note: Remote Assistance

Remote Assistance is a similar facility that allows an analyst to control a user's session remotely. Available only for Windows XP and Windows Server 2003 computers, this facility lets a user request help from a helper (typically a help desk analyst or a friend). The helper can then see the user's session and take control of it if necessary (if allowed to do so). Remote Assistance is covered in Chapter 11.


The Terminal Services Profile tab allows the administrator to configure the user profile applied to the user's Terminal Services session. The administrator can specify the path of the profile to be used and the home folder location. These items can be different from the profile path and home folder location specified on the Profile tab. There is also a check box on which the administrator can determine whether the user is allowed to log on to the terminal server (see Figure 2.12).

Figure 2.12. Use the Terminal Services Profile tab to specify the profile path and home folder location for the user's Terminal Services sessions.


Note: Terminal Services

These Terminal Services settings should be changed only at the individual user-configuration level if specific functions are to be added or denied to a specific user.


On the Environment tab, the administrator can configure the startup environment a Terminal Services user sees. Any setting specified here will override the setting specified by the Terminal Services client. The administrator can require that a program start automatically at logonwhen the user exits the program, the session will be logged off. This is a way of limiting users to a specific application instead of presenting them with a Windows Server 2003 desktop, which is the default. In addition, the administrator can control whether drives and printers on the client computer are available from the session, as well as whether print jobs are automatically sent to the default printer of the client computer.

Exam Alert: Be Familiar with the Added Features

Administrators who have used previous versions of Windows Terminal Services might unwittingly ignore the options for device mapping. However, these options are now fully supported in Windows Server 2003 Terminal Services without requiring the Citrix add-on. Expect to see questions on these added features on the exam.


On the Sessions tab, shown in Figure 2.13, the administrator can specify what to do with Terminal Services sessions that are disconnected or left idle. A session is disconnected when the user disconnects rather than logging off or when the communication between the client computer and the Terminal Services server is broken. The administrator can choose to leave the disconnected session running forever, or only for a fixed period (such as 3 hours). The administrator can also specify how long an active session can continue, and how long an idle session can be left connected. When either of these limits is met, the session can be disconnected or ended. Finally, when the session has been disconnected, the administrator can specify whether reconnection is allowed from any client computer, or only from the client computer with which the disconnected session was initiated.

Figure 2.13. Specify how idle and disconnected sessions are handled on the Sessions tab.


On the Dial-In tab, the administrator can determine whether a user can connect to a Windows Server 2003 machine remotely, either by a dial-in or a virtual private network (VPN) connection. When the domain is at the Windows 2000 native or Windows Server 2003 functionality level, remote access can be controlled through Remote Access Policy, which is substantially more sophisticated than a simple Allow Access or Deny Access setting. For example, a remote access policy can specify that only members of specific groups can access the network by dial-in, and then only from specific IP addresses and during stated periods in the day or week.

Also on the Dial-In tab, the administrator can choose to verify caller ID on the dial-in connection. The administrator can also require, for additional certainty, that only authorized locations are dialing in. By the administrator configuring the callback options, the server can break the connection as soon as authentication is complete, and then call the user back at a preset telephone number.

Saving Time with User Templates

In most organizations, many people have the same resource access needs. Perhaps all Kansas City engineers need print and management access to a particular printer, and read and write access to two shared folders. Also, staff in a particular location may have the same logon hours or other information, which is the same from person to person.

Rather than laboriously entering the same information for each user account, it's easier to create one account as a template and then copy that account whenever you need to create another user account with the same characteristics.

To do this, create a new user account and give it a display name that will cause it to be shown at the start of the username list in the container in Active Directory Users and Computers. Because special characters sort first, a name such as _Engineer or _Engineer Template would work well. Assign the account to the groups the users will be in, specify logon hours and logon computer restrictions, and enter the information on the Address, Account, Profile, and Organization tabs that you want to apply to all users. It's a good idea to disable the template account so that when new accounts are created from the template, they will be disabled also. This ensures new accounts won't be automatically available to anyone with malicious intent.

As an example of a user template, note the Organization page of the _Engineer account shown in Figure 2.14. This is the template account used to create the Test Engineer account.

Figure 2.14. The template account should have commonly needed information in the fields of the Organization tab.


After the template has been created, all you have to do to create a new user with the same characteristics is right-click the template account and choose Copy. You enter the username, user ID, and password of the specific user, and the resulting account has both the specific information for an actual user and the necessary ancillary information applicable to all users in the group because most of it was already entered into fields in the template account.

When a new account for Test Engineer was created by copying the _Engineer account, most of the information on the Organization tab was carried over, as you can see in Figure 2.15.

Figure 2.15. The Title field was not copied to the new account.


You might be wondering which attributes are copied to a new account created by copying a template. The values included in any attributes marked "Attribute Is Copied when Duplicating User" in the Active Directory Schema snap-in will be included in the copied account. With the necessary privileges, you can change which attributes are copied and which are not.

Caution: Schema Changes Are Not Reversible

You should exercise extreme caution when making changes to the Active Directory schema. Additions made to the schema are not reversible; they can only be disabled.


When creating template accounts, consider making separate templates for temporary employees. If your organization is planning to hire several summer students, set up a template with the account-expiration dates set to the end of the summer. This way, all the users created using the _Summer Intern template will have the correct expiration already set when the accounts are created.

A good rule when creating template accounts is that you want to have a new template account for every set of new user types that might have unique information prepopulated. For example, in the case of the summer interns, their accounts are unique because of the expiration date. Using the _Summer Intern template would not be appropriate for a new employee whose account will not expire, and vice versa. You might decide to create template accounts for the different departments in your company or for those who have different work hours or managers. The key thing to remember is that the template you use must match the characteristics of the user you are creating. Otherwise, information will be automatically placed in the user account properties (via the template copy) that is not relevant for that user.

Creating Accounts Using Automation

Objective:

Create and modify user accounts by using automation

When you have only a few accounts to create or change, it's reasonable to use Active Directory Users and Computers. But for large numbers, you would want to automate the process. This section discusses using the command-line tools in conjunction with batch files to create many accounts, and we'll discuss importing user accounts as well.

Creating and Modifying User Accounts with Command-Line Tools

New in Windows Server 2003 are several command-line tools that can help in automating the creation and modification of user accounts:

  • dsadd Used to create Active Directory objects

  • dsget Used to retrieve specific properties of a user account

  • dsmod Used to change a property in a user account

  • dsmove Used to move or rename an Active Directory object

  • dsrm Used to delete Active Directory objects

The first one we'll discuss is dsadd, which adds accounts to the Active Directory service.

Creating Accounts with dsadd

The dsadd command can be used to create several types of objects in Active Directory. You can consider these to be subcommands of the dsadd command:

  • dsadd computer Adds a computer to the directory

  • dsadd contact Adds a contact to the directory

  • dsadd group Adds a group to the directory

  • dsadd ou Adds an OU to the directory

  • dsadd user Adds a user to the directory

  • dsadd quota Adds a quota specification to a directory partition

To learn how to use the dsadd command, open a command prompt and enter the following:

dsadd /?


To learn about the use of the subcommands, at the command prompt enter the following:

dsadd user /?


The dsadd user command can take several parameters, but the only required one is DN (distinguished name).

What's a distinguished name? It is the name assigned to an object in Active Directory, and it's made up of the object name (for example, Bill Bailey), the container it resides in, and the list of all the parent containers of that container, right up to the domain. Here's the distinguished name for Bill Bailey:

"CN=Bill Bailey,OU=Users,OU=Kansas City,DC=70-290,DC=int"


The following list examines the parts of this name:

  • CN=Bill Bailey CN stands for common name. It can be used for users, groups, computers, and containers.

  • OU=Users,OU=Kansas City This string lists all the containers in order, from the one the object resides in, up to the first container below the domain object.

  • DC=70-290,DC=int DC stands for domain component, and we need a DC for each part of the fully qualified domain name (FQDN) of the domain, 70-290.int.

Exam Alert: Know the Difference

The default Active Directory folders shown in the root of the Active Directory Users and Computers MMCUsers, Builtin, and Computersare actually containers and not OUs. When referencing these containers, you have to use the CN= attribute and not OU=.


Windows Server 2003 will not permit you to create more than one object with the same distinguished name, so that you can be sure a distinguished name refers to a unique object. A good example of this is the Users OU we created earlier. Although its name is the same as the Users container that is created by default, the distinguished name is unique. With that knowledge in mind, you now know that we can create a new user in the same container as Bill Bailey's with the following command:

dsadd user "CN=Tom Thomson,OU=Users,OU=Kansas City,DC=70-290,DC=int"


Having run this command, we return to Active Directory Users and Computers, and after refreshing the contents of the Users container under Kansas City, we see the new user object, as shown in Figure 2.16.

Figure 2.16. The user object for Tom Thomson now exists.


If you look at the properties of the object, you will see that none of the user-defined fields have been filled in. Note that, by default, the account is shown as disabled.

Obviously, using dsadd in this way doesn't save us much time if we later have to go into the properties of the object manually to add the user's details. However, all the usually defined properties can be included in the dsadd command, along with the distinguished name, so the whole object-creation process, including the user details, can be automated.

The following is a partial list of the properties that can be included with the dsadd command (from dsadd user /?):

  • -samid The user ID in a form that is usable with nonActive Directory accounts management.

  • -upn The user principal name is an alternative name that can be used for logon. In place of the usual domain\user, you can enter name@domain. For example, Bill Bailey could log on as bbailey@70-290.int.

  • -fn The user's first name.

  • -mi The user's middle initial.

  • -ln The user's last name.

  • -display The name that denotes the account in listings, such as in Active Directory Users and Computers.

  • -empid An EmployeeID field.

  • -pwd This field can contain the password to be assigned to the account. If you want to be prompted for a password when creating the account, enter *. This wildcard is probably not appropriate for mass creating users because the script will stop each time a user is created, asking for a password.

  • -desc A description of the user.

  • -memberof A list of distinguished names of the groups the user should be made a member of.

  • -office The name of the user's office.

  • -tel The user's main phone number.

  • -email The user's email address.

  • -webpg The user's web page address.

  • -title The user's title.

  • -dept Department.

  • -company Company.

  • -mgr The manager of this user.

  • -hmdir The path to the user's home directory.

  • -hmdrv The drive letter assigned to the user's home directory.

  • -mustchpwd The user must change the password at next logon: {yes | no}.

  • -canchpwd The user is able to change the password: {yes | no}.

  • -reversiblepwd The password is stored with reversible encryption (used with Macintosh systems and digest authentication): {yes | no}.

  • -pwdneverexpires The password does not expire: {yes | no}.

  • -acctexpires The number of days until the account expires.

  • -disabled The account is disabled: {yes | no}.

  • -q The command should run with no output to the console.

Using as many of these parameters as necessary to define the user account, the administrator can create the account with a single command, like this:

[View full width]

dsadd user "CN=Arthur Lismer,OU=Users,OU=Kansas City,DC=70-290,DC=int" -samid ALismer -upn alismer@70-290.int -fn Arthur -ln Lismer -pwd Passw0rd -memberof "CN=Kansas City Users ,DC=70-290,DC=int" -office Kansas City -disabled no -mustchpwd yes


"But wait," you say, "that's more effort than working my way through Active Directory Users and Computers to create a user." That's true, for one user. However, if you're creating a thousand of them, and you have their names in a spreadsheet, it takes very little work to create a batch file where each line in the file creates another user.

After you have invested the time to master dsadd, you can save huge amounts of time in creating large numbers of user accounts.

Note: Using Net User

Another way to create users from the command line is with the Net User command. It works with a limited set of parameters compared to dsadd, but its biggest drawback is that any user account created using Net User is placed in the Users container. If you have any structure in your Active Directory tree (and you should, to allow administrative flexibility), you would be much better off with dsadd than with Net User.

It is possible to change the default containers for newly created accounts. The command redirusr.exe changes the default container for users, and redircmp.exe changes the default container for computers. But even with these specific commands to enhance the Net User command, it is clear that dsadd is much more flexible.


Listing the Properties of User Accounts with dsget

If you want to get the value of some properties of a user account with a command-line tool, you use dsget user. The syntax of the command is as follows:

dsget user <dn> <list of properties>


The properties you can use are shown in the following list, from Windows Server 2003 Help and Support:

  • -dn Shows the DN of the user.

  • -samid Shows the SAM account name of the user.

  • -sid Shows the user's Security ID.

  • -upn Shows the user principal name of the user.

  • -fn Shows the first name of the user.

  • -mi Shows the middle initial of the user.

  • -ln Shows the last name of the user.

  • -display Shows the display name of the user.

  • -empid Shows the user employee ID.

  • -desc Shows the description of the user.

  • -office Shows the office location of the user.

  • -tel Shows the telephone number of the user.

  • -email Shows the email address of the user.

  • -hometel Shows the home telephone number of the user.

  • -pager Shows the pager number of the user.

  • -mobile Shows the mobile phone number of the user.

  • -fax Shows the fax number of the user.

  • -iptel Shows the user IP phone number.

  • -webpg Shows the user's web page URL.

  • -title Shows the title of the user.

  • -dept Shows the department of the user.

  • -company Shows the company info of the user.

  • -mgr Shows the user's manager.

  • -hmdir Shows the user's home directory. It also displays the drive letter to which the home directory of the user is mapped (if the home directory path is a Universal Naming Convention [UNC] path).

  • -hmdrv Shows the user's home drive letter (if home directory is a UNC path).

  • -profile Shows the user's profile path.

  • -loscr Shows the user's logon script path.

  • -mustchpwd Shows whether the user must change his or her password at the time of next logon. Displays yes or no.

  • -canchpwd Shows whether the user can change his or her password. Displays yes or no.

  • -pwdneverexpires Shows whether the user's password never expires. Displays yes or no.

  • -disabled Shows whether the user account is disabled for logon. Displays yes or no.

  • -acctexpires Shows when the user account expires. Displays a value (a date when the account expires or the string never if the account never expires).

  • -reversiblepwd Shows whether the user password is allowed to be stored using reversible encryption. Displays yes or no.

For example, the command

dsget user "CN=Najma Lakhani,OU=Users,OU=Kansas City,DC=70-290,DC=int" -fn -ln -desc -office


returns the following information:

desc               fn       ln         office Senior Engineer    Najma    Lakhani    Kansas City


This command can be very useful in determining the values of the properties of one or several user accounts.

Modifying User Accounts with dsmod

You've probably been wondering what you would do if you had to make a change to hundreds or thousands of users. Well, just as dsadd allows you to automate the creation of users, dsmod allows you to change them.

dsmod uses the same parameters as dsadd, so you indicate the account you want to change with its distinguished name and then specify the parameter and the value it should have. For example, the following would change the value of the office parameter to Burnaby, while leaving all the other parameters unchanged:

dsmod user "CN=Arthur Lismer,OU=Users,OU=Kansas City,DC=70-290,DC=int"office Burnaby


Using Piping Commands

If you're like some administrators, you took one look at the dsmod command in the previous paragraph and said, "There's too much work in typing distinguished names! I'm sticking with Active Directory Users and Computers!"

This is where piping comes in. Piping allows you to use the output of one command as the input for a second command. If you can issue a dsquery command that finds the Arthur Lismer user object, you can pipe (using the | symbol on the keyboard) the output from the dsquery command into the dsmod command. Let's walk through this:

C:\>dsquery user -name arthur* "CN=Arthur Lismer,OU=Users,OU=Kansas City,DC=70-290,DC=int" "CN=Arthur Adams,OU=Users,OU=Kansas City,DC=70-290,DC=int"


No, that produced too many Arthurs. Let's try this:

C:\>dsquery user -name *lismer "CN=Arthur Lismer,OU=Users,OU=Kansas City,DC=70-290,DC=int"


There we go, just the user we wanted. Now let's pipe the output of dsquery into dsget to find the current value of the office parameter:

C:\>dsquery user -name *lismer | dsget user -office   Office   Vancouver dsget succeeded


Good. Now we change the value of the office parameter with a dsmod command:

C:\>dsquery user -name *lismer | dsmod user -office Burnaby dsmod succeeded:CN=Arthur Lismer,OU=Users,OU=Kansas City,DC=70-290,DC=int


And now we can confirm that the change was made:

C:\>dsquery user -name *lismer | dsget user -office      Office      Burnaby dsget succeeded


This is much more efficient than typing long distinguished names! And if you use a dsquery that returns several user accounts, the dsmod command can modify the same field in all the returned accounts, all at once.

For example, as in the preceding example when we changed the office location, typing the following command changes the user's telephone number without typing the DN:

C:\>dsquery user -name *lismer | dsmod user tel 803-734-1122


You can use similar logic to change any other piece of information in the directory by searching for the user's name, UPN, location in the directory, or even several other parameters you can see when using dsquery user /?. Hopefully, you are starting to see that the power of these commands is far greater than what it first appears.

Moving or Renaming Objects with dsmove

If you need to move an object to another location within a domain, or you want to rename the object, you can do so with dsmove. The syntax of dsmove is as follows:

dsmove <ObjectDN> [-newparent <ParentDN>] [-newname <NewName>]


So if Najma Lakhani moves from Vancouver to Phoenix, and she changes her name to Najma Larson, we could accomplish the change with the following command:

C:\>dsquery user -name "Najma*" | dsmove -newparent "OU=Users,OU=Phoenix,DC=70-290,DC=int" -newname "Najma Larson"


Checking in Active Directory Users and Computers shows Najma Larson in the new OU. Note that only the object name has changed. To complete the user's name change, properties of the object such as display name, last name, and email address will still have to be modified with dsmod or Active Directory Users and Computers.

Removing Objects with dsrm

The final command-line tool for Active Directory is dsrm. It is used to delete Active Directory objects. If the object being referenced is a container, it's possible to delete the objects in the container but retain the object itself.

The syntax for dsrm is as follows:

dsrm <ObjectDN ...> [-noprompt] [-subtree [-exclude]]


  • -noprompt Do not prompt for confirmation before deleting object.

  • -subtree Delete the object and all objects included in it.

  • -exclude Used with subtree. Do not delete the object, just its contents.

For example, assume the Phoenix office has just completed a Systems Analysis course and wants to delete the accounts that were created for students in the course. The accounts were in the OU called AnalysisStudents under the "OU=Phoenix,DC=70-290,DC=int" OU. The AnalysisStudents OU should be retained for future classes. The following command will delete all the objects in the AnalysisStudents OU but retain the OU:

C:\>dsrm "OU=AnalysisStudents,OU=Phoenix,DC=70-290,DC=int" -subtree -exclude Are you sure you wish to delete all children of OU=AnalysisStudents,OU=Phoenix,DC=70-290,DC=int (Y/N)? y dsrm succeeded:OU=AnalysisStudents,OU=Phoenix,DC=70-290,DC=int


Importing and Exporting User Accounts

Objective:

Import user accounts

Some organizations occasionally have a need to create, modify, or delete thousands of user accounts at a time. Think of a large university with an incoming class of several thousand students at the start of each term. You certainly wouldn't want to create each of those accounts with Active Directory Users and Computers!

What saves the day here is two facts: Almost certainly there is a database somewhere in the organization that has all the information needed to define the needed accounts, and Microsoft has provided two programs with Windows Server 2003, ldifde and csvde, that can be used to import accounts into Active Directory.

To create the thousands of user accounts, you would export the necessary information from the database system, manipulate the data so that it is in the format the import program needs, and then run the import program. It may take some time to go through these steps, but that's better than many days of tedious and error-prone work with Active Directory Users and Computers.

Why are there two import utilities, and how do they differ? The next sections answer those questions. csvde is simpler, so we'll discuss it first.

More About Importing/Exporting

Although the utilities we discuss here are fine for small- to medium-sized organizations, large enterprises need tools that are built to handle a large volume of changes. HP offers a tool called LDAP Directory Synchronization Utility (LDSU) that can easily handle the import and export changes described here, and it's robust enough for large enterprises to rely on.

LDSU was used to synch the Digital and Compaq directories during that merger (105,000 users and mailboxes), as well as the Compaq and HP directories (165,000 user accounts and mailboxes). Both of them were completely in synch within hours after the merger was finalized.

The beauty of LDSU is that it is simple to use, and it can "map" fields and formatting from one side to the other and keep the directories in sync as changes occur in the future.

Some basic information on LDSU is provided at http://h18008.www1.hp.com/services/messaging/mg_ldap_fact.html.


The csvde Utility

The csvde (Comma Separated Value Directory Exchange) utility exports data from Active Directory, or imports data into Active Directory, in Comma Separated Value (CSV) format. In this format, each line of data represents one record, and each field is separated from the next by a comma. If any field has commas as part of the data, the whole field is enclosed by quotation marks. So that the import utility can properly allocate each value to the appropriate field, the first line of the data file lists the names of the fields in the order they will appear in the data records.

As an example, here is the output from csvde of the Arthur Lismer record in our sample company:

[View full width]

DN,objectClass,ou,distinguishedName,instanceType,whenCreated,whenChanged,uSNCreated ,uSNChanged,name,objectCategory,dSCorePropagationData,cn,sn,physicalDeliveryOfficeName ,givenName,displayName,userAccountControl,codePage,countryCode,accountExpires ,sAMAccountName,userPrincipalName,description,mail,c,l,st,title,postalCode,co,department ,company,streetAddress,userWorkstations,manager"CN=ArthurLismer,OU=Users,OU=Vancouver ,DC=70-290,DC=int",user,,"CN=ArthurLismer,OU=Users,OU=Phoenix,DC=70-290,DC=int",4 ,20030421210344. 0Z,20030421210345.0Z,33732,33738,ArthurLismer,"CN=Person,CN=Schema ,CN=Configuration,DC=70-290,DC=int",,ArthurLismer,Lismer,Phoenix,Arthur,,512,0,0 ,9223372036854775807,ALismer,alismer@t70-290.int ,,,,,,,,,,,,,


The first line (starting DN,objectClass... is the header line, listing the fields in the data. The second line is the data for the Arthur Lismer record. It's hard to read, but if you load it into a spreadsheet program, each field will be in a separate column, and it's easy to work with then.

This output was created with the following command:

csvde -f c:\lismer.csv -r "(name=*lismer)"


The parameter -f c:\lismer.csv sends the output of the command to the file c:\lismer.csv, and the parameter -r "(name=*lismer)" tells the utility to select just those records whose name field ends in lismer.

To make the output of csvde easier to use, you can specify the fields you want to have exported. For example, the command

C:\>csvde -f c:\lismer.csv -r "(name=*lismer)" -l l,company,objectclass,name,title,company,l,telephoneNumber,userAccountControl,samaccountname


results in the simpler output file

[View full width]

DN,objectClass,title,telephoneNumber,company,name,userAccountControl,sAMAccountName "CN=Arthur Lismer,OU=Users,OU=Phoenix,DC=70-290,DC=int",user,Network Architect,555-5678 ,Thomson Associates,Arthur Lismer,512,Alismer


It is useful to run csvde in output mode first, to list the names of the attributes.

Now, to import a user, we make a text file in the same format as the output files and then run csvde in import mode. For example, let's run the command

csvde -i -f c:\adams-in.csv -j c:\


with the following input file:

[View full width]

DN,objectClass,title,telephoneNumber,company,name,userAccountControl ,sAMAccountName"CN=ArthurAdams,OU=Users,OU=Phoenix,DC=70-290,DC=int",user,Network Architect ,555-5678,Thomson Associates,Arthur Adams,514,Aadams


This creates a user account for Arthur Adams, with the attributes listed. Note that we have used the userAccountControl value of 514, which means the account is disabled when it is first created. This is because our work is not yet done; we haven't assigned the user to any groups and we haven't set the user's password (csvde cannot import or export passwords). We can complete these tasks with the dsmod utility and then enable the account.

The ldifde Utility

The name of this utility, ldifde, means LDIF Directory Exchange. LDIF (LDAP Data Interchange Format) is a definition of how data can be exchanged between LDAP-based directories. LDAP (Lightweight Directory Access Protocol) is an industry-standard protocol for accessing directories. For complete information about LDAP, see RFCs 22512256, and for information on LDIF, see RFC 2849, which can be read at www.ietf.org/rfc/rfc2849.txt.

There are two primary differences between ldifde and csvde. First, whereas csvde can only import and export records, ldifde can also modify records and delete records, making it a much more powerful utility. Second, the data format is very different. Instead of a file with a header record and one record per entry, the file contains many lines per entry, with the field name as the first part of each line.

Here is what the ldifde output looks like for the Arthur Lismer user account. Note that an entry starts with the distinguished name (dn) of the entry, then a changetype line (the changetype command can be add, modify, or delete), and then the attributes of the entry, in alphabetical order by attribute name:

dn: CN=Arthur Lismer,OU=Users,OU=Phoenix,DC=70-290,DC=int changetype: add accountExpires: 9223372036854775807 cn: Arthur Lismer codePage: 0 countryCode: 0 distinguishedName: CN=Arthur Lismer,OU=Users,OU=Phoenix,DC=70-290,DC=int givenName: Arthur instanceType: 4 name: Arthur Lismer objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=70-290,DC=int objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user physicalDeliveryOfficeName: Phoenix sAMAccountName: ALismer sn: Lismer userAccountControl: 512 userPrincipalName: alismer@t70-290.int uSNChanged: 33738 uSNCreated: 33732 whenChanged: 20030421210345.0Z whenCreated: 20030421210344.0Z


To use ldifde to create a series of user accounts, we'll need to build an input file of records in the format shown.

The following input file was used with the command

Ldifde -i -f c:\ldif-in1.txt


to create a new user account for Frank Carmichael:

dn: CN=Frank Carmichael,OU=Users,OU=Phoenix,DC=70-290,DC=int changetype: add cn: Frank Carmichael codePage: 0 countryCode: 0 distinguishedName: CN=Frank Carmichael,OU=Users,OU=Phoenix,DC=70-290,DC=int givenName: Frank instanceType: 4 name: Frank Carmichael objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=70-290,DC=int objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user physicalDeliveryOfficeName: Phoenix sAMAccountName: FCarmichael sn: Carmichael userAccountControl: 514 userPrincipalName: fCarmichael@t70-290.int


Using dsmod as described earlier, we can add three users' accounts to the Phoenix Users group with this command (entered as a batch file):

[View full width]

dsmod group "CN=Phoenix Users,DC=70-290,DC=int" -addmbr "CN=Tom Thomson,OU=Users ,OU=Phoenix,DC=70-290,DC=int" "CN=Arthur Adams,OU=Users,OU=Phoenix,DC=70-290,DC=int" "CN=Frank Carmichael,OU=Users,OU=Phoenix,DC=70-290,DC=int" -c


A second dsmod command sets all these users' passwords to Secur1ty and requires them to change their passwords at the next logon:

[View full width]

dsmod user "CN=Tom Thomson,OU=Users,OU=Phoenix,DC=70-290,DC=int" "CN=Arthur Adams,OU=Users ,OU=Phoenix,DC=70-290,DC=int" "CN=Frank Carmichael,OU=Users,OU=Phoenix,DC=70-290,DC=int" -pwd Secur1ty -mustchpwd yes


And a final dsmod command enables the three accounts:

[View full width]

dsmod user "CN=Tom Thomson,OU=Users,OU=Phoenix,DC=70-290,DC=int" "CN=Arthur Adams,OU=Users ,OU=Phoenix,DC=70-290,DC=int" "CN=Frank Carmichael,OU=Users,OU=Phoenix,DC=70-290,DC=int" -disabled no


A common use for ldifde is to create a set of objects in a new directory from an existing one. For example, you might be creating a set of user accounts in a new test directory from the user accounts in a production directory.

It's a fairly simple process to use ldifde in export mode to create a file containing information about the existing user accounts. Then running ldifde in import mode will load the accounts into the new location. However, the distinguished names will all have to be changed because they will refer to the source directory.

For example, imagine that we are setting up a test domain called 70-290.com. We want to populate the new directory with information exported from our 70-290.int domain. All the information about the accounts will be the same, but the Active Directory paths will be different in all the distinguished names.

This is where the c parameter is used. Using ldifde with c <old string> <new string> causes the replacement of any occurrences of <old string> by <new string> before the data is acted on by ldifde.

Troubleshooting User Accounts

Objective:

Troubleshoot user accounts

There are several reasons why users may find that they cannot use their user accounts. In this section, we will look at account lockouts and at reasons why an account might not be usable.

Troubleshooting Account Lockouts

Objective:

Diagnose and resolve account lockouts

Account lockout is a Windows Server 2003 security feature designed to protect accounts from repeated attempts to guess the account's password. A policy can be set that causes a user account to be disabled if a specific number of invalid login attempts are made within the specified time frame. The account is disabled for a specific number of minutes; if the specified time frame passes without another invalid attempt, the count of invalid attempts is reset to zero.

The term invalid logon attempt includes attempts to guess a password that is protecting a workstation's session, whether with a password-protected screensaver, a Ctrl+Alt+Del Lock Workstation command, the initial login dialog box, or from across the network.

Table 2.1 shows the default values and the ranges of possible values for the account lockout feature.

Table 2.1. Default Values for Account Lockouts

Setting

Default Value

Range of Values

Account lockout duration

30 minutes

From 099,999 minutes. A setting of 0 means the account is locked out until an administrator unlocks it.

Account lockout threshold

Five invalid attempts

From 0999. A setting of 0 means account lockout will not be used.

Reset lockout counter after

30 minutes

From 199,999 minutes.


Many administrators initially set the account lockout duration to 0 so that they will always know if an attempt was made, and this is certainly the most secure approach. However, a few irate calls from locked-out users usually results in a setting of 30 or 60 minutes!

Indefinite Lockouts

Why is an indefinite lockout the most secure approach? If the default settings are in effect, and an intruder tries all weekend to guess an account's password, he could try dozens of times, but nobody would know about the attempts if the intruder stops 30 minutes before the actual user comes to log on.


If a user account is locked out, you can allow it to be used again with Active Directory Users and Computers. Figure 2.17 shows the location.

Figure 2.17. Allow the account to be used by clearing the Account Is Locked Out check box.


To implement account lockout, modify the Default Domain Policy (in the Group Policy tab of the domain object of Active Directory Users and Computers). The account lockout settings are found under Computer Configuration, Windows Settings, Security Setting, Account Policies, Account Lockout Policy.

Like password policies, account lockout can be defined only at the domain level. So be carefulall password policy settings will affect every user account in your domain.

Account lockout is a security feature that must be put in place for any production network to be considered secure. Be sure you have management agreement with any new account password settings, and give your user community several days' warning before you implement it.

Troubleshooting Issues Related to User Account Properties

Objective:

Diagnose and resolve issues related to user account properties

Many help desk analysts will tell you that a large portion of the calls they receive have to do with settings on the user account. Here are several situations that arise because of settings on user account properties.

Account Disabled

It is common practice to disable the account of any user who is either on leave for an extended period or no longer with the organization. Of course, when the user returns and attempts to use the account, she will be unable to log on.

A disabled account can easily be enabled using the Active Directory Users and Computers MMC. Either open the properties of the user account and clear the Account Is Disabled check box on the Accounts tab, or just right click the account and select Enable from the pop-up menu. Alternatively, you can use dsmod and enter the following:

dsmod user <distinguished name> -disabled no


Note: Disable, Don't Delete!

Why not just delete the account of a user who leaves an organization? One reason is that the user account probably has access to files on the network that may be useful to the organization. If you delete the account, retrieving those files can be difficult. It's best to disable the account and then change the password and reenable the account when a person has been designated to review the files to which the account has access.


Account Expired

We know that an account can have an expiration datethe date after which the account cannot be used. If a temporary worker's contract is extended and the network administrator has not been asked to adjust or remove the account expiration date, the worker will not be able to log in until the expiration date is reset.

This setting can be modified in Active Directory Users and Computers: Open the properties of the user account; then on the Account tab, in the Account Expires section, select either Never or a new date. Alternatively, with dsmod, you can enter

dsmod user <distinguished name> -acctexpires never


or

dsmod user <distinguished name> -acctexpires <number of days>


Dial-in Disallowed

A user might complain of being unable to connect by dial-in connection or through a virtual private network (VPN) connection. In this case, check the Dial-In tab of the user account's properties, as shown in Figure 2.18.

Figure 2.18. If the Remote Access Permission setting is Deny Access, no dial-in or VPN connections will be allowed.


To permit dial-in or VPN connections, select Allow Access or, in domains where the functional level is at least Windows 2000 native, Control Access Through Remote Access Policy.

Cannot Change Password

In some cases, users call the help desk because the operating system does not allow them to change their password. There are two possible reasons for this situation.

First, the account may have been set up with the User Cannot Change Password option. This situation is easily rectified, if appropriate, by going to the Account tab of the user account Properties dialog box and clearing the check box.

Second, a user may be unable to change the user account's password because the password entered does not meet the complexity requirements determined by the domain account policies. If enabled, this policy requires that passwords meet the following minimum requirements:

  • Not contain all or part of the user's account name

  • Be at least six characters in length

  • Contain characters from three of the following four categories:

    • English uppercase characters (A through Z)

    • English lowercase characters (a through z)

    • Base 10 digits (0 through 9)

    • Nonalphabetic characters (for example, !, $, #, %)

If the user's password change is being denied due to password complexity requirements, minimum password age, or other restrictions, you must explain the requirements to the user.

Using Saved Queries

A very useful tool in Windows Server 2003 is Saved Queries, a new function under Active Directory Users and Computers. With this facility, a user can define a query that is frequently used and return to it easily whenever it is needed.

Microsoft has supplied several predefined queries to support common administrative tasks such as user management. This includes queries for disabled user accounts, non-expiring passwords, and days since last logon. However, the query function allows you to query for common attributes for user, computer or group accounts. For example, assume that the administrator wants to list all the user accounts in the Engineering department. Follow the procedure in Step by Step 2.5 to create a query that will list all Engineering users.

Step by Step

2.5 Creating a saved query

1.

Open Active Directory Users and Computers and right-click the Saved Queries folder, as shown in Figure 2.19.

Figure 2.19. Select New, Query from the pop-up menu.


2.

Select New, Query from the pop-up menu.

3.

On the New Query dialog box, shown in Figure 2.20, enter the name of the query and a description. When finished, click the Define Query button.

Figure 2.20. Enter a descriptive name for your query.


4.

When the dialog box opens, select Users, Contacts and Groups from the Find drop-down, and then select the Advanced tab.

5.

As shown in Figure 2.21, click the Field button, and then select Users, Department from the pop-up menus.

Figure 2.21. You can query on most fields of Active Directory objects.


6.

Next, click the drop-down for the Condition filed and select IS(Exactly). Enter Engineering in the Value field.

7.

Click the Add button, and then click OK twice to save.

8.

To see the results of the saved query, select it in the left pane and the results will be displayed in the right pane. (See Figure 2.22.)

Figure 2.22. The results of the saved query.


The resulting query is available for use anytime the administrator returns to the Saved Queries function.

You can define quite complex queries, using the fields of any Active Directory object, and save it to be run in the future.

Challenge

You are the administrator of a network for a manufacturing company that has multiple Windows Server 2003 servers used for file and print services.

Common to most manufacturing entities is the need to protect sensitive design data from industrial espionage. The products that your company manufactures are for very price-conscious consumersnot only the design of the products, but also the manufacturing techniques, must be protected.

You need to find a way to minimize the exposure of external users hacking in to your servers.

Using the things that you have learned so far in this chapter, what is the best way to solve this issue in Windows Server 2003? On your own, try to develop a solution that would involve the least amount of downtime and expense.

If you would like to see a possible solution, follow these steps:

This is a fairly straightforward decision, mainly because the only security features we have discussed so far are user accounts and passwords. To increase security in your domain, you can modify the default domain policy to adjust the account-lockout settings so that hackers can't repeatedly try different passwords to access your servers. In addition, you can require complex passwords so that dictionary attacks won't be effective.

1.

From the Start menu, select All Programs, Administrative Tools, Active Directory Users and Computers.

2.

Right-click the domain name entry and select Properties from the pop-up menu.

3.

From the Properties dialog box, click the Group Policy tab.

4.

On the Group Policy tab, double-click the Default Domain Policy entry.

5.

From the Group Policy MMC, navigate to Default Domain Policy, Computer Configuration, Windows Settings, Security Settings, Account Policy, Password Policy. Ensure that the following settings are applied:

  • Account Lockout Threshold3

  • Account Lockout Duration60

  • Passwords Must Meet Complexity RequirementsEnabled

6.

Close the MMC and then click OK in the Properties dialog box to save.

With the lockout threshold set, the account will be locked after three failed logon attempts, and it will be reenabled automatically after 1 hour. Passwords will be required to meet the complexity requirements discussed earlier in this chapter.





MCSA. MCSE 70-290 Exam Prep. Managing and Maintaining a MicrosoftR Windows ServerT 2003 Environment
MCSA/MCSE 70-290 Exam Prep: Managing and Maintaining a Microsoft Windows Server 2003 Environment (2nd Edition)
ISBN: 0789736489
EAN: 2147483647
Year: 2006
Pages: 219
Authors: Lee Scales

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net