IT Services accounts

Expand All

Your Oxford username is usually of the form abcd1234, where abcd is a code for your college or department to which you are first affiliated. It is administered by IT Services and is separate from any other local college or departmental accounts you may have.

A Single Sign-on (SSO) password provides a high security username and password system. It also has a second factor authentication process once set up by the customer. This gives you access to many web-based services using one set of account details for authentication. It works with any web browser that supports cookies.

Your Oxford username and Single Sign-On password can be used to log in and this will start a Single Sign-On session.  Single Sign-On means that after your initial login, you can use associated services without having to re-enter your username and password.

Manage your SSO account takes you to our WebAuth pages where you can use to set up, update, reset a password.


Oxford Single Sign-On is the only login page where you should enter your Oxford username and Single Sign-On password. You can think of the Single Sign-On as a central authentication system that is trusted by various services in Oxford to handle all the username and password checking so that each individual service doesn't need to do it for itself. Once you have entered your Single Sign-On details you will need to enter your additional authentication credentials to proceed.  See Multi-factor authentication.

To end your Single Sign-On session ("logout") you will need to close your web browser (that includes quitting all running copies of your web browser).

Each person has a primary Oxford username and Single Sign-On password which is also known as the Oxford Account. This account will stay with a person throughout their time at the University, and will be re-used if the owner leaves and then returns within 5 years.

The generation of a University Card record is the trigger which initiates the Oxford account creation process. Once the account has been created it has to be activated, which is the process whereby a security question/answer and a password are set for the account. Please note that the password must not be shared with anybody else.  The customer must then set up their Multi-factor authentication.

If your activation code has expired, please contact the Service Desk quoting the account name and your card barcode number, and the same code will be renewed for a further 30 days.

Facilities available through the Oxford account will be terminated at University Card expiry. See Finishing IT use at Oxford.

Please note that a change of affiliation or status does not result in the creation of another account. All we change are the Oxford email addresses. No paperwork or email is sent.

Account activation details for new members of staff, visitors and part-time students are provided by their college or department HR or IT team.

Oxford SSO activation details are emailed to students in advance of their arrival at Oxford. The trigger for this is the process called Final C (this is the University process which confirms that the student has satisfied all the conditions and has returned their signed University Contract agreeing to abide by the University's rules). It culminates with the generation of a University Card record, which in turn causes a new SSO account to be created. For Michaelmas starters, this process begins on 1st July; for Hilary starters on 1st December; for Trinity starters on April 1st.

The email addresses used for this are those registered with Student Records. The quality of this data is a bit variable. Undergraduate applicants often use their school email address, which doesn't work once they have left school. Therefore, known school email addresses are not used to send out activation details. Working email addresses will be requested from college admission officers where necessary.

Some mail systems treat the activation email as spam, so it is worth looking in a mailbox's junk mail folder if the message has apparently not arrived.

Nexus is built on Microsoft Exchange so as well as email it also offers calendaring, Teams, Delve and other features.

The majority of people in the University will have a Nexus mailbox and Active Directory (AD) record (status UserMailbox) created at the same time that their SSO account is created. The exceptions are non-University members with 'cardholder' or 'virtual' status cards who are not entitled to a Nexus mailbox (see service entitlements). They will have an AD record with status MailUser.

Although a Nexus mailbox is associated with an SSO account, it doesn't use the Single Sign-On system directly for authentication. Instead the SSO password is synchronised with the Nexus AD so the SSO and Nexus passwords should always be the same.

Access to a personal mailbox can be delegated to others personally for 'Send on behalf of' rights or giving access to individual folders. Alternatively, the Service Desk can set either 'Send As' or 'Send on behalf' rights, as well as 'Full Access' to the whole Inbox and all subfolders, calendars, address books etc. at the personal request of the owner. This is typically used for a Personal Assistant accessing their employer's mailbox. To make a request, use the self-service form for Email Account Delegation.

A personal mailbox will normally be visible in the Nexus Global Address List (GAL). This is so that mailboxes can be found, and Outlook autodiscover will work. It is possible to for a mailbox to be hidden in the GAL (this requires Head of House approval).

If a mailbox belonging to a Retiree isn't used within six months of it being set up, it will be removed.

 

These are often role-based accounts which can be passed on to a different person if the original role-holder leaves. They are essentially identical in functionality to a primary mailbox.

A Project mailbox will be created on request from an IT Support officer.

Generally these accounts are deprecated, as password sharing is a security risk. Shared mailbox access can be achieved using delegation via Outlook or OWA. Also 'Send As' or 'Send on behalf' rights, as well as 'Full Access' to the entire mailbox can be requested via the self-service form for Email Account Delegation.

A password is needed when a mailbox is to be used with IMAP or a mobile phone mail client, or when non-Nexus facilities are needed as well eg mail list ownership, Linux, web space.

A project mailbox without an SSO account can only be accessed using delegation via Outlook or OWA. 'Send As' or 'Send on behalf' rights, as well as 'Full Access' to the entire mailbox can be requested via the appropriate self-service form for Email Account Delegation. These mailboxes are not suitable if access from an IMAP client or mobile device is required.

A Resource mailbox is a specialised mailbox used for calendaring or room booking. In AD it has a status of RoomMailbox or EquipmentMailbox. It cannot be associated with an SSO account.

Non-University members with 'cardholder' or 'virtual' status have a record in AD (Active Directory) but have no mailbox (AD status MailUser). Such people can access SharePoint, and can have an external email address associated with the account so they can participate in SharePoint activities.

Secondary accounts are similar to personal Nexus365 accounts, and they can be shared more easily with multiple people across the University.  They can be created with or without a mailbox and with or without a Single Sign-On password.  Example email addresses used for secondary accounts are enquiries@college.ox.ac.uk or itsupport@unit.ox.ac.uk

Secondary accounts are also referred to as project, non-personal, role-based or generic accounts.

Some examples of when a secondary account may be used could be when:

  • a shared calendar is required for group events
  • several people need to monitor mail sent to an email address
  • several people need to send mail from a common email address
  • the account relates to a specific role and is passed to a different person if the role changes hands

Project accounts can be registered for any member of the University, but must be requested by an IT officer through the secondary account request form (ITSS access only).

Following its creation, the owner of an account can update its delegates through the Email Account Delegation service request.

For further information, see our webpage on Shared and secondary accounts.

A Remote Access username and password is used to authenticate to the following services:

An individual can only have one Remote Access account, which has the same username as their primary Oxford Single Sign-On account. It can be used on multiple devices, however.

A Remote Access account can be created by going to IT Services self-registration and setting a password. You must never set your Remote Access password to be the same as your Single Sign-On password.

Remote Access passwords are tied to university card expiry dates. A password can be changed at any time via self-registration.

 

IT Services provides a general purpose computer system running Debian GNU/Linux. This is available to University members who have an Oxford account. However, non-University members with 'cardholder' or 'virtual' status cards are not entitled to use the Linux service.

Before using a linux.ox.ac.uk account for the first time, it needs to be activated. To do this, visit the web-based account management interface and choose Activate shell account.

The service is accessed using your Oxford username and Single Sign-On password on secure login to linux.ox.ac.uk. A wide range of software is provided, but does not include any commercial programs. There is no mail delivery to the system. Personal web filestore can also be accessed.

Most web browsers (including Chrome, Edge, Internet Explorer, Firefox, and Safari) work with Oxford's web services out-of-the-box.

The particular features your browser must support are:

  • Cookies - these are used to hold information about your Single Sign-On login status
  • SSL Certificates - these are the digital equivalent of ID cards which help other people identify you, and help you identify other people, websites, and organizations. Certificates are issued and administered by Certificate Authorities (CAs). Oxford uses certificates that have been signed by either QuoVadis or Trend Micro, both of which will automatically be accepted as a trusted CA by most modern browsers

If you are security-conscious enough to use a custom security configuration then you may want to bear in mind the following points:

  • For javascript settings - you will need to trust scripting from nexus.ox.ac.uk
  • For cookie settings - you will need to accept cookies either automatically or when prompted. If you are very concerned about cookies you can delete them at the end of your browser session to avoid any ongoing tracking
  • For CA certificates - you will need to trust certificates issued by the Certificate Authorities that we use (QuoVadis or Trend Micro)