openldap-technical

openldap-technical@openldap.org

3 participants
9937 discussions

syncrepl provider not working after upgrade to 2.4.26
by Nick Milas 19 Oct '11

19 Oct '11

Hi, I have a syncrepl provider v2.4.22 working fine (the only provider in our organization). I upgraded with the same configuration to v2.4.26 and provider is not working (neither over ldaps: nor over ldap:). Otherwise connectivity is fine (with any ldap client) both with ldap and with ldaps. I get (in all consumers): Oct 17 21:21:32 vmail slapd[14621]: do_syncrep2: rid=111 LDAP_RES_SEARCH_RESULT Oct 17 21:21:32 vmail slapd[14621]: do_syncrep2: rid=111 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Oct 17 21:21:32 vmail slapd[14621]: do_syncrep2: rid=111 (53) Server is unwilling to perform Oct 17 21:21:32 vmail slapd[14621]: do_syncrepl: rid=111 rc -2 retrying How can I troubleshoot the issue further? Current config on the provider is: overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 and on consumers: syncrepl rid=111 provider=ldaps://ldap.example.com tls_reqcert=never type=refreshAndPersist retry="60 +" searchbase="dc=example,dc=com" schemachecking=off bindmethod=simple binddn="cn=someuser,dc=example,dc=com" credentials="password" Thanks, Nick

4 6

Loading LDAP schema files into cn=config
by Mark Cave-Ayland 19 Oct '11

19 Oct '11

Hi all, Having started to look at the changes required to migrate from a slapd.conf setup to a cn=config setup, one of things I'm struggling with is how to load new LDAP schemas into cn=config. I've seen the guides similar to this one here: http://blogger.ziesemer.com/2011/01/ldap-authentication-for-samba.html which suggest hacking together a temporary slapd.conf file containing just the include directives, run slaptest, and then hack the output so that it can be loaded into cn=config using ldapadd. Given that this is a quite a common task, is there no way of generating the LDIF directly to be loaded into the directory, e.g. slaptest -s /etc/ldap/schema/myschema.schema [ -n <schemanum> ] -l myschema.ldif Or then again, is this functionality already there but I just haven't managed to find it yet? I'd be grateful if someone could point me in the right direction and/or give me some hints as to the best way to manage schemas in the new regime. Many thanks, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

13 49

What's the java equivalent of ldap_set_option( NULL, LDAP_OPT_X_TLS_CACERTDIR, cert_path)?
by daisy.wu＠emc.com 19 Oct '11

19 Oct '11

Hi, OpenLDAP developers, I have been able to successfully write a simple C program using the OpenLDAP C-SDK to establish connection to Microsoft Active Directory Server over SSL. In my test program, I call ldap_set_option( NULL, LDAP_OPT_X_TLS_CACERTDIR, cert_path) to set the path to a directory where all my CA Root certificates are. OpenLDAP uses OpenSSL format of certificate management, the trusted CA Root Certificates are no longer imported into a single file (aka the certificate store). OpenSSL hashes the certificate file (.pem format), and uses symbolic link to link to the actual certificate.pem file. Here's content of my cert_path dir: wud2@pleoski:[/emc/wud2/ldap_certdb]> ls -altr total 80 -rw-r--r-- 1 wud2 dctmuser 1688 Sep 16 09:36 ldap112_rootca.pem drwxr-xr-x 2 wud2 dctmuser 1024 Sep 16 09:37 ./ lrwxrwxrwx 1 wud2 dctmuser 18 Sep 16 10:11 e8332e5a.0 -> ldap112_rootca.pem drwxr-xr-x 67 wud2 dctmuser 9216 Oct 14 14:04 ../ I am trying to write a Java LDAP client program using Novell's JLDAP to connect to Microsoft Active Directory server, over SSL. I would like to use my current cert_path (listed above) to establish LDAP SSL connection, in Java. I found an example listed on the Novell site: http://developer.novell.com/documentation/samplecode/jldap_sample/security/… // Dynamically set JSSE as a security provider Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider()); // Dynamically set the property that JSSE uses to identify // the keystore that holds trusted root certificates System.setProperty("javax.net.ssl.trustStore", path); As you can see, in this Java example, the "path" value is expected to be "keystore file that holds trusted root certificates". But in my case, I only have a directory where trusted root certificates are present. I don't exactly have a single keystore file. So, my questions is, what is the Java equivalent for ldap_set_option( NULL, LDAP_OPT_X_TLS_CACERTDIR, cert_path)? Any comments/input would be much appreciated. Thanks. Daisy

5 4

SCRAM-SHA-1
by Michael Ströder 17 Oct '11

17 Oct '11

HI! I'd like to do some interop testing using SCRAM-SHA-1. But I don't know how to set the userPassword value in OpenLDAP for that. I guess I have to write my own tool... Did anybody here already play with it? Ciao, Michael.

2 1

Migrating ACLs to cn=config
by Nick Milas 17 Oct '11

17 Oct '11

Hello, I have used: slaptest -f slapd.conf -F slapd.d to migrate my slapd.conf-based config, but ACLs included in slapd.conf as: include /path/to/acl.conf where not included in the produced configuration. Instead a default(?) rule of "olcAccess: {0}to * by * none" was included. How can we migrate all rules from acl.conf automatically (it's a fairly big file - about 1000 lines). Thanks in advance, Nick

2 2

multi master no syncing.
by Sébastien Bernard 17 Oct '11

17 Oct '11

Hi, I've setup a multimaster cluster composed of two machine (in my example 192.168.0.204 and 192.168.0.197). Everything is working ok and both side are replicating ok. However, I've a problem I'd like to submit to your sagacity. When I put down a server, and modify the other server (delete or add), when the first server comes back, the modifications are not pushed in the old server. Server 1 says Entry cn=seb,ou=orgunit,o=org,dc=example,dc=com changed by peer, ignored Adding new entries works ok and synchronisation happens but for the nodes altered while one of the servers was down, the modifications are lost (or more precisely ignored by the other). My questions: Is this normal behaviour (Maybe I got the configuration wrong) ? How may I force the missing entries to be replicated to the other ? (Only solution I found is to wipe the entire database on the down server that force a replication from its peer). sincerely, Seb Here an extract of the slapd.log from server 1: Sep 22 10:12:32 dhcp204 slapd[2689]: do_syncrep2: rid=002 (-1) Can't contact LDAP server Sep 22 10:12:32 dhcp204 slapd[2689]: do_syncrepl: rid=002 rc -1 retrying (4 retries left) Sep 22 10:12:32 dhcp204 slapd[2689]: do_syncrep2: rid=004 (-1) Can't contact LDAP server Sep 22 10:12:32 dhcp204 slapd[2689]: do_syncrepl: rid=004 rc -1 retrying (4 retries left) Sep 22 10:12:32 dhcp204 slapd[2689]: conn=1002 op=2 UNBIND Sep 22 10:12:32 dhcp204 slapd[2689]: conn=1002 fd=19 closed Sep 22 10:12:32 dhcp204 slapd[2689]: conn=1003 op=2 UNBIND Sep 22 10:12:32 dhcp204 slapd[2689]: conn=1003 fd=20 closed Sep 22 10:12:37 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN="cn=config" ldap_sasl_bind_s failed (-1) Sep 22 10:12:37 dhcp204 slapd[2689]: do_syncrepl: rid=002 rc -1 retrying (3 retries left) Sep 22 10:12:37 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN="cn=manager,dc=example,dc=com" ldap_sasl_bind_s failed (-1) Sep 22 10:12:37 dhcp204 slapd[2689]: do_syncrepl: rid=004 rc -1 retrying (3 retries left) Sep 22 10:12:42 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN="cn=manager,dc=example,dc=com" ldap_sasl_bind_s failed (-1) Sep 22 10:12:42 dhcp204 slapd[2689]: do_syncrepl: rid=004 rc -1 retrying (2 retries left) Sep 22 10:12:42 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN="cn=config" ldap_sasl_bind_s failed (-1) Sep 22 10:12:42 dhcp204 slapd[2689]: do_syncrepl: rid=002 rc -1 retrying (2 retries left) Sep 22 10:12:47 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN="cn=manager,dc=example,dc=com" ldap_sasl_bind_s failed (-1) Sep 22 10:12:47 dhcp204 slapd[2689]: do_syncrepl: rid=004 rc -1 retrying (1 retries left) Sep 22 10:12:47 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN="cn=config" ldap_sasl_bind_s failed (-1) Sep 22 10:12:47 dhcp204 slapd[2689]: do_syncrepl: rid=002 rc -1 retrying (1 retries left) Sep 22 10:12:52 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN="cn=config" ldap_sasl_bind_s failed (-1) Sep 22 10:12:52 dhcp204 slapd[2689]: do_syncrepl: rid=002 rc -1 retrying Sep 22 10:12:52 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN="cn=manager,dc=example,dc=com" ldap_sasl_bind_s failed (-1) Sep 22 10:12:52 dhcp204 slapd[2689]: do_syncrepl: rid=004 rc -1 retrying Sep 22 10:12:57 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN="cn=config" ldap_sasl_bind_s failed (-1) Sep 22 10:12:57 dhcp204 slapd[2689]: do_syncrepl: rid=002 rc -1 retrying (4 retries left) Sep 22 10:12:57 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN="cn=manager,dc=example,dc=com" ldap_sasl_bind_s failed (-1) Sep 22 10:12:57 dhcp204 slapd[2689]: do_syncrepl: rid=004 rc -1 retrying (4 retries left) Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1007 fd=13 ACCEPT from IP=192.168.0.197:55471 (IP=0.0.0.0:389) Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1007 op=0 BIND dn="cn=manager,dc=example,dc=com" method=128 Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1007 op=0 BIND dn="cn=manager,dc=example,dc=com" mech=SIMPLE ssf=0 Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1007 op=0 RESULT tag=97 err=0 text= Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1008 fd=15 ACCEPT from IP=192.168.0.197:55473 (IP=0.0.0.0:389) Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1008 op=0 BIND dn="cn=config" method=128 Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1008 op=0 BIND dn="cn=config" mech=SIMPLE ssf=0 Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1008 op=0 RESULT tag=97 err=0 text= Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1008 op=1 SRCH base="cn=config" scope=2 deref=0 filter="(objectClass=*)" Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1008 op=1 SRCH attr=* + Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1008 op=1 INTERM oid=1.3.6.1.4.1.4203.1.9.1.4 Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1007 op=1 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1007 op=1 SRCH attr=* + Sep 22 10:13:02 dhcp204 slapd[2689]: srs csn 20110922081225.199039Z#000000#000#000000 Sep 22 10:13:02 dhcp204 slapd[2689]: log csn 20110922081225.199039Z#000000#000#000000 Sep 22 10:13:02 dhcp204 slapd[2689]: cmp 0, too old Sep 22 10:13:02 dhcp204 slapd[2689]: Entry cn=seb,ou=orgunit,o=org,dc=example,dc=com changed by peer, ignored Sep 22 10:13:02 dhcp204 slapd[2689]: syncprov_search_response: cookie=rid=003,csn=20110922081235.611410Z#000000#000#000000 Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1007 op=1 INTERM oid=1.3.6.1.4.1.4203.1.9.1.4 Sep 22 10:17:57 dhcp204 slapd[2689]: do_syncrep2: rid=002 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Sep 22 10:17:57 dhcp204 slapd[2689]: do_syncrep2: rid=004 LDAP_RES_INTERMEDIATE - REFRESH_DELET

3 4

adding monitor to cn=config on already running slapd
by Craig White 17 Oct '11

17 Oct '11

The openldap guide suggests that the configuration for dynamic configuration is yet to be written and it seems it is probably easy to get configured from the start but not intuitive enough for me to add to an already running server. (this is my consumer if that makes a difference) # cat monitor-add.ldif # Load dynamic backend modules dn: cn=module,cn=config changetype: add add: module olcModuleload: back_monitor - # http://www.openldap.org/doc/admin24/monitoringslapd.html dn: olcDatabase=monitor,cn=config #objectClass: olcDatabaseConfig changetype: add add: olcDatabase olcDatabase: {2}monitor # ./monitor-add.sh Enter LDAP Password: adding new entry "cn=module,cn=config" ldapmodify: update failed: cn=module,cn=config ldap_add: Bad parameter to an ldap routine (-9) I can't seem to find the right ldif combination to add monitor (Ubuntu Lucid / slapd 2.4.21-0ubuntu5.5) # grep ModulePath /etc/ldap/slapd.d/cn\=config/cn\=module\{0\}.ldif olcModulePath: /usr/lib/ldap -- Craig White ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ craig.white(a)ttiltd.com 1.800.869.6908 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ www.ttiassessments.com Need help communicating between generations at work to achieve your desired success? Let us help!

4 5

Re: Syncrepl SSL fail
by Hugo Deprez 17 Oct '11

17 Oct '11

Hello, tls_reqcert=never is necessary for the replication. If it is not defined, I get an error. The weird thing, is that I do have the same configuration on another host, running Debian Lenny with slapd version 2.4.23-3 and I don't have to define this parameter. The server I report the error, is running 2.4.23-7 on Squeeze. Is there any way to explain this difference ? Regards, Hugo On 17 October 2011 04:27, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Sunday, October 16, 2011 12:51 AM -0700 Howard Chu <hyc(a)symas.com> > wrote: > >> Quanah Gibson-Mount wrote: >>> >>> >>> --On October 13, 2011 10:43:55 AM -0700 Josh Miller >>> <joshua(a)itsecureadmin.com> wrote: >>> >>>> >>>> On Oct 13, 2011, at 10:29 AM, Quanah Gibson-Mount wrote: >>>>> >>>>> I don't see any of the tls_* options to the syncrepl configuration >>>>> here. Likely the syncrepl client is unable to verify the master's >>>>> cert. I would note that using refreshOnly is ill-advised. >>>> >>>> Hi Quanah, >>>> >>>> Why is RefreshOnly ill-advised? That is the recommendation in the docs >>>> (very timely as I just set this up again myself). >>>> >>>> re: http://www.openldap.org/doc/admin24/replication.html >>> >>> The admin guide has examples, not recommendations. In any case, I fully >>> intend to change those examples to be refreshAndPersist so people stop >>> defaulting to refreshOnly. It is not always reliable, and your >>> significantly delay your replication by using it. >> >> Of course, it may be the only thing that works reliably if you have a >> firewall that silently kills old connections. >> >> The examples should stand as-is. We cannot predict what environment it's >> going to be deployed in. It's up to administrators to use their brains >> and know these details of their network. > > I think at the least we should document both. Virtually everyone takes the > admin guide verbatim without comprehending what it is they are doing. Giving > them two options would hopefully at least make them have to consider why > there are multiple options. > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > >

1 0

"TLS_REQCERT allow" rejects CN and hostname mismatch?
by Noël Köthe 16 Oct '11

16 Oct '11

Hello, (openldap 2.4.25 on Debian GNU/Linux) TLS_REQCERT allow is documented with "The server certificate is requested. If no certificate is provided, the session proceeds normally. If a bad certificate is provided, it will be ignored and the session proceeds normally." But if I test it it looks like the common name (CN) is checked against the hostname of the server: $ cat /etc/ldap/ldap.conf BASE dc=domain,dc=lan URI ldaps://localhost TLS_CACERT /etc/ldap/ca.crt TLS_REQCERT allow $ ldapsearch -x -d320 cn=* TLS: hostname (thinker.domain.lan) does not match common name in certificate (localhost). ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) If I change TLS_REQCERT to never the ldapsearch command works like expected. Is it correct that "TLS_REQCERT allow" checks the CN and the hostname and stops when they mismatch? I found this old ITS entry with a patch which would document my described behaviour in the manpage. http://www.openldap.org/its/index.cgi/Documentation?id=4941;selectid=4941 Is this part of "TLS_REQCERT allow" just missing in the documentation or do I have a problem to understand this correctly? thx for your answer. -- Noël Köthe <noel debian.org> Debian GNU/Linux, www.debian.org

3 2

Adding new Indexes while the directory is running
by Diego Lima 16 Oct '11

16 Oct '11

Hello all, I've recently migrated my OpenLDAP servers configurations to the online configuration (cn=config) and I have a question on how to deal with indexes. I can add a new index directive while the base is running, but should I do this? Don't I need to stop the directory and reindex the whole database when I add the new index entry? Or can I add it and postpone running slapindex to a later time? Thank you! -- Diego Lima http://www.diegolima.org

5 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical