Patch: System keytab usage improvements

Andrew Bartlett abartlet at
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
> applied.  
> 	THIRD PASS - nothing left to try, NT_STATUS_ACCESS_DENIED is
> returned.
> 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

+    krb5_init_context(&context);
+    if (krb5_kt_resolve(context, "WRFILE:/tmp/whatever", &keytab))
+      exit(0);
+    exit(1);

(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 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

Andrew Bartlett                                 abartlet at
Manager, Authentication Subsystems, Samba Team  abartlet at
Student Network Administrator, Hawker College   abartlet at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url :

More information about the samba-technical mailing list