If you have trouble accessing the Windows Desktop SSO Authentication module, first inspect the debug log files amAuthWindowsDesktopSSO or amAuth file. Errors or exceptions that users may encounter when Windows Desktop SSO Authentication doesn't work properly include the following:
The problem occurs when you try to access Windows Desktop SSO Authentication module directly. Example URL: http://openSSOhost.domain/UI/Login?module=WinSSO. An “Unauthorized Access” message is displayed. The message may also indicate that “The Kerberos token is not valid.” The following is displayed in the server-side debug log amAuthWindowsDesktopSSO:
06/20/2007 11:06:03:974 AM PDT: Thread[WebContainer : 1,5,main] WindowsDesktopSSO params: principal: HTTP/veet.red.iplanet.com@RED.IPLANET.COM keytab file:///tmp/keytab/veet.HTTP.keytab realm : RED.IPLANET.COM kdc server: cerberus.red.iplanet.com domain principal: false auth level: 0 06/20/2007 11:06:03:977 AM PDT: Thread[WebContainer : 1,5,main] Retrieved config params from cache. 06/20/2007 11:06:04:000 AM PDT: Thread[WebContainer : 1,5,main] SPNEGO token: 4e 54 4c 4d 53 53 50 00 01 00 00 00 07 82 08 a2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05 01 28 0a 00 00 00 0f 06/20/2007 11:06:04:000 AM PDT: Thread[WebContainer : 1,5,main] token tag:4e 06/20/2007 11:06:04:006 AM PDT: Thread[WebContainer : 1,5,main] kerberos token is not valid. |
Be sure that the browser is configured correctly.
Be sure that your XP domain login has the Kerberos ticket from the Kerberos Domain Controller.
When attempting the log in, the message “LoginException: Unable to obtain password from user” is displayed. The following is displayed in the server-side debug log amAuthWindowsDesktopSSO:
06/20/2007 01:08:08:614 PM PDT: Thread[service-j2ee,5,main] ERROR: Service Login Error: 06/20/2007 01:08:08:614 PM PDT: Thread[service-j2ee,5,main] Stack trace: javax.security.auth.login.LoginException: Unable to obtain password from user at com.sun.security.auth.module. Krb5LoginModule.promptForPass(Krb5LoginM odule.java:745) at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication (Kr b5LoginModule.java:624) at com.sun.security.auth.module. Krb5LoginModule.login(Krb5LoginModule.ja va:512) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ..... |
Be sure the appropriate cryptosystem is being used for generating the keytab file.
Be sure the appropriate version of Java is configured for the OpenSSO Enterprise server.
Be sure the configured service principal is identical to the principal in the keytab file. You can use klist command view the keytab file information.
The following is displayed in the server-side debug log amAuthWindowsDesktopSSO :
ERROR: Service Login Error: 06/20/2007 02:04:33:181 PM PDT: Thread[service-j2ee,5,main] Stack trace: javax.security.auth.login.LoginException: Clock skew too great (37) at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication (Kr b5LoginModule.java:696) at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.ja va:542) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769) at javax.security.auth.login.LoginContext.access$000(LoginContext.java:1 86) |
Be sure that the clocks of OpenSSO Enterprise server host and the Kerberos or Active Directory Domain Controller host are synchronized properly.
The following will be display in the server-side debug log amAuthWindowsDesktopSSO :
ERROR: Service Login Error: 06/20/2007 04:42:16:265 PM PDT: Thread[service-j2ee,5,main]Stack trace: javax.security.auth.login.LoginException: kdc.red.iplanet.com: kdc.red.iplanet.com at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication (Krb5LoginModule.java:700) at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:542) |
Be sure the Kerberos Server Name is configured using the FQDN for the Kerberos Domain Controller host. Use the ping command to verify that the Kerberos Domain Controller host is accessible from the OpenSSO host.
The following will be displayed in the server-side debug log amAuthWindowsDesktopSSO :
ERROR: Service Login Error: 02/24/2009 11:17:37:212 PM JST: Thread[service-j2ee-1,5,main] Stack trace: javax.security.auth.login.LoginException: Client not found in Kerberos database (6) at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.jav a:696) at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:542) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) |
Test the keytab file with kinit command. The keytab file may have been generated or mapped improperly.
The following is displayed in the server-side debug log amAuth:
09/14/2005 05:41:58:182 PM SGT: Thread[service-j2ee-3,5,main]Exception com.sun.identity.authentication.spi.AuthLoginException(1):null com.sun.identity.authentication.spi.AuthLoginException(2):null java.security.PrivilegedActionException(3):null java.security.PrivilegedActionException: GSSException: Failure unspecified at GSS-API level (Mechanism level: Integrity check on decrypted field failed(31)) at java.security.AccessController.doPrivileged(NativeMethod) at javax.security.auth.Subject.doAs(Subject.java:396) at com.sun.identity.authentication.modules.windowsdesktopsso.WindowsDesktopSSO.process (WindowsDesktopSSO.java:156) at com.sun.identity.authentication.spi.AMLoginModule.wrapProcess (AMLoginModule.java:723) at com.sun.identity.authentication.spi.AMLoginModule.login(AMLoginModule.java:871) at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethod) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.sun.identity.authentication.jaas.LoginContext.invoke(LoginContext.java:215) |
JDK1.5_08 and higher support RC4-HMAC, and earlier JDK versions support 3DES and DES enctypes only. Be sure to select +DesOnly encryption for mapping the account with the service principal in the Windows Kerberos Domain Controller. Also, be sure to use DES-CBC-CRC or DES-CBC-MD5 for cryptosystem when generating the service principal keytab file
Be sure the appropriate crypto system is used for generating keytab file. Be sure the appropriate version of Java is configured for OpenSSO Server.
Java may not be handling the Kerberospre-auth correctly. This can occur if the principal name does not match what is stored in Active Directory, and what the principal name was when the password was last changed. This mismatch is not a problem for Active Directory, but it is a problem for Kerberos or a renamed account where the password has not been changed. Java 1.6 is reported to have a fix for this problem. The fix will accept the pre-authentication hint from the Kerberos Domain Controller as to what "salt" to use when doing the string to key function. The "salt" is derived from the principal name at the time the password was changed. Older Java versions assumed they know the salt and tried to skip the first step in the pre-authentication.
See the information at the end of the procedure To Configure the OpenSSO Enterprise Windows Desktop SSO Authentication Module about using IBM WebSphere.
The following message is displayed in the server-side debug log amAuthWindowsDesktopSSO :
06/20/2007 03:49:20:704 PM PDT: Thread[service-j2ee,5,main] WindowsDesktopSSO params: principal: HTTP/am-v1280-01.red.iplanet.com@RED.IPLANET.COM keytab file: /tmp/keytab/wsso.HTTP.keytab realm : RED.IPLANET.COM kdc server: cerberus.red.iplanet.com domain principal: false auth level: 0 06/20/2007 03:49:20:704 PM PDT: Thread[service-j2ee,5,main] Init WindowsDesktopSSO. |
This should not happen often. Be sure the keytab file uses the same filename and directory as specified in the user account.
Kerberos Authentication is successful, but OpenSSO Enterprise cannot find the user profile. This is a configuration issue. Be sure the user exists in the user repository.
The Windows Desktop SSO Authentication module worked fine. Then it stopped working after the OpenSSO Enterprise server was configured as a server in a site configuration with a load balancer. .
The following message trace is displayed in the server-side debug log amAuthWindowsDesktopSSO:
...... 02 a6 ff 1d 1c 3c e2 dc d4 89 66 b0 70 dd 6b b0 c1 a4 69 bd 29 29 54 05 04 e8 75 06/25/2007 09:13:56:559 AM PDT: Thread[service-j2ee,5,main] In authenticationToken ... 06/25/2007 09:13:56:561 AM PDT: Thread[service-j2ee,5,main] Context created. 06/25/2007 09:13:56:565 AM PDT: Thread[service-j2ee,5,main] Authentication failed with GSSException. |
You will also see a bigger Kerberos token than a normal token. Be sure the defined principal for the OpenSSO Enterprise server has load balancer fully-qualified domain name (FQDN). Example: HTTP/amlb. openSSOhost.example.com.