PATCH: Another revision to enable / enhance use of the system
J.Keltsch at science-computing.de
Wed Apr 28 12:33:34 GMT 2004
Hi Dan, hi samba team,
first of all, thank you for this very useful patch to samba-3.0.3pre2
We consider the functionality of synchronizing system keytab files to be vital
for the operation of UNIX systems with samba. In our environments samba
servers are usually not solely serving smb, but also performing other server
If UNIX systems are integrated into kerberos AD authentication, they require
to have the current HOST service keys in their keytab file to successfully
authenticate users. Especially, since samba is able to change the system
passwords from time to time, it is no option to manually carry the keytab
file from the AD server to the UNIX system.
Hence, it is a strong requirement that this patch is applied, if anyone
intents to use a UNIX system for other purposes but SMB file services.
The unpatched implementation of samba actually *prevents* its use on
However, the patched version implies the use of samba even on systems that do
not actually serve as file servers. This is because key management is much
easier with samba than it were using ktpass on AD and then fiddling around
with secure keytab transfer. Aside from this radical improvement concerning
convinience, you obtain reasonably strong keys for your services.
We therefore want to stress the necessity to integrate this functionality into
samba 3.0.3 final.
However, the functionality of changing keys AND removing the older keys from
the keytab file at the same time poses the following problem:
any client aquires a key for a service on host server.domain, say for
keberized ssh access.
The client holds a ticket for
host/server.domain at REALM
valid for 10hrs or so.
Within this period, ssh client will not request new tickets, since it can
reuse the currently available ticket, until it expires.
However, if samba changes the host key within this period, the cached service
key cannot be decrypted any more by the server. It has become invalid.
For a user, the only way to resolve this situation is to reinitialize the
ticket cache (on UNIX, using "kinit") or to remove the responsible service
key (on Win*, using "klist purge").
Note that this problem affects ALL kerberized services, i.e. CIFS stops
working, too. (Try to disconnect a share and reconnect it on an XP client,
after samba has changed the password. It will fail unless you "kinit purge"
the responsible CIFS ticket)
On MS servers this problem does not occur, because MS services accept their
current and previous password. (MS Knowledge Base Q325850)
The solution was not to remove the keytab contents completely, but to leave
all keys with current KVNO minus 1 reside untouched inside the keytab file.
The services on UNIX would then also accept the previous keys, which might
still be cached in many ticket caches.
Dan, is there already a more recent patch that covers this issue, or do you
see any chances to solve this problem in a newer version?
Hoping that this patch will finally make it into samba 3.0.3,
> -----Original Message-----
> Subject: PATCH: Another revision to enable / enhance use of the system
> keytab Date: Friday 16 April 2004 17:27
> From: "Dan Perry" <dperry at pppl.gov>
> To: <samba-technical at lists.samba.org>
> Hi all,
> Here's another revision of a patch to enable use of the system keytab.
> This version of the patch that addresses the following two items:
> 1) Cleanup of the service principals list for a computer account in active
> directory is now cleanly done. Older service principals are properly
> removed from active directory computer account when things are flushed from
> the system keytab.
> 2) Added a 'net ads delegation' command that turns on (or off) Kerberos
> delegation a Windows 2003 domain. This is useful as it enables the
> Kerberos delegation for the computer accounts in active directory to
> perform to properly delegate principals
More information about the samba-technical