This isn't a post about a bug or a problem, but rather things I've encountered that may help others when deploying SPNEGO or kerberos in general. It's such a pain in the butt when I've encountered these errors, and had to search through tons of sites. Hopefully this should help others who'd want to deploy SPNEGO or kerberos authentication in general.
Keytab generation:
To generate a keytab for Windows XP use the following command:
ktpass /princ HTTP/YOURCOMPUTERNAMEHERE@YOURDOMAINHERE.COM /mapuser YOURUSERHERE /pass YOURPASSWORDHERE /Target YOURDOMAINHERE.COM /out YOURKEYTABFILENAMEHERE.keytab /kvno 0 /crypto RC4-HMAC-NT /ptype KRB5_NT_PRINCIPAL
Parameter breakdown:
* /princ - The SPN to register, e.g. HTTP/MEDUSA@LOCAL.COM
* /mapuser - To map the SPN to a specific user (almost like setspn but not quite)
* /pass - The password of the user (I haven't figured out how to use the rndPass properly)
* /Target - Just to be sure that we're pointing to the domain we would want
* /out - The filename or filename and path of the keytab file
* /kvno - The KV version, I think it's a known bug with JRE's above 1.6 b18. You'd need to set this to zero or it wouldn't seem to read the keytab ( http://bugs.sun.com/view_bug.do?bug_id=6984764 ), I haven't tried any other version number though.
* /crypto - How the keytab would encrypt the data for this principal (RC4-HMAC-NT for XP, AES256-SHA1 for Windows 7)
* /ptype - The type of the principal KRB5_NT_PRINCIPAL means that this is a user account (just like the account I created on the AD)
When your server is deployed on Windows 7/2008, and you have XP clients you need to have AES256 and RC4 user details on the keytab. Java would automatically pick-up the appropriate keytab detail within the file, given that the principal name needs to be the same.
For generating a keytab on Windows 7 with XP clients use:
ktpass /princ HTTP/YOURCOMPUTERNAMEHERE@YOURDOMAINHERE.COM /mapuser YOURUSERHERE /pass YOURPASSWORDHERE /Target YOURDOMAINHERE.COM /out YOURKEYTABFILENAMEHERE.keytab /kvno 0 /crypto RC4-HMAC-NT /ptype KRB5_NT_PRINCIPAL
ktpass /princ HTTP/YOURCOMPUTERNAMEHERE@YOURDOMAINHERE.COM /mapuser YOURUSERHERE /pass YOURPASSWORDHERE /Target YOURDOMAINHERE.COM /in YOURKEYTABFILENAMEHERE.keytab /out YOURKEYTABFILENAMEHERE.keytab /kvno 0 /crypto AES256-SHA1 /ptype KRB5_NT_PRINCIPAL
The /in parameter was specified on the second call in order to append to the existing keytab instead of overwriting it completely.
Kerberos configuration:
The default encryption types are:
arcfour-hmac-md5 - This is the default for Windows XP systems
aes256-cts-hmac-sha1-96 - This is the default for Windows 7 systems (you'd need to apply the unlimited encryption patch to the jre to use this)
Kerberos errors
1. Invalid argument (400) - Cannot find key of appropriate type to decrypt AP REP - AES256 CTS mode
This means that the keytab you have does not contain the proper encryption of the hashed password. Specify the /crypto parameter when using ktpass.exe.
2. Failure unspecified at GSS-API level (Mechanism level: Checksum failed)
- Either it's an incorrect password, or
- Might be that the SPN wasn't registered properly, or there are duplicate SPN's registered.
This would output a text file at C:\upn_out.txt which would indicate to which users the specified SPN is registered to. The guaranteed way to remove association is by deleting the user ("setspn -D" somehow doesn't remove this association).
*For some unknown reason, the setspn -L command might show registered spn's but running the command above would display nothing.
After making sure that there's only one SPN associated to one user, you'd need to restart your http server too.
3. Client not found in database
The SPN you're using wasn't registered properly, use ktpass with the /mapuser parameter.
4. Unable to obtain password from user
Your keytab doesn't have the user name (principal attribute on the configuration) specified on your login.conf, or JAAS login configuration. You can open the keytab file through notepad to verify the name in the keytab (the name is stored in plaintext).
This can happen too when you specified the incorrect crypto option on the generation of the keytab (e.g. using AES256 only on Windows XP/2003).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I share your frustration. What made this project appealing to me was the simplicity of some of the steps as opposed to how complicated they were in some of the other implementations.
Generating the keytab using KTAB instead of ktpass was one of those steps. It is much simpler syntax and doesn't reset the password, as some versions of ktpass appear to do.
setspn -s adds the specified SPN after verifying that no duplicates exist. Usage: setspn –s <SPN accountname>.
With JBOSS, it seems important that the KVNO in the keytab matches the ms-KeyVersionNumber that will be visible using the ADSIEdit.msc utility. This number is incremented on the AD side each time the password is changed and incremented in the Keytab each time it is created with ktab -a <SPN accountname> -k<keytab file name>. It will set it at 1 if the file doesn't already exist and increment it if the file exists.
The real frustrating one for me was the size of the credential. When deploying in an environment with a large number of AD group memberships, the size of the user's credential will exceed Tomcat's maxHttpHeaderSize. https://sourceforge.net/projects/spnego/forums/forum/1003769/topic/3699577?message=8383434. Other than the 400 - Bad Request, this error doesn't seem to get reported directly. It was a real mystery why SPNEGO worked out of the box in some environments and failed in others.
Hope these posts help keep a bit more hair on the heads of people trying to use it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What I like about ktpass is that the setspn command could be skipped and I could set a random password with it. What I haven't figured out with it is how to setup using the random password setting and then generating a second entry on the keytab with the same password. As I need to support Windows 7 and Windows XP environments, and the server application would most likely be deployed on a Server 2008 instance.
I haven't tried ktab yet, but that might help me skip the whole setting of the kvno parameter for ktpass.
Then there's the odd behavior that I get with setspn, sometimes I'm able to make it work, sometimes it simply chunks out "checksum failed". Going through ktpass' mapuser parameter has gotten me more consistent successful results, but I am willing to try other methods.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- The mapuser parameter is not required in ktpass. What this actually does is replace the user logon name with the principal value specified, and then call on the setspn.
The same desired effect could be achieved by following the instructions already on the main page. That is creating the keytab wherein the /princ value is the username@REALM.COM. You'd have a warning about no mapping to user taking place, but this should be fine.
Call on the setspn with the HTTP/computername.REALM.COM and HTTP/computername, register it to the created user.
- Do not set the Password Never Expires option on your client accounts used for desktop logon
For some reason, the computer you're logging onto may or may not actually connect into the domain. There were times when we were getting NTLM requests instead of Kerberos requests, indicating that it didn't log into the domain correctly.
- After installing another instance of Windows 7, it now defaults the keytab to RC4-HMAC instead of the AES256. I'm not yet sure why our old Windows 7 instances were throwing AES256 tokens instead of the regular RC4. (We weren't using AES in the domain for any of the user accounts).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This isn't a post about a bug or a problem, but rather things I've encountered that may help others when deploying SPNEGO or kerberos in general. It's such a pain in the butt when I've encountered these errors, and had to search through tons of sites. Hopefully this should help others who'd want to deploy SPNEGO or kerberos authentication in general.
Keytab generation:
To generate a keytab for Windows XP use the following command:
ktpass /princ HTTP/YOURCOMPUTERNAMEHERE@YOURDOMAINHERE.COM /mapuser YOURUSERHERE /pass YOURPASSWORDHERE /Target YOURDOMAINHERE.COM /out YOURKEYTABFILENAMEHERE.keytab /kvno 0 /crypto RC4-HMAC-NT /ptype KRB5_NT_PRINCIPAL
Parameter breakdown:
* /princ - The SPN to register, e.g. HTTP/MEDUSA@LOCAL.COM
* /mapuser - To map the SPN to a specific user (almost like setspn but not quite)
* /pass - The password of the user (I haven't figured out how to use the rndPass properly)
* /Target - Just to be sure that we're pointing to the domain we would want
* /out - The filename or filename and path of the keytab file
* /kvno - The KV version, I think it's a known bug with JRE's above 1.6 b18. You'd need to set this to zero or it wouldn't seem to read the keytab ( http://bugs.sun.com/view_bug.do?bug_id=6984764 ), I haven't tried any other version number though.
* /crypto - How the keytab would encrypt the data for this principal (RC4-HMAC-NT for XP, AES256-SHA1 for Windows 7)
* /ptype - The type of the principal KRB5_NT_PRINCIPAL means that this is a user account (just like the account I created on the AD)
When your server is deployed on Windows 7/2008, and you have XP clients you need to have AES256 and RC4 user details on the keytab. Java would automatically pick-up the appropriate keytab detail within the file, given that the principal name needs to be the same.
For generating a keytab on Windows 7 with XP clients use:
ktpass /princ HTTP/YOURCOMPUTERNAMEHERE@YOURDOMAINHERE.COM /mapuser YOURUSERHERE /pass YOURPASSWORDHERE /Target YOURDOMAINHERE.COM /out YOURKEYTABFILENAMEHERE.keytab /kvno 0 /crypto RC4-HMAC-NT /ptype KRB5_NT_PRINCIPAL
ktpass /princ HTTP/YOURCOMPUTERNAMEHERE@YOURDOMAINHERE.COM /mapuser YOURUSERHERE /pass YOURPASSWORDHERE /Target YOURDOMAINHERE.COM /in YOURKEYTABFILENAMEHERE.keytab /out YOURKEYTABFILENAMEHERE.keytab /kvno 0 /crypto AES256-SHA1 /ptype KRB5_NT_PRINCIPAL
The /in parameter was specified on the second call in order to append to the existing keytab instead of overwriting it completely.
Kerberos configuration:
The default encryption types are:
arcfour-hmac-md5 - This is the default for Windows XP systems
aes256-cts-hmac-sha1-96 - This is the default for Windows 7 systems (you'd need to apply the unlimited encryption patch to the jre to use this)
Kerberos errors
1. Invalid argument (400) - Cannot find key of appropriate type to decrypt AP REP - AES256 CTS mode
This means that the keytab you have does not contain the proper encryption of the hashed password. Specify the /crypto parameter when using ktpass.exe.
2. Failure unspecified at GSS-API level (Mechanism level: Checksum failed)
- Either it's an incorrect password, or
- Might be that the SPN wasn't registered properly, or there are duplicate SPN's registered.
To check for duplicate SPN definitions use this:
ldifde -f c:\upn_out.txt -d "DC=yourdomainhere,DC=com" -l * -r "(userprincipalname=HTTP/YOURCOMPUTERHERE@YOURDOMAINHERE.COM)" -p subtree
This would output a text file at C:\upn_out.txt which would indicate to which users the specified SPN is registered to. The guaranteed way to remove association is by deleting the user ("setspn -D" somehow doesn't remove this association).
*For some unknown reason, the setspn -L command might show registered spn's but running the command above would display nothing.
After making sure that there's only one SPN associated to one user, you'd need to restart your http server too.
3. Client not found in database
The SPN you're using wasn't registered properly, use ktpass with the /mapuser parameter.
4. Unable to obtain password from user
Your keytab doesn't have the user name (principal attribute on the configuration) specified on your login.conf, or JAAS login configuration. You can open the keytab file through notepad to verify the name in the keytab (the name is stored in plaintext).
This can happen too when you specified the incorrect crypto option on the generation of the keytab (e.g. using AES256 only on Windows XP/2003).
I share your frustration. What made this project appealing to me was the simplicity of some of the steps as opposed to how complicated they were in some of the other implementations.
Generating the keytab using KTAB instead of ktpass was one of those steps. It is much simpler syntax and doesn't reset the password, as some versions of ktpass appear to do.
setspn -s adds the specified SPN after verifying that no duplicates exist. Usage: setspn –s <SPN accountname>.
With JBOSS, it seems important that the KVNO in the keytab matches the ms-KeyVersionNumber that will be visible using the ADSIEdit.msc utility. This number is incremented on the AD side each time the password is changed and incremented in the Keytab each time it is created with ktab -a <SPN accountname> -k<keytab file name>. It will set it at 1 if the file doesn't already exist and increment it if the file exists.
The real frustrating one for me was the size of the credential. When deploying in an environment with a large number of AD group memberships, the size of the user's credential will exceed Tomcat's maxHttpHeaderSize. https://sourceforge.net/projects/spnego/forums/forum/1003769/topic/3699577?message=8383434. Other than the 400 - Bad Request, this error doesn't seem to get reported directly. It was a real mystery why SPNEGO worked out of the box in some environments and failed in others.
Hope these posts help keep a bit more hair on the heads of people trying to use it.
What I like about ktpass is that the setspn command could be skipped and I could set a random password with it. What I haven't figured out with it is how to setup using the random password setting and then generating a second entry on the keytab with the same password. As I need to support Windows 7 and Windows XP environments, and the server application would most likely be deployed on a Server 2008 instance.
I haven't tried ktab yet, but that might help me skip the whole setting of the kvno parameter for ktpass.
Then there's the odd behavior that I get with setspn, sometimes I'm able to make it work, sometimes it simply chunks out "checksum failed". Going through ktpass' mapuser parameter has gotten me more consistent successful results, but I am willing to try other methods.
A few things to amend:
- The mapuser parameter is not required in ktpass. What this actually does is replace the user logon name with the principal value specified, and then call on the setspn.
The same desired effect could be achieved by following the instructions already on the main page. That is creating the keytab wherein the /princ value is the username@REALM.COM. You'd have a warning about no mapping to user taking place, but this should be fine.
Call on the setspn with the HTTP/computername.REALM.COM and HTTP/computername, register it to the created user.
- Do not set the Password Never Expires option on your client accounts used for desktop logon
For some reason, the computer you're logging onto may or may not actually connect into the domain. There were times when we were getting NTLM requests instead of Kerberos requests, indicating that it didn't log into the domain correctly.
- After installing another instance of Windows 7, it now defaults the keytab to RC4-HMAC instead of the AES256. I'm not yet sure why our old Windows 7 instances were throwing AES256 tokens instead of the regular RC4. (We weren't using AES in the domain for any of the user accounts).
This is regarding the kvno issue.
Please take a look at this post…
https://sourceforge.net/projects/spnego/forums/forum/1003769/topic/4884463