Cross Realm Administration?

Douglas E. Engert deengert at
Fri Jan 14 10:21:51 EST 2011

On 1/13/2011 9:25 AM, Jeff draht wrote:
> Here is the piece you requested to view in my /etc/krb5/krb5.conf
> It looks like others, similar to the Docs?
> [realms]
>          LAB-PASSHE.LCL = {
>                  kdc = drsaddcd01.lab-passhe.lcl
>                  admin_server = drsaddcd01.lab-passhe.lcl
>                  kdc = drsaddcd01.lab-passhe.lcl
>                  kdc = drsaddcd02.lab-passhe.lcl
>                  kdc = drsaddcd03.lab-passhe.lcl
>                  kpasswd_server = drsaddcd01.lab-passhe.lcl
>                  kpasswd_protocol = SET_CHANGE
>          }
> [domain_realm]
>          .lab-passhe.lcl = LAB-PASSHE.LCL
>          lab-passhe.lcl = LAB-PASSHE.LCL
> Regarding the system keytab file? /etc/krb5/krb5.keytab
> So I am understanding it to be for Services only?

It is for the services running on the local computer.

> ex:
> ldap/drsaddcd01.lab-passhe.lcl at LAB-PASSHE.LCL
> host/yeoman.lab-passhe.lcl at LAB-PASSHE.LCL

So on yeoman, it should *only* have entries for
services run on yeoman:
host/yeoman.lab-passhe.lcl at LAB-PASSHE.LCL

It should *NOT* have the krbtgt/LAB-PASSHE.LCL at LAB-PASSHE.LCL
or the ldap/drsaddcd01.lab-passhe.lcl at LAB-PASSHE.LCL as they
are the keys for the AD server!

Kerberos is a third party between a user and a server. Only the
KDC and the user know the user's secret. Only the server and the
KDC know the server's secret. Giving away the
krbtgt/LAB-PASSHE.LCL at LAB-PASSHE.LCL key would allow anyone to
impersonate any user to any service in the domain!

> The please explain a personal keytab?

The encryption keys use by Kerberos are a function of the password
  Key = string_to_key(PW, salt)
  where salt depends on the key type and principal name. (for RC4
there is no salt, for DES and AES it is a string composed of the
components of the principal.)

So given the password and salt, one can derive a key at any time.
Windows tends to derive keys when they are needed. i.e. the password
is stored in the AD account for the user or service. The user knows
their password, and client machines and services have a password buried
in the registry.

Other Kerberos implementations generate the key once when the principal
is enrolled, or the password in the KDC. Users know their passwords
but not keys, so nothing needs be stored long term on a client about
a user. But services could store a password, but a key is normally
stored instead in a keytab file. (There is not reverse function for
PW=f(Key)) so there is some additional security in storing keys.)

So the situation where a user would use a keytab, would only be
in situations where the user could not enter a password, such as
for use with cron jobs.

> So the AD Server creates the keytab.

What usually happens is an AD admin creates the keytab for a service
and updates the AD account at the same time. This keeps them in
sync.(There is also a key version number (KVNO) that gets incremented.
In AD it is stored as the msDS-keyVersionNumber attribute.
ktpass can update both at the same time, and can use a randomly
chosen password.

But this could be a two step process. An AD account is created and
a password is set by some AD admin. At some other time ktutil could
be run by a unix user to create a keytab using the same password
and kvno that AD has stored. So a user could create their own

Keep in mind that if the password is changed in AD, the keytab need
to be changed.

> I have a request from SAP to create a personal keytab for userid
> xf1adm?
> This is what they are asking for?

I don't know SAP, but that is what it sounds like.

> So the keytab is created by the AD Server using ktpass?

It the account is already setup, thne the user or root) on the
  unix machine could create the keytab.

> Then I take it on the unix machine and run the kinit command?
> I must save that keytab then and point xf1adm to always look at it?

xf11adm could still use the password if the password is known.

> KRB5_KTNAME=/<directory>/xf1.keytab.MD5.SUN (location of the keytab)

You probably don't want to set KRB5_KTNAME if you are going to
use the kinit -k -t ...
But read the SAP documentation. They may be calling kinit internally
or using the principal and keytab as a service.

> kinit -k -t /<directory>/xf1.keytab.MD5.SUN xf1adm at
> ________________________________________________
> Kerberos mailing list           Kerberos at


  Douglas E. Engert  <DEEngert at>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

More information about the Kerberos mailing list