[IPA] Attribute Linking and Indexing
Endi Sukma Dewata
edewata at redhat.com
Tue Oct 20 13:38:51 MDT 2009
Andrew (and others who gave me feedbacks),
Thanks for the responses. I dug deeper and it seems that the problem
is caused by the difference in the way OpenLDAP and FDS validate search
base DN. Here's what happens:
When the provisioning tool adds the wellKnownObjects attribute, the
extended_dn_store LDB module will try to find the specified object in
the directory. So it will issue a search operation with this base DN:
On FDS it returns a "no such object" (32) but on OpenLDAP it returns
an "invalid DN" (34). The problem is the module expects to get either
a "no such object" or a "success". The "invalid DN" causes the
provisioning tool to fail.
I tested this against OpenLDAP 2.4.15 and 2.4.19, they produced the
same result. For the FDS I was using version 1.2.3.
If the schema is changed to use DN+Binary syntax, would OpenLDAP
be able to accept such DN in the search base DN?
Since currently neither FDS or OpenLDAP is using the DN+Binary syntax,
does it limit current Samba's functionality?
Would it be better if Samba handles this in the LDB layer instead
of relying on LDAP backend support so any backends will benefit from
Endi S. Dewata
----- "Andrew Bartlett" <abartlet at samba.org> wrote:
> Yeah, the problem here is due to the mapping of attribute types.
> are attributes of DN+Binary syntax, and that creates challenges. If
> of these were ever to be renamed, then we should update the DN
> of these values. They should also in other ways be treated like a DN.
> But telling FDS and OpenLDAP that these are a DN triggers the
> (legitimate) input validation. So we must either define a new type
> both backends, so punt it back to a directory string...
> (BTW, Samba4 on ldb doesn't even handle the update of these links
> rename, but it should)
> Andrew Bartlett
> Andrew Bartlett
> Authentication Developer, Samba Team http://samba.org
> Samba Developer, Cisco Inc.
More information about the samba-technical