ldap user/machine suffix - Samba

This is a discussion on ldap user/machine suffix - Samba ; 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') ...

ldap user/machine suffix

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 :-)

Re: ldap user/machine suffix

On Mon, 2008-06-23 at 22:18 +0200, 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 :-)

I think both cases make sense, and we can easily support both by adding
a new parameter called something like "machines search suffix", if set
this would activate a path similar to Jeremy's patch, otherwise the
current behavior would be maintained.

Re: ldap user/machine suffix

On Mon, Jun 23, 2008 at 04:28:30PM -0400, simo wrote:
>
> I think both cases make sense, and we can easily support both by adding
> a new parameter called something like "machines search suffix", if set
> this would activate a path similar to Jeremy's patch, otherwise the
> current behavior would be maintained.

Nope. No New Parameters (tm). This is a special case for a broken
LDAP tree. If it works for that site then they'll have to use it
as a n out-of-tree patch (IMHO).
> I wouldn't like to break the current behavoir by default if possible.

Then let's just leave it alone.

Jeremy.

Re: ldap user/machine suffix

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

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.

Re: ldap user/machine suffix

On Mon, Jun 23, 2008 at 04:56:04PM -0500, John H Terpstra wrote:
> 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.

This is the one thing I don't get, seriously: What is the
difference between a multi-domain AD tree/forest and an
OpenLDAP that has multiple independent subtrees? How can a
government regulation favor the specific Active Directory
Technology over something else? I would really like to see
the technical wording of this requirement and see how we can
match that with a fully standards compliant directory
server but without having to mix all accounts in one bucket.