openldap-technical

openldap-technical@openldap.org

1 participants
9961 discussions

Delta-syncrepl and delay in replication
by MIKI Soichiro 11 Jun '10

11 Jun '10

Hi All, I am testing delta-syncrepl using OpenLDAP 2.3.43.7(actually as ZimbraLDAP on ZCS 5.0.16). It spends a lot of time to complete replication when adding 20,000 or 200,000 objects(accounts) to the master at a time. [Time for replication] User time(updates to master) replica1 replica2 ------------------------------------------- 20,000 0:19:03 0:58:51 1:19:29 200,000 2:38:03 4:33:39 13:33:38 [Setting value in LDAP] *checkpoint = 10240 *Thread numbers = 8 *Security = 0(zimbra_require_interprocess_security) *The following operation is actually executed by each user in a loop. 1.Add account 2.Add settings(filters,contacts,signatures) for an account 3.Update the setting of the created account There seems no performance problem with writing accesslog to the database, thus, updates to the master server was finished successfully in reasonable time. Also, it seems that there is no bottleneck such as resource of the servers, and we still have extra spaces on CPU, memory and network. I've attached the servers spec. I assume there will be a problem with the process of pushing data from LDAP master to multiple replicas, but is this process serialized ? How can we reduce the replication time on replica servers? I think updates could not be delayed on the replicas themselves because only the secondary replica took a lot of time to update data. And we don't have plan to execute export/import method. Here are the settings of the provider and the replicas: ######################################################## # BDB database definitions for provider # excluding Zimbra settings ######################################################## database bdb suffix "" rootdn "cn=config" # number of entries to keep in memory cachesize 10000 # number of search results to keep in memory idlcachesize 10000 # check point whenever 64k data bytes written or # 5 minutes has elapsed whichever occurs first checkpoint 64 5 # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory "/opt/zimbra/openldap-data" # recommended for replication index entryUUID eq index entryCSN eq sizelimit unlimited timelimit unlimited overlay syncprov syncprov-checkpoint 20 10 syncprov-sessionlog 500 include /opt/zimbra/conf/master-accesslog-overlay.conf ################################################## # BDB database definitions for consumer ################################################## database bdb suffix "" rootdn "cn=config" # number of entries to keep in memory cachesize 10000 # number of search results to keep in memory idlcachesize 10000 # check point whenever 64k data bytes written or # 5 minutes has elapsed whichever occurs first checkpoint 64 5 # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory "/opt/zimbra/openldap-data" index uid pres,eq # white pages index mail pres,eq,sub index cn pres,eq,sub index displayName pres,eq,sub index sn pres,eq,sub index gn pres,eq,sub # recommended for replication index entryUUID eq index entryCSN eq sizelimit unlimited timelimit unlimited ###include /opt/zimbra/conf/master-accesslog-overlay.conf syncrepl rid=100 provider=ldap://ldapm.XXX1.XXX-test.ne.jp:389 retry="60 +" type=refreshAndPersist schemachecking=off searchbase="" bindmethod=simple binddn=uid=zmreplica,cn=admins,cn=zimbra credentials=@@ldap_replication_password@@ starttls=critical logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata="accesslog" updateref ldap://ldapm.ngm1.XXX-test.ne.jp:389 overlay syncprov Please let us know if you need more information. Best Regards, Soichiro Miki ===== Soichiro Miki Hitachi Software Engineering Co,Ltd. s-miki(a)hitachisoft.jp

3 2

OU string representation in openldap
by rahul.manchanda＠bt.com 11 Jun '10

11 Jun '10

Hello, One of the our application functionality reads the hosts data from the ldap particularly dn - "ou=hosts, ou=hostdata,o=BT" and from application point this dn will be updated when we add any new hosts in administration tab. In application there is no restriction on the host name to be entered. It can be anything mean it can accept _ (underscore) , (comma) .(dot). But when this code snippet reads this DN and in case if the ou has characters like . or , or _ it will throw exception when it reads such dn(s). We tried changing putting string syntax to this particular attribute and tried but getting the same results. Is this the expected behavior? And is there a way we can change this behavior? Many Thanks in advance!! Regards Rahul

2 1

TLS Connection Failure
by Radomir Klacza 10 Jun '10

10 Jun '10

Hi all, I'm trying to establish TLS connection with my newly configured OpenLDAP server, but all the time I get the TLS Connection Failure error. I have the following configuration in slapd.conf: TLSCACertificateFile /etc/openldap/cacert.pem TLSCertificateFile /etc/openldap/servercrt.pem TLSCertificateKeyFile /etc/openldap/serverkey.pem TLSVerifyClient never The CA and certs where creating with accordance to this tutorial: http://www.openldap.org/faq/data/cache/185.html server error (with loglevel -1): connection_get(29) Jun 10 10:51:30 firma slapd[6203]: connection_get(29): got connid=190 Jun 10 10:51:30 firma slapd[6203]: connection_read(29): checking for input on id=190 Jun 10 10:51:30 firma slapd[6203]: connection_read(29): TLS accept failure error=-1 id=190, closing Jun 10 10:51:30 firma slapd[6203]: connection_closing: readying conn=190 sd=29 for close Jun 10 10:51:30 firma slapd[6203]: connection_close: conn=190 sd=29 Jun 10 10:51:30 firma slapd[6203]: daemon: removing 29 Jun 10 10:51:30 firma slapd[6203]: conn=190 fd=29 closed (TLS negotiation failure) the client error: # ldapsearch -d -1 -H ldap://192.168.2.49 -D 'cn=Manager,dc=melog,dc=com' -W -ZZ ldap_create ldap_url_parse_ext(ldap://192.168.2.49) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP 192.168.2.49:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.2.49:389 ldap_connect_timeout: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_dump: buf=0x978a418 ptr=0x978a418 end=0x978a437 len=31 0000: 30 1d 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 0....w...1.3.6.1 0010: 2e 34 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 .4.1.1466.20037 ber_scanf fmt ({) ber: ber_dump: buf=0x978a418 ptr=0x978a41d end=0x978a437 len=26 0000: 77 18 80 16 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e w...1.3.6.1.4.1. 0010: 31 34 36 36 2e 32 30 30 33 37 1466.20037 ber_flush: 31 bytes to sd 3 0000: 30 1d 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 0....w...1.3.6.1 0010: 2e 34 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 .4.1.1466.20037 ldap_write: want=31, written=31 0000: 30 1d 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 0....w...1.3.6.1 0010: 2e 34 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 .4.1.1466.20037 ldap_result ld 0x9782218 msgid 1 ldap_chkResponseList ld 0x9782218 msgid 1 all 1 ldap_chkResponseList returns ld 0x9782218 NULL wait4msg ld 0x9782218 msgid 1 (infinite timeout) wait4msg continue ld 0x9782218 msgid 1 all 1 ** ld 0x9782218 Connections: * host: 192.168.2.49 port: 389 (default) refcnt: 2 status: Connected last used: Thu Jun 10 10:50:24 2010 ** ld 0x9782218 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ** ld 0x9782218 Response Queue: Empty ldap_chkResponseList ld 0x9782218 msgid 1 all 1 ldap_chkResponseList returns ld 0x9782218 NULL ldap_int_select read1msg: ld 0x9782218 msgid 1 all 1 ber_get_next ldap_read: want=8, got=8 0000: 30 84 00 00 00 10 02 01 0....... ldap_read: want=14, got=14 0000: 01 78 84 00 00 00 07 0a 01 00 04 00 04 00 .x............ ber_get_next: tag 0x30 len 16 contents: ber_dump: buf=0x978b550 ptr=0x978b550 end=0x978b560 len=16 0000: 02 01 01 78 84 00 00 00 07 0a 01 00 04 00 04 00 ...x............ read1msg: ld 0x9782218 msgid 1 message type extended-result ber_scanf fmt ({eaa) ber: ber_dump: buf=0x978b550 ptr=0x978b553 end=0x978b560 len=13 0000: 78 84 00 00 00 07 0a 01 00 04 00 04 00 x............ read1msg: ld 0x9782218 0 new referrals read1msg: mark request completed, ld 0x9782218 msgid 1 request done: ld 0x9782218 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_extended_result ber_scanf fmt ({eaa) ber: ber_dump: buf=0x978b550 ptr=0x978b553 end=0x978b560 len=13 0000: 78 84 00 00 00 07 0a 01 00 04 00 04 00 x............ ldap_parse_result ber_scanf fmt ({iaa) ber: ber_dump: buf=0x978b550 ptr=0x978b553 end=0x978b560 len=13 0000: 78 84 00 00 00 07 0a 01 00 04 00 04 00 x............ ber_scanf fmt (}) ber: ber_dump: buf=0x978b550 ptr=0x978b560 end=0x978b560 len=0 ldap_msgfree TLS trace: SSL_connect:before/connect initialization tls_write: want=142, written=142 0000: 80 8c 01 03 01 00 63 00 00 00 20 00 00 39 00 00 ......c... ..9.. 0010: 38 00 00 35 00 00 88 00 00 87 00 00 84 00 00 16 8..5............ 0020: 00 00 13 00 00 0a 07 00 c0 00 00 33 00 00 32 00 ...........3..2. 0030: 00 2f 00 00 45 00 00 44 00 00 41 00 00 07 05 00 ./..E..D..A..... 0040: 80 03 00 80 00 00 05 00 00 04 01 00 80 00 00 15 ................ 0050: 00 00 12 00 00 09 06 00 40 00 00 14 00 00 11 00 ........@....... 0060: 00 08 00 00 06 04 00 80 00 00 03 02 00 80 9b 34 ...............4 0070: a3 18 95 67 ad a3 47 d0 89 9b 85 3f e2 e5 7a 44 ...g..G....?..zD 0080: e5 72 f1 07 82 06 51 45 f2 17 d9 a2 47 51 .r....QE....GQ TLS trace: SSL_connect:SSLv2/v3 write client hello A tls_read: want=7, got=0 TLS: can't connect. ldap_perror ldap_start_tls: Connect error (-11) client is configured: TLS_CACERT /etc/openldap/cacert.pem and cacert is the same like on the server. I'm using gentoo with openldap 2.4.19-r1 and openssl 0.9.8n I'm working on it for long time and currently I have no idea why it does not working...

2 1

User restriction
by Stuart Cherrington 10 Jun '10

10 Jun '10

Hi, I'm migrating from a Sun One DS service to Openldap 2.4. In our current setup, the ldap.conf on each client the nss_base_passwd line is configured as nss_base_passwd ou=people,dc=ldn,dc=sw,dc=com?sub?ismemberof=cn=access,ou=auth,dc=ldn,dc=sw,dc=com This ensures that only users within the CN 'access' can login to the servers. Have exported and imported the data and carried out necessary cleaning up work, the ldapsearch brings back identical output when examining 'cn=access,ou=auth,dc=ldn,dc=sw,dc=com' but on my client which talks to the Openldap server, I cannot login with any accounts is the above setting is in place. I'm presuming that the issue is about the config of the above line but try as I might I can't get it to work correctly. Any help would be appreciated. Thanks, Stuart Cherrington. _________________________________________________________________ http://clk.atdmt.com/UKM/go/197222280/direct/01/ Do you have a story that started on Hotmail? Tell us now

7 8

Re: smbk5pwd: ldappassword hangs
by Frank Van Damme 10 Jun '10

10 Jun '10

2010/6/7 Quanah Gibson-Mount <quanah(a)zimbra.com>: > --On Monday, June 07, 2010 11:56 AM +0200 Frank Van Damme > What version of OpenLDAP are you using? You've failed to mention that > anywhere. 2.4.11 (Debian 5.0). -- Frank Van Damme A: Because it destroys the flow of the conversation. Q: Why is it bad? A: No, it's bad. Q: Should I top post in replies to mailing lists or on Usenet?

2 1

help SSL on Openldap and java
by s g 10 Jun '10

10 Jun '10

> > Our requirement is that we need to test if a server certificate from > Openldap server is valid and then upload to our trust store and use the > certificate for further communications using SSL to the ldap server. > I configured Openldap for SSL as per the Openldap admin guide - generated > the 3 certificates cacert.pem,servercert.pem and serverkey.pem and put the > corresponding entries in slapd.conf file. My assumption is cacert.pem is the > file for the CA,servercert.pem is the server certificate file(?!) and the > serverkey.pem is the file containing the private key to the server. After > configuring my client ldap.conf file to point to cacert.pem as per the > following directives - > > TLS_CACERTDIR <path to my cacert.pem file> > TLS_REQCERT hard > > I was able to execute an ldapsearch command successfully. My problem is > that after adding cacert.pem to my truststore, I am unable to use the > certificate in java using SSL. I get the following exception - > > javax.naming.CommunicationException: simple bind failed: > vcheung-181.lab.xxxx.net:636 [Root exception is > javax.net.ssl.SSLHandshakeException: > sun.security.validator.ValidatorException: Netscape cert type does not > permit use for SSL server] > at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:197) > at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2658) > at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:287) > at > com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:175) > at > com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:193) > at > com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:136) > at > com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:66) > at > javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667) > at > javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288) > at javax.naming.InitialContext.init(InitialContext.java:223) > at javax.naming.InitialContext.<init>(InitialContext.java:197) > at > javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:82) > at > com.xxxx.analyst.manager.database.LDAPSchemaTest.areAllAttributesPresent(LDAPSchemaTest.java:84) > at > com.xxxx.analyst.presentation.action.ReCreateDomainAction.doAttributeCheck(ReCreateDomainAction.java > :249) > at > com.xxxx.analyst.presentation.action.ReCreateDomainAction.execute(ReCreateDomainAction.java:182) > at > org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) > at > org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) > at > org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) > at > org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at com.xxxx.util.ReLiveUserFilter.doFilter(ReLiveUserFilter.java:70) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > com.xxxx.analyst.util.ReAccessFilter.doFilter(ReAccessFilter.java:191) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) > at > org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39) > at > org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153) > at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482) > at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482) > at > org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59) > 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.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.jav > a:744) > at > org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) > at > org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112) > at java.lang.Thread.run(Thread.java:619) > > Caused by: javax.net.ssl.SSLHandshakeException: > sun.security.validator.ValidatorException: Netscape cert type does not > permit use for SSL server > at > com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174) > at > com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1591) > at > com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:187) > at > com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:181) > at > com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:975) > at > com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:123) > at > com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:516) > at > com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:454) > at > com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:884) > at > com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1096) > at > com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:623) > at > com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:59) > at > java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65) > at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123) > at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:393) > at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:334) > at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:192) > ... 47 more > > > I googled for the above exception and from what I got, I thought I had to > configure for a client certificate but we have to test the server > certificate for validity not the client certificate. I am not sure I am > following the procedure correctly. My question is - > Is servercert.pem the file that I need to use as server certificate. How > can I validate it(I mean make sure that it is a valid server certificate > file)? (Pointing to the servercert.pem file in ldap.conf gave me an error) - ldap_create ldap_url_parse_ext(ldaps://vcheung-181.lab.xxxx.net:636) ldap_bind_s ldap_simple_bind_s ldap_sasl_bind_s ldap_sasl_bind ldap_send_initial_request ldap_new_connection ldap_int_open_connection ldap_connect_to_host: TCP vcheung-181.lab.xxxx.net:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 172.25.4.181:636 ldap_connect_timeout: fd: 3 tm: -1 async: 0 ldap_ndelay_on: 3 ldap_is_sock_ready: 3 ldap_ndelay_off: 3 TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 1, err: 19, subject: /C=US/ST=California/O=yyyy/OU=yyyy/CN=vcheung-181.lab.xxxx.net, issuer: /C=US/ST=California/O=yyyy/OU=yyyy/CN=vcheung-181.lab.xxxx.net TLS certificate verification: Error, self signed certificate in certificate chain TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't connect. ldap_perror ldap_bind: Can't contact LDAP server (-1) Is there some other directive in ldap.conf file which points to this file ( > I thought only 3 valid directives are present > TLS_CACERTDIR,TLS_CACERT,TLS_REQCERT). There were other directives TLS_CERT > - but these point to the client certificate. > Thanks Sirisha.

3 4

Write through an LDAP Proxy?
by Christoph Berkemeier 09 Jun '10

09 Jun '10

Greetings, i would like to use multiple OpenLDAP Server with Samba. As Samba uses only one database server, i considered it would be suitable to use a ldap proxy in front of my master and my slaves servers. I tried it with the proxycache overlay, but after some testing and combing the internet for information it seems this does not work for write-request. Is this information correct? And if it is, are there some alternatives? Best Regards, Christoph Berkemeier

5 9

pam_ldap doesn't bind SIMPLE for anonymous auth?
by Jo Rhett 09 Jun '10

09 Jun '10

I'm seeing a problem where I can authenticate as a user using the ldap tools (ie ldapsearch) but I am unable to login using PAM. Comparing debug on the server shows that ldapsearch is doing a new BIND, where's PAM is not: Jun 4 14:58:52 ldap-server slapd[5158]: => dn: [1] Jun 4 14:58:52 ldap-server slapd[5158]: => acl_get: [2] attr userPassword Jun 4 14:58:52 ldap-server slapd[5158]: access_allowed: no res from state (userPassword) Jun 4 14:58:52 ldap-server slapd[5158]: => acl_mask: access to entry "uid=jrhett,ou=Users,dc=equinix,dc=com", attr "userPassword" requested Jun 4 14:58:52 ldap-server slapd[5158]: => acl_mask: to value by "", (=0) Jun 4 14:58:52 ldap-server slapd[5158]: <= check a_dn_pat: anonymous Jun 4 14:58:52 ldap-server slapd[5158]: <= acl_mask: [1] applying auth(=xd) (stop) Jun 4 14:58:52 ldap-server slapd[5158]: <= acl_mask: [1] mask: auth(=xd) Jun 4 14:58:52 ldap-server slapd[5158]: => access_allowed: auth access granted by auth(=xd) Jun 4 14:58:52 ldap-server slapd[5158]: send_ldap_result: conn=75 op=2 p=3 Jun 4 14:58:52 ldap-server slapd[5158]: send_ldap_result: err=49 matched="" text="" Jun 4 14:58:52 ldap-server slapd[5158]: send_ldap_response: msgid=3 tag=97 err=49 Jun 4 14:58:52 ldap-server slapd[5158]: conn=75 op=2 RESULT tag=97 err=49 text= Now ldapsearch has identical debug output down until just below the access_allowed line. Jun 4 15:02:54 ldap-server slapd[5158]: => acl_get: [2] attr userPassword Jun 4 15:02:54 ldap-server slapd[5158]: access_allowed: no res from state (userPassword) Jun 4 15:02:54 ldap-server slapd[5158]: => acl_mask: access to entry "uid=jrhett,ou=Users,dc=equinix,dc=com", attr "userPassword" requested Jun 4 15:02:54 ldap-server slapd[5158]: => acl_mask: to value by "", (=0) Jun 4 15:02:54 ldap-server slapd[5158]: <= check a_dn_pat: anonymous Jun 4 15:02:54 ldap-server slapd[5158]: <= acl_mask: [1] applying auth(=xd) (stop) Jun 4 15:02:54 ldap-server slapd[5158]: <= acl_mask: [1] mask: auth(=xd) Jun 4 15:02:54 ldap-server slapd[5158]: => access_allowed: auth access granted by auth(=xd) Jun 4 15:02:54 ldap-server slapd[5158]: conn=83 op=0 BIND dn="uid=jrhett,ou=Users,dc=equinix,dc=com" mech=SIMPLE ssf=0 Jun 4 15:02:54 ldap-server slapd[5158]: do_bind: v3 bind: "uid=jrhett,ou=Users,dc=equinix,dc=com" to "uid=jrhett,ou=Users,dc=equinix,dc=com" Jun 4 15:02:54 ldap-server slapd[5158]: send_ldap_result: conn=83 op=0 p=3 Jun 4 15:02:54 ldap-server slapd[5158]: send_ldap_result: err=0 matched="" text="" Jun 4 15:02:54 ldap-server slapd[5158]: send_ldap_response: msgid=1 tag=97 err=0 Jun 4 15:02:54 ldap-server slapd[5158]: conn=83 op=0 RESULT tag=97 err=0 text= Jun 4 15:02:54 ldap-server slapd[5158]: daemon: activity on 1 descriptor Jun 4 15:02:54 ldap-server slapd[5158]: daemon: activity on: Can someone give me a clue what's going wrong here? The key to this problem is that I'm trying to avoid putting system logins, rootbinddns on each server, and just do anonymous bind's for authentication. No configuration file on this client has a valid Manager or any other authentication password, and I'm trying to keep it that way. In theory, this should work ;-) I mean, ldapsearch works fine ... -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

4 5

Tool to covert from LDIF cn=config to slapd.conf?
by Nick Urbanik 09 Jun '10

09 Jun '10

Dear Folks, It is nice that the tools convert from slapd.conf to the LDIF configuration. Is there a tool that converts the other way round? I could write one, but I'd rather use an existing wheel if there is one. -- Nick Urbanik http://nicku.org 808-71011 nick.urbanik(a)optusnet.com.au GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24 I disclaim, therefore I am.

2 1

Re: ldapsearch -w "password" only check first 8 words ?
by Zdenek Styblik 08 Jun '10

08 Jun '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/09/10 07:23, shyuejyh.tw wrote: > yes , i use crypt to hash my password .. > so .. the problem is crypt just hash first 8 words , right ? > > and i just need change another hash function like md5 ? > > thanks a lot for your help :-) > > Yep, that's correct. Zdenek - -- Zdenek Styblik Net/Linux admin OS TurnovFree.net email: stybla(a)turnovfree.net jabber: stybla(a)jabber.turnovfree.net > --- 10/6/9 (三)，Zdenek Styblik <stybla(a)turnovfree.net> 寫道： > > > 寄件者: Zdenek Styblik <stybla(a)turnovfree.net> > 主旨: Re: ldapsearch -w "password" only check first 8 words ? > 收件者: "shyuejyh.tw" <shyuejyh.tw(a)yahoo.com.tw> > 日期: 2010年6月9日,三,下午1:05 > > > On 06/09/10 03:50, shyuejyh.tw wrote: >> Hi Everyone: >> i have a question , how can i change ldapsearch command to check password more than 8 words? > >> my openldap is 2.4.11 (Debian/Lenny) > >> when i use freeradius 2.0.4 to authentication a account, >> my password is 12345678 , than i type 123456789 , Pass ..... > >> this is radius's log: >> rlm_ldap: login attempt by "amo" with password "123456789" >> rlm_ldap: user DN: uid=amo,dc=hello,dc=com >> rlm_ldap: (re)connect to 127.0.0.1:389, authentication 1 >> rlm_ldap: bind as uid=amo,dc=hello,dc=com/123456789 >> rlm_ldap: waiting for bind result ... >> rlm_ldap: Bind was successful >> rlm_ldap: user amo authenticated succesfully >> ++[ldap] returns ok > > >> than i try use ldapsearch search a user (still use password 123456789) > >> ldapsearch -x -b "dc=hello,dc=com" -D "uid=amo,dc=hello,dc=com" -W -h localhost -LLL uid=jojo >> Enter LDAP Password: >> pass than find user information. > >> dn: uid=jojo,dc=hello,dc=com >> shadowLastChange: 123123 >> loginShell: /bin/csh >> gidNumber: 102 >> homeDirectory: /home/jojo >> uidNumber: 1002 > >> i guess ldapsearch command just check first 8 words, is this a bug or change something can fix it ? > >> thanks a lot > > > > > hello, > > isn't it because you're using CRYPT for password hash? > > Regards, > Zdenek > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwPJwoACgkQ8MreUbSH7ikPsgCgsvEjTOnwflV9Y4MkxuAJgAeN l5kAoMOWTUhLWGP6kY26LA2zvZ4zeLkN =nH2z -----END PGP SIGNATURE-----

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical