openldap-software

openldap-software@openldap.org

2719 discussions

Re: syncrepl only works as rootdn
by Howard Chu 02 Feb '07

02 Feb '07

Redirected from -bugs; there is no evidence of a bug here. Christopher Cowart wrote: > Hello, > > I have 3 installations of openldap-server-2.3.33 running on FreeBSD > 6.1-REL: ldap-master, ldap1, ldap2. I am using syncrepl to replicate > ldap-master to ldap1 and ldap2. The replicated directory is missing > entire ou branches in my tree. > > I have created the following objects in my directory: > cn=syncrepl-ldap1,dc=example,dc=com > cn=syncrepl-ldap2,dc=example,dc=com > > I've made the following configurations on the provider: > | access to * > | by dn.regex="cn=syncrepl-(ldap1|ldap2),dc=example,dc=com" read > | by * break > | > | # More ACLs Follow > | > | # For Sync Replication > | overlay syncprov > | syncprov-checkpoint 100 10 > | syncprov-sessionlog 100 More information is needed. There's no indication that ACLs are any problem here. Of course, you've listed your rootdn in your ACLs, which is useless. One possible explanation is that you didn't raise the sizelimits for the syncrepl users, so they weren't able to get a full refresh. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: syncrepl only works as rootdn
by Christopher Cowart 01 Feb '07

01 Feb '07

On Thu, Feb 01, 2007 at 08:59:39PM -0800, Christopher Cowart wrote: > On Thu, Feb 01, 2007 at 08:25:52PM -0800, Howard Chu wrote: > > Redirected from -bugs; there is no evidence of a bug here. > Perhaps the -software list charter should include mention of support > issues or questions? As it was, -bugs seemed most appropriate. > > > Christopher Cowart wrote: > > >Hello, > > > > > >I have 3 installations of openldap-server-2.3.33 running on FreeBSD > > >6.1-REL: ldap-master, ldap1, ldap2. I am using syncrepl to replicate > > >ldap-master to ldap1 and ldap2. The replicated directory is missing > > >entire ou branches in my tree. > > > > > >I have created the following objects in my directory: > > >cn=syncrepl-ldap1,dc=example,dc=com > > >cn=syncrepl-ldap2,dc=example,dc=com > > > > > >I've made the following configurations on the provider: > > >| access to * > > >| by dn.regex="cn=syncrepl-(ldap1|ldap2),dc=example,dc=com" read > > >| by * break > > >| > > >| # More ACLs Follow > > >| > > >| # For Sync Replication > > >| overlay syncprov > > >| syncprov-checkpoint 100 10 > > >| syncprov-sessionlog 100 > > > > More information is needed. There's no indication that ACLs are any problem > > here. Of course, you've listed your rootdn in your ACLs, which is useless. > > Could you suggest what other information might be helpful? I thought the > fact that syncrepl works when binding as the rootdn but not the syncrepl > user indicated ACLs. What makes you think otherwise? > > > One possible explanation is that you didn't raise the sizelimits for the > > syncrepl users, so they weren't able to get a full refresh. > > Thanks for this suggestion. I've added this (from a forum post): > | limits dn.regex="cn=syncrepl-ldap1,dc=example,dc=com" > | time.soft=unlimited time.hard=unlimited size.soft=unlimited > | size.hard=unlimited > > After restarting the provider, the consumer is still not replicating the > missing portions of the directory. Do you have any other suggestions? Just to clarify, I also blew away the backend on the consumer and restarted that instance of slapd. -- Chris Cowart Network and Infrastructure Systems Administrator RSSP-IT, UC Berkeley "May all your pushes be popped"

2 1

Re: syncrepl only works as rootdn
by Howard Chu 01 Feb '07

01 Feb '07

Christopher Cowart wrote: > Thanks for this suggestion. I've added this (from a forum post): > | limits dn.regex="cn=syncrepl-ldap1,dc=example,dc=com" > | time.soft=unlimited time.hard=unlimited size.soft=unlimited > | size.hard=unlimited > > After restarting the provider, the consumer is still not replicating the > missing portions of the directory. Do you have any other suggestions? Aside from carefully reading the syncrepl documentation in the Admin Guide: > And on the consumer (ldap1): > | # Sync Replication > | syncrepl rid=001 > | provider=ldaps://ldap-master.example.com/ > | type=refreshAndPersist > | interval=00:01:00:00 > | searchbase="dc=example,dc=com" > | scope=sub > | schemachecking=off > | bindmethod=simple > | binddn="cn=syncrepl-ldap1,dc=example,dc=com" > | credentials=supersecret You probably need a retry specification here. Otherwise the consumer will quit once it encounters an error. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: syncrepl only works as rootdn
by Howard Chu 01 Feb '07

01 Feb '07

Christopher Cowart wrote: > On Thu, Feb 01, 2007 at 08:25:52PM -0800, Howard Chu wrote: >> Redirected from -bugs; there is no evidence of a bug here. > Perhaps the -software list charter should include mention of support > issues or questions? As it was, -bugs seemed most appropriate. The -bugs list is for discussion of actual bug reports. Bug reports are submitted using the ITS. Usage questions belong on the -software list. As its charter says: "technical issues specific to OpenLDAP Software." >> More information is needed. There's no indication that ACLs are any problem >> here. Of course, you've listed your rootdn in your ACLs, which is useless. > > Could you suggest what other information might be helpful? I thought the > fact that syncrepl works when binding as the rootdn but not the syncrepl > user indicated ACLs. What makes you think otherwise? Aside from the extraneous rootdn rules, there was no problem with your ACLs. You should have provided the complete database configuration on the provider, for starters. At this point that's probably not necessary since you obviously didn't have the correct limits in place. These requirements are documented in section 15.3.2 of the Admin Guide. http://www.openldap.org/doc/admin23/syncrepl.html >> One possible explanation is that you didn't raise the sizelimits for the >> syncrepl users, so they weren't able to get a full refresh. > > Thanks for this suggestion. I've added this (from a forum post): > | limits dn.regex="cn=syncrepl-ldap1,dc=example,dc=com" > | time.soft=unlimited time.hard=unlimited size.soft=unlimited > | size.hard=unlimited > > After restarting the provider, the consumer is still not replicating the > missing portions of the directory. Do you have any other suggestions? You'll probably need to reset the sync cookie on the consumers. See section 15.3.3 of the Admin Guide, and/or the slapd(8) manpage. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Bind using credentials from another directory server
by François Beretti 01 Feb '07

01 Feb '07

Hello all ! Does OpenLDAP provide a way to authenticate on it using a DN / pwd of another LDAP server ? I have read the manual page about the LDAP and META backends, but I did not find if it match my will. At the end I would like to authenticate on OpenLDAP with a DN/pwd of another directory (or maybe SASL credentials ?), and access (probably only through OpenLDAP) to the data of both OpenLDAP and the other directory server. I can customize the OpenLDAP server (in fact: our server), and not the other server (the customer server). Thank you François

6 11

Could not locate TLS/SSL package on openldap install
by Andrew Higginbotham 01 Feb '07

01 Feb '07

Hi, I'm installing openldap with tls against a custom openssl install that is located in /usr/local/ssl . To compile I run # export LDFLAGS="-L/usr/local/ssl/lib" # export CPPFLAGS="-I/usr/local/ssl/include/openssl" Then we have # env | grep FLAG LDFLAGS=-L/usr/local/ssl/lib CPPFLAGS=-I/usr/local/ssl/include/openssl So that all looks normal. But when I run 'configure' with # ./configure --prefix=/usr/local/openldap --libexecdir=/usr/local/libexec --enable-slurpd --with-tls --enable-slapd the last few lines I see are checking openssl/ssl.h usability... yes checking openssl/ssl.h presence... yes checking for openssl/ssl.h... yes checking for SSL_library_init in -lssl... no checking for ssl3_accept in -lssl... no checking OpenSSL library version (CRL checking capability)... no configure: error: Could not locate TLS/SSL package So it looks like it can see the header files alright at least. I have attached my config.log file to this mail, in case that might help. Thanks, Andrew

2 1

Slapd issue
by Philip Bellino 01 Feb '07

01 Feb '07

Hello, I am running slapd(openldap-2.3.32) on a linux host. I am also running openldap-2-32-3 on a linux client. If I use the "allow_bind_v2" switch in the slapd.conf file, I can do anonymous simple binds from the client to the server over TCP with no problems. I can also do simple login/password authentication with no problems. I now an trying to use v3 secure connections. When I attempt to authenticate, I get the following errors from the slapd logs (in bold): TLS trace: SSL_accept:SSLv3 flush data tls_read: want=5 error=Resource temporarily unavailable TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL daemon: epoll: listen=9 active_threads=0 tvp=NULL daemon: epoll: listen=10 active_threads=0 tvp=NULL daemon: activity on 1 descriptor daemon: activity on: 14r daemon: read active on 14 connection_get(14) connection_get(14): got connid=0 connection_read(14): checking for input on id=0 tls_read: want=5, got=5 0000: 15 03 01 00 02 ..... tls_read: want=2, got=2 0000: 02 30 .0 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:1057 connection_read(14): TLS accept failure error=-1 id=0, closing connection_closing: readying conn=0 sd=14 for close connection_close: conn=0 sd=14 daemon: removing 14 conn=0 fd=14 closed (TLS negotiation failure) daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL daemon: epoll: listen=9 active_threads=0 tvp=NULL daemon: epoll: listen=10 active_threads=0 tvp=NULL daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL daemon: epoll: listen=9 active_threads=0 tvp=NULL daemon: epoll: listen=10 active_threads=0 tvp=NULL My slapd.conf file is: include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/nis.schema # Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args TLSCACertificateFile /usr/local/etc/openldap/cacert.pem TLSCertificateFile /usr/local/etc/openldap/servercrt.pem TLSCertificateKeyFile /usr/local/etc/openldap/serverkey.pem TLSVerifyClient never ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "dc=mrv,dc=com" rootdn "cn=Manager,dc=mrv,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /usr/local/var/openldap-data # Indices to maintain index objectClass eq #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 It loks to me as is slapd is trying to read the client certificate even though my slapd.conf file entry "TLSVerifyClient never" is set. I am new to this all, so I do not know if I am interpreting this correctly or not. Any help would be most appreciated. Thanks, Phil Bellino ============================ Phil Bellino MRV Communications, Inc. Boston Product Division 295 Foster St. Littleton,MA 01460 Tel: (978)952-4807 Email: pbellino(a)mrv.com ============================

2 1

ldapsearch for digest-md5
by Radhakrishnan Balasubramanian 01 Feb '07

01 Feb '07

Hi All, I have Openldap Server -2.2.13 with Cyrus SASL configured. I am trying to do ldapsearch for digest-md5 .I am getting the following error : ldapsearch -Y digest-md5 -D "uid=pokemon,ou=People,dc=cisco,dc=com" -w pokemon123 SASL/DIGEST-MD5 authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): authentication failure: client response doesn't match what we generated But ldapsearch with -U option is successful. Please let me know what need to be done on my LDAP server for making ldapsearch sucessful without using -U (SASL authentication identiy) and using only -D option . Thanks, RK ____________________________________________________________________________________ Don't get soaked. Take a quick peak at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/#loc_weather

4 4

Searching Boolean attributes
by tarallo＠ort.edu.uy 01 Feb '07

01 Feb '07

We have created a custom object class that has one boolean attribute, we use openldap 2.3.19. We can't get results from the searches using that attribute. We created sucessfully some objects and set the attribute to TRUE, but when we try to search we get nothing. We are executing things like that: ldapsearch -x -b "ou=roles,dc=ort,dc=edu,dc=uy" "(SiteEnabled=TRUE)" -- A/P Andrés Tarallo

1 0

2.3.33 back_meta test failure
by Andreas Hasenack 01 Feb '07

01 Feb '07

Hello, while running make test on a 2.3.33 build, I get an error in test030-relay when using the meta backend: (...) Using meta backend... Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Searching base="dc=example,dc=com"... Searching base="o=Example,c=US"... Search failed (255)! ./scripts/relay: line 78: kill: (31577) - Processo inexistente >>>>> ./scripts/test030-relay failed (exit 255) make: ** [bdb-yes] Erro 255 The log shows: $ tail testrun/slapd.1.log conn=3 op=1 >>> meta_search_dobind_init[0] conn=3 op=1 <<< meta_search_dobind_init[0]=1 ==> rewrite_context_apply [depth=1] string='o=Example,c=US' ==> rewrite_rule_apply rule='((.+),)?o=Example,[ ]?c=US$' string='o=Example,c=US' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'dc=example,dc=com'} [rw] searchBase: "o=Example,c=US" -> "dc=example,dc=com" ==> rewrite_context_apply [depth=1] string='(objectClass=*)' ==> rewrite_context_apply [depth=1] res={0,'NULL'} [rw] searchFilter: "(objectClass=*)" -> "(objectClass=*)" /home/andreas/updates-svn/openldap/BUILD/openldap-2.3.33/servers/slapd/.libs/lt-slapd: symbol lookup error: ../servers/slapd/back-meta/.libs/back_meta-2.3.so.0: undefined symbol: ldap_back_proxy_authz_ctrl Anybody else with the same problem?

4 7

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software