UW Windows Authentication Group Multiple forest scenario task force - Testing report and recommendations

Background Refresher “WINAUTH” group established to consider alternatives to the existing UW Windows Forest, initial meeting 6/2005 Primary drivers: Security – known issue where compromise of any single domain within the forest could lead to compromise of the entire forest. This lead to a recommendation that departments leave the forest. “Nebula” did so this past summer, others done or in process. But…some expressed concern that the functionality provided by the forest was vital and that we need to facilitate sharing of resources not establish silos. Some in the UW forest were concerned about the “LABS” domain moving outside the forest, and losing some functionality in the process. (The “LABS” domain is used by some to authenticate any arbitrary UW user into a Windows based service without having to create separate domain based accounts.)

Active Directory Model Discussion If we want to facilitate sharing of resources, simply moving each department into their own forest is not the answer, instead it creates silos. We discussed three potential models that could be utilized instead: 1. Existing UW Forest – A single forest with multiple domains 2. Single Domain with Multiple Organizational Units 3. Multiple Forests with one-way trusts

Existing Model Single Forest Multiple Domains Allows easy sharing of resources But…existing security concern is unresolved Use of LABS domain was supported for EPLT only. Note: Central provisioning of accounts is provided by a custom developed application (“kiwi”) that currently has little to no staffing behind it. To date the code has run well however and it could be extended if given adequate resources.

Single Forest/Single Domain Multiple OU Model Widely used at other universities Facilitates sharing of resources Solves security issue related to domain administrator obtaining forest administrator credentials But…potentially difficult to do at UW given our highly decentralized environment. How OU’s are managed, in what OU objects are placed, and how management takes place could all be difficult questions that would have to be agreed upon

Multiple Forests with One-Way Trust Relationships Model All accounts are provisioned in a central accounts forest Departmental forests establish a one-way trust to that forest so they can utilized those centrally provisioned accounts if desired

Multiple forest testing To verify that a multi-forest scenario could potentially work for us, a task force was asked to do testing and report back Group consisted of: Brian Arkills, C&C Forest Administrator Scott Barker, Information School David Cox, EPLT Eugene Sherman, C&C Client Services Additional input received from: Andrew Benton, C&C Client Services Mark McNair, C&C Client Services

Testing Methodology Setup one “central account” forest Setup three “departmental” forests and established one-way trusts to the central forest Setup client PCs that were members of the various departmental forests All rolled out just as though they would be “for real” including creation of new DNS domains through the NOC All servers setup with Windows 2003 SP1, clients were XP SP2 Created a list of items that would be tested. This list was posted on a SharePoint site and various members took responsibility for testing each item and documenting their results.

Results Short answer – all scenarios worked but… Not always the same way as presently. Example: From a departmental forest, to assign rights to a user that has an account in the central forest (named uwlabs) we had to use the convention: userid@uwlabs.washington.edu rather than uwlabs\userid And you couldn’t “browse” to “pick” like you can in the existing forest.

Alternative proposal, a hybrid A single domain multiple OU model is the “standard” solution most commonly deployed by large universities While it takes coordination that doesn’t mean it isn’t worth doing FOR THOSE THAT WANT TO DO IT For those that don’t, we can still support the multiple forest with a one-way trust scenario. Departments that select this option can still leverage centrally provisioned accounts for some purposes, yet maintain complete freedom to do what they want at the same time

The delegation problem While we can make everything “work” from a technical perspective, to do so often raises management and delegation issues What OU’s do we create? Do all user objects go in a single OU, do we divide them by department? What rights are we willing to delegate? How are conflicts resolved (single user in multiple departments for example)? This is an implementation problem that will require careful planning, coordination and potentially supplemental funding

Recommendations We should adopt the hybrid model as our “vision” for the future We should share this vision with others (such as computing directors, existing forest members) and see if they agree and there is buy-in from the community Assuming the model is accepted, Nebula should become the “anchor” tenant of this new central forest and other forest member encouraged to participate We need to insure that automatic account provisioning and synchronization of important metadata to this central directory is done in a way that is reliable and can be fully supported This may require modification or support of the existing “kiwi” code, or evaluation of other synchronizations tools such as MIIS (Microsoft Identify Information Server) that are used by peer institutions Ideally this metadata should include both personal information (name, email address etc.) as well as group information (student, faculty, staff, course membership etc.)

Recommendations continued We as an institution must understand the value and importance of a campus Windows Active Directory infrastructure and support it just like any other enterprise service We should recognize that there may be many complimentary directories at UW over time, one may not solve everything The university should leverage this directory as needed to support other services. If there are commercial applications for instance that support active directory, we should not hesitate to deploy them using this infrastructure. Other applications (such as the various Catalyst Tools) also might be able to leverage this directory without having to build their own Work on other C&C initiatives such as the groups project should be reflected in this AD structure so even if we have multiple directories on campus, they are in sync If additional resources are needed within C&C to make this vision a reality, an ITAC proposal should be initiated – working group to be determined

Questions and Discussion: