While s3 is in ADS member server mode, the logic of listing domain users and groups in one-way trusts is reversed

Joshua Hawkinson jhawkinson at overlandstorage.com
Tue Apr 10 11:43:59 MDT 2012

Hiya guys!

                Just to tie off here... The reason why proper winbindd enumeration was important to us is that we used its ability to enumerate users and groups for to present lists of objects for administrative purposes (such as share access, quota, manual mapping, etc). We've decided to take another approach to this by implementing more of an AD style search. In this new approach we will ask the user to select a domain container, and then perform an LDAP search for objects. We found this is necessary because winbindd's enumeration doesn't scale very well to large domains/forests anyways.  In addition to the scalability issue there isn't a good way to stab a credential into winbindd to enumerate users across a one way trust.  The only way I could think to accomplish the winbindd one way trust enumeration is to store a NT style restrict anonymous user for use by winbindd which seems like a horrible plan security wise. With the LDAP based search, we can prompt for credentials for the restricted domains on demand, which creates a very familiar windows like experience.

                Now, the left over problem.... I'm still not sure why winbindd would traverse one way trusts in the case where the domain we've joined does not trust the domain winbindd is traversing.  It seems that since those domains do not have access to us -- as a file server - we would not care to enumerate them.  In theory as a client we *can* access those other domains, but winbindd doesn't really need to go through the effort and headache to establish communication with those domains in this case.  In a larger distributed enterprise, it can take winbindd some time (minutes to hours) to initialize based on figuring out domains that can't even use the file server.  We are investigating winbindd's domain discovery and trust enumeration to make this more efficient.  The question I pose to the list however:

Is there any reason why it would be preferred to care about a domain as a member server based on an incoming trust alone?

Joshua Hawkinson

From: Joshua Hawkinson
Sent: Friday, March 30, 2012 4:18 PM
To: samba-technical at lists.samba.org
Subject: While s3 is in ADS member server mode, the logic of listing domain users and groups in one-way trusts is reversed

Hello Samba Team,

While evaluating the one way trust support in samba I've noticed that the user / group listing behaviors are not correct.  In a pure windows environment the trusting domain and clients thereof can enumerate users from the trusted domain; this is because users from the trusted domain actually can access resources from the trusting domain so the enumeration is necessary for ShACLS and whatnot. While a Samba server is joined to the trusting domain, it cannot enumerate users and groups from the trusted domain,  but on the other hand is the samba server joins the trusted domain samba can enumerate users from the trusting domain, which makes no sense because users from trusting domain cannot access anything from the trusted domain.  In conclusion it seems that user listing for one way trusts is broken in a fundamental way.
I'm not entirely sure that the "broken" behavior matters to the average samba user as authentication when joined to the trusting domain actually works as it should. In our product setup we utilize Winbinds ability to enumerate users to produce selectable lists for share access control, so in our implementation Winbind produces the list incorrectly no matter which domain we are joined to.  IIRC support for one way trusts was added back in samba 3.0 or 3.2, and I'm having a hard time believing that one way trusts are that uncommon.
All of that aside, I wanted to run this by the team because it seems to oddly broken for it to be out there with no detected bug reports.  Any thoughts on the matter?

Joshua Hawkinson
Overland Storage, Inc.

More information about the samba-technical mailing list