[Samba] AD+DFS+Samba flakiness

[Carl Wilhelm Soderstrom]

On 03/05 10:27 , Carl Wilhelm Soderstrom wrote:
> We have a situation at a couple of completely unrelated locations, where
> there is an Active Directory server (Windows 2008R2) hosting a DFS tree, but
> the back end is a collection of Samba servers hosting the files (Samba 3.6.3
> on Ubuntu 12.04).
> 
> Every now and then users will get 'access denied' messages when trying to
> browse shares under the DFS tree.
> 
> If they go directly to the share on the Samba server, they generally can get
> their files just fine.

After much examination of one case today, I'm not much closer to figuring
out what's going on. However, I *did* see errors like this in the logs on
the Samba server when trying to access a share under the DFS tree:

[2014/03/05 14:19:40.127577,  2]
smbd/service.c:627(create_connection_session_info)
  user 'DOMAIN+username' (from session setup) not permitted to access this
share (Sharename)

If I went to the share directly on the Samba server, I could get in without
any problems.

If I used Smbclient from another Linux box, I could get into
\\sambaserver\sharename without any problems.

If I used Smbclient from another Linux box, I could get into
\\ADserver\DFS\sharename without any problems. (This being the path through
the Windows server to the Samba share listed above).

I killed the smbd process by which the user was logged into the samba
server, and thereafter the user was able to connect again successfully.

So I'm wondering if somehow some bad credentials were cached when the user
first authenticated. It only happens *sometimes* tho. Often enough to be
annoying (and make management want to go all-Microsoft), but infrequent
enough that it's exceedingly difficult to build a test case.


Does anyone have any advice on how to troubleshoot this further?

Random suggestions for things to look at next?

The problem is that even at log level 3, the logs get really huge really
fast, and I dread trying to turn up the logs to level 10, capture the
relevant data from all the appropriate logfiles for a successful logon,
wait around for an error to crop up, and hope the user tells me in time that
I can go look at it before it goes away.

I'll probably have to do that anyway.

-- 
Carl Soderstrom
Systems Administrator
Real-Time Enterprises
www.real-time.com