What was the resolution about why we are talking to DCs when a client authenticates with Kerberos

[Uri Simchoni]

The "shit-loads of DNS" is not my experience. Winbindd is supposed to
keep an open SMB connection (for RPC) and an LDAP connection per
domain. There was bug 11259 that caused an ldap reconnect per request,
if ldap was signed/sealed. After that got fixed, there was one ldap
and 3-4 RPCs per session-setup (typically, that obviously depends on
size of PAC and state of the winbindd cache), and that's what Jeremy
started working on. Once it came down to one ldap + a few RPCs, it
became bearable and dropped in priority, although I would love to see
it work without contacting at all - better scalability etc.


On Wed, Aug 5, 2015 at 5:59 PM, Simo <simo at samba.org> wrote:
> On Wed, 2015-08-05 at 06:56 -0700, Richard Sharpe wrote:
>> On Wed, Aug 5, 2015 at 4:30 AM, Simo <simo at samba.org> wrote:
>> > On Tue, 2015-08-04 at 15:58 -0700, Richard Sharpe wrote:
>> > > Hi folks,
>> > >
>> > > I recall some discussion that we were contacting DCs even when a
>> > > client authenticates with Kerberos 5.
>> > >
>> > > There was a suggestion that we should not be doing that.
>> > >
>> > > Was the investigation of why we are doing it completed? What was
>> > > the
>> > > resolution?
>> >
>> > Define: contacting the DC.
>> > For what operations ?
>>
>> During authentication, when using the client uses Kerberos auth,
>> Samba
>> contacts the DCs.
>>
>> First, it looks up shit-loads of DNS entries, both the IP addresses
>> of
>> the DCs and SRV records. This was causing me problems, see below.
>>
>> Secondly, it uses RPCs for some ops and does LDAP requests. I can be
>> more precise later today when I have access to my captures.
>>
>> The DNS bit was causing problems because the DNS config (internal to
>> the company and not at a customer site, but customers might
>> experience
>> this as well.) was not correct. By mistake we were not using the DNS
>> servers on that subnet and the link between the Colo and the location
>> of the DNS servers was overloaded. This was causing multiple DNS
>> lookup timeouts (3-4 by 5 seconds) and adding 20 seconds to
>> authentication.
>>
>> Since we do not care one whit about SID to UID/GID translation (we
>> use
>> acl_xattr and we do not store those worthless POSIX ACLs) and this is
>> the third gig where we have done that I would much rather that we did
>> not do SID to UID/GID translation.
>>
>> Quick question. How many customers care about SID to UID/GID
>> translation? In my experience, about 1 in a million!
>
> All the ones that use Samba on a normal filesystem, which means all but
> the OEMs you work for :-)
>
> Getting rid of all those requests will not be easy, some samba code is
> crufty and leans a lot on the old RPC skeleton code.
> But it'd be nice to see some cleanup when a server is joined to ADS to
> reduce the amounts of lookups needed.
>
> To avoid SID->UID/GID transalation though, you would have to
> fundamentally alter how samba works. As we need that to create the
> process credentials we use to talk to the kernel. Normal kernels
> understand only UID/GIDs, not SIDs.
>
> I guess you can avoid lookups in most cases with an algorithmic
> IDmapping module, and simply assign both a UID and a GID to every SID
> regardless of "gender" and thus avoid the call to resolve whether a SID
> is a USer or a Group. You would also need to decide how to resolve SID
> to Names, that is done via LDAP calls to the Global Catalog even on
> Windows clients.
>
> Simo.
>
>