LDAP servers store passwords using hash function, optionally salted to stymie simple dictionary attacks. OpenLDAP details this in their documentation, section 14.4 "Password Storage" at [1].

I've seen a number of issues in the queue that seem to start out talking about encoding passwords, but then seem to become about decrypting them for binding purposes. THIS ISSUE IS NOT ABOUT PASSWORDS FOR BINDING USED BY SERVICE ACCOUNTS. This is for saving the passwords of site users in LDAP.

The old LDAP Integration module had the option, on a per-server basis, to specify the password encryption type. This one should have the same ability.

[1] http://www.openldap.org/doc/admin24/security.html

CommentFileSizeAuthor
#8 ldap_servers_encoded_passwords-1968208-1.patch6.06 KBkenorb
#7 ldap_servers_encoded_passwords-1968208-1 (1).patch5.92 KBkenorb
#1 ldap_servers_encoded_passwords-1968208-1.patch6.25 KBjohn franklin

Comments

john franklin’s picture

john franklin commented
StatusFileSize
new ldap_servers_encoded_passwords-1968208-1.patch6.25 KB

Attached patch adds two fields to the server settings under "LDAP USER TO DRUPAL USER RELATIONSHIP":

- Password attribute (password_attr)
- Password attribute encoding (password_attr_encoding)

LdapServer::modifyLdapEntry() will encode the specified attribute with the specified encoding prior to writing it to the LDAP server.

johnbarclay’s picture

johnbarclay commented
Title: Allow for encrypting of the userPassword field with md5, sha, smd5 or ssha on a per-server basis » LDAP User: Allow for encrypting of the userPassword field with md5, sha, smd5 or ssha on a per-server basis

This is currently implented with tokens in ldap user module. Here is one issue related #1884962: LDAP Users: Password encryption token options available for Provisioning to LDAP of drupal password.. I've renamed this issue. With provisioning to LDAP I prefer the mappings to be stored in LDAP user. There is a need to ldap user to support multiple ldap servers also and a separate issue for that.

john franklin’s picture

john franklin commented

The server objects already track AuthName, AccountName, email and even thumbnail (picture) attributes, but the password, the encoding of which is of primary value to the LDAP servers themselves, belongs in user?

johnbarclay’s picture

johnbarclay commented

Yes. Ldap_user refers to both ldap entry of the user and the corresponding drupal user. Since authname, accountname, email, and thumnail are simply mapping fields from one to another, they should be in ldap_user also. In the Drupal 8 version, we should attempt to get these into ldap_user and make sure ldap user can deal with mulitple servers.

johnbarclay’s picture

johnbarclay commented
Issue summary: View changes

Clarification

Ruth___’s picture

Ruth___ commented

edit: I think I posted this in the wrong issue..
It was intended here: https://drupal.org/node/1884962

I needed another patch to get this working:
modules/ldap/ldap_servers/ldap_servers.tokens.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/modules/ldap/ldap_servers/ldap_servers.tokens.inc b/modules/ldap/ldap_servers/ldap_servers.tokens.inc
index 3b8061d..8fd551f 100644
--- a/modules/ldap/ldap_servers/ldap_servers.tokens.inc
+++ b/modules/ldap/ldap_servers/ldap_servers.tokens.inc
@@ -389,7 +389,7 @@ function ldap_servers_token_tokenize_user_account($user_account, $token_keys = '
$parts = explode('.', $token_key);
$attr_type = $parts[0];
$attr_name = $parts[1];
- $attr_conversion = (isset($parts[2])) ? $parts[1] : 'none';
+ $attr_conversion = (isset($parts[2])) ? $parts[2] : 'none';
$value = FALSE;
$skip = FALSE;

kenorb’s picture

kenorb commented
Issue summary: View changes
Status: Active » Needs review
kenorb’s picture

kenorb commented
StatusFileSize
new ldap_servers_encoded_passwords-1968208-1 (1).patch5.92 KB

Changed ldap_servers_update_7206 to ldap_servers_update_7207.

kenorb’s picture

kenorb commented
Status: Needs review » Reviewed & tested by the community
StatusFileSize
new ldap_servers_encoded_passwords-1968208-1.patch6.06 KB
johnbarclay’s picture

johnbarclay commented
Status: Reviewed & tested by the community » Closed (won't fix)

We can't just keep adding new attributes to the server configuration for every edge case. That is why the ldap user module has the tokens in it, so a field can be mapped and have transformations such as encryption and hashing. LDAP passwords and how they are pushed into an ldap vary from implementation to implementation. If explicit behaviors for passwords are desired outside of the tokens in ldap user, I would suggest an ldap_passowrd module to deal with the variety of ways its approached. Or, more ideally, ldap_openldap, ldap_active_directory, etc. modules to deal with specific ldaps. With the latter approach all the oddities of each ldap could be dealt with such as the memberOf attribute, default configuration values, etc. The latter could simply be features as well instead of actual modules.

Anyway, as I mentioned in #2 and #4 this functionality is elsewhere so I'm closing this issue.

kenorb’s picture

kenorb commented

I think the patch is only for encrypting password stored in features, it's not related anyway how it's stored on the server side.