syslog

They say that buses come in threes; I can’t promise that this will be the case with our team vacancies, but we have recently advertised a second Systems Administrator role. Again, we are looking for someone to join the team to work with us on maintaining and improving existing services, as well as supporting the development of new ones. The job advert is included below, along with a link to further details:

Do you consider yourself a capable Unix/Linux systems administrator? Are you enthusiastic about working in an expert team where quality of service, attention to detail, and a willingness to respond positively to new challenges are all important? Would you also be able to specify, install, network and configure Linux platforms for resilient, enterprise IT systems? If so, we invite you to apply for the post of Unix Systems Administrator at Oxford University Computing Services.

The Unix Systems Administrator will join a team responsible for many of the IT services critical to the operation of the University, including Identity and Access Management services; web hosting; email and collaboration services; standard and bespoke application hosting platforms for other parts of the Department; and substantial infrastructure and monitoring capabilities. The post-holder will contribute to, and carry out independent work on, the development and management of new and existing systems and services.

The primary deployment platform used by the Systems Development and Support section is Debian GNU/Linux, and includes an extensive configuration and software management suite. The ideal candidate will have experience of a university environment, and knowledge of technologies such as Kerberos, LDAP, AFS, and systems management and monitoring.

There are many advantages to working at the University other than the world-class research culture. Benefits include flexible working, an excellent pension, career prospects and generous holiday provision.

Applications for this vacancy are to be made online. Please ensure that you address each of the selection criteria in your supporting statement.

In order to apply for this role and for further details, including a job description and selection criteria, please visit the University recruitment site: Unix Systems Administrator (Systems Development and Support Section) post.

Sysdev are currently looking for an experienced Systems Administrator to join the team to work with us on maintaining and improving existing services, as well as supporting the development of new ones. The job advert is included below, along with a link to further details:

Salary: £36,862 – £44,016

Do you consider yourself an expert in Unix/Linux systems management? Are you enthusiastic about working in an expert team where quality of service, attention to detail, and a willingness to respond positively to new challenges are all important? Would you also be able to specify, network and configure hardware and Linux platforms for resilient, enterprise IT systems? If so, we invite you to apply for the post of Unix Systems Administrator at Oxford University Computing Services.

The Unix Systems Administrator will join a team responsible for many of the IT services critical to the operation of the University, including Identity and Access Management services; web hosting; email and collaboration services; standard and bespoke application hosting platforms for other parts of the Department; and substantial infrastructure and monitoring capabilities. The postholder will take a leading role in the development and management of new and existing systems and services.

The primary deployment platform used by the Systems Development and Support section is Debian GNU/Linux, and includes an extensive configuration and software management suite. The ideal candidate will have experience of web application hosting and development, the ability to address the interoperability challenges posed by a mixed platform environment, and experience of large-scale systems management.

There are many advantages to working at the University other than the world-class research culture. Benefits include flexible working, an excellent pension, career prospects and generous holiday provision.

This position is offered on a fixed term of two years initially.

In order to apply for this role and for further details, including a job description and selection criteria, please visit the University recruitment site: Unix Systems Administrator (Systems Development and Support Section) post.

SSO account holders are automatically emailed when their password needs to be changed – but surely any email that says “access to your account will be restricted until you have logged in here <url>” will be counted as a phishing message and ignored.

The template in current use was designed in 2006, and aside from a few minor adjustments has remained largely the same for over 5 years. Although x0,000 users process it smoothly each year, it certainly does exhibit several characteristics that should trigger caution from a responsible user. Recently there has been a campaign to raise user awareness of phishing and, whether consequently or coincidentally, there is (anecdotal) evidence of increased numbers of enquiries about the authenticity of our internal messages, including password expiry notifications.

Designing a good template for this message is hard. On one hand there is a desire to avoid looking like a phishing email – mentioning account management, loss / restriction of access, and providing links to reset / confirm account details are all features that should sound alarm bells for most users. On the other hand, the very nature of what we need to communicate means that in order to be effective a message will touch on these aspects – and users will expect us to make life easy with a handy link.

We have recently invited Oxford ITSS to suggest improved versions of the “password expiry” template by emailing them to sysdev@oucs.ox.ac.uk. Other members of the University are welcome to contribute to this as well, through the same channel.

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:

1. Introduction (5 minutes)
2. Break-out Session: “How do you use AD?” (15 minutes)
3. Presentation (30 minutes)
4. Break-out Session: “How does a central AD help you?” (25 minutes)
5. Break (5 minutes)
6. Break-out Session: “Every Service has Benefits and Costs” (25 minutes)
7. 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.

Tuesday saw this year’s UAS Conference taking place in the University Examination Schools. This annual event brings together staff from around the University with the aim of exchanging information about things happening in the University Administration and Services Division. OUCS officially joined UAS in January of this year (moving from ASUC), so although we have been invited to present / attend in the past, there was perhaps a sense in which our presence was cast in a different light this time around.

The UAS Conference and ICTF Conference are quite different affairs. Where the ICTF Conference has a backbone of plenaries with workshops woven around them, the UAS Conference programme is much more open with up to 11 concurrent workshops (either 30 minutes or hour-long). These are organised in four hour-long slots, with an opening plenary (this year given by the Registrar under whom UAS sits), and a closing panel Q&A session.

Workshop topics are quite diverse, as you might expect given the diversity of operations within UAS itself. Some, such as “Using assertiveness to improve communication in the workplace”, are bite-sized training sessions, whilst others such as “X5 Project: an update”, aim to communicate about current activities and future plans.

I made it along to 5 sessions, interspersed with lots of ad hoc discussions as I bumped into colleagues from all parts of the University.

Toward Coordinated Central ICT provided an update on work to bring together BSP, ICTST, and OUCS. The presentation was given by Anne Trefethen who is leading the project, and outlined key features of the project and current thinking. The project’s objectives are to create a more coordinated service for users, and to increase efficiency and effectiveness. A high-level schedule was outlined: identify opportunies 0 – 6 months; quick wins, planning, revised governance model, and initial consolidation 6 – 12 months; implementation of plans 12 – 24 months; completing implementation of new organisational structure 24 – 36 months, and we were given an indication of what the revised governance model might look like.

Understanding the JRAM and the Infrastructure Charge – second time round for me – showed how incoming funds such as student fees are divided and distributed amongst the academic divisions, departments, and colleges, and how a portion of this is then claimed back from divisions to fund central University operations. Some fine animated visuals made it easy to understand what is in fact quite a complex model (the JRAM). The workshop went on to describe how the 123 Infrastructure Charge then determines how much should be pulled back from academic departments, and on this I will attempt to provide a summary.

The 123 Infrastructure Charge works on the basis that the cost of centrally provided services are related to academic departments in one of 3 main ways. Type 1 services (e.g. divisional office) are consumed by specific divisions, so the cost is essentially a direct cost to that division. Type 2 services (e.g. student admin, estates) are shared by several departments, and the cost is distributed amongst these according to an appropriate measure of “level of use” which may vary depending on the service (e.g. student numbers, floor space, annual turnover, etc). Type 3 services do not have a usage-based link to divisions, and are subdivided into those for which the divisions can reasonably be expected to pay (e.g. VC/Registrar, PRAS), and those for which divisions cannot be expected to pay (e.g. University Parks, museums). In a slightly Douglas Adams-esque fashion, the 123 Infrastructure Charge includes a fourth category of “service to service” charge where the costs of a service which is only consumed indirectly by divisions (such as BSP) is redistributed across the directly consumed services prior to the apportionment calculation.

The Worst Website in the World made extensive – almost exclusive – use of audience participation to describe the most annoying web site we could cumulatively imagine. By suggesting how to achieve the opposite of each annoyance we then discovered how to create something which isn’t the worst website in the world. The notes that we typed up will be published soon on a …website… near you!

What’s Religion and Belief got to do with me? This workshop, offered by the Equality and Diversity Unit, raised awareness of legislation changes introduced in the Equality Act 2010, and ongoing work to explore perceptions of how well the University understands accommodates those with particular religions and belief systems. An interesting session from which I took away two points: one of the areas most commonly raised as a problem by survey respondents was college food, and the Equality and Diversity Office is an excellent source of advice and assistance.

Sharing Services: what do you think we can do? was another facilitated discussion, with the audience encouraged to think about the opportunities for greater sharing of services within the University, what could be stopped in order to release resources to do this, and how to get the ball rolling. What made this particularly interesting for me – coming from OUCS – was hearing about the opportunities for non-IT services to be shared.

The day was rounded off with a panel Q&A session. The questions were the sort of thing you might expect – “What do you see as the biggest challenges / opportunities facing us”, “How can a democratic governance ensure that every voice is heard”, … However it was two of the panels responses that I will remember.

The first was in response to a question about colleges and the university working together – the push and pull of centralisation. Tim Gardam provided one of the best expressions of the value in Oxford’s organisational (un)structure. He said that the University structure is two-dimensional – it could be viewed as a vertical structure within the divisions, cross-cut by the colleges. This is a very modern (matrix) structure, and provides great resilience because a vulnerability to current conditions in one structure can be bolstered by strength in the other. He went on to say that this also enables the Collegiate University to provide students, tutors, and researchers, with an experience that is both “big and small” – vast yet personal.

The second was from a panel member who joined the University just 7 weeks ago. Her comment was that Oxford “is like no other place”. Yes indeed, there’s no cookie-cutter for Oxford, despite what some consultants would have us believe – long live innovation!