70-240 in 15 minutes a week: Active Directory Object Management and DFS

by Dan DiNicolo

Welcome to article number ten in my 70-240 in 15 minutes a week series. This week's article covers domain object management and the distibuted file system. This includes a look at domain user, group, and container management, user profiles, and DFS concepts and administration. This is the third article in the server portion of the series, with another 2 or 3articles to follow before we begin Active Directory Implementation and Administration. 

The material covered in this article includes:

- Active Directory Object Management
- Domain users, groups, computers, and OUs
- User Profiles
- Distributed File System (DFS)

Active Directory Object Management

The administration of Active Directory involves the management of domain objects and their associated properties. The objects managed within a domain include user accounts, group accounts, computer accounts, and organizational units primarily. Unlike NT 4 where we used one tool to manage users and groups (User Manager for Domains) and another to manage computer accounts (Server Manager), in a Windows 2000 domain all management of these objects is handled via a tool called Active Directory Users and Computers, an MMC snap-in. Note that this tool can quickly be accessed from the Run command, by running dsa.msc. When opened, Active Directory Users and Computers will be focused on a particular domain controller. This will be the domain controller to which updates and additions will be written. It can be changed by right-clicking the domain object and choosing to connect to another domain controller instead. This is actually quite useful - because replication between sites can have associated schedules, you might decide to change a user's properties on their local domain controller instead of another, and thus not have to wait for the changes to replicate. The AD Users and Computers program displays the domain object, and then a series of containers, as shown below:
Welcome to article number ten in my 70-240 in 15 minutes a week series. This week's article covers domain object management and the distibuted file system. This includes a look at domain user, group, and container management, user profiles, and DFS concepts and administration.

First and foremost, the folders that appear beneath the domain object are actually containers. Two types of containers exist - built-in containers, and OUs. A built-in container appears as a plain folder, while an OU looks like a folder with a book icon on it. Note that OUs can have group policies applied to them, while built-in containers cannot. However, both types of container allow you to delegate administrative control. The containers which are created automatically are described below:

Built-in: This container houses all built-in user and group accounts created when Active Directory is installed. 
Computers: This container houses any upgraded computer accounts, or any new accounts added as part of joining a domain from a client system.
Domain Controllers: This OU contains all domain controllers for the domain.
ForeignSecurityPrincipals: Container for SIDs of user accounts from external trusted domains.
Users: This container is where upgraded user accounts are stored. You will also find the domain Administrator and Guest accounts here.

These are not the only built-in containers that exist, however. If you choose Advanced Features from the View menu, you will also find the following containers:

LostAndFound: This container houses orphaned objects. For example, imagine if an OU was deleted on one domain controller, and before replication had completed, a user was created in that OU on another domain controller. This user would be placed into the LostAndFound container, since its container object no longer exists.
System: This container holds settings relating to domain operational information, including AD-integrated DNS, domain DFS configuration, and so forth.

Within these containers (or the root of the domain) other objects can be created such as users, computers, groups and so forth. Note that there is no requirement to actually create users in the Users container, or computer accounts within the Computers container. You can use these, or create additional OUs according to your organizational needs and place accounts there instead. You can also easily move objects between contains by right-clicking the object and choosing Move. To create a new object within a container, right-click the object and choose New, and then choose the appropriate object type you wish to create, as shown below:

User Account Objects

Every User that needs to log into the domain will require a user account. Note that the account can be created within any container (built-in, or OU that you create), since these are all still technically 'domain' accounts. The user will still only need to supply the domain they wish to log into, not the container in which their account actually exists. Unlike NT 4 where the properties relating to a user account were very limited, in Active Directory user account properties are actually quite extensive. Most of these are not configured during the account creation process, but actually afterwards by accessing the properties of an account. Like NT 4, you can change the properties of multiple accounts simulataneously by selecting many accounts and then accessing their properties collectively. The property tabs found on a domain user account differ based on the services installed. For example, if Exchange 2000 is installed, a user's mail configuration is done from the property sheets. Note that to view some tabs, you must choose Advanced Features from the View menu.The default tabs and their purposes are listed below:

General - contains basic information about the user including first name, last name, email address, etc.
Address - home address of the user
Account - user account details, including logon name, logon hours, account options, and account expiry.
Profile - user profile and logon script information, as well as home directory details.
Telephones - various phone numbers for the user.
Organization - information on title, department, and manager.
Environment - Terminal services startup information.
Sessions - settings relating to Terminal service sessions, such as idle session disconnect.
Remote Control - settings relating to Terminal service remote control options.
Terminal Services Profile - information relating to Terminal service profile, home directory, and allowing/disallowing logon to terminal server.
Published Certificates - listing of users X.509 certificates and purposes.
Member Of - listing of groups the user is a member of.
Dial-in - Dial-in settings for this user, including items such as callback settings.
Object - shows fully qualified name of the user object, when it was created.
Security - show access control list associated with this object.


Group accounts have also changed in Windows 2000. Unlike NT 4 where we only found Global and Local groups, Windows 2000 includes new group types, scopes and abilities. Before we discuss these however, we need to take a look at something referred to as the 'mode' of a domain. By default, all domains are created in something called Mixed Mode. In this mode, NT 4 BDCs can still exist, and many of the rules associated with an NT 4 domain still apply. Once all domain controllers have been switched to Windows 2000, the domain can be switched into what is referred to as Native Mode. This is a one-way process. Note that even if you are not upgrading an NT 4 domain, a Windows 2000 domain is still automatically created in Mixed Mode, and the change to Native mode must be made before many of the new feature with respect to users and groups can be used.

Windows 2000 supports two types of groups. The first are very similar to groups in NT 4, and are referred to as Security groups. Quite simply, a security group has a SID, and as such can be part of a Discretionary Access Control List (DACL), the list of users and groups that have permissions to access a resource. The second type of group is called a Distribution group, and exists for the purposes of sending email messages to a group of users. This functionality largely exists for the purpose of Exchange 2000 integration. Distribution groups have no SID, and as such cannot be added to a DACL. You may be asking why it is necessary to make a distinction. The reason relates to what happens when a user logs on - a security token gets created that lists their SID, and the SIDs of the groups they are part of. The larger the number of security groups, the larger the security token for a user, and the longer it will take to log on. Distribution groups provide an easy and less resource-intensive way to be able to integrate messaging technologies with Active Directory.

After group type, you must consider group scope. In Windows 2000, there are three scopes of groups - domain local, global, and universal. An explanation of each is listed below:

Domain Local: these groups exist on domain controllers, and can be applied to any system in a domain. These groups should be used to apply permissions, similar to NT 4. The benefit is that unlike local groups from NT 4, these can all be created in Active Directory and then applied to any system. In Native Mode, domain local groups can contain Users (from any domain), Global groups (from any domain), Universal groups, and domain local groups from the same domain. Note that in Mixed mode, domain local groups can only contain global groups and users from any domain, similar to how things were in NT 4.

Global Groups: These groups are still meant as a way to group users with common needs. In Native Mode, a global group can contain users from the same domain, as well as other global groups from the same domain. In Mixed mode, a global group may only contain users from the same domain.

Universal Groups: These only exist in Native Mode, and can contain users or global groups from any domain in the entire forest. These reside on domain controllers designated as global catalog servers. 

You did read the above correctly. Windows 2000 in Native mode does support group nesting, or placing global groups in global groups, for example. This is meant to provide an additional level of flexibility with respect to administration, but also the potential for confusion if groups are nested too deeply. My suggestion is to use same-scope group nesting sparingly. Also, you should note that Windows 2000 groups can also contain computer accounts - following the same rules as those listed for users above.

As far as creating groups in concerned, right-click the object in which you wish to create the group and choose New Group. You will be prompted with the screen below.

Note that if the Universal group option is grayed out, that would be a good indication of a domain still in Mixed mode. To view the membership of a group, go into the properties and view the Members tab. To view the groups that this group is a member of, simply choose the Member Of tab. A discussion of each of the built-in groups, and the rights associated with them, will be looked at in the Active Directory portion of the series. 

Computer Accounts

Active Directory requires that computer accounts be created for both Windows 2000 and Windows NT-based operating systems. Similar to NT 4, Windows 9x-based systems do not require this, on account on the fact that these systems do not have a SID. Computer accounts can be created in the built-in Computers container or other containers in advance. If you create the computer account as part of joining a domain, the account will automatically be placed in the Computers container. Of course, it can be moved at any time, according to your management and administration needs. 

Organizational Units

As noted earlier, the basic difference between a built-in container and an OU is that OUs can have group policy settings applied to them. Another benefit is the fact that OUs can be nested, which provides benefits in terms of the inheritance of group policy. Note that an OU can be moved within a domain, just like any other domain object. Simple right-click the OU and choose to move it. Be careful about deleting an OU, however, since you will also be deleting all of the objects it contains (at least you get a warning!)

OUs exist primarily for the purpose of organization of resources according to administrative needs. For example, I can delegate control over an OU called Servers to the server support team, and not grant them administrative access to anything else. By the same token, I can apply policies to an OU (such as one containing all bank teller user accounts), which would allow me to lock down the desktop environments of these users specifically. As mentioned in a previous article, group policy can be applied at 4 levels, in the following order:

1. Local
2. Site
3. Domain
4. OU followed by sub-OUs, if any

The order of application is very important. All group policy settings that apply merge together, unless there is a conflict. In the case of conflicting settings, the settings at the lower level apply. For example, if a setting at the domain level said that users were to have the Run command disabled, and a policy at the OU level specifically enabled it, the user would have access to the Run command. The order followed is the one described above. By the same token, it is possible that conflicting settings would exist in different policies applied to the same OU, as listed below:

In this case, it is important to note that policies are applied from bottom to top. That is, first Policy A is applied, followed by Policy B, and then Policy C. As such, if there were a conflict between Policy C and Policy A, the settings from Policy C would apply. You can change the order of policies at a given level by using the up and down arrows seen in the screen shot above.

I already know what you're thinking. That means that someone could create a policy at the OU level that overrides a site or domain policy - you're absolutely correct. In order to control this, Windows 2000 enables two features: No Override and Block Inheritance. This No Override feature is based on the prinicple that higher levels in the hierarchy should have more control. As such, No Override can be set on site, domain, and OU policies. When this is set, as shown below, these settings override any others in the event of a conflict. Note that settings still merge, but in the event of conflicts, the No Override policy's settings will take precedence.

By the same token, in some scenarios you may not want block policy settings to a particular OU, like the one containing yor software developers for example. In this case, you can set Block Inheritance on a policy. In this case, any settings that would be inherited from above are ignored. Block Inheritance is set on a policy as shown below:

This leads to another interesting question - what happens when an administrator has set No Override on a domain policy, and another administrator has set Block Inheritance on an OU policy? Clearly a conflict exists, and the answer is simple - No Override always wins.

You should be aware that group policy settings will automatically refresh on a client system approximately every 90 minutes (there is a random offset of 30 minutes), and on a domain controller every 5 minutes by default. If you wish to force a group policy update immediately, you would use the command-line security configuration and analysis tool, secedit.exe. The syntax is below:

To refresh the computer portion of group policy: secedit /refreshpolicy machine_policy
To refresh the user portion if group policy: secedit /refreshpolicy user_policy

One last note with respect to group policy objects. When these are set up, there are security permsissions associated with them. By default, the Authenticated Users group is given the 'Apply Group Policy' and 'Read' permissions to the GPO. If you wanted to filter policy application further, you could change the permissions associated with a GPO. For example, if I removed the permissions above from the Authenticated Users group, and applied them only to the Sales group in my domain, then the settings in this GPO would only be applied to members of the Sales group. Be sure to remember that group policy cannot be applied to groups - however, you now know that policy settings can be filtered to achieve a similar objective.

User Profiles

Much like in NT 4, a user profile defines a user's desktop environment and settings. This can include things like the placement of desktop icons, drive and printer mappings, and mouse-related properties. In Windows 2000, two types of profiles still exist - local and roaming. 

A local profile is the most simple. By default, every time a user logs onto a system for the first time, the default profile is opened for that user, and is ultimately saved on that system in a folder bearing the user's name, under the Documents and Settings folder. Any changes made by the user are saved at logoff. When the user logs on to that system again, they receive the environment they left off with. The nature of a local profile is that it does not 'follow' the user. That is, if the user were to log on to another computer, they would receive the default profile, and another local profile would be created.

A roaming profile is one where the user's environment 'follows' them as they move to different systems on the network. These profiles are stored on a server, and are copied back and forth as the user logs on or off. In order for a user to have a roaming profile, the location of the profile must be stored in the properties of the user's account, in the User Profile section of the 'Profile' tab, as shown below:

As far as roaming profiles are concerned, two types exist, personal and mandatory. A personal roaming profile is the default type, and allows a user to make changes to their profile. A mandatory roaming profile is one which a user is not allowed to change - that is, any changes that they make while logged on will not be back saved to the server. A personal roaming profile is changed to a mandatory roaming profile by renaming the Ntuser.dat file in the profile to Ntuser.man. When mandatory roaming profiles are used, usually you have many users accessing the safe profile information, so many accounts would be set up to point to the same profile location. A good example of why mandatory roaming profiles might be used is with respect to a environment such as that used by bank tellers - we would want their environment to always be consistent, regardless of the system to which they logged on. 

For a list of local profiles on a system, use the User Profiles tab in the System program. This will show you the profiles that exist on the system, their size, and type (local or roaming). This program also allows you to copy a profile over to a server and change its type, if you wanted to change a profile from local to roaming, or vice versa. 

The Distributed File System

DFS, or the distrbuted file system, was a feature originally found in the NT 4 product but underutilized. The distributed file system allows you to organize shared folders on the network into a single logical hierarchy, while maintaining data on different physical servers. To the user, data which is actually distributed appears to fall under an organized, structured hierarchy. This allows you to not only manipulate how users see the data (you can use different share names for existing folders), but also how they access it (you can create whatever hierarchy will best suit the needs of the users). For example, data might be physically distributed, as outlined below:

Sales data files \\server13\salesdata 
Sales quota files \\server2\s-quotainfo
Sales report files \\server1\rpt

Using DFS, we could create a DFS root called Sales using an empty shared folder on Server1 called Sales, and create a the following hierarchy:



We would simply map a drive for users to the Sales folder on Server1, and they would automatically be redirected to the appropriate folder of the appropriate server as they accessed the subfolders. Note that DFS maintains and does not change any of the permissions associated with the actual folders. Whatever level of access users had to the folders before DFS will be the same level of access after DFS has been configured.

In Windows 2000, two types of DFS structures exist - standalone DFS, and domain-based DFS. Note that while a domain can host multiple DFS roots, any server can host only a single DFS root, regardless of type (stand-alone or domain-based).

Standalone DFS structures can be created on any server running Windows 2000 with DFS installed (it is installed by default). With standalone DFS, Active Directory is not required. Creating a DFS structure begins with a server hosting the root of DFS. This is the shared folder that will first be connected to by clients. With Standalone DFS, this root can only be hosted on a single server. As such, if this server fails, users will not be able to gain access to the DFS tree (of course, they will still be able to access resources that exist on other physical servers if they knew the location of those folders). Standalone DFS does not support having replicas of the root, although you can configure replicas of folders beneath the root. This would allow users to be load-balanced between folders that exist of different servers, but contain identical information. Note that in a standalone DFS setup, the replication of data between replicas does not happen automatically - you must somehow make replication happen between the replicas (using a tool such a robocopy, for instance).

Domain-based DFS takes advantage of Active Directory by storing DFS topology information in Active Directory. This type of DFS supports the ability to have root replicas, which provide both load-balancing and fault-tolerance. For example, if multiple root-replicas were created and a replica is taken offline, a user can still access the DFS structure, simply by being redirected to another replica. On top of this, replicas of shared folders can also be created, and replication can take place automatically using the file replication service (FRS) - up to 32 replicas are supported. In the case of domain-based DFS, the root points not to a server, but instead to the domain - an example of a DFS root might be \\win2000trainer.com\dfsroot. Using site information stored in Active Directory, a user attempting to access the DFS root would be redirected to the root replica in their own site, for example, instead of accessing the root from over the WAN. Note that in order to access domain-based DFS, a client running Windows 9x, or Windows NT 4 needs to have the Active Directory client software installed.

And yet another week over and done. Thanks again to all those who have been following the series. As usual, I look forward to your comments, questions, and feedback. I hope you'll help me by letting others know about the series if you find it useful. Be sure to keep an eye on my website over the next few weeks - a number of big changes are coming, and I need another few weeks to get everything prepared. I guarantee that it will all ultimately benefit you and your studies! Best of luck with your studies this week.



This article was originally published on Apr 19, 2001
Page 1 of 1

Thanks for your registration, follow us on our social networks to keep up-to-date