If the Kerberos problem does not seem to be on the client, turn on Kerberos Service debugging. Do this by setting the debug=true option in the JAAS configuration for the KrbServiceLoginModule on
WebSphere; on WebLogic do it by setting the Debug option to true for the Kerberos Service Authentication Provider.
What follows are a few of the more common Kerberos problems. Some error messages will have a number, for example (9), that represents a standard Kerberos error code. This number can appear in either the message itself or, as is the case with WebSphere, as the minor error code for the error. Here are the problems:
"The client or server has a null key (9)"
This could indicate that the CE server has not had the
AllowTgtSessionKey_fix_for_Krb5LoginModule.reg registry patch applied. This patch is necessary on certain later service packs and versions of Windows.
"KDC has no support for encryption type (14)"
"Cannot find key of appropriate type to decrypt AP REP - RC4 with HMAC"
"Cryptographic key type rc4-hmac not found"
These errors might mean that the "identity" domain user account does not have the "Use DES encryption types for this account " option set. Another possibility is that the wrong ktab utility was used (say the Sun ktab utility was used on a WebSphere system). It can also mean on WebSphere systems that the krb5.ini file does not have these settings in the [libdefaults] section:
default_tgs_enctypes = des-cbc-md5 des-cbc-crc default_tkt_enctypes = des-cbc-md5 des-cbc-crc
"Password has expired - change password to reset (23)"
The "identity" user account's password must be changed. Also remember to run the ktab utility on the CE server to change the keytab's password if necessary.
"Pre-authentication information was invalid (24)"
The most likely error is that the user name and password in the keytab does not exactly match the user name and password of the “identity” user account given when creating the account. Notice that this match is case-sensitive for both the user name and the password. This could also mean that the keytab file was not found for the user account (in the
[email protected] form), but there should also be a "could not find user in keytab" error prior to this. There is also the possibility that the system clocks are too far out of sync, see the "Clock skew too great " error.
"Integrity check on decrypted field failed (31)"
This could mean that "identity" user account mapped to the SPN which the client used does not match the user account that the CE's KrbServiceLoginModule used. A possible reason for this is that the login module's serviceAccountName is not set to the correct mapped SPN name for a cluster.
This error can also occur on a WebSphere system if the user name in the keytab does not exactly match the user name (case-sensitive) given when the “identity” user account was created. This means that the case of the user name given in the ktab command really matters!
"Request is a replay (34)"
This request has the same Kerberos token as an earlier request. This is probably because a .NET client is reusing a KerberosToken (or KerberosToken2 ) object rather than re-constructing it for each request. If on JBoss, then this might mean that the cacheSize option's value is too small and must be increased. For the security minded, it could also mean that intruders are trying to impersonate users using a "replay attack" (but, seriously, only consider this for a production system which has been using Kerberos for a while and has all the bugs worked out).
"Clock skew too great (37)"
This error can happen if the clocks on the client machine and the CE server are more than some number of minutes apart. Commonly this is 5 minutes, but can also be 1 minute. The fix for this is to more closely synchronize the clocks on the two machines.
"The user could not be found in the keytab"
"Key for the principal FNCEWS_mycemp01@MYDOM. EXAMPLE.COM not available in default key tab"
"No Kerberos creds in keytab for principal [email protected]"
These errors could either indicate that the "identity" user (for example,
FNCEWS_mycemp01@MYDOM. EXAMPLE.COM ) was not in the keytab or that the keytab file itself could not be found. Use "ktab" by itself from the command line to list the contents of the default keytab file and check for misspellings. The keytab file is, by default, the c:\Documents and Settings\
<user> \krb5_keytab file. Where <user> is the name of the account that the application server is running as. Note that if the application server is running as a service, there will probably be no corresponding <user> directory and it is best if the keytabPath="c:/my_keytab"
KrbServiceLoginModule option is used to specify what and where the keytab is.
"Could not create default AuthorizationToken during propagation login"
This is a WebSphere error that probably means that the security mechanism is set to "SWAM" rather than "LTPA". See the notes above on setting up WebSphere on how to change this.
"Principal [email protected] not found"
This error can occur if the GCD does not have a directory configuration for the
MYDOM.EXAMPLE.COM Active Directory. In EM, right-click the name of the P8 domain and select
"Properties" from the context menu and then click Directories.
This error can also happen in a multi-domain environment if the GCD does not have the directory configuration for a client domain set up, as each client domain must individually have its directory configuration set up.
"JAAS configuration FileNetP8KerberosService not found"
This error will occur if the FileNetP8KerberosService JAAS configuration entry has not yet been configured.
"Cannot get kdc for realm MYDOM.EXAMPLE.COM"
This error can happen if the kdc= line in the CE's krb5.ini file has not been edited correctly to
reference the primary domain controller for the MYDOM.EXAMPLE.COM domain. Another possibility is that the Kerberos configuration file, krb5.ini, cannot be found by the CE as it is either not in the c:\winnt directory or the –Djava.security.krb5.conf= setting is wrong.
This can also happen in a multi-domain setup which uses external two-way trusts if the CE's krb5.ini file has not been setup to configure each client domain.
“Null key”
This error can happen on WebSphere systems if the server's SPN identity (for example,
[email protected] ) cannot be found in the CE server's currently configured keytab.
It can also happen if the keytab file itself cannot be found for some reason, such as using the default keytab, but that keytab was created by one user and the app server is running as another (a
particular problem if the app server is running as a Windows service). One fix for this is to specify the keytabPath option for the KrbServerLoginModule, for example, keytabPath="c:/config/keytab".
“Null name”
This error will occur on WebSphere systems if the identity user name used for Kerberos's identity account is longer than 20 characters. The default identity user name is derived by CE to be the string FNCEWS_ + hostname. Unfortunately this default name will be too long if hostname itself is 14 or more characters long. If this is the case, this can be fixed by using some other name for this identity user account and specifying that name in the serviceAccountName option for
KrbServiceLoginModule. For example, serviceAccountName=FN_long_hostname_123).
Another possibility, also on WebSphere servers, is that the encryption type of the key saved in the keytab does not match the encryption type used when encrypting the Kerberos ticket. One way for this to happen is if the “identity” account does not have the “Use DES encryption types for this
account” option set in the account's property dialog. (See “Step 1 - Create an Active Directory domain user account”.)
This problem might require setting the ‑Dcom.ibm.security.jgss.debug=all and
-‑Dcom.ibm.security.krb5.Krb5Debug=all properties on the JVM to diagnose as described below.
There can be many other CE server Kerberos problems. If Kerberos Service debugging is not enough to isolate the problem, try turning on additional system debugging, which will give even more
information. CE WebLogic and JBoss servers can specify the sun.security.krb5.debug property, usually on the Java command line with -Dsun.security.krb5.debug=true. This produces a lot of trace output on the JVM's console. There are two Java command line switches for CE WebSphere servers:
-Dcom.ibm.security.jgss.debug=all -Dcom.ibm.security.krb5.Krb5Debug=all
which also provide extra messages in WebSphere's log.
Authorization
When a security principal that has already been authenticated attempts to access FileNet P8 objects, Content Engine or Process Engine will attempt to retrieve that principal's user and group memberships from the directory service provider. If successful, the user or group will be authorized to carry out actions described by the access rights placed on the objects.
The topics in this section describe authorization: the various features used to manage security and apply security to objects, as well as the details of security behavior.