ldap user/machine suffix
John H Terpstra
jht at samba.org
Mon Jun 23 21:56:04 GMT 2008
On Monday 23 June 2008 15:18:50 Volker Lendecke wrote:
> Jeremy sent me the attached patch for review. He has a
> large site that needs it to work. Essentially, the patch
> introduces the ldap machine and user suffixes to searches
> into LDAP. From my (and some of my customers') point of view
> this would break setups.
> We have two kinds of setups that are "special" in their own
> respect: Jeremy's setup is special in the sense that DC's
> for multiple domains share a common LDAP tree with for
> example multiple machine accounts sharing a name. Thus the
> need for separating in multiple subtrees. "My" setup is
> special in the sense that I have sites that move around
> objects and which depend on objects being created in a
> subtree (i.e. under "ldap machine suffix"), but which can be
> moved later according to organizational needs. They will be
> found later because during searches will always do a full
> subtree search on the "ldap suffix" tree.
> These two kinds of "specialness" can not be satisfied with a
> common set of code, one or the other will not be happy. I
> would argue that sharing LDAP objects and names between
> domains is just too confusion, others might argue that the
> ability to move around objects in LDAP is too confusing,
> this flexibility is not needed.
> So, if I was asked, this patch should not go in, but let the
> battle begin :-)
My vote is to leave this one alone. i.e.: Do NOT fix - but document how to get
around the limitation.
I would like to see this fixed, but not at the risk of breaking a large number
of large installations. So far I know of only 3 sites that are affected by
the present problem.
The real solution is Samba4 with ADS support. Fixing Samba3 is like simply
applying a bandage and duct-tape that ultimately will not hold.
There are several points at issue here:
1) Mulitple domains and Samba3 should NOT share a single LDAP DIT.
Using a single LDAP DIT across multiple Samba3 domains is fundamentally asking
_BUT_ the challenge is that there are governing bodies (think HIPAA and SOX)
that exercise a liberal and inconsistent interpretation of government
regulations that in some parts of the USA stipulate that a diverse group of
public organizations (eg: a group hospitals that have a central point of
administration but where the each site is a separate organization, and
multiple community health centers that are administered by an outsource
2) Stipulations by regulatory supervisors is pushing Samba deployment towards
In every case the topology required by the regulatory supervisors can be met
with Microsoft Active Directory, but in the case of OpenLDAP and Samba
requires use of a single directory tree across all sites that are centrally
By default, Samba does a recursive sub-tree search for user and trust account
information creates a problem with recent releases of the 3.0.x tree. I can
see why we do this, but the fact that we do this now makes it impossible to
use the "net rpc trustdom" tool to create interdoamin trust accounts where
there exist more than two domains in a single shared LDAP DIT. The result is
that LDAP administrative staff must craft their own tools and methods to
create and maintain interdomain trusts.
I agree with the site admins that this is a royal pain in the neck and exposes
them to additional auditing, and for that read cost of maintaining large
3) When the interdomain trust accounts exist Samba is happy.
After the interdomain trust accounts have been manually created in the
respective sub-containers as specified by the "ldap machine suffix", Samba
3.0.30+ works without apparent problems. After the trust account has been
created it appears all further interdomain trust lookups are done by SID, and
that works juse fine.
The problem is limited to creation of the interdomain trust accounts. If we
all agree that this problem is too sensitive to fix, should the manual
work-around be documented?
Does anyone object to documenting how to work around Samba's design
limitations? Or is that a bad idea too?
4) We have a logical paradox in respect of the suffixes.
Samba admins have logically deduced that because they specify in the smb.conf
file separate containers for "ldap user suffix" and "ldap machine suffix"
this means that internally Samba will keep these separate also. This is not
The minimum action that must be taken is to document the fact that the
specification of the different suffixes does NOT limit the search for use and
trust objects. Ergo: Do not share a single DIT across multiple Samba3
5) We generally try not to break older Samba installations by what ever fix we
adopt. Recent changes to how we create interdomain trust accounts has broken
older behavior. How should we document this?
I have tested Jeremy's patch. It does work, in that creation of multiple
interdomain trusts within a single DIT now succeeds. On the other hand, it
appears we still do other searches from the top of the DIT down.
Fixing this may be the right thing to do, but it will involve more time that
we don't have, and it requires careful documentation of the possible impact
of the changes regardless of the decision made.
No matter which way this matter is decided, I will gladly document the
behavior we settle on.
- John T.
More information about the samba-technical