[Samba] Use case to test Clock skew on SAMBA4 (4.4.5)

[Biswajit Banerjee]

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
>