In general, while attributes may look like attributes in any LDAP system, the password attribute is almost always a special case. Perhaps it is restricted by the LDAP server as a special case. Perhaps ACL's protect it. Perhaps it is write-able, but not readable.
Often there are actually several password attributes (AD has unicodePassword and userPassword), and it kind of depends which is to be used in which case. Novell/NetIQ eDirectory has userPassword, which depends on how you are configured, as to what value is underneath it (RSA keypairs, nspmPassword, or the simple password, which is an even odder case than a simple attribute, as it is stored in pieces across multiple attributes)
Some LDAP servers will let you bind with a hashed value, that matches the hashed value stored and the hashed value might be retrievable, but not reversible.
But the key is, it should not matter. Since every LDAP server is different you need to use the standards approach to LDAP passwords which is to try and Bind as a user with the provided DN and password. And if they do not provide a DN, do a search for uid=Username or cn=username or whatever your naming attribute is, to find the full DN.
Finally, be aware that the LDAP standard says a bind with a blank password will succeed, but as an anonymous connection. So you need to be sure the passwords you allow are not blank, else you will get a successful bind, and possibly let someone in, unwittingly.