External LDAP with multiple CN's?

[rdejean]

All,

We're testing Zimbra. Trying to configure external LDAP auth to our eDirectory server. Can anyone familiar with the LDAP code comment if Zimbra is looking at the cn attribute?

We have a pretty customized schema, and each user has two cn attributes. One is the username, one is Lastname,Firstname. Ie this filter for me returns two cn's:

'(&(objectclass=selueduperson)(cn=w0114869))'
cn: DeJean,Raymond
cn: W0114869

So the error i'm getting from Zimbra is "javax.naming.AuthenticationException: too many results from search filter!" and in zimbra.log " ldapAuthenticate searchFilter returned more then one result: (&(objectclass=seluEduPerson)(cn=w0114869))"

Of course that filter only returns one entry for my user object, but if Zimbra is looking at the two cn's, it might be a problem. As far as i know it is legal to have multiple cn's on a user object. I had this problem with another app (Serena Collage), and the developer's had to issue a patch for this.

I found this code http://cvs.zimbra.com:8080/viewrep/~.../LdapUtil.java
which leads me to believe it may be something with the call to the getNameinNamespace function.

Can anyone comment on this? Can i turn on any debug to see what the resultDN is? Is there a way to get Zimbra to use another attribute instead of cn? Thanks for any info... Zimbra looks pretty promising so i'd like to get this working.

ray

[schemers]

That error shouldn't have anything to do with one entry having multiple attrs, it is saying that multiple entries are getting returned from the search filter, when one and only one has to be returned, otherwise the operation could be ambigiouus (i.e.,authing with the same "username" twice could result in two different DN's being used for the bind, which could lead to confusion).

Is the CN attr actually your DN as well? That might be what is causing the problem. If so, I'll have to think about how to determine that the two seperate entries returned from the search are actually one and the same.

[rdejean]

Is the CN attr actually your DN as well? That might be what is causing the problem. If so, I'll have to think about how to determine that the two seperate entries returned from the search are actually one and the same

I'm not sure if the CN is actually the DN. When i try to remove one of the cn attrs, i receive a 'Operation not allowed on RDN' error message. I have run an ldapsearch using the same filter and search base as i have in Zimbra. Below is the result of ldapsearch. I am using the same ldapproxy bind account in zimbra as well. I also did a tcpdump capture, and ethereal shows the LDAP query/results and i dont see any LDAP errors in the capture.


[01:46am zrd@cliffy W0114869 (1022)]$ldapsearch -h ldap4.csd.selu.edu -D cn=ldapproxy,ou=admin,o=slucsd -w xxxxxx -x -b o=slucsd -s sub '(&(objectclass=selueduperson)(cn=w0114869))'
version: 2

#
# filter: (&(objectclass=selueduperson)(cn=w0114869))
# requesting: ALL
#

# W0114869, facstaff, users, slucsd
dn: cn=W0114869,ou=facstaff,ou=users,o=slucsd
sluHoursEnrolled: 0
sluCMSUID: ray
sluUsageAgreement: 11668
sluCurrentAffiliation: STAFF
sluNetStorageDir: cn=NETSTORAGE_WEB,ou=admin,o=slucsd#0#facstaff\w01 14869
sluNetStorageAccess: Y
sluWirelessAccess: Y
sluWirelessCard: 00904b-24af3c
sluPeopleSoftUID: W0114869
sluPeopleSoftUID: RAY
sluLabAccessFlag: Y
sluChallengeResponseAttempts: 0
sluNationalID: 999999999
sluResponse: xxxxx
sluChallenge: my first truck
sluBirthdate: 102176
sendmailvacationmessage: "I'm on vacation"
sendmailforwarddate: 0
sendmaildismaildate: 0
sendmailAliasValue: W0114869
sendmailRewriteValue: ray
sendmailAliasKey: ray
sendmailAliasKey: rdejean
sendmailAliasKey: istu457
sendmailAliasKey: zrd
sendmailAliasKey: xcsd3037
sendmailAliasKey: scsd3037
sendmailAliasKey: Raymond.DeJean
sendmailAliasKey: vpn
shadowExpire: -1
shadowInactive: 30
shadowWarning: 14
shadowMax: 180
shadowLastChange: 13272
loginShell: /bin/bash
homeDirectory: /home/FacStaff/D/W0114869
gecos: Raymond Dejean
gidNumber: 114869
uidNumber: 114869
sluAccessFlag: Y
sluEmailFlag: Y
sluPeopleSoftFlag: Y
eduPersonPrincipalName: 0114869
eduPersonPrimaryAffiliation: STAFF
eduPersonOrgUnitDN: ou=facstaff,ou=users,o=slucsd
eduPersonOrgDN: o=slucsd
eduPersonNickname: Raymond
eduPersonAffiliation: STAFF
eduPersonAffiliation: STUDENT
departmentNumber: 1406
mail: ray@selu.edu
employeeNumber: 0114869
uid: W0114869
uid: istu457
uid: scsd3037
uid: zrd
uid: xcsd3037
uid: ray.dejean
givenName: Raymond
fullName: DeJean,Raymond
title: Systems Programmer
telephoneNumber: 985/549-5980
sn: Dejean
securityEquals: cn=clg_users,ou=collage,ou=groups,ou=users,o=slucs d
postOfficeBox: SLU 10430
passwordUniqueRequired: FALSE
passwordRequired: TRUE
passwordMinimumLength: 5
passwordAllowChange: TRUE
ou: ou=FacStaff,ou=Users,o=slucsd
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: seluEduPerson
objectClass: posixAccount
objectClass: shadowAccount
objectClass: sendmailPerson
objectClass: ndsLoginProperties
objectClass: top
objectClass: eduPerson
loginTime: 20060711054103Z
l: MCCL 103A
ndsHomeDirectory: cn=NETSTORAGE_WEB,ou=admin,o=slucsd#0#facstaff\w01 14869
groupMembership: cn=clg_users,ou=collage,ou=groups,ou=users,o=slucs d
description: Admin Computing Services
cn: DeJean,Raymond
cn: W0114869
ACL: 2#subtree#cn=W0114869,ou=facstaff,ou=users,o=slucs d#[All Attributes Right
s]
ACL: 6#entry#cn=W0114869,ou=facstaff,ou=users,o=slucsd# loginScript
ACL: 2#entry#[Public]#messageServer
ACL: 2#entry#[Root]#groupMembership
ACL: 6#entry#cn=W0114869,ou=facstaff,ou=users,o=slucsd# printJobConfiguration
ACL: 2#entry#[Root]#networkAddress
ACL: 7#entry#cn=W0114869,ou=facstaff,ou=users,o=slucsd# shadowLastChange
ACL: 7#entry#cn=W0114869,ou=facstaff,ou=users,o=slucsd# passwordManagement
ACL: 7#entry#cn=W0114869,ou=facstaff,ou=users,o=slucsd# sendmailAccessKey
ACL: 7#entry#cn=W0114869,ou=facstaff,ou=users,o=slucsd# sendmailAliasValue
ACL: 7#entry#cn=W0114869,ou=facstaff,ou=users,o=slucsd# sendmailvacationmessage
ACL: 7#entry#cn=W0114869,ou=facstaff,ou=users,o=slucsd# sendmailRewriteValue
ACL: 7#entry#cn=W0114869,ou=facstaff,ou=users,o=slucsd# sluChallenge
ACL: 7#entry#cn=W0114869,ou=facstaff,ou=users,o=slucsd# sluResponse
ACL: 7#entry#cn=W0114869,ou=facstaff,ou=users,o=slucsd# sluChallengeResponseAtt
empts

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1


Let me know if this helps of if you need more info. Thanks.

ray

[schemers]

Looks like the CN is part of the DN:

dn: cn=W0114869,ou=facstaff,ou=users,o=slucsd

Though the LDAP search only appears to be returning one entry. It would seem to strange if JNDI thought there were multiple results, though maybe it is since the CN is part of the DN and there are multiple CNs.

Do people actually login with something like: "W00114869" as their username? And does your filter look something like:

(&(objectclass=selueduperson)(cn=%n))

Your comment about "Is there a way to get Zimbra to use another attribute instead of cn?" confused me a little as well, since you are the one defining the filter and can use whatever attr'd you'd like to search on. The only contstraint is it should return a single entry.

It looks like other attrs (sluPeopleSoftUID/uid/eduPersonPrincipalName) could potentially be used in the search instead of CN if multiple CNs is indeed causing JNDI to think there are multiple entries (I need to try and verify that theory). You could try one of those, if it is supposed to be unique on an entry.

[romulo]

Hello ,

I have problem the same here, but some users auth and others not .

Below is the result of ldapsearch for 2 users:

[root@email ~]# ldapsearch -x uid=romulo
# extended LDIF
#
# LDAPv3
# base <> with scope sub
# filter: uid=romulo
# requesting: ALL
#

# romulo, NI, POA, SJRS
dn: cn=romulo,ou=NI,ou=POA,o=SJRS
loginShell: /bin/sh
homeDirectory: /home/romulo
gidNumber: 1000
uidNumber: 810
uid: romulo
fullName: Romulo Giordani Boschetti
Language: PORTUGUE
sn: romulo
securityEquals: cn=mailAtivo,ou=GRUPOS,ou=LINUX,o=SJRS
securityEquals: cn=IMAtivo,ou=GRUPOS,ou=LINUX,o=SJRS
securityEquals: cn=QUOTA_INSTITUCIONAL,ou=GRUPOS,ou=LINUX,o=SJRS
securityEquals: cn=SREDE,ou=PUBLICO,ou=LISTAS,ou=MAIL,ou=LINUX,o=S JRS
securityEquals: cn=TESTE,ou=PRIVADO,ou=LISTAS,ou=MAIL,ou=LINUX,o=S JRS
securityEquals: cn=catalogoPrivado,ou=GRUPOS,ou=LINUX,o=SJRS
postalAddress: PRIVADO
passwordAllowChange: TRUE
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: Person
objectClass: ndsLoginProperties
objectClass: Top
objectClass: posixAccount
loginTime: 20060717171244Z
groupMembership: cn=mailAtivo,ou=GRUPOS,ou=LINUX,o=SJRS
groupMembership: cn=IMAtivo,ou=GRUPOS,ou=LINUX,o=SJRS
groupMembership: cn=QUOTA_INSTITUCIONAL,ou=GRUPOS,ou=LINUX,o=SJRS
groupMembership: cn=SREDE,ou=PUBLICO,ou=LISTAS,ou=MAIL,ou=LINUX,o=S JRS
groupMembership: cn=TESTE,ou=PRIVADO,ou=LISTAS,ou=MAIL,ou=LINUX,o=S JRS
groupMembership: cn=catalogoPrivado,ou=GRUPOS,ou=LINUX,o=SJRS
cn: romulo
ACL: 2#subtree#cn=romulo,ou=NI,ou=POA,o=SJRS#[All Attributes Rights]
ACL: 6#entry#cn=romulo,ou=NI,ou=POA,o=SJRS#loginScript
ACL: 2#entry#[Public]#messageServer
ACL: 2#entry#[Root]#groupMembership
ACL: 6#entry#cn=romulo,ou=NI,ou=POA,o=SJRS#printJobConf iguration
ACL: 2#entry#[Root]#networkAddress

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1



And

[root@email ~]# ldapsearch -x uid=groupware
# extended LDIF
#
# LDAPv3
# base <> with scope sub
# filter: uid=groupware
# requesting: ALL
#

# groupware, MAIL, SJRS
dn: cn=groupware,ou=MAIL,o=SJRS
loginShell: /bin/bash
homeDirectory: /home/webmail
gidNumber: 500
uidNumber: 5000
uid: groupware
Language: ENGLISH
sn: groupware
securityEquals: cn=email,o=SJRS
securityEquals: cn=IMAtivo,ou=GRUPOS,ou=LINUX,o=SJRS
securityEquals: cn=mailAtivo,ou=GRUPOS,ou=LINUX,o=SJRS
passwordRequired: FALSE
passwordAllowChange: TRUE
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: Person
objectClass: ndsLoginProperties
objectClass: Top
objectClass: posixAccount
loginTime: 20060717194132Z
groupMembership: cn=email,o=SJRS
groupMembership: cn=IMAtivo,ou=GRUPOS,ou=LINUX,o=SJRS
groupMembership: cn=mailAtivo,ou=GRUPOS,ou=LINUX,o=SJRS
cn: groupware
ACL: 2#subtree#cn=groupware,ou=MAIL,o=SJRS#[All Attributes Rights]
ACL: 6#entry#cn=groupware,ou=MAIL,o=SJRS#loginScript
ACL: 2#entry#[Public]#messageServer
ACL: 2#entry#[Root]#groupMembership
ACL: 6#entry#cn=groupware,ou=MAIL,o=SJRS#printJobConfig uration
ACL: 2#entry#[Root]#networkAddress

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1


I.e: The user "groupware" auth normally, but user "romulo" it returns t error below :

javax.naming.AuthenticationException: too many results from search filter!
at com.zimbra.cs.account.ldap.LdapUtil.ldapAuthentica te(LdapUtil.java:274)
at com.zimbra.cs.account.ldap.Check.checkAuthConfig(C heck.java:152)
at com.zimbra.cs.service.admin.CheckAuthConfig.handle (CheckAuthConfig.java:53)
at com.zimbra.soap.SoapEngine.dispatchRequest(SoapEng ine.java:255)
at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.jav a:163)
at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.jav a:84)
at com.zimbra.soap.SoapServlet.doPost(SoapServlet.jav a:228)
at javax.servlet.http.HttpServlet.service(HttpServlet .java:709)
at com.zimbra.cs.servlet.ZimbraServlet.service(Zimbra Servlet.java:154)
at javax.servlet.http.HttpServlet.service(HttpServlet .java:802)
at org.apache.catalina.core.ApplicationFilterChain.in ternalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.do Filter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invo ke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invo ke(StandardContextValve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke( StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invok e(StandardEngineValve.java:107)
at org.apache.catalina.valves.AccessLogValve.invoke(A ccessLogValve.java:541)
at org.apache.catalina.connector.CoyoteAdapter.servic e(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(H ttp11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11 ConnectionHandler.processConnection(Http11BaseProt ocol.java:667)
at org.apache.tomcat.util.net.PoolTcpEndpoint.process Socket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThr ead.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlR unnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)



Thanks.

Rômulo Giordani Boschetti

[schemers]

Rômulo, what are the values you are putting it for search base and search filter in the admin UI?

Also, can you look in zimbra.log for:

"ldapAuthenticate searchFilter returned more then one result: ..."

And post that?

thanks.

[romulo]

Hi schemers,

I find the problem. It is in LDAP search, because implementation deref alias = always.

Example :
"ldapsearch -a always "

In NOVELL Edirectory is common the use of de aliases in different OUs.

What I made was to point for the respective OU (in the BASE search) that only contains ALIASES, and was OK.

I think that could have an option to choose if wants or not to deref alias.

Example :
"ldapsearch -a never "

thanks.

[ari]

Romulo,

This is an ancient thread, but just in case any Novell eDirectory administrators are running into the same issue, you can tell Zimbra NOT to dereference aliases with the following command:

zmlocalconfig -e ldap_deref_aliases=never

- Ari

ari@zimbra.com