Anil SRIVASTAVA wrote: > | > > | > > | > > The compare operation may be used to compare a userPassword. This > | > > might be performed when a client wishes to verify that user's > | > > supplied password is correct. An example of this is an LDAP PAM > | > > | > When you say PAM, are you referring to a Posix compliant system that > | > supports the Open Group defined PAM subsystem? If so, how does the compare > | > operation help? I am having trouble coming up with feasable implemtation > | > where the pam_authenticate back-end procedure does not need to open a new > | > connection to the LDAP server each time it is called. Thus I don't see how > | > that example shows how you can eliminate the overhead of the bind > | operation. > > | > | Several 3-tier applications are using LDAP to perform password based > | authentication. This can be the case of an web-ldap gateway, an Mail server, > | an FTP server...or the LDAP Pluggable Authentication Module (PAM). > | It's true that opening a connection for each authentication doesn't really > | scale. > | Many of these applications open one connection, authenticate themselves and > | just check the user password using a compare operation using the User DN and > | the user password. The compare operation is much faster because you don't > | have to perform extra checking and computing that the bind operation has to > | do. > | > > Does the DS apply the pwdDefaultStorageScheme hash to the password BEFORE the > compare is done? It has to. That's the only way to verify if it is the same password. > All LDAP directory servers don't apply the storage hash > before the compare. If some servers keep a cleartxt version of the password then there is no need to hash it otherwise I don't see how that is possible. > This is done only on a bind. Hence using a compare for > user authentication is not gauranteed to work. > > Anil Srivastava > iPlanet Messaging Server > > | /prasanta
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature