Presentation on theme: "Overview Identifying Business Needs Characterizing the IT Organization"— Presentation transcript:
1Module 3: Designing Active Directory to Delegate Administrative Authority
2Overview Identifying Business Needs Characterizing the IT Organization Developing a Strategy for Administrative DesignDeveloping a Strategy for Delegation
3Microsoft® Windows® 2000 Active Directory™ provides network architects with control over information access in Active Directory. By structuring the Active Directory hierarchy and then managing the permissions on directory objects and properties, you can precisely specify the accounts that can access the directory and the level of permissions that they can have. For example, you can give a person authority over user passwords in a particular organizational unit (OU), without giving that person any control over other objects or attributes in Active Directory. This precise specification allows administrators to delegate specific authority over portions of the directory to groups of users, without making directory information vulnerable to unauthorized access.
4At the end of this module, you will be able to: Identify the business needs of an organization that will impact the hierarchical design of Active Directory.Develop a strategy for planning an administrative design that facilitates delegation.Develop strategies for delegation of administrative authority.
5Identifying Business Needs CEOOrganizational ChartInformationTechnologyProductionHuman ResourcesAccountingInformationTechnologyIT InfrastructurePurchasingLogisticsAccounts ReceivableAccounts PayableInfrastructureSoutheastNortheastNorthwestDocumenting the Administrative Process:Level of AdministrationWho Administers WhatBuild Flexibility Into PlanAtlantaCharlotteSeattlePortland
6Organizations can delegate administrative authority by granting limited administrative permissions to trusted individuals. Delegation reduces the workload and responsibility of a single administrator. Delegation also safely separates administrative authority from other areas of the organization. Managers who have the appropriate administrative rights can, in turn, delegate administration of a subset of their accounts and resources to other individuals. To support delegation of administrative authority, you should design the Active Directory structure to support the organization's desired administrative Information Technology (IT) structure.
7Documenting the Administrative Process Begin by documenting the existing structure of the organization. One strategy is to divide the administrative tasks into categories and then document the administrator or administrators responsible for each category. Once the existing process has been documented, you should work with the planning team to identify areas for improvement. For example, it may be more cost- effective to combine several IT teams from different divisions. You may identify non-IT employees who can assist in the administrative process and reduce the IT staff workload. This allows the IT staff to focus on the areas where their expertise is most needed.
8Once the existing and desired processes are identified, use the following as guidelines for your delegation plan:
9Determine the level of administration Determine the level of administration. Decide what each group should control and at what level in the administrative hierarchy you will delegate administration. The delegation plan should define what permissions a group of users may have for that level of the hierarchy.
10Identify the administrators and the users and resources they administer. This information will help determine the ownership and permissions assignment to the OUs you create to support the delegation plan. An administrator or the object owner must grant users access rights to an object in Active Directory before users can have access to the object.
11Build flexibility into your delegation model Build flexibility into your delegation model. You can grant rights to administrators to manage a small set of users or groups within their area of responsibility and, at the same time, deny rights to manage accounts in other parts of the organization. For example, you may want to grant printer control rights to a small group of users. You may allow certain OU administrators to have Full Control over specific OUs and objects. You may restrict other administrators altogether, so that they are not able to view the OU.
12Characterizing the IT Organization Centralized ITCentralized IT with Decentralized ManagementDecentralized ITOutsourced IT
13Before designing the administrative structure of an organization, you must first characterize your IT organization. The most common IT organizations are:
14Centralized IT. The centralized IT organization reports to a single individual, and is usually the group responsible for all network and information services, although some day-to-day tasks may be delegated to certain groups or departments.
15Centralized IT with Decentralized Management Centralized IT with Decentralized Management. IT organizations often employ distributed management, where control is spread out across more than one location. In this model, a centrally located core IT team has responsibility for the base infrastructure services, but delegates most of the day-to-day operations to IT groups in branch offices, which provide local administrative support to their users.
16Decentralized IT. This type of organization allows various business units to select an appropriate IT model to serve the needs of each individual unit. This type of organization may have multiple IT groups with varying needs and goals. Whenever there are organization-wide technology initiatives, such as an upgrade to an organization-wide messaging application, the IT groups must work together to implement changes.
17Outsourced IT. Some organizations may choose to outsource all or part of their IT organization. When only parts of the IT organization are outsourced, it becomes imperative that a proper delegation model be implemented. Thus, the internal IT group maintains control of the organization without compromising the service level agreements the outsourced company has committed to provide. For example, if an outsourced company has committed to support the physical infrastructure of an organization's network, you may choose to create OUs to contain the routers, servers, and any other items over which they may need control.
18Developing a Strategy for Administrative Design Designing a Hierarchy Based on LocationDesigning a Hierarchy Based on OrganizationDesigning a Hierarchy Based on FunctionDesigning a Hybrid Hierarchy by Location then OrganizationDesigning a Hybrid Hierarchy by Organization then LocationDesign Guidelines
19If your Active Directory design is accurately modeled after the needs of an organization's administrative IT model, then that design will best support delegation of administrative authority. When planning the Active Directory administrative structure, it is important to accommodate for change and growth in the organization. Organizational changes should not impact the domain and high level OU structure, for example.
20In this lesson you will learn about the following topics: Designing a hierarchy based on locationDesigning a hierarchy based on organizationDesigning a hierarchy based on functionDesigning a hybrid hierarchy by location then organizationDesigning a hybrid hierarchy by organization then locationDesign guidelines
21Designing a Hierarchy Based on Location Is Resistant to ChangeAccommodates Mergers and ExpansionsMay Compromise SecurityTakes Advantage of Network Strengthsnwtraders.msftOUNew EnglandBostonHartfordDomainna.nwtraders.msftasia.nwtraders.msft
22If the IT organization is centralized, but network management is geographically distributed, then organizing the Active Directory structure by location may be the best strategy. For example, you may decide to create OUs for New England, Boston and Hartford within the same domain, such as contoso.msft.
23Characteristics of Location-based Designs A location-based OU or domain hierarchy possesses the following characteristics:Resistant to company reorganizations. While divisions and departments may change frequently, location rarely does in most organizations.Accommodates Mergers and Expansions. If an organization merges with or acquires another company, it is simple to add new locations to the OU or domain hierarchy.Takes Advantage of Network Strengths. Typically, an organization's physical network topology will resemble a location-based hierarchy. If you create domains with this method, you can take advantage of areas where the network has high bandwidth, and limit the amount of data replicated across low bandwidth areas.Possible Security Compromises. If a location includes multiple divisions or departments, an individual or group with administrative authority over that domain or OU may also have authority over any child domains or OUs.Important: A location-based OU or domain hierarchy is recommended only if administrators are present at each location. If administrators from multiple departments or divisions are in the same location, they may need to cooperate with each other for certain administrative tasks.
24Designing a Hierarchy Based on Organization Reflects Business ModelIs Vulnerable to ReorganizationsMaintains Departmental AutonomyAccommodates Mergers and ExpansionsMay Affect ReplicationOUmanufacturingengineeringpurchasingresearchnwtraders.msftmfg.nwtraders.msftdistrib.nwtraders.msftDomain
25An organization that separates IT administration by department or division may choose to design Active Directory based on the structure of the organization. An architect must be very careful to follow the administrative structure, rather than the organizational chart, when designing an organization-based Active Directory. The organizational chart may not map to the administrative needs of an organization. If you design the Active Directory structure to reflect the organizational chart, it may be difficult to delegate administrative authority, because the objects in the Active Directory, such as printers and file shares, may not be grouped in a way that facilitates delegation of administrative authority. Because users never see the Active Directory structure, the design should accommodate the administrator's convenience instead of the users' convenience.
26When deciding whether to organize the Active Directory structure by organization, consider the following characteristics of organization-based designs:
27Reflects Business Model Reflects Business Model. An organizational structure tends to better reflect the organization's actual business practices than a structure based on location. However, users do not see the hierarchical structure.
28Vulnerable to Reorganizations Vulnerable to Reorganizations. Because the reorganization of the corporate structure can greatly alter the organization-based design, extensive IT resources may be needed to restructure Active Directory.
29Maintains Departmental and Divisional Autonomy Maintains Departmental and Divisional Autonomy. An organizational hierarchy presents few security concerns, because there will likely be no crossing of departmental or divisional boundaries with this design. When trying to define the hierarchy design, the security requirements at the departmental level are an important factor.
30Accommodates Mergers and Expansions Accommodates Mergers and Expansions. If an organization merges with or acquires another organization, additional departments can be easily added to the organization-based hierarchy.
31May Impact Replication May Impact Replication. Organization-based structures that are used to create domains may not make efficient use of the network, because the domain naming context may replicate across one or more low bandwidth areas.
32Designing a Hierarchy Based on Function Is Immune to ReorganizationsMay Require Additional LayersMay Affect Replicationsaleshardwareproject1project2consultantsmarketing
33An organization with decentralized administration may choose to design the Active Directory structure based on the functions within the organization. A function-based hierarchy is an ideal choice for small organizations that have job functions that span several departments. For instance, an organization such as a consulting agency may have a cross-departmental team that is dedicated to supporting a particular customer. Such a company could benefit from a function-based design. A function-based hierarchy considers only the business functions of the organization, without regard to geographical location, departmental or divisional barriers. Choose this approach only if the IT function is not based on location or organization.
34Characteristics of Function-based Designs When deciding whether to organize the Active Directory structure by function, consider the following characteristics of function- based designs:Immune to Reorganizations. A function-based hierarchy is not affected by corporate or organizational reorganizations.May Require Additional Layers. When using this structure, it may be necessary to create additional layers in the OU hierarchy to accommodate administration of users, printers, servers, and network shares.May Impact Replication. Organization-based structures that are used to create domains may not make efficient use of the network, because the domain naming context may replicate across one or more areas of low bandwidth.Important: Function-based hierarchies are only appropriate in small organizations because functional departments in medium and large organizations are often very diverse and do not group effectively into broad categories.
35Designing a Hybrid Hierarchy by Location then Organization Allows for GrowthAllows for Security BoundariesLeverages Strength of Physical NetworkMay Require Lower Level Changes After a Reorganizationasia.nwtraders.msftMfgHRresearchrecruitingtraining
36Some organizations combine various strategies to accommodate the most appropriate administrative structure. Designing a hybrid hierarchy combines strengths from several areas to meet the needs of the organization. Designing the higher OUs or domains by location, and the lower OU or domain levels by organization works well in a highly distributed organization with a centralized IT function and strong departmental or divisional separation. Because the highest levels are based on location, this model is less likely to change, and therefore less likely to require a major effort in the event of a reorganization.
37When designing a hybrid hierarchy by location then organization, consider that this type of hierarchy has the following characteristics:Allows for additional geographic, departmental, or divisional growth.Allows for distinct security boundaries by department or division.May necessitate a new design of the lower OUs or domains if the IT function is reorganized.May require administrators to cooperate with each other for some administrative tasks if they are in the same location but in different divisions or departments.
38Designing a Hybrid Hierarchy by Organization then Location Allows for Security BoundariesAllows Administration by LocationVulnerable to Reorganizationssales.nwtraders.msftNew EnglandBostonHartford
39Designing the higher OUs or domains by organization and the lower OUs or domains by location works well in a large, highly distributed organization that has physically distributed distinct business units with a need for distinct security policies in each division. The upper organizational/lower location hierarchy supports the business organization, while still accommodating geographic distribution of the IT function.
40When deciding whether to choose a hybrid hierarchy by organization then location, consider that this type of hierarchy has the following characteristics:Allows for strong separation of administrative function between departments or divisions, while still allowing administrative delegation based on a physical location.A reorganization will alter the design of the OU or domain hierarchy, which will in turn require an extensive amount of work for the IT department to reconstruct it.If this method is used for domain creation, it may not make effective use of the physical network, because domains will likely be located in multiple sites.
41Regardless of the hybrid hierarchy used, organizations can add additional OUs to facilitate function-based administration. For example, you can create additional OUs that divide the users, mail servers, domain controllers, and print servers into separate containers, if each is managed by a different group of individuals.
42Design Guidelines Hierarchy Location Organization Function Hybrid HierarchyBy Location then OrganizationBy Organization then Location
43Design strategies for hierarchical design and the The table summarizes various design strategies for hierarchical design and the characteristics of each. The following flow chart represents a decision tree that is useful for determining the appropriate hierarchical strategy for an organization.Design strategies for hierarchical design and the
44Developing a Strategy for Delegation Determining Delegation MethodsDetermining Object OwnershipCreating a Strategy for Object-Based and Task-Based DelegationCreating a Strategy for Delegating AuthorityCreating Strategies for Inheritance of PermissionsDesign Choice GuidelinesDemonstration: Using Visio 2000
45Delegation of administration is the process of decentralizing the responsibility for container ownership and administration from a central administrator to other people or groups within the organization. You can use several methods to delegate authority, and assign to users and groups different categories of ownership. The ability to establish separate access to sites, domains, and OUs is an important security feature in Active Directory.
46Use the following to identify the important factors to consider when planning administrative delegation:Determining methods used for delegating authority.Examining object ownership.Creating strategies for object-based and task-based ownership.Creating strategies for delegating authority at different administrative levels.Creating strategies for planning inheritance of permissions.Documenting the delegation plan.Examining guidelines for designing delegation of authority.
47Determining Delegation Methods Delegating Authority Includes:Changing Container PropertiesCreating, Changing, and Deleting Child ObjectsUpdating Object AttributesCreating New Users or GroupsManaging Small Groups of Users or Groups
48When you are planning to delegate administration, you should decide what permissions you want to assign to various users in your organization. You may apply permissions to an object, a branch of the Active Directory tree, a particular object type, or an attribute. The following are types of permissions you may want users to have:
49Change container properties Change container properties. Designated users will be able to change properties on a particular container, such as the GPOs set on an OU.
50Create, change, and delete child objects Create, change, and delete child objects. Designated users will be able to create, change, and delete child objects of a specific type within a container, such as users, groups, or printers.
51Update object attributes in a certain class Update object attributes in a certain class. Designated users will be able to update specific attributes on child objects of a specific class within a container, for example, the right to set passwords on user objects.
52Create new users or groups Create new users or groups. Designated users will be able to create new users or groups within the container.
53Manage a small group of users or groups within a given area of responsibility. Designated users will be able to manage a small set of users or groups within their area of responsibility, such as a container in the Active Directory structure. For example, a user can be given the ability to manage printer queues and file resources within a particular OU or among several OUs.
54Determining Object Ownership 1. Creator Grants Permission to User to Take OwnershipCreator2. User Takes OwnershipUser Account3. New Owner
55Every object in Active Directory has an owner Every object in Active Directory has an owner. The person who creates the object automatically becomes the owner and, by default, has Full Control over the object. When assigning permission to create objects, remember that the owner of an object controls how permissions are set for an object and to whom permissions are assigned, even if the owner is not listed in the discretionary access control list (DACL). Owners can assign the Take Ownership permission to any user or group account. When creating a plan to delegate administrative authority, remember that a user or group account with this permission can take ownership of the object, and will retain ownership until the permission is removed. Note: Members of the Domain Admins group always have the ability to take ownership of any object in the domain and then change the permissions. This is one reason to limit the number of users in the Domain Admins group. If a member of the Administrators group creates an object or takes ownership of an object, the Administrators group becomes the object's owner. For tracking purposes, the name of the specific Administrators group member who created the object or took ownership is also listed as owner.
56Creating a Strategy for Object-Based and Task-Based Delegation OUAdminsFull ControlOUAdminsReset passwordEntire OUUsers Only
57Administrative delegation can be based on objects, such as sites, domains, and organizational units, or on tasks. An example of a task is "change all passwords for all user objects in this organizational unit." Determining whether the object-based or task- based delegation is best depends on the administrative model used in the organization. In general, avoid assigning permissions at the task or attribute level. Assigning permissions at this level is time-consuming, thereby increasing administrative overhead. It is also difficult to document administrative authority. Consider placing objects in separate OUs based on how they will be managed. This allows for inheritance, easier documentation, and better troubleshooting.
58Creating a Strategy for Delegating Authority Site-Level Delegation May Affect Multiple DomainsDomain-Level Delegation Affects All Objects in the DomainOU-Level Delegation Can Affect Parent OU Only, or Parent and All Child OUs
59The goal of delegating the ability to grant permissions wherever possible is to conserve administrative effort and cost, thus reducing the total cost of ownership (TCO). Assigning permissions to users in an organization involves deciding who can and cannot gain access to an object and its contents, and the type of access that a person may or may not have.
60Creating Strategies for Inheritance of Permissions OUFull ControlOUFull ControlOUFull ControlObjects Inherit Existing PermissionsInheritance Can Be Blocked
61The following methods can be used to assign permissions to users in an organization: Delegating the ability to assign access control permissions for objects to users or groups of users; in other words, delegating the ability to delegate.Controlling which users can gain access to individual objects or object attributes, and the type of access these users have.Assigning common or special permissions on objects.Using inheritance to allow access control permissions to flow to child objects.Note: The object type defines the available permissions and varies from one object type to another.
62When deciding whether to delegate authority at the site, domain, or organizational unit level, remember the following points:Authority delegated at the site level will likely span domains, or conversely may not include targets within the domain.Authority delegated at the domain level will affect all objects in the domain.Authority delegated at the organizational unit level can affect that object and all of its child objects, or just the object itself.
63Careful planning of permissions can eliminate the need to assign permissions to individual objects in Active Directory. Objects that are created inherit the permissions that are assigned to the parent object. The advantage of inheritance is that an administrator can manage permissions of all objects in a container without having to manage all of the child objects separately. Permissions can be applied to an object only; an object and all of its child objects; child objects only; or specific types of child objects, such as computers, users, or groups.
64Inheriting Existing Permissions In Active Directory, the permissions on directory objects are stored as attributes of the objects. When an object is created, its DACL contents are determined, based on the default permissions for the type of object in the schema and the permissions on the parent container.
65Blocking Inheritance of Permissions At times, you may need the specific permissions on an object to override the permissions that might be inherited from a parent. You can prevent a child object from inheriting permissions set on the parent object. Future changes to the parent object's permissions will not change the DACL on the child object. Blocking inheritance makes it difficult to document and troubleshoot permissions on an object. Try to avoid blocking inheritance of permissions. Note: To change the permissions for an entire hierarchy, change the permissions for the top parent object and specify that the change should also affect child objects. The permissions will be added automatically to the DACL of every object in the hierarchy.
66Design Guidelines Assign Permissions at the OU Level When Possible Avoid Assigning Permissions at Property or Task LevelUse a Small Number of Domain AdministratorsAssign Access Permissions to Groups
67The following guidelines should be considered before planning delegation of administrative control in your organization:
68Assign control at the OU level and take advantage of inheritance whenever possible. By assigning control at the highest OU level possible rather than on individual objects, managing permissions will be much easier and more efficient. It is a simpler trail for administrators to audit, and there is less chance for disaster if an administrator makes a mistake while logged on with an administrative account.
69Avoid assigning permissions at the property or task level as much as possible to simplify administration. Consider placing objects in separate OUs based on how they will be managed, before deciding to manage properties with separate DACLs for objects in a single OU.
70Use a small number of domain administrators Use a small number of domain administrators. The Domain Admins group has special abilities within a domain, including the ability to take ownership of any object in the domain and define security policies for the entire domain. In situations where the domain administrator privileges need to be tightly controlled, you could grant administrative rights to users for the various OUs, and limit membership in the Domain Admins group.
71Assign access permissions to groups, rather than to individuals, to grant or deny access to users. Group permissions makes it easier to keep DACLs current on networks that have many users and objects. Also, assigning permissions to groups is very powerful because groups can be nested within one another. Nesting groups reduces the total number of objects that need to be administered, and therefore reduces administrative overhead.