summaries krb5 keytab requirements

[Dave Daugherty]

Gerald (Jerry) Carter says...
Sent: Friday, May 19, 2006 8:42 AM


> I'm trying to wrap my head around all of the past issues
> that have caused our krb5 code to look like it does today
> (with hopes of cleaning things up).  These are my random
> thoughts.  Please correct me if I am wrong on any point.

It's a tough issue with many subtle gotchas.  I suggest proceeding very
carefully.

> Salting
> =======
> We only need to derive the Salt for DES keys if we are in an
> AD domain and if the account has the USE_DES_KEYS flags set.
> Otherwise, service tickets are always encrypted with RC4-HMAC.
> This will make a lot of of the loops in derive_salting_for_principal()
> go away.  The principals names used for salting DES keys are:
> http://marc.theaimsgroup.com/?l=samba-technical&m=110005392723944&w=2

The bit is for "use DES only", but DES keys are still honored. Some
applications such as Oracle and MIT's Kerberized telnet only use DES,
and will fail if the salted DES keys are not in the keytab.

On the other hand the Windows Administrator account is special and is
precluded from using DES encryption.

Salt is case sensitive. In the Windows world SPNs and UPNs are not. You
can't assume that if someone types in aDmInIsTrator at foo.com then that is
what the salt should be.

Computer account salt is not the same as User salt, and the computer
account salting rules are different for Win2k and Win2k3 (Win2K will use
the UPN host/name at REALM if it is present), hence the net ads join code
to guess what salt should be used.
 
> SPN values
> =========
> The CIFS/machine principal name is unnecessary in AD (even though
> clients ask for it): http://support.microsoft.com/kb/326985/en-us

On the other hand other apps want things like HTTP/... and FTP/...

> dNSHostName & SPN
> =================
> See this on the relationship between the dNSHostName and SPN
> values and the "VAlidated write" access permission.
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ad/ad/c
ontrol_access_rights.asp


> kinit -k
> ========
> This does not require a UPN, but can use the sAMAccountName

I think Samba could live without UPN on a computer account, but it
should live with it if it is there (i.e. Win2k Computer Account - UPN
determines the salt).

> SPN case insensitivity from Windows XP clients in MIT realms
> ============================================================
> http://marc.theaimsgroup.com/?l=samba-technical&m=110933962414367&w=2

> I'm not really sure what to do here.  The real fix it seems
> would be to simply canonicalize the SPN by the TGS before granted
> in the service ticket.  It seems that string a vast amount of
> possible SPNs in /etc/krb5.keytab is really ugly.


- -- cheers, jerry

Hope this helps...
Dave Daugherty
Centrify Corp.