[SAMBA4] LDAP Backend status

[Martin Kühl]

On 8/18/06, Andrew Bartlett <abartlet at samba.org> wrote:
> I wanted to update the list on the status of my work with the Samba4
> LDAP backend.
>
> For the past couple of days, I have been working on a conversion tool,
> to make OpenLDAP (and hopefully FedoraDS) compatible schema from the
> what is stored in Samba4's LDB.
>
> I have also created a mapping file, to allow target version-specific
> mapping of duplicate OIDs, or skipping of problematic objectClass or
> attribute schema elements.
>
> However, the conversion utility doesn't quite work yet.  We will need
> further enhancements to the entryUUID module, to cope with elements that
> appear to hold objectClasses, but are declared as being type OID.  (I
> want to map them to an OID in that module).  In the meantime, I use the
> attached schema, generated with a script and hand-munged.
>
> I need to add some more provision options, so we don't try and add an
> objectGUID to records when it is so forbidden, and to make access
> anonymous, but for now, I use the attached patch.
>
> I use the option 'system:anonymous=true' in the smb.conf, to force
> anonymous access, and therefore avoid authentication issues.  The
> slapd.conf needs to be configured:
>
> include         /etc/openldap/schema/samba4.schema
> include         /etc/openldap/schema/ad.schema
> access to * by * write
> access to * by anonymous write
>
> allow update_anon
>
> My provision command line is:
>
> ./setup/provision --realm=tammy.abartlet.net --domain=tamdom
> --adminpass=samba2 --host-ip=192.168.199.1
> --domain-sid=S-1-5-21-3449274803-1753676318-108097457
> --domain-guid=40fb3386-d14b-4efd-a15c-1ffc3e4f2f9b
> --ldap-backend="ldap://127.0.0.1:2389"
>
> (I have openldap listening on 2389).
>
> I hope with these instructions, someone else may be able to reproduce
> this.

Thanks to your instructions, I also just successfully provisioned
against OpenLDAP.  I got errors (no such object) trying to provision
against a live, empty server however, and had to take an additional
slapadd step along the lines of:

# ./setup/provision --realm=example.com --domain=wind
--adminpass=penguin --host-ip=127.0.0.1
--domain-sid=S-1-5-21-3449274803-1753676318-108097457
--domain-guid=40fb3386-d14b-4efd-a15c-1ffc3e4f2f9b
--ldap-backend="ldap://127.0.0.1:3891" --ldap-base="dc=example,dc=com"
# sudo slapadd -l /home/mkhl/src/soc/prefix/private/example.ldif
# sudo /etc/init.d/ldap start
# ./setup/provision --realm=example.com --domain=wind
--adminpass=penguin --host-ip=127.0.0.1
--domain-sid=S-1-5-21-3449274803-1753676318-108097457
--domain-guid=40fb3386-d14b-4efd-a15c-1ffc3e4f2f9b
--ldap-backend="ldap://127.0.0.1:3891

I also happened to notice that the `distinguishedName' attribute of
the generated domain controller record is that of the template
computer:

# ldbsearch -H "ldap://localhost:3891" -b "cn=BLACK,cn=Domain
Controllers,dc=example,dc=com" -s base distinguishedName
# record 1
dn: cn=BLACK,cn=Domain Controllers,dc=example,dc=com
distinguishedName: cn=TemplateComputer,cn=Templates

I assume this is not intentional?

Thanks,
Martin