I dug around and found the issue. The problem was not the log-in itself, it was the getUserInfo method used for gethering the user's information after the log-in. The error was:
metacat 20140225-15:12:46: [ERROR]: AuthLdap.getUserInfo - Problem getting users:javax.naming.NameNotFoundException: [LDAP: error code 32 - No Such Object]; remaining name 'uid=frenockm,ou=people,dc=piscoweb,dc=org' [edu.ucsb.nceas.metacat.AuthLdap]
If there was an exception in the getuserInfo method, the entire authentication process would fail. The user information is not very critical in the authentication process, so I changed it a little bit - the user information will be not shown rather than the authentication failed if the getuserInfo method throws an exception.
I also took a look at the getUserInfo method to figure out why it threw an exception. In Metacat 2.3.0, this method takes the parameter 'username'-uid=frenockm,o=PISCO,dc=ecoinformatics,dc=org and search the server ldap.ecoinformatics.org to get the information. However, we started to handle the alias in Metacat 2.4.0. We have to replace the username by the alias name which was obtained from the method getAliasedDN. In this case, the user name was replaced by the alias uid=frenockm,ou=people,dc=piscoweb,dc=org and the code threw an exception. For both LTER and UCNRS accounts, the alias name is the same one (e.g., the alias for uid=tao,o=LTER,dc=ecoinformatics,dc=org is uid=tao,o=LTER,dc=ecoinformatics,dc=org), so the log-in for those accounts work. I modified the getAliasedDn method in order to make it work. The method getAliasedDN is for a internal link, not an external referral, so I changed the Context.REFERRAL value from the "follow" to the "ignore" in the method. It works after the modification.
I installed a Metacat instance on Dev. I tested the login for LTER, UCNRS, PISCO, unaffiliated, NCEAS, and Sanparks account. All of them worked.
I committed the modification to both the trunk and 2.4.0 branch.