70-240 in 15 minutes a week: AD User and Group Administration

Tuesday Jun 5th 2001 by ServerWatch Staff
Share:

Welcome to Article 15 in Dan DiNicolo's 70-240 in 15 minutes a week series. This week's article covers Active Directory User and Group Administration, as well as publishing resources in Active Directory. This includes a look at user logon names, bulk account processing utilities, account maintenance, group types and strategies, and publishing printers and folders to the directory.

by Dan DiNicolo
http://www.win2000trainer.com

Welcome to article number 15 in my 70-240 in 15 minutes a week series. This week's article covers Active Directory User and Group Administration, as well as publishing resources in Active Directory. This includes a look at user logon names, bulk account processing utilities, account maintenance, group types and strategies, and publishing printers and folders to the directory. Again, this topic falls into the Active Directory portion of the 70-240 exam. I anticipate another 3 to 4 articles relating to Active Directory, before moving into articles relating to the final major area, networking services.

The material covered in this article includes:

- Introduction to user accounts and logon names
- Creating and managing user accounts
- Active Directory group concepts
- Active Directory group strategies
- Publishing resources in Active Directory


Introduction to User Accounts and Logon Names

Since the basics of this topic have already been covered in previous articles, I will keep this part short. Just as a review, remember that 3 main types of user accounts exist in a Windows 2000 Active Directory environment:

Local User Accounts: These accounts exist in the local Security Accounts Manager (SAM) database on each Windows 2000 system (with the exception of domain controllers). These accounts are created using the Local Users and Groups tool in Computer Management. Note that in order to log on with a local account, the account must exist in the SAM database of the system you are logging in from. This makes local accounts impractical for large environments, due to the administrative overhead involved. 

Domain User Accounts: These accounts are stored in Active Directory, and can be used to log on to systems and access resources throughout an AD forest. Accounts are configured centrally using Active Directory Users and Computers. 

Built-in Accounts: These accounts are created by the system and cannot be deleted. By default, both standalone systems and domains will have two accounts, Administrator and Guest. The guest account will be disabled by default.

Since this portion of the series covers Active Directory, we will concentrate on domain user accounts. These accounts are stored on domain controllers, which carry a copy of the Active Directory database. You will need to be familiar with the different formats in which user logon names exist, because there are differences to allow for backwards compatibility with 'downlevel' clients (such as Windows 95, 98, NT). The two main types of names are the User Principal Name (referred to as the user logon name in the interface) and user logon name (pre-Windows 2000). Both are seen in the screen shot below:

A User Principal Name (UPN) is formatted much like an email address. It lists a logon name followed by the '@' sign and domain name. By default, the domain name of the root domain will appear selected in the dropdown box, regardless of the domain in which the account is being created (the drop down list with also contain the domain name of the domain in which you are creating the account). It is also possible to create additional domain suffixes that can appear in the dropdown box and be used in the UPN if you so choose (this is done using Active Directory Domains and Trusts). The only requirement is that all UPNs in the forest be unique. When a user logs on to a Windows 2000 system using a UPN, they need only specify the UPN and the password - there is no longer a need to input or remember the domain name. Another benefit would be having UPNs map to user email addresses, again simplifying the amount of information users need to remember.

The User logon name (pre-Windows 2000) is provided for backwards compatibility with Microsoft systems not running Windows 2000. These systems still rely on traditional Netbios-based authentication, where a username, password, and domain name (in Netbios format) need to be provided. These downlevel logon user names must be unique within a domain. Note that the username portion of both the downlevel logon name and UPN need not be identical.




Creating User Accounts

Creating user accounts in Active Directory is simply enough, seeing as a wizard walks you through the process. Simply right-click in Active Directory User and Computers, choose New - User, and you're off to the races. The wizard only sets up basic account properties, such as names, logon names, passwords, and so forth. To get at the majority of the settings (such as group membership, home directory info, etc), you must access the properties of the user after creating it. In smaller environments, creating all user accounts one at a time may be reasonable. In larger environments, you might create a template account, and then copy that account (and common settings) in order to more quickly create new accounts. However, you should also be aware that Windows 2000 includes 2 utilities that exist for the purpose of bulk-import of user accounts and associated properties: 

Csvde: This tool does bulk import to AD of comma-separated source files. Note that Csvde can only be used to import accounts - it cannot be used to delete or change information. The file used in a simply text file, with values separated by commas. The first line of the file defines the structure. For example, if I wanted to create a .csv text file to be imported that would import 2 user accounts, it might look like the one below:

dn, displayname, objectClass, sAMAccountName, userPrincipalName, telephoneNumber
"cn=dan dinicolo, cn=users, dc=win2000trainer, dc=com", Dan DiNicolo, user, dinicolo, dinicolo@win2000trainer.com, 416-555-5555
"cn=john doe, cn=users, dc=win2000trainer, dc=com", John Doe, user, doe, doe@win2000trainer.com, 416-555-5556

Note that basically any user settings can be imported, as long as the file is structured correctly and the attribute names are properly defined. For a list of available attributes, click here. http://support.microsoft.com/support/kb/articles/q257/2/18.asp

Ldifde: this tool does bulk-import to AD using LDIF, the LDAP Interchange Format. It can be used to add, delete, or modify objects in Active Directory. LDIF files use a line-separated format, meaning that each attribute has its own line, and records are separated by a blank line. For example, if I wanted to create the users from the previous example using ldifde, I would create a text file with the entries shown below:

Dn: cn= dan dinicolo, cn=users, dc=win2000trainer, dc=com
DisplayName: Dan DiNicolo
ObjectClass: user 
SAMAccountName: dinicolo
UserPrincipalName: dinicolo@win2000trainer.com
TelephoneNumber: 416-555-5555

Dn: cn= john doe, cn=users, dc=win2000trainer, dc=com
DisplayName: John Doe
ObjectClass: user 
SAMAccountName: doe
UserPrincipalName: doe@win2000trainer.com
TelephoneNumber: 416-555-5556

Note that all accounts created with these utilities are disabled by default, and that you cannot include passwords in the bulk-import process (they are left blank be default). For a more detailed overview of csvde and ldifde, click here 

Of course, after user accounts have been created, a number of common management tasks may need to be performed. Note that while many of these involve setting up information relating to a particular user (phone numbers, addresses, etc), some have father-reaching implications in terms of security. Note that the most important account settings are found on the Account tab in the properties of a user account. It is from here that you can require that a user change their password at next logon, disable an account, set logon hour restrictions, account expiry, account lockout, and so forth. 

Note that passwords are reset in Windows 2000 by right clicking on an account and choosing the Reset Password option. In big environments (especially ones with many OUs) you may have trouble remembering where you created an account. To quickly find the user (or other objects), right click the domain name and choose Find in Active Directory Users and Computers. 

A couple of additional notes on user accounts:

- Remember that an account can be renamed, without affecting the resources that the account has access to. As such, if Bob quits and Mark replaces him, simply rename the Bob's account (and change the personal information obviously) and Mary will be a have access to everything that Bob previously did.
- Deleting an account is a big deal. When you delete an account, the SID associated with the account is also deleted. As such, if you were to recreate an account with the same username, it would not have access to whatever the original account has been granted access to, since the SID would be different. Note that a deleted account can be restored using an authoritative restore (discussed later in the series).


Active Directory Group Concepts

Windows 2000 Active Directory presents a number of different group options not found in the NT domain environment. The two biggest changes are the different types/scopes of groups that now exist, as well as the ability to nest groups. Group accounts for domain users are again created in Active Directory Users and Computers

First, understand that there are two types of groups: security and distribution. Distribution groups exist for the purpose of sending email, and do not have a SID. Security groups do have a SID, and as such can be used to assign permissions and rights via access control lists and policy settings. 

Secondly, there are three scopes of groups: domain local, global, and universal. A quick overview of each:

Domain Local groups: domain local groups are similar to local groups in NT 4, except that they can be applied to any system within a domain, not just on the system where the group exists (since domain local groups actually reside in the AD database). These groups are usually used to assign permissions to resources. 

Global groups: global groups are very similar to those found in an NT 4 domain. They are still collections of users with common needs. 

Universal groups: universal groups are totally new in Windows 2000. A universal group can contain users from any domain in an AD forest. Similar to global groups, they are used as collections of users with common needs or characteristics. Only an member of the Enterprise Admins group can create a universal group.

The screen shot below shows the dialog box you are presented with when creating a new group:

Note that the option to create a Universal group is not available. This is because my domain is still in Mixed Mode. Universal groups can only be created in Native Mode. The ability to nest groups is also new to Windows 2000, and is also only available in Native Mode. Nesting refers to the ability to place a group into a group of the same type - for example placing a global group into a global group. The table below outlines group membership rules for domains in Native Mode.

Group Scope May Contain
Domain Local Users from any domain, global groups from any domain, universal groups, domain local groups from the same domain. Can only be used to access resources in the same domain.
Global Users from same domain, global groups from same domain. Can be used to access resources in any domain.
Universal Users from any domain, global groups from any domain, universal groups. Can be used to access resources in any domain.

Active Directory Group Strategies

Some of you will remember the group usage strategy outlined by Microsoft for NT 4 domain environments. It suggested that you place user accounts into global groups according to needs, assign permissions to local groups, and then place global groups into local groups, thereby giving users access to resources. This model was often referred to as AGLP:

Accounts (get placed into) Global Groups (which are then placed in) Local Groups (who are ultimately assigned) Permissions 

Although there are many different possibilities in terms of assigning permissions, the above method is amongst the most scalable. By the same token, a methodology exists in Windows 2000 that you should follow (especially on the exam!). 

Accounts > Global Groups > Domain Local Groups > Permissions

Note that the model can extend beyond this, however. For example, you can nest global groups (which is useful if you have a few global groups in the same domain who you wish to further organize), or place global groups from different domains into a Universal group. With a Universal group, this would then make the model:

Accounts > Global Groups > Universal > Domain Local Groups > Permissions

The idea is simple - group users with common needs using global groups (or universal if you wish), and then place that group into a domain local group, which is assigned permissions to a resource. This allows many users to have access to the resource, while assigning permissions only once. A name for the new model that you won't forget? Try AGULP (just remember that the L is for domain local now)

Publishing Resources in Active Directory

One of the benefits of Active Directory is that it is useful for more than just user authentication. As a store of information, Active Directory can be queried to find details about objects that we know about (such as a users telephone number), as well as to find objects that we perhaps didnt know existed at all. Many objects are published in Active Directory by default, such as users, groups, and computers. However, it is also possible to publish information about other useful objects, most notably printers and shared folders. Once a resource has been published, the resource can be moved, and users will still be able to find it, as long as you update the shortcut to the object in Active Directory.

Let's start with a look at printers. Printers are published automatically in Active Directory as long as they were created on a print server running Windows 2000. However, it is possible that you have a printer that is using a downlevel system as a print server, say Windows 98 or Windows NT. These can also be published to AD, either by using Active Directory Users and Computers, or by using the file pubprn.vbs found in the Windows 2000 system32 directory. Printers are published using their UNC path, in the format \\print_server\printer. The screen below shows a printer being published in AD Users and Computers.

The pubprn.vbs script needs to be run from the command prompt, using the cscript scripting host. The command needs to specify the container into which the printer(s) should be published, in LDAP format. The example below first shows a single printer being published into the printers OU, and then the command to have all printers from a print server published to the printers OU.

Cscript %systemroot%\system32\pubprn.vbs \\ntserver\hp4 "LDAP://OU=Printers, DC=win2000trainer, DC=com"

Cscript %systemroot%\system32\pubprn.vbd ntserver "LDAP://OU=Printers, DC=win2000trainer, DC=com"

Once the printer has been published, it is then possible for users to search for it in Active Directory, using the Search command from the Start menu. Note that the only printers that will be returned by a search are those to which the user has access.

Among the most useful features in the ability to search for a printer is the ability to search by location, according to the location listed on the properties of the printer itself. It is also worth noting that there is a very powerful option associated with locations called printer location tracking. In this setup the location field is automatically populated with the location name of the subnet where the user is located. Essentially subnets must be given location names (in AD Sites and Services, discussed below), printers must be given location names that correspond to their subnet location, and location tracking must be enabled in group policy. If these have been done, when a user tries to search for a printer, the location field will be populated with the name of the current location, based on the user's subnet location. As such, the user would be presented with a list of printers which (in theory at least) should be close by. The screen shot below outlines the setting in group policy for printer location pre-population. The setting is found in \Computer Configuration\Administrative Templates\Printers.

If you want the exact step-by-step details of enabling location tracking in policy, click here

In order for printer location tracking to work, all subnet objects must have an associated location. This is set in the properties of the subnet object in AD Sites and Services, as shown below. 

Location names follow the convention Name/Name/Name etc, where any name can be only 32 characters, and the maximum length for an entire location is 260 characters. It would be a very good idea to map out a location naming convention that makes sense and maps to the actual physical network topology. For example, in a multinational corporation with a presence in many countries might use the format:

Company/USA/Boston/Building 1/Floor 3 

Or

Company/Europe/Czech/Prague/HeadOffice

Just remember that location names correspond to IP subnets. Once enabled in policy, the printer search box changes to automatically include the location, as shown below:

Shared folders can also be published in Active Directory in order to simplify the ability to find information. Any folder accessible by a UNC path can be published in Active Directory. To do this, in AD Users and Computers right click and choose New Shared Folder. Users can now browse for the folder in Active Directory, or a shortcut can be created to it. The UNC location of the folder can also be changed, by accessing the properties of the published folder, making it easy to change physical locations without affecting how users see resources. Just as importantly, you can also associate keywords with the folder (these are set in the properties of the published shared folder), which would allow users to search for it by those keywords. Searching by keyword is done by using the Find command in either AD Users and Computers, or by browsing to the AD domain in My Network Places, right clicking and choosing Find, as shown below:

Note that the published object, like all objects in Active Directory, has a discretionary access control list (DACL) associated with it. As such, the permissions granted to the user via the published folder may differ from the NTFS or Share permissions set on the folder itself, which may restrict a user's ability to access it with appropriate control. To view the permissions associated with the folder, remember that you will need to have the View - Advanced Features option selected in AD Users and Computers prior to accessing the object's properties - this will allow you to view the DACL via the Security tab.

That does it for this week. In next week's article I intend to cover a couple of topics, both delegating administrative control and implementing group policy. Thanks again to everyone who has been supporting the series and sticking with their studies. As always, feel free to contact me with your comments, questions, and suggestions, I look forward to hearing from you. I also hope that you'll visit my website, where you'll find my free practice exams, article archive, and links to great study resources. I hope you'll also consider using my message board to ask your technical questions - maybe you can help out by answering the questions that others have as well! Until next week, good luck with your studies.

Dan
dan@win2000trainer.com
http://www.win2000trainer.com

Share:
Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved