Active Directory for Oxford (Project MADDOX): Final report

Transcription

1 Active Directory for Oxford (Project MADDOX): Final report Oxford University Computing Services Executive Summary Project MADDOX (July 2011 October 2011) has finished, having met all stated aims. The project's main goal was to deliver improvements to the support offered for ITSS wishing to integrate local Active Directory deployments with University Single Sign-On. Technical tests concluded that users experience the same level of SSO integration regardless of which technology (Microsoft AD Kerberos or MIT Kerberos) is used to authenticate users. Tests further confirmed that the extent of SSO integration that can be achieved within a federated IT organisation is primarily limited by the capabilities and configuration of the Microsoft Windows operating system on the client, and the application software used. A workshop for ITSS proved pivotal in deciding that a technology-only solution such as deployment of a top-level Active Directory domain would not satisfy the needs of any substantial ITSS group within the University. Instead, a strong case was made for clarifying, publicising, and enhancing the degree of central support offered to ITSS who are seeking to achieve SSO integration of their own AD installations. The implementation phase of the project focussed on the output of the ITSS workshops, making immediate and substantial improvements to both the catalogue of central support services and technical documentation. The project also identified a number of recommendations for follow-on initiatives, where implementation either falls within business-as-usual activities or requires recurrent funding. A full project archive is available at Project Overview Project MADDOX was an internally-funded OUCS project running from July to October Its aims and objectives were to offer an enhanced level of support for integration of Microsoft Active Directory (AD) based domains with central identity and access management services, allowing greater uptake of SSO across the University and corresponding improvements in user experience and overall security. The first of two project phases covered a detailed investigation of different technical architectures for supporting AD domains across the University, including a variety of end-user test cases. Investigation focused on integration of Windows workstations joined to an AD domain. The second phase built on the findings from phase one to select an approach and provide improved support for SSO integration of AD environments. Background OUCS provides an MIT Kerberos-based Kerberos realm, OX.AC.UK, at the core of its SSO authentication infrastructure. This provides direct support for Kerberos-supporting clients and servers, and forms the basis for the widely used WebAuth and Shibboleth web single sign on technologies. In addition, it is integrated with several other realms, including some AD domains operated by departments and colleges, allowing seamless access to local services with the Oxford SSO account. Whilst this integration has taken place successfully in a number of cases, two key factors in proposing MADDOX were: 1) to improve this integration point by offering more clearly defined

2 and understood local support for AD integration; 2) to investigate the extent to which Microsoft supports this configuration. Scenarios The project considered the deployment of AD at Oxford University. This is characterised by a large number of unconnected AD domains and forests, typically operated within a single department or college for the exclusive benefit of users associated with that unit. Three scenarios were considered for detailed investigation and analysis: 1. Native AD-AD : central AD in receipt of krb5-sync password synchronisation from MIT realm; unit AD with one-way trust to central AD 2. Indirect cross-realm trust : central AD with one-way direct realm trust to central MIT realm; unit AD with one-way trust to central AD 3. Direct cross-realm trust : one-way direct realm trust between unit AD and central MIT realm; this is the configuration currently offered to, and used by, ITSS Scenario 1: Native AD-AD Scenario 2: Indirect cross-realm trust

3 Scenario 3: Direct cross-realm trust Two further scenarios were not considered owing to clearly apparent technical issues: 1. A single central AD forest replacing the local installations, and containing all user accounts, servers, workstations, and other AD objects. (This would not be able to accommodate conflicts between differing local unit requirements, e.g. relating to schema extensions, user home directories, etc, nor would it be possible to encapsulate and devolve the necessary administrative rights to local ITSS). 2. Synchronisation of passwords to all local AD installations (password synchronisation to the large number of AD domains within Oxford would cause slow and inconsistent synchronisation, great confusion for users, and high call volumes to IT service desks). These scenarios are documented in more detail at

4 Use cases and supported platforms The following use cases were identified as important for any solution and support for these use cases was the primary focus for the investigation: Workstation login Workstation login with access to file server Workstation login receiving group policy from local domain Workstation login with access to print server Browser authentication to IIS (Internet Explorer 6, 7, 8; Firefox 5.0; Chrome 13.0; Safari 5.1; Opera 11.5) Sharepoint 2010 authentication MS SQL Server authentication These use cases are documented in more detail at In all cases, Windows XP, Windows Vista and Windows 7 workstations bound to a local AD domain were in scope. Workstations not bound to a local AD domain were out of scope. Additionally, Windows 'Home' OS editions do not support AD integration, and so were also out of scope. Test methodology A virtual test environment was built to include AD servers and member workstations to model the above scenarios (no krb5-sync arrangement was put in place, since the operation of krb5-sync is already understood from the work undertaken to support SSO passwords in Nexus; this was used as a base-line test with native AD accounts). Each use case was set up and performed for the three test scenarios listed. The test infrastructure was set up in order to provide a repeatable set of tests, depending on a minimum of external systems; VM snapshots and cloning using the NSMS virtual 'vm4rent' service were used where required in order to assist with this. The existing TEST.OX.AC.UK realm, which matches the configuration of the main OX.AC.UK realm, was also used. Tests were carried out manually in accordance with test scripts, to ensure a high degree of repeatability without the need for the development of automated test infrastructure. More details about the test methodology may be found at Test results A full matrix of test results is available at only a summary of important findings is presented here. Native AD to AD The native AD to AD scenario (excluding password synchronisation) is the Microsoft recommended configuration and was therefore taken as a baseline test. All tests carried out using this set-up succeeded as expected, except for Opera, which does not support Kerberos-based HTTP authentication (SPNEGO). It should be noted that previous experience with the krb5-sync setup at OUCS has identified a number of specific and recurrent problems including frequent failure to synchronise during system maintenance and at other times, and the inability to reflect accurately password expiry attributes.

5 One additional challenge with this setup is the fact that some Microsoft clients prompt users to set or change their password directly in the AD domain; the one-way nature of synchronisation in this setup means that this cannot be supported. Indirect Cross-realm Trust The indirect cross-realm trust (scenario 2 above) failed to support the initial workstation login. The problem was unexpected, and traced back to a STATUS_DOMAIN_TRUST_INCONSISTENT error reported by the trusting AD domain controller. Having failed the initial login, this scenario was consequently unable to be tested for the other use cases. A support call was placed to Microsoft, via their broker ESCuk, on 19 th September The call was placed to establish the reason for a "STATUS_DOMAIN_TRUST_INCONSISTENT" Kerberos error message received from the domain controller in the trusting AD (maddox-trust-unit.ox.ac.uk in our scenarios), when attempting to log on to a client Windows XP workstation under the indirect cross-realm trust approach. Various logs, traces and other information were supplied to ESCuk on request over the following few days. Initial triage was performed by ESCuk and they officially passed the call onto Microsoft for resolution on 6th October Some initial suggestions from Microsoft were off the mark and the call was further escalated on 2 nd November. As of 9th November, no resolution had been received, nor a satisfactory explanation for why the error message was displayed. Direct Cross-realm Trust The direct cross-realm trust tests (scenario 3 above) all succeeded as expected, again with the exception of Opera. Summary of results Scenario Summary of results Native AD-AD All tests successful, with the exception of Opera 11.5 Kerberos/SPNEGO test Indirect cross-realm trust All tests failed Direct cross-realm trust All tests successful, with the exception of Opera 11.5 Kerberos/SPNEGO test Additional Observations For those tests that included setting up groups to authorise authenticated users' access to particular unit-level services, some access is required to view users in the central AD. A cross-forest trust as set up in the defined scenarios is not sufficient to grant the level of access required to browse the central AD domain. A production implementation based on this scenario would have to consider the establishment and management of specific ITSS users with limited privileges to view users in the central directory. It may be sufficient/acceptable to grant these privileges to the Oxford usernames of specific ITSS. The unit-level domain controllers need access to certain ports of the central DC prior to establishment of a cross-forest trust. Client machines within a unit-level domain would also need access to certain ports (e.g. Kerberos ports) of the central DC. A production deployment at Oxford would be likely to grant client access to a central DC from all University subnets to avoid having to configure access to specific client workstations and unit-level DCs on the establishment of each new cross-forest trust. The specific ports required are identified at

6 ITSS workshops Testing in phase one demonstrated that the native AD-AD and direct cross-realm trust scenarios both supported all use cases. In order to identify which of these would provide the best central support for AD installations around the University, it was decided to organise a workshop to present the findings from phase one and solicit from ITSS the differentiating factors that would enable a clear decision on how to proceed with the second phase of the project. Two workshops were held; they set out to find out from ITSS across the University: how AD was currently used how a central authentication-only AD service might help ITSS the potential benefits and costs, and potential funding models for such a service In addition, the workshops sought to improve the general understanding of issues relating to AD integration across the University. A detailed report of the workshops is available at The key perceived benefits of a central service were suggested to include: easier (e.g. automated) support for processes such as account provisioning and deprovisioning, improving the responsiveness of IT to arrivals and departures, and also reducing operational demands on ITSS an improvement in the user experience (primarily through the conveniences of having fewer passwords to remember and needing to login less frequently) and consequent positive impact on customer satisfaction and reputation of IT services / ITSS provision of centrally-maintained groups to support access control potential for cross-unit resource sharing and support for centrally provided AD-based shared services (e.g. Microsoft Dynamics CRM) A disadvantage to some of the scenarios was identified as negative impact on local autonomy, arising from two issues. One issue is the real-time dependence on the availability of central services, where access to local IT services could be severely disrupted by failure of the central service or network connection. Another issue is the limitation of the level of control that local ITSS would have over central user accounts and related objects (e.g. Group Policy) in AD. Key factors relating to costs and savings were: Some ITSS recognised that time savings were possible, from the point of view of reduced calls to the Help Desk, a reduction in duplicated effort, and more automated processes Others asserted that the value of the service compared to the local cost of integrating it would be negligible Where ITSS had already invested in their own account provisioning and de-provisioning, the benefits were not seen to be significant. For those that did not have account management processes in place there were increased benefits in centrally-provided or centrally-supported account management Many of the benefits were seen as difficult to equate with a monetary value.

7 Phase Two Approach The technical investigations demonstrated that two deployment scenarios (native AD-AD and direct cross-realm trust) could provide a means of integrating local AD installations with University SSO, and that there is very little in the user experience to differentiate them. The ITSS workshops identified a number of specific benefits, to both users and ITSS, that could be realised through improved central support for integration of local AD installations with University SSO. The feedback received during the ITSS workshops demonstrated that requirements from different sectors of the ITSS community are hugely diverse, and any single technical solution would only meet the needs of a minority. The workshops also revealed that low take-up and minimal cost savings (if any) anticipated by ITSS would make it impossible to justify the costs of development and ongoing support for a new central AD service. However, the workshops did find consensus among ITSS that work to formalise and better support the existing direct cross-realm trust scenario would be highly desirable. This work included both technical and non-technical aspects. As a result, it was decided by the project team that the second phase of the project would deliver: a. a number of immediate improvements to the existing service and associated support, and b. make recommendations for further work through a combination of future projects and business-as-usual activity It was agreed that the project would not deliver a new central AD authentication-only service. Improvements to existing services The main activity in the remaining project time was to formalise our support offering for integration of local AD domains with SSO and establish an initial set of support documents. A new page has been created within the Kerberos service documents to list the elements of support that are provided: Creation of Kerberos principals required to establish cross-realm trust Testing of integration for new releases of Microsoft Windows Server operating systems Provision and maintenance of technical documentation on AD configuration and integration with University SSO Provision of advice on specific AD configuration and integration scenarios Assisting in diagnosis of integration and authentication problems associated with crossrealm trusts Acting as a broker to refer enquiries / faults to Microsoft (via our appointed Microsoft partner) The poorly maintained AD-SSO integration documentation on the wiki has been reviewed, restructured, updated, and moved onto the OUCS web site where it can be properly maintained. The wiki page has been pruned of the migrated configuration instructions, but remains in place as a location for community contributions and discussion. The officially maintained documentation can be found on the OUCS web site at: In addition, an announcement was sent to ITSS confirming the enhanced service offering now available.

8 Recommendations for further work In addition, several opportunities for further development on existing IAM services were identified, including: Addition of RC4, 128-bit AES, and 256-bit AES encryption types to the MIT realm TGT, bringing improved support for Windows 7 clients Support for seamless web SSO with WebAuth, via HTTP Negotiate-Auth Making the case for increased funding to provide dedicated staff time to develop and support integration of local AD deployments with University SSO Undertaking the ongoing testing of new versions of Microsoft Windows and AD technologies with the direct cross-realm integration, including updates and validation of the online support documentation Dominic Hargreaves, John Ireland, Nigel Brown, Adrian Parks, 11 November 2011