openldap-technical

openldap-technical@openldap.org

9 participants
9876 discussions

Using SSLv2 with ldapclient.
by Friedrich Clausen 03 Aug '11

03 Aug '11

Hi, We have a check (shell script) that talks to a customer's LDAP server (over which we have no control) and only SSLv2 seems to work when using "openssl s_client -connect". I am trying to make ldapclient use SSLv2 but it does not work (Our machine is running RHEL 5.4 x86_64.). First an the OpenSSL illustration ]# openssl s_client -ssl3 -connect 10.1.2.3:636 CONNECTED(00000003) depth=3 <omitted for privacy> verify return:1 depth=2 <omitted for privacy> verify return:1 depth=1 <omitted for privacy> verify return:1 depth=0 <omitted for privacy> verify return:1 6759:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:530: # but if we use SSLv2 then it works - I am able to establish a connection and see the certificate used. I have created a small ldap client config file with the following contents TLS_REQCERT never TLS_CIPHER_SUITE SSLv2 I make sure that config is used by setting the "LDAPCONF" variable while calling ldapsearch, like so # LDAPCONF=./ldaprc ldapsearch -H ldaps://10.1.2.3:636 -x -s base -D 'CN=binder,OU=Service Accounts,OU=example ou,dc=example,dc=com' -w 'secret' -b '' -d 1 ldap_create ldap_url_parse_ext(ldaps://10.1.2.3:636) ldap_bind ldap_simple_bind ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP 10.1.2.3:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 10.1.2.3:636 ldap_connect_timeout: fd: 3 tm: -1 async: 0 TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS: can't connect. ldap_perror ldap_bind: Can't contact LDAP server (-1) # but it mysteriously fails. If I make the configuration file us SSLv3, then the following output is given (but that is expected as the server does not seem to want to speak SSLv3) - # LDAPCONF=./ldaprc ldapsearch -H ldaps://10.1.2.3:636 -x -s base -D 'CN=binder,OU=Service Accounts,OU=example ou,dc=example,dc=com' -w 'secret' -b '' -d 1 ldap_create ldap_url_parse_ext(ldaps://10.1.2.3:636) ldap_bind ldap_simple_bind ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP 10.1.2.3:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 10.1.2.3:636 ldap_connect_timeout: fd: 3 tm: -1 async: 0 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: 3, <omitted> TLS certificate verification: depth: 2, <omitted> TLS certificate verification: depth: 1, <omitted> TLS certificate verification: depth: 0, <omitted> TLS trace: SSL_connect:SSLv3 read server certificate A TLS trace: SSL_connect:SSLv3 read server certificate request A TLS trace: SSL_connect:SSLv3 read server done A TLS trace: SSL_connect:SSLv3 write client certificate A TLS trace: SSL_connect:SSLv3 write client key exchange A TLS trace: SSL_connect:SSLv3 write change cipher spec A TLS trace: SSL_connect:SSLv3 write finished A TLS trace: SSL_connect:SSLv3 flush data TLS trace: SSL_connect:failed in SSLv3 read finished A TLS: can't connect. ldap_perror ldap_bind: Can't contact LDAP server (-1) any suggestions would be much appreciated. Regards, Fred.

1 0

Problems using idassert-bind
by michel.gruau 03 Aug '11

03 Aug '11

Hello, A have a slapd-meta configuration with 6 backend directories. All of them can be accessed anonymously except One of them need that need to be accessed through a technical account. This technical must be used whatever the proxy bind DN is: - anonymous - user account - manager account (cn=Manager,dc=example,dc=com) Below is my test configuration: database meta suffix dc=example,dc=com uri ldap://remote:389/dc=example,dc=com idassert-bind bindmethod=simple binddn="uid=tech,dc=example,dc=com" credentials="password" As no anonymous access were allowed, I had to add the following line: idassert-authzFrom "dn.regex:.*" This configuration allowed me to perform an anonymous search but the technical account were not used when connecting to the remote directory (anonymous account were used instead). I then tested "mode=self" and "mode=anonymous". But I received "protocol error" from the remote server when performing an anonymous search (search using user account and search using manager account were working). I managed to make it working using "mode=none". As the technical account were still not used when connecting to the proxy with a user account, I finally add the "flag=override". This latest configuration looks good to me but I have to questions : 1/ Do you confirm that "none" is the rigth mode for my need ? 2/ Do you now why I cannot use "self" and "anonymous" ? What could be the reason why I receive the "protocol error" using mode=none and mode=self ? FYI, remote server is a Sun One DS 5.2. I don't know whether it could explain. Thank you very much for your expertise. Michel Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net

1 0

Ldappasswd failure
by Naga Chaitanya Palle 03 Aug '11

03 Aug '11

Hi, I have configured a openldap2.4.25 server on RHEL5.4 and added few users to the ldap. I want to assign password to the user and I am trying it out this way, but getting Naming violation error [root@dtr98 bin]# ldappasswd -xvv -D "cn=Manager,dc=comverse-in,dc=com" -W -S "uid=cbsuser,ou=People,dc=comverse-in,dc=com" New password: Re-enter new password: ldap_initialize( <DEFAULT> ) Enter LDAP Password: Result: Naming violation (64) [root@dtr98 bin]# The user info is [root@dtr98 bin]# ldapsearch -x -LLL -s sub -b "dc=comverse-in,dc=com" "cn=cbsuser" dn: uid=cbsuser,ou=People,dc=comverse-in,dc=com cn: cbsuser objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount uidNumber: 300 [root@dtr98 bin]# Please let me know what the problem is Thanks and Regards, Naga Chaitanya =============================================================================== Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. ===============================================================================

2 2

syncrepl: consumer state is newer than provider
by Mahadevan, Venkatasubramanian 02 Aug '11

02 Aug '11

Hello, I have 2 OpenLDAP servers with the following configuration: -- OpenLDAP 2.4.26-Release running on Red Hat Enterprise 5.5 -- The two servers are setup in a mirrored multi-master configuration. Below is the relevant portion of the slapd.conf: server1 ---------- syncrepl rid=002 provider=ldaps://server2 type=refreshAndPersist retry="5 5 300 +" searchbase="o=ourdomain.ca" attrs="*,+" bindmethod=simple binddn="cn=Replication Manager,o=ubc.ca" credentials=something mirrormode TRUE overlay syncprov syncprov-checkpoint 100 10 server2 ---------- syncrepl rid=001 provider=ldaps://server1 type=refreshAndPersist retry="5 5 300 +" searchbase="o=ourdomain.ca" attrs="*,+" bindmethod=simple binddn="cn=Replication Manager,o=ubc.ca" credentials=something mirrormode TRUE overlay syncprov syncprov-checkpoint 100 10 The servers have their clocks synchronized using ntp. Below is the output of ntpq: server1 ---------- ntpq> peer remote refid st t when poll reach delay offset jitter ============================================================================== +hub.ubc.ca 93.113.2.250 3 u 594 1024 377 1.252 1.110 1.520 *dns3.ubc.ca 192.53.103.108 2 u 92 1024 377 1.648 2.670 0.157 server2 ---------- ntpq> peer remote refid st t when poll reach delay offset jitter ============================================================================== +hub.ubc.ca 93.113.2.250 3 u 332 1024 377 0.706 3.487 0.900 *dns3.ubc.ca 192.53.103.108 2 u 325 1024 377 1.631 3.668 0.022 As far as I can tell the clocks appear to be in sync with each other, so hopefully this is not a cause of the replication issues I am having. The problem is that the servers are now refusing to synchronize with each other (replication was working before) but not it does not. The log files on the servers are filled with entries like: server1 ---------- Jul 29 13:48:54 ldapdev1 slapd[11989]: do_syncrep2: rid=002 LDAP_RES_SEARCH_RESULT Jul 29 13:48:54 ldapdev1 slapd[11989]: do_syncrep2: rid=002 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Jul 29 13:48:54 ldapdev1 slapd[11989]: do_syncrep2: rid=002 (53) Server is unwilling to perform Jul 29 13:48:57 ldapdev1 slapd[11989]: conn=1081 op=1 SRCH base="o=ubc.ca" scope=2 deref=0 filter="(objectClass=*)" Jul 29 13:48:57 ldapdev1 slapd[11989]: conn=1081 op=1 SRCH attr=* + Jul 29 13:48:57 ldapdev1 slapd[11989]: conn=1081 op=1 SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider! server2 ---------- Jul 29 13:50:52 ldapdev2 slapd[7996]: do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT Jul 29 13:50:52 ldapdev2 slapd[7996]: do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Jul 29 13:50:52 ldapdev2 slapd[7996]: do_syncrep2: rid=001 (53) Server is unwilling to perform Jul 29 13:50:55 ldapdev2 slapd[7996]: conn=1102 op=1 SRCH base="o=ubc.ca" scope=2 deref=0 filter="(objectClass=*)" Jul 29 13:50:55 ldapdev2 slapd[7996]: conn=1102 op=1 SRCH attr=* + Jul 29 13:50:55 ldapdev2 slapd[7996]: conn=1102 op=1 SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider! So it is looking like the ContextCSN cookies on both servers are out of sync. Digging further into this, I did a search for the ContextCSN values on both servers and got the following values: server1 ---------- 20110729165747.697237Z#000000#001#000000;20110726161604.535176Z#000000#002#000000 server2 ---------- 20110728220449.050499Z#000000#001#000000;20110728223211.933995Z#000000#002#000000 So my question is: how does one get the server synchronization cookies back into sync and ensure that replication is restarted succesfully again? As of now, all I see is the log files filling up with messages as shown above and the sync cookies not being updated. Any help or pointers are appreciated. Thanks! cheers, Ven

4 5

Memory usage (ITS 6660): Is there a patch to 2.4.23 version to fix the problem ?
by Friedrich Locke 02 Aug '11

02 Aug '11

Dear list members, i am running openlda 2.4.23 and i am facing memory usage problems (ITS 6660). I am not given the option to change to 2.4.23. Is there a patch to fix this problem? Thanks once more.

4 12

SSL server certificate that has an intermediary certificate in the chain
by Francis Swasey 02 Aug '11

02 Aug '11

I have searched the faq-o-matic, google, the admin guide, and I cannot find any documentation that will allow me to set up my OpenLDAP 2.4.25 server using an SSL certificate that was issued from a CA that uses intermediate certificates (by, which I mean to indicate any commercial SSL cert company currently selling certs). Apache has the SSLCertificateChainFile directive to handle this. OpenLDAP seems to be lacking this functionality. I have tried placing both the server certificate and the intermediate certificate in the same file. OpenLDAP won't start if I put the intermediate certificate first, and openssl fails to verify the certificate chain if I put the server certificate first in the file. Have I missed something obvious or has OpenLDAP really forced me into the position of needing to add the intermediate certificate from my SSL CA Vendor into my trusted store on all my clients? -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900)

6 16

rewrite on bindDN
by Perrin, David 02 Aug '11

02 Aug '11

Hi, thank you for reading this message! I'm configuring openldap (2.4.26) as a proxy for active directory (Win 2003) and encountered some inconsistent responses to bind/search requests that may relate to a misconfiguration around an rwm mapping. Hopefully this is the right place to ask for this kind of assistance. I haven't yet been able to see what I'm missing but have spent a lot of time with slapd.conf man, slap-rwm man, and tailing logs even at loglevel -1. Here's what happens: On the console of the openldap server, I'll start the slapd service like: ./slapd -4 -n slapd-ldap -u ldap -g ldap then run an ldapsearch command to the openldap server using a bindDN that requires no rewrite, and a base that requires a rewrite. I get successful binds and search results 100% of the time. If I then run an ldapsearch where the bindDN requires a rewrite, occasionally I'll get a "bind massage" error on the console. Tailing the log file, shows a line like this: Aug 1 16:45:12 localhost slapd-ldap[19490]: conn=1001 op=0 SEARCH RESULT tag=101 err=1 nentries=0 text=00000000: LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece If I stop slapd, restart the service, and run the ldapsearch where the bindDN requires a rewrite, I'll only get errors. Then if I do an ldapsearch with a bindDN that doesn't need a rewrite (which always binds and searches successfully), subsequent ldapsearch bind/search attempts with a bindDN that requires a rewrite will succeed most of the time. Below I've included some shell interaction and log output (loglevel 256 for brevity), non-comment lines from my slapd.conf, and other configuration details. Any suggestions for how I could debug this further or glaring mistakes would be greatly appreciated. Humbly yours, Dave # Start openldap Aug 1 16:38:42 localhost slapd-ldap[19426]: @(#) $OpenLDAP: slapd 2.4.26 (Jul 29 2011 14:11:30) $#012#011dave@localhost.localdomain:/usr/src/openldap-2.4.26/servers/sla pd Aug 1 16:38:42 localhost slapd-ldap[19427]: slapd starting # bind and search that requires no rewrite on bind but a rewrite on base (ou=App Auth 1 -> ou=Students) - this always works /opt/openldap/proxy/bin/ldapsearch -b "ou=App Auth 1,dc=TEST_STUDENT,dc=TEST_EDU" -D "CN=Addott\, Steven (saddott),ou=Students,DC=TEST_STUDENT,DC=TEST_EDU" -w "saddott" -x "(mail=sadd*)" name Aug 1 16:40:01 localhost slapd-ldap[19427]: conn=1001 fd=8 ACCEPT from IP=127.0.0.1:36499 (IP=0.0.0.0:389) Aug 1 16:40:01 localhost slapd-ldap[19427]: conn=1001 op=0 BIND dn="cn=Addott\2C Steven (saddott),ou=Students,dc=TEST_STUDENT,dc=TEST_EDU" method=128 Aug 1 16:40:01 localhost slapd-ldap[19427]: conn=1001 op=0 BIND dn="cn=Addott\2C Steven (saddott),ou=Students,dc=TEST_STUDENT,dc=TEST_EDU" mech=SIMPLE ssf=0 Aug 1 16:40:01 localhost slapd-ldap[19427]: conn=1001 op=0 RESULT tag=97 err=0 text= Aug 1 16:40:01 localhost slapd-ldap[19427]: conn=1001 op=1 SRCH base="ou=App Auth 1,dc=TEST_STUDENT,dc=TEST_EDU" scope=2 deref=0 filter="(mail=sadd*)" Aug 1 16:40:01 localhost slapd-ldap[19427]: conn=1001 op=1 SRCH attr=name Aug 1 16:40:01 localhost slapd-ldap[19427]: conn=1001 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Aug 1 16:40:01 localhost slapd-ldap[19427]: conn=1001 op=2 UNBIND Aug 1 16:40:01 localhost slapd-ldap[19427]: conn=1001 fd=8 closed # success! this comes back in the console: # extended LDIF # # LDAPv3 # base <ou=App Auth 1,dc=TEST_STUDENT,dc=TEST_EDU> with scope subtree # filter: (mail=sadd*) # requesting: name # # Addott\2C Steven (saddott), Students, TEST_STUDENT.TEST_EDU dn: cn=Addott\2C Steven (saddott),ou=Students,dc=TEST_STUDENT,dc=TEST_EDU name: Addott, Steven (saddott) # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 # now search and bind requiring a search base rewrite and bind rewrite (mail -> cn) /opt/openldap/proxy/bin/ldapsearch -b "ou=App Auth 1,dc=TEST_STUDENT,dc=TEST_EDU" -D "mail=saddott(a)localhost.localdomain,ou=Students,DC=TEST_STUDENT,DC=TEST_ EDU" -w "saddott" -x "(mail=sadd*)" name Aug 1 16:40:59 localhost slapd-ldap[19427]: conn=1002 fd=8 ACCEPT from IP=127.0.0.1:36502 (IP=0.0.0.0:389) Aug 1 16:40:59 localhost slapd-ldap[19427]: conn=1002 op=0 BIND dn="mail=saddott(a)localhost.localdomain,ou=Students,dc=TEST_STUDENT,dc=TE ST_EDU" method=128 Aug 1 16:40:59 localhost slapd-ldap[19427]: conn=1003 fd=12 ACCEPT from IP=127.0.0.1:36503 (IP=0.0.0.0:389) Aug 1 16:40:59 localhost slapd-ldap[19427]: conn=1003 op=0 SRCH base="ou=Students,dc=TEST_STUDENT,dc=TEST_EDU" scope=2 deref=0 filter="(mail=saddott(a)localhost.localdomain)" Aug 1 16:40:59 localhost slapd-ldap[19427]: conn=1003 op=0 SRCH attr=1.1 Aug 1 16:40:59 localhost slapd-ldap[19427]: conn=1003 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= Aug 1 16:40:59 localhost slapd-ldap[19427]: conn=1003 op=1 UNBIND Aug 1 16:40:59 localhost slapd-ldap[19427]: conn=1003 fd=12 closed Aug 1 16:40:59 localhost slapd-ldap[19427]: conn=1002 op=0 BIND dn="cn=Addott\2C Steven (saddott),ou=Students,dc=TEST_STUDENT,dc=TEST_EDU" mech=SIMPLE ssf=0 Aug 1 16:40:59 localhost slapd-ldap[19427]: conn=1002 op=0 RESULT tag=97 err=0 text= Aug 1 16:40:59 localhost slapd-ldap[19427]: conn=1002 op=1 SRCH base="ou=App Auth 1,dc=TEST_STUDENT,dc=TEST_EDU" scope=2 deref=0 filter="(mail=sadd*)" Aug 1 16:40:59 localhost slapd-ldap[19427]: conn=1002 op=1 SRCH attr=name Aug 1 16:40:59 localhost slapd-ldap[19427]: conn=1002 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Aug 1 16:40:59 localhost slapd-ldap[19427]: conn=1002 op=2 UNBIND Aug 1 16:40:59 localhost slapd-ldap[19427]: conn=1002 fd=8 closed # and again, success! this comes back # extended LDIF # # LDAPv3 # base <ou=App Auth 1,dc=TEST_STUDENT,dc=TEST_EDU> with scope subtree # filter: (mail=sadd*) # requesting: name # # Addott\2C Steven (saddott), Students, TEST_STUDENT.TEST_EDU dn: cn=Addott\2C Steven (saddott),ou=Students # restarting the service Aug 1 16:44:54 localhost slapd-ldap[19427]: daemon: shutdown requested and initiated. Aug 1 16:44:54 localhost slapd-ldap[19427]: slapd shutdown: waiting for 0 operations/tasks to finish Aug 1 16:44:54 localhost slapd-ldap[19427]: slapd stopped. Aug 1 16:45:02 localhost slapd-ldap[19489]: @(#) $OpenLDAP: slapd 2.4.26 (Jul 29 2011 14:11:30) $#012#011dave@localhost.localdomain:/usr/src/openldap-2.4.26/servers/sla pd Aug 1 16:45:02 localhost slapd-ldap[19490]: slapd starting # here's where I get a failure, attempting to bind where the bind requires a rewrite # same request as above but this time I'm doing it right after a service restart [root@localhost openldap]# /opt/openldap/proxy/bin/ldapsearch -b "ou=App Auth 1,dc=TEST_STUDENT,dc=TEST_EDU" -D "mail=saddott(a)localhost.localdomain,ou=Students,DC=TEST_STUDENT,DC=TEST_ EDU" -w "saddott" -x "(mail=sadd*)" name ldap_bind: Other (e.g., implementation specific) error (80) additional info: bindDN massage error .. log file shows Aug 1 16:45:12 localhost slapd-ldap[19490]: conn=1000 fd=8 ACCEPT from IP=127.0.0.1:46174 (IP=0.0.0.0:389) Aug 1 16:45:12 localhost slapd-ldap[19490]: conn=1000 op=0 BIND dn="mail=saddott(a)localhost.localdomain,ou=Students,dc=TEST_STUDENT,dc=TE ST_EDU" method=128 Aug 1 16:45:12 localhost slapd-ldap[19490]: conn=1001 fd=10 ACCEPT from IP=127.0.0.1:46175 (IP=0.0.0.0:389) Aug 1 16:45:12 localhost slapd-ldap[19490]: conn=1001 op=0 SRCH base="ou=Students,dc=TEST_STUDENT,dc=TEST_EDU" scope=2 deref=0 filter="(mail=saddott(a)localhost.localdomain)" Aug 1 16:45:12 localhost slapd-ldap[19490]: conn=1001 op=0 SRCH attr=1.1 Aug 1 16:45:12 localhost slapd-ldap[19490]: ==> rewrite_context_apply error ... Aug 1 16:45:12 localhost slapd-ldap[19490]: conn=1000 op=0 RESULT tag=97 err=80 text=bindDN massage error Aug 1 16:45:12 localhost slapd-ldap[19490]: conn=1001 op=0 SEARCH RESULT tag=101 err=1 nentries=0 text=00000000: LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece Aug 1 16:45:12 localhost slapd-ldap[19490]: conn=1000 fd=8 closed (connection lost) Aug 1 16:45:12 localhost slapd-ldap[19490]: conn=1001 op=1 UNBIND Aug 1 16:45:12 localhost slapd-ldap[19490]: conn=1001 fd=10 closed Now back to the request that required no bind rewrite [root@localhost openldap]# /opt/openldap/proxy/bin/ldapsearch -b "ou=App Auth 1,dc=TEST_STUDENT,dc=TEST_EDU" -D "CN=Addott\, Steven (saddott),ou=Students,DC=TEST_STUDENT,DC=TEST_EDU" -w "saddott" -x "(mail=sadd*)" name # extended LDIF # # LDAPv3 # base <ou=App Auth 1,dc=TEST_STUDENT,dc=TEST_EDU> with scope subtree # filter: (mail=sadd*) # requesting: name # # Addott\2C Steven (saddott), Students, TEST_STUDENT.TEST_EDU dn: cn=Addott\2C Steven (saddott),ou=Students,dc=TEST_STUDENT,dc=TEST_EDU name: Addott, Steven (saddott) # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Aug 1 16:45:47 localhost slapd-ldap[19490]: conn=1002 fd=8 ACCEPT from IP=127.0.0.1:46177 (IP=0.0.0.0:389) Aug 1 16:45:47 localhost slapd-ldap[19490]: conn=1002 op=0 BIND dn="cn=Addott\2C Steven (saddott),ou=Students,dc=TEST_STUDENT,dc=TEST_EDU" method=128 Aug 1 16:45:47 localhost slapd-ldap[19490]: conn=1002 op=0 BIND dn="cn=Addott\2C Steven (saddott),ou=Students,dc=TEST_STUDENT,dc=TEST_EDU" mech=SIMPLE ssf=0 Aug 1 16:45:47 localhost slapd-ldap[19490]: conn=1002 op=0 RESULT tag=97 err=0 text= Aug 1 16:45:47 localhost slapd-ldap[19490]: conn=1002 op=1 SRCH base="ou=App Auth 1,dc=TEST_STUDENT,dc=TEST_EDU" scope=2 deref=0 filter="(mail=sadd*)" Aug 1 16:45:47 localhost slapd-ldap[19490]: conn=1002 op=1 SRCH attr=name Aug 1 16:45:47 localhost slapd-ldap[19490]: conn=1002 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Aug 1 16:45:47 localhost slapd-ldap[19490]: conn=1002 op=2 UNBIND Aug 1 16:45:47 localhost slapd-ldap[19490]: conn=1002 fd=8 closed and searching again with the bindDN requiring a map rewrite - this time it failed [root@localhost openldap]# /opt/openldap/proxy/bin/ldapsearch -b "ou=App Auth 1,dc=TEST_STUDENT,dc=TEST_KSC" -D "mail=saddott(a)localhost.localdomain,ou=Students,DC=TEST_STUDENT,DC=TEST_ EDU" -w "saddott" -x "(mail=sadd*)" name ldap_bind: Other (e.g., implementation specific) error (80) additional info: bindDN massage error Aug 1 16:45:56 localhost slapd-ldap[19490]: conn=1003 fd=8 ACCEPT from IP=127.0.0.1:46180 (IP=0.0.0.0:389) Aug 1 16:45:56 localhost slapd-ldap[19490]: conn=1003 op=0 BIND dn="mail=saddott(a)localhost.localdomain,ou=Students,dc=TEST_STUDENT,dc=TE ST_EDU" method=128 Aug 1 16:45:56 localhost slapd-ldap[19490]: conn=1004 fd=13 ACCEPT from IP=127.0.0.1:46181 (IP=0.0.0.0:389) Aug 1 16:45:56 localhost slapd-ldap[19490]: conn=1004 op=0 SRCH base="ou=Students,dc=TEST_STUDENT,dc=TEST_EDU" scope=2 deref=0 filter="(mail=saddott(a)localhost.localdomain)" Aug 1 16:45:56 localhost slapd-ldap[19490]: conn=1004 op=0 SRCH attr=1.1 Aug 1 16:45:56 localhost slapd-ldap[19490]: conn=1004 op=0 SEARCH RESULT tag=101 err=1 nentries=0 text=00000000: LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece Aug 1 16:45:56 localhost slapd-ldap[19490]: conn=1004 op=1 UNBIND Aug 1 16:45:56 localhost slapd-ldap[19490]: conn=1004 fd=13 closed Aug 1 16:45:56 localhost slapd-ldap[19490]: ==> rewrite_context_apply error ... Aug 1 16:45:56 localhost slapd-ldap[19490]: conn=1003 op=0 RESULT tag=97 err=80 text=bindDN massage error Aug 1 16:45:56 localhost slapd-ldap[19490]: conn=1003 fd=8 closed (connection lost) I tried the same ldapsearch command again and this time it succeeded Aug 1 16:46:12 localhost slapd-ldap[19490]: conn=1005 fd=8 ACCEPT from IP=127.0.0.1:46182 (IP=0.0.0.0:389) Aug 1 16:46:12 localhost slapd-ldap[19490]: conn=1005 op=0 BIND dn="mail=saddott(a)localhost.localdomain,ou=Students,dc=TEST_STUDENT,dc=TE ST_EDU" method=128 Aug 1 16:46:12 localhost slapd-ldap[19490]: conn=1006 fd=13 ACCEPT from IP=127.0.0.1:46183 (IP=0.0.0.0:389) Aug 1 16:46:12 localhost slapd-ldap[19490]: conn=1006 op=0 SRCH base="ou=Students,dc=TEST_STUDENT,dc=TEST_EDU" scope=2 deref=0 filter="(mail=saddott(a)localhost.localdomain)" Aug 1 16:46:12 localhost slapd-ldap[19490]: conn=1006 op=0 SRCH attr=1.1 Aug 1 16:46:12 localhost slapd-ldap[19490]: conn=1006 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= Aug 1 16:46:12 localhost slapd-ldap[19490]: conn=1006 op=1 UNBIND Aug 1 16:46:12 localhost slapd-ldap[19490]: conn=1006 fd=13 closed Aug 1 16:46:12 localhost slapd-ldap[19490]: conn=1005 op=0 BIND dn="cn=Addott\2C Steven (saddott),ou=Students,dc=TEST_STUDENT,dc=TEST_EDU" mech=SIMPLE ssf=0 Aug 1 16:46:12 localhost slapd-ldap[19490]: conn=1005 op=0 RESULT tag=97 err=0 text= Aug 1 16:46:12 localhost slapd-ldap[19490]: conn=1005 op=1 SRCH base="ou=App Auth 1,dc=TEST_STUDENT,dc=TEST_EDU" scope=2 deref=0 filter="(mail=sadd*)" Aug 1 16:46:12 localhost slapd-ldap[19490]: conn=1005 op=1 SRCH attr=name Aug 1 16:46:12 localhost slapd-ldap[19490]: conn=1005 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Aug 1 16:46:12 localhost slapd-ldap[19490]: conn=1005 op=2 UNBIND Aug 1 16:46:12 localhost slapd-ldap[19490]: conn=1005 fd=8 closed AD is running on a VM openldap-2.4.26 was configured on a Fedora 15 (2.6.38.8-35.fc15.i686) VM with: ./configure --prefix=/opt/openldap/proxy --enable-ldap --enable-rewrite --enable-rwm --enable-memberof --with-tls=no non-comment lines from my slapd.conf look like: include /opt/openldap/proxy/etc/openldap/schema/core.schema include /opt/openldap/proxy/etc/openldap/schema/cosine.schema include /opt/openldap/proxy/etc/openldap/schema/inetorgperson.schema # schema to add sAMAccountName include /opt/openldap/proxy/etc/openldap/schema/myorg.schema pidfile /opt/openldap/proxy/var/run/slapd.pid argsfile /opt/openldap/proxy/var/run/slapd.args moduleload rwm.la ####################################################################### # BDB database definitions ####################################################################### database ldap suffix "dc=TEST_STUDENT,dc=TEST_EDU" uri "ldap://..." # ... is the ip of my AD host acl-bind bindmethod=simple binddn="cn=serviceuser,cn=Users,dc=TEST_STUDENT,dc=TEST_EDU" credentials="pwd" idassert-bind bindmethod=simple binddn="cn=serviceuser,cn=Users,dc=TEST_STUDENT,dc=TEST_EDU" credentials="pwd" authzID="dn:cn=serviceuser,cn=Users,dc=TEST_STUDENT,dc=TEST_EDU" loglevel 256 # much of this was borrowed from slapo-rwm man page overlay rwm rwm-rewriteEngine on # all dataflow from client to server referring to DNs rwm-rewriteContext default rwm-rewriteRule "(.+,)?<virtualnamingcontext>$" "$1<realnamingcontext>" ":" # empty filter rwm-rewriteContext searchFilter # from server to client rwm-rewriteContext searchEntryDN rwm-rewriteRule "(.+,)?<realnamingcontext>$" "$1<virtualnamingcontext>" ":" rwm-rewriteContext searchAttrDN alias searchEntryDN rwm-rewriteContext matchedDN alias searchEntryDN # misc empty rules rwm-rewriteContext referralAttrDN rwm-rewriteContext referralDN # define default rewrite for virtual of anything # ou=App Auth 1 -> ou=Students rwm-rewriteContext searchDN rwm-rewriteRule "(.+)?ou=App Auth 1,dc=TEST_STUDENT,dc=TEST_EDU$" "$1ou=Students,dc=TEST_STUDENT,dc=TEST_EDU" ":" # bind map from source rwm-rewriteMap ldap source2dn "ldap:///ou=Students,dc=TEST_STUDENT,dc=TEST_EDU?dn?sub" rwm-rewriteContext bindDN rwm-rewriteRule "^mail=([^,]*),ou=Students,dc=TEST_STUDENT,dc=TEST_EDU" "${source2dn(mail=$1)}" ":"

1 0

openldap 2.4.15 with error
by deconya 02 Aug '11

02 Aug '11

HI Im using openldap database with samba and Im with the database broken with this message Aug 2 11:20:43 earth slapd[4145]: slap_client_connect: URI=ldap://earth.esci.es DN="cn=admin,dc=esci,dc=es" ldap_sasl_bind_s failed (80) Aug 2 11:20:43 earth slapd[4145]: do_syncrepl: rid=005 retrying (1 retries left) Aug 2 11:20:43 earth slapd[4145]: slap_client_connect: URI=ldap://moon.esci.es DN="cn=admin,dc=esci,dc=es" ldap_sasl_bind_s failed (-1) Aug 2 11:20:43 earth slapd[4145]: do_syncrepl: rid=008 retrying (4 retries left) Aug 2 11:20:43 earth slapd[4145]: slap_client_connect: URI=ldap://moon.esci.es DN="cn=admin,cn=config" ldap_sasl_bind_s failed (-1) Aug 2 11:20:43 earth slapd[4145]: do_syncrepl: rid=004 retrying (4 retries left) Aug 2 11:20:43 earth slapd[4145]: bdb(dc=esci,dc=es): PANIC: fatal region error detected; run recovery Aug 2 11:20:43 earth last message repeated 9 times Aug 2 11:20:43 earth slapd[4145]: null_callback : error code 0x50 Aug 2 11:20:43 earth slapd[4145]: syncrepl_entry: rid=007 be_add failed (80) Aug 2 11:20:43 earth slapd[4145]: do_syncrepl: rid=007 retrying (4 retries left) Aug 2 11:20:45 earth slapd[4145]: bdb(dc=esci,dc=es): PANIC: fatal region error detected; run recovery Aug 2 11:20:48 earth last message repeated 9 times Aug 2 11:20:48 earth slapd[4145]: slap_client_connect: URI=ldap://earth.esci.es DN="cn=admin,dc=esci,dc=es" ldap_sasl_bind_s failed (80) Aug 2 11:20:48 earth slapd[4145]: do_syncrepl: rid=005 retrying Aug 2 11:20:48 earth slapd[4145]: bdb(dc=esci,dc=es): PANIC: fatal region error detected; run recovery Really I don't know how to repair and all information speaks to use db_recovery but inside ubuntu I dont' know how to install this commands. For example. http://sdb.open-xchange.com/node/29 It's some important to recover this databse because has information without backup and never has problems. Any help will be appreciate Thanks

2 1

chaining and referral object with two referrals
by Andreas Haubod 31 Jul '11

31 Jul '11

Hello, I use the overlay "chain" on one Server (lets call "global-ldap-01.site." ). How does the overlay chain behave, if it get an referral object with two referrals: dn: ou=finance,dc=mycomapny,dc=com objectClass: referral objectClass: extensibleObject ref: ldap://ldap-01-p.site/ou=finance, dc=mycomapny,dc=com ref: ldap://ldap-01-s.site/ou=finance, dc=mycomapny,dc=com This referral is in the DIT from the global-ldap-01 database, but refers to other ldap-servers. (ldap-01-p and ldap-01-s are configured as N-Way multi-master and located in different data centers) The objective is, that I can shut down one server (or if one Server fails) and the system is running without "bigger" disruption. If I turn off the ldap-01-p, ldap-01-s will be used from the global-ldap-01 So that works fine. If the ldap-01-p comes back, the global-ldap-01 use it again automatically. But if the Server ldap-01-p is down a longer time and I turn on this server, it has to replicate with the running ldap-01-s first. Can I control or configure this preemption and behavior? Thank and kindly regards Meike

1 0

Re: SlapD is using more CPU
by Édnei 30 Jul '11

30 Jul '11

Hello, sorry for the message delayed. So, how many clients you have in this server ? On 28-07-2011 05:28, arun.sasi1(a)wipro.com wrote: > > Hi, > > Below are the latest unexpected service outage log > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3273 op=2 SEARCH > RESULT tag=101 err=32 nentries=0 text= > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3276 fd=36 ACCEPT > from IP=134.32.44.37:60341 (IP=0.0.0.0:389) > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3276 op=0 BIND > dn="cn=admin,dc=emb,dc=slb,dc=com" method=128 > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3276 op=0 BIND > dn="cn=admin,dc=emb,dc=slb,dc=com" mech=SIMPLE ssf=0 > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3276 op=0 RESULT > tag=97 err=0 text= > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3276 op=1 SRCH > base="dc=emb,dc=slb,dc=com" scope=2 deref=0 > filter="(&(objectClass=posixAccount)(uidNumber=470649))" > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3276 op=1 SRCH > attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell > gecos description objectClass > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3276 op=1 SEARCH > RESULT tag=101 err=0 nentries=1 text= > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3262 op=8 SRCH > base="ou=Groups,dc=emb,dc=slb,dc=com" scope=2 deref=0 > filter="(&(objectClass=sambaGroupMapping)(sambaSID=s-1-1-0))" > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3262 op=8 SRCH > attr=gidNumber sambaSID sambaGroupType sambaSIDList description > displayName cn objectClass > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3262 op=8 SEARCH > RESULT tag=101 err=0 nentries=0 text= > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3273 op=3 SRCH > base="ou=Groups,dc=emb,dc=slb,dc=com" scope=2 deref=0 > filter="(&(objectClass=sambaGroupMapping)(gidNumber=65534))" > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3273 op=3 SRCH > attr=gidNumber sambaSID sambaGroupType sambaSIDList description > displayName cn objectClass > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3273 op=3 SEARCH > RESULT tag=101 err=0 nentries=0 text= > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3260 op=3 SRCH > base="ou=Groups,dc=emb,dc=slb,dc=com" scope=2 deref=0 > filter="(&(objectClass=sambaGroupMapping)(gidNumber=65534))" > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3260 op=3 SRCH > attr=gidNumber sambaSID sambaGroupType sambaSIDList description > displayName cn objectClass > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3260 op=3 SEARCH > RESULT tag=101 err=0 nentries=0 text= > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3262 op=9 SRCH > base="ou=Groups,dc=emb,dc=slb,dc=com" scope=2 deref=0 > filter="(&(objectClass=sambaGroupMapping)(sambaSID=s-1-5-2))" > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3262 op=9 SRCH > attr=gidNumber sambaSID sambaGroupType sambaSIDList description > displayName cn objectClass > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3262 op=9 SEARCH > RESULT tag=101 err=0 nentries=0 text= > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3276 fd=36 closed > (connection lost) > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: daemon: shutdown > requested and initiated. > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3173 fd=19 closed > (slapd shutdown) > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=4 fd=21 closed > (slapd shutdown) > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=0 fd=22 closed > (slapd shutdown) > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=1 fd=23 closed > (slapd shutdown) > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3230 fd=24 closed > (slapd shutdown) > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=6 fd=25 closed > (slapd shutdown) > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=805 fd=26 closed > (slapd shutdown) > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3223 fd=27 closed > (slapd shutdown) > > Jul 28 08:05:02 gb0135embldap01 slapd[23254]: conn=3246 fd=28 closed > (slapd shutdown) > > Thanks, > > -Arun > > *From:*Arun Sasi V (WI01 - Manage IT) > *Sent:* Tuesday, July 26, 2011 9:39 AM > *To:* 'Édnei' > *Subject:* RE: SlapD is using more CPU > > Hi, > > I can show you the settings by live meeting session... there we can > chat or can call too... > > Can I have your number and also let me know your convenient time to > share the session... > > Thanks, > > -Arun > > *From:*Arun Sasi V (WI01 - Manage IT) > *Sent:* Tuesday, July 26, 2011 9:16 AM > *To:* 'Édnei' > *Cc:* openldap-technical(a)openldap.org > *Subject:* RE: SlapD is using more CPU > > Fyi... > > Thanks, > > -Arun > > *From:*Édnei [mailto:ednei.felipe.rodrigues@gmail.com] > *Sent:* Tuesday, July 26, 2011 2:11 AM > *To:* Arun Sasi V (WI01 - Manage IT) > *Cc:* openldap-technical(a)openldap.org > *Subject:* Re: SlapD is using more CPU > > Hello. > Do you show us the settings ? > On 25-07-2011 04:54, arun.sasi1(a)wipro.com > <mailto:arun.sasi1@wipro.com> wrote: > > Hello Team, > > Whenever the number of search increase to the master server... slapd > is utilizing more about more than 100%... What could be the reason and > also is there any bench mark defined... > > Whenver it goes 100% slapd server is getting stopped... > > Thanks & Regards, > > *Arun Sasi V* > > *Please do not print this email unless it is absolutely necessary. * > > The information contained in this electronic message and any > attachments to this message are intended for the exclusive use of the > addressee(s) and may contain proprietary, confidential or privileged > information. If you are not the intended recipient, you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately and destroy all copies of this message and any attachments. > > WARNING: Computer viruses can be transmitted via email. The recipient > should check this email and any attachments for the presence of > viruses. The company accepts no liability for any damage caused by any > virus transmitted by this email. > > www.wipro.com <http://www.wipro.com> > > *Please do not print this email unless it is absolutely necessary. * > > The information contained in this electronic message and any > attachments to this message are intended for the exclusive use of the > addressee(s) and may contain proprietary, confidential or privileged > information. If you are not the intended recipient, you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately and destroy all copies of this message and any attachments. > > WARNING: Computer viruses can be transmitted via email. The recipient > should check this email and any attachments for the presence of > viruses. The company accepts no liability for any damage caused by any > virus transmitted by this email. > > www.wipro.com >

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical