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 AccountsEach 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:
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:
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:
Creating and Modifying User Accounts Using Active Directory Users and Computers
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.
Logging On to a Windows Server 2003 Domain ControllerNow 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 ConsoleNow 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:
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 AccountsNow 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."
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 AccountsNow 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.
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.
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 TemplatesIn 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
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 ToolsNew in Windows Server 2003 are several command-line tools that can help in automating the creation and modification of user accounts:
The first one we'll discuss is dsadd, which adds accounts to the Active Directory service. Creating Accounts with dsaddThe 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:
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:
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 /?):
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:
"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 dsgetIf 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:
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 dsmodYou'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 CommandsIf 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 dsmoveIf 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 dsrmThe 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]]
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
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.
The csvde UtilityThe 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:
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
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:
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 UtilityThe 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):
A second dsmod command sets all these users' passwords to Secur1ty and requires them to change their passwords at the next logon:
And a final dsmod command enables the three accounts:
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
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
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.
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!
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
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 DisabledIt 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 ExpiredWe 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 DisallowedA 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 PasswordIn 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:
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 QueriesA 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.
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.
|