Skip to end of metadata
Go to start of metadata

Here errors are explained that were not covered in the blogs. Feel free to add more:

The following errors were mentioned in Configuring and troubleshooting SPNego -- Part 3:

  • NTLM token received 

  • Windows integrated authentication is not enabled

  • Clock skew too great (37)

  • Integrity check on decrypted field failed (31)

  • Acquiring credentials for realm failed

  • Wrong JDK

(Sun has released JDK 1.4.2_17 -- but it seems to have still the same bug)

  • KDC has no support for encryption type

New Problems

Length octets must contain values [0x01;0xFF]. Found 0 // Integrity check on decrypted field failed (31)) 

Single Sign On was not working in this case. From the logs you could see that a Kerberos Token was sent from the client, but then you got the error: Length octets must contain values [0x01;0xFF]. Found 0.

Further down the error CreateContext failed: GSSException: Failure unspecified at GSS-API level (Mechanism level: Integrity check on decrypted field failed (31))  was shown.

As it turned out the ServicePrincipalname (setspn -A ...) was set for a different user and not the one used during the SPNego Wizard installation. So make sure that if you run ldifde -r (serviceprincipalname=HTTP/...) you really get the user you used in the Wizard.

Service User is locked in ADS


Firewall settings: J2EE Engine is unable to connect to KDC


Firewall settings GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new ACCEPT credentials failed!)
SocketTimeOutException with attempt: 3(screenshots will follow soon) 

J2EE Engine configured with SSL (HTTPS)


Although the J2EE Engine is accessed with HTTP the setting for the ServicePrincipalname still has to be HTTP/servername (and not HTTPS/servername). If not HTTP/servername is used, then no Kerberos Ticket will be created an for the user.

IE7 - Kerberos issue

If you are using IE7 and Kerberos don't work (check it with Kerbtray) this fix may help you:

  • No labels

1 Comment

  1. We have a SSO (SPNego) NetWeaver system set up which is used for authenticating Web Services users from an external application to our SAP ECC 6.0 backend.  Its' been working like a charm, until just recently. Our web service users in ECC are configured as COMMUNICATIONS type users. As such, their passwords are in the INITIAL status (since there is no dialog logon allowed for COMMUNICATIONS users). This hasn't posed a problem until last week. The web service was failing and we finally tracked it down to an error in the SAP Java logs indicating it was waiting for a password change for this COMMUNICATIONS user. To resolve this we had to change the user type to DIALOG, log on as that user and change the password (so it was no longer INITIAL), then change the user type back to COMMUNICATIONS.  As a side note, on our identically configured development layer, the COMMUNICATIONS user was still functioning - not prompting for a password change - even though it's password was in the INITIAL status.  Do you know of a way around manually changing the passwords for all COMMUNICATIONS users using the SPNego module to authenticate to the ECC UME? Thank you!