Can smbd serve files without contacting a DC
realrichardsharpe at gmail.com
Tue May 5 07:43:50 MDT 2015
On Tue, May 5, 2015 at 3:52 AM, Uri Simchoni <urisimchoni at gmail.com> wrote:
> An appliance vendor I'm doing work for, which uses samba as its file
> server, is sometimes encountering situations where the connection from the
> appliance to the domain controller is flaky, and that creates issues with
> smbd's ability to serve files. Long delays in initial connection from the
> user's machine to the appliance (20 seconds between session-setup-and-x to
> the response) cause Windows explorer to freeze and the end result is bad
> user experience. The users themselves do not have connectivity issues with
> the appliance, but the fact that the appliance is contacting the domain for
> each new user connection creates the bad user experience.
> 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
> (we're always talking about relatively complex AD setups, with multiple
> sites, and the appliance typically sits in some branch office.
> Additionally, the IT staff of the customer often outsources AD
> configuration and any modifications are hard to make).
> The way I see it (and maybe I'm wrong), a Windows file server doesn't need
> to contact the DC in order to serve files because it has all the
> information it needs in the PAC. Perhaps this is why the customer only has
> trouble when he throws away the Windows servers and places samba-based
> appliances, even though the network problems or mis-configuration had been
> there all along.
> Assuming it is true, can smbd do the same? (i.e. serve files without
> contacting a DC)
> Well, smbd, being a UNIX process, also needs to have the unix process
> token. But what if the id-mapping does not need a connection to the DC
> (e.g. rid-based)? From the code it looks like:
> 1. smbd does a getpwnam in order to check for PAM restrictions (well this
> can be avoided if PAM checks are disabled)
> 2. there's another getpwnam in check_account() which is used to get the uid
> and primary gid, and also for some username conversions (not sure I
> understand all this). But the uid/gid can be obtained directly from the
> sids, which would save the domain lookup in case of rid id-mapping.
> Alternatively maybe it's possible to cache username->info3 in addition to
> sid->info3 and have winbindd (which ultimately handles the getpwnam) use
> 3. in order to convert group sids to unix gids, winbindd would first
> contact the domain to determine the sid type. However, if the sids
> originate in the PAC, don't we already know that they are group sids?
> Given the above, it seems like it's feasible to serve files without ever
> contacting the domain controller, at least under some configurations.
> I'd appreciate any input on the feasibility and "upstreamability" of this.
It does seem feasible to at least use the same principle as
hash-mapping of SIDs to generate UIDs and GIDs to generate them during
login rather than asking winbindd for that info.
It will take some surgery in the various pieces of login code to do
that ... but maybe winbindd already does that if you use the RID or
HASH back-ends for your groupmapping stuff. The only thing it can't
tell without asking the DC, I guess, is what the type of the SID is,
but as you say, we already know that.
More information about the samba-technical