ldap user/machine suffix

[John H Terpstra]

On Monday 23 June 2008 15:18:50 Volker Lendecke wrote:
> Hi!
>
> 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 :-)
>
> Volker

Quick answer:
------------------
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.


Detailed answer:
---------------------
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 
for trouble.

_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 
center).


2) Stipulations by regulatory supervisors is pushing Samba deployment towards 
Active Directory.

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 
administered.

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 
multi-domain infrastructure.


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 case.

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 
domains.


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.