Storing Users LDAP Passwords

When you say "limit this to either never or ..." do you mean that you hope to implement a method where you can opt to not store the password at all? The ability to check a box somewhere indicating that the password will not be stored or cached locally is important to us.

Our application serves as a tool in research / academic institutions. We use their LDAP or AD for authentication, when an SSO alternative doesn't exist. When going through IT/security audits with these prospective clients, it seems like the primary roadblock to cross is always how we are dealing with their passwords. Among my standard response verbiage here, I highlight the fact that the password is never stored or logged on our servers, encrypted or not. In other words, if we were hacked, no one could get login credentials (even encrypted) for their users cause we don't have em!

I think this is pretty important to maintain. It's rare to find an institution that is the least bit cavalier on this point. And in the last two years, we've even seen our more relaxed clients implement stricter and more intensive security requirements around password handling. More and more people are moving away from directory based authentication altogether toward SSO. Those sticking with LDAP and AD for authentication are implementing stronger security controls, access controlled reader accounts, SASL certificate binding/authentication, etc.

Just food for thought.

I never understood a use case for this in years of working with LDAP Integration either. When would you ever need the store the user's password within the session?

The user object should have the functionality to pull anything needed from LDAP, but why would the password itself ever be needed?

I can see that if you need to update/change ldap setting you would need to connect to the ldap server other then the initial connection. I guess the idea of attaching the password to the user profile depends on the finally structure of the connection.

Thanks
Robert

IIRC, this was also required in ldap_integration when the service/machine account has read-only access and changes to user data are being written back to LDAP. I would probably favor storing it in the session in that case, because most users would only have permission to mess up their own info. That being said, I will probably never write data back to LDAP in my sites, since Drupal would never be the source for LDAP data changes in our identity management configuration.

I understand that saving a ldap password into our drupal db, is a HUGE security issue, BUT how do you handle the following scenario:

I have a client who has a Intranet and Internet presence.
They want their internal audience(employees and contractors), who login to the network via AD and LDAP, to have edit functionality on the Internet Site(sitting in the DMZ). The Intranet site is simple because it can bind to the LDAP server. The internet is more difficult because, the server is in the DMZ. No net-sys admin is going to permit a FW rule allowing access to the LDAP Server. So how do you accommodate the client who doesn't want their internal audience to have two passwords to maintain?

I can share the users table, between the two Drupal installs, but without bind ability, the external site would have a different password than the internal one. which wouldn't update when the password is changed in LDAP.

Thoughts?

This whole "feature" sounds scary to me. I think we should strongly suggest the machine account approach. I understand we should support alternative setups, but at some point security should be obtained through proper design, not overly complex application logic.