Active directory user groups implementation

Subsequent to the Active Directory (AD) implementation discussion, this proposal addresses possible user accounts and group organizations for Riordan Manufacturing. This document discusses user and group accounts available through AD, and addresses possible implementation plans for the parent domain of These plans could also be implemented in the child domains for the four Riordan facilities, though addressing the actual implementations for those sites falls beyond the scope of this document. Users and Groups

AD recognizes several types of accounts. User accounts refer to individual system users. Groups refer to user groupings based on function, need, department, or any number of criteria set by the company and/or the system administrator.

User accounts fall into two categories: domain user accounts and local user accounts. Local user accounts define users to local computers with resource access restricted to resources associated with that local computer. Local user accounts cannot access any other resources within the domain. Domain user accounts contain information that defines users to the domain, AD stores this information, and the information is replicated to the domain controller.

User groups further set and assign permissions for security and access to domain resources. Local groups represent a collection of local users on a single server or computer, with permissions assigned only to resources associated with that single server or computer. Domain local groups represent a collection of domain user accounts or groups specific to the local domain, with permissions to access resources specific to the local domain.

Global groups also contain user accounts or groups from the local domain, but these groups' permission can define access to all domains within the AD tree. Universal groups can contain users from any domain in the AD tree, with permissions set accordingly. Group Configuration and Nesting

Presuming Riordan follows the multiple domain design previously discussed, a good strategy for Riordan would be to incorporate domain local groups, global groups, and universal groups. Universal groups would be reserved for widely-used groups that are fairly static in nature.

In order to provide the most flexible user and group configurations, allowing for network growth and reducing the number of permission assignments, the following provides a guideline for groups and group nesting: §Global groups – organized based on administrative needs

§Domain local groups – identified as common resources §Global groups nested into domain local groups §Permissions assigned to domain local groups The AD implementation proposal categorized the following Organizational Units for Riordan's parent domain: (visio drawing not included)

Organized based on administrative needs, each of the sub-units represent another organizational unit (OU). Each OU has its own and shared resources. After identifying resource needs such as files, folders, printers, and other peripherals, each resource or group of resources would be placed in domain local groups. Global groups with the same access needs for resources would be placed in the appropriate domain local group or groups, inheriting the permissions assigned to the domain local group.

The following depicts a high-level look at possible global and domain local group organizations. Some global groups within one OU will need access to assets in another OU or global group. By placing the global groups within designated domain local groups (shown as "printers," "files & folders," and "computers" in the figure below), Riordan reduces the amount of permission assignments needed. (visio drawing not included)

Further nesting and grouping can easily be done within each OU, depending on assets, user needs, and cross-group permissions. For example, the patent group would need access to files and folders in the development group. The customer service group would need access to sales information, product technical support, and transportation information. Groups and nesting allow much easier administration of all domain assets. A similar schema can be applied to each of Riordan's child domains for the four geographically discrete locations.


Microsoft. (2002). Windows 2000 Domain Architecture: Design Alternatives. Retrieved June 3, 2005, from the World Wide Web: /activedirectory/plan/w2kdomar.mspx#EHAA. NetG. (2005). MS Win 2000 Administration, Part 2. Reinstein, Robert. (2000). Microsoft Windows 2000 Server. Que publishing.