[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: OpenLDAP with back-sql



Remco Post wrote:

Hi all,

I've been fooling around with back-sql for some time now, and I ran into
a bit of a strange thing.


What version?


I have a postgres database that provides a view called 'posixaccount' which contains all of the fiets that one would expect to find in a posixaccound object, I have a few ldap entries in the ldap_entries table that point to this table, and I can search this table perfectly. Also, there are a few entries in the ldap_entry_objclasses that add the shadowaccount objectclass to these objects.

When I do a ldapsearch for just any objectclass of a posixaccount
objectclass, I get the expecter results:

[sscpremc@collect]~> ldapsearch -x -D 'ou=beowulf,o=sara,c=nl' -W \
'(uid=sscpremc)'
Enter LDAP Password: # extended LDIF
#
# LDAPv3
# base <> with scope sub
# filter: (uid=sscpremc)
# requesting: ALL
#


# sscpremc, beowulf, sara, NL
dn: uid=sscpremc,ou=beowulf,o=sara,c=NL
objectClass: shadowAccount
objectClass: posixAccount
cn: Remco Post
userPassword:: <some password>
uid: sscpremc
shadowLastChange: 0
homeDirectory: /home/sscpremc
gecos: Remco Post,+31 20 592 8026,remco@sara.nl
loginShell: /bin/bash
gidNumber: 50001
uidNumber: 50001

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1


But If I do the same search for a shadowaccount objectclass, I do not get any results unless:

1- dn is explicitly specified in the list of fields requested eg:
`ldapsearch -x -D 'ou=beowulf,o=sara,c=nl' -W \
'(objectclass=shadowaccount)' dn uid userPassword`


Mmmmmh, "dn" is not a valid attribute, and back-sql (and slapd itself)
should quietly ignore it.

2- there is no such list eg: `ldapsearch -x -D 'ou=beowulf,o=sara,c=nl' \
-W '(objectclass=shadowaccount)'`

In all other cases, I get no results returned at all.

This wouldn'd be so bad, if it weren't for all those ldap clients that
play nice and explicitly list all the fields they need, ommiting the dn
field. This works as expected for the 'primairy' objectclass (the one
refered to in the ldap_entries table), but not for the other
objectclasses, the ones listed in the ldap_entry_objclasses table.

Now, it's not unlikely that I'm doing something wrong, I just can't
figure out what.....


If you provide the version, I can try to reproduce and investigate the problem.

p.




SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497