[Samba] samba-tool domain classicupgrade with LDAP backend

Juan Asensio Sánchez okelet at gmail.com
Fri Jan 4 02:18:42 MST 2013


2013/1/4 Andrew Bartlett <abartlet at samba.org>

> On Fri, 2013-01-04 at 08:57 +0100, Juan Asensio Sánchez wrote:
> > Hi
> >
> >
> > I forgot to explain my scenario... I have one Samba3 test-production
> > with LDAP backend (it's a test server, but used intensively), so to
> > make the tests I created a new virtual machine in a separated/isolated
> > network. This is a clean CentOS 6.3 machine, just installed the
> > compile dependencies and then compile and install Samba; I didn't
> > modify resolv.conf, neither nscd.conf, so the name resolution is using
> > an "official" DNS server. After posting the message, I continued
> > investigating and I found this message
> >
> https://lists.samba.org/archive/samba-technical/2012-September/086979.html,
> where the user reports the same problem than me. The solution there is to
> use the IP address instead of the DNS name, and he says that the problem
> can be due to his configuration, but I have the same problem... so I could
> think this is bug, not a server configuration problem I can connect
> perfectly to the LDAP server, use ldapsearch command, etc. Indeed, the
> script retrieves correctly the users, but only fails when exporting the
> Posix attributes).
> What is your 'name resolve order' parameter set to?
name resolve order = wins lmhosts hosts bcast

(Samba3 is not installed in the new virtual machine, just copied smb.conf
and tdb files; smb.conf is configured to make the server act as a PDC using
the LDAP server in other machine)

> > The problem with us about "ldap group suffix" is that our LDAP has
> > multiple organizations, each one with their own users and groups:
> >
> >
> > dc=myorg,dc=es
> >
> > - o=suborg1,dc=myorg,dc=es
> >
> > - - ou=People,o=suborg1,dc=myorg,dc=es
> > - - ou=Groups,o=suborg1,dc=myorg,dc=es
> > - o=suborg2,dc=myorg,dc=es
> > - - ou=People,o=suborg2,dc=myorg,dc=es
> > - - ou=Groups,o=suborg2,dc=myorg,dc=es
> > ...
> >
> >
> > So, in our Samba3 configuration we have "ldap suffix" to
> > "dc=myorg,dc=es" but "ldap group suffix" to "ou=Groups,o=suborg1" (for
> > the Samba3 domain controller for suborg1; each suborganization has its
> > own domain under its tree and its own domain controller using that
> > domain). Then, all users (from any suborganization) can login in any
> > organization/domain/domain controller (we have resolved the problem
> > with SIDs from one domain to another using a plugin in the 389DS LDAP
> > server).
> why is your ldap suffix 'dc=myorg,dc=es' and not
> 'o=suborg1,dc=myorg,dc=es'?

Because we want all users from the rest of organizations can login in any
domain, so the user search base is set to the entire organization, but the
group search base is set to the group from the organization; so, the users
are global to the organization (from the point of view of Samba, as they
really are in the ou=People,o=XXXXX,dc=myorg,dc=es), but groups (and
machines) are locally to the suborganization (users SIDs are changed
dynamically to match the SambaSid of the domain where the user is logging
in, although he belongs to another domain; the path to 389DS LDAP Server I
refer previously). This is a requisite of the client.

> Either way, the migration script expects a directory layout at least
> somewhat near the typical described in our documentation and populated
> with either the ldapsam:edixposix tool or smbldap-tools.  As you move
> beyond that, the ability of a standardised script to cope drastically
> decreases.
> I'm very happy for the script to try and cope with more diverse
> configurations, if you wish to propose patches however.  I'm keen for it
> to import any additional attributes for which we have matching schema,
> for example (not just the posix attributes).
I know the particularities of our organization, so I don't expect the
script to match all our requisites. As you said, we have made a lot of
modifications in the source LDAP schema, so we would need to write
additional scripts to add the schema and re-sync the new object classes and
attributes to the users in Samba4.

> > Our target (is and here comes my big doubt) is to configure Samba4 to
> > host multiple domains under the same forest, replicating our current
> > environment and stablishing trust relationships between the domains.
> > Is this possible? How should I do it?
> Samba as an AD DC does not support either being or hosting a subdomain,
> nor the trust relationships needed between those domains.  This remains
> a future development task.
> A small amount of support exists for inter-realm trusts, trusts with
> Samba classic domains and kerberos trusts, but what little support
> exists here is experimental and undocumented, existing mostly because it
> fell out of other work.
> Andrew Bartlett
For now, we are just testing, because Samba4 is a big step, to unify all
services that AD provides (LDAP, domain, DNS, Kerberos) without patching
lot of external services to make a Samba3 domain work correct but
defective. Perhaps we could ask the client to change the internal
organization, but it's not easy, due to the internal structure (38
sub-organizations, 60.000 users, 5.000 groups, 60 LDAP/Samba servers,

I will continue testing and reporting the results... Now I have more
problems, but I will open a new thread to not mix different subjects.


>  --
> Andrew Bartlett                                http://samba.org/~abartlet/
> Authentication Developer, Samba Team           http://samba.org

More information about the samba mailing list