[Samba] Samba kerberos more time sensitive that Windows?

[Jeremy Allison]

On Fri, Mar 16, 2007 at 07:47:12AM +1300, Jason Haar wrote:
> >   
> It was a Win2K3 client with its clock hours off connecting to a Samba
> server (with Win2K3 domain controllers at the back end) - with correct
> clocks.
> 
> It was a nasty case. The problem was that it was a CentOS4 server
> running Win2K3 as as virtual server under VMware. There is a bug/issue
> between current vmware-server instances and 2.6.9* series Linux kernels
> that means VMware can't emulate "time signals"(?) correctly. End result
> was that even though the Win2K3 client had a ntp agent installed, it was
> unable to keep it's clock in sync. We also have an identical issue with
> running virtual Linux in the same environment. The syslog is filled with
> ntp errors about being unable to slew the clock.
> 
> So we're going to run VMware under Fedora instead - at least that kernel
> is less than 2 years old ;-)

It truely is a strange case. I find that if I change
the clock on the client and log in it re-syncs the
time from the DC and all connections to servers work
(as you'd expect with the correct time).

If I log in then change the client time and then attach
to the Samba server it fails to login (interal logs show
clock-skew errors). I can make the server return this
error to the client and the client then displays the
message "This servers' clock is not synchronized with
the primary domain controller's clock", which I think
is an improvement (although not accurate as it's the
client's clock that is wrong). This is the code I'm
going to check in for 3.0.25 as it gives a much clearer
error message to a user than "login denied".

I'm guessing that once the client has logged in and
got a TGT it believes it's time must always be correct
or it wouldn't have got the initial TGT.

The interesting sessionsetup shenanigans I see in
the trace you sent me only seem to happen when
the client is connecting to the DC. I'm guessing
it's that connection with the embedded krb5 error
returned containing the "CLOCK SKEW" error (containing
the DC's current time) is what causes the client
to re-sync the time on login. As we're not yet able
in Samba3 to be a KDC the client will not accept
that error message on sessionsetup from us (it
just displays the standard "bad username or password"
and terminates the connection) but I'm going to
leave the code in place (#ifdef'ed out) so we
can turn this on once we're truely running as
a KDC.

Jeremy.