openldap-technical September 2008

openldap-technical@openldap.org

54 participants
58 discussions

Syncrepl question
by Ivan Ordonez 04 Dec '08

04 Dec '08

Hi all, We have a small size domain with about 500 users and computers. We are using Samba with Openldap integration to authenticate user login and file sharing. Our setup is consist of 3 servers running Gentoo Linux - 1PDC and 2BDCs. As for replication, we are still using "slurpd". Any changes or modification is done through the PDC which replicates the changes to BDC1, then from BDC1, it then goes down to BDC2 - it's like a chain. We want to start using "syncrepl" soon as a way to replicate our database but I'm not sure were to start. We want to setup all of our machine to sync with each other everyday, and not worry which machine is use to make changes, modification, etc.... I'm not sure which syncrepl function to use to achieve what we want to do. Is "N-Way Multi Master replication" the correct choice to do this? We are using "BDB" database on each servers, and would like to achieve this with minimal downtime if possible. What is the best way to do this? Please advise. Any help is greatly appreciated. -Ivan

3 12

LDAP proxy for AD
by Lynn York 22 Oct '08

22 Oct '08

Hello, I have been attempting to use openldap as a proxy to AD with no success. I have attempted multiple different ways that I found online. I am able to get the proxy server to connect to AD, but I cannot get a client server to connect through the proxy to the AD server. Can anyone suggest anything? -Lynn

7 22

CSN too old
by Paul Lee 09 Oct '08

09 Oct '08

Dear all, I am using openldap version 2.4.9, I am using 4 ldap servers with 4-way master configured. Data can be synronized initially, but when the records is getting more and more, now is around 100k records, I always find data is not synronized between the four ldap servers. I find that "CSN is too old, ignoring" in the LDAP log file. Sep 24 04:04:03 disb01 slapd[28779]: do_syncrep2: cookie=rid=003,sid=001,csn=20080923200403.713637Z#000000#003#000000 Sep 24 04:04:03 disb01 slapd[28779]: do_syncrep2: rid=003 CSN too old, ignoring 20080923200403.713637Z#000000#003#000000 Sep 24 04:04:03 disb01 slapd[28779]: do_syncrep2: cookie=rid=002,sid=001,csn=20080923200403.713637Z#000000#003#000000 Sep 24 04:04:03 disb01 slapd[28779]: do_syncrep2: rid=002 CSN too old, ignoring 20080923200403.713637Z#000000#003#000000 Sep 24 04:04:03 disb01 slapd[28779]: do_syncrep2: cookie=rid=002,sid=001,csn=20080923200403.739461Z#000000#002#000000 Sep 24 04:04:03 disb01 slapd[28779]: syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) Sep 24 04:04:03 disb01 slapd[28779]: syncrepl_entry: rid=002 be_search (0) Sep 24 04:04:03 disb01 slapd[28779]: syncrepl_entry: rid=002 cn=pwdfail,ou=SCIG,ou=Govt-Dept,o=HKSARG Any idea of this kind of error and how to fixed it ? Thanks Confidential Communication - This e-mail (including any attachments) is confidential and may be legally privileged. If this e-mail has been sent to you by mistake please inform us by reply e-mail and then delete the e-mail, destroy any printed copy and do not disclose or use the information in it.

4 13

AW: openldap and TLS certificates
by Hauke Coltzau 02 Oct '08

02 Oct '08

Hi Nick, it took me some time to set up TLS successfully, so I'm with you in this journey ;-) >From my own experience, I would suggest to start verfifying the server first. Let the client simply have the TLS_CACERT /<path>/<to>/<cachain>/cacert.chain.pem TLS_REQCERT demand options set and not send any certificate at all. On the server's side, only set TLSCertificateFile /your/cert.pem TLSCertificateKeyFile /your/private/key.pem You will not need a CACert file on the server for now. Make sure that the client will not send any certificate, so check your current users .ldaprc, because the client certificate depends on the user that runs the ldapsearch command. If you can set up TLS this way, you can be sure that the server is valid. To validate your client, you will need a .ldaprc in the current user's home directory which points to the user's cert and key. The server must be able to verify the user's cert. Hope, this helps, Hauke ----- Ursprüngliche Mail ----- Von: "Nick Kasparidis" <nick.kasparidis(a)toumaz.com> An: openldap-technical(a)openldap.org Gesendet: Montag, 29. September 2008 17:11:10 GMT +01:00 Amsterdam/Berlin/Bern/Rom/Stockholm/Wien Betreff: openldap and TLS certificates Hello everyone, I seem to have a problem with setting up secure connections with my LDAP server. I believe the problem has mainly to do with my certificates rather than anything else. I used the tutorial provided by the openLDAP admin guide to generate my certificates http://damncoolpics.blogspot.com/2008/09/oktoberfest-2008-in-munich.html My slapd.conf files has the following entries #SSL/TLS Options TLSCipherSuite HIGH:MEDIUM TLSCACertificateFile /usr/local/etc/slapd-cacert.pem TLSCertificateFile /usr/local/etc/slapd-cert.pem TLSCertificateKeyFile /usr/local/etc/slapd-key.pem and my ldap.conf TLS_CACERTDIR /etc/openldap/cacerts TLS_CACERT /etc/openldap/cacerts/slapd-cert.pem slapd-cacert.pem is the certificate of the CA slapd-cert.pem is the server certificate (same copy on client and server) slapd-key.pem is the server key (I manually removed the certificate request that was generated by the process on the link above) I start the server using /usr/local/libexec/slapd -h ldap:/// ( also tried the -d 9 flag for debugging), and when I use ldapsearch I get the following errors (from the client) ldapsearch -x -ZZ (I have most of the settings in my ldap.conf) ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (from the server with the -d 9 flag) I get load of stuff, but the important seems to be the following TLS trace: SSL3 alert read:fatal:unknown CA TLS trace: SSL_accept:failed in SSLv3 read client certificate A TLS: can't accept. TLS: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca s3_pkt.c:1053 connection_read(12): TLS accept failure error=-1 id=0, closing When I try a search without the -ZZ flag everything works fine. When I created the certificates I tried different common names. I tried the ip address, fully qualified name (as shown below), the short name, even my name, but no luck. I have read the proper RFC but could not get anyusefull information. By the way I have a local DNS server and the domain name should match the correct IP address (and the reverse). Truth is I do not know much about SSL and certificates, so I might be missing something. Just for your information, The certificate authority is the same with the LDAP server. I will provide the certificate below, with email and addresses altered. Also the hashes have been altered so key and cert will not match. I merely provide them just in case you see something wrong in the syntax. The server certificate Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha1WithRSAEncryption Issuer: C=GB, ST=Oxfordshire, O=Company, OU=IT, CN=ldapserver.eng.mydomain.com/emailAddress=admin@mydomain.com Validity Not Before: Sep 29 09:49:07 2008 GMT Not After : Sep 29 09:49:07 2009 GMT Subject: C=GB, ST=Oxfordshire, L=Abingdon, O=Company,, OU=IT, CN=ldapserver.eng.mydomain.com/emailAddress=admin@mydomain.com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:c4:4d:49:ce:35:a6:80:67:d5:c5:ea:2e:5a:b0: 0f:96:a2:de:28:c3:97:fc:5d:9d:05:57:ae:a8:db: d4:cd:8c:bb:1d:4d:2c:41:51:45:0e:c9:17:8f:a0: 5b:bb:a0:5e:d3:d7:5d:a4:64:dd:23:9a:64:ad:dc: 7b:49:5a:92:68:65:32:6c:0c:50:84:8a:75:26:da: 76:7f:65:13:14:0a:05:eb:5e:d3:f7:1e:89:7f:a2: d8:1b:4a:46:28:ee:98:5f:f9:bd:21:88:df:76:5c: b9:8e:7e:5b:09:29:65:e7:6b:a7:5b:5f:4a:99:77: 7d:6c:d1:44:7e:7a:77:05:fe:1c:b9:6d:2b:e2:57: 63:63:29:b3:cb:c6:68:35:b5:81:fa:ef:ee:ba:c0: 54:3e:d8:70:0a:f6:c9:39:74:21:f8:75:b9:08:89: 6a:5e:e3:fe:1e:5e:37:b0:29:2d:13:35:b4:7c:aa: 55:3e:c3:c4:59:cd:08:e1:ef:21:43:29:0f:82:8f: 84:7d:f2:65:b5:79:2e:fc:87:7c:7d:ca:fb:7a:ef: 54:c4:33:20:ed:f5:8a:64:de:60:18:60:07:ee:f9: ea:0f:97:bf:af:63:e1:e4:e8:b2:15:1b:5f:95:fd: ad:c7:83:8c:94:f3:e4:ef:95:63:f0:d4:a8:f8:49: 13:05 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 1F:9F:4E:5A:C8:61:53:4B:5F:50:28:84:F8:D7:45:54:C0:C9:7E:67 X509v3 Authority Key Identifier: keyid:7C:5A:92:7E:5C:6B:3E:9B:0E:87:46:7C:FB:27:8F:34:AD:42:3B:27 Signature Algorithm: sha1WithRSAEncryption 04:3d:f9:64:e9:c1:13:8c:98:e6:b6:33:a9:e0:8b:8e:b0:68: 2f:70:8e:8e:b4:b2:6f:61:7c:bd:63:f2:cb:20:b8:6e:4f:0a: 53:5f:ba:ed:32:20:c7:31:24:0c:c3:e8:d6:42:1c:a8:3e:7b: 32:b4:87:94:71:d6:8b:ca:c9:57:f5:9f:fc:8d:89:77:e2:3e: ac:49:cd:c8:c7:01:83:41:41:a6:05:7c:df:c6:37:0e:15:d8: d2:51:3f:a5:92:b7:bf:3f:65:4e:68:71:b7:4e:3e:26:f6:15: fe:38:72:e1:f9:b7:60:29:e8:ff:78:3c:aa:34:be:e8:46:f1: 5f:87:8b:a1:60:8b:82:31:ca:5e:a1:31:83:e7:b7:90:be:a5: 2f:ac:f7:1c:fe:af:89:15:02:af:c7:4f:2f:97:87:2b:0b:83: 5c:07:83:f9:f9:c7:63:00:69:fa:c9:d0:fc:fb:7a:ef:7a:41: 1c:e0:99:e4:01:73:7f:94:fa:2c:12:0f:8e:3f:8f:b4:9b:b6: 85:42:90:1a:aa:d6:11:9b:49:db:83:f9:19:1e:dd:8b:0a:c7: b5:c0:5c:06:78:ca:f1:75:f9:8b:eb:c0:94:b0:3f:96:fc:b8: 88:7c:52:46:ad:ab:bb:22:52:c1:31:dc:87:a7:c9:bd:de:98: bd:76:45:2b -----BEGIN CERTIFICATE----- MIIESTCCAzGgAwIBAgIBATANBgkqhkiG9w0BAQUFADCBnzELMAkGA1UEBhMCR0Ix FDASBgNVBAgTC094Zm9yZHNoaXJlMSIwIAYdVQQKExlUb3VtYXogVGVjaG5vbG9n eSBMaW8pdGVkMQswCQYDVQQLEwJJVDEeMBwGA1UEAxMVbWFnZ2llLmVuZy50b3Vt YXouY29tMSkwJwYJKoZIhvcNAQkBFhpuaWNrLmthc3BhcmlkaXNAdG91bWF6LmNv bTAeFw0wODA5MjkwOTQ5MDdaFw0wOTA5MjkwOTQ5MDdaMIGyMQswCQYDVQQGEwJH QjEUMBIGA1UECBMLT3hmb3Jkc2hpcmUxETAPBgNVBAcTCEFiaW5nZG9uMSIwIAYD VQQKExlUb3VtYXogVGVjaG5vbG9neSBMaW1pdGVkMQswCQYDVQQLEwJJVDEeMBwG A1UEAxMVbWFnZ2llLmVuZy50b3VtYXouY29tMSkwJwYJKoZIhvcNAQkBFhpuaWNr Lmthc3BhcmlkaXNAdG91bWF6LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAMRNSc41poBn1cXqLlqwD5ai3ijDl&xdnQVXrqjb1M2cux1NLEFRRQ7J F4+gW7ugXtPXXaRk3SOaZK3ce0lakmhlMmwMUISKdSbadn9lExQKBete0/ceiX+i 2BtKRijumF/5vSGI33ZcuY5+WwkpZedrp1tfSpl3fWzRRH56dwX+3LltK+JXY2Mp s8vGaDW1gfrv7rrAVD7YcAr2yTl0Ifh1uQiJal7j/h5eN7ApLRM1tHyqVT7DxFnN COHvIUMpD4KPhH3yZbV5LvgHfH3K+3rvVMQzIO31imTeYBdgB+756g+Xv69j4eTo shUbX5X9rceCjJTz5O+VY/DUqPhJEwUCAwEAAaN7MHkwCQYDVR0TBAIwADAsBglg hkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFB+fXlrIYVNLX1AphPjXRVTAyX9nMB8GA1UdIwQYMBaAFHxakn5cWz6bDodG fPsnjzSuQjsnMA0GCSqGSIb3DQEBBQUAA4IBAQAEPflk6cETjJjmtjOp4IuOsGgv cI6OtLNvYXy9Y/LLILhuTwpTX7rtMiDGMCQMw+jWQhyoPnsytIeUcdaLyslX9Z/8 jYl34j6sSc3IxwGDQUGmBXzPxjcOFdjSUT+lkre/P2VOaHG3Tj4m9hX+OHLh+bdg Kej/eDyqNL7oRvFfh4uhYIuCMcpeoTGD57eQvQUvrPcc/q+JFQKvx08vl4crC4NM B4P5+cdjAGn6ydD8+3rvekEc4JnkAXN/lPosEg+OP4+0m7aFQpAaqtYRmknbg/kZ Ht2LCse1wFwGeMrxdfmL68CUsD+W/LiIfFJGrau7IlLBMdyHp8m93pi9dkUr -----END CERTIFICATE----- The CA certificate Certificate: Data: Version: 3 (0x2) Serial Number: 0 (0x0) Signature Algorithm: sha1WithRSAEncryption Issuer: C=GB, ST=Oxfordshire, O=Company, OU=IT, CN=ldapserver.eng.mydomain.com/emailAddress=admin@mydomain.com Validity Not Before: Sep 29 09:48:17 2008 GMT Not After : Sep 29 09:48:17 2011 GMT Subject: C=GB, ST=Oxfordshire, O=Company, OU=IT, CN=ldapserver.eng.mydomain.com/emailAddress=admin@mydomain.com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:a6:6e:3b:1f:87:e9:1a:c9:e9:5c:3a:b8:96:19: af:c9:e7:41:87:72:76:55:a8:fc:db:3c:05:55:9c: 25:8f:83:5b:35:05:9f:cb:7b:4e:9b:3a:84:98:60: 46:d5:79:be:c1:4c:b5:ea:cd:79:2b:c2:33:86:05: 67:98:e4:62:77:d7:cf:98:c3:52:93:6c:ba:1c:fc: a3:f9:81:26:ea:d8:a1:56:cd:74:f5:47:fe:0f:8d: 95:7a:b7:8b:14:25:e7:9d:e2:e7:46:a2:d6:90:4c: 25:94:16:20:51:78:6a:68:da:e0:06:2c:45:4e:27: c4:2b:8b:bc:a9:e2:fb:c5:c1:8b:9d:33:5f:e3:be: d1:f5:53:9d:2b:0c:bf:2a:95:e6:57:29:5e:ef:ab: 3a:e9:33:09:00:c3:7d:94:aa:a9:b4:3c:08:9d:e8: e6:92:f2:60:03:ed:12:1d:df:81:9f:a7:d2:81:7f: 3e:8b:fa:a4:01:ba:c1:49:1c:51:02:c6:54:3c:48: 9a:3f:18:54:04:35:c4:e1:c7:12:f6:7a:26:7e:47: 04:e6:f8:fc:ed:8c:2e:17:05:62:b6:73:9a:4e:52: 10:17:92:52:38:3a:4d:2d:32:ab:76:c8:61:ab:36: cd:52:f9:95:bb:87:63:ad:5d:d3:d0:f9:6f:06:a6: 29:6f Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 7C:5A:92:7E:5C:5B:3E:9B:0E:87:46:7C:FB:27:8F:34:AE:42:3B:27 X509v3 Authority Key Identifier: keyid:7C:5A:92:7E:5C:5B:3E:9B:0E:87:46:7C:FB:27:8F:34:AE:42:3B:27 Signature Algorithm: sha1WithRSAEncryption 2b:b9:65:09:2d:ff:c0:80:dd:e0:f4:d0:01:9a:87:b9:da:54: d2:f1:e4:0a:56:0b:cf:31:55:97:9f:93:62:df:59:3d:11:5b: 06:6c:e7:f9:56:9b:c8:e8:e0:77:54:12:5b:ca:98:f9:c7:fa: c6:41:45:6d:14:31:2d:d6:19:a8:41:ba:89:55:5a:7f:5c:79: 1b:05:36:d7:e4:00:7b:e7:ae:5e:56:74:12:f9:fa:ab:63:0f: f6:8e:97:cc:53:d3:91:7e:4b:48:6e:15:27:bc:73:4a:68:1f: ff:36:67:b2:fa:6b:38:40:0c:f2:99:5f:75:2a:4f:27:21:a8: fb:b5:9a:c3:7a:05:a5:45:03:3f:cf:85:21:eb:42:69:23:af: d5:b8:32:17:4e:a5:52:c2:3e:01:bd:1f:f2:1a:b6:f0:f8:8f: d9:d0:70:30:08:39:37:42:84:42:67:27:74:16:be:e7:2d:0f: 54:e8:3d:8b:6f:6c:76:a6:39:d9:df:e4:b9:33:9a:92:5b:3e: b2:6a:8a:8f:2e:9c:3a:01:54:c7:3e:0e:f4:45:9c:bd:f6:39: e9:8c:9d:95:60:e7:2a:10:f6:ac:4a:a2:b7:16:bf:06:44:76: 4b:5d:51:5a:0b:82:b0:53:f6:4a:d7:04:f0:85:7e:34:c6:fc: 50:1a:c4:b3 -----BEGIN CERTIFICATE----- MIIENjCCAx6gAwIBAgIBADANBgkqhkiG9w0BAQUFADCBnzELMAkGA1UEBhMCR0Ix FDASBgNVBAgTC094Zm9yZHNoaXJlMSIwIAYDVQQKExlUb3VtYXogVGVjaG5vbG9n eSBMaW1pdGVkMQswCQYDV1QLEwJJVDEeMBwGA1UEAxMVbWFnZ2llLmVuZy50b3Vt YXouY29tMSkwJwYJKoZIhvcNAQkBFhpuaWNrLmthc3BhcmlkaXNAdG91bWF6LmNv bTAeFw0wODA5MjkwOTQ4MTdaFw0xMTA5MjkwOTQ4MTdaMIGfMQswCQYDVQQGEwJH QjEUMBIGA1UECBMLT3hmb3Jkc2hpcmUxIjAgBgNVBAoTGVRvdW1heiBUZWNobm9s b2d5IExpbWl0ZWQxCzAJBgNVBAsTAklUMR4wHAYDVQQDExVtYWdnaWUuZW5nLnRv dW1hei5jb20xKTAnBgkqhki39w0BCQEWGm5pY2sua2Fz5GFyaWRpc0B0b3VtYXou Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApm47H4fpGsnpXDq4 lhmvyedAh3J2Vaj82zwFVZwlj4NbNQWfy3tOmzqEmGBG1Xm+wUy16s15K8IzhgVn mORid9fPmMNSk2y6HPyj+YEm6tihVs109Uf+D42VereLFCHnneLnRqLWkEwllBYg UXhqaNrgBixFTifEK4u8qeL7xUGLnTNf477R9VOdKwy/KpXmVyle76s66TMJAMN9 lKqptDwInejmkvJgA+0SHd+Bn6fSgX8+i/qkAbrBSRxRAsZUPEia3xhUBDXE4ccS 9nomfkcE5vj87YwuFwVitnOZTlIQF5JSODpNLTKrdsHhqzbNUvmVu4djrV3T0Plv BqYpbwIDAQABo3sweTAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NM IEdlbmVyYXRlZC5DZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUfFqSflxbPpsOh0Z8+yeP NK5COycwHwYDVR0jBBgwFoAUfFqSflxbPpsOh0Z8+yePNK5COycwDQYJKoZIhvcN AQEFBQADggEBACu5ZQkt/8CA3eD00AGah7naVNLx5ApWC88xVZefk2LfWT0RWwZs H/lWm8jo4HdUElvKmPnH+sZBRW0UMS3WGahBuolVWn9ceRsFNtfkAHvnrl5WdBL5 +qtjD4aOl8xT05F+S0huFSe8c0poH/82Z7L6azhADPKZ73UqTychTPu1msN6BaVF Az/PhSHrQmkj39W4MhdOpFLCPgG9H/IatvD4j9nQcDAIOTdChEJnJ3QWvuctD1To PYtvbHamOdnf5LkzmpJbPrJiio8unDoBVMc+DvRFnL32OemMnzVg5yoQ9qxKorcW vwZEdktdUVoLgrBT9krXBPCFfjTG/FAaxLM= -----END CERTIFICATE----- and finally the server key, which I modified slightly be removing a certificate request entry -----BEGIN RSA PRIVATE KEY----- MIIEowIBAAKCAQEAxE1JzjWmgGfVxeouWrAPlqLeKMOX/F2dBVeuqNvUzZy7HU0s QVFFDskXj6B9u6Be09ddpGTdI5pkrdx7SVqSaGUybAxQhIp1Jtp2f2UTFAoF617T 9x6Jf6LYG0pGKO6YX/m9IYjfdly5jn5bCSll52unW19KmXd9bNFEfnp3Bf7cuW0r 4ldjYymzy8ZoNbWB+u/uusBUPthwCvbJOXQh+HW5CIlqXuP+Hl43bCktEzW0fKpV PsPEWc0I4e8hQykPgo+EffJltXku/Id8fcr7eu9UxDMg7fWKZN5gF2AH7vnqD5e/ r2Ph5OiyFRtflf2tx4KMlPPk75Vj8NSo+EkTBQIDAQABAoIBAFkajAniKHXYrBxu NCRODoVd4GG4huCyzXeDWXCkeG/sWLLwOMpdTW9ssBktvPXp0aFu/L6GWiqzBkg0 8HFXf2WLqduJq3K+NncwauFgy8wo0I8KOETPw7IABQA+MqKZyuilv8fdDTH43PFl QYVjGTJ2lzzOgFow9unSA7k1dZluTeMyE+RzpVYwE/WSgsOFa7qYQnCXy0hlx85u /SNU5383/v1cvrSghDCbZ2WrllHAerjUep1FNDounGkhiWj+JWUfddL7zYM+KVdJ AKRaxeYo+UTAVa9rd9D8qgZo5oIJ6l53bvobkwcrVnAoYPxtzAjhcBhgtQjXSXrJ YrHhKQECgYEAavUIAaT/XfHDXuXYMHnSf/ZgAqipOv36OPPnXnpg0yZbyLs/dgN6 GYVBtvd3ugfQ3ZEUfOwYw2wVq6hItq6+lQRjL+G5IsoeyKJXGIpBdlr7Yhhes1gv 4R5nGB97+F9kBVEmDephg0K++EeKRZMpzUgn1cBvBXrcfJsUc8OAFbUCgYEAy31q k8HXBltJz7QQxmXLZogFkb0dxxXUrax202e6XsqroUpmUWx1n75TVnnP4QNH0Tqx 8EQTDMZzQRHgFidwLAzhpI16Ex1fLfSw/lMQij7ojxtGp8LbC057dGpseBxwTPjP I5dpdIl2Mt8HeH5qMiizRls1EcSu1RK9cPhOWhECgjEAtU+pFSwCoQKDIgU1+EE4 nuJQEyOpO7qEH5RS5jaLJ/sdn/551TcwSdRgLuj5agea/VEq7ZyZgcC1GFZxLE6X dejGubzLpBMpDrzBnS7EaRTbQ2YJATtfy7n6juduqSe/03eErOrLtQcoFjjP98zX //Nd671gxXEyt/lTxrpeK5ECgYBFbIFq7awFkCmLgjxi46HUVj3ILgQ1wt3vbrKP h4kPBAgwG+jyiJVMratTCnYAp5Td7i988EyrhB0YKxgPlt7vOGnXMSlf0hqB3ERy UDaJY9MF1+FwJMuEfP8jhZeCFvm9WPmag/LHfoVj6rFqy35BpJ8dNsrRSA/5w837 98sLcQKBgBBfNJdPOGjgLZxLM5hXI88UkYFc3ppVh83SHSikKULO5d7wrWeQDR9V u3t+sx8bl067E2dILPzTa9qLt3RO+GPCwOQMQUywNBh7jQ1BjaOg/4ctlJkjAdKo x4hAG2dU5Z7iEob5AWpfv3+A5taS8P9RjI1O2jUwnTR84vqJtNx7 -----END RSA PRIVATE KEY----- Any ideas would be welcome Best Regards Nick -- ------------------------------------ Fernuniversität in Hagen Lehrgebiet Kommunikationsnetze http://www.fernuni-hagen.de/kn Fon/Fax: +49 2331 987 -1142 / -353 ------------------------------------

2 1

Shared Addressbook using LDAP
by Tarak Ranjan 01 Oct '08

01 Oct '08

Hi List, I am configuring a shared addressbook for squirrelmail. but the problem is it's showing the only single email address of the user, using that email id i'm login into the webmail. here is my slapd.conf. include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema allow bind_v2 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args loglevel 256 access to * by self write by anonymous auth by users read access to dn.children="ou=addressbook,dc=mail,dc=example,dc=com" by self write by anonymous read by users read database bdb suffix "dc=mail,dc=example,dc=com" rootdn "cn=Manager,dc=mail,dc=example,dc=com" rootpw {SSHA}WtGEFDMu4JYHmuGNngBNib80Nwka9o20 directory /var/lib/ldap index objectClass eq,pres dbconfig set_cachesize 0 10485760 0 dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 , /\ Tarak Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/

2 1

OpenLDAP 2.4 replication to a write-only LDAP server
by Brouwer, Onno - Acision 30 Sep '08

30 Sep '08

Hi List, I am trying to set up replication from an OpenLDAP 2.4 master to a write-only LDAP slave. This slave is not really an LDAP slave, but has an LDAP interface to have changes replicated to it. In earlier OpenLDAP releases I could use slurpd for this, but since this has been deprecated I am trying to get it working using syncrepl. Based on what I found in the online manual I am trying to achieve this with an additional OpenLDAP 2.4 proxy which replicates changes it learns from the master through syncrepl to the slave through the LDAP backend. Is there some way I can get this to work? If the slave is a real LDAP server, then the proxy works, but it stores the contextCSN on the slave, and not on the proxy. If I have some form of storing this contextCSN elsewhere then I might try to start the proxy (in case it dies) with this contextCSN value specified on the command line. Also, when I try to ban searches on the slave (since it is a write-only slave), the proxy thinks none of the master entries exist on the slave and then happily tries to add them to the slave, resulting in duplicate errors. Any help would be greatly appreciated! Regards, Onno This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

2 2

bindpw and SSHA
by Nick Kasparidis 29 Sep '08

29 Sep '08

Hello everyone, I have a small problem setting up my ldap client. The issue comes from trying to force authenticated queries. So I have set the following lines in my slapd.conf disallow bind_anon require authc on the client side I have added the following lines to my ldap.conf binddn cn=manager,dc=domain,dc=com bindpw {SSHA}<the hash> Using this approach I cannot get a connection to the ldap server. I checked through wireshark, and I get a packet bindResponse(1) invalidCredentials () If on the other hand I when use the cleartext password, instead of SSHA then everything works fine. I am not sure if it is important but the 'bindRequest(1) simple' packet contains the text {SSHA}<hash> exactly as it appears in the ldap.conf file. Should it be processed on the client end? I have created the SSHA hash using slappasswd on the server machine, and then I copied and pasted the text across to my ldap.conf file. The hashes used by the server and client are identical. Have I done something wrong, should I encrypt the password using another way? Also if there is another way to initiate an authenticated query without using plaintext passwords, please let me know. By the way my server is openldap 2.4.10 on solaris 10 (sparc) and the client I experiment with openldap 2.2.13-12 on RHEL4.7 (i386) Thank you Nick

2 3

Error with OpenLDAP
by Arun NAIR 28 Sep '08

28 Sep '08

Hey Guys, My configuration I'm not sure doesn't seems to be working too well, it was working this morning now its not. If you could analyze it for me and tell me how I can achieve 100% success with this would be great. Thanks in advance for all the time extended Regards, Arun Nair The current error that I'm getting is * [root@centserver ~]# service ldap start Checking configuration files for slapd: WARNING: No dynamic config support for database sql. backend_startup_one: bi_db_open failed! (1) slap_startup failed (test would succeed using the -u switch) [FAILED] * *My slapd.conf file is as under: * # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema loglevel -1 # Define global ACLs to disable default read access. defaultaccess read access to * by * read access to * by self write # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args modulepath /usr/lib/openldap moduleload back_sql.la ####################################################################### # sql database definitions ####################################################################### database sql suffix dc=abc,dc=corp rootdn cn=Manager,dc=abc,dc=corp rootpw {CRYPT}2aFSZAS2uxw.. dbname ldap dbuser ldap dbpasswd password subtree_cond "ldap_entries.dn LIKE CONCAT('%',?)" insentry_query "INSERT INTO ldap_entries (dn,oc_map_id,parent,keyval) VALUES (?,?,?,?)" has_ldapinfo_dn_ru no TLSCertificateFile /etc/openldap/ldap.cert TLSCertificateKeyFile /etc/openldap/ldap.key *My odbc.ini configuration is as under: * *[ODBC Data Sources] *myodbc5 = MyODBC 5.1.5 Driver DSN *[myodbc5] *Driver = /usr/lib/libmyodbc5.so Description = LDAP Connector SERVER = localhost PORT = USER = ldap Password = password Database = ldap SOCKET = /var/lib/mysql/mysql.sock

1 0

index_param failed
by Denis BUCHER 27 Sep '08

27 Sep '08

Hello ! I have cyrus (IMAP mailserver) working perfectly based on openldap, BUT I have some strange messages in the logs that I would like to understand/correct : * bdb_equality_candidates: (accountStatus) index_param failed (18) * bdb_equality_candidates: (virtualdomain) index_param failed (18) * bdb_equality_candidates: (description) index_param failed (18) This is exactly ONE session where one of our users (description=dbucher(a)ourcompany.ch) is sending a mail to the outside world (dbucher(a)destdomain.ch). If someone would be nice enough to explain me exactly what it means, and how to solve this problem, it would be very nice... I already searched a lot to find help on this topic, without success, I found some possible solutions but I don't know exactly how to test them : 1. define the approriate indexes in slapd.conf, reindex and restart 2. Check the actual index files to make sure they're correct permissions, etc, and then try a db_recover. In slapd.conf I have : index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub I tryed to add : index accountStatus,description eq but : # slapindex bdb_db_open: database already in use backend_startup_one: bi_db_open failed! (-1) slap_startup failed Thanks a lot in advance for your help Denis Sep 11 20:19:29 mailhost slapd[2099]: conn=21436 op=1273 BIND anonymous mech=implicit ssf=0 Sep 11 20:19:29 mailhost slapd[2099]: conn=21436 op=1273 BIND dn="cn=mailadmin,ou=mailservices,dc=ourcompany,dc=ch" method=128 Sep 11 20:19:29 mailhost slapd[2099]: conn=21436 op=1273 BIND dn="cn=mailadmin,ou=mailservices,dc=ourcompany,dc=ch" mech=SIMPLE ssf=0 Sep 11 20:19:29 mailhost slapd[2099]: conn=21436 op=1273 RESULT tag=97 err=0 text= Sep 11 20:19:29 mailhost slapd[2099]: conn=21436 op=1274 SRCH base="ou=mailservices,dc=ourcompany,dc=ch" scope=2 deref=0 filter="(|(&(objectClass=CourierMailAccount)(mail=dbucher@ourcompany.ch)(accountStatus=active))(&(cn=mailadmin)(description=dbucher@ourcompany.ch)))" Sep 11 20:19:29 mailhost slapd[2099]: conn=21436 op=1274 SRCH attr=dn Sep 11 20:19:29 mailhost slapd[2099]: <= bdb_equality_candidates: (accountStatus) index_param failed (18) Sep 11 20:19:29 mailhost slapd[2099]: <= bdb_equality_candidates: (description) index_param failed (18) Sep 11 20:19:29 mailhost slapd[2099]: conn=21436 op=1274 SEARCH RESULT tag=101 err=0 nentries=1 text= Sep 11 20:19:29 mailhost slapd[2099]: conn=21436 op=1275 BIND anonymous mech=implicit ssf=0 Sep 11 20:19:29 mailhost slapd[2099]: conn=21436 op=1275 BIND dn="cn=dbucher,ou=users,ou=ourcompany.ch,ou=mailservices,dc=ourcompany,dc=ch" method=128 Sep 11 20:19:29 mailhost slapd[2099]: conn=21436 op=1275 BIND dn="cn=dbucher,ou=users,ou=ourcompany.ch,ou=mailservices,dc=ourcompany,dc=ch" mech=SIMPLE ssf=0 Sep 11 20:19:29 mailhost slapd[2099]: conn=21436 op=1275 RESULT tag=97 err=0 text= Sep 11 20:19:29 mailhost slapd[2099]: conn=24035 op=4 SRCH base="ou=mailservices,dc=ourcompany,dc=ch" scope=2 deref=0 filter="(&(objectClass=CourierMailAlias)(mail=dbucher(a)destdomain.ch)(accountStatus=active))" Sep 11 20:19:29 mailhost slapd[2099]: conn=24035 op=4 SRCH attr=maildrop Sep 11 20:19:29 mailhost slapd[2099]: conn=24035 op=4 SEARCH RESULT tag=101 err=0 nentries=0 text= Sep 11 20:19:29 mailhost slapd[2099]: conn=24035 op=5 SRCH base="ou=mailservices,dc=ourcompany,dc=ch" scope=2 deref=0 filter="(&(objectClass=CourierMailAlias)(mail=(a)destdomain.ch)(accountStatus=active))" Sep 11 20:19:29 mailhost slapd[2099]: conn=24035 op=5 SRCH attr=maildrop Sep 11 20:19:29 mailhost slapd[2099]: conn=24035 op=5 SEARCH RESULT tag=101 err=0 nentries=0 text= Sep 11 20:19:29 mailhost slapd[2099]: conn=24036 op=4 SRCH base="ou=mailservices,dc=ourcompany,dc=ch" scope=2 deref=0 filter="(&(objectClass=CourierMailAlias)(mail=dbucher(a)destdomain.ch)(accountStatus=active))" Sep 11 20:19:29 mailhost slapd[2099]: conn=24036 op=4 SRCH attr=maildrop Sep 11 20:19:29 mailhost slapd[2099]: conn=24036 op=4 SEARCH RESULT tag=101 err=0 nentries=0 text= Sep 11 20:19:29 mailhost slapd[2099]: conn=24036 op=5 SRCH base="ou=mailservices,dc=ourcompany,dc=ch" scope=2 deref=0 filter="(&(objectClass=CourierMailAlias)(mail=(a)destdomain.ch)(accountStatus=active))" Sep 11 20:19:29 mailhost slapd[2099]: conn=24036 op=5 SRCH attr=maildrop Sep 11 20:19:29 mailhost slapd[2099]: conn=24036 op=5 SEARCH RESULT tag=101 err=0 nentries=0 text= Sep 11 20:19:29 mailhost slapd[2099]: conn=24038 fd=20 ACCEPT from IP=127.0.0.1:41775 (IP=0.0.0.0:389) Sep 11 20:19:29 mailhost slapd[2099]: conn=24038 op=0 BIND dn="cn=mailadmin,ou=mailservices,dc=ourcompany,dc=ch" method=128 Sep 11 20:19:29 mailhost slapd[2099]: conn=24038 op=0 BIND dn="cn=mailadmin,ou=mailservices,dc=ourcompany,dc=ch" mech=SIMPLE ssf=0 Sep 11 20:19:29 mailhost slapd[2099]: conn=24038 op=0 RESULT tag=97 err=0 text= Sep 11 20:19:29 mailhost slapd[2099]: conn=24038 op=1 SRCH base="ou=mailservices,dc=ourcompany,dc=ch" scope=2 deref=0 filter="(&(objectClass=CourierMailAlias)(mail=destdomain.ch)(accountStatus=active))" Sep 11 20:19:29 mailhost slapd[2099]: conn=24038 op=1 SRCH attr=maildrop Sep 11 20:19:29 mailhost slapd[2099]: conn=24038 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= Sep 11 20:19:29 mailhost slapd[2099]: conn=24038 op=2 SRCH base="ou=mailservices,dc=ourcompany,dc=ch" scope=2 deref=0 filter="(&(objectClass=CourierDomainAlias)(virtualdomain=destdomain.ch))" Sep 11 20:19:29 mailhost slapd[2099]: conn=24038 op=2 SRCH attr=virtualdomain Sep 11 20:19:29 mailhost slapd[2099]: <= bdb_equality_candidates: (virtualdomain) index_param failed (18) Sep 11 20:19:29 mailhost slapd[2099]: conn=24038 op=2 SEARCH RESULT tag=101 err=0 nentries=0 text= Sep 11 20:19:35 mailhost slapd[2099]: conn=24038 fd=20 closed (connection lost)

2 4

DB_KEYEXIST: Key/data pair already exists
by Stelios A. 26 Sep '08

26 Sep '08

Hello all, I have 2 users with identical Full Name and their ldif change on mail, uid, username and home directory in order to avoid ldap constraints. However, even though I have no other constraints apart from unique_attributes uid mail uidNumber homeDirectory I'm getting the following error and cannot add the 2nd user. root@masterldap:~# slapadd -l debug.ldif -f /etc/ldap/slapd.conf => hdb_tool_entry_put: id2entry_add failed: DB_KEYEXIST: Key/data pair already exists (-30996) => hdb_tool_entry_put: txn_aborted! DB_KEYEXIST: Key/data pair already exists (-30996) slapadd: could not add entry dn="cn=Full Name,ou=Users,dc=mydomain,dc=com" (line=1): txn_aborted! DB_KEYEXIST: Key/data pair already exists (-30996) root@masterldap:~# Any ideas how I can see which attribute is causing the problem? -- Stelios A

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical September 2008