Marc Muehlfeld
2016-Aug-28 10:42 UTC
[Samba] Use case to test Clock skew on SAMBA4 (4.4.5)
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
Biswajit Banerjee
2016-Aug-28 14:02 UTC
[Samba] Use case to test Clock skew on SAMBA4 (4.4.5)
Thanks Andrew and Marc . I really appreciate the quick response , efforts and view point . We also tried to simulate "Access to Samba Member share access" the way Marc Did , but we are able to access the share . Let me see once again on this aspect ( Samba Member Share access ) once again in next 24 hours and report the success or failure . Thanks Biswajit Banerjee On Sunday 28 August 2016 04:12 PM, Marc Muehlfeld wrote:> 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 >
Andrew Bartlett
2016-Aug-28 19:23 UTC
[Samba] Use case to test Clock skew on SAMBA4 (4.4.5)
On Sun, 2016-08-28 at 12:42 +0200, Marc Muehlfeld wrote:> 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?I'm sorry if you interpreted my comments as meaning this would be seamless: Time sync is critical to the correct behaviour and the security of the system. It is just that our clients try to cope in the trivial cases where just the client is out of sync. To work out expected behaviour further, a comparison with Windows would be worthwhile. Thanks, 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
Marc Muehlfeld
2016-Aug-29 17:54 UTC
[Samba] Use case to test Clock skew on SAMBA4 (4.4.5)
Am 28.08.2016 um 21:23 schrieb Andrew Bartlett via samba:> To work out expected behaviour further, a comparison with Windows would > be worthwhile.I set up a Windows Server 2012 R2 DC and the behaviour is the same: I can log on to a Win7 client (2 weeks time difference). And if I kinit from a Linux machine, I also get the already expired ticket. Regards, Marc