[PATCH] Start to fix bug 8630

[Andreas Schneider]

On Monday, 2 January 2017 08:55:01 CET Uri Simchoni wrote:
> On 01/01/2017 10:57 PM, Andreas Schneider wrote:
> > On Sunday, 1 January 2017 17:17:47 CET Volker Lendecke wrote:
> >> On Fri, Dec 30, 2016 at 05:01:30PM +0100, Volker Lendecke wrote:
> >>> On Fri, Dec 30, 2016 at 02:50:20PM +0100, Volker Lendecke wrote:
> >>>> The attached patchset is a rewrite of how winbind puts together user
> >>>> information. Its goal is to remove domain_list dependency and make us
> >>>> work better in complex trust scenarios. It is waiting for the last few
> >>>> tests in autobuild, but all the winbind ones have passwd, autobuild
> >>>> has already found some quirks in early versions.
> >>> 
> >>> Gna. Failed in samba.blackbox.wbinfo after 3h22m12s. So more fixups
> >>> needed, but I would still appreciate some review already.
> >> 
> >> This one just survived an autobuild for me. The diff against the
> >> previous version is also attached.
> > 
> > I can review this tomorrow.
> > 
> > 	Andreas
> 
> RB+ me.

First, Volker this is really nice work. Thank you for looking into this!
 
> Can we add a WHATSNEW that documents the slight changes in behavior? The
> ones I spotted were:
> - if the getpw{nam,sid} user has no netsamlogon cache entry, the gecos
> field is now empty (before there was an attempt by the backend to fill
> it up)
> - getgrouplist() nss call (or id utility) returns only the primary group
> id if the user doesn't have a netsamlogon cache entry (i.e. if he hasn't
> logged on, as in the case of "force user" parameter for example).

Yes, this is what we wanted. An 'id' command as root wihtout the user being 
looged in should only display the primary group and nothing else. Whatever we 
collect and display is mostly wrong and confuses our customers. We regularly 
get bug reports for this and need to explain why the groups displayed are 
incomplete or wrong.

> 
> Andreas, do you want to have a look too or shall I push it?
> Thanks,
> Uri.

I'm currently looking over it as Volker and I discussed this some days ago.


The scenario we looked at is the following:


+------------------+                +------------------+
|                  |                |                  |
| FOREST1 DOM ROOT <----------------> FOREST2 DOM ROOT |
|                  |   two-way      |                  |
+------------------+    trust       +--------+---------+
                                             ^
                                             |
        ^                                    |
        |                            +-------+-------+
        |                            |               |
        |                            | CHILD.FOREST1 |
        |                            |               |
        |                            +-------+-------+
        |                                    ^
        |                                    |
        |                                    |
        | LOGIN                         +----+----+
        | FOREST1\Administrator         |         |
        +------------------------+      | WINBIND |
                                        |         |
                                        +---------+




-- 
Andreas Schneider                   GPG-ID: CC014E3D
Samba Team                             asn at samba.org
www.samba.org