When using a non-Internet Explorer browser, rather than presenting a username and password dialog box, the browser gives an error message indicating that the authentication mechanism is not supported.
The filter has not been configured to allow fallback authentication for non-Internet Explorer browsers.
You need to ensure that the filter is configured with the idm.allowFallback option set to true. Without this, non-Internet Explorer browsers are not supported.
Servlet/JSP configured with AuthFilter fails to start.
This is commonly caused by a configuration problem with the AuthFilter filter. You need to check your application server’s log file to determine the root cause. Possible log entries are:
ServletException: Need to set idm.realm.
The idm.realm parameter determines the Kerberos realm that will be use by the SSO solution to authenticate clients. It must be set in the deployment descriptor.
ConfigException: Only one of “idm.keytab” or “com.wedgetail.idm.sso.password” should be specified.
Only one of idm.keytab or com.wedgetail.idm.sso.password may be specified. For production systems, idm.keytab is to be preferred.
ConfigException: Must configure either idm.keytab or com.wedgetail.idm.sso.password.
The deployer must specify one or the other — with keytab preferred for production systems.
Config Exception: Must use a keytab if idm.allowFallback configured.
The idm.allowFallback parameter allows the deployer to specify whether the AuthFilter filter should allow users to authenticate using basic authentication and act as an authentication proxy to perform a Kerberos login to the key distribution center on the user's behalf. If fallback mode is enabled, then user-to-service mode must be used, and hence a keytab must be specified via the idm.keytab parameter, or the keytab password specified by the com.wedgetail.idm.sso.password system property.
ConfigException: <keytab> not found
The keytab specified by idm.keytab could not be loaded. The keytab must be at the path specified. Ensure that the file is present and that the correct path and file name is specified in the idm.keytab parameter.
ConfigException: No keytab entries for <principal>@<realm> in <keytab>
The specified keytab did not contain any keys for the principal that was configured using idm.principal and idm.realm. If idm.principal was not specified then entry will be of the form:
Where <host> is the fully qualified name of the host on which the filter is deployed.
You can use the Kerberos klist command to check the keytab entries. Under UNIX this command is supplied as part of the Kerberos distribution and under Windows is supplied with JDK 1.4. Ensure that there is an entry for the specified principal.
ConfigException: Could not load keytab “<keytab>”
The keytab could not be loaded for some reason. Possibly this was due to corruption, or an incorrectly formatted file.
ProtocolException: Could not get service ticket for principal name [caused by: com.dstc.security.kerberos.CryptoException: Integrity check failure]
The realm specified in idm.realm is case-sensitive and is usually uppercase. If the case does not match, the DES keys for the service will be incorrect, as they are derived from the fully-qualified principal name.
Filter could not be loaded: com.dstc.security.util.licensing.InvalidLicense: Error verifying license: Cannot open resource jcsi.licensing.cert.pem
The licensing code can not find a license, either because it has not been installed, or Java 2 Security has been enabled, without a suitable policy file.
Why is Internet Explorer trying to do NTLM?
Single Sign-on for Java is designed to work with Windows Integrated Authentication using Kerberos. However, if your browser or Active Directory is not configured correctly this will fail, and Internet Explorer will attempt to fallback to NTLM authentication.
If you have NTLM disabled in Single Sign-on for Java you may be presented with a username/ password dialog, and you will see the following message in the error log:
Could not authorize request: com.wedgetail.idm.sso.NtlmNegotiatedException
Generally, fallback to NTLM will occur for one of the following reasons:
One way to test whether it is either of the latter two possibilities is to install a packet sniffer. One Identity recommends Wireshark (http://www.wireshark.org). If SPN mapping for Single Sign-on for Java is not correct, Wireshark should provide the following output:
HTTPresponse 401 Unauthorized
KRB_AP_REP (Indicating a Kerberos Error)
HTTP request with the broken negotiate header.
If you are certain the SPN has been correctly set up, send the Wireshark trace to https://support.oneidentity.com/ and one of our experienced support engineers will assist you in identifying the problem.
If your browser has not been configured correctly as explained above, no Kerberos traffic will be visible in the Wireshark trace.
When using a keytab I get Could not verify PAC in auth data
When generating a keytab using ktpass the default key type is DES-CBC-CRC. There is a known problem using these types of keys.
You must specify -crypto DES-CBC-MD5 when generating the keytab.
I am getting a No keytab entry for decrypting. Data encrypted with key type 23... message.
This error is caused when the keytab used contains only DES keys but the account is not set to Use DES only.
This can be fixed by either adding an RC4 key to the keytab, or setting the user account to Use DES only.
When attempting to connect to a URL protected by the filter you receive an error message: 403 Forbidden This Connection Must be secured.
By default, Single Sign-on for Java requires that communications be performed securely (for example using HTTPS).
There are two reasons for this:
One Identity strongly recommends using SSL to secure communications for these reasons. However, should you wish to use the SSO solution to authenticate clients over unprotected connections (for example, for testing, or where there is a very low risk of attackers hijacking sessions), you may set the idm.allowUnsecured option to true.