Non-admin LDAP user cannot log in

Unable to login as non-admin LDAP user:

When logging into Teaming 2  as a non-admin user being synchronized from eDirectory or Active Directory,  a "HTTP Status 500" error is displayed along with an exception report.

1. Locate the log file that records error exceptions. On Windows, this will be:
   D:\Program Files\Novell\Teaming\apache-tomcat-6.0.18\webapps\ssr\WEB-INF\logs\ssr.log
   On Linux, it will be:
   /opt/novell/teaming/apache-tomcat-6.0.18/logs/catalina.out
2. Look for an entry in the log file which has the same date and time stamp as the failed login. The entry will appear as follows:
   ERROR [http-8080-2] [org.kablink.teaming.module.authentication.impl.AuthenticationModuleImpl] - Authentication failure for zone 1
   org.springframework.dao.IncorrectResultSizeDataAccessException: Incorrect result size: expected 1, actual 2
3. The problem is that there are multiple entries in LDAP for the same username. This username will be the username of the user who failed to log in. The value in the error message will indicate how many LDAP users were found with this name. In the example above, there were two users with the same user name in LDAP.
4. In LDAP (eDirectory or other LDAP server, such as Microsoft Active Directory), locate the objects with this user name, and delete all the duplicates.
   

When Teaming tries to synchronize Teaming users with eDirectory (or other LDAP server) users, it is incapable of resolving multiple users with the same username. When this situation occurs, Teaming refuses to allow any user by that name to log in; instead, on each login attempt, it will throw an exception of the type authentication failure, incorrect result size. This message in the log file indicates how many duplicate users were found in LDAP that matched the user trying to log in.

While the log does not indicate which user was trying to log in, that information should be available because the user will be aware of the login failure, indicated by an HTTP 500 error code. Matching the user's login failure with the message in the log file will allow the administrator to determine which user account is causing the problem, and how many duplicates exist in the LDAP tree.

Resolution is most commonly accomplished by removing the duplicates in the LDAP tree. If the duplicates serve a purpose and need to remain, then the LDAP administrator needs to arrange the tree in such a way that a filter can be applied which will only get the users without their duplicates. For example, if all Teaming user objects can be placed in the same organizational unit in LDAP, then the filter "ou=<name>" can be used to select the desired LDAP objects and none of the duplicates that may appear in other parts of the tree.