Kerberos auth against AD, keytabs, and service principal names

[Douglas E. Engert]

kerberos at noopy.org wrote:
> I've been able to use ktpass.exe on the Windows (2003R2) side to
> create working keytabs for my NFSv4 environment.  I'd like to have
> both host/ and nfs/ service principal names for each host.fqdn in my
> (DNS) domain.  To this end I ran 'setspn -A ...' to create a SPN for
> host/host.fqdn and nfs/host.fqdn and then I ran ktpass.exe to create a
> keytab for each of host/host.fqdn and nfs/host.fqdn.
> 
> Then I copied the keytabs to my Linux system and tested kinit for
> host/host.fqdn and nfs/host.fqdn.  kinit for nfs/host.fqdn worked but
> kinit for host/host.fqdn *failed*.   What?!  Looking at my entries in
> AD, it appears that ktpass.exe sets both userprincipal name and
> serviceprincipal name to *the same thing* and merely adding SPNs to
> the host.fqdn entry in AD doesn't fix the problem with kinit -- if
> princ/host.fqdn doesn't exist in AD as a UPN.  That is to say, only
> UPNs are consulted when I kinit some princ/host.fqdn?
> 
> Is my assessment right about this? 

Pretty much.

An account in AD has a single password, single UPN and maybe multiple SPNs.
Kerberos keys are generated on the fly from the password.

A keytab has the SPN and the key.

When you kinit using a keytab to AD, you are using the SPN, but AD
is looking it up as a UPN.

Note the since there is only one password, all the SPNs share the same
key, and all enctypes use the same password to generate the keys.

  Is the only solution to have
> multiple AD entries, one for each SPN you intend to support?

That may not be so bad, as you may want different keys for different
principals. Just have a good account name naming convention for all
these accounts.

> 

-- 

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