Can smbd serve files without contacting a DC

[Richard Sharpe]

On Tue, May 5, 2015 at 11:08 AM, Uri Simchoni <urisimchoni at gmail.com> wrote:
> (posting again to the list as well - Sorry Richard for double posting...)
>
> On Tue, May 5, 2015 at 4:43 PM, Richard Sharpe <realrichardsharpe at gmail.com>
> wrote:
>>
>> On Tue, May 5, 2015 at 3:52 AM, Uri Simchoni <urisimchoni at gmail.com>
>> wrote:
>> > Hi,
>> >
>>
>> <snip>
>>
>> >
>> > Usually the "flakiness" is a result of mis-configured AD, namely DC's
>> > that
>> > are out of service, but CLDAP replies still point at them. In those
>> > cases
>> > we're able to fix the domain setup, but this takes time and grief. There
>> > are also cases of high packet loss, long delay, or limited bandwidth.
>>
>> Can you tell us some more here? If the connection between the DSc and
>> the server is flakey then likely the connection between the clients
>> and the DCs are flakey as well and getting tickets could be the
>> problem.
>
>
> By the time it got to me, the problem was resolved by removing dead DCs from
> the AD database. The end users started complaining after removing the
> Windows file server and putting the appliance instead, which makes the "no
> ticket" theory less probable.

Depends on the timing. Was it after ticket expiry or before?

> Vendor reports it happened in the past too,
> also with bad connections. All the hard evidence I have is a packet capture
> showing 20 seconds between session-setup request and response, and  CLDAP
> replies targeting the appliance at dead DCs which do not answer. Vendor was
> unable to reproduce it in his lab.

OK, the packet capture tends to more reliably rule out ticket issues.
Was Kerberos used for auth or not?

Reproducing difficult problems tends to be an issue. I recall a
problem with winbindd consuming 100% of CPU that had been known about
for 6 years before it was fixed, primarily because no one knew how to
reproduce the problem.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)