Troubleshooting authentication issues

This topic provides information for troubleshooting authentication issues of Remedy Single Sign-On.

Related topics

Generic authentication issue

Issue	Description	Workaround
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: `Unexpected error happened. Not possible to define a realm.` 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

Issue Description Workaround

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:

If you do not generate the JSON web key (JWK), the Remedy SSO server does not find the private key to sign and cannot generate the issue id_token.
You do not provide the URL of the server issuing the id_token.

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:

Provide the URL of the server issuing the id_token in the OpenID Issuer URL field on the OAuth2 > Settings tab.
Generate the JWK from the OAuth2 > OpenID tab.

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:

An error occurred. Please contact your administrator or retry later.

The following exception is logged in the log files:
id_token is invalid. Message: id_token is issued at 'Wed Jan 30 22:46:39GMT-12:00 2019', now is 'Wed Jan 30 22:46:29 GMT-12:00 2019)

Synchronize the time on the Remedy SSO server and Remedy SSO agent machines.

Cross launch issues for applications integrated with different Remedy SSO servers

Issue	Description	Workaround
The cross launch link is not displayed. In Chrome, no text is displayed in the iframe. The following message is displayed in the developer console (F12): Refused to display '<originating_app_host>:<port>/rsso/cross-sso? goto=<target_app_host>#jwt=<jwt_value>' in a frame because an ancestor violates the following Content Security Policy directive: "frame-ancestors 'self'". The following message is displayed in Firefox: Blocked by Content Security Policy. The following message is displayed in Microsoft Internet Explorer: This content cannot be displayed in an frame. The following message is displayed in Microsoft Edge: This content can’t be shown in an frame.	The target Remedy SSO server is not configured correctly.	On the target Remedy SSO server, for the Preauth authentication method, make sure that you enter the name of the originating Remedy SSO server in the ALLOW-FROM Domain(s) field. For information about how to configure this field, see Configuring preauthentication.
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.	Enable the DEBUG log level on the target Remedy SSO server and reproduce the issue. Check the logs. The following statements might be displayed: Authentication failed. Reason: 'Could not parse certificate: java.io.IOException: java.lang.IllegalArgumentException: Input byte array has wrong 4-byte ending unit' Authentication failed. Reason: 'JWT signature does not match locally computed signature. JWT validity cannot be asserted and should not be trusted.' Configure the correct certificate for the Preauth authentication method on the target Remedy SSO server.

Remedy AR authentication issues

Issue Description Workaround

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

Check the contents of the ARSystemInstallFolder/Conf/rsso.cfg file, and verify that the value of the sso-service-url property corresponds to the Remedy SSO server URL.
Check that the sso-service-url is accessible from the AR server node.
You can use curl to test network connectivity from the AR server node to the Remedy SSO server URL.
If the connection test works, use curl go to the next step.
Check if any proxy is used on the AR System plugin server for the outgoing network connection.
- The proxy option must be defined in the Java options in armonitor.cfg. The startup string for the Java plugin server would have Java parameters for enabling proxy.
- If the proxy server is defined in the Java plugin server, force a bypass of the proxy for the Remedy SSO server host name.

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-USER-GROUPS-FIX: true

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 Installing encryption on BMC Remedy applications Open link .

To integrate Remedy SSO with Premium Encryption, see DOC-128148 Open link .

SAML authentication issues

Issue	Description	Workaround
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 https://sso.connect.pingidentity.com/sso/idp/SSO.saml2?idpid=XXX, you will not be able to log in.	Not applicable
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

Issue	Description	Workaround
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: `javax.naming.CommunicationException: simple bind failed:` `<LDAP SERVER NAME>:PORT` `[Root exception is javax.net.ssl.SSLHandshakeException:` `server certificate change is restricted during renegotiation]`	Add the Java proprerties for the JVM that Tomcat uses. `-Djdk.tls.allowUnsafeServerCertChange=true -Dsun.security.ssl.allowUnsafeRenegotiation=true` Linux example: Create or edit the TomcatInstallFolder/bin/setenv.sh file. `JAVA_OPTS="-Djdk.tls.allowUnsafeServerCertChange=true" JAVA_OPTS="$JAVA_OPTS - D sun.security.ssl.allowUnsafeRenegotiation=true" export JAVA_OPTS` Microsoft Windows example: Use the tomcatXw.exe GUI. Create a similar setenv.bat file with similar content.
LDAP authentication failure	If the LDAP server uses a self-signed certificate, the JVM that Tomcat uses on the Remedy SSO server does not trust this certificate.	To use TLS/SSL connection to the LDAP server, import the LDAP server certificates (cacerts) to the truststore (JavaHome \jre\lib\security) of the Apache Tomcat used by the Remedy SSO server. Import the certificates by using third-party utilities such as Keystore explorer.
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.

Issue	Description	Workaround
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: `amJAAS:10/18/2011 09:35:00:435 AM PDT: Thread[http 8443-1,5,main] Exception: com.sun.identity.authentication.spi.AuthLoginException: Failed to authentication. Failure unspecified at GSS-API level (Mechanism level: Specified version of key is not available (44))`	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: `The entry Authentication token is NTLM but not SPNEGO.`	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: A browser is not correctly configured to use Kerberos authentication. For information about how to configure the browser correctly, see Configuring Kerberos authentication. A service token for the Remedy SSO server was not obtained. Make sure that a Kerberos service ticket is obtained when it tries to access theRemedy SSO server on a client's machine. Click here to view more details Check that customer's computer asked for the Remedy SSO server from the key distribution center (KDC), and then issued a service ticket: `c:\Windows\system32\klist.exe ... #1> Client: dev_adei @ QA2R.LOCAL Server: HTTP/access.bmc.com @ QA2R.LOCAL KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize Start Time: 11/3/2016 9:00:43 (local) End Time: 11/3/2016 19:00:43 (local) Renew Time: 11/10/2016 9:00:43 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 ...`
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: `java.security.PrivilegedActionException: GSSException: Failure unspecified at GSS-API level (Mechanism level: Checksum failed) Caused by: GSSException: Failure unspecified at GSS-API level (Mechanism level: Checksum failed) Caused by: KrbException: Checksum failed Caused by: java.security.GeneralSecurityException: Checksum failed`	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 `HTTP/access.bmc.com@RSSO.COM`. To see content of the existing keytab file, run the `ktab` command. Click here to view the command details c:\java sun.security.krb5.internal.tools.Ktab -l -e -t -k all.keytab Keytab name: all.keytab KVNO Timestamp Principal ---- ----------------- ------------------------------------------------------------------------------------ 0 12/31/69 12:00 PM HTTP/access.bmc.com@RSSO.COM (1:DES CBC mode with CRC-32) 0 12/31/69 12:00 PM HTTP/access.bmc.com@RSSO.COM (3:DES CBC mode with MD5) 0 12/31/69 12:00 PM HTTP/access.bmc.com@RSSO.COM (23:RC4 with HMAC) 0 12/31/69 12:00 PM HTTP/access.bmc.com@RSSO.COM (18:AES256 CTS mode with HMAC SHA1-96) 0 12/31/69 12:00 PM HTTP/access.bmc.com@RSSO.COM (17:AES128 CTS mode with HMAC SHA1-96) This keytab file contains five entries for the same principal, but each entry has a different encryption type. You must use the `/crypto all` option with the `ktpass` utility to generate the keytab file.
The following error appears in the rsso.log file: `Cannot find key of appropriate type to decrypt AP REP - AES256 CTS mode with HMAC SHA1-96 (or AP REP - AES128 CTS)`		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: Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files for JRE 8 Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files for JRE 7 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.	Specify the `maxHttpHeaderSize` attribute on the HTTPS connector, and set a large enough value in bytes.

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:
```
C:\whoami
DOMAIN\userID
```
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.