This documentation supports the 20.08 version of Remedy Single Sign-On, which is available only to BMC Helix subscribers (SaaS).

To view an earlier version, select the version from the Product version menu.

Troubleshooting authentication issues

Generic authentication issues

IssueDescriptionWorkaround

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 "*".

Unauthorized_client

issue during the authentication flow

A user receives the following message during the authentication flow:

{"state":"f91a20a1-3409-4fc8-bcaf-a21be1bd668e","error":"unauthorized_client"}

The state value is an example and can vary for different cases.

In most cases, the issue is related to the incorrect redirect URI in the /authorize request. The following steps are required:

  1. Compare the redirect_uri query parameter in the end-user request query with the redirect URI specified for the particular OAuth client in the Remedy SSO Admin Console.
    The client_id can be found in the same end-user request query. Make sure that the redirect URI you are looking for in the Remedy SSO Admin Console corresponds to the proper client_id.
  2. Add the missing redirect URI to the OAuth client in the Remedy SSO Admin Console.
  3. Reinitiate the login flow.

Authentication issues for applications hosted on different domains

IssueDescriptionWorkaround

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

IssueDescriptionWorkaround

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.

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.

  1. Enable the DEBUG log level on the target Remedy SSO server and reproduce the issue.
  2. 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.'

  3. Configure the correct certificate for the Preauth authentication method on the target Remedy SSO server.

Remedy AR authentication issues

IssueDescriptionWorkaround

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

  1. 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.
  2. 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.
  3. Check if any proxy is used on the AR System plug-in 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 available 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 Encryption Premium is enabled on AR System Server

After installing Encryption Premium or Performance security is installed 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 Encryption Premium , see DOC-128148 Open link .

AR 623 error during authentication

Various issues can cause this error. Use the steps in the workaround to identify and fix any issues that you find. This troubleshooting can be applied only if Remedy SSO is integrated with Remedy AR System. For all other cases, see Troubleshooting Open link in the Remedy AR System documentation.

Confirm that the integration of Remedy SSO with the Remedy AR System is configured correctly :

  1. In the AREA settings (<AR>/Conf/ar.cfg) (or in the AR System Administration Console, click System > General > Server Information > EA), you must have the following attribute values:
  • External-Authentication-RPC-Socket: 390695
  • Authentication-Chaining-Mode: 1
  • Crossref-Blank-Password: T

2. Ensure that the rsso.cfg file exists in <AR>/Conf.

3. Ensure that the following URL leads to the correct Remedy SSO server service URL:

SSO-SERVICE-URL: <rsso_service_url>

4. Ensure that the following files exist in <AR>/pluginsvr:

  • rsso-area-plugin-all.jar
  • gson-2.3.1.jar
  • slf4j-api-1.7.25.jar

5. Ensure that the following entries exist in <AR>/pluginsvr/pluginsvr_config.xml:

<plugin>

<name>ARSYS.AREA.RSSO</name>  <classname>com.bmc.rsso.plugin.area.RSSOPlugin</classname>

<pathelement type="location"><AR>/pluginsvr/rsso-area-plugin-all.jar</pathelement>

<pathelement type="location"><AR>/pluginsvr/gson-2.3.1.jar</pathelement>

<pathelement type="location"><AR>/pluginsvr/slf4j-api-1.7.25.jar</pathelement>

<userDefined>

<configFile>{AR}/Conf/rsso.cfg</configFile>

</userDefined>

</plugin>

Ensure that the Operating-Mode parameter in the ar.cfg file is set to 0. To make the applied parameter live, restart the AR server.

Ensure that the following alias entry exists in the ar.cfg file:

Server-Plugin-Alias: AREA AREA <servername>:9999

It it is missing, add the entry and restart the AR server.

There might be a handshake issue between the AR and Remedy SSO servers.

Note

To confirm that this issue is related to the certificate, disable SSL and TLS checks. To do so, in the rsso.cfg file, set the following parameter to true:

com.bmc.rsso.tls.disable.checks: true

If the issue is caused by the certificate, import the Remedy SSO root certificate into the Java cacerts file on the AR server.

You see the following error that identifies an incorrect password for the AR server in the Mid Tier configuration tool:

ERROR (623): Authentication failed; MidTier Service

You can update the password by going to AR Server Settings > Edit AR Server. To validate the password, select the Validate Password check box.

A user name received from the IdP might not match with the user name in the AR Server's User form. To see the user name, go to the Session tab. If the two user names do not match, you should create a transformation in the Remedy SSO Admin Console.

Example:

If LDAP sends the user name as user@bmc.com but in the AR Server's User form, the user name is specified as user, you should create a transformation to remove the email domain.

The 623 error can be displayed if the AR Java plug-in is not initialized or not working. To ensure that the AR Java plug-in is working:

  • To check that the AR Java plug-in is running, initiate the following command:
    netstat -an | findstr "ar_plugin_port"
  • In Task Manager, add the Command line column and check the AR Java plug-in process.
    If the Java process with \pluginsvr; is not displayed, the AR Java plug-in is not initialized.
  • In the ARSystem/db folder, open the arjavaplugin.log file to see if there are any errors related to Remedy SSO.
    If details of the login failure are not displayed in the logs, enable the debug level logging for the AR Java plug-in and restart the plug-in. Then, log in again to the BMC application to see more details.
    To enable the debug level logging for the AR Java plug-in, see the BMC Communities KA Open link .

SAML authentication issues

IssueDescriptionWorkaround

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 as an encrypted string

Some IdPs might encrypt the NameID if the length of the NameId column in the IssuesToken table is too short.

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).

SAML authentication fails

The following error is displayed:

***Failed to validate notBefore condition***
            ***Failed to process SAML message, cause: conditions validation error***

The issue is caused by the absence of a time sync between Remedy SSO and the IdP server. In the Remedy SSO Admin Console, configure the Assertion Time Skew attribute; see Importing configuration from an identity provider and configuring SAML.

Fail to generate and view SP metadata in Remedy SSO

When you generate or view SP metadata in Remedy SSO, the following error is displayed:

Metadata is incomplete. Following attributes are missed or empty: [SP certificate]

SP certification configuration is missing or incorrect. Follow the steps:

  1. Configure an SP certificate as described in Creating and updating the SP signing certificate for SAML authentication.
  2. Run the keytool command (keytool -list -keystore <path to the keystore file> -storepass <keystore password>) or a certificate tool such as Keystore Explorer to identify the key alias. 
    The key alias configured in the Remedy SSO SP certificate configuration must match the key alias in the keystore.
Fail to process a SAML message related to relayState

Users cannot log in to BMC applications through SAML with the following error:

no relayState found

An incorrect client application URL (relayState) might be provided. These URLs are stored in the Remedy SSO database table "RelayState" and should be the same as the requested ones. You can also verify that the browser shortcut to the client application URL is correct.

Fail to process a SAML message related to a signature

Users cannot log in to BMC applications through SAML with the following error:

invalid Signature

An IdP certificate configured in the Remedy SSO Admin Console might be invalid or expired. Obtain an updated IdP metadata URL from the SAML team of the organization and import it into the Remedy SSO configuration. For more information, see Importing configuration from an identity provider and configuring SAML.

Log in to the BMC application through Remedy SSO fails with the configured SAML authentication

Users cannot log in to the BMC application that has been configured to use Azure Active Directory for identity management by using SAML. The following message is displayed:

Error - AADSTS75011 Authentication method by which the user authenticated with the service doesn't match requested authentication method AuthnContextClassRef

In the Remedy SSO Admin Console, remove the saml:AuthNContextClassRef value from the SAML configuration. For more information, see Troubleshoot sign-on to SAML-based SSO apps in Microsoft Open link .

LDAP authentication issues

IssueDescriptionWorkaround
LDAP authentication failure

When you use 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 properties 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:

    1. Use the tomcatXw.exe GUI.
    2. Create a setenv.bat file with the content similar to the Linux 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.

To use TLS/SSL connection to the LDAP server, import the LDAP server certificates (cacertsto 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 Open link .

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.

LDAP test connection fails

In the Remedy SSO Admin Console, when you configure LDAP and click Test, the following message is displayed: Connection to the LDAP server failed or the host name or port number is incorrect.

The test connection failure can be caused by the incorrect attributes in the LDAP authentication window.

First, in the Remedy SSO Admin Console, check the following attributes:

  • Server Host(s)—The host name of your directory server, for example, ad.bmc.com, ldap.bmc.com, opends.bmc.com.
  • Server Port—The port that your directory listens on, for example, 389, 10389, 636 (for example, the SSL port that your directory listens on).
  • Use TLS connection—This check box should be selected if the connection to the directory server is an SSL connection.
    To use this setting, you also need to configure an SSL certificate.
  • Bind DN—The distinguished name of the user that the application leverages when connecting to the directory server; for example, cn=administrator,cn=users,dc=ad,dc=bmc,dc=com; cn=user,dc=domain,dc=com; user@domain.com.
    To connect to LDAP, the user must have the "Bind" and "Read" privileges.
  • Bind Password—The password of the user specified in the Bind DN field.
    The password cannot be one-way hashed. It must be recoverable in the context of the application.

If the test connection still fails, use LDAP administration tools such as LDAP Admin for Windows or JXplorer for Linux to identify whether the issue is caused by Remedy SSO or your LDAP connection.

LDAP Admin example:

  1. Click Start > Connect > Create New Connection.
  2. In the Connection name field, specify a descriptive connection name.
  3. Click Admin, and configure the following attributes:
  • Host—Specify the name of the LDAP server.
  • Port—Specify the default LDAP port is 389.

4. (Optional) If the LDAP server uses an SSL certificate, the port number changes to 636. In this case, you must select the SSL check box.

5. Clear the Anonymous connection check box.

6. In the Username field, specify a user name or an LDAP bind user format name.

7. In the Password field, specify the password for the user.

8. Click Test connection.

If the test connection is successful, click Fetch DNs and see a list of DNs on the LDAP server.

If the test connection fails with the following messages, contact the LDAP Administrator:

  • Exception Security Context—The user name or password is incorrect.
  • LDAP Server Down—The hostname is incorrect or you cannot reach the LDAP server from your location.

Fail enable LDAP over SSLUsers cannot set up an LDAP SSL certificate.

To enable LDAPS:

  1. If the LDAP team does not have such a certificate, install a certificate that meets the documented requirements; see the Requirements for an LDAPS certificate paragraph in How to enable LDAP over SSL with a third-party certification authority Open link .
  2. Import the LDAP certificate into the Java keystore file of the Remedy SSO server by running the following command: keytool -importcert -v -keystore "<path-to-jre>\lib\security\cacerts" -file "<path-to-ldap-cert-file>"
  3. Enter the password.
    This Java keystore file should be the one that runs the Tomcat service for Remedy SSO. To find out which Java keystore file serves the Remedy SSO Tomcat on Windows, run tomcat.exe depending on which Tomcat version you use, and under the Java tab, see the path. For Linux, run ps ef | grep tomcat.

4. (Windows) In the Java Options field, specify the Java truststore parameters, for example:

-Djavax.net.ssl.trustStore=<path to jre cacerts> 
-Djavax.net.ssl.trustStorePassword=changeit 

5. (Linux) Go to the sh Tomcat startup file and specify the Java truststore parameters, for example:

set JAVA_OPTS="-Djavax.net.ssl.trustStore=<path to jre_keystore" "-Djavax.net.ssl.trustStorePassword=changeit"  

6. Save the configuration.

7. Restart the Tomcat service.

8. In the Remedy SSO Admin Console, test the LDAP connection by using the server port 686 and selecting the Use TLS connection check box.

Login to Remedy Mid Tier, Remedy with Smart IT and BMC Digital Workplace fails.

Users cannot log in to Remedy Mid Tier, Remedy with Smart IT and BMC Digital Workplace.

There are multiple factors that can cause this problem. On the Remedy SSO side, you can use the two paths:

  • Check whether the LDAP users are already present in the CTM:People form.
    In the Remedy SSO logs, you can see the following message:
    ERROR: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C09042F, comment: AcceptSecurityContext error, data 52e, v2580
    This error indicates an issue with the user account that is used to connect to the LDAP server. The account can be locked out, requires a password change, or the password is incorrect.
  • Check one of the Remedy SSO server logs: "rsso.log" or "rsso.0.log". The UserID must not be "None" and LDAP must send the correct user name (the same as the Login name in the CTM:People form of AR user forms).

Login to BMC TrueSight Operations Management (BMC TrueSight Presentation Server, BMC TrueSight Capacity Optimization, BMC TrueSight Infrastructure Management, TrueSight Orchestration Platform) fails.

Users cannot log in to BMC TrueSight Operations Management (BMC TrueSight Presentation Server, BMC TrueSight Capacity Optimization, BMC TrueSight Infrastructure Management, TrueSight Orchestration Platform).

If you log in to one of these BMC products and see the error "You are not authorized to use this system", the user does not belong to any group that has correct login permissions.

To check it on the Remedy SSO side, in the Remedy SSO Admin Console, click the Session tab.

If the userID is listed, but disappears in 10 seconds. Remedy SSO has successfully authenticated the user with LDAP, but BMC TrueSight Operations Management has not given the user a group permission.

You must check whether the users and groups belong to the Authorization Profile in BMC TrueSight Presentation Server:

  1. Log in to BMC TrueSight Presentation Server as a default admin user.
  2. Go to Administration > Authorization Profiles.
  3. Create a new authorization profile by clicking the vertical ellipsis next to the Authorization Profiles field.
  4. In the Authorization Profile Name field, specify the authorization profile name.
  5. Click User Groups > Add.

Remedy SSO connects to LDAP to fetch the groups from the LDAP server and the local Remedy SSO User Management Groups (Roles).

After the group has been added to the profile, you must assign roles to this group:

  1. Click Roles > Add.
  2. In the Search for Roles window, select the roles that you want to add for the profile.
  3. Click OK.
    Depending on the roles you have given to the authorization profiles, you might also need to add objects.

If you log in to BMC TrueSight Operations Management as an LDAP user, Remedy SSO authenticates you and then BMC TrueSight Operations Management authorizes you. Any other LDAP users that belong to this group can also log in to BMC TrueSight Operations Management.

No groups or users are retrieved by TrueSight Presentation ServerYou cannot see any groups or users in the TrueSight Presentation Server Console.

In the Remedy SSO Admin Console, check that the attributes in the LDAP authentication window are correct and the Enable Group Retrieval check box is selected.

The external LDAP attributes are mapped to the Remedy SSO fields:

  • User Attributes are mapped to the User Authentication tab in Remedy SSO.
  • Group Attributes are mapped to the Group Support tab in Remedy SSO.
  • Connection Settings are mapped to the LDAP connection settings in the Remedy SSO Admin Console (Host, Port, Bind DN, Bind Password, Users Base DN, Identity Attribute).

If the issue persists, use the filters in the LDAP administration tool such as LDAP Admin to see how many results you have. If the list is lengthy, narrow down the search to see the groups.

Multiple entries are returned for a user

The LDAP server returns more than one entry for one user with an error in the Remedy SSO logs:

04-03-20 10:23:57.069 [3-exec-249] WARN  com.bmc.rsso.data.idps.IdPLDAP.getUserGroups()  : LDAP error: 'LDAP server returned more than one entry for user: userxxxx'
com.bmc.rsso.core.ldap.LDAPConfigurationException: LDAP server returned more than one entry for user: userxxxx
    at com.bmc.rsso.core.ldap.LDAPHelper.searchUserEntry(LDAPHelper.java:103)
    at com.bmc.rsso.core.ldap.LDAPHelper.getGroupsByUser(LDAPHelper.java:173)
    at com.bmc.rsso.data.idps.IdPLDAP.getUserGroups(IdPLDAP.java:298)
    at com.bmc.rsso.servlet.rest.admin.GroupsForUserResource$1.doWithNode(GroupsForUserResource.java:63)
    at com.bmc.rsso.servlet.rest.admin.IdpsToJson.convert(IdpsToJson.java:35)
    at com.bmc.rsso.servlet.rest.admin.GroupsForUserResource.getUserGroupsForUser(GroupsForUserResource.java:65)
    at sun.reflect.GeneratedMethodAccessor123.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)

It is a LDAP configuration issue. In the Remedy SSO Admin Console, in the User Authentication tab for LDAP, compare the default filter parameters against their values and correct any that do not match. The (sAMAccountName=$USER$) parameter must be specified.

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.
IssueDescriptionWorkaround

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.

    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.

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 Open link
  • Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files for JRE 7 Open link

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

  1. To ensure that customer's machine has joined the domain and the domain user is used, run the following command:

    C:\whoami
    DOMAIN\userID
  2. 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.
  3. Ensure that the Remedy SSO server is configured to use the same domain that your machine has joined.
  4. 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.
  5. Ensure that you have obtained the Kerberos ticket-granting ticket (TGT).
  6. Ensure that the browser is configured properly, see Configuring browser settings for Kerberos authentication.
  7. Ensure that the KDC domain is defined in uppercase in the Remedy SSO Admin Console.
  8. Ensure that the time difference between the KDC and your machine is no more than 5 minutes.
  9. 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.

Was this page helpful? Yes No Submitting... Thank you

Comments