Page Comparison

...

1. Check from the Accounting Service audit log if there are these kind of lines with error "Access token is not active":

   Code Block
   language text
   "2019-09-18 12:59:05.131" "Resource access" "cn=Administrator,ou=System,cn=Ubilogin,dc=ucentos7allsingle" "GET /accounting/verify/events/2019-09-17" "SUCCESS" "" "2019-09-18 12:59:05.429" "Auth event" "" "GET /api/v1/accounting/verify/events/2019-09-17" "AUTHORIZATION_FAILURE" "OAuth2AuthenticationException: Access token is not active."

   
   

2. SUCCESS in getting the resource indicates that there is a valid OAuth2 session but the AUTHORIZATION_FAILURE in token introspection indicates that OAuth2 client authentication fails.

3. Client authentication settings in the browser cookie or Accounting Service settings do not match with the LDAP settings. Restart your browser and try again.

4. If this does not help update SSO again
   in Linux:

   Code Block
   language bash
   cd /usr/local/ubisecure/ubilogin-sso/ubilogin ./config/tomcat/update.sh

   in Windows:

   Code Block
   language powershell
   cd /d "C:\Program Files\Ubisecure\ubilogin-sso\ubilogin" config\tomcat\update.cmd

   
   

Sample health check response in an error case

NOTE that the detailed information is by default shown only to the authenticated users, see Accounting Service management / Health endpoint detailed information.

The following screen snapshot of Accounting Service health check is captured in a situation when the Accounting Service has first succesfully started but then PostgreSQL server has stopped. Processing the health check request takes 30 seconds which is the connection timeout length. HTTP response code 503 is returned with the following kind of JSON data:

The default output for unauthenticated users simply shows the main level status: