In September Project MADDOX invited ITSS to attend a 2-hour workshop entitled “Active Directory – Single Sign-On Integration”. The workshop content was geared towards ITSS who operate Active Directory environments and who want those environments to be integrated with the University’s SSO infrastructure. Around 40 ITSS signed up across two workshops, with approximately equal representation from across the University’s divisions and colleges.
The workshop was planned as an interactive session to foster audience participation, with the following format:
- Introduction (5 minutes)
- Break-out Session: “How do you use AD?” (15 minutes)
- Presentation (30 minutes)
- Break-out Session: “How does a central AD help you?” (25 minutes)
- Break (5 minutes)
- Break-out Session: “Every Service has Benefits and Costs” (25 minutes)
- Next Steps and Questions (15 minutes)
After an introduction to the workshop we started with a break-out session, entitled “How do you use AD?”, in which we asked attendees to split into pairs and describe what kinds of usage their current AD deployments are put to. Responses to this question were wide-ranging, with not only descriptions of the expected use cases such as workstation user authentication and authorisation, group policy, controlling access to shares and printers, web services, database services, and third-party appliances, but also for VPN authN/authZ, access for Macs, and many other rarer, more specialised third-party applications.
Adrian Parks and Nigel Brown then gave a presentation on Project MADDOX to the attendees. We began by describing the background of AD and SSO within the University, from 2000 onwards, through the work done in the run-up to the Nexus implementation, up to the current day. Next we provided an update on the current OUCS project that is investigating ways of offering an enhanced level of support for AD-SSO integration: Project MADDOX. The project’s investigations were carried out into the potential of an Active Directory integrated with central SSO for authentication only. This is because authorisation in a federated environment is best devolved locally (local ITSS will know their authorisation requirements best). We described the centralised AD support scenarios that we investigated as a part of the MADDOX project (Native AD, Indirect Realm Trust, and Direct Trust). We briefly explained the reasons for the scenario selections, and why some other scenarios were ruled out. Finally we described the tests that we ran and the results. The presentation is available for ITSS to review at http://projects.oucs.ox.ac.uk/maddox/resources/MaddoxWorkshop-v1.8.ppt.
Following the presentation we introduced another break-out session, entitled “How does a central AD help you?”, in which attendees were asked to break out into small groups, to discuss the perceived benefits of the feasible scenarios described in the presentation, as well as what would characterise their ideal AD solution. The responses were wide-ranging again, but commonly focused on:
- easier account provisioning and deprovisioning
- an improvement in the user experience (the convenience of fewer passwords)
- benefits for group policy based deployment
- a desire for a better level of documentation and support, with ITSS recognising the potential for cross-unit shares and other central services that a wide take-up of SSO would offer
There was also some discussion about the authorisation difficulties that some units faced, many of which the Core User Directory (CUD) project should help to ease. Another important point raised was that while 3rd party applications may appear to “support AD”, they may not support Microsoft’s recommended Kerberos authentication mechanism (in cases such as these it would be beneficial to ask vendors for appropriate support).
At this point in the workshop we took a break for attendees to stretch their legs.
After returning to the session we embarked on the final break-out session of the workshop, “Every Service has Benefits and Costs”, in which ITSS were asked to identify the benefits of enhanced central support for AD authentication, and consider any costs. In an attempt to estimate the worth of a proposed service some good points were made for both benefits and costs. To summarise:
- Some ITSS recognised that time savings were possible, from the point of view of reduced calls to the Help Desk, reduced pressure on local ITSS time, a reduction in duplicated effort, and improvements in reputation and customer satisfaction
- Others postulated 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 deprovisioning, the benefits were not seen to be significant
- For those that did not have account management processes in place there were increased benefits in, or improved support for, centrally-provided account management.
- Many of the benefits were seen as difficult to equate with a monetary value.
This session also touched on the question of whether a service like this could be chargeable, and what units would be prepared to pay for such a service. Many (but not all) College and Department ITSS were/would be reluctant to pay for a centralised authentication-only AD service, and the general feeling appeared to be that University Departments already pay for SSO services through the infrastructure charge. However, the range of responses to this was large. Most attendees from Departments estimated the savings to be minimal, with the exception of one Departmental attendee estimating a saving of up to 3 people’s workload per year, and attendees from Colleges largely estimating a negligible saving, with a few College ITSS esimating a saving of up to 50 hours per year. In cases where the move to a centralised service was estimated to incur net costs, it was considered that this was likely to be a one-off migration cost, with the cost gradually offset by future benefits.
Following the final break-out session we described the next steps: to assess the options in the light of ITSS feedback, cost-effectiveness, and key stakeholder concerns; to select an appropriate solution and implement it. Once the choice of a preferred solution has been made, we plan to communicate this to ITSS. We then took questions from attendees. One question was about whether any of the existing AD SSO solutions would be removed as a result of decisions taken during the MADDOX Project (it should be stressed that the currently available AD SSO solutions will remain, whatever choices are made as a result of the MADDOX Project). Other questions were concerned with the technical possibilities around using cached logins and shadow accounts with a central domain. Someone else posed the question of why we can’t simply use OUs (or individual domains) in a single central AD (because there could be no local-specific settings, would be too many admins, problems in maintaining intra-forest security boundaries etc), or set up password synchronisation to local ADs (password synchronisation has technical limitations that would make this entirely unsupportable, quite apart from the security risks inherent in widely distributing SSO credentials).
Finally we wrapped up the session, and as I did then, again I would like to take this opportunity to thank all the ITSS that attended the workshops, who will have helped inform the choices to be made during the MADDOX Project.