[Samba4] Using existing samba3 data from an external LDAP with
samba4
Martin Kühl
kuehl at univention.de
Tue Oct 24 15:40:55 GMT 2006
Hi,
The following are notes I've taken while trying to connect a samba4
service
to the samba3 data contained in the LDAP directory of a UCS[1] system.
Goals
=====
Let X be a (UCS) server system where user/group information is stored in
an
LDAP directory according the the samba3 schema and Y be a linux system
with a
samba4 service running.
The goals are to (1) let samba4 store its information in the LDAP
directory on
X and (2) let samba4 reuse the information stored in the LDAP directory
by
other services running on X.
Attempted Solution 1: Mapping via samba3sam
===========================================
1.1: Provision first, map later
-------------------------------
Install the samba4 packages on Y, provision locally without regadring
the LDAP
directory. Then register the directory as an additional partition and
install
a samba3sam mapping from baseDN to the LDAP partition.
Problems:
* After installing the mapping, the data created by provision are
shadowed
with those from the LDAP directory; only data mappable by samba3sam is
available through samba4.
* The hierarchical organization of the directory trees differs; some
kinds of
objects (e.g. groups) might be looked for in the wrong containers.
Limitations of the ldb_map module:
* The ldb_map module "prefers" one of the two linked subtrees,
effectively
shadowing data that existed in the other one once the mapping is in
place.
* It's not possible to create mappings between multiple subtrees for the
same
module (e.g. cn=users,$BASEDN -> cn=users,$LDAP *and* cn=computers,
$BASEDN
-> cn=computers,$LDAP).
1.2: Provision with mapping
---------------------------
Install the samba4 packages, modify provision data so the LDAP tree is
registered as an additional partition and a samba3sam mapping from
baseDN to
the LDAP partition is installed. Provision "locally" with these
changes.
Problems:
* The mapping attempts to map all data, e.g. that below
CN=Configuration, into
the LDAP partition, leading to errors dealing with objectClasses
unknown to
the mapping.
Limitations of the ldb_map module:
* The check whether a record belongs to the mapped partition doesn't
check
namingContext information and succeeds for data outside of it.
* Handling of unknown objectClasses is fragile (IIRC); objectClasses in
general will be problematic once both the mapped and fallback
partition
backends check them.
The above attempts seemed to require too much change in the ldb_map
module, so
we decided to try an alternative route.
Attempted Solution #2: Schema extension
=======================================
2.1: Use the samba4 schema
--------------------------
Install the OpenLDAP-formatted samba4 schema on X and make slapd load
it.
Install the samba4 packages on Y, provision against the LDAP directory
of X.
Samba3sam is not used in the process (yet).
Problems and Workarounds:
* Some of the OIDs/attributes/objectClasses of the samba4 schema
conflict with
the schemas loaded by slapd. (Most of these are duplicates.)
-> Remove conflicting entries from the samba4 schema.
* The "person" objectClass is incompatible: a person object "must"
contain the
"sn" attribute, which isn't set for any samba4 objects. "Person" here
includes users, groups and computers.
-> Make the attribute optional in the "core" schema's "person"
objectClass.
* Provisioning erases all data from the LDAP directory.
-> Change the deletion process so that when provisioning against an LDAP
backend and when the partition to be deleted is the baseDN, erase
only
objects that were added by samba4. Determine this property by
searching
for "objectCategory=*" records.
* The baseDN record is already present in the LDAP directory but is
missing
the objectClasses "domainDNS" and "extensibleObject". Adding the
former is
forbidden in OpenLDAP because it would change the structuralThe
following are notes I've taken while trying to connect a samba4 service
to the samba3 data contained in the LDAP directory of a UCS system.
Goals
=====
Let X be a (UCS) server system where user/group information is stored in
an
LDAP directory according the the samba3 schema and Y be a linux system
with a
samba4 service running.
The goals are to (1) let samba4 store its information in the LDAP
directory on
X and (2) let samba4 reuse the information stored in the LDAP directory
by
other services running on X.
Attempted Solution 1: Mapping via samba3sam
===========================================
1.1: Provision first, map later
-------------------------------
Install the samba4 packages on Y, provision locally without regadring
the LDAP
directory. Then register the directory as an additional partition and
install
a samba3sam mapping from baseDN to the LDAP partition.
Problems:
* After installing the mapping, the data created by provision are
shadowed
with those from the LDAP directory; only data mappable by samba3sam is
available through samba4.
* The hierarchical organization of the directory trees differs; some
kinds of
objects (e.g. groups) might be looked for in the wrong containers.
Limitations of the ldb_map module:
* The ldb_map module "prefers" one of the two linked subtrees,
effectively
shadowing data that existed in the other one once the mapping is in
place.
* It's not possible to create mappings between multiple subtrees for the
same
module (e.g. cn=users,$BASEDN -> cn=users,$LDAP *and* cn=computers,
$BASEDN
-> cn=computers,$LDAP).
1.2: Provision with mapping
---------------------------
Install the samba4 packages, modify provision data so the LDAP tree is
registered as an additional partition and a samba3sam mapping from
baseDN to
the LDAP partition is installed. Provision "locally" with these
changes.
Problems:
* The mapping attempts to map all data, e.g. that below
CN=Configuration, into
the LDAP partition, leading to errors dealing with objectClasses
unknown to
the mapping.
Limitations of the ldb_map module:
* The check whether a record belongs to the mapped partition doesn't
check
namingContext information and succeeds for data outside of it.
* Handling of unknown objectClasses is fragile (IIRC); objectClasses in
general will be problematic once both the mapped and fallback
partition
backends check them.
The above attempts seemed to require too much change in the ldb_map
module, so
we decided to try an alternative route.
Attempted Solution #2: Schema extension
=======================================
2.1: Use the samba4 schema
--------------------------
Install the OpenLDAP-formatted samba4 schema on X and make slapd load
it.
Install the samba4 packages on Y, provision against the LDAP directory
of X.
Samba3sam is not used in the process (yet).
Problems and Workarounds:
* Some of the OIDs/attributes/objectClasses of the samba4 schema
conflict with
the schemas loaded by slapd. (Most of these are duplicates.)
-> Remove conflicting entries from the samba4 schema.
* The "person" objectClass is incompatible: a person object "must"
contain the
"sn" attribute, which isn't set for any samba4 objects. "Person" here
includes users, groups and computers.
-> Make the attribute optional in the "core" schema's "person"
objectClass.
* Provisioning erases all data from the LDAP directory.
-> Change the deletion process so that when provisioning against an LDAP
backend and when the partition to be deleted is the baseDN, erase
only
objects that were added by samba4. Determine this property by
searching
for "objectCategory=*" records.
* The baseDN record is already present in the LDAP directory but is
missing
the objectClasses "domainDNS" and "extensibleObject". Adding the
former is
forbidden in OpenLDAP because it would change the structural
objectClass of
the record.
-> Add the objectClasses and modify the structuralObjectClass attribute
via
slapcat/slapadd.
* Some other records are already present in the LDAP directory.
-> Extract these records (cn=users and cn=computers) into their own
LDIF.
When adding them fails, try to modify the existing records instead
(as with
the baseDN).
The above workarounds (except the first two) are contained in the
attachment
`tp3-ldap.patch'; they fulfill goal (1) but not (2).
2.2: Use the samba4 schema + samba3sam
--------------------------------------
In addition to the steps taken in 2.1, load the samba3sam module during
provision.
Problems and Workarounds:
* The LDAP directory is already used as the backend of the baseDN
partition,
i.e. the mapped and fallback partition coincide.
-> Adapt the samba3sam module to work more like entryUUID: don't use a
fallback partition, use a wildcard "keep" mapping, remove all
"ignore"
mappings. Add an option to provision that adds samba3sam as a
partition
module to the baseDN partition.
* With the samba3sam module loaded, adding the first record from the
"users
and groups" LDIF fails with an "Operations error". This hasn't been
sufficiently debugged yet but seems to occur before the ldb_map module
starts operating.
The above changes can be found in the attached `tp3-samba3sam.patch'.
They
are a first attempt at fulfilling goal (2), but are far from complete.
objectClass of
the record.
-> Add the objectClasses and modify the structuralObjectClass attribute
via
slapcat/slapadd.
* Some other records are already present in the LDAP directory.
-> Extract these records (cn=users and cn=computers) into their own
LDIF.
When adding them fails, try to modify the existing records instead
(as with
the baseDN).
The above workarounds (except the first two) are contained in the
attachment
`tp3-ldap.patch'; they fulfill goal (1) but not (2).
2.2: Use the samba4 schema + samba3sam
--------------------------------------
In addition to the steps taken in 2.1, load the samba3sam module during
provision.
Problems and Workarounds:
* The LDAP directory is already used as the backend of the baseDN
partition,
i.e. the mapped and fallback partition coincide.
-> Adapt the samba3sam module to work more like entryUUID: don't use a
fallback partition, use a wildcard "keep" mapping, remove all
"ignore"
mappings. Add an option to provision that adds samba3sam as a
partition
module to the baseDN partition.
* With the samba3sam module loaded, adding the first record from the
"users
and groups" LDIF fails with an "Operations error". This hasn't been
sufficiently debugged yet but seems to occur before the ldb_map module
starts operating.
The above changes can be found in the attached `tp3-samba3sam.patch'.
They
are a first attempt at fulfilling goal (2), but are far from complete.
Both patches are against the TP3 release code but applied with fuzz
against HEAD last time I checked.
Does anyone have ideas or suggestions about how to solve these problems?
Is solving them of general interest to the project? Is there a plan
for handling existing samba3 data other than vampiring it?
Thanks,
Martin
[1] My results aren't specific to UCS, only to the problem of using
existing data from an external LDAP server.
--
Martin Kühl <kuehl at univention.de> fon: +49 421 22 232-0
Univention GmbH Linux for Your Business fax: +49 421 22 232-99
Mary-Somerville-Str. 1 28359 Bremen http://www.univention.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tp3-ldap.patch
Type: text/x-diff
Size: 24778 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20061024/526667b3/tp3-ldap.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tp3-samba3sam.patch
Type: text/x-diff
Size: 10800 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20061024/526667b3/tp3-samba3sam.bin
More information about the samba-technical
mailing list