SSO Authentication Fails

The SSO authentication feature in the RealPresence Web Suite Services Portal is provided by a separate bundle in a war package.

When the SSO authentication fails, a set of error and debug messages is written to the log file /var/log/polycom/rpp-tomcat/cloudaxis_wsp-ui.log

To troubleshoot SSO authentication issues, set the log level to Debug to capture the debug messages. In the log file, look for debug messages with the following log patterns.

Note: Debug Message Type 1
Note: KDC has no support for encryption type (14) OR

Cannot find key of appropriate type to decrypt AP REP - RC4 with HMAC OR

Cryptographic key type rc4-hmac n ot found OR

Cryptographic key type des-cbc-md5 not found OR

Cryptographic key type des-cbc-crc not found

Explanation:

These errors indicate one of the following:
  • DES security is needed, but the domain user account does not have Use DES Encryption types for this account selected.
  • RC4-HMAC security is needed, but the domain user account does have Use DES Encryption types for this account selected.
  • The wrong keytab utility was used to generate the keytab file. For example, the Sun keytab utility was used on a WebSphere system.
    Note: Debug Message Type 2
    Note: org.ietf.jgss.GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)

Explanation:

A variety of conditions could cause Kerberos authentication not to work and cause RealPresence Web Suite to fall back to NTLM.

The following include general reasons for no or invalid Kerberos service tickets being sent to the RealPresence Web Suite Services Portal server.

Issue

Solution

Duplicate SPNs

SPNs must be unique.

  • Remove all duplicate SPNs.
  • Create a new SPN for the service account and regenerate the keytab file.
  • Update the SSO configuration with the new keytab file.

The user is logged in outside of the domain

To get a Kerberos ticket, users must initiate their logins within the domain. If a user has not logged in to the domain before starting SSO authentication, they would not have a ticket to send when the adapter asks for it.

The Microsoft client must also be joined to the domain. If the client is not joined, it cannot participate in Kerberos authentication and thus the client has no choice but to fall back to using NTLM.

Incorrect Browser Configuration

The browser must be configured to trust the target server to send the credentials.

  • In Internet Explorer, the user must add the target server or its domain under Tools > Internet Options > Security > Intranet Zone. Make sure it is Intranet Zone.
  • In Internet Explorer, click Tools > Internet Options > Advanced and select Enable Integrated Windows Authentication.
  • In some browsers, Integrated Windows Authentication must also be turned on to enable automatic authentication.

Outdated Windows Login

After the SPN has been set or changed, users who use SSO need to re-enter their credentials to authenticate to the domain controller. By providing their credentials, they get a new ticket with the SPN changes.

Make sure that users log out and log back into the AD domain.

Outdated Saved Network Credentials

If a user entered credentials into a Network Password dialog box and elected to save them, the client uses those credentials, initiating NTLM rather than Kerberos.

SPN in general

If there is a problem with the SPN on the service account or domain user account that prevents the client from initiating Kerberos authentication, the client has no choice but to fall back to using NTLM.

DNS host name

Ensure that the RealPresence Web Suite Services Portal URL host name is a DNS A record host name, not a CNAME alias. When the browser requests a ticket from KDC, it always uses the DNS A record host name, regardless of the host name that appears in the browser address bar. Users can still use CNAME alias host names to access the site, but the keytab file must be created using an A record host name.

Note: Debug Message 3
Note: org.ietf.jgss.GSSException: Failure unspecified at GSS-API level (Mechanism level: Clock skew too great (37)) OR

sun.security.krb5.internal.KrbApErrException: Clock skew too great (37)

Explanation:

The times on the servers are not synchronized with the NTP service