Re: ACL userPassword Problem Re-Visited

[Stephan Siano <stephan.siano@suse.de>]

On Thursday, 7. March 2002 03:28, Christine Robertson wrote:
> Hi All,
>
> This is a long post; sorry, but I need to show the traces.
> I have now worked out why, although apparently binding
> successfully as the record DN, I could not see the
> userPassword attribute of my posixAccount record.
> Incidentally, this is OpenLDAP 2.0.22 on FreeBSD 4.5.
>
> The problem lies with our setup.  We have 7 directories,
> 6 with suffixes of the form dc=au,dc=cordoors,dc=com,
> and a master directory of dc=cordoors,dc=com which
> contains references to the other 6 directories,
> thus enabling us to look up records with the generic
> base of "dc=cordoors,dc=com."

Hi,

to clear things a little up:

With your setup you are chasing referrals with simple bind (providing a bind 
dn and a user password). However, the client library is always chasing these 
referrals with an anonymously for security reasons (if it was different, I 
could insert a referral to my own LDAP server into your directory and all 
users would send me their passwords). So you are just doing an anonymous 
search. (you can test this fairly easy, just remove the -C parameter from 
ldapsearch and you won't chase referrals at all).

If you have made sure that those security considerations do not apply to your 
directory (e.g. because only trustwothy administrators are able to write 
entrys into your directory) and you are using your own client (not the 
command line tools that are coming with OpenLDAP), your client code could 
provide a rebind function. That is actually a callback function that does the 
rebind to the server when chasing referrals (that means you will have to 
store the bind dn and the password in a global variable and access it from 
the function). (The API call is ldap_set_rebind_proc).

Another (more secure way) is using SASL authentication. In this case no 
cleartext passwords are sent to the server at all and rebinds are not 
anonymous. The pitfall of this solution is, that the credentials are not in 
the directory, so you have to administer the users in two sources (LDAP and 
the underlying SASL mechanism (e.g. sasldb or Kerberos V)).

Yours
Stephan Siano

-- 
Stephan Siano                           Mail:  Stephan.Siano@suse.de
SuSE Linux AG                           Phone: 06196 50951 31
CU PS DU South TCC UC                   Fax:   06196 409607
Mergenthalerallee 45-47	
D-65760 Eschborn