Hi Danilo,
This is interesting. From what you are saying, it seems that it's up to the 
_client_ to re-issue the auth request. Therefore it's a feature of Windows 
client rather than server. Why would then my client not reissue the request 
to the Samba server? I'm just trying to understand.

I have just discovered something else interesting. I have set up a testing 
Samba servert with exactly the same configuration as my production server. 
I've noticed that clients with clock skew can connect to it. As far as I can 
see from the logs, the client doesn't even attempt Kerberos auth with this 
server, and does NTLM auth instead. Can anyone please help me understand why 
Kerberos is not attempted?

Thanks,
  Leonid

"Danilo Almeida" <[EMAIL PROTECTED]> ???????/???????? ? ???????? 
?????????: 
news:[EMAIL PROTECTED]
This is an area where Samba does not emulate Windows very well.

See http://mailman.mit.edu/pipermail/kerberos/2006-September/010482.html. 
This is the basic idea:

MS Kerberos servers return the time skew error along with the server time. 
Then the client can re-issue the auth request using the server's time info 
(generating a new authenticator using the timestamp).  The time in this 
context is used to control replay attacks.

- Danilo

-----Original Message-----
From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of 
Aaron Kincer
Sent: Friday, September 22, 2006 7:34 AM
To: Leonid Zeitlin
Cc: samba@lists.samba.org
Subject: Re: [Samba] Re: can't access Samba share when clocks skew is too 
great

Actually, now that you mention it and I've got more caffeine in the
veins, I would throw the theory out that the Samba server-side
authentication is being more proactive than AD would be. In other words,
AD says "You got the right password? Come on in!" whereas Samba says
"You got the right password? That's great, but our time is out of sync
and that's a problem. This session has timed out."

This is just a guess, more or less.

Feel free to email me directly with your questions about GPOs if you
want to take it off-list.

Aaron

Leonid Zeitlin wrote:
> Hi Aaron,
> Thanks, I understand. As a matter of fact, yes, I do need help with GPOs
> (not NTP on Samba server - thanks, that's clear to me), so if you can 
> offer
> a suggestion, I'd appreciate (I understand this is off topic on the Samba
> list).
>
> At the same time, as I mentioned in the previous post, I'm trying to
> understand why clients with incorrect clock can connect to Windows servers
> and can't connect to Samba. I thought Samba tried to emulate Windows file
> server as close as possible. In this particular case I thought Samba would
> fall back to NTLM auth. Maybe I misunderstand something.
>
> Thanks,
>   Leonid
>
> "Aaron Kincer" <[EMAIL PROTECTED]> ???????/???????? ? ???????? ?????????:
> news:[EMAIL PROTECTED]
> It is pretty standard behavior for encrypted authentication schemes to
> reject authentication requests when the time deviation between the
> client and server are too far apart. This is by design. It is basically
> a timeout from Active Directory's perspective. You can use Active
> Directory GPOs to configure clients to use NTP and you can also
> configure NTP on your Samba server (use cron to sync time hourly if you
> must). This should fix your authentication issue. If you need help with
> GPOs or configuring NTP on your Samba server, let me know.
>
> Bruno Rodrigues Neves wrote:
>
>> Hi Leonid,
>>
>> I donĀ“t know the cause of this problem, but if you try add into your
>> netlogon script a line such as a "set time" in order to set the clock
>> to the same from the server?
>>
>> Regards!
>>
>> -- 
>> Bruno
>>
>>
>> On 9/22/06, Leonid Zeitlin <[EMAIL PROTECTED]> wrote:
>>
>>> Hi all,
>>> I have a Samba 3.0.23c server joined to an Windows 2003 AD domain. Users
>>> access it from Windows workstations (XP, 2000). The problem is that if a
>>> workstation has its time off by more than 5 minutes, Samba server cannot
>>> be
>>> accessed. I understand that Kerberos cannot authenticate the clients due
>>> to
>>> clock skew; however, I thought that in such case Samba could falls back
>>> to
>>> NTLM auth. At least, the workstations with the wrong clock can access
>>> Windows file servers, but not Samba. Is Samba's behavior in this case
>>> intentional? Is this supposed to work? How can I help or debug this
>>> situation? Any help is appreciated.
>>>
>>> Thanks,
>>>   Leonid
>>>
>>>
>>>
>>> -- 
>>> To unsubscribe from this list go to the following URL and read the
>>> instructions:  https://lists.samba.org/mailman/listinfo/samba
>>>
>>>
>
>

-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba



-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba

Reply via email to