Can smbd serve files without contacting a DC

[Uri Simchoni]

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

My first reaction was "why would the appliance contact the domain? it has
all the information it needs" but then I reviewed the code it according to
my analysis it does contact the domain even if sid->uid and sid->gid does
not require DC connection.


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

IMHO we should always ask winbindd because that's what it's for, but
perhaps if winbindd knew it was a group SID or a user SID in advance, it
could do it more efficiently.


> 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.
>
> --
> Regards,
> Richard Sharpe
> (何以解憂？唯有杜康。--曹操)
>