Can smbd serve files without contacting a DC

[Scott Lovenberg]

On Tue, May 5, 2015 at 5:52 AM, Uri Simchoni <urisimchoni at gmail.com> wrote:
>
> 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.


If I'm understanding the situation, I think you want to set your PAM
winbind module to "cached_login = yes" and your smb.conf should have
"winbind offline login = true".  Ref:
https://www.samba.org/samba/docs/man/manpages/pam_winbind.conf.5.html

I'm not sure how cranky KRB will become if tickets expire when there
are issues with the path between the appliance and the core AD
servers.  Also, for what it's worth, the exact situation is pretty
much what read-only domain controllers (RODC) were created for.
Unfortunately, the wiki seems to indicate that Samba's RODC support
isn't complete, but the wiki could also be out of date. Ref:
https://wiki.samba.org/index.php/Join_a_domain_as_a_RODC

-- 
Peace and Blessings,
-Scott.