Can smbd serve files without contacting a DC

[Uri Simchoni]

Hi,

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.

(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
that.

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.

Thanks,
Uri.