Fóruns

Início » Liferay Portal » English » Liferay Legacy

Visualização combinada Visão plana Exibição em árvore
Tópicos [ Anterior | Próximo ]
Louis DeRobertis
Liferay 4.2.0 and LDAP {CRYPT} passwords
12 de Dezembro de 2006 14:26
Resposta

Louis DeRobertis

Ranking: New Member

Mensagens: 3

Data de entrada: 12 de Dezembro de 2006

Mensagens 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
Michael Young
RE: Liferay 4.2.0 and LDAP {CRYPT} passwords
12 de Dezembro de 2006 17:16
Resposta

Michael Young

LIFERAY STAFF

Ranking: Liferay Master

Mensagens: 843

Data de entrada: 4 de Agosto de 2004

Mensagens recentes

Is CRYPT supported by JSE? If so, we can probably add this type to the properties file.
Louis DeRobertis
RE: Liferay 4.2.0 and LDAP {CRYPT} passwords
13 de Dezembro de 2006 05:42
Resposta

Louis DeRobertis

Ranking: New Member

Mensagens: 3

Data de entrada: 12 de Dezembro de 2006

Mensagens 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
Juan J
RE: Liferay 4.2.0 and LDAP {CRYPT} passwords
10 de Janeiro de 2007 08:23
Resposta

Juan J

Ranking: New Member

Mensagens: 19

Data de entrada: 3 de Maio de 2006

Mensagens 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
M M
RE: Liferay 4.2.0 and LDAP {CRYPT} passwords
11 de Janeiro de 2007 13:13
Resposta

M M

Ranking: New Member

Mensagens: 16

Data de entrada: 26 de Junho de 2006

Mensagens recentes

Juan 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
RE: Liferay 4.2.0 and LDAP {CRYPT} passwords
12 de Janeiro de 2007 08:29
Resposta

Huy Ho

Ranking: Regular Member

Mensagens: 177

Data de entrada: 18 de Abril de 2006

Mensagens 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 emoticon
Michael Young
RE: Liferay 4.2.0 and LDAP {CRYPT} passwords
12 de Janeiro de 2007 10:07
Resposta

Michael Young

LIFERAY STAFF

Ranking: Liferay Master

Mensagens: 843

Data de entrada: 4 de Agosto de 2004

Mensagens recentes

can someone create a jira ticket for this? Thanks. We'll make sure to patch this up.
Juan J
RE: Liferay 4.2.0 and LDAP {CRYPT} passwords
12 de Janeiro de 2007 12:33
Resposta

Juan J

Ranking: New Member

Mensagens: 19

Data de entrada: 3 de Maio de 2006

Mensagens 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 emoticon)

 1
 2252         private static boolean _authenticate(
 3    253                         LdapContext ctx, Properties env, Binding binding, String baseDN,
 4    254                         Attribute userPassword, String password, String companyId,
 5    255                         String userId, String emailAddress)
 6    256                 throws Exception {
 7    257
 8    258                 // Check passwords by either doing a comparison between the passwords or
 9    259                 // by binding to the LDAP server
10    260
11    261
12    262 //              if (userPassword != null) {
13    263                 System.out.println ("I won't let liferay to compare passwords, just force the bind");    264                 if (false) {
14    265                         String ldapPassword = new String((byte[])userPassword.get());
15    266
16    267                         String encryptedPassword = password;
17    268
18    269                         String algorithm = PrefsPropsUtil.getString(
19    270                                 companyId,
20    271                                 PropsUtil.AUTH_IMPL_LDAP_PASSWORD_ENCRYPTION_ALGORITHM);
21    272
22    273                         if (Validator.isNotNull(algorithm)) {
23    274                                 encryptedPassword =
24    275                                         "{" + algorithm + "}" +
25    276                                                 Encryptor.digest(algorithm, password);
26    277                         }
27    278
28    279                         if (!ldapPassword.equals(encryptedPassword)) {
29    280                                 _log.error(
30    281                                         "LDAP password " + ldapPassword +
31    282                                                 " does not match with given password " +
32    283                                                         encryptedPassword + " for user id " + userId);
33    284
34    285                                 return false;
35    286                         }
36    287                 }
37    288                 else {
38    289                         try {
39    290                                 String userDN = binding.getName() + StringPool.COMMA + baseDN;
40    291
41    292                                 env.put(Context.SECURITY_PRINCIPAL, userDN);
42    293                                 env.put(Context.SECURITY_CREDENTIALS, password);
43    294
44    295                                 ctx = new InitialLdapContext(env, null);
45    296                         }
46    297                         catch (Exception e) {
47    298                                 _log.error(
48    299                                         "Failed to bind to the LDAP server with " + userId +
49    300                                                 " " + password, e);
50    301
51    302                                 return false;
52    303                         }
53    304                 }
54    305
55    306                 return true;
56    307         }
M M
RE: Liferay 4.2.0 and LDAP {CRYPT} passwords
15 de Janeiro de 2007 07:14
Resposta

M M

Ranking: New Member

Mensagens: 16

Data de entrada: 26 de Junho de 2006

Mensagens 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
pipe melero
user binding instead of password comparison
13 de Julho de 2007 01:24
Resposta

pipe melero

Ranking: New Member

Mensagens: 22

Data de entrada: 29 de Janeiro de 2007

Mensagens 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
Louis DeRobertis
RE: Liferay 4.2.0 and LDAP {CRYPT} passwords
12 de Janeiro de 2007 11:40
Resposta

Louis DeRobertis

Ranking: New Member

Mensagens: 3

Data de entrada: 12 de Dezembro de 2006

Mensagens recentes

Huy 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 emoticon


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.