Working With Keytabs

Working With Keytabs

By Centrify Contributor II on ‎07-09-2018 02:10 PM

Introduction

I often have discussions with various Active Directory administrators, security architects and application groups concerning the Kerberization of applications. Nowhere is this more prevalent than in the big data space. However, as soon as we start discussing the generation of dedicated service principal accounts, or custom principals and keytabs for application integration, eyes gloss over and confusion ensues. Microsoft has done such an amazing job of making Kerberos seamless that even senior architects barely understand what’s happening under the covers. So in this article, we’ll quickly revisit how Kerberos works and then walk through some real life examples for keytab generation using the Centrify adkeytab utility.

 

Kerberos Basics

The Kerberos architecture can be broken up into three entities. The core component is the KDC, or Key Distribution Center. In the Active Directory world, this is any domain controller. You also have Kerberos clients, or end users, and servers, which provide resources to clients. We’ll use a file server in this example.

 

The process starts when a user types in their credentials to log onto a domain-joined workstation or server. Rather than sending the username and password in clear text to the domain controller to authenticate the user, Kerberos instead generates an authentication request, locally, on the client workstation. This request is encrypted using the user’s password before being sent to the KDC so the password cannot be snooped off the wire.

 

Next, the KDC looks up the clear text username and attempts to decrypt the request using the user’s password stored in the directory. If decryption is successful, then the user must be who they say they are because the request was encrypted with the password matching what’s stored in the directory. Once this user is successfully authenticated, the KDC generates what’s called a Ticket Granting Ticket (TGT) and encrypts this with the KDC key, only known to the KDC. This is stored in memory back on the client workstation and can then be used to make any service ticket request for the next eight hours.

 

Now that the user has been authenticated and given a TGT, the user needs to connect to the domain-joined file server. To get a ticket for this particular server, the user submits their TGT to the KDC and requests a ticket for the file server. Since the KDC encrypted the TGT with its key, it’s the only entity that can decrypt it. If decryption is successful using the KDC key, the KDC knows this is a valid request and will generate a service ticket for the file server using the file server’s password stored in the directory, without having to reauthenticate the user every time. This ticket is then given to the user and placed in memory on the workstation.

Lastly, to connect to the file server, the user makes a copy of its service ticket and sends it to the server. The server uses its password to decrypt the request. If it can do so, the server knows a valid ticket, generated by the KDC, has been presented and grants access to the user based on user and group membership contained within the service ticket.

 

Just that easy! One important note: Because Kerberos validates the identity of both the user and server, you achieve Identity Assurance Level Two. For those of you who have to deal with regulations, as a comparison, a password vault replaying a credential to authenticate to a server only gets you to Identity Assurance Level One. This is why Kerberos is seen as such a secure protocol.

 

Working with Keytabs

In the above example, we walked through the process that started with a user entering their username and password. But how is this same process handled when you’re dealing with applications, services or scripts and there is no human involved? You certainly wouldn’t want to leave the password sitting around in clear text, so it can be used to create a request. This is where keytabs come in. Keytabs contain a list a valid principals and an encrypted copy of the password. If an application or service needs to authenticate to one of these principals, they can initialize the request from this keytab and the rest of the process works the same.

 

There are three very common scenarios and the syntax for generating the keytab can be a bit confusing. Let’s explore each:

 

Scenario – One: Generate a new service principal account with a randomized password in AD and generate a new keytab.

 In this configuration, the target principal does not yet exist within AD so a new account will have to be created in the specified organizational unit. Adkeytab will generate a complex password and encrypt this within the keytab. No human will ever know the password.

 

Note: This syntax will set the password to never expire. Should it ever change within the directory, the keytab will have to be regenerated. Since the password is essentially unmanaged and unknown to any user, it’s generally seen as a safe practice to create the account with the password never expires flag. If it is an issue, simply delete the existing account and rerun the command to create a new pair at your preferred interval. Most Hadoop vendors have a ‘regenerate principals’ option to do this automatically.

 

 

[root@server1 ~]# adkeytab -n -P http/server1.centrifylab.net -u jsmith-a@centrifylab.net -U http/server1.centrifylab.net@CENTRIFYLAB.NET -S http-server1 -W -K /etc/security/keytabs/http-server1.keytab -c ou=cluster1,ou=Hadoop,ou=Accounts,dc=centrifylab,dc=net http/server1.centrifylab.net

 

Where:

-n create a new account

-P SPN value

-u username to bind to AD

-U UPN value

-S samAccountName

-W password never expires

-K path to keytab file

-c container path for new account

Account (DisplayName)

 

Typically, the resulting keytab would be owned and only accessible to root or an application account. These users can initialize directly, and other users can use command elevation to initialize as these accounts.

 

Scenario – Two: Adopt an existing service principal or user principal account with a new randomized password in AD and generate a new keytab.

 In this example, let’s assume we already have an account with a known password in AD. We want to use this account to create a new keytab, but as part of the process we want to convert from a known password to a randomized unmanaged password – just as we did in the first scenario.

 

[root@server1 ~]# adkeytab -A -K /etc/security/keytabs/adjoinacct.keytab -S adjoinacct "Join Account"

 

Where: 

-A adopt an existing account

-K path to keytab file

-S samAccountName

Account (use the Active Directory display name in quotes, even if there are no spaces)

 

You will be asked for the existing password for this account when executed. The target account will need permissions to change the password.

 

 

Scenario – Three: Adopt an existing service principal or user principal account using the existing password in AD and generate a new keytab.

 I typically prefer to go the unmanaged password route and not have to worry about it but there may be cases where you want to generate a keytab using the existing known password. In this case, we don’t want to change anything in AD, we just want to generate the keytab and encrypt the known password within. Adding the -l and -w options makes this a local change only using the provided password.

 

[root@server1 ~]# adkeytab -A -K /etc/security/keytabs/adjoinacct.keytab  -l -w KnownPassword -S adjoinacct "Join Account"

 

Where:

-A adopt an existing account

-K path to keytab file

-l local

-w the existing password

-S samAccountName

Account (use the Active Directory display name in quotes, even if there are no spaces)

 

Using your Keytab

If the keytab is owned by root and you are currently logged on as root, the command is as simple as:

 

[root@server1 ~]# kinit -kt /etc/security/keytabs/adjoinacct.keytab adjoinacct@CENTRIFTLAB.NET

 

If you want to see the principals stored in the keytab:

 

[root@server1 ~]# klist -kt /etc/security/keytabs/adjoinacct.keytab

 

I don’t typically recommend logging on directly with highly privileged accounts and making yourself susceptible to malware attack, so if you’re logged on with a least privilege user account, DirectAuthorize could technically be used to perform command elevation to achieve the same goal. Just remember: when you elevate a command to be executed as root, the resulting Kerberos cache file will be owned by root. You’ll have to take an additional step to chown the cache back to your account for it to work correctly. It would look something like this:

 

Using the custom keytab:

# destroy the default user principal:

[clusteradmin@server1 tmp]$ kdestroy

 

# Run kinit against custom service keytab; owned by root so use dzdo to run kinit as root

[clusteradmin@server1 tmp]$ dzdo kinit -k -t /etc/security/keytabs/adjoinacct.keytab adjoinacct@CENTRIFYLAB.NET

 

#Because we ran as root, resulting cache file is owned by root so chown it back to your account.

[clusteradmin@server1 tmp]$ dzdo chown clusteradm:clusteradm /tmp/krb5cc_uidNumber

Showing results for 
Search instead for 
Do you mean 
Labels

Community Control Panel