openldap-technical

openldap-technical@openldap.org

10 participants
9969 discussions

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

SSL / Certificates / ... Some confusion
by Götz Reinicke - IT-Koordinator 12 Apr '10

12 Apr '10

Hi, since a couple of days I try to setup a provider and a consumer over ssl following the documentation in a book [1] an dusing two servers. (Red Hat 5.x, openssl-0.9.8e-12, openldap-2.3.43-3 ) Doing so I was confronted with a lot off different warnings/messages but finaly I got the replication crypted. The final step in the tutorial is to use the saslmech=external but the messages I do get are different from the messages I should get. I noticed and googeled some provider debug info and wanted to ask for some prove or clarification or work around: >From the provider log: TLS certificate verification: Error, unsupported certificate purpose ... TLS trace: SSL3 alert write:warning:bad certificate connection_read(13): unable to get TLS client DN, error=49 id=1 >From a posting from 2006 and the answere from Howard Chu [2] I think I do have the same problem: My consumer server certificate "should be" from the providers view a client certificate. >From the certificate: X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Cert Type: SSL Server Am I wrong, right, lost, ... Is there a workaround or any step while creating the certificates? Thanks once more and best regards, Götz [1] http://www.galileocomputing.de/katalog/buecher/titel/gp/titelID-1801 [2] http://www.openldap.org/lists/openldap-software/200604/msg00202.html -- 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 5

TLS issues
by Daniel Gomes 12 Apr '10

12 Apr '10

Dear list members, I am having some problems with TLS I would like to share and hopefully solve with your help. First of all, the specs: it's a OpenLDAP 2.4.19 compiled (manually, not via apt-get) on a Ubuntu 8.04 (Hardy). I don't think it matters, but I am using the dynlist overlay (that's why I had to compile manually and not via apt-get, as I couldn't get it to work with the package Ubuntu provides). Passing on to the problem itself, let me just start by saying that the SSL/TLS setup itself seems to be working fine, and I am always able to ldapsearch on port 636 with ldaps:// (SSL) or on port 389 with ldap:// and -ZZ (TLS). Unfortunately, using other clients (phpLDAPadmin and some custom php scripts I wrote), the behavior is rather random. Sometimes it fails, sometimes it works (at the beginning it worked more often than not, lately it has been working less and less). The server logs, unfortunately, are not so helpful (for me, at least!). The only error I see (with logs at -1, trying to connect via phpLDAPadmin with TLS on port 389) is: connection_read(15): TLS accept failure error=-1 id=23, closing Apr 7 16:45:18 gold slapd[7385]: connection_closing: readying conn=23 sd=15 for close Apr 7 16:45:18 gold slapd[7385]: connection_close: conn=23 sd=15 Apr 7 16:45:18 gold slapd[7385]: daemon: removing 15 Apr 7 16:45:18 gold slapd[7385]: daemon: activity on 1 descriptor Apr 7 16:45:18 gold slapd[7385]: daemon: activity on: Apr 7 16:45:18 gold slapd[7385]: conn=23 fd=15 closed (TLS negotiation failure) Trying on port 636 with ldaps:// yields the same error. But as I mentioned, it just happen sometimes, while on others the connection is successfully established! Although I did notice that even when it does work, I get the following error: connection_read(14): unable to get TLS client DN, error=49 id=8 but it is quickly followed by a "conn=8 fd=14 TLS established tls_ssf=256 ssf=256"... So, this is my problem and it is getting me quite puzzled... The fact that it does work on occasion makes me think it can't be my configuration or the usual file permission culprit... Here's my slapd.conf (I removed the ACL configuration, as I am guessing it's not important here): # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/dyngroup.schema include /usr/local/etc/openldap/schema/inetorgperson.schema #Custom Schemas include /usr/local/etc/openldap/schema/local.schema include /usr/local/etc/openldap/schema/postfix.schema pidfile /home/slapd/run/slapd.pid argsfile /home/slapd/run/slapd.args ####################################################################### # Database definitions ####################################################################### database hdb suffix "dc=example,dc=com" rootdn "cn=admin,dc=example,dc=com" rootpw secret directory /home/slapd/database index objectClass eq ####################################################################### # Replication ####################################################################### overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 ####################################################################### # TLS ####################################################################### TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCACertificateFile /home/slapd/ssl/cacert.pem TLSCertificateFile /home/slapd/ssl/servercrt.pem TLSCertificateKeyFile /home/slapd/ssl/serverkey.pem TLSVerifyClient never ####################################################################### # Overlay (for dynamic lists) ####################################################################### overlay dynlist dynlist-attrset ipfnRole memberURL member If it helps for anything, in the ldap.conf files of the client I also have the "TLS_REQCERT never" setting, together with the TLS_CACERT and TLS_CACERTDIR for the CA's certificate. Thanks in advance for any help, -- Daniel Gomes (SysAdmin) dgomes(a)ipfn.ist.utl.pt Ext. 3487 - 218419487 Instituto de Plasmas e usão Nuclear Instituto Superior Técnico - UTL Av. Rovisco Pais - 1049-001 Lisboa - Portugal

2 2

deleting one domain
by Patrick Mburu 12 Apr '10

12 Apr '10

Hi guys i get this output from slapcat; dn: dc=mycompany,dc=com objectClass: dcObject objectClass: organization o: mycompany dc: mycompany structuralObjectClass: organization entryUUID: e235aa56-cd4a-102e-9e99-4f8ab88a5141 creatorsName: cn=root,dc=mycompany,dc=com modifiersName: cn=root,dc=mycompany,dc=com createTimestamp: 20100326174351Z modifyTimestamp: 20100326174351Z entryCSN: 20100326174351Z#000000#00#000000 dn: dc=mycompany,dc=local objectClass: dcObject objectClass: organization o: mycompany dc: mycompany structuralObjectClass: organization entryUUID: 4c85f2e4-cf9e-102e-9a60-f35afa4f4768 creatorsName: cn=root,dc=mycompany,dc=local modifiersName: cn=root,dc=mycompany,dc=local createTimestamp: 20100329164559Z modifyTimestamp: 20100329164559Z entryCSN: 20100329164559Z#000000#00#000000 i want to delete the mycompany.com domain and be left with mycompany.local how do i go abt it? thanks in advance

2 1

Re: Support for multiple suffixes in openldap
by masarati＠aero.polimi.it 12 Apr '10

12 Apr '10

> Hello Sarati > > I did not get what you said by single database rooted at "", the empty > DN. > > Can you please send me a sample config file if you have ? I really > appreciate the same. Please reply to the list. The example is database <whatyoulike> suffix "" p. > > Cheers!!!!!!!!!! > Ram > > > Don't do that. First of all, think if you really need multiple suffixes > in a single databases. In most cases, this requirement can be relaxed by > setting each suffix in a separate database. If you think you really need > to have multiple suffixes, you can use a single database rooted at "", the > empty DN. > > > > > > ________________________________ > From: "masarati(a)aero.polimi.it" <masarati(a)aero.polimi.it> > To: Meena Ram <meenaram21(a)yahoo.com> > Cc: openldap-technical(a)openldap.org > Sent: Sat, April 10, 2010 8:40:16 PM > Subject: Re: Support for multiple suffixes in openldap > >> Hello all: >> >> Is there any work around to get multiple suffixes working in openldap >> for multiple domains >> >> I saw this info in one of the links which says you have to add this >> #define BDB_MULTIPLE_SUFFIXES and then compile. >> >> >> Note: As of OpenLDAP 2.1.2.13, the default configuration will allow only >> one suffix to be defined for each bdb database. The C preprocessor >> directive #define BDB_MULTIPLE_SUFFIXES (file: >> servers/slapd/back-bdb/init.c) may be used if you want to compile in >> multiple suffix support. If you use it, subtree indexing will slow down >> by >> factor of 2. The use of suffixAlias is no longer supported by default in >> version 2.1.13. >> >> Is there any short cut to get multiple suffixes working without having >> to >> re-compile everything again. Any shortcuts really appreciated > > Don't do that. First of all, think if you really need multiple suffixes > in a single databases. In most cases, this requirement can be relaxed by > setting each suffix in a separate database. If you think you really need > to have multiple suffixes, you can use a single database rooted at "", the > empty DN. > > p. > > >

3 3

Support for multiple suffixes in openldap
by Meena Ram 10 Apr '10

10 Apr '10

Hello all: Is there any work around to get multiple suffixes working in openldap for multiple domains I saw this info in one of the links which says you have to add this #define BDB_MULTIPLE_SUFFIXES and then compile. Note: As of OpenLDAP 2.1.2.13, the default configuration will allow only one suffix to be defined for each bdb database. The C preprocessor directive #define BDB_MULTIPLE_SUFFIXES (file: servers/slapd/back-bdb/init.c) may be used if you want to compile in multiple suffix support. If you use it, subtree indexing will slow down by factor of 2. The use of suffixAlias is no longer supported by default in version 2.1.13. Is there any short cut to get multiple suffixes working without having to re-compile everything again. Any shortcuts really appreciated Cheers!!!!!!!!!! Ram

2 1

Slapd-ldap proxy between replica and mirror
by Ubay Dorta 09 Apr '10

09 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. Is it the same problem with the propagation of identity? Is there any way to avoid the problem? Thanks in advance. Javier Manteiga wrote: We are trying to set a system with the DIT split in several servers, using the Meta backend to proxy the LDAP requests among them. In the remote servers we would like to check the ACLs using the identity of the client that sent the request, instead of the identity used to create the proxy connections. For this we have configured the idassert parameters in the meta targets as follows: idassert-bind bindmethod=simple binddn="cn=manager,dc=operator,dc=com" (root user of the backend receiving the proxied query) credentials="manager" mode=self iddassert-authzFrom "dn:*" When the first proxy is made everything is OK. The proxyAuthz extension control is added to the LDAP message and the remote server behaves as expected. Our problem is that in some cases we have requests that must be proxied several times. E.g: consider a scenario with three servers in A, B and C. in which the LDAP request sent by the external client is received in A, this server proxies it to B. Finally B proxies it to C. When B tries to set the proxyAuthz control it detects that there is already one and it returns the error "proxyAuthz not allowed within namingContext". Is there anyway in which we can avoid this error and propagate the credentials of the external client to the last server?. No. If you use proxyAuthz to propagate the client's identity to a remote server, then the remote server cannot use the same trick to propagate what it believes the client's identity, while it's actually the first proxy's identity. By design we decided to disallow nested identity assertion. This mechanism requires distributed procedures, where any control like *proxyAuthz would be wrapped by procedure distribution information, thus *allowing nested chaining and so. This was discussed long ago when chaining and identity assertion were first implemented. The I.D. about distributed procedures expired long ago, and was never revitalized, so this functionality is not available. p.

2 1

slapd wont start
by Nick Pappin 09 Apr '10

09 Apr '10

Can someone tell me whats wrong here.. I had a working ldap/samba server and after I restarted the machine due to a power outage the slapd service wont start back up. Here are what the logs show when I try to bring slapd back online: Apr 8 14:06:23 mdc slapd[12286]: @(#) $OpenLDAP: slapd 2.3.43 (Apr 8 2010 13:58:40) $ Apr 8 14:06:23 mdc root@mdc: /var/tmp/portage/net-nds/openldap-2.3.43/work/openldap-2.3.43/servers/slapd Apr 8 14:06:23 mdc slapd[12286]: nss_ldap: failed to bind to LDAP server ldap://127.0.0.1/: Can't contact LDAP server Apr 8 14:06:23 mdc slapd: Last message 'nss_ldap: failed to ' repeated 1 times, supressed by syslog-ng on mdc.mydomain.org Apr 8 14:06:23 mdc slapd[12286]: nss_ldap: reconnecting to LDAP server... Apr 8 14:06:23 mdc slapd[12286]: nss_ldap: failed to bind to LDAP server ldap://127.0.0.1/: Can't contact LDAP server Apr 8 14:06:23 mdc slapd[12286]: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)... Apr 8 14:06:24 mdc slapd[12286]: nss_ldap: failed to bind to LDAP server ldap://127.0.0.1/: Can't contact LDAP server Apr 8 14:06:24 mdc slapd[12286]: nss_ldap: could not search LDAP server - Server is unavailable Apr 8 14:06:24 mdc slapd[12286]: nss_ldap: failed to bind to LDAP server ldap://127.0.0.1/: Can't contact LDAP server Apr 8 14:06:24 mdc slapd: Last message 'nss_ldap: failed to ' repeated 1 times, supressed by syslog-ng on mdc.mydomain.org Apr 8 14:06:24 mdc slapd[12286]: nss_ldap: reconnecting to LDAP server... Apr 8 14:06:24 mdc slapd[12286]: nss_ldap: failed to bind to LDAP server ldap://127.0.0.1/: Can't contact LDAP server Apr 8 14:06:24 mdc slapd[12286]: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)... Apr 8 14:06:25 mdc slapd[12286]: nss_ldap: failed to bind to LDAP server ldap://127.0.0.1/: Can't contact LDAP server Apr 8 14:06:25 mdc slapd[12286]: nss_ldap: could not search LDAP server - Server is unavailable Apr 8 14:06:25 mdc slapd[12287]: bdb(dc=mydomain,dc=org): unable to allocate memory for mutex; resize mutex region Apr 8 14:06:25 mdc slapd[12287]: hdb_db_open: Database cannot be opened, err 12. Restore from backup! Apr 8 14:06:25 mdc slapd[12287]: bdb(dc=mydomain,dc=org): DB_ENV->lock_id_free interface requires an environment configured for the locking subsystem Apr 8 14:06:25 mdc slapd[12287]: bdb(dc=mydomain,dc=org): txn_checkpoint interface requires an environment configured for the transaction subsystem Apr 8 14:06:25 mdc slapd[12287]: bdb_db_close: txn_checkpoint failed: Invalid argument (22) Apr 8 14:06:25 mdc slapd[12287]: backend_startup_one: bi_db_open failed! (12) Apr 8 14:06:25 mdc slapd[12287]: bdb_db_close: alock_close failed Apr 8 14:06:25 mdc slapd[12287]: slapd stopped. Apr 8 14:06:25 mdc slapd[12287]: connections_destroy: nothing to destroy. Thanks ~ Nick

3 3

group migration to Ldap
by Francis, Steve (IHG) 09 Apr '10

09 Apr '10

I'm tyring to migrate my /etc/group to openldap. I've used the migration tools, but for some reason, I get the following when trying to do the ldapadd for the group.ldif generated . adding new entry "cn=at,ou=Group,dc=zlinux,dc=hiw,dc=com" ldap_add: Object class violation (65) additional info: no structural object class provided Not sure why, as the /etc/passwd migrated just fine. Steve Francis Technical Advisor - zSeries, zLinux, z/OS IHG Alpharetta Data Center Ph: 770-442-7157 Cell: 770-906-3122 IM: francisihg

2 4

ProxyAddresses: attribute undefined Any info on how to fix this
by Meena Ram 09 Apr '10

09 Apr '10

ProxyAddresses: attribute undefined Any info on how to fix this ldap_add: Undefined attribute type (17) additional info: proxyAddresses: attribute type undefined

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical