[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: search LDAP back-sql entry with two objectclasses (structural and auxiliary)
Hello,
perhaps better title:
can not read attributes of 2nd objectClass via back-sql
UPDATE:
Sorry I found one error: but problem still unsolved.
the ldap_entry_objclasses entry_id should NOT point to my
organizationalUnit field, but to the entry (2nd, see below). SORRY
Two objectClasses: mozillaAbPersonAlpha and inetOrgPerson.
Both in ldap_oc_mappings, one of them defined in ldap_entries, other one
in ldap_entry_objclasses.
Problem: I get only the values from the attributes belonging to the
objectClass defined in ldap_oc_mappings.
Here my new ldapsearch:
(here cn,sn,givenname fields belong to inetOrgPerson)
ldapsearch -LLL -s sub -b 'ou=contacts,ou=contacts,dc=...'
'objectclass=*' -D 'cn=USER' -w PASSWORD -x
dn: ou=contacts,ou=contacts,dc=...
objectClass: organizationalUnit
ou: contacts
dn: cn=NAME Andreas,ou=contacts,ou=contacts,dc=...
objectClass: mozillaAbPersonAlpha
objectClass: inetOrgPerson
c: Deutschland
ou: text
st: text
mail:
pager: title: mobile: nsAIMid: birthDay: birthYear: homePhone:
birthMonth: postalCode: description: displayName: mozillaCustom1:
mozillaCustom2: mozillaCustom3: mozillaCustom4: mozillaHomeUrl:
mozillaWorkUrl: mozillaNickname: telephoneNumber: mozillaHomeState:
mozillaHomeStreet: mozillaSecondEmail: mozillaWorkStreet2:
mozillaHomePostalCode: mozillaHomeCountryName: facsimileTelephoneNumber:
Would it help to post the output from this search with "-d 65535"
option? I am not sure if I have found all positions with the password is
in this output. But here a small part:
ld 0x9e5a278 response count 0
ldap_chkResponseList ld 0x9e5a278 msgid 1 all 1
ldap_chkResponseList returns ld 0x9e5a278 NULL
ldap_int_select
read1msg: ld 0x9e5a278 msgid 1 all 1
ber_get_next
ldap_read: want=8, got=8
TEXT
ldap_read: want=6, got=6
TEXT
ber_get_next: tag 0x30 len 12 contents:
ber_dump: TEXT
read1msg: ld 0x9e5a278 msgid 1 message type bind
ber_scanf fmt ({eAA) ber:
ber_dump: TEXT
read1msg: ld 0x9e5a278 0 new referrals
read1msg: mark request completed, ld 0x9e5a278 msgid 1
request done: ld 0x9e5a278 msgid 1
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 1, msgid 1)
ldap_free_connection 0 1
ldap_free_connection: refcnt 1
ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_dump: TEXT
ber_scanf fmt (}) ber:
ber_dump: buf=0x9e63d88 ptr=0x9e63d94 end=0x9e63d94 len=0
ldap_msgfree
ldap_search_ext
put_filter: "objectclass=*"
put_filter: default
put_simple_filter: "objectclass=*"
ldap_build_search_req ATTRS: 2
ldap_send_initial_request
ldap_send_server_request
ber_scanf fmt ({it) ber:
Sorry for second trial, thanks and greetings,
Andreas
Am 16.02.2011 02:06, schrieb Andreas Härtel:
> Hello,
>
> I am running a LDAP server on a debian system with a mySQL database as
> backend.
>
> slapd-version:
> $OpenLDAP: slapd 2.4.11 (Jul 24 2010 08:14:20)
> $@murphy:/build/buildd-openldap_2.4.11-1+lenny2-i386-H5BDjb/openldap-2.4.11/debian/build/servers/slapd
>
> mysql-version:
> mysql Ver 14.12 Distrib 5.0.51a, for debian-linux-gnu (i486) using
> readline 5.2
>
> Everything is running fine if I am searching the LDAP tree for data
> containing only one objectClass (inetOrgPerson). Now I have add a second
> auxiliary objectClass (mozillaAbPersonAlpha) to my data via
> ldap_entry_objclasses table in the mySQL database, but a search only
> results in the three inetOrgPerson fields I have set:
>
> ldapsearch -LLL -s sub -b 'ou=contacts,ou=contacts,dc=...'
> 'objectclass=*' -D 'cn=USER' -w unsafe-password -x
> dn: ou=contacts,ou=contacts,dc=...
> objectClass: organizationalUnit
> objectClass: inetOrgPerson
> objectClass: mozillaAbPersonAlpha
> ou: contacts
>
> dn: cn=Name Firstname,ou=contacts,ou=contacts,dc=...
> objectClass: inetOrgPerson
> cn: Name Firstname
> sn: Name
> givenName: Firstname
>
> If I switch the dependency in the ldap_entries table from inetOrgPerson
> to the mozilla scheme, I get the mozilla fields but - e.g. in
> phpldapadmin - I can not see any data (also in my thunderbird
> addressbook). My opinion: mozilla scheme is not structural.
>
> Perhaps this old mailing-list entry gives an answer but - for me myself
> - no solution:
> http://www.openldap.org/lists/openldap-software/200403/msg00303.html
>
> Hope, someone has any idea about this problem ... !?
> Tanks a lot,
>
> Andreas
>
>
>
>
> My /etc/ldap/slapd.conf file (parts of it):
> #################################################################
> include /etc/ldap/schema/core.schema
> include /etc/ldap/schema/cosine.schema
> include /etc/ldap/schema/nis.schema
> include /etc/ldap/schema/inetorgperson.schema
> include /etc/ldap/schema/extension.schema
> include /etc/ldap/schema/mozillaAbPersonAlpha.schema
>
> pidfile /var/run/slapd/slapd.pid
> argsfile /var/run/slapd/slapd.args
> loglevel 256
> modulepath /usr/lib/ldap
> moduleload back_hdb
> moduleload back_sql
>
> sizelimit 500
> tool-threads 1
>
> backend hdb
> backend sql
>
> database sql
>
> suffix "ou=contacts,ou=contacts,dc=...
> dbname contacts
> dbhost localhost
> dbuser myuser
> dbpasswd mypassword
> lastmod off
> has_ldapinfo_dn_ru no
> upper_func "upper"
>
> access to dn.subtree="ou=contacts,ou=contacts,dc=...
> by dn="cn=admin,dc=..." peername.ip=127.0.0.1 write
> by dn="cn=user" read
> by * none
> #################################################################
>
> I thought about ataching my database entries but this could be too long.
> If there should be questions about it, please let me know.