Re: TLS works not proper; so does searching

["Pierangelo Masarati" <ando@sys-net.it>]

> Hi Patrick and the rest of you!
>
>> Do you have any user data in ldap? You decide where your user-subtree
>> is when you add it to ldap
>
> Yes, of course. As mentioned I am able to see everything I put in the ldif
> file with this command:
> ldapsearch -h ldap -x -b 'dc=testldap,dc=org'
> That works from localhost as well as from a remote machine. The whole
> output,
> which I expect with TLS too looks like:
>
> # extended LDIF
> #
> # LDAPv3
> # base <dc=testldap,dc=org> with scope sub
> # filter: (objectclass=*)
> # requesting: ALL
> #
>
> # testldap.org
> dn: dc=testldap,dc=org
> objectClass: dcObject
> objectClass: organizationalUnit
> dc: testldap
> ou: testldap
>
> # users, testldap.org
> dn: ou=users,dc=testldap,dc=org
> objectClass: organizationalUnit
> objectClass: top
> ou: users
>
> # John One, users, testldap.org
> dn: cn=John One,ou=users,dc=testldap,dc=org
> objectClass: inetOrgPerson
> objectClass: organizationalPerson
> objectClass: person
> objectClass: top
> cn: John One
> displayName: John
> homePostalAddress: at home
> mail: john.one@mailme.com
> postalCode: 54356
> telephoneNumber: 6323-6798
> sn: One
>
> # Jim Two, users, testldap.org
> dn: cn=Jim Two,ou=users,dc=testldap,dc=org
> objectClass: inetOrgPerson
> objectClass: organizationalPerson
> objectClass: person
> objectClass: top
> cn: Jim Two
> displayName: Jim
> homePostalAddress: at work
> mail: jim.two@mailme.com
> postalCode: 54356
> telephoneNumber: 5245-65354
> sn: Two
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 5
> # numEntries: 4
>
>> and from your other email.
>
> Means what?
>
>> > The server invoked with ldap# /usr/local/libexec/slapd -d9 -h
>> "ldap:///
>> > ldaps:///" shows me:
>>
>> You are starting the server on one machine, and it will only accept
>> connection from the localhost (I believe).
>
> Yes, there is a difference. A local user which issues this:
>
> ldapsearch -v -n -Z -b 'dc=testldap,dc=org'
>
> with one or two Zs gets this:
>
> bash-2.05b$ ldapsearch -v -n -Z -b 'dc=testldap,dc=org'
> ldap_initialize( <DEFAULT> )
> filter: (objectclass=*)
> requesting: ALL
> # extended LDIF
> #
> # LDAPv3
> # base <dc=testldap,dc=org> with scope sub
> # filter: (objectclass=*)
> # requesting: ALL
> #
>
> A remote user:
>
> user@box:~$ ldapsearch -h 192.168.1.22 -v -n -ZZ -b 'dc=testldap,dc=org'
> ldap_init( 192.168.1.22, 0 )
> ldap_start_tls: Connect error (91)
>         additional info: Error in the certificate.
>
>
>> To allow connections from a remote host, start the servers with -h
>> "ldap://fullcomputername";
>
> I did that. Now changes.
>
>> for example -h "ldap://pickle.cc.columbia.edu";, where pickle is the
>> name of the machine.
>>
>> Then when you try to connect from a remote host, use something like
>> ldapsearch -x -H "ldap://pickle.cc.columbia.edu:port"; uid=phr2101
>
> I did:
>
> bash-2.05b$ ldapsearch -x -H "ldap://ldap.uwskoeln.de:389"; uid=Jim
> # extended LDIF
> #
> # LDAPv3
> # base <> with scope sub
> # filter: uid=Jim
> # requesting: ALL
> #
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 1
>
> That puzzles me. What if not "Jim", in my case, is a uid? I experienced
> such
> things with other clients (gq, ldap-browser) too. It is always possible to
> see everything but not parts of it. Pretty annoying if you have more than
> 2
> example users...
>
>> I would suggest first getting everything to work without tls.
>> Then get everything to work with tls on the server only.
>> Finally add the client certificates in at the end.
>
> Yeah, that was my plan too ;) I realize now that there is a problem even
> without TLS.
>
>> Hopefully the above helps.
>
> Helping in a way of discovering new problems. But thanks anyway. I see
> it's a
> long way to the top if you want ldap!
> Do you have an idea why I only can see all or nothing?

there's no "uid" attribute in the entries listed above;
either you didn't provide any value to "uid" at all, or
"uid" is read (and appaerntly search) protected by ACLs.

This has really nothing to do with TLS; fix or clarify
this before going any further.

p.

>
> Greetings,
>
> Oliver.
>
>


-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


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