[PATCH] heimdal fixes for the new keytab code

Rakesh Patel rapatel at optonline.net
Wed Jul 7 23:56:01 GMT 2004

Guenther, I believe I can help with one of the questions below -
inline response below:

Guenther Deschner wrote:

>Hi Jeremy,
>On Thu, Jun 24, 2004 at 02:27:14PM -0700, Jeremy Allison wrote:
>>Ok, I've finished the changes and the current SVN source code
>>compiles with Heimdal. If you could test it I'd appreciate
>Thank you, Jeremy.
>There are still some small issues, I'm afraid ;-)
>* why do we let samba now kinit with HOST/fqdn at REALM, instead of
>  HOST/machine at REALM in security=ads ? the current code does not even create 
>  HOST/fqdn at REAM-principals but HOST/fqdn-principals.
I'm not sure what spns are created in AD from the latest version of the 
however the host keytab always needs host/fqdn at REALM for normal kerberos 
to function. When joining the machine to the AD domain, AD has a large 
number of
automatic "aliases" for the machines principal name and either 
pregenerates each
version of the key or most likely dynamically generates the kerberos 
key. SPNs such
as "host$",  "HOST/machine", etc. are part of that list. It is an AD 
attribute and
I have seen it in the past - the list of acceptable SPNs is lengthy.

Since Samba code automatically handles requests in a similar manner by 
using the
password from secrets.tdb, it does not need to worry about which SPNs 
need to be
added to the system keytab.

As far as a later question about CIFS/machine - I am not sure where that 
from. I suggest checking a registered file server to see if CIFS/machine is
one of the SPNs for any file servers. If not, that should probably be 
I don't recall the name of the attribute listing the "aliases" for the 
SPN, but
the values for that attribute should also be checked in case CIFS is 
listed in there.


>  AFAIK, this will break all existing security=ads installations prior to
>  current svn. We should at least provide an internal upgrade path or describe
>  the to-be-expected-effect in WHATSNEW.TXT. Or am I completely wrong here ?
>* The cleanup in libads might be a good chance to apply the remaining parts of
>  the fix for #1208 (fix existing one-direction clock-skew-correction that can
>  lead to infite loops whereever libsmb/clikrb5.c's cli_krb5_get_ticket is
>  used) :)
>* with the keytab-patch several initialize_krb5_error_tables slipped in. This
>  is only needed for Heimdal Kerberos, we should provide another abstraction
>  function for that later on.
>* ads_keytab_create_default should not return it's last error-code (that is
>  always non-0, at least in Heimdal) (attached)
>Thanks a lot,
>Index: source/libads/kerberos_keytab.c
>--- source/libads/kerberos_keytab.c	(revision 1287)
>+++ source/libads/kerberos_keytab.c	(working copy)
>@@ -479,7 +479,7 @@
> 	ret = krb5_kt_start_seq_get(context, keytab, &cursor);
> 	if (ret != KRB5_KT_END && ret != ENOENT ) {
>-		while ((ret = krb5_kt_next_entry(context, keytab, &kt_entry, &cursor)) == 0) {
>+		while ((krb5_kt_next_entry(context, keytab, &kt_entry, &cursor)) == 0) {
> 			if (kt_entry.vno != kvno) {
> 				char *ktprinc = NULL;
> 				char *p;

More information about the samba-technical mailing list