samba - Apr 2020 - Prevent `wbinfo -u` from making Winbind unresponsive

On Friday, 3 April 2020 10:46:54 PDT Ralph Boehme wrote:
> Am 4/1/20 um 11:09 PM schrieb Alexey A Nikitin via samba:
> > Is there a way, preferrably without ugly hacks, to prevent this from
happening on accident, by mistake? By this I mean ideally so that Winbind
remains responsive even if someone mistakenly ran `wbinfo -u` or `wbinfo -g`,
but limiting the result sets of these commands or blocking them altogether is
acceptable too.
> 
> well, blocking it altogether by means of a new smb.conf option (maybe
> wbinfo enum users|groups ?) would be trivial.
> 
> It would be interesting to know whether you see the issue with settings
> of winbind max domain connections higher then the default of 1. If so,
> does increasing it to some sane value eg 10 help?
> 
> -slow
> 
> 
Well, looks like setting 'winbindf max domain connections' to a value
above 1 makes 'wbinfo -u' no longer a threat, but it is pretty much
ignored if 'winbind offline logon' is enabled... Can anyone explain why?
Because when auth can be broken so easily--just run 'wbinfo -u', for
which you don't even need elevated privileges--despite offline logon
enabled, that makes one wonder what is even the point of having that option.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.samba.org/pipermail/samba/attachments/20200403/7cc282a7/signature.sig>

On Fri, Apr 03, 2020 at 03:26:42PM -0700, Alexey A Nikitin via samba
wrote:
> On Friday, 3 April 2020 10:46:54 PDT Ralph Boehme wrote:
> > Am 4/1/20 um 11:09 PM schrieb Alexey A Nikitin via samba:
> > > Is there a way, preferrably without ugly hacks, to prevent this
from happening on accident, by mistake? By this I mean ideally so that Winbind
remains responsive even if someone mistakenly ran `wbinfo -u` or `wbinfo -g`,
but limiting the result sets of these commands or blocking them altogether is
acceptable too.
> > 
> > well, blocking it altogether by means of a new smb.conf option (maybe
> > wbinfo enum users|groups ?) would be trivial.
> > 
> > It would be interesting to know whether you see the issue with
settings
> > of winbind max domain connections higher then the default of 1. If so,
> > does increasing it to some sane value eg 10 help?
> > 
> > -slow
> > 
> > 
> 
> Well, looks like setting 'winbindf max domain connections' to a
value above 1 makes 'wbinfo -u'
> no longer a threat, but it is pretty much ignored if 'winbind offline
logon' is enabled...
> Can anyone explain why? Because when auth can be broken so easily--just run
'wbinfo -u',
> for which you don't even need elevated privileges--despite offline
logon enabled,
> that makes one wonder what is even the point of having that option.
Well it *is* in the man page :-) :

docs-xml/smbdotconf/winbind/winbindmaxdomainconnections.xml

  7         <para>This parameter specifies the maximum number of
simultaneous
  8         connections that the
<citerefentry><refentrytitle>winbindd</refentrytitle>
  9         <manvolnum>8</manvolnum></citerefentry> daemon
should open to the
 10         domain controller of one domain.
 11         Setting this parameter to a value greater than 1 can improve
 12         scalability with many simultaneous winbind requests,
 13         some of which might be slow.
 14         </para>
 15         <para>
 16         Note that if <smbconfoption name="winbind offline
logon"/> is set to
 17         <constant>Yes</constant>, then only one
 18         DC connection is allowed per domain, regardless of this setting.

But I'll have to look into why this is. Obviously there's a reason :-).

On Fri, Apr 10, 2020 at 02:37:45PM -0700, Jeremy Allison via samba
wrote:
> On Fri, Apr 03, 2020 at 03:26:42PM -0700, Alexey A Nikitin via samba wrote:
> > On Friday, 3 April 2020 10:46:54 PDT Ralph Boehme wrote:
> > > Am 4/1/20 um 11:09 PM schrieb Alexey A Nikitin via samba:
> > > > Is there a way, preferrably without ugly hacks, to prevent
this from happening on accident, by mistake? By this I mean ideally so that
Winbind remains responsive even if someone mistakenly ran `wbinfo -u` or `wbinfo
-g`, but limiting the result sets of these commands or blocking them altogether
is acceptable too.
> > > 
> > > well, blocking it altogether by means of a new smb.conf option
(maybe
> > > wbinfo enum users|groups ?) would be trivial.
> > > 
> > > It would be interesting to know whether you see the issue with
settings
> > > of winbind max domain connections higher then the default of 1.
If so,
> > > does increasing it to some sane value eg 10 help?
> > > 
> > > -slow
> > > 
> > > 
> > 
> > Well, looks like setting 'winbindf max domain connections' to
a value above 1 makes 'wbinfo -u'
> > no longer a threat, but it is pretty much ignored if 'winbind
offline logon' is enabled...
> > Can anyone explain why? Because when auth can be broken so
easily--just run 'wbinfo -u',
> > for which you don't even need elevated privileges--despite offline
logon enabled,
> > that makes one wonder what is even the point of having that option.
> 
> Well it *is* in the man page :-) :
> 
> docs-xml/smbdotconf/winbind/winbindmaxdomainconnections.xml
> 
>   7         <para>This parameter specifies the maximum number of
simultaneous
>   8         connections that the
<citerefentry><refentrytitle>winbindd</refentrytitle>
>   9         <manvolnum>8</manvolnum></citerefentry>
daemon should open to the
>  10         domain controller of one domain.
>  11         Setting this parameter to a value greater than 1 can improve
>  12         scalability with many simultaneous winbind requests,
>  13         some of which might be slow.
>  14         </para>
>  15         <para>
>  16         Note that if <smbconfoption name="winbind offline
logon"/> is set to
>  17         <constant>Yes</constant>, then only one
>  18         DC connection is allowed per domain, regardless of this
setting.
> 
> But I'll have to look into why this is. Obviously there's a reason
:-).
Aha. Here it is:

commit 9c2fcb689b647be60731ea8ce8abfe22c0e63dde

    This implementation breaks offline logons, as the cached credentials are
    maintained in a child (this needs fixing). So, if the offline logons are
    active, only allow one DC connection.

    Probably the offline logon and the scalable file server cases are

So to make both work, we'll need to fix where the cached credentials
are maintained.

If this use case is important to Amazon, I know of a couple of companies
who you could pay to get this fixed :-). Or we'd also be happy to receive
a patch from you that fixes this limitation !

Cheers,

	Jeremy.

On Friday, 10 April 2020 14:37:45 PDT Jeremy Allison
wrote:
> On Fri, Apr 03, 2020 at 03:26:42PM -0700, Alexey A Nikitin via samba wrote:
> > Well, looks like setting 'winbindf max domain connections' to
a value above 1 makes 'wbinfo -u'
> > no longer a threat, but it is pretty much ignored if 'winbind
offline logon' is enabled...
> > Can anyone explain why? Because when auth can be broken so
easily--just run 'wbinfo -u',
> > for which you don't even need elevated privileges--despite offline
logon enabled,
> > that makes one wonder what is even the point of having that option.
> 
> Well it *is* in the man page :-) :
> 
> docs-xml/smbdotconf/winbind/winbindmaxdomainconnections.xml
> 
>   7         <para>This parameter specifies the maximum number of
simultaneous
>   8         connections that the
<citerefentry><refentrytitle>winbindd</refentrytitle>
>   9         <manvolnum>8</manvolnum></citerefentry>
daemon should open to the
>  10         domain controller of one domain.
>  11         Setting this parameter to a value greater than 1 can improve
>  12         scalability with many simultaneous winbind requests,
>  13         some of which might be slow.
>  14         </para>
>  15         <para>
>  16         Note that if <smbconfoption name="winbind offline
logon"/> is set to
>  17         <constant>Yes</constant>, then only one
>  18         DC connection is allowed per domain, regardless of this
setting.
> 
> But I'll have to look into why this is. Obviously there's a reason
:-).
> 
I did see this snippet when the config options were mentioned. In fact, the very
first thing I did was locate them in the man page. But with all due respect, it
only answers the question of "what", not "why", and my
question is exactly the "why" - why is it that we cannot
simultaneously have multiple connections to DC allowed and still use offline
logon, is there a particular reason for that?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.samba.org/pipermail/samba/attachments/20200413/5d25d517/signature.sig>