external LDAP authentication in M2

Ask questions about your setup or get help installing ZCS server (ZD section below).
Post Reply
jstewart
Posts: 3
Joined: Fri Sep 12, 2014 10:01 pm

external LDAP authentication in M2

Post by jstewart »

Hi,

In M1 running on FC4 I had external LDAP authentication working splendidly with only the following bind DN template:
uid=%u,ou=People,o=Company
When I upgraded to M2, it continued to work. Later when I reinstalled M2 from scratch (to resolve a separate issue) I attempted to add the same external LDAP config. It seems the input fields have changed a bit. I've tried every possible permutation of the above (uid=%u,ou=People,o=Company) with the filter, search base and bind DN input fields, and still no luck.
It seems like the interface has changed and does not allow for the same 'bind DN template' that was working in the M1 release. Can't seem to figure it out - any help would be greatly appreciated!


thanks! -Jim
schemers
Outstanding Member
Outstanding Member
Posts: 225
Joined: Fri Sep 12, 2014 9:53 pm

external LDAP authentication in M2

Post by schemers »

Hi. We switched to a filter because the bind template was too restrictive and didn't work well with sites that had multiple orgs.
If your bind template was indeed:
uid=%u,ou=People,o=Company
Then you should be able to do something like:
search filter: (uid=%u)

search base: ou=People,o=Company
I just tried the following on my dev box and it worked:
search filter: (uid=%u)

search base: ou=people,dc=slapshot,dc=liquidsys,dc=com
Let me know if that works for you...
roland
jstewart
Posts: 3
Joined: Fri Sep 12, 2014 10:01 pm

external LDAP authentication in M2

Post by jstewart »

Hi, thanks for the quick response. I tried, with and without parenthesis around the uid=%u filter with the search string ou=People, o=Company - but still no luck.

Just wondering - it seemed like after the upgrade, the template functionality was still there but on the fresh install it is not (at least thru the UI) - is there any way to revert to the template functionality, or configure it manually through command line/conf file?
I've copied the error message output below:
thanks again! -Jim
javax.naming.AuthenticationException: empty search

at com.zimbra.cs.account.ldap.LdapUtil.ldapAuthenticate(LdapUtil.java:262)

at com.zimbra.cs.account.ldap.Check.checkAuthConfig(Check.java:152)

at com.zimbra.cs.service.admin.CheckAuthConfig.handle(CheckAuthConfig.java:53)

at com.zimbra.soap.SoapEngine.dispatchRequest(SoapEngine.java:249)

at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.java:163)

at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.java:84)

at com.zimbra.soap.SoapServlet.doPost(SoapServlet.java:226)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)

at com.zimbra.cs.servlet.ZimbraServlet.service(ZimbraServlet.java:148)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)

at org.apache.catalina.core.StandardContextValve.invoke(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.invoke(StandardEngineValve.java:107)

at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:526)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)

at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:825)

at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:738)

at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:526)

at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)

at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)

at java.lang.Thread.run(Thread.java:595)
schemers
Outstanding Member
Outstanding Member
Posts: 225
Joined: Fri Sep 12, 2014 9:53 pm

external LDAP authentication in M2

Post by schemers »

It is saying AuthenticationException. On the wizard step after you enter the filter/base, are you clicking on the authentication box? You should only fill in that info if you need to pre-auth to the directory to do the search filter you entered in. i.e., if you can do an anonymous bind and run the search filter you typed in, then you should not check that box.
roland
jstewart
Posts: 3
Joined: Fri Sep 12, 2014 10:01 pm

external LDAP authentication in M2

Post by jstewart »

Hi, the box is not checked. Should I be using this pre-authentication to bind to the OpenLDAP server now that we are using a filter as opposed to bind template? thanks again, Jim
schemers
Outstanding Member
Outstanding Member
Posts: 225
Joined: Fri Sep 12, 2014 9:53 pm

external LDAP authentication in M2

Post by schemers »

my bad. In looking at the source code, "empty search" gets returned when the search filter didn't match anything. Are you sure the search filter and base are correct?
For example, going against the internal Zimbra OpenLDAP server, the search filter/base is:
search filter: (uid=%u)

search base: ou=people,dc=slapshot,dc=liquidsys,dc=com
when I type in my test username to the wizard ("user1"), the search done on the LDAP server would be:
(uid=user1)
under the ou=people,dc=slapshot,dc=liquidsys,dc=com directory, which would match the entry:
uid=user1,ou=people,dc=slapshot,dc=liquidsys,dc=com
We then take that DN and the supplied password, and auth using that.
One thing to try would be to use ldapsearch to see if you can find the entry:



ldapsearch -x -b ou=people,dc=slapshot,dc=liquidsys,dc=com '(uid=user1)'


This binds without auth, does the search, and returns a single entry. If that fails, then your LDAP search might not let you do the search un-authenticated, in which case you'll need to either change ACLs, or create a special account used to do the search.
If that doesn't work, you can ultimately fallback to the previous mechanism, by unseetting zimbraAuthLdapSearchFilter on the domain, and setting zimbraAuthLdapBindDn instead, but it is probably better to get it working.
It might also help if you could run:



zmprov gd {yourdomain} | grep zimbraAuth


So we can see all the zimbraAuth settings on the domain.
roland
Post Reply