Troubleshooting authentication issues
This topic provides information for troubleshooting authentication issues of Remedy Single Sign-On.
Generic authentication issue
A non-existing domain is mapped to a realm
When a user request is redirected to the Remedy SSO login URL, the following message is displayed:
This error happens when the administrator deletes the default realm "*'" and then adds another realm, but does not configure a domain of the new realm.
Add the application host name or FQDN in the realm domain if the realm ID is not "*".
Authentication issues for applications hosted on different domains
Unable to issue id_token
After configuring the Remedy SSO agent for using the OpenID scope, the Remedy SSO server fails to generate id_token in the following scenarios, and an exception is logged in the Remedy SSO agent logs:
For more information about the exception, see the Remedy SSO agent logs.
After configuring the Remedy SSO agent for using the OpenID scope, make sure that you:
|An OAuth2 client cannot use the OpenID scope|
At the time of registering a client as an OAuth2 client, if you do not select the openid (Scope used for OpenID connect) check box, the client cannot use the OpenID scope. The Remedy SSO server logs a message mentioning that the specified OAuth2 client is not allowed to use the OpenID scope.
|On the Admin Console, edit the OAuth2 client details and select the openid (Scope used for OpenID connect) check box for that client.|
|id_token is invalid|
The user cannot log in and gets the following error message:
The following exception is logged in the log files:
Synchronize the time on the Remedy SSO server and Remedy SSO agent machines.
Cross launch issues for applications integrated with different Remedy SSO servers
The cross launch link is not displayed.
The target Remedy SSO server is not configured correctly.
The following error message is displayed in an iframe:
Unexpected error happened. Failed to login. Please contact the Administrator.
A wrong certificate is configured for a realm with the Preauth authentication method on the target Remedy SSO server.
Remedy AR authentication issues
AREA plugin error after AR user credentials were submitted
The user completes a Remedy SSO login (on the Remedy SSO login page for AR authentication or on the IdP login page) and is redirected back to BMC application URL.
Then, the application might display an authentication error.
The AR AREA plugin log file (ARSystemInstallFolder/Arserver/Db/arjavaplugin.log) might contain the following or similar error logs:
2015-09-13 17:04:21,324 ERROR [pool-4-thread-10] com.bmc.arsys.pluginsvr.plugins.ARPluginContext (?:?) - <ARSYS.AREA.RSSO> Could not validate userId with Service Provider. Could not retrieve user from authentication string. 2015-09-13 17:04:21,324 ERROR [pool-4-thread-10] com.bmc.arsys.pluginsvr.plugins.ARPluginContext (?:?) - <ARSYS.AREA.RSSO> Return Code:2
No groups for authenticated users
Remedy AR System is integrated with Remedy SSO, and authenticated users have no groups after login.
Uncomment the following setting in the ARSystemInstallFolder/Conf/rsso.cfg file:
AR Authentication on Remedy SSO does not work when Premium Encryption is enabled on AR System Server
After installing Encryption Premium or Performance security on AR System Server, Remedy SSO can no longer connect to AR System Server with encryption enabled.
Install the same Premium or Performance security application on the Remedy SSO server. For information about how to set up Premium or Performance security application, see .
To integrate Remedy SSO with Premium Encryption, see .
SAML authentication issues
IdP error on SAML request if SAML IdP login URL contains a query parameter
If the IdP login URL contains a query parameter (a question mark [?] is in the URL), an error might appear when the browser is redirected to the IdP login URL. For example, if you are trying to access you will not be able to log in.
SAML IdP returns NameID with an encrypted string
|Some IdPs might return an encrypted string in the NameID of the response.|
If the NameID in a SAML response returned by IdP exceeds 255 characters, increase the size of the NameId column in the IssuesTokens table of the Remedy SSO database. For example, if the NameID length is 300 characters, set the NameId column to at least VARCHAR(300).
LDAP authentication issues
|LDAP authentication failure|
When using LDAP over SSL in an environment that uses Java 8+, users are not authenticated.
The the following records are available in the Remedy SSO server logs:
Add the Java proprerties for the JVM that Tomcat uses.
Create or edit the TomcatInstallFolder/bin/setenv.sh file.
Microsoft Windows example:
If the LDAP server uses a self-signed certificate, the JVM that Tomcat uses on the Remedy SSO server does not trust this certificate.
import to the truststore () of the Apache Tomcat used by the Remedy SSO server..
|The login request is redirected to an empty rsso/start URL|
When the Remedy SSO server and the integrated application both use self-signed TLS/SSL certificates for the HTTPS connection, the certificate confirmation dialog box breaks the flow, and you cannot log in by using Microsoft Edge and Safari browsers.
|Use another browser to log in, or open the application URL again after confirming the exception for the certificate.|
Kerberos authentication issues
You can find the events and log information related to Kerberos in the following files, which are usually located in the log directory for Tomcat:
- rsso.log—The main log file of the Remedy SSO server.
- tomcat8-stdout.*.log—A file that contains Kerberos related events from Java Authentication and Authorization Service, which the Remedy SSO server uses internally to authenticate users.
Invalid keytab index number for Kerberos
An exception is generated in the logs when the keytab file is generated with a key version number (KVNO) different from the one specified in the ticket.
The log file might look something like this:
Regenerate the keytab file. You must specify the /kvno 0 option to ensure that the KVNO value is compatible.
Browser sends NTLM instead of SPNEGO
The token that the Remedy SSO server receives from the client is a Microsoft Windows NT LAN Manager (NTLM) token and not the Kerberos token.
If this issue happens, the following entry is recorded in the log file:
Ensure that the Remedy SSO server host name or domain is added to the list of websites for Kerberos authentication.
The failure could happen due to the following reasons:
Keytab file does not contain an entry to decrypt a service ticket
The keytab file does not contain an entry to decrypt a service ticket. The logs might look something like this:
Examine items and make sure that the service principal names (SPNs) are valid. If an SPN password is used in the Remedy SSO Admin Console, ensure that the Service Principal Name is specified as
To see content of the existing keytab file, run the
Click here to view the command details
The following error appears in the rsso.log file:
Install JCE Unlimited Strength Jurisdiction Policy Files for JDK/JRE to support AES128 and AES256 encryption types. You can find the policy files at the following links:
Also, install these policy files in the JRE that is used by the Tomcat server on which the Remedy SSO runs.
|The login fails because of the large size, and the browser displays an error|
The Kerberos service ticket is passed as a header value in the HTTP request. Though the default maximum header size in Tomcat is 4096 bytes (4 KB), the header size may go up to 28 KB under some circumstances.
The login fails because of the large size, and the browser displays an error message because Tomcat does not respond to such requests.
To debug Kerberos authentication issues
To ensure that customer's machine has joined the domain and the domain user is used, run the following command:
- Ensure that you have other internal resources with Kerberos authentication, and you can successfully log in to them and use them.
For this, you must have service tickets in the output of the klist utility.
- Ensure that the Remedy SSO server is configured to use the same domain that your machine has joined.
- Ensure that you are trying to access the Remedy SSO server by using its FQDN (for example, http://access.example.com/rsso/). Also, make sure that the host name used in the FQDN is identical to the host name used in the service principal name (SPN) for a service account created in the key distribution center (KDC). In this case, the SPN will be HTTP/access.example.com.
- Ensure that you have obtained the Kerberos ticket-granting ticket (TGT).
- Ensure that the browser is configured properly, see Configuring browser settings for Kerberos authentication.
- Ensure that the KDC domain is defined in uppercase in the Remedy SSO Admin Console.
- Ensure that the time difference between the KDC and your machine is no more than 5 minutes.
- Ensure that the Kerberos service ticket obtained on the machine accessing the Remedy SSO server looks like HTTP/access.bmc.com@RSSO.COM where access.bmc.com@RSSO.COM is the host name of the machine that hosts the Remedy SSO server.