Patch: System keytab usage improvements
abartlet at samba.org
Tue Jun 1 02:47:06 GMT 2004
On Tue, 2004-06-01 at 12:16, Dan Perry wrote:
I certainly would not keep anything more than kvno - 2 or a week, but
lets just do kvno -1 for now, we can always fix it later.
> Like I mentioned above, things will probably head towards using secrets.tdb
> eventually. However, this patch is getting kind of big already. Perhaps
> maybe using secrets.tdb could come after the patch at hand is merged. I'd be
> happy to work on getting secrets.tdb to store a better keytab structure...
OK. It's just easier to extract these things when we can hold a patch
over their heads ;-)
> Upon re-reading the email I sent, perhaps I should explain the changes my
> patch makes to kerberos_verify() a little more clearly. The patch does not
> create a situation in which kerberos_verify would break, by changing
> kerberos_verify() to be keytab only. The patched kerberos_verify() works
> like this:
> FIRST PASS - checks the keys in the keytab, if it even exists. If a
> key works, great, the session succeeds.
> SECOND PASS - if the keys in the keytab fail, (for example if the
> keytab doesn't exist, the system admin doesn't have a correct reverse dns
> zone, etc.) Then kerberos_verify() tries to use the machine password from
> secrets.tdb to make keys, just like it the function did before the patch was
> THIRD PASS - nothing left to try, NT_STATUS_ACCESS_DENIED is
> This behavior should be completely backwards compatible and just as lenient
> to a poor Kerberos / dns setup as the kerberos_verify() function was before
> the patch. It does, however, let users with existing Kerberos sessions keys
> continue to use those keys after a machine password change. However, if you
> know a better way to implement, please let me know.
That makes it sound much more reasonable.
On particular issues:
Your configure test needs to be much more careful about security.
Execute it in the build directory, at the very least, and perhaps use
+ if (krb5_kt_resolve(context, "WRFILE:/tmp/whatever", &keytab))
(If there are systems with kerberos, but without mkstemp(), you can
use our utility replacement)
Also, did all these people really write your new kerberos_keytab.c?
--- samba-3.0.5pre1/source/libads/kerberos_keytab.c 2004-05-06 17:14:58.000000000 -0400
+++ samba-3.0.5pre1/source/libads/kerberos_keytab.c 2004-05-31 15:16:31.000000000 -0400
@@ -0,0 +1,115 @@
+ Unix SMB/CIFS implementation.
+ kerberos keytab utility library
+ Copyright (C) Andrew Tridgell 2001
+ Copyright (C) Remus Koos 2001
+ Copyright (C) Luke Howard 2003
+ Copyright (C) Guenther Deschner 2003
+ Copyright (C) Jim McDonough (jmcd at us.ibm.com) 2003
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
Please don't do a copy & past of copyright notices, unless you really copied code.
Is this magic number from somewhere? How do we know it won't change?
--- samba-3.0.5pre1/source/utils/net_ads.c 2004-04-04 03:37:38.000000000 -0400
+++ samba-3.0.5pre1/source/utils/net_ads.c 2004-05-31 16:43:19.000000000 -0400
+#define MAX_KEYTAB_NAME_LEN 511
Once these are fixed/justified, I'm happy with the patch, subject to testing.
I do however need our release manger (jerry) to indicate his feeling, as
we are pretty 'stable' with 3.0 at the moment.
Andrew Bartlett abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team abartlet at samba.org
Student Network Administrator, Hawker College abartlet at hawkerc.net
http://samba.org http://build.samba.org http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20040601/006bdd8b/attachment.bin
More information about the samba-technical