Creating Kerberos Keytab Files Compatible with Active Directory

How to create a keytab file for a Kerberos user logging into Active Directory.  What's a keytab file?  It's basically a file that contains a table of user accounts, with an encrypted hash of the user's password.  Why have a keytab file?  Well, when you want a server process to automatically logon to Active Directory on startup, you have two options:  type the password (in clear text) into a config file somewhere, or store an encrypted hash of the password in a keytab file.  Which is safer?  Well, you can decide.  In any case, you'd better do a good job of protecting the file (be it a config file or a keytab).

Anyway, the accepted way to store a hashed password in Kerberos is to use a keytab file.  Now the file can be created using a number of utilities.  On a Windows machine, you can use ktpass.exe.  On Ubuntu Linux, you can use ktutil.



Before I demonstrate how to create the keytab, a word about encryption.  There are a number of encryption types used for hashing a password.  These include DES-CBC-CRC, DES-CBC-MD5, RC4-HMAC and a few others.  Active Directory uses RC4-HMAC by default.  Back in Windows 2000, you could also use the DES types without any trouble, but since Windows 2003, only RC4-HMAC is supported, unless you make a registry change (to all of your domain controllers).  If you need to use DES for some reason, then refer to the Technet article at the bottom of the page.

Before attempting to create a keytab file, you'll need to know the user's kerberos principal name, in the form of [email protected], and the user's password.

Creating a KeyTab on Windows (tested on Windows Server 2008 R2)
Open a command prompt and type the following command:

ktpass /princ [email protected] /pass password /ptype KRB5_NT_PRINCIPAL /out username.keytab

Creating a KeyTab on Ubuntu Linux (tested on Ubuntu 10.10 - Maverick Meerkat)
Open a terminal window and type the following commands:

ktutil
addent -password -p [email protected] -k 1 -e RC4-HMAC
- enter password for username -
wkt username.keytab
q

Testing the Keytab File
Now in order to test the keytab, you'll need a copy of kinit.  You can use the version that's on Ubuntu, or if on Windows, you can install the latest Java runtime from Sun (JRE).  In either case, you'll need to setup your /etc/krb5.conf file (on Linux) or c:\windows\krb5.ini (on Windows).  Either file should look something like this:

[libdefaults]
default_realm = MYDOMAIN.COM
krb4_config = /etc/krb.conf
krb4_realms = /etc/krb.realms
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true

[realms]
MYDOMAIN.COM = {
kdc = mydomain.com:88
admin_server = mydomain.com
default_domain = mydomain.com
}

[domain_realm]
.mydomain.com = MYDOMAIN.COM
mydomain.com = MYDOMAIN.COM

[login]
krb4_convert = true
krb4_get_tickets = false

Once you've got your Kerberos file setup, you can use kinit to test the keytab.  First, try to logon with your user account without using the keytab:

kinit username@MYDOMAIN.COM
- enter the password -

If that doesn't work, your krb5 file is wrong.  If it does work, now try the keytab file:

kinit username@MYDOMAIN.COM -k -t username.keytab

Now you should successfully authenticate without being prompted for a password.  Success!

More Information
If you need to use any other encryption Type than RC4-HMAC, then you'll need to tweak your AD domain controllers.  Please refer to the following TechNet article.

17 comments:

Anonymous said...

I suppose the fact that there's mixed usage of my.domain.com and mydomain.com is an error, right?

Brian said...

Yes. Fixed!

Меир said...

Microsoft's manual of Ktpass command states that /princ attribute "specifies the principal name in the form host/[email protected].". You are stating that the parameter value should be of the form [email protected]. What is correct? MIT Kerberos instruction states that "the keytab file is computer independent, so you can perform the process once, and then copy the file to multiple computers.", hence, hostname is not required when creating a keytab file. Does this mean that your proposal is more right? My issue is that I want to use one keytab in multiple computers and do not want to attach keytab only to one computer.

Brian said...

Both are valid. You may want your application to run under the security context of the computer or a user account. Typically, you want your app to run as a user, that you grant only the specific rights needed for the application to work. I think this is the more common scenario, so I've shown the commands to create a keytab for a user.

Anonymous said...

Brian, your article and comments helped me to understand a little better the process. I need to implement SSO/IWA for a web server and a correct keytab is one of the pre-requisites.
So, even if this is not the responsibility of my role, I can provide a good support for the pre-requisites.

Thanks!

PS. Do you still maintain the site?

Brian said...

Yup. Still Here, though I've changed jobs so I blog about other things recently. My other site is BehindTheRacks.com

Unknown said...

Brian, you stated on November 25th in the comments the following "You may want your application to run under the security context of the computer or a user account". Do I understand it correctly that when I run multiple Samba instances (each with their own config, etc) on 1 server I would have to [email protected] and [email protected] to get a keytab file for each samba instance specifically. kinit with the keytab file then would look like: kinit [email protected] -k -t /path_to/samba1.my.domain.keytab ?

Brian said...

I've never tried to put multiple instances of samba on the same server, but I assume that's correct. Each instance would have its own principal, and therefore require its own keytab.

Anonymous said...

Hi Brain,

Thanks for your blog, your article helped me to understand a little better. Could you please clarify me below points.

Actually am having 10 user's in AD and i generated the keytab file and using now. After some days i added 10 more user's to AD. Is i need to generate the new keytab file or not required? if it is yes. Can we automate the updating the key tab file once user is created in AD?

Brian said...

I'm not sure I understand the question. If your users need keytab files to logon, then they should each have their own keytab file. The user's keytab file should be kept in a secure location accessible by only that user, otherwise, other users could impersonate them without needing to know their password!

Anonymous said...

This is one of the clearest and best articles on the subject.
Well done and thank you.

Reto said...

I would second the opinion of Anonymous. This is a very good description and the only one I've found, that explains how to test if it works ...

Unknown said...

when I run the 'wkt username.keytab' command I'm getting the following error:
wkt: No such file or directory while writing keytab "username.keytab"

what am i doing wrong, can someone please help me

Unknown said...

While doing the klist its showing as
[vasu@lnxintux32]$ klist
Ticket cache: FILE:/tmp/krb5cc_59491
Default principal: [email protected]

Valid starting Expires Service principal
06/08/17 15:42:57 06/09/17 01:43:03 krbtgt/[email protected]
renew until 06/15/17 15:42:57


Kerberos 4 ticket cache: /tmp/tkt59491
klist: You have no tickets cached
[vasu@lnxintux32]$


Currentlu I am using krb5 but its showing error as "klist: You have no tickets cached". Why ?

Please help me to solve the issue. I am using Redhat 5.6 Version.

Brian said...

Vasu, it looks like you have a krb5 ticket, just no krb4 tickets. Looks good to me.

Shannon said...

Hi Brian, as others have mentioned, your documentation is the best out there. Are there any updates for the newer OS's?

Thank you!

Neil Gealy said...

If you're getting

wkt: No such file or directory while writing keytab "username.keytab"

It might be because ktutil writes the keytab to the current directory (if you don't specify the full path) and you do not have permission to write to that location.

Post a Comment

Related Posts Plugin for WordPress, Blogger...