Structure of Active Directory for University of Edinburgh

Transcription

1 Structure of Active Directory for University of Edinburgh Version 1.5 : July 4th 2003 Original Author : George Howat Latest Updates : Scott Currie 1. Changes from last version (From 1.4) 6.1 minor updates (From 1.3) 6.1 and 6.4 updated to reflect recent decisions (From 1.2) minor editorial corrections 6.4 updated to reflect current thinking. (From 1.1) minor correction to delegation rights in 6.1

2 2. Introduction This document outlines a high level view of the Active Directory (AD) structure; an overview of Active Directory itself and the terms used in this document can be found at This design is not static in that we still have to standardise, define and refine policy and attribute usage. Note that, in conjunction with the MIS service, which also makes use of the same AD, we have entered into a service phase with the introduction of ediary and for MIS customers. This makes the transition and change control an important feature of the AD service. AD is at the centre of several initiatives in the University concerning authentication and user account services. The design will therefore need to be flexible in order to accommodate these uses which may be outside the windows environments. Similarly to NT and Netware services, the current AD structure is populated via the Automation Service which receives user account information from Human Resources (HR),Registry, and in the future the MIS Visitor s Registration system, as well as miscellaneous input regarding visitors/conferences etc. As will be seen, the AD structure contains account and group information concerning people, applications and computers. 3. The design objective The design objective is to achieve a networking environment which is an evolution from NT4 and eventually from Netware, a directory based resource for computing infrastructure which will support multiple services, a flexible means of administration of the University computing resources, to securely delegate administration to those Schools who may wish to undertake it. To this end, emphasis is placed on design for the deployment of security groups. Since potentially each attribute of each object in the AD forest can be configured to have different access rights, AD s group construct offers the ability to fine-tune these rights and to assign administration to the most appropriate party. (Note: normally one would not use this ability since it is a high overhead; the design and use of Organisational Units, and group policy when modelling IT management is a more likely target.) It is an important feature from the outset that delegation of appropriate administration is a requirement, and can be achieved through group definition.

3 4. The basic structure The logical structure of the live forest 1 is currently defined to follow the computer and account administration model for the University and not any other potential administrative models. Root ed edinburgh Miscorp CMR The forest has two trees: edinburgh which is deployed for security purposes contains secure entities such as the Certificate Server, the Automation Server (Metropolis) and is focussed on enterprise management. ed contains most of the University windows computing objects and all user accounts for the various Units, Schools etc. The ed domain contains two further domains: miscorp which holds the MIS administration domain, and CMR for the centrally managed resources. [Discussions are ongoing to remove this division, which is largely a historical accident this will simplify the scheme considerably]. 5. AD and the DNS Active Directory domains and Domain Name Service (DNS) domains have the same hierarchical structure and the naming of AD domains follows the DNS conventions, for the above example: edinburgh.ac.uk, ed.ac.uk, miscorp.ed.ac.uk and cmr.ed.ac.uk. Although separate and implemented differently for different purposes, an organization's namespace for DNS and for Active Directory domains have an identical structure. For example, ed.ac.uk is a DNS domain and an Active Directory domain. Active Directory clients and domain controllers use SRV resource records in the DNS to determine the IP addresses of domain controllers. However, it is important to note that the name spaces DNS and AD are actually distinct. For example, the real computer system: desktop PC AMON, has DNS name amon.ucs.ed.ac.uk which is linked to its IP address. This DNS name is not necessarily the name of the computer object in the AD. The fact that it may 1 Note: there is a test forest which mimics this structure and is the place where development and checking of, for example, policies can be tested and refined before going live.

4 be in the ed.ac.uk or edinburgh.ac.uk domain does not impose any constraint on the DNS naming of systems. 6. The ed domain As noted earlier, the ed domain holds the information which may be of most interest to administrators and users. It is important to note that apart from the two domains, miscorp and CMR, the current design does not use AD domains to model the computer and user administration boundaries but instead deploys Organisational Units (OU) within the domain. Generally the creation of domains is regarded as unnecessary for the University structure since it provides little gain over OUs and does imply additional hardware to support them. Discussions are ongoing to merge the miscorp and CMR domains into one for this very reason. Specifically, the features which a domain offers over and above an OU are: Set the minimum length required for a password Set the password complexity rules (concerning what passwords may contain etc.) Set the account lockout rules (rules for intruder detection and account deactivation) It also implies the requirement for a domain controller (DC) actually at least two for resilience to manage the domain. The ed domain structure is: ed UoE UoEM UoER UoES Operations Service Users Where UoE UoEM UoER UoES Operations ServiceUsers is the OU which contains all non student (staff, visitors, etc) user accounts is the OU which contains all centrally managed computers, services, etc is the OU which contains devolved resources computers, services, etc is the OU which contains all student accounts is the OU which contains operational administration groups is the OU which contains accounts and groups for central services The OUs UoE, UoEM, UoES and UoER are for operational purposes: management is distributed and delegated using group policy. The OUs Operations and Service Users are for infrastructure management, and are administered centrally. The various OUs and objects are created and named after data received from HR and Registry; this is described in a separate document regarding attributes.

5 Illustration from test forest }Used for test purposes only Non Student Accounts Centrally Managed Resource Accounts Devolved Resources Accounts Student Accounts The above figure shows what the top level of the directory looks like as implemented in the test forest (note that the Operations and Service Users OUs are not implemented here; note also that names like Builtin, Computers etc are standard OUs which are not discussed here for clarity). Each OU is in a container which looks like a Windows Directory in the screenshots shown here. 6.1 The UoE Organisational Unit The top level of the UoE OU is shown above. This reflects the Colleges and Support Groups level 2 in the official Organisational Hierarchy (see the Planning Unit s web pages for details). All non-student people accounts are contained herein, i.e staff, associates and visitors. The OU container names below UoE are derived from the Hierarchy College and School data fields e.g. History and Classics, Mathematics, Careers Service etc, with the exception of Infrastructure and Facilities, which contains certain special accounts e.g. for training and conferences. The advantage in having this here is that the structure is the same for UoER and UoEM below. There is also an OU for each College and Support Group. The diagram below shows the layout for Science and Engineering; Appendix 1 shows the full UoE structure. Note however that there are a few funnies in that HR have not yet fully implemented the new structure Each of the Level 5 OU containers holds the user accounts for staff which have been assigned to the Level 5 Unit. It is important to note that HR associate staff with one and only one Level 5 Unit, and the Automation Service automatically places the staff member s account into that OU container. There are some staff who only exist at College or School levels (e.g. administrations staff) and even fewer staff who exist at a lower level (Level 6). The Automation Service will place staff into the appropriate level, the vast majority being at Level 5 it was expected that the Level 6 staff were a historical anomaly who will not exist in the real system, but it would appear that Human Resources will take some time to remove these people from the database.

6 Delegation of rights to School Computing Officers, e.g. to add visitors, will be up to level 4 (i.e. they can add visitors at Levels 5 and 6). Computing Officers will be able to move staff from one OU to another from Level 6 downwards. The Automation Server will not move staff unless their School/Level 5 unit code has changed in the download, therefore to move staff to OUs above Level 6 will require a code change in the HR database, which should be done via School or College administrators. Example of UoE OU Structure See Appendix 1 for the full structure. Level 2 - College Level 4 - School Level 5 - L5 Unit In addition, each of the School OU containers also holds a security group object, e.g.

7 Chemistry OU Staff UUN1 Staff UUN2 Staff UUN Chemistry Users User User User Security Group and each user account is set to be a member of that security group (in this example Chemistry Users). This group is designed as a means of applying policy to the Unit users as a whole. Note that certain operations on the management of the Level 5 user accounts will be delegated to administration identified for that School. School administrators will be permitted to perform actions such as reset password, view account details and so on. Accounts are generally created centrally via the Automation Service, which also manages deletion and rename etc. It is expected that portals will be available for other account manipulation purposes. This area of requirements is to be developed. 6.2 UoER (R=resource) The structure of the UoER OU is identical to the UoE OU, i.e. it reflects the College, Support Group and School/Level 5 structure. The School and Level 5 Resource OUs within UoER are delegated completely to the administration identified for that School. At this time, this delegation is controlled by a security group object held in the Operations OU. School administrators will be free to perform any actions within their OU including creation of other OUs within it. (It is important to recognise that the Microsoft recommendation is not to exceed a depth of 6 starting at ed, as this could incur performance penalties.) Typically the OU will contain computers, group objects and so on. Group objects may be used by administrators to fine tune access rights for systems which are in their part of the AD forest. Thus one could have Chemistry Resource OU Server 1 Server 2 Pr2 WS1 WS Group1 Group 2... Server Server Printer Workstation Workstation

8 The various systems and services which need administration by Chemistry are included in this container. The Group objects may be configured to refine policy of access, change control etc. on the various objects for this administration. 6.3 UoEM (M=managed resource) The managed resource OU contains all the resources which are controlled by the EUCS Desktop team. Its structure is the same as UoER (with some extensions), as schools or Level 5 units can opt in to the centrally managed desktop. The reason behind the existence of this OU is to clearly separate centrally managed resources from devolved management. The extensions noted above are to cover the open access labs and other items which are University wide. 6.4 UoES (S=student) All student accounts, under- and post-graduate are held here. Originally, the OU container names below the UoES unit name collecting the student account data, were going to be derived from the Programme of Study (PoS) description as supplied by Registry. However, because of a proposed review of course, students will also be grouped by College and School, with a further subdividion to undergraduates, taught postgraduates and research-postgraduates. This set of OU s is also created by the Automation Service. In this case policy for students is to be developed. We seek guidance on the requirements and how these may be mapped onto the details held for students, via security groups, etc. 6.5 Operations This OU collects special groups to allow rights to other containers and is focussed on central administration. In the current implementation, one set of such groups is the School Admin groups: that is, a security group for each of the Schools is created (called a Resource Organisation), and the rights to the UoE and UoER containers for that School may be controlled through it. Members are added and removed from this Admin group as required. Input is requested on this area, for example we could have groups per School which are Operations, Supervisor, Administrator etc. which could have different access rights. As an example, a group could be created where the members are permitted to change user passwords and to view account, security and group details, but not configure them. 6.6 Service Users OU This OU is to administer the enterprise, and contains a set of users and policies concerning central services, etc.

9 Appendix 1 - Full UoE Structure

10

11

12 Current AD infrastructure (excepting CMR) King s Buildings Appleton Tower Logical Domains Domain Controllers Exchange Servers

13