[PATCH] heimdal fixes for the new keytab code

[Rakesh Patel]

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
>>it.
>>    
>>
>
>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 
patch,
however the host keytab always needs host/fqdn at REALM for normal kerberos 
clients
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 
came
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 
removed.
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.

Rakesh.

>  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,
>Guenther
>
>  
>
>------------------------------------------------------------------------
>
>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;
>  
>