It is about how you interpret what they are writing. They are not saying you should not hash and should store passwords in plain text. What it is saying is that the value you write into LDAP is not hashed or encrypted. This is like the situation you have with a normal database. You can define a column called password and you can either tell the database to encrypt that column or not. You can then stick data in that column, which may be encrypted/hashed or plain text. If you define the column as being encrypted, then data is encrypted as it is written to the column and will be decrypted when it is read from it. If you are storing hashes of a password, that hash will also be encrypted and will require decrypting before it can be used. In general, database encryption is about protecting data exported in data dumps etc. It is a bit like disk encryption in that once you have access to the database tables, the encryption/decryption is done behind the scenes and you don't see it. However, if someone manages to access a dump of the data or gets access to the table datafile on disk, they won't be able to read the information.
Note the definition of password attributes as being stored in an octet string syntax. This format is defined to support the full range of characters you will encounter in hashed passwords. What the best practice is saying is that LDAP stores the value you give it 'as is' without any further encryption or hashing. It is the duty of the software which manages this data to do whatever hashing you want
The 'L' is LDAP stands for lightweight. An LDAP server typically sees lots of reads with far fewer writes. It is designed to handle lots of queries and tries to ensure good performance by keeping it simple. Adding encryption creates additional unnecessary overhead. If the password attribute was encrypted, then all queries would need to decrypt that information, degrading performance.
LDAP also keeps things simple by not providing a management interface. It is essentially a defined tree of attributes and values whose primary role is to answer queries. To further re-inforce this, you will often find that in high-demand environments, you will have a master LDAP server where all the writes/updates are sent and slave/replicaiton servers where all the queries are sent. When you write to the master, if will forward on the changes to the slaves.
Management of the data is usually performed by some other program. For example, at our site, we have a perl program which receives data from our IAM system. It then takes this data, applies some business rules and writes the results to the LDAP master. The perl program performs the hashes of the passwords (we actualy need to support multiple hash types for each password because not every application understands the same hashing algorithm. This hashing also adds a salt.
When a client queries the LDAP server, it will just get whatever is stored in the attribute. With passwords, the data stored includes details of what type of hash has been used. Of course, for binds to work, the LDAP server must understand at least one of the hashes being used in order to perform the bind.
In our case, the main hash we use is SHA-512. References to MD5, SHA1, Crypt etc are outdated and should not be used. This is another example of the advantage of this approach. We used to use SHA-1 and even Crypt once upon a time. We could update to a newer hashiing algorithm easily without having to worry too much about LDAP and versions etc.
