Troubleshooting resource access problems

If you are an end user, you should contact your administrator. You can look up their chosen contact details via the forgotten password page.

From time to time your patrons might report problems accessing resources. Usually it is something that can be quickly and easily resolved yourself like a forgotten password, but occasionally not. Here is how in general to find out what is up and what to do. Hopefully steps 4 and above will rarely be reached.

1. Ask the user which resource they are trying to access

   1. If it is one you subscribe to, check the resource status page.

   2. If it is one you subscribe to, and you are using restrictive mode, check that it is in one of the permission sets allocated to that user and add it if necessary (it will be a few minutes before this takes effect everywhere)

   3. If it is one you subscribe to, and no one has gained access at all, check that the provider has enabled remote access for you. This will usually be referred to as federated access unless it is a specialist resource only available via the proxy

      1. In the unlikely event that there is any confusion over which catalogue resource it should be, talk to your OpenAthens support provider

   4. If it is one that you do not subscribe to, then the user correctly did not get access, however you should still:

      1. Check that the resource is not listed in any permission sets

      2. Consider if you need to turn on restrictive mode

      3. Ask the user why they're trying to access that one in case you have a link on other pages you control... or want to consider subscribing

2. Check the activity tab on that user's account

   1. If nothing is there, the user is either not signing in at all, or is not using that account's username / email address. Remind the user of their ID and reset the password if necessary

   2. If activity is there you will see if they have been entering the wrong password or if they've been stopped for other reasons

3. Attempt access with your own account, or ideally a test account that uses the same permission sets as the user's account. If the user is present, watch them attempt access with their account

   1. If access is achieved, educate the user

   2. If access is not achieved, assess what is blocking it

      1. If the error message is unclear, look at the URL to see where it is coming from. 

         1. If the URL in your browser starts with something like https://login.openathens.net, the error message is from us.

            1. If you use local accounts it could come up during the login process and would usually mean ether a problem with something vital not being sent (such as the specified user ID), or a problem mapping the user to a sub-organisation if you use that feature.

            2. If it says anything about not finding an entity, then the resource is not in the same federation, or if it's a custom SAML resource there's a hiccup with that

            3. If it says anything about trying again later, check the service status page 

            4. If you are still unsure you can contact our service desk

         2. If the URL in your browser starts with the resource's domain, then the message is from them.

            1. Often it is because their system doesn't think you have a subscription for one reason or another, but sometimes things are broken

            2. They are the best (and often only) people who can tell you what the error means

         3. If the URL in your browser starts with your own domain, then talk to your IT team

4. If the resource is one you subscribe to and is not providing the required level of access, contact the service provider. You will probably have to tell them your organisation identifiers

5. If the resource is one you subscribe to and the error message says anything about attributes, you have either not set the expected role or entitlement attributes on the permission set(s) used by the account, or not allocated the relevant permission set(s) to the user, or not set the attributes as releasable. The service desk can help you if you are unsure but this will be one of two things:

   1. If it is only affecting one user who should have access, then the account does not have the correct attributes or permission set(s) assigned

   2. If it is affecting all users, then the permission set(s) do not have the correct attributes assigned to them or the release policy does not release them

6. If you are still not getting as far as the resource and are getting an error message from us, first check the service status page and if there is nothing there to suggest there is a known problem that is being fixed, then contact our service desk

These have been ordered by the general likelihood of where a problem is. You will know your set-up and patrons best and may find a different order suits you better.

Other things that may affect access

If the user frequently has to sign in again

• They may be blocking or clearing the OpenAthens session cookie

• Redirector links are customer specific - using links from a different OpenAthens organisation will present the user with a login page

• If the user selects the wrong organisation in a WAYF they'll be presented with a login page

With the last two, they can go back and correct their error if they don't have credentials for the other organisation.

Contacting our service desk

If you are contacting our service desk, there is some information that they will always require to investigate an access issue and supplying it when you log the call means they will not have to ask you for it and everyone can avoid the delays which that kind of clarification questions can bring. The things they will always need to know to start looking at any access problem are:

• An example of a username / user ID that has failed. Do not send the password.

• The date and time that username failed (within a few minutes is close enough)

  • saying 'every time' or 'always' is unfortunately not as helpful as you might imagine as we have to find references in various logs that cover millions of events per day

• The name of the resource you are accessing

• The URL you followed to the resource

• The URL and text of any error message on the page you ended up at 

Some other bits of information that may occasionally be needed which you could include if you have them to hand, are:

• The type of resource (federated, proxy, etc)

• The sub-organisation you were acting as (if you were)

• If you have modified the access URL of the resource in the catalogue, please include that too

• Any steps to recreate if it happens via one method and not by another