openldap-technical

openldap-technical@openldap.org

9 participants
9868 discussions

Re: Slapd-ldap proxy between replica and mirror
by masarati＠aero.polimi.it 15 Apr '10

15 Apr '10

>> Hi, >> >> We have a similar scenario that the one explained in the post of Javier >> Manteiga: >> http://www.openldap.org/cgi-bin/wilma_hiliter/openldap-technical/200907/msg… >> >> We have deployed two servers: a master and a replica (delta-syncrepl). >> We >> added the chaining configuration that appears in openldap 2.4 >> administrator's guide (12.3.2) to handle the modifications originated >> from >> the replica. >> >> Replica slapd.conf: >> >> ##################### >> # Chaining configuration # >> ##################### >> overlay chain >> chain-uri "ldap://192.168.1.10:389" >> chain-idassert-bind bindmethod="simple" >> binddn="cn=replicator,dc=example,dc=com" >> credentials="secret" >> mode="self" >> chain-return-error TRUE >> >> ########## >> # Replica # >> ########## >> database bdb >> suffix "dc=example,dc=com" >> rootdn "cn=Administrator,dc=example,dc=com" >> rootpw "secret" >> .... >> ################## >> # Syncrepl directives # >> ################## >> syncrepl rid=001 >> provider=ldap://192.168.1.10:389 >> type=refreshAndPersist >> retry="60 +" >> searchbase="dc=example,dc=com" >> filter="(objectclass=*)" >> scope=sub >> attrs="*" >> schemachecking=on >> binddn="cn=replicator,dc=example,dc=com" >> bindmethod=simple >> credentials=secret >> sizelimit=unlimited >> logbase="cn=accesslog" >> logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" >> syncdata=accesslog >> >> # Refer updates to the master >> updateref ldap://192.168.1.10:389 >> >> The problem appears when we change the single master for a mirrormode >> configuration (administrator guide 18.3.4.1). In addition, we set up a >> back-ldap proxy between mirror and replica. >> >> back-ldap proxy slapd.conf: >> >> ######## >> # Proxy # >> ######## >> database ldap >> suffix "dc=example,dc=com" >> rootdn "cn=slapd-ldap" >> >> uri "ldap://192.168.1.20:389 ldap://192.168.1.30:389" >> >> >> The IP addresses are: >> 192.168.1.10 -> Back-ldap proxy >> 192.168.1.20 -> Mirror mode server 1 >> 192.168.1.30 -> Mirror mode server 2 >> >> >> When we try to modify the password through the replica, we get the >> following >> messages in the server where is located the proxy: >> >> ldap-proxy[13175]: daemon: activity on 1 descriptor >> ldap-proxy[13175]: daemon: activity on: >> ldap-proxy[13175]: 12r >> ldap-proxy[13175]: >> ldap-proxy[13175]: daemon: read active on 12 >> ldap-proxy[13175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL >> ldap-proxy[13175]: connection_get(12) >> ldap-proxy[13175]: connection_get(12): got connid=1002 >> ldap-proxy[13175]: connection_read(12): checking for input on id=1002 >> ldap-proxy[13175]: op tag 0x66, time 1270632398 >> ldap-proxy[13175]: conn=1002 op=2 do_modify >> ldap-proxy[13175]: conn=1002 op=2 do_modify: dn >> (uid=user,ou=people,dc=example,dc=com) >> ldap-proxy[13175]: => get_ctrls >> ldap-proxy[13175]: => get_ctrls: oid="2.16.840.1.113730.3.4.18" >> (noncritical) >> ldap-proxy[13175]: parseProxyAuthz: conn 1002 >> authzid="dn:uid=user,ou=people,dc=example,dc=com" >> ldap-proxy[13175]: slap_sasl_getdn: conn 1002 >> id=dn:uid=user,ou=people,dc=example,dc=com [len=38] >> ldap-proxy[13175]: >>> dnNormalize: >> <uid=user,ou=people,dc=example,dc=com> >> ldap-proxy[13175]: <<< dnNormalize: >> <uid=user,ou=people,dc=example,dc=com> >> ldap-proxy[13175]: ==>slap_sasl2dn: converting SASL name >> uid=user,ou=people,dc=example,dc=com to a DN >> ldap-proxy[13175]: <==slap_sasl2dn: Converted SASL name to <nothing> >> ldap-proxy[13175]: parseProxyAuthz: conn=1002 >> "uid=user,ou=people,dc=example,dc=com" >> ldap-proxy[13175]: ==>slap_sasl_authorized: can >> cn=replicator,dc=example,dc=com become >> uid=user,ou=people,dc=example,dc=com? >> ldap-proxy[13175]: <== slap_sasl_authorized: return 48 >> ldap-proxy[13175]: <= get_ctrls: n=1 rc=123 err="not authorized to >> assume >> identity" >> ldap-proxy[13175]: send_ldap_result: conn=1002 op=2 p=3 >> ldap-proxy[13175]: send_ldap_result: err=123 matched="" text="not >> authorized >> to assume identity" >> ldap-proxy[13175]: send_ldap_response: msgid=3 tag=103 err=123 >> ldap-proxy[13175]: conn=1002 op=2 RESULT tag=103 err=123 text=not >> authorized >> to assume identity >> ldap-proxy[13175]: conn=1002 op=2 do_modify: get_ctrls failed >> ldap-proxy[13175]: daemon: activity on 1 descriptor >> ldap-proxy[13175]: daemon: activity on: >> >> The authorization is denied for cn=replicator,dc=example,dc=com. > > The error looks self-explanatory: the identity > "cn=replicator,dc=example,dc=com" is not authorized to assume the identity > of the client that attempted the write. The failure appears to happen in > slap_sasl2dn(), where the user's DN is converted to <nothing> (the > "mapping" fails). It is not clear why it fails. Sorry, I take the last sentence back: mapping a DN to nothing means there was nothing to map. The failure is just later, where (pretty self-explanatory): ldap-proxy[13175]: ==>slap_sasl_authorized: can cn=replicator,dc=example,dc=com become uid=user,ou=people,dc=example,dc=com? ldap-proxy[13175]: <== slap_sasl_authorized: return 48 ldap-proxy[13175]: <= get_ctrls: n=1 rc=123 err="not authorized to assume identity" the entry "cn=replicator,dc=example,dc=com" does not have the right to assume the identity of "uid=user,ou=people,dc=example,dc=com". > You probably do not show > enough of your master and replica slapd.conf. This is correct. Also, the error may depend on the value of the authzTo/authzFrom attributes of the identities involved in the mapping. As clearly stated in slapd-ldap man page about idassert: [snip] Other identity assertion modes are anonymous and self, which respectively mean that the empty or the client’s identity will be asserted; [snip] For all modes that require the use of the proxyAuthz control, on the remote server the proxy identity must have appropriate authzTo permissions, or the asserted identities must have appropriate authzFrom permissions. p.

2 3

serviceSearchDescriptor problem.
by Miha Krajnc 15 Apr '10

15 Apr '10

Hey, I'm having a problem setting up an openLDAP database. I've installed it, configured it (that took a while, OpenLDAP should realy supply a script to do it manualy) and set my server to use it for authentication (as well as the /etc/passwd file). But now i want to configure the server to work with the sudoers file so users can use the "sudo" command. Here is where i'm having problems. I folowed this guide: http://georgia.ubuntuforums.org/showthread.php?p=9121830 <http://georgia.ubuntuforums.org/showthread.php?p=9121830#post9121830>And i came to the part where i need to insert this code into the database with ldapadd: dn: ou=SUDOers,dc=prvi-dijak,dc=si objectClass: top objectClass: organizationalUnit ou: SUDOers serviceSearchDescriptor: sudoers: ou=sudoers,dc=example,dc=com But here is where i run into a problem. The server always gives out an error, like this: ldapadd -f sudoWork/sudoMaster.ldif -h 127.0.0.1 -D cn=admin,dc=prvi-dijak,dc=si -W -x Enter LDAP Password: adding new entry "ou=SUDOers,dc=prvi-dijak,dc=si" ldap_add: Undefined attribute type (17) additional info: serviceSearchDescriptor: attribute type undefined And i have no idea why. I also tried to do it manualy. I added the organizationalUnit with "phpLDAPadmin" but i can not find the serviceSearchDescriptor attribute anywhere. Could you advise me on how to fix this problem? -- Good day, Miha Krajnc.

2 2

Facing ldap_sasl_bind_s failed (-1) error for N-way Multimaster ldap replication
by Shamika Joshi 15 Apr '10

15 Apr '10

I'm seeing following erros in syslog after I was done with N-way Multimaster ldap replication. I following these links exactly to configure my master & slave servers http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master https://help.ubuntu.com/9.10/serverguide/C/openldap-server.html Apr 15 00:28:08 x6 slapd[5783]: slap_client_connect: URI=ldap:// x6.testlab.com DN="cn=admin,cn=config" ldap_sasl_bind_s failed (49) Apr 15 00:28:08 x6 slapd[5783]: do_syncrepl: rid=001 rc 49 retrying (1 retries left) Apr 15 00:28:08 x6 slapd[5783]: slap_client_connect: URI=ldap:// x6slave.testlab.com DN="cn=admin,cn=config" ldap_sasl_bind_s failed (-1) Apr 15 00:28:08 x6 slapd[5783]: do_syncrepl: rid=002 rc -1 retrying (1 retries left) While troubleshooting ldap_sasl_bind_s failed (-1) error in my syslog for ldap replication, I have also ended adding wrong olcSyncrepl entries as shown in snapshot below. How should I go about removing these entries from my cn=config? Could anyone give me an example? Thanks Shamika dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootDN: cn=admin,cn=config olcRootPW: {CRYPT}7hzU8RaZxaGi2 olcSyncrepl: {0}rid=001 provider=ldap://x6.testlab.combinddn="cn=admin,cn=con fig" bindmethod=simple credentials=1234 searchbase="cn=config" type=refreshAn dPersist retry="5 5 300 5" timeout=1 olcSyncrepl: {1}rid=002 provider=ldap://x6slave.testlab.combinddn="cn=admin,c n=config" bindmethod=simple credentials=1234 searchbase="cn=config" type=refr eshAndPersist retry="5 5 300 5" timeout=1 olcSyncrepl: {2}rid=001 provider=ldap://x6.testlab.combinddn="cn=admin,dc=tes <==== tlab,dc=com" bindmethod=simple credentials=secret searchbase="cn=config" type =refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncrepl: {3}rid=002 provider=ldap://ldap02.example.combinddn="cn=admin,dc <==== =testlab,dc=com" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncrepl: {4}rid=001 provider=ldap://x6.testlab.combinddn="cn=admin,cn=con <==== fig" bindmethod=simple credentials=secret searchbase="cn=config" type=refresh AndPersist retry="5 5 300 5" timeout=1 olcSyncrepl: {5}rid=002 provider=ldap://x6slave.testlab.combinddn="cn=admin,c <==== n=config" bindmethod=simple credentials=secret searchbase="cn=config" type=re freshAndPersist retry="5 5 300 5" timeout=1 olcMirrorMode: TRUE dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov dn: olcOverlay={1}syncprov,olcDatabase={0}config,cn=config <==== objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {1}syncprov dn: olcOverlay={2}syncprov,olcDatabase={0}config,cn=config <==== objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {2}syncprov dn: olcOverlay={3}syncprov,olcDatabase={0}config,cn=config<==== objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {3}syncprov dn: olcOverlay={4}syncprov,olcDatabase={0}config,cn=config<==== objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {4}syncprov dn: olcOverlay={5}syncprov,olcDatabase={0}config,cn=config<==== objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {5}syncprov

1 0

OpenLDAP Data Directory issue
by rahul.manchanda＠bt.com 14 Apr '10

14 Apr '10

Hello, For a running LDAP if I delete the data directory still the LDAP is responding to reads and writes without giving any error. All logins in related to application are working fine. Is this picking the data from cache or actual data itself is getting stored somewhere. Can someone please provide his/her technical expertise on this behavior? Regards Rahul Manchanda ------------------------------------------------------------------------ ---------------------------------- Andes , Selfcare Platform Build Team tel: (+91) (20) 66018100 extn: 6178; e-mail: rahul.manchanda(a)bt.com Address: Tech Mahindra, Sharada Center, Erandwana Pune-4

3 3

Sincronizing two different structred trees
by Rodrigo Renie Braga 14 Apr '10

14 Apr '10

Hello list. I was wondering if it's possible to sincronize, using chaining or syncrepl, two different structured OpenLDAP servers, actually, both servers are equal on a specific sub-tree and it's that specific subtree that I'd like to sincronize. Something like: Server A dc=example,dc=com | | - ou=users | | - ou=company Server B dc=other,dc=org | | - ou=people | | - ou=company It's both "company" subtrees that i'd like to sinc... Is it possible? Thanks in advance...

2 2

SASL EXTERNAL, sasldb2 and authz-regexp
by Götz Reinicke - IT-Koordinator 14 Apr '10

14 Apr '10

Hi folks, first of all thanks to all comments about my previous posts! Finaly I'm faced with hopefully the last authentication problem and may be somewone could tell me an answere or point me once more into the right direction. My consumer server should bind to the provider using sasl with the saslmech external. (Red Hat 5.x, cyrus-sasl-2.1.22, openldap-2.3.43-3 ) I'v changed the slapd.conf files on both servers: consumer: syncrepl ... bindmethod=sasl saslmech=EXTERNAL starttls=yes provider: authz-regexp "dn=email=webmaster(a)filmakademie.de,cn=ldap2.filmakademie.de,ou=it officenet,o=filmakademie baden-wuerttemberg gmbh,l=ludwigbsburg,st=baden-wuerttemberg,c=de" "cn=replicator,dc=filmakademie,dc=de" after restarting both servers I do get the error: <==slap_sasl2dn: Converted SASL name to <nothing> SASL [conn=0] Error: unable to open Berkeley db /etc/sasldb2: No such file or directory I've searched my docs, online howtoos and found postings about "know sasl before using openldap" but the sasl docs didn't help too. Thanks for any help and best regards, Götz -- Götz Reinicke IT-Koordinator Tel. +49 7141 969 420 Fax +49 7141 969 55 420 E-Mail goetz.reinicke(a)filmakademie.de Filmakademie Baden-Württemberg GmbH Akademiehof 10 71638 Ludwigsburg www.filmakademie.de Eintragung Amtsgericht Stuttgart HRB 205016 Vorsitzende des Aufsichtsrats: Prof. Dr. Claudia Hübner Geschäftsführer: Prof. Thomas Schadt

3 4

Re: Problem with SSL/TLS
by Chris Jacobs 13 Apr '10

13 Apr '10

/etc/ldap.conf is used by nss tools and the ilk. /etc/openldap/ldap.conf would be used by openldap tools - like ldapsearch. I have the same setting there for tls_checkpeer - but in the latter ldap.conf (under openldap). FWIW: there's apparently no real different format for the two files; while one would only be setup on ldap servers, mine are identical and things work with a mirror master, both setup behind a VIP (fail over, not load balanced) and a plethora of slaves in different subdomains. - chris PS: I'd forgotten to 'reply-to-all' earlier. :) Chris Jacobs, Systems Administrator Apollo Group | Apollo Marketing | Aptimus 2001 6th Ave Ste 3200 | Seattle, WA 98121 phone: 206.441.9100 x1245 | mobile: 206.601.3256 | fax: 206.441.9661 email: chris.jacobs(a)apollogrp.edu ________________________________ From: Lynn York To: Chris Jacobs Sent: Mon Apr 12 10:29:19 2010 Subject: RE: Problem with SSL/TLS Here is my /etc/ldap.conf: #host 127.0.0.1 base cn=users,dc=testing,dc=com uri ldap://localhost:636 binddn cn=manager,dc=testing,dc=com bindpw password scope sub timelimit 120 bind_policy soft bind_timelimit 120 idle_timelimit 3600 ssl on tls_cacert /etc/openldap/cacerts/servercrt.pem tls_cacertdir /etc/openldap/cacerts tls_checkpeer no nss_base_group cn=groups,dc=testing,dc=com?sub pam_password md5 I have tried it with and without “tls_checkpeer”…. I am sort of at a loss as to what it can be. I also tested it using openssl client.. and here is the output: CONNECTED(00000003) SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL_connect:SSLv3 read server hello A depth=1 /C=US/ST=Pennsylvania/O=MavenWire, LLC/OU=Support/CN=testing.com/emailAddress=testing@testing.com<http://testing.com/emailAddress=testing@testing.com> verify return:1 depth=0 /C=US/ST=Pennsylvania/L=King of Prussia/O=MavenWire, LLC/OU=Support/CN=testing.com/emailAddress=testing@testing.com<http://testing.com/emailAddress=testing@testing.com> verify return:1 SSL_connect:SSLv3 read server certificate A SSL_connect:SSLv3 read server certificate request A SSL_connect:SSLv3 read server done A SSL_connect:SSLv3 write client certificate A SSL_connect:SSLv3 write client key exchange A SSL_connect:SSLv3 write certificate verify A SSL_connect:SSLv3 write change cipher spec A SSL_connect:SSLv3 write finished A SSL_connect:SSLv3 flush data SSL_connect:SSLv3 read finished A --- Certificate chain 0 s:/C=US/ST=Pennsylvania/L=King of Prussia/O=MavenWire, LLC/OU=Support/CN=testing.com/emailAddress=testing@testing.com<http://testing.com/emailAddress=testing@testing.com> i:/C=US/ST=Pennsylvania/O=MavenWire, LLC/OU=Support/CN=testing.com/emailAddress=testing@testing.com<http://testing.com/emailAddress=testing@testing.com> -----BEGIN CERTIFICATE----- MIIDPzCCAqigAwIBAgIBATANBgkqhkiG9w0BAQUFADCBmTELMAkGA1UEBhMCVVMx FTATBgNVBAgTDFBlbm5zeWx2YW5pYTEXMBUGA1UEChMOTWF2ZW5XaXJlLCBMTEMx EDAOBgNVBAsTB1N1cHBvcnQxFjAUBgNVBAMTDW1hdmVud2lyZS5jb20xMDAuBgkq hkiG9w0BCQEWIW13LWhvc3Rpbmctc3lzYWRtaW5AbWF2ZW53aXJlLmNvbTAeFw0x MDA0MDkyMDUwNDlaFw0xMTA0MDkyMDUwNDlaMIGzMQswCQYDVQQGEwJVUzEVMBMG A1UECBMMUGVubnN5bHZhbmlhMRgwFgYDVQQHEw9LaW5nIG9mIFBydXNzaWExFzAV BgNVBAoTDk1hdmVuV2lyZSwgTExDMRAwDgYDVQQLEwdTdXBwb3J0MRYwFAYDVQQD Ew1tYXZlbndpcmUuY29tMTAwLgYJKoZIhvcNAQkBFiFtdy1ob3N0aW5nLXN5c2Fk bWluQG1hdmVud2lyZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMGp U5HS8A2DRokU5TQz1Dyycx/VA2uhrRwatTPq8xtoQigWM2feiXUwtoiQ/gP3IjB5 AJLf8aC8y72Io2IME4aqh1s7bdscV2b0QMs1MfXiL9h2XQWZVCkgDLjjb1XzHhlw 3I6vkrh/uGH2PQyXbuG/6dIguzCHfnGgGXgy1o45AgMBAAGjezB5MAkGA1UdEwQC MAAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRl MB0GA1UdDgQWBBR0mZkOwZZjYFiWlloEvgSpoPxOuzAfBgNVHSMEGDAWgBS7Iqbt j25p56k4BdHpXYG3xjhdijANBgkqhkiG9w0BAQUFAAOBgQARO7OcDgNOZ3WuP9IM mUeQWuGVBAh7MQ3Uv2HrSOAfTHxg/QxjCZZlwULq1EZZDHNgyPMM+5ElWSID5El/ fdxHcizNOjPPuVPwtJIrs8RhTIehn0aKryqtkvpcAnxFuc+VxwcCBhV58wtbSuXL PXRTvoTDXWkiXwdR4m1bubOF5A== -----END CERTIFICATE----- 1 s:/C=US/ST=Pennsylvania/O=MavenWire, LLC/OU=Support/CN=testing.com/emailAddress=testing@testing.com<http://testing.com/emailAddress=testing@testing.com> i:/C=US/ST=Pennsylvania/O=MavenWire, LLC/OU=Support/CN=testing.com/emailAddress=testing@testing.com<http://testing.com/emailAddress=testing@testing.com> -----BEGIN CERTIFICATE----- MIIDJTCCAo6gAwIBAgIBADANBgkqhkiG9w0BAQUFADCBmTELMAkGA1UEBhMCVVMx FTATBgNVBAgTDFBlbm5zeWx2YW5pYTEXMBUGA1UEChMOTWF2ZW5XaXJlLCBMTEMx EDAOBgNVBAsTB1N1cHBvcnQxFjAUBgNVBAMTDW1hdmVud2lyZS5jb20xMDAuBgkq hkiG9w0BCQEWIW13LWhvc3Rpbmctc3lzYWRtaW5AbWF2ZW53aXJlLmNvbTAeFw0x MDA0MDkyMDUwMDBaFw0xMzA0MDgyMDUwMDBaMIGZMQswCQYDVQQGEwJVUzEVMBMG A1UECBMMUGVubnN5bHZhbmlhMRcwFQYDVQQKEw5NYXZlbldpcmUsIExMQzEQMA4G A1UECxMHU3VwcG9ydDEWMBQGA1UEAxMNbWF2ZW53aXJlLmNvbTEwMC4GCSqGSIb3 DQEJARYhbXctaG9zdGluZy1zeXNhZG1pbkBtYXZlbndpcmUuY29tMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQC6yVPz1ccamBapkRR8vTjpiKj7JuJKdCecTQ7/ f2KWoIRuYdEWU4njEsu/KHQWmxR0lelqOzM15EHVanOJCsPKCEMQg4lY5cQm8W1Q YCGQyqg0ITQ6nbPuQchFHHnldqYZsfiWjly8SC454B61ItHi9Lcxvfh4cVonSCqw KeoF4wIDAQABo3sweTAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NM IEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUuyKm7Y9uaeepOAXR6V2B t8Y4XYowHwYDVR0jBBgwFoAUuyKm7Y9uaeepOAXR6V2Bt8Y4XYowDQYJKoZIhvcN AQEFBQADgYEAg5xdwSmeF2afO1UJZys5Mmvn7YfUdOIRgVaYN5sQLt1ixCXjDEew 56br5RKs2W6PaqeXl7CN5bYqxDDo3ekds9uquzE91HaKH04gQUc+/NA82y5NiaGZ EOiLoTvc/+PShAjl8ZVwf+eNloay2FChb6S47rX0f28tKXpteWax00k= -----END CERTIFICATE----- --- Server certificate subject=/C=US/ST=Pennsylvania/L=King of Prussia/O=MavenWire, LLC/OU=Support/CN=testing.com/emailAddress=testing@testing.com<http://testing.com/emailAddress=testing@testing.com> issuer=/C=US/ST=Pennsylvania/O=MavenWire, LLC/OU=Support/CN=testing.com/emailAddress=testing@testing.com<http://testing.com/emailAddress=testing@testing.com> --- Acceptable client certificate CA names /C=US/ST=Pennsylvania/O=MavenWire, LLC/OU=Support/CN=testing.com/emailAddress=testing@testing.com<http://testing.com/emailAddress=testing@testing.com> /C=US/ST=Pennsylvania/L=King of Prussia/O=MavenWire, LLC/OU=Support/CN=testing.com/emailAddress=testing@testing.com<http://testing.com/emailAddress=testing@testing.com> --- SSL handshake has read 2160 bytes and written 2117 bytes --- New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 1024 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : AES256-SHA Session-ID: 7475F12DDB7A8CAE5047244136B5CDBD877D9C71E72B7DE379FEEC681ECA635C Session-ID-ctx: Master-Key: 5253A27AAB6096A906DD64C1565110582414DE0B24543D7275D267235BDF06F75EA1E745323E6E34420D90613AD74BF7 Key-Arg : None Krb5 Principal: None Start Time: 1271093212 Timeout : 300 (sec) Verify return code: 0 (ok) That all appears to be OK… which is confusing to me as to why it won’t work? From: Chris Jacobs [mailto:Chris.Jacobs@apollogrp.edu<mailto:Chris.Jacobs@apollogrp.edu>] Sent: Monday, April 12, 2010 12:30 PM To: 'lynn.york(a)mavenwire.com<mailto:lynn.york@mavenwire.com>' Subject: Re: Problem with SSL/TLS Did you setup the CA's cert as a trusted CA on your clients? There is also a setting to skip verifying the cert for /etc/openldap/ldap.conf - but I can't recall atm. - chris Chris Jacobs, Systems Administrator Apollo Group | Apollo Marketing | Aptimus 2001 6th Ave Ste 3200 | Seattle, WA 98121 phone: 206.441.9100 x1245 | mobile: 206.601.3256 | fax: 206.441.9661 email: chris.jacobs(a)apollogrp.edu<mailto:chris.jacobs@apollogrp.edu> ________________________________ From: openldap-technical-bounces+chris.jacobs=apollogrp.edu<http://apollogrp.edu>@OpenLDAP.org To: openldap-technical(a)openldap.org<mailto:openldap-technical@openldap.org> Sent: Mon Apr 12 08:13:39 2010 Subject: Problem with SSL/TLS I have created a cert. on the server and openldap starts without any issues, however when I attempt to connect via ldaps I keep getting the following error: ?? ?? ldapsearch -x -H ldaps://localhost:636 -D "cn=Manager,dc=testing,dc=com" -W -b "dc=testing,dc=com" "(objectClass=top)" Enter LDAP Password: ldap_bind: Can't contact LDAP server (-1) ?????????????? additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed ?? I can???t quite pin point what the problem might be.?? ?? Lynn York II MavenWire Hosting Admin www.mavenwire.com<http://www.mavenwire.com> (866) 343-4870 x717 ?? MavenWire - We DELIVER http://www.mavenwire.com ?? This e-mail and any attached files may contain confidential and/or privileged material for the sole use of the intended recipient.?? Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive this e-mail for the recipient), you may not review, copy or distribute this message.?? Please contact the sender by reply e-mail and delete all copies of this message. ?? MavenWire - We DELIVER http://www.mavenwire.com This e-mail and any attached files may contain confidential and/or privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive this e-mail for the recipient), you may not review, copy or distribute this message. Please contact the sender by reply e-mail and delete all copies of this message. ________________________________ This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system. MavenWire - We DELIVER http://www.mavenwire.com This e-mail and any attached files may contain confidential and/or privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive this e-mail for the recipient), you may not review, copy or distribute this message. Please contact the sender by reply e-mail and delete all copies of this message. ________________________________ This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.

4 6

Overlay Chain Extended Passmod Problem
by Ralf Zimmermann 13 Apr '10

13 Apr '10

Hi all, last week I wrote to the list because I have a problem with overlay chain. Today I traced the problem. The configuration and the host are the same. OpenLDAP syncrepl runs fine over the weekend. But if I want to change a password nothing happens. I can't see any packet with tcpdump from the slave to the master. I traced slapd with loglevel=65535. The slave is openldap 2.4.21. # Here the trace with no successfull passmod operation: ----------------------------------------------------- conn=1126 op=1 BIND dn="cn=ldapadmin,dc=camelot,dc=de" method=128 do_bind: version=3 dn="cn=ldapadmin,dc=camelot,dc=de" method=128 => bdb_entry_get: ndn: "cn=ldapadmin,dc=camelot,dc=de" => bdb_entry_get: oc: "(null)", at: "(null)" bdb_dn2entry("cn=ldapadmin,dc=camelot,dc=de") => bdb_entry_get: found entry: "cn=ldapadmin,dc=camelot,dc=de" bdb_entry_get: rc=0 => bdb_entry_get: ndn: "cn=default,ou=policies,dc=camelot,dc=de" => bdb_entry_get: oc: "(null)", at: "(null)" bdb_dn2entry("cn=default,ou=policies,dc=camelot,dc=de") bdb_entry_get: found entry: "cn=default,ou=policies,dc=camelot,dc=de" bdb_entry_get: rc=0 ==> hdb_bind: dn: cn=ldapadmin,dc=camelot,dc=de bdb_dn2entry("cn=ldapadmin,dc=camelot,dc=de") ) # Here the trace after I restart slapd with exactly the same config # and working passmod oepration: ------------------------------------------------------------------ conn=1000 op=1 BIND dn="cn=ldapadmin,dc=camelot,dc=de" method=128 do_bind: version=3 dn="cn=ldapadmin,dc=camelot,dc=de" method=128 => bdb_entry_get: ndn: "cn=ldapadmin,dc=camelot,dc=de" => bdb_entry_get: oc: "(null)", at: "(null)" bdb_dn2entry("cn=ldapadmin,dc=camelot,dc=de") => hdb_dn2id("cn=ldapadmin,dc=camelot,dc=de") <= hdb_dn2id: got id=0x5 entry_decode: "" <= entry_decode() => bdb_entry_get: found entry: "cn=ldapadmin,dc=camelot,dc=de" bdb_entry_get: rc=0 => bdb_entry_get: ndn: "cn=default,ou=policies,dc=camelot,dc=de" => bdb_entry_get: oc: "(null)", at: "(null)" bdb_dn2entry("cn=default,ou=policies,dc=camelot,dc=de") => hdb_dn2id("ou=policies,dc=camelot,dc=de") <= hdb_dn2id: got id=0x9 => hdb_dn2id("cn=default,ou=policies,dc=camelot,dc=de") <= hdb_dn2id: got id=0xa entry_decode: "" <= entry_decode() => bdb_entry_get: found entry: "cn=default,ou=policies,dc=camelot,dc=de" bdb_entry_get: rc=0 ==> hdb_bind: dn: cn=ldapadmin,dc=camelot,dc=de bdb_dn2entry("cn=ldapadmin,dc=camelot,dc=de") When the passmod operation is successfull there are hdb_dn2id entries in the trace. When the passmod operation ist not successfull the entries doesn't exist. What happens, that I must restart the slapd? The configuration is the same and all other things works fine. Only the write operations to the master hangs. If I make a passmod without TLS everything works fine and I can change the password after I restarted the slapd on the slave. Then I can change the passwords the wholy day. Tomorrow I'll must restart slapd on the slave because the passmod operation is not successfull. Any ideas? regards Ralf Zimmermann -- .''`. Ralf Zimmermann : :' : SIEGNETZ.IT GmbH `. `' Schneppenkauten 1a `- 57076 Siegen Tel.: +49 271 68193 13 Fax.: +49 271 68193 29 Amtsgericht Siegen HRB4838 Geschaeftsfuehrer: Oliver Seitz Sitz der Gesellschaft ist Siegen

2 2

Problem with SSL/TLS
by Lynn York 12 Apr '10

12 Apr '10

I have created a cert. on the server and openldap starts without any issues, however when I attempt to connect via ldaps I keep getting the following error: ldapsearch -x -H ldaps://localhost:636 -D "cn=Manager,dc=testing,dc=com" -W -b "dc=testing,dc=com" "(objectClass=top)" Enter LDAP Password: ldap_bind: Can't contact LDAP server (-1) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed I can’t quite pin point what the problem might be. Lynn York II MavenWire Hosting Admin www.mavenwire.com (866) 343-4870 x717 MavenWire - We DELIVER http://www.mavenwire.com This e-mail and any attached files may contain confidential and/or privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive this e-mail for the recipient), you may not review, copy or distribute this message. Please contact the sender by reply e-mail and delete all copies of this message. MavenWire - We DELIVER http://www.mavenwire.com This e-mail and any attached files may contain confidential and/or privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive this e-mail for the recipient), you may not review, copy or distribute this message. Please contact the sender by reply e-mail and delete all copies of this message.

2 2

Re: Problem with SSL/TLS
by Chris Jacobs 12 Apr '10

12 Apr '10

Also, if you've the CA's cert in a file and point the conf directly to it (via tls_cacert) it's unnecessary to use the tls_cacetdir directive. - chris Chris Jacobs, Systems Administrator Apollo Group | Apollo Marketing | Aptimus 2001 6th Ave Ste 3200 | Seattle, WA 98121 phone: 206.441.9100 x1245 | mobile: 206.601.3256 | fax: 206.441.9661 email: chris.jacobs(a)apollogrp.edu ________________________________ From: Chris Jacobs To: 'lynn.york(a)mavenwire.com' Cc: 'openldap-technical(a)openldap.org' Sent: Mon Apr 12 10:35:51 2010 Subject: Re: Problem with SSL/TLS /etc/ldap.conf is used by nss tools and the ilk. /etc/openldap/ldap.conf would be used by openldap tools - like ldapsearch. I have the same setting there for tls_checkpeer - but in the latter ldap.conf (under openldap). FWIW: there's apparently no real different format for the two files; while one would only be setup on ldap servers, mine are identical and things work with a mirror master, both setup behind a VIP (fail over, not load balanced) and a plethora of slaves in different subdomains. - chris PS: I'd forgotten to 'reply-to-all' earlier. :) Chris Jacobs, Systems Administrator Apollo Group | Apollo Marketing | Aptimus 2001 6th Ave Ste 3200 | Seattle, WA 98121 phone: 206.441.9100 x1245 | mobile: 206.601.3256 | fax: 206.441.9661 email: chris.jacobs(a)apollogrp.edu ________________________________ From: Lynn York To: Chris Jacobs Sent: Mon Apr 12 10:29:19 2010 Subject: RE: Problem with SSL/TLS Here is my /etc/ldap.conf: #host 127.0.0.1 base cn=users,dc=testing,dc=com uri ldap://localhost:636 binddn cn=manager,dc=testing,dc=com bindpw password scope sub timelimit 120 bind_policy soft bind_timelimit 120 idle_timelimit 3600 ssl on tls_cacert /etc/openldap/cacerts/servercrt.pem tls_cacertdir /etc/openldap/cacerts tls_checkpeer no nss_base_group cn=groups,dc=testing,dc=com?sub pam_password md5 I have tried it with and without “tls_checkpeer”…. I am sort of at a loss as to what it can be. I also tested it using openssl client.. and here is the output: CONNECTED(00000003) SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL_connect:SSLv3 read server hello A depth=1 /C=US/ST=Pennsylvania/O=MavenWire, LLC/OU=Support/CN=testing.com/emailAddress=testing@testing.com<http://testing.com/emailAddress=testing@testing.com> verify return:1 depth=0 /C=US/ST=Pennsylvania/L=King of Prussia/O=MavenWire, LLC/OU=Support/CN=testing.com/emailAddress=testing@testing.com<http://testing.com/emailAddress=testing@testing.com> verify return:1 SSL_connect:SSLv3 read server certificate A SSL_connect:SSLv3 read server certificate request A SSL_connect:SSLv3 read server done A SSL_connect:SSLv3 write client certificate A SSL_connect:SSLv3 write client key exchange A SSL_connect:SSLv3 write certificate verify A SSL_connect:SSLv3 write change cipher spec A SSL_connect:SSLv3 write finished A SSL_connect:SSLv3 flush data SSL_connect:SSLv3 read finished A --- Certificate chain 0 s:/C=US/ST=Pennsylvania/L=King of Prussia/O=MavenWire, LLC/OU=Support/CN=testing.com/emailAddress=testing@testing.com<http://testing.com/emailAddress=testing@testing.com> i:/C=US/ST=Pennsylvania/O=MavenWire, LLC/OU=Support/CN=testing.com/emailAddress=testing@testing.com<http://testing.com/emailAddress=testing@testing.com> -----BEGIN CERTIFICATE----- MIIDPzCCAqigAwIBAgIBATANBgkqhkiG9w0BAQUFADCBmTELMAkGA1UEBhMCVVMx FTATBgNVBAgTDFBlbm5zeWx2YW5pYTEXMBUGA1UEChMOTWF2ZW5XaXJlLCBMTEMx EDAOBgNVBAsTB1N1cHBvcnQxFjAUBgNVBAMTDW1hdmVud2lyZS5jb20xMDAuBgkq hkiG9w0BCQEWIW13LWhvc3Rpbmctc3lzYWRtaW5AbWF2ZW53aXJlLmNvbTAeFw0x MDA0MDkyMDUwNDlaFw0xMTA0MDkyMDUwNDlaMIGzMQswCQYDVQQGEwJVUzEVMBMG A1UECBMMUGVubnN5bHZhbmlhMRgwFgYDVQQHEw9LaW5nIG9mIFBydXNzaWExFzAV BgNVBAoTDk1hdmVuV2lyZSwgTExDMRAwDgYDVQQLEwdTdXBwb3J0MRYwFAYDVQQD Ew1tYXZlbndpcmUuY29tMTAwLgYJKoZIhvcNAQkBFiFtdy1ob3N0aW5nLXN5c2Fk bWluQG1hdmVud2lyZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMGp U5HS8A2DRokU5TQz1Dyycx/VA2uhrRwatTPq8xtoQigWM2feiXUwtoiQ/gP3IjB5 AJLf8aC8y72Io2IME4aqh1s7bdscV2b0QMs1MfXiL9h2XQWZVCkgDLjjb1XzHhlw 3I6vkrh/uGH2PQyXbuG/6dIguzCHfnGgGXgy1o45AgMBAAGjezB5MAkGA1UdEwQC MAAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRl MB0GA1UdDgQWBBR0mZkOwZZjYFiWlloEvgSpoPxOuzAfBgNVHSMEGDAWgBS7Iqbt j25p56k4BdHpXYG3xjhdijANBgkqhkiG9w0BAQUFAAOBgQARO7OcDgNOZ3WuP9IM mUeQWuGVBAh7MQ3Uv2HrSOAfTHxg/QxjCZZlwULq1EZZDHNgyPMM+5ElWSID5El/ fdxHcizNOjPPuVPwtJIrs8RhTIehn0aKryqtkvpcAnxFuc+VxwcCBhV58wtbSuXL PXRTvoTDXWkiXwdR4m1bubOF5A== -----END CERTIFICATE----- 1 s:/C=US/ST=Pennsylvania/O=MavenWire, LLC/OU=Support/CN=testing.com/emailAddress=testing@testing.com<http://testing.com/emailAddress=testing@testing.com> i:/C=US/ST=Pennsylvania/O=MavenWire, LLC/OU=Support/CN=testing.com/emailAddress=testing@testing.com<http://testing.com/emailAddress=testing@testing.com> -----BEGIN CERTIFICATE----- MIIDJTCCAo6gAwIBAgIBADANBgkqhkiG9w0BAQUFADCBmTELMAkGA1UEBhMCVVMx FTATBgNVBAgTDFBlbm5zeWx2YW5pYTEXMBUGA1UEChMOTWF2ZW5XaXJlLCBMTEMx EDAOBgNVBAsTB1N1cHBvcnQxFjAUBgNVBAMTDW1hdmVud2lyZS5jb20xMDAuBgkq hkiG9w0BCQEWIW13LWhvc3Rpbmctc3lzYWRtaW5AbWF2ZW53aXJlLmNvbTAeFw0x MDA0MDkyMDUwMDBaFw0xMzA0MDgyMDUwMDBaMIGZMQswCQYDVQQGEwJVUzEVMBMG A1UECBMMUGVubnN5bHZhbmlhMRcwFQYDVQQKEw5NYXZlbldpcmUsIExMQzEQMA4G A1UECxMHU3VwcG9ydDEWMBQGA1UEAxMNbWF2ZW53aXJlLmNvbTEwMC4GCSqGSIb3 DQEJARYhbXctaG9zdGluZy1zeXNhZG1pbkBtYXZlbndpcmUuY29tMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQC6yVPz1ccamBapkRR8vTjpiKj7JuJKdCecTQ7/ f2KWoIRuYdEWU4njEsu/KHQWmxR0lelqOzM15EHVanOJCsPKCEMQg4lY5cQm8W1Q YCGQyqg0ITQ6nbPuQchFHHnldqYZsfiWjly8SC454B61ItHi9Lcxvfh4cVonSCqw KeoF4wIDAQABo3sweTAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NM IEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUuyKm7Y9uaeepOAXR6V2B t8Y4XYowHwYDVR0jBBgwFoAUuyKm7Y9uaeepOAXR6V2Bt8Y4XYowDQYJKoZIhvcN AQEFBQADgYEAg5xdwSmeF2afO1UJZys5Mmvn7YfUdOIRgVaYN5sQLt1ixCXjDEew 56br5RKs2W6PaqeXl7CN5bYqxDDo3ekds9uquzE91HaKH04gQUc+/NA82y5NiaGZ EOiLoTvc/+PShAjl8ZVwf+eNloay2FChb6S47rX0f28tKXpteWax00k= -----END CERTIFICATE----- --- Server certificate subject=/C=US/ST=Pennsylvania/L=King of Prussia/O=MavenWire, LLC/OU=Support/CN=testing.com/emailAddress=testing@testing.com<http://testing.com/emailAddress=testing@testing.com> issuer=/C=US/ST=Pennsylvania/O=MavenWire, LLC/OU=Support/CN=testing.com/emailAddress=testing@testing.com<http://testing.com/emailAddress=testing@testing.com> --- Acceptable client certificate CA names /C=US/ST=Pennsylvania/O=MavenWire, LLC/OU=Support/CN=testing.com/emailAddress=testing@testing.com<http://testing.com/emailAddress=testing@testing.com> /C=US/ST=Pennsylvania/L=King of Prussia/O=MavenWire, LLC/OU=Support/CN=testing.com/emailAddress=testing@testing.com<http://testing.com/emailAddress=testing@testing.com> --- SSL handshake has read 2160 bytes and written 2117 bytes --- New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 1024 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : AES256-SHA Session-ID: 7475F12DDB7A8CAE5047244136B5CDBD877D9C71E72B7DE379FEEC681ECA635C Session-ID-ctx: Master-Key: 5253A27AAB6096A906DD64C1565110582414DE0B24543D7275D267235BDF06F75EA1E745323E6E34420D90613AD74BF7 Key-Arg : None Krb5 Principal: None Start Time: 1271093212 Timeout : 300 (sec) Verify return code: 0 (ok) That all appears to be OK… which is confusing to me as to why it won’t work? From: Chris Jacobs [mailto:Chris.Jacobs@apollogrp.edu<mailto:Chris.Jacobs@apollogrp.edu>] Sent: Monday, April 12, 2010 12:30 PM To: 'lynn.york(a)mavenwire.com<mailto:lynn.york@mavenwire.com>' Subject: Re: Problem with SSL/TLS Did you setup the CA's cert as a trusted CA on your clients? There is also a setting to skip verifying the cert for /etc/openldap/ldap.conf - but I can't recall atm. - chris Chris Jacobs, Systems Administrator Apollo Group | Apollo Marketing | Aptimus 2001 6th Ave Ste 3200 | Seattle, WA 98121 phone: 206.441.9100 x1245 | mobile: 206.601.3256 | fax: 206.441.9661 email: chris.jacobs(a)apollogrp.edu<mailto:chris.jacobs@apollogrp.edu> ________________________________ From: openldap-technical-bounces+chris.jacobs=apollogrp.edu<http://apollogrp.edu>@OpenLDAP.org To: openldap-technical(a)openldap.org<mailto:openldap-technical@openldap.org> Sent: Mon Apr 12 08:13:39 2010 Subject: Problem with SSL/TLS I have created a cert. on the server and openldap starts without any issues, however when I attempt to connect via ldaps I keep getting the following error: ?? ?? ldapsearch -x -H ldaps://localhost:636 -D "cn=Manager,dc=testing,dc=com" -W -b "dc=testing,dc=com" "(objectClass=top)" Enter LDAP Password: ldap_bind: Can't contact LDAP server (-1) ?????????????? additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed ?? I can???t quite pin point what the problem might be.?? ?? Lynn York II MavenWire Hosting Admin www.mavenwire.com<http://www.mavenwire.com> (866) 343-4870 x717 ?? MavenWire - We DELIVER http://www.mavenwire.com ?? This e-mail and any attached files may contain confidential and/or privileged material for the sole use of the intended recipient.?? Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive this e-mail for the recipient), you may not review, copy or distribute this message.?? Please contact the sender by reply e-mail and delete all copies of this message. ?? MavenWire - We DELIVER http://www.mavenwire.com This e-mail and any attached files may contain confidential and/or privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive this e-mail for the recipient), you may not review, copy or distribute this message. Please contact the sender by reply e-mail and delete all copies of this message. ________________________________ This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system. MavenWire - We DELIVER http://www.mavenwire.com This e-mail and any attached files may contain confidential and/or privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive this e-mail for the recipient), you may not review, copy or distribute this message. Please contact the sender by reply e-mail and delete all copies of this message. ________________________________ This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical