Fórum
Liferay 4.2.0 and LDAP {CRYPT} passwords
Louis DeRobertis, modificado 17 Anos atrás.
Liferay 4.2.0 and LDAP {CRYPT} passwords
New Member Postagens: 3 Data de Entrada: 12/12/06 Postagens Recentes
Hi,
I noticed that MD5 and SHA encrypted passwords are now added in the new release. I've been using pam_ldap and have imported over the old crypt format passwords into the Openldap tables. To keep everything nice and tidy - I'd like to be able to have the user authenticate against the Crypt password.
Can anyone point me in the right direction?
Regards,
Lou
I noticed that MD5 and SHA encrypted passwords are now added in the new release. I've been using pam_ldap and have imported over the old crypt format passwords into the Openldap tables. To keep everything nice and tidy - I'd like to be able to have the user authenticate against the Crypt password.
Can anyone point me in the right direction?
Regards,
Lou
Michael Young, modificado 17 Anos atrás.
RE: Liferay 4.2.0 and LDAP {CRYPT} passwords
Liferay Master Postagens: 846 Data de Entrada: 05/08/04 Postagens Recentes
Is CRYPT supported by JSE? If so, we can probably add this type to the properties file.
Louis DeRobertis, modificado 17 Anos atrás.
RE: Liferay 4.2.0 and LDAP {CRYPT} passwords
New Member Postagens: 3 Data de Entrada: 12/12/06 Postagens Recentes
Thanks for the quick reply - It's great to know that someone's out there ;)
I added:
auth.impl.ldap.password.encryption.algorithm.types=MD5,SHA,CRYPT
to /usr/local/tomcat/common/classes/portal-ext.properties
and the Crypt choice shows up in the LDAP setup section. Upon login failure - the tomcat log file shows:
8:20:20,034 ERROR [Digester:52] java.security.NoSuchAlgorithmException: CRYPT M
essageDigest not available
at sun.security.jca.GetInstance.getInstance(GetInstance.java:142)
at java.security.Security.getImpl(Security.java:658)
at java.security.MessageDigest.getInstance(MessageDigest.java:122)
at com.liferay.portal.kernel.util.Digester.digest(Digester.java:55)
at com.liferay.util.Encryptor.digest(Encryptor.java:148)
at com.liferay.portal.security.auth.LDAPAuth._authenticate(LDAPAuth.java
:271)
at com.liferay.portal.security.auth.LDAPAuth.authenticate(LDAPAuth.java:
218)
<snipping out the rest for brevity>
Is that something that's misconfigured on my end? Or something that I need to look at in the source and recompile?
Lou
I added:
auth.impl.ldap.password.encryption.algorithm.types=MD5,SHA,CRYPT
to /usr/local/tomcat/common/classes/portal-ext.properties
and the Crypt choice shows up in the LDAP setup section. Upon login failure - the tomcat log file shows:
8:20:20,034 ERROR [Digester:52] java.security.NoSuchAlgorithmException: CRYPT M
essageDigest not available
at sun.security.jca.GetInstance.getInstance(GetInstance.java:142)
at java.security.Security.getImpl(Security.java:658)
at java.security.MessageDigest.getInstance(MessageDigest.java:122)
at com.liferay.portal.kernel.util.Digester.digest(Digester.java:55)
at com.liferay.util.Encryptor.digest(Encryptor.java:148)
at com.liferay.portal.security.auth.LDAPAuth._authenticate(LDAPAuth.java
:271)
at com.liferay.portal.security.auth.LDAPAuth.authenticate(LDAPAuth.java:
218)
<snipping out the rest for brevity>
Is that something that's misconfigured on my end? Or something that I need to look at in the source and recompile?
Lou
Juan J, modificado 17 Anos atrás.
RE: Liferay 4.2.0 and LDAP {CRYPT} passwords
New Member Postagens: 19 Data de Entrada: 04/05/06 Postagens Recentes
We had this problem with our LDAP implementation, since some of the users have MD5 while others have CRYPT as their encryption algorithm for password, (due to previous migration of the users directory).
I solved this changing the LDAPAuth class (_authenticate method), to not letting Liferay to (get and) compare the password with the one that user typed, but forcing the authentication with a bind to the LDAP server. That is the way that applications normally work: binding to LDAP to authenticate with some user credentials; indeed this is could done in liferay just commenting a few lines.
I think that liferay team should consider to change the way they are doing the authentication (not comparing passwords, but binding to LDAP with user's credentials), or at least there should be a way to configure the way you want to authenticate. This would be very useful to not be "encryption-dependent".
Please take a look at the _authenticate method, and change the "if-else" block.
Let me know if you have any doubt.
Juan
I solved this changing the LDAPAuth class (_authenticate method), to not letting Liferay to (get and) compare the password with the one that user typed, but forcing the authentication with a bind to the LDAP server. That is the way that applications normally work: binding to LDAP to authenticate with some user credentials; indeed this is could done in liferay just commenting a few lines.
I think that liferay team should consider to change the way they are doing the authentication (not comparing passwords, but binding to LDAP with user's credentials), or at least there should be a way to configure the way you want to authenticate. This would be very useful to not be "encryption-dependent".
Please take a look at the _authenticate method, and change the "if-else" block.
Let me know if you have any doubt.
Juan
M M, modificado 17 Anos atrás.
RE: Liferay 4.2.0 and LDAP {CRYPT} passwords
New Member Postagens: 16 Data de Entrada: 27/06/06 Postagens RecentesJuan J:
I solved this changing the LDAPAuth class (_authenticate method), to not letting Liferay to (get and) compare the password with the one that user typed, but forcing the authentication with a bind to the LDAP server.
Juan:
Would you mind sharing your implementation of this? I agree with you. I tried this approach many months ago and couldn't get it to work. It would be nice to see a different perspective. Thanks in advance!
-M
Huy Ho, modificado 17 Anos atrás.
RE: Liferay 4.2.0 and LDAP {CRYPT} passwords
Regular Member Postagens: 177 Data de Entrada: 19/04/06 Postagens Recentes
I agree with J on this one too. Someone pointed this out when version 4.1 was released. I'd prefer this approach better because we don't need a master account to retrieve passwords, and we certainly prefer not to store the password in the properties file.
One good thing about the current approach is that when you save the LDAP configuration in the UI, it checks to verify that the binding works, otherwise you ended up "locking yourself out" if you can't bind to the ldap server. This was before they patched it so that Omni-admins don't need to verify with Ldap to sign in.
I would suggest Liferay to consider changing LDAP authentication approach to simple binding rather than comparing passwords.
And to verify the LDAP settings, you can have a "test section" with a sample user name and password with a "Check" button. You don't really need to verify the configurations when you do the saving because you can always go back to change the settings using the Omni-admin login.
Something to consider
One good thing about the current approach is that when you save the LDAP configuration in the UI, it checks to verify that the binding works, otherwise you ended up "locking yourself out" if you can't bind to the ldap server. This was before they patched it so that Omni-admins don't need to verify with Ldap to sign in.
I would suggest Liferay to consider changing LDAP authentication approach to simple binding rather than comparing passwords.
And to verify the LDAP settings, you can have a "test section" with a sample user name and password with a "Check" button. You don't really need to verify the configurations when you do the saving because you can always go back to change the settings using the Omni-admin login.
Something to consider
Michael Young, modificado 17 Anos atrás.
RE: Liferay 4.2.0 and LDAP {CRYPT} passwords
Liferay Master Postagens: 846 Data de Entrada: 05/08/04 Postagens Recentes
can someone create a jira ticket for this? Thanks. We'll make sure to patch this up.
Juan J, modificado 17 Anos atrás.
RE: Liferay 4.2.0 and LDAP {CRYPT} passwords
New Member Postagens: 19 Data de Entrada: 04/05/06 Postagens Recentes
Michael, the JIRA ticket is:
http://support.liferay.com/browse/LEP-2003
For those of you interested in a temporal solution (forcing the bind):
com/liferay/portal/security/auth/LDAPAuth.java
CHANGE THE IF-ELSE BLOCK, EITHER COMMENTING OUT THE FIRS PART [if (userPassword != null) { ....}] OR FORCING TO BIND (forcing the "else" with a "if (false)" ... AND I know... not too elegant )
http://support.liferay.com/browse/LEP-2003
For those of you interested in a temporal solution (forcing the bind):
com/liferay/portal/security/auth/LDAPAuth.java
CHANGE THE IF-ELSE BLOCK, EITHER COMMENTING OUT THE FIRS PART [if (userPassword != null) { ....}] OR FORCING TO BIND (forcing the "else" with a "if (false)" ... AND I know... not too elegant )
252 private static boolean _authenticate(
253 LdapContext ctx, Properties env, Binding binding, String baseDN,
254 Attribute userPassword, String password, String companyId,
255 String userId, String emailAddress)
256 throws Exception {
257
258 // Check passwords by either doing a comparison between the passwords or
259 // by binding to the LDAP server
260
261
262 // if (userPassword != null) {
263 System.out.println ("I won't let liferay to compare passwords, just force the bind"); 264 if (false) {
265 String ldapPassword = new String((byte[])userPassword.get());
266
267 String encryptedPassword = password;
268
269 String algorithm = PrefsPropsUtil.getString(
270 companyId,
271 PropsUtil.AUTH_IMPL_LDAP_PASSWORD_ENCRYPTION_ALGORITHM);
272
273 if (Validator.isNotNull(algorithm)) {
274 encryptedPassword =
275 "{" + algorithm + "}" +
276 Encryptor.digest(algorithm, password);
277 }
278
279 if (!ldapPassword.equals(encryptedPassword)) {
280 _log.error(
281 "LDAP password " + ldapPassword +
282 " does not match with given password " +
283 encryptedPassword + " for user id " + userId);
284
285 return false;
286 }
287 }
288 else {
289 try {
290 String userDN = binding.getName() + StringPool.COMMA + baseDN;
291
292 env.put(Context.SECURITY_PRINCIPAL, userDN);
293 env.put(Context.SECURITY_CREDENTIALS, password);
294
295 ctx = new InitialLdapContext(env, null);
296 }
297 catch (Exception e) {
298 _log.error(
299 "Failed to bind to the LDAP server with " + userId +
300 " " + password, e);
301
302 return false;
303 }
304 }
305
306 return true;
307 }
M M, modificado 17 Anos atrás.
RE: Liferay 4.2.0 and LDAP {CRYPT} passwords
New Member Postagens: 16 Data de Entrada: 27/06/06 Postagens Recentes
Hi Juan:
Once this change is made in LDAPAuth, you still have to specify the LDAP provider in portal.properties, and with this set-up there is no password synchronization in LPortal db, correct? Thanks again for the tip!
-M
Once this change is made in LDAPAuth, you still have to specify the LDAP provider in portal.properties, and with this set-up there is no password synchronization in LPortal db, correct? Thanks again for the tip!
-M
pipe melero, modificado 16 Anos atrás.
user binding instead of password comparison
New Member Postagens: 22 Data de Entrada: 29/01/07 Postagens Recentes
Thanks for the tip too!
Anyway, I have noticed that each LDAP server brings out different information to Liferay Portal affecting, for example, to the creation of the user. In my case, OpenLdap didn't retrieve firstName and lastName so I had to insert manually.
regards
Anyway, I have noticed that each LDAP server brings out different information to Liferay Portal affecting, for example, to the creation of the user. In my case, OpenLdap didn't retrieve firstName and lastName so I had to insert manually.
regards
Louis DeRobertis, modificado 17 Anos atrás.
RE: Liferay 4.2.0 and LDAP {CRYPT} passwords
New Member Postagens: 3 Data de Entrada: 12/12/06 Postagens RecentesHuy Ho:
I agree with J on this one too. Someone pointed this out when version 4.1 was released. I'd prefer this approach better because we don't need a master account to retrieve passwords, and we certainly prefer not to store the password in the properties file.
One good thing about the current approach is that when you save the LDAP configuration in the UI, it checks to verify that the binding works, otherwise you ended up "locking yourself out" if you can't bind to the ldap server. This was before they patched it so that Omni-admins don't need to verify with Ldap to sign in.
I would suggest Liferay to consider changing LDAP authentication approach to simple binding rather than comparing passwords.
And to verify the LDAP settings, you can have a "test section" with a sample user name and password with a "Check" button. You don't really need to verify the configurations when you do the saving because you can always go back to change the settings using the Omni-admin login.
Something to consider
This is exactly what I was looking for. The binding to the LDAP server in Liferay would allow us to have a true single sign-on. We've been offering library patrons/staff members free Internet access since 95 (dial-in and email accounts). I was stuck using the password/shadow files until I ported over to LDAP, but still carried over the CRYPT format to make life easier for everyone. The next push in our field is to offer more content that the user can manipulate to make it more relevant to him/herself. The Liferay portal is perfect for this.
Binding to the LDAP server as the user allows us to keep the existing username/password combination, and the guest page allows anyone to get directly to what they want without adding specific content (if they don't have the time). Love the product - and it fits in nicely with what we have and what we'd like to have.