openldap-technical

openldap-technical@openldap.org

9989 discussions

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

could not config n-way multi-master because insufficient access
by owen nirvana 08 Jun '10

08 Jun '10

my env is Debian squeeze, OpenLDAP 2.4.17( from packages.debian.org) I create an OpenLDAP Server, and try to config N-Wat multi-master, according to OpenLDAP Admin Guide. i adding init.ldif file on the server , the following is the content *dn: cn=config objectClass: olcGlobal cn: config olcServerID: 1 dn: olcDatabase={0}config,cn=config* * objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW: secret* and I get error --- "insufficient access" , even if I set "acess to * by * write" in slapd.conf actually, I don't understand what the guide said. ''''''''''''' This sets up the config database: * dn: cn=config objectClass: olcGlobal cn: config olcServerID: 1 dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW: secret* '''''''''''''''''''''''''''' the above configuration block could not be import in my computer, it is said at the begin. '''''''''''''''''''''''''''' Now we setup the first Master Node (replace $URI1, $URI2 and $URI3 etc. with your actual ldap urls): * dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 $URI1 olcServerID: 2 $URI2 olcServerID: 3 $URI3 dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=002 provider=$URI2 binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=003 provider=$URI3 binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 - add: olcMirrorMode olcMirrorMode: TRUE* '''''''''''''''''''''''''''' the configuration block seems conflict with the former, why should I write "olcServerID: 1 $URI1" into LDAP Server if "olcServerID: 1" is right, and why should I not write an entire configuration, but two configuration file which seems conflict separately. I have set up an unlimit previledge, why LDAP Server report "insufficient access". what previledge should be set. thanks for help gtalk:freeespeech@gmail.com <gtalk%3Afreeespeech(a)gmail.com>

2 2

ldapsearch -w "password" only check first 8 words ?
by shyuejyh.tw 08 Jun '10

08 Jun '10

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

2 1

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