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

+ Reply to Thread
Results 1 to 5 of 5

Thread: ldap user/machine suffix

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

    Volker

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.5 (GNU/Linux)

    iD8DBQFIYAUqUzqjrWwMRl0RAm5/AJoCAvWaKj6GLG/GXLnPX6iEfFk7twCghf1F
    rHzS129oGPnG2bu5djqaP9g=
    =dBFN
    -----END PGP SIGNATURE-----


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

    I wouldn't like to break the current behavoir by default if possible.

    Simo.

    --
    Simo Sorce
    Samba Team GPL Compliance Officer
    Senior Software Engineer at Red Hat Inc.


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


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


    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.


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

    Do you have a reference for that?

    Volker

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.5 (GNU/Linux)

    iD8DBQFIYCQ+UzqjrWwMRl0RAgSJAJ45xc/6Hwb65hEN51JwORpbIRgZYACeL/iF
    ehjZmdLi3DX9NMJLoD/c+h8=
    =XzlJ
    -----END PGP SIGNATURE-----


+ Reply to Thread