[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
>>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;
>
>
More information about the samba-technical
mailing list