|
||||||||||||||
| UCB Windows 2000 Resource Center |
||||||||||||||||
|
UCB Campus Active Directory BasicsActive Directory Design Active Directory Design The Windows 2000 Active Directory hierarchy is comprised of Forests, Trees, Domains, and Organizational Units. Information on how these items relate to each other is available from Microsoft in the Active Directory Logical Structure (www.microsoft.com/windows2000/techinfo/reskit/en-us/distrib/dsbb_act_YAEH.asp) section of the Windows 2000 Server Resource Kit. At UCB ITS has chosen a single forest, single tree design. This means that the central UCB Active Directory uses a single schema and has a single root domain. A basic diagram of the UCB AD is available here: www.colorado.edu/its/windows2000/itsresources/ADdesign.pdf Within the root domain departments are delegated control over their own Organizational Unit. The details of this delegation are covered in the "Distributed Support Delegation" section of this article. Some larger departments with special needs and sufficient resources have child domains off of the root domain. As discussed in the "Account Management / Directory Information" section of this article, ITS handles the creation and deletion of user objects for UCB faculty, staff, and students. These user objects are all located in a single Organizational Unit in the root domain. This was done largely because of the difficulty of sub-dividing people in an organization where multiple affiliations are common. Every Windows 2000 domain within an Active Directory requires at least one domain controller to manage a number of tasks. ITS maintains three domain controllers serving the root domain of the UCB Active Directory as well as a fourth domain controller for rapid disaster recovery. They are kept in three secure locations on campus with other networking and IT infrastructure components. A number of precautions are taken with the domain controllers including hardware redundancy, backup power and data backups. Each department with a child domain must maintain its own domain controllers. ITS asks that each department with a child domain operate at least two domain controllers, and assists departments with the setup of their domain controllers. Windows 2000 Active Directory is tightly linked to DNS for a number of functions including the location of domain controllers by clients. ITS examined the various possibilities in interoperability between Windows 2000 Active Directory and the existing campus DNS infrastructure. The chosen DNS design uses ad.colorado.edu as the DNS space for the root domain of the UCB Active Directory tree (a root of colorado.edu is not possible due to conflicts with other infrastructure services). A diagram of the UCB AD/DNS design is located here www.colorado.edu/its/windows2000/itsresources/DNSconfig.pdf Having the root domain located at ad.colorado.edu does not mean that computers within the domain must have names like computer1.ad.colorado.edu. The only computers that must be nameserved in ad.colorado.edu are the domain controllers. Computers may be nameserved in the colorado.edu namespace and still be a member of the UCB Active Directory. Because Windows 2000 relies on DNS for locating computers for certain functions, matching the computer name to its DNS name is important to fully leverage the benefits of Active Directory. Since Dynamic DNS updates are not currently supported at UCB, this means DHCP clients in the UCB Active Directory will not be able to leverage all of the benefits of an Active Directory. The vast majority of functions are not affected by DNS name mismatches. The primary authentication mechanism for Windows 2000 in an Active Directory is Kerberos 5, more information on Kerberos is available from Microsoft (www.microsoft.com/windows2000/techinfo/reskit/en-us/distrib/dscd_aun_yfet.asp) and from MIT (the developers of Kerberos) (web.mit.edu/kerberos/www/). As with DNS, UCB already has a Kerberos infrastructure that most people know as IdentiKey. ITS created an Active Directory implementation plan that allows for interoperability with the existing Kerberos infrastructure, and a diagram of that process is available here: (www.colorado.edu/its/windows2000/itsresources/kerbdiag.pdf) This implementation allows for users to logon to a properly configured Windows 2000/XP Active Directory client using their IdentiKey username and password (credentials). This design required the automatic creation of user objects in the UCB AD for all users on the UCB campus, this is discussed in the "Account Management / Directory Information" section of this article. Since the existing Kerberos passwords are stored in one-way encryption, long, random passwords were automatically generated for all users in the AD. This creates a situation where users can logon to properly configured Windows 2000/XP clients in the UCB AD using their IdentiKey credentials, but do not know the actual password for their AD user object. For certain environments including Windows 9x, NT 4 and Mac OS, and certain applications like Exchange knowing one's password for their AD user object is required. For these situations, ITS has a mechanism for departments to allow their users to set their AD user object passwords. Account Management / Directory Information As mentioned in the previous section, ITS automatically populates the UCB AD with user objects for all faculty, staff, and students at the UCB campus. To facilitate the interoperability with the existing IdentiKey infrastructure, this account management process is based upon the creation and deletion of IdentiKey accounts. In addition to creating the accounts, ITS populates a number of pieces of information into the user objects to make it easier to identify the correct users. This information comes from the UCB enterprise directory and is limited to publicly viewable information. The privacy rules governing the enterprise directory are reflected in the UCB AD. A diagram of this process is available here: www.colorado.edu/its/windows2000/itsresources/acctdiag.pdf Distributed Support Delegation An Active Directory is designed to facilitate centralized administration for corporate environments, so ITS spends a great deal of time working on the best ways to leverage this technology in a distributed IT environment like UCB. The basis for the UCB model is the delegation of Organizational Units (OUs) to departmental IT staff. Within their own OU departments can create and manage the computers and groups of users for their department. Departmental IT staff are given second "administrative" user accounts to use for AD administrative tasks. ITS creates these accounts and it is the responsibility of the department to notify ITS when these accounts must be created or deleted. These accounts are joined to an OU administrators group for the department and all delegated access is given to that group. Departments have the ability to perform most functions within their OU
including creating computer objects, groups, Group Policy Objects, printers,
etc. The Ins and Outs of a delegated OU are described here: www.colorado.edu/its/windows2000/adminguide/inoutOU.html.
The most notable exception is the inability to create user objects since
they are centrally created for all campus users. ITS will create special
case user objects for departments upon request (eg. a generic lab or test
account). The Ins and Outs of user management are outlined here: www.colorado.edu/its/windows2000/adminguide/inoutUsers.html
Because all of the user objects are located in a single OU, departments do not have direct control over the user objects for the people in their department. Instead, they are granted the ability to write to Windows specific attributes (Profile Path, Home Directory, etc.) for all user objects. In the event that two departments wish to change the same attribute on a single user, these departments must reach some agreement on their own for the management of overlapping users. Get Help
|
|||||||||||||||
| Support | | | Training | | | Facilities | | | About ITS | | | ITS Home | |||
|
|||||||||||