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

[Richard Sharpe]

On Wed, Aug 5, 2015 at 10:16 AM, Uri Simchoni <urisimchoni at gmail.com> wrote:
> 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.

I am seeing 80+ DNS requests, which might be because we have 5 DCs in
the domain being queried!

However, real customers out there (Fortune 500) are likely to have the
same sort of thing, and it is a big problem when, because someone
screwed up DNS server specification (not wrong, just on a different
subnet) all of a sudden authentication starts failing or taking a long
time.

Windows does not have that problem. Samba does!

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



-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)