[PATCH] Correctly handle !authoritative in the rpc-based auth backends

Andrew Bartlett abartlet at samba.org
Thu Jun 15 22:24:00 UTC 2017


On Thu, 2017-06-15 at 23:33 +0200, Stefan Metzmacher wrote:
> Am 11.06.2017 um 23:06 schrieb Stefan Metzmacher via samba-technical:
> > Am 10.04.2017 um 09:08 schrieb Stefan Metzmacher via samba-
> > technical:
> > > Hi Andrew,
> > > 
> > > > Thanks.  For the manpage, try:
> > > > 
> > > > By default, and with <smbconfoption name="map untrusted to
> > > > domain">auto</smbconfoption> smbd will defer the mapping
> > > > decision to
> > > > the Comain Controller (DC) of the domain it is a member of, if
> > > > it is
> > > > not a DC.  If the DC indicates that the domain portion is
> > > > unknown, then
> > > > a local authentication is performed.  Standalone servers always
> > > > ignore
> > > > the domain.  This is basically the same as the behavior
> > > > implemented in
> > > > Windows.
> > > > 
> > > > With <smbconfoption name="map untrusted to
> > > > domain">no</smbconfoption>,
> > > > if a client connects to smbd using an untrusted domain name,
> > > > such as
> > > >      BOGUS\user, smbd replaces the BOGUS domain with it's SAM
> > > > name
> > > > (forcing local authentication) before
> > > >      attempting to authenticate that user.  While this appears
> > > > similar
> > > > to the default behaviour of <smbconfoption name="map untrusted
> > > > to
> > > > domain">auto</smbconfoption>, the difference is that smbd do
> > > > not
> > > > contact any DC first in this case, and so must intuit if the
> > > > domain is
> > > > trusted or not locally. 
> > > >      </para>
> > > >  
> > > >      <para>
> > > > With <smbconfoption name="map untrusted to
> > > > domain">yes</smbconfoption>, smbd provides the
> > > >      legacy behavior matching that of versions of Samba pre
> > > > 3.4: if
> > > > smbd was acting as a domain
> > > >      member server, the BOGUS domain name would instead be
> > > > replaced by
> > > > the
> > > >      primary domain which smbd was a member of.  In this case
> > > > authentication
> > > >      would be deferred off to a DC using the credentials
> > > > DOMAIN\user.  
> > > >      </para>
> > > >  
> > > >      <para>
> > > > +    <smbconfoption name="map untrusted to
> > > > domain">no</smbconfoption>,
> > > > +    was the default up to Samba 4.6.
> > > > +    </para>
> > > > +
> > > > +    <para>
> > > >      When smbd is acting as a standalone server, this parameter
> > > > has no
> > > >      effect.
> > > >      </para>
> > > >  
> > > > 
> > > > Finally, can you think of a situation that which will change
> > > > when you
> > > > change the default in 'docs-xml: change the default for "map
> > > > untrusted
> > > > to domain" to "auto"'?  Would UPNs behave differently?
> > > 
> > > It makes a big difference for one-way trusts, see
> > > https://bugzilla.samba.org/show_bug.cgi?id=8630
> > > 
> > > If you have the following situation:
> > > 
> > > childa.foresta.example.com <-> foresta.example.com <- one-way
> > > forest-trust -> forestb.example.com
> > > 
> > > forestb trusts foresta and we're a member of the domain forestb
> > > (MEMBERB).
> > > 
> > > When we get a get an authentication for CHILDA\userchilda, it
> > > would
> > > get mapped to MEMBERB\userchilda, because winbindd on MEMBERB
> > > doesn't have
> > > CHILDA in the list of trusted domains, it doesn't have
> > > permissions to list
> > > the domains in foresta.
> > > 
> > > The key is that we skip is_trusted_domain() and just blindly pass
> > > the
> > > authentication for CHILDA\userchilda to winbindd and winbindd
> > > just
> > > uses it's default route (the primary domain on a member server)
> > > to forward
> > > it to a DC (e.g. DC-A1) of the domain FORESTB. DC-A1 is able to
> > > establish
> > > a netlogon schannel connection to a DC of FORESTA and call
> > > netr_GetForestTrustInformation(). So DC-A1 know the correct route
> > > to CHILDA.
> > > 
> > > I'll try to add an one-way trust test to autobuild.
> > 
> > After trying to add a test I realized that we can't support such a
> > setup
> > with our current ADDC capabilities yet:-(
> > 
> > However I have some patches for selftest to add a one-way trust,
> > but
> > it's not yet used, but it will make it easier to add tests once
> > I've added support for NTLM trusts.
> > 
> > The two attached patchsets are in private autobuilds currently.
> 
> Some selftest patches are already in master, the rest needs more
> work.
> 
> As the selftest are not directly attached to the
> bug8630-v4.patches.txt changes, are there any objects against
> the patches bug8630-v4.patches.txt? Sadly it's not possible
> to have regression tests for the problem yet, but it still
> passes all existing tests and fixes a long outstanding real world
> problem...
> 
> I've attached the current state on top of master...
> 
> Please review and push:-)

Thanks.  I'm happy to push it at this point, we certainly want this in
4.7.  Please do make sure to come back with a test once we are able.

Reviewed-by: Andrew Bartlett <abartlet at samba.org>

I'll push it.

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett
https://samba.org/~abartlet/
Authentication Developer, Samba Team         https://samba.org
Samba Development and Support, Catalyst IT   
https://catalyst.net.nz/services/samba



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20170616/219ea1c7/signature.sig>


More information about the samba-technical mailing list