[Samba] winbind causing huge timeouts/delays since 4.8

[Rowland Penny]

On Tue, 26 Feb 2019 11:19:45 +0100
Alexander Spannagel via samba <samba at lists.samba.org> wrote:


> > If you only used one database, you would be 100% sure you wouldn't
> > get any clashes.
> >
> Agreed, but not feasible in our company as there are - for good
> reasons 
> - two big server farms spreading across multiple countries. One is
> based on Linux and the other on Windows. The glue between those two
> farms is build upon samba due to it's flexibility,  strength and
> reliability.

Fair enough, I still think you could use one database eventually, but
it is your network and I am sure you don't to do anything that risks it.

> 
> >>
> >>>>>>> There is absolutely no point in having 4 databases (yes there
> >>>>>>> are 4, Unix, sssd, winbind and the ldap lines in smb.conf),
> >>>>>>> they could all be combined in AD.
> >> No it won't work as our windows team doesn't accept schema changes
> >> for unix in AD.
> > 
> > How shall I put this, your windows team is either not telling you
> > the entire truth or is stupid. The entire RFC2307 attributes are
> > part of the standard Windows schema. what isn't added is IDMU and
> > this just makes the Unix attributes tab work in ADUC. You can
> > however use other tools to create Unix users etc.
> > 
> Beside what i mentioned earlier you are rigth that the RFC2307 
> attributes are still around, but reading a blog entry from 2016 in 
> technet it's cleraly stated that one should look on other
> alternatives as it may go in future realease. Here the comment:
> "I am using Windows Server IDMU/NIS Server role today, what should I
> do? We recommend to start planning for alternatives, for example:
> native LDAP, Samba Client, Kerberos or other non-Microsoft options.
> Existing Windows Server 2012 R2 or earlier deployments will continue
> to be supported in accordance with the Microsoft Support lifecycle."
> Taken out of this blog entry:
> https://blogs.technet.microsoft.com/activedirectoryua/2016/02/09/identity-management-for-unix-idmu-is-deprecated-in-windows-server/

All that has been removed is the IDMU scaffold, all the attributes are
still there and I do not think there is any plans to remove them,
mainly because they would be so easy to put back. My guess is that
Microsoft will just pretend they are not there.
 
> introduced patch for Bug 13503 "getpwnam resolves local system
> accounts to AD accounts" with 4.8.4 it may be the same problem. As
> mentioned earlier removing patch for Bug 13503 also resolves seen
> problems.

If this fixes your problem, then great ;-)

> > There is no real problem with using multiple methods in
> > nsswitch.conf, there is just no real point, the first one to
> > produce  a result wins and as sssd & winbind do the same thing, you
> > don't need both.
> > 
> They don't and shouldn't provide same thing in our setup. The main
> jobs in the unix farm can and should be processed while the windows
> farm may in trouble and vice versa.
> The huge delays are seen, when user isn't known to sssd and winbind 
> tries to look that user without explicitly a domain given and the
> option "winbind use default domain" is on it's default of "No" in
> smb.conf.

If you have multiple domains, then you should not use 'winbind use
default domain = yes', you need to configure smb.conf to use these
domains.

> >> I'll try to somehow reconfig idmap as you suggested taking care of
> >> all the trees in our forest and will report back if that changes
> >> the situation.
> >>
> I reconfigured idmap config auccesfuly like this:
>          idmap config * : range = 3000-7999
>          idmap config * : backend = tdb
>          idmap config ops : range = 1000000-1999999
>          idmap config ops : backend = rid
>          idmap config ops2 : range = 2000000-2999999
>          idmap config ops2 : backend = rid
> ...
> 
> But it didn't change the problem with the delayed response or timeout
> of winbind calling "wbinfo -i foo".

At least this proves there is a problem and not a miss-configuration
> 
> One good point about the suggestion - It point to a fix of a
> "problem" seen with autorid:
> The used ID ranges from the pool used for different domains seem to
> vary for servers being member of one of the other domains. Changing
> from autorid to rid looks like the way to fix that as we can
> configure dedicated ranges from the pool per domain and so uid/gid
> resloution will become consitant across all of our domains. :)

This is what I was trying to say, you need different ranges for each
domain. It doesn't matter what winbind backend you use, you must use a
different range for each domain, it is for this reason that I
personally do not see the point to autorid, it doesn't seem to give you
much more than what rid does and neither gives you access to the
RFC2307 attributes.

> 
> I did some more tested about nsswitch.conf:
> 1. removing sss -> no more hangs (independand of shadow configured
> with winbind or not)
> passwd:     files winbind
> shadow:     files # winbind
> group:      files winbind
> 2. removing winbind -> no more hangs
> passwd:     files sss
> shadow:     files sss
> group:      files sss
> 3. exchange winbind/sss - no change, still delays
> passwd:     files winbind sss
> shadow:     files sss
> group:      files winbind sss
> 
> It still looks that either sssd or winbindd (or both) relays/calls
> each other, when no domain is given. I will try to get debug logging 
> correlated to see if and if yes which service calls the other.

They are written by different teams and, in theory, have nothing to do
with each other. sssd does use some of the winbind libary code, so
whether this is causing a possible link, I do not know. 

Rowland