samba - Aug 2016 - Use case to test Clock skew on SAMBA4 (4.4.5)

Hi Experts ,

I have a situation where I have to demonstrate that if the time 
difference between  Samba4 (AD) and Windows Client is more that 5 Min ( 
as per Kerbrose ) , the user should note be allowed to login via that 
windows PC .

When I simulate it I get Clock skew in the logs ( as shown below ) but 
the user is allowed to login .

/ Kerberos: Too large time skew, client time 2016-08-27T17:08:26 is out 
by 7280 > 300 seconds -- sysinfo$@MYDOMAIN.LOCAL//
// Kerberos: Too large time skew, client time 2016-08-27T17:11:56 is out 
by 7280 > 300 seconds -- brijesh.vishwakarma at MYDOMAIN.LOCAL/

Is it the right Use case to demonstrate ? If yes then why is the case 
failing .

If No , what can be right use case to demonstrate ?

TIA

Biswajit Banerjee

On Sat, 2016-08-27 at 19:56 +0530, Biswajit Banerjee via samba
wrote:
> Hi Experts ,
> 
> I have a situation where I have to demonstrate that if the time 
> difference between  Samba4 (AD) and Windows Client is more that 5 Min
> ( 
> as per Kerbrose ) , the user should note be allowed to login via
> that 
> windows PC .
> 
> When I simulate it I get Clock skew in the logs ( as shown below )
> but 
> the user is allowed to login .
> 
> / Kerberos: Too large time skew, client time 2016-08-27T17:08:26 is
> out 
> by 7280 > 300 seconds -- sysinfo$@MYDOMAIN.LOCAL//
> // Kerberos: Too large time skew, client time 2016-08-27T17:11:56 is
> out 
> by 7280 > 300 seconds -- brijesh.vishwakarma at MYDOMAIN.LOCAL/
> 
> Is it the right Use case to demonstrate ? If yes then why is the
> case 
> failing .
> 
> If No , what can be right use case to demonstrate ?
Many clients will use the error generated above to re-sync their clock
to the KDC, to avoid failure in this case.

Or, they will log in with NTLM over the NETLOGON service. 

Time in modern networks is just too fragile to allow for direct failure
here, so a lot of work is done to avoid it, both by using NTP to keep
time in sync, and to auto-skew to the KDC's time.

I hope this helps clarify things,

Andrew Bartlett

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba

Hi Andrew,

Am 28.08.2016 um 11:05 schrieb Andrew Bartlett via
samba:
> Many clients will use the error generated above to re-sync their clock
> to the KDC, to avoid failure in this case.
> 
> Or, they will log in with NTLM over the NETLOGON service. 
> 
> Time in modern networks is just too fragile to allow for direct failure
> here, so a lot of work is done to avoid it, both by using NTP to keep
> time in sync, and to auto-skew to the KDC's time.


I tried yesterday what Biswajit tried: I shutdown ntpd on the DC and set
the date to 12 days ago.

While I can successfully log in to the DC and access the file shares
(only "Too large time skew, client time..." was logged), I can't
access
file shares on a Samba member server that has the same time like the client.

Additionally I tried a kinit from a different Linux host and I got a
Kerberos ticket from the DC, that was already expired:


Time on the Samba AD DC:
[root at DC1 ~]# date
Mo 15. Aug 15:19:42 CEST 2016




Time on the Linux Client (almost 12 days ahead):
[root at M1 ~]# date
Sa 27. Aug 18:52:33 CEST 2016

[root at M1 ~]# kinit administrator at SAMDOM.EXAMPLE.COM
Password for administrator at SAMDOM.EXAMPLE.COM:

[root at M1 ~]# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: administrator at SAMDOM.EXAMPLE.COM

Valid starting       Expires              Service principal
15.08.2016 15:18:10  16.08.2016 01:18:10
krbtgt/SAMDOM.EXAMPLE.COM at SAMDOM.EXAMPLE.COM
	renew until 22.08.2016 15:18:07



Is this really expected?



Regards,
Marc