using the zimbra LDAP for authentication

I'd like to use the zimbra LDAP server to authenticate our users in our other applications, maybe using php or some other scripting language.

Looking through the Zimbra LDAP Schema, I see that the objectclass zimbraAccount has a uid and the userPassword and the userPassword is hashed with something that ends up like:

e1NTSEF9anR3T0Zqc0tsOHJhRrT0Zqc05PN0xrT0Zqc05PN0x3 eWk=

QUESTION: what kind of hash is that?

To list all the users I can run this command:
/opt/zimbra/openldap/bin/ldapsearch -D "uid=zimbra,cn=admins,cn=zimbra" -x -w "[password]" |grep "dc=[ourdomain]"

where [password] came from:
zmlocalconfig -s zimbra_ldap_password
and [ourdomain] is, well, our domain (e.g. the example part of example.com)

QUESTION: anyone have tips on how I can query the zimbra ldap server with a username and password and return whether they are a valid user or not?

ideas?

jb

They are in {SSHA} format... Some more info here:

http://www.zimbra.com/forums/administrators/1163-migrating-accounts-ldap-encrypted-passwords.html

If your just looking to check the user/pass you could use a SOAP request and do a AuthRequest. This way you can just pass in the userid and password and let zimbra do all the auth magic. Might be easier/faster than trying to write your own wrapper around ldapsearch.

Thanks. Here's a way to use php and curl to get the soap response:

<?

$post_data = '<Envelope xmlns="http://www.w3.org/2003/05/soap-envelope">
<Body>
<AuthRequest xmlns="urn:zimbraAccount">
<account by="name">[USERNAME]</account>
<password>[PASSWORD]</password>
</AuthRequest>
</Body>
</Envelope>';

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, "https://[ZIMBRAURL]:7071/service/admin/soap" );
curl_setopt($ch, CURLOPT_POST, 1 );
curl_setopt($ch, CURLOPT_POSTFIELDS, $post_data);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
$postResult = curl_exec($ch);

if (curl_errno($ch)) {
print curl_error($ch);
}
curl_close($ch);
print "$postResult";

?>

where [USERNAME], [PASSWORD] and [ZIMBRAURL] are filled in with your particular values.

interestingly, if the auth failes, the soap reply includes a java trace:

<Trace>com.zimbra.cs.account.AccountServiceExcepti on: authentication failed for [USERNAME]@[DOMAIN].[EXTENSION]
at com.zimbra.cs.account.AccountServiceException.AUTH _FAILED(AccountServiceException.java:76)
at com.zimbra.cs.account.ldap.LdapProvisioning.verify Password(LdapProvisioning.java:2145)
at com.zimbra.cs.account.ldap.LdapProvisioning.authAc count(LdapProvisioning.java:2004)
at com.zimbra.cs.account.ldap.LdapProvisioning.authAc count(LdapProvisioning.java:1988)
at com.zimbra.cs.service.account.Auth.handle(Auth.jav a:91)
at com.zimbra.soap.SoapEngine.dispatchRequest(SoapEng ine.java:252)
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:214)
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:526)
at org.apache.catalina.connector.CoyoteAdapter.servic e(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(H ttp11Processor.java:825)
at org.apache.coyote.http11.Http11Protocol$Http11Conn ectionHandler.processConnection(Http11Protocol.jav a:738)
at org.apache.tomcat.util.net.PoolTcpEndpoint.process Socket(PoolTcpEndpoint.java:526)
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)
</Trace>

Yes. We include the stack on all errors if possible so user/qa/support can have easy access for debugging. Many times the user will not have access to logs of the system so getting the data back in a SOAP response is the best way.