PATCH: Another revision to enable / enhance use of the system keytab

[Joachim Keltsch]

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 
tasks.

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 
multi-purpose systems.

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,

Joachim


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