Concering issues others are having with Samba 3.5.10+ and group membership behavior when joined to AD as member servers

[David Disseldorp]

Hi Andrew and Neil,

On Fri, 20 Apr 2012 10:06:09 +1000
Andrew Bartlett <abartlet at samba.org> wrote:

> On Mon, 2012-04-16 at 17:10 -0700, Jeremy Allison wrote:
> > On Mon, Apr 16, 2012 at 11:47:35PM +0000, Goldberg, Neil R. wrote:
...
> > > So we made a patch that does several things.
> > > 1) Re-add the timeout for the netsamlogon_cache, deleting entries that are stale upon fetch (currently piggy-backing on the winbind timeout parameter). Apparently there was once an issue retrieving group lists as complete as the SAMR RPC calls could provide motivating the non-expiration, but in testing we believe those issues have since been addressed.

Separate to uncommenting the lp_winbind_cache_time() based expiry code
in netsamlogon_cache_get(), Jerry initially proposed expiring the cache
based on whether the session was still around:

http://lists.samba.org/archive/samba-technical/2005-November/043891.html

> > > 2) Remove the resource group (domain local) group filtering from the sid_array_from_info3 function, as it was ill-advised and of questionable use.
> > > 3) Remove the reliance on the ADS path of winbind on netsamlogon_cache and have it always query LDAP if the winbind cache is expired.
> > > 
> > > It fixed our problem. Now our group lists are always the same, whether they hit the Winbind cache or not.
> > > 
> > > We did not address the potential bug (not correctly querying the domain for aliases) in the lookup_aliases portion of the MSRPC path in Winbind, because we do not understand it well enough.
> > > 
> > > We have a patch for samba-3.5.10 (which is of interest only to users of RHEL 5.x) which we can provide, or we can apply them to any current clean release.
> > > 
> > > We welcome any feedback about our approach, assumptions, and conclusions.
> > 
> > Wow ! Very comprehensive analysis of the problem !
> > 
> > We would love to see your patches with explainations,
> > to analyze for a future Samba release.

Agreed, Neil please send through these patches.

> > Thanks very much for spending the time to do this !
> 
> I'll need to see the exact patches to be sure, but I fear that some of
> the assumptions are incorrect.  
> 
> At first principals, the only reliable way to get the group membership
> for a user is to request the PAC for the user.  I would be very hesitant
> to move back to using anything other than the last successfully obtained
> PAC.  If we want to move to a timeout, then we should do a kerberos
> S4U2Self to obtain the PAC for an arbitrary user. 

Wouldn't we still need a fallback when S4U2Self is not permitted, via
"act as a part of operating system" or otherwise?

> While it is possible to obtain the group membership of a user in the
> local domain by querying LDAP (just as Samba4 AD queries the local LDB
> on the KDC), in a multi-domain situation, you would need to query both
> domains to get the full group list, as groups may be added from the
> resource domain.
> 
> With MSRPC and SAMR, it is even more difficult - I'm not sure if the
> interfaces can even represent the nested groups. 

The netr_LogonSamLogonEx response includes entries for nested groups in
the samr_RidWithAttribute array, but there's nothing to differentiate
between direct or nested groups.

Cheers, David