Thoughts Concerning The Planning Of A Campus-Wide Directory Service (OBSOLETE)

The remarks made in this document were developed after extensive research into Active Directory domain design as well as in-depth consultation with Tom Serviss and Jim Johnston of MFCF and David Gawley of CSCF. I'd would like to thank them for their extensive input which has substantially aided in the development of this document.

In this document the word "trust" will be used numerous times in two specific contexts.

1. Active Directory domain trust: This is the mechanism where one domain will accept (or trust) the authentication of a user provided by another domain. Essentially, DOMAIN1 says a user is legitimately authenticated and systems in DOMAIN2 accept that authentication.This however does not immediately imply that this user is authorized to use the resources in DOMAIN2. That access must be subsequently granted by the administrators of DOMAIN2.
   Within a single Active Directory forest, all domains trust each other by default. This is called two-way transitive trust.
2. Professional trust: There are several large autonomous IT groups on campus. There is CSCF, MFCF, IST and Engineering Computing to name a few. They exist for differing reasons and all have their own purposes and goals. With the exception of IST, it is the responsibility of these autonomous IT groups to be able to quickly respond to the specific needs of their customers without being overly concerned about the goals of other IT groups on campus. The efforts of one group are not going to meet the needs and goals of others.
   This is not to say there is a visceral or personal grudge between groups or members therein. Just the need to be accountable to their own upper management.

As Things Currently Stand

Presently, UW is a large multi-forest institution. According to Microsoft's documents institutions having multiple forests are a consequence of little or no collaboration between autonomous IT departments. Here at UW, groups such as CSCF, MFCF, IST and Eng. Comp. are definitely autonomous and collaboration is not high. Microsoft documentation also cites lack of (professional) trust between such groups as a likely reason for the development of multiple forests in an institution like a university. The documents do not cite whether these conditions are good, bad or necessary for such institutions. However, it is clear that Active Directory is conceived to be successful even under such conditions.

The Single Domain Design

Many authors, technical manuals and web pages espouse the benefits of a single domain (the kerberos term is "realm") model for an institution's directory service. This is often the first option mentioned in any guide for the development of a forest. Such an arrangement is less costly when considering hardware, licensing and manpower. However, the same documents also advise that such a mode is best utilized in an institution that has a "strong central IT structure".

As stated above, this is not true at UW where many organizations have their own extensive IT groups to provide speedy in house support for critical IT services such as authentication. Indeed in the book Windows Server 2008 Unleashed the author states explicitly that, "if different branches of an organization generally manage their own IT structure and there are no future plans to consolidate them into a centralized model, multiple interconnected domains might be ideal".

Issues Concerning User Authentication At UW

As of today both the Math Faculty and SCS each maintain two security zones (in the old xhier structure these were called regions) for their students, faculty and staff. There has always been a desire for a security separation between work done in the teaching or undergrad environment and that of research and administration - which includes graduate students. This desire continues to this day. Hence many UW users in Math and SCS require separate accounts using the same username with potentially different passwords for accessing completely different environments. In SCS this is accomplished through either the CS-TEACHING or CS-GENERAL domains within the CSCF Active Directory forest. This is a functional requirement for authentication in both groups.

It is also recognized that the password used to access one's day-to-day work and correspondence should not be the one that admits a user to their own personal and private information. Information retained by Human Resources or the Registrar's office or both are currently accessed using IST's ADS domain. The day-to-day password is the most vulnerable to hackers just because it is used so often (everyday or even every few hours) and in public places. The ADS password should be less vulnerable because it is only used for the occasional access of one's own personal information and is usable only from tightly controlled systems.

That last part is currently a fallacy since UW Wireless service access is authenticated through ADS. This is reflective of a single password for everything model which is sponsored by IST. However, HR and Registrar (personal and private) information may be protected (in whole or in part) by FIPPA. Not providing a separate security zone for user access to this information might be a violation of reasonable protections. Definitely, in any future structure, authentication of wireless access should be switched to a different account than the one used for HR and Registrar information. This would seem to be another functional requirement.

It would appear then that any UW user must have at least two accounts within UW as a consequence of FIPPA. It would also be necessary for access to HR and Registrar records to be available to a UW user long after he/she has left the university and no longer has access to other campus systems. If then everyone must have two accounts, as opposed to just a few special users, it makes better management sense to create a second domain (or kerberos realm) for the accounts which are used to access personal data stored at UW. The alternative of retaining duplicate user objects within a single domain (named username-priv for example) for over twenty thousand users would create a significant and unnecessary operational load for a domain critical to campus operation. It would also reduce service scalability. And a separate domain could be more secure as it can be more tightly controlled access-wise and therefore less susceptible to denial of service attacks and break-ins.

For us in CSCF and MFCF, this creates the need for at least two and perhaps three passwords per user. That is three domains dedicated to user objects.

Authorization (Resource and Service Access)

The next question to tackle is how services, provided by computers (aka. machines), are supported by a campus directory service. As stated above, UW has several autonomous IT groups charged with providing speedy in house support their critical IT services. Support groups which will continue to be autonomous even after establishing a campus-wide forest structure. Some of the services provided by these groups are as follows.

• CPU Access: Console, RDP, SSH, X Windows (for Windows, Macintosh, Linux and Solaris desktops)
• File and Disk Space Access: SMB, NFS, SFTP
• EMail: IMAP, POP
• Web: HTTP, HTTPS
• Printing: SMB, LPR
• Wireless Network: HTTPS

Not all IT groups provide the same list of services. Some groups (like CSCF and MFCF) are mandated to provide separate but identical services to differing classes of users (undergrad teaching environment vs. research and administration). Access to most of these services must be managed by the local IT group. In an Microsoft Active Directory type directory service, controlling access to services is accomplished through security groups, GPOs (group policy objects) and service accounts. Service accounts include the following.

• Course Accounts
• Special Event Accounts
• Visitor Accounts (maybe)
• UNIX Host Accounts (Linux and Solaris computers)
  • If these UNIX systems rely upon kerberized NFS mounted disk space, then each will require two account objects in the directory. One for the host instance and another for the root instance.
    See ADAddKrb5NFS for more details
• Accounts Management Accounts
• Limited Logon Accounts (for the kiosk)
• NIL Password Accounts (for the kiosk)
• User Directory Overlay Objects

CSCF in particular, maintains over 200 course related accounts. These accounts are often created upon request by the course instructor, are not directly linked to any specific user and are only used on systems managed by CSCF. Other accounts are created by CSCF staff to support services which CSCF elects to implement. Due to the need for rapid deployment only within an IT group's service area, these accounts could not and should not be maintained by those managing the central UW user account base. Nor should these accounts be retained in any domain supporting centralized UW user accounts for security reasons.

Since there is as yet no campus standard for UW user account UNIX attributes (RFC 2307: uidNumber, gidNumber, loginShell, homeDirectory, etc.), CSCF will require the maintenance of User Directory Overlay Objects. These are disabled user objects which retain established UNIX attribute values for each user that is designated to utilize CSCF managed UNIX based environments. Math and SCS maintain a faculty-wide UID/GID database for UNIX users and groups. So while authentication would be managed by centralized campus user domains, CSCF systems would have their LDAP clients configured to read the overlay objects for each user in order to acquire the requisite attribute information. Since two user objects cannot have the same name within a single domain, these user overlay objects cannot be retained in the same domains as true user objects.

And even if these objects could be placed in the same domain with true user objects (named username-csunix for example), this would create at least eleven thousand additional user objects and corresponding group objects to the central user domains. As with duplicate user accounts for HR and Registrar access, these additional twenty-two thousand objects would create a significant and unnecessary load on a domain critical to all parts of the campus. And again, it would also reduce the scalability of centralized campus authentication.

CSCF also has specialized conventions for group naming. This was established to cope with the fact the Active Directory does not permit groups and users to have the same name. However, it is common place for there to be user groups named after specific users (all of our users) in many UNIX environments here at UW. In order to resolve this discrepancy, a group object's displayName attribute is set to the desired group name for the UNIX environment. Our UNIX based systems are configured to read the displayName attribute of group objects. This is not a commonplace configuration.

All of these functional requirements point to the need for campus IT groups (CSCF in particular) to maintain their own domains within a campus wide forest. Authentication of human users could take place through centralized user domains. Services supported by local IT groups and the management of the corresponding objects would be maintained in an IT group's domain or domains. It is currently common practice for computers (services) to be maintained in the same domain as their user base. However, directory services like Microsoft Active Directory maintain two-way transitive trusts throughout their forest structure, making this practice unnecessary. Users whose accounts reside in DOMAIN1 may utilize computer services maintained in DOMAIN2 as long as the administrators of DOMAIN2 permit it.

This dovetails back to the point made that, "if different branches of an organization generally manage their own IT structure and there are no future plans to consolidate them into a centralized model, multiple interconnected domains might be ideal". At least every autonomous IT department on campus should have their own domain or domains within the campus forest. There would be at least one domain each for CSCF, MFCF, IST, Engineering Computing, etc. Or more accurately, one tree each. Each of these IT groups could decide for themselves whether sub-domains are beneficial to their needs.

It has been argued that all computer systems can be managed in one campus-wide domain utilizing department based OUs for delegation of authority. But remembering that all of UW's IT groups function autonomously, the structure which provides greatest flexibility, efficient operation and fuller autonomy is one using separate domains as opposed to designated OUs. Within their own domains different IT groups do not have to organize approval of the other IT groups for changes that effect the deployment of their own services. Differing IT groups can establish their own naming conventions and standards for groups, GPOs and service accounts. Even more importantly, a domain based plan will separate the activities of differing IT groups so there is no potential unintended interference while retaining all potential for interdepartmental cooperation.

Another point that the author of Windows Server 2008 Unleashed makes is that of "unique DNS namespace considerations". Active Directory domains are equivalent to DNS domains. Essentially, systems in an institution's forest should reside in directory domains consistent with their fully qualified domain name (FQDN). For example, in the case of CSCF, hosts with a DNS name hostname.cs.uwaterloo.ca should be in their own AD domain; a domain with DNS name cs.uwaterloo.ca. Hosts with a DNS name hostname.student.cs.uwaterloo.ca should be in their own AD subdomain; a domain with DNS name student.cs.uwaterloo.ca. This is largely due to AD's dependence on DNS (both Host and SRV records) to properly identify which systems are genuine domain members. This may also affect kerberos for authentication as it is highly dependent on hostnames and realm names.

Directory Service Forest Development Design

Forest Structure and Domain Naming Conventions

We've slightly altered the domain NetBIOS naming convention from our original proposed forest. The forest root domain now has a NetBIOS name of DS to represent this forest's designation as a "Directory Service" - the corresponding DNS name for this domain is ds.uwaterloo.ca. Further, the domain NetBIOS names for UW-TEACHING and UW-GENERAL have been truncated to TEACHING and GENERAL respectively to make them more generic - in DNS they are named teaching.ds.uwaterloo.ca and general.ds.uwaterloo.ca respectively. And, at the present time, the security domain UW-CONFIDENTIAL is being omitted. We currently do not possess the requisite infrastructure or a complete business plan for it. However, the domain can be developed easily within this forest design as a type USER domain when it is required.

Although many directory designs feature the forest root at the top domain of an institutional forest, this does not need to be the case. Especially if the corresponding DNS domain is claimed for a different purpose. So, instead of a single tree forest we have a multi-tree forest design in mind as depicted in the diagram below.

The Directory Service forest is broken up into three domain types:

• USER Domains: As the name implies, most user objects would be maintained in these domains and user authentication would also be performed by these domains. It still remains to be determined exactly which users would populate the TEACHING domain and the GENERAL domain as there would likely be considerable overlap between the two. It may be preferable to allow individual IT departments to pick and choose which of these domains they might use (either or both), in which case it might be better to have all users present in TEACHING and GENERAL as well.
  Populating of user domains would eventually be the responsibility of a central campus authority who would likely obtain its user information for account creation and maintenance from both the Registrar's Office and Human Resources.
• SERVICE Domains: These domains provide the services for the users. They would be the responsibility of local IT groups such as MFCF, CSCF, Eng. Comp., etc. Most services supported by the SERVICE domains would authenticate off of either the TEACHING or GENERAL domains or both. However, authorization would be controlled through mechanisms managed in the SERVICE domains. Services like UW Wireless would also switch to authenticating off of either TEACHING or GENERAL or both.
  Though IT groups would typically be limited to one tree root domain, they could add sub-domains to their tree as their operations demand. For example, both MFCF and CSCF separate their services between teaching and research/admin support. Service hostnames of these systems reflect this separation with teaching services residing in a sub-domain of the main department domain.
• FOREST ROOT Domain: This is an empty domain as recommended by Microsoft and is the first domain created in any forest.

Schema Extensions

Unlike the Windows 2003 AD, RFC 2307 schema classes and attributes (UNIX classes and attributes) are already included in the Windows 2008 AD schema. Therefore no special schema extensions need to be implemented to prepare the Directory Service for UNIX system authentication.

However, in this new Directory Service design we now wish to include management of Macintosh clients and users and avoid depending on the "Golden Triangle" adaptation (see ADMacInteg) which we have used for management of Macintosh terminals which authenticate from our Windows 2003 Active Directory service.

Alas, unlike the RFC 2307 extensions for Windows 2003, there is no (as yet) pre-packaged schema extension (an LDIF or .ldf) file which Apple supplies for this purpose. Though, Apple has published a document outlining a method for generating such schema extensions titled Modifying the Active Directory Schema to Support Mac Systems - dated October 2009. This procedure is dependent upon having an operational Open Directory service for Macintoshes. A service which we already have due to our use of the "Golden Triangle" solution with the Windows 2003 AD - fortunately. Following the instructions in this document one can generate the requisite schema extensions in an LDIF format for implementation on the forest's schema master.

To save time, we've posted the contents of our schema extension file at the following link: ADAppleExt

In principal, one is using a Windows based tool called ADSchemaAnalyzer to compare the schema of our new Active Directory based Directory Service with the "Golden Triangle's" Open Directory schema. The differences are then exported to an LDIF file containing all classes and attributes which pertain to Macintosh (apple) management. After one has exported the LDIF file, further steps massage its contents to make it compatible for extending an Active Directory schema. The Apple document is quite thorough but there are a few additional details which need to be stated to make the procedure clear.

• Development of the schema extension file is dependent on a Windows tool called ADSchemaAnalyzer. Unmentioned in the Apple document is the fact that this tool is part of a system "role" called Active Directory Lightweight Services which is not installed by default on a Windows Server 2008 R2 system. One installs this role using the Add Role option in the Server Manager utility in Administrative Tools.
  Once the role is installed, ADSchemaAnalyzer.exe is found in the C:\Windows\ADAM directory.
• Concerning the section on setting certain objectClassCategory values to 3, the document assumes that all exported objectClassCategory values were set to 1. This has not been true for our trials with all the exported objectClassCategory values were set to 0 - an invalid value apparently. So, before updating the objectClassCategory values for the apple-user, apple-group, and apple-computer classes to 3, correct all objectClassCategory values to 1 first.
• Finally when attempting to implement the schema modifications on the forest schema master, we found that the /c option of the ldifde command does not work. And all references to DC=X in the schema extension file must be changed to the relevant LDAP forest root domain string. In our case, DC=X had to be changed to DC=ds,DC=uwaterloo,DC=ca.
  The final implementation command was as follows, where apple-mods.ldf is the developed schema extension file.
  ldifde /j . /k /i /f apple-mods.ldf /v

Organizational Unit Plan

We are currently implementing the following OU structure in both the TEACHING and GENERAL domains. It is an update of the existing OU layout that evolved with the domains of our existing Windows 2003 AD. For the example of the GENERAL domain, we create an OU named General directly below the domain root (this OU would be named Teaching in the TEACHING domain). The purpose of this is to separate (as best as possible) all objects created through SCS (or whoever is appointed to manage this domain) operations from objects automatically created and maintained by the Active Directory. Please see the diagram below.

Underneath the General OU there would be at least the following list of sub-OUs.

• Computers for all client systems of this domain. As GENERAL is a User domain not a Service domain, it is not likely there will be many client computers in this OU. Domain controllers have their own special OU created by the Active Directory and we intend to leave them there.
• Groups will certainly maintain all user group objects (ctucker_group for example) utilized by UNIX-type platforms. Coarse groups, may be maintained here as well though it can be argued that course groups would be better managed in a Service domain. That will likely depend upon exactly how a course group will be defined from now on.
• Users will maintain all common user accounts for this domain.
  The sub-OU ~New will carry newly created accounts to allow a scheduled task to efficiently scan their attributes for missing values. Once an account is complete, it is moved up to the Users OU.
  The sub-OU ~Expired will maintain user account objects which are expired. A scheduled task can scan the expiry attribute of an account object and move expired objects to this OU as required - and visa-versa.
  The sub-OU ~Old exists for account objects which are expired and have not seen any activity in over two years (time period is arbitrary). This OU allows us to identify directory account objects which can be safely deleted.

This structure has the benefit of keeping all User objects and Group objects in specific locations within a domain. Thus we can narrow the search rules for user and group lookup on UNIX based systems that authenticate in these domains. This should help improve efficiency of user logins. At the present time in our Windows 2003 AD, we must allow our UNIX clients to scan the whole domain OU structure as users and groups can be found in two different places.

This will also make it easier to manage attribute permissions on user and group objects. By default anonymous read of user and group objects is not permitted within Microsoft Active Directory. Unfortunately it is required by our UNIX based systems for user login purposes. The above design reduces the number of OUs to which anonymous read need be applied, Users and Groups. Default Active Directory security can be maintained elsewhere. Similarly, the SELF permission must be added to user account objects to permit a user to edit account attributes such as (UNIX) loginShell with their own credentials. This is not possible by default and this additional permission can be simply applied to the Users sub-OU (and inherited by its sub-OUs).

This new format will also quell some of the complaints from users and support staff concerning (newly created) account objects residing in an OU called Unassigned (as in the current Windows 2003 AD domains) and what exactly such a designation is supposed to mean.

Original Proposed Designs (NOW SUPPLANTED BY Directory Service Forest Development Design ABOVE)

The information in this section has been supplanted by the forest and OU design documentation written above. However, we continue to maintain the old proposed structure documentation in order to provide a historical context for how this project has evolved.

In the diagrams below, the displayed domain names are only intended as an example and to provide reference. UW-CONFIDENTIAL might alternatively be called UW-PERSONAL or some other more descriptive name. Similarly UW-TEACHING or UW-GENERAL might end up with differing names reflecting somewhat modified purpose than outlined in this document.

USER domains would be maintained by a central campus authority which would likely obtain its identities from both the Registrar's Offices as well as Human Resources. Everyone would have an account in UW-CONFIDENTIAL. It still remains to be determined exactly which users would populate UW-TEACHING and UW-GENERAL as there would likely be considerable overlap between the two domains. It may be preferable to allow individual IT departments to pick and choose which of these domains they might use (either or both), in which case it might be preferable to have all users present in UW-TEACHING and UW-GENERAL as well.

SERVICE domains would be the responsibility of local IT groups such as MFCF, CSCF, Eng. Comp., etc. Though IT groups would typically be limited to one tree root domain, they could add sub-domains to their tree as their operations demand. For example, both MFCF and CSCF separate their services between teaching and research/admin support. Service hostnames of these systems reflect this separation with teaching services residing in a sub-domain of the main department domain. Most services supported by the SERVICE domains would authenticate off of either the UW-TEACHING or UW-GENERAL domains or both. Services like UW Wireless would also switch to authenticating off of either UW-TEACHING or UW-GENERAL or both as opposed to UW-CONFIDENTIAL.

The FOREST ROOT domain is an empty domain as recommended by Microsoft and is the first domain created in any forest. Although many AD designs feature it as the top domain of a particular institution's forest, this does not need to be the case. Especially if the corresponding DNS domain is claimed for a different purpose. So, instead of a single tree forest we propose a multi-tree forest.

Authentication off of UW-CONFIDENTIAL would be limited to a select list of services and would not accept authentication requests from any other systems.

As an alternative design, it would also be valid to have the USER domains as sub-domains of the FOREST ROOT domain as opposed to having them as separate tree roots. This structure might be chosen to limit the number of additional upper level domains registered on campus.

Unresolved Issues

• Domain Controllers in SERVICE domains
  • Who owns (and pays for) them?
  • Do Administrators of the USER domains and the FOREST ROOT have a say in administration of these DCs?
  • Common security standards?
• Visitor Accounts
  • Should accounts provided to users who will be present for only brief periods be the purview of a central campus authority or local IT groups?
  • Should visitor accounts be kept in one of the USER domains or in an IT group's SERVICE domain?
• Certificate Authority
  • CSCF relies heavily on its own forest based certificate authority for accounts management and is looking to expanding the application of user certificates to authentication for service access. For example, local printer access for wireless users.
• Standards for RFC 2307 (UNIX) User and Group Attributes
• Inclusion of Research Groups
• Level of security applied to UW-TEACHING and UW-GENERAL accounts
  • To establish UNIX client authentication within CSCF's AD, client systems must be permitted anonymous read rights of common user account objects. This entails permitting anonymous LDAP connections forest wide as well as granting ANONYMOUS LOGON read rights to user objects.