openldap-software

openldap-software@openldap.org

2719 discussions

delta-syncrepl, accesslog logpurge, slapadd -w problem
by David Hawes 09 Sep '08

09 Sep '08

I was testing the recovery of a slave in a delta-syncrepl configuration after an accesslog purge, and noticed that operations that have been purged from the accesslog that occurred while the slave was down do not get replicated when the initial master database was loaded with "slapadd -w". If the slave database is empty, it will correctly receive all master entries, but if you shut the slave down (after it has done the initial sync), make a change, wait for the change to be purged from the accesslog, and then bring the slave back up, the slave will not see the change. The contextCSN of the slave is updated in this case, but nothing else is replicated, and the slave is effectively stale. When the slave is first brought up I do notice that two different contextCSN(s) are written to the auditlog. When the initial database is loaded without using the -w flag with slapadd or with ldapsearch (on an empty database), the slave receives all changes correctly after the accesslog has been purged. Is this expected behavior in any way? I am using the standard delta-syncrepl config from the admin guide with 2.4.11.

3 5

Problem with 2.4.11 configure
by Philip Bellino 09 Sep '08

09 Sep '08

Hello, When I tried to configure OpenLDAP-2.4.11, I received the following error from "configure -with-tls -enable-ipv6"" Checking Berkeley DB version for BDB/HDB backends... no Configure error: BDB/HDB: BerkeleyDB version incompatible When I used OpenLDAP-2.3.39 and ran configure with the same options, it finds the backends and all is well. I have attached both "config.log" files. <<config.2.4.11.log.log>> <<config.2-3.39.log.log>> Any help will be appreciated. Thanks, Phil Bellino Phil Bellino Software Engineer MRV Communications, Inc. 295 Foster Street Littleton, MA. 01460 Phone: 978-952-4807 Fax: 978-952-5444 Email: pbellino(a)mrv.com <http://www.mrv.com/>

2 3

Re: sasl-secprops' minssf not setting SASL SSF correctly
by PGNet 09 Sep '08

09 Sep '08

> Re-read what the slap.conf(5) man page says. That's unhelpful. It's of course, already been read. man slapd.conf ... minssf=<factor> property specifies the minimum acceptable security strength factor ... maxssf=<factor> property specifies the maximum acceptable security strength factor ... Reads to me like "SASL SSF" is set by min/maxssf. It certainly affects it. Unfortuntely, in a manner that's confusing. If have some helpful clarification, please state it. Thanks.

2 1

sasl-secprops' minssf not setting SASL SSF correctly
by PGNet 09 Sep '08

09 Sep '08

In 'man slapd.conf', sasl-secprops <properties> ... minssf=<factor... The default is 0. If I set values in /etc/openldap/slapd.conf, and test security layer strength, (1) sasl-secprops noanonymous,noplain,noactive ldapwhoami -ZZ SASL SSF: 56 (2) sasl-secprops noanonymous,noplain,noactive,minssf=128 ldapwhoami -ZZ SASL SSF: 56 (3) sasl-secprops noanonymous,noplain,noactive,minssf=128,maxssf=256 ldapwhoami -ZZ SASL SSF: 0 I'd expected for the 3 cases, (1) SASL SSF: 0 <- default (2) SASL SSF: 128 <- set by minssf (3) SASL SSF: 128 <- set by minssf Am I correct in my understanding that "SASL SSF" is supposed to track with the sasl-secprops properties? If yes, is there more config required? A bug, maybe? If no, how do I correctcly set/verify SASL SSF strength? Thanks. update: I fell across a 2-year old, seemingly-relevant post: http://www.openldap.org/lists/openldap-software/200609/msg00148.html "The Cyrus SASL GSSAPI module currently doesn't know how to report the actual SSF in effect. It is hardcoded to report 56. Some versions assume that triple-DES is available and report 112, depending on the Kerberos library you compiled with. Anyway, this is not a limitation in OpenLDAP, it's a bug in Cyrus SASL." Could what I'm seeing be the result of this as yet (still) unresolved bug?

2 1

Re: AW: Re: AW: Re: SASL bind with Kerberos: (was: Simple binds with SASL/GSSAPI (Resource temporarily unavailable))
by Quanah Gibson-Mount 08 Sep '08

08 Sep '08

--On Monday, September 08, 2008 9:26 PM +0200 Hauke Coltzau <hauke.coltzau(a)FernUni-Hagen.de> wrote: > ii libsasl2-modules-gssapi-mit 2.1.22.dfsg1-18ubuntu2 \\ > Cyrus SASL - pluggable authentication module I would highly recommend using Heimdal on the master side. But that's up to you. ;) > - In the first approach, the user already has a TGT and asks the KDC for > a "ldap/fqdn@REALM-ticket"? This is done by ldapsearch, not by slapd? > Hence, slapd "only" needs access to its keytab to be able to decrypt the > clients messages? I believe that is correct, yes. At Stanford, I had to point slapd at the keytab in a shell script, but I believe that was because I was using SASL/GSSAPI to do replication as well. It's been a while. ;) > - And in the second one, the user provides username and password (plain), > slapd converts the username into a principle (user@REALM) and forwards > this to saslauthd? So this should be secured via TLS? You can try securing it via startTLS, but nothing blocks a user from still doing it in the clear, unfortunately (i.e., you can reject the non-secured bind, but they'll have already sent their credentials, so anyone sniffing would be able to get them). > There used to be a well-known howto for all this at > http://www.bayour.com/LDAPv3-HOWTO.html but the site is offline for some > days now. This howto is completely wrong, and the various folks have asked the author to take it down for years. I'm glad to hear it is not accessible. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: virtual view strategies: replying differently to different clients
by Pierangelo Masarati 07 Sep '08

07 Sep '08

----- "Aaron Richton" <richton(a)nbcs.rutgers.edu> wrote: > On Fri, 25 Jul 2008, Guillaume Rousse wrote: > > > First, using a distinct database doesn't allow to provide a virtual > view > > from a branch in my original database to another branch in the same > > database. Meaning, I can't have ou=telephony,dc=myprefix a virtual > view > > of ou=users,dc=myprefix, I need to use a distinct prefix. > > Have you tried declaring the ou=telephony,dc=myprefix back-relay > subordinate to dc=myprefix back-$END? I was about to reply the same, but you anticipated me :) I've tried the above, and it works as expected as soon as the "relay" statement is omitted. In fact, it requires the superior database to already exist. Probably, that test should either be relaxed or moved to db_open(). With respect to Guillaume's second question, I see the issue. In principle, what he needs to do is something like rwm-map attribute telephoneNumber homePhone rwm-map attribute * telephoneNumber so that real homePhone is mapped to virtual telephoneNumber, and real telephoneNumber is hidden. Unfortunately, this seems to result in a "double mapping" for telephoneNumber. I need to look at the logic of mapping, since what Guillaume wants to do seems to make sense, so it should be allowed. As per the reason of hiding everything not working, it's related to the fact that hiding everything does not allow "objectClass" to be returned, which causes the search filter to fail because the objectClass is not present. Unfortunately, the objectClass attribute cannot be mapped, so it cannot be explicitly preserved by adding rwm-map attribute objectClass * I recommend he files an ITS for each of those two issues. > > Third, this solution doesn't work currently when trying to sync > > the appliance users from ldap. From ldap log, it seems some > specific > > control is not supported with relay backend: > > I think you'd be better served by syncing the real data, and > configuring > the back-relay/slapo-rwm identically across your slaves so as to give > > consistent results. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

2 4

Problem with tls connections
by Norman Gies 07 Sep '08

07 Sep '08

Hello, i have a problem with tls connections to my openldap server. The openldap server is running on debian. I created all certificates with openssl. If I use ldapsearch on the server (SASL//EXTERNAL mech/) everything works fine, but if i try to connect with jxplorer, ldapbrowser (softera), eclipse (apache directoy), or with the examples from jldap, i always got the same error: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake This is the log from the openldap server. Sep 5 08:18:33 domain slapd[1770]: slapd starting Sep 5 08:18:33 domain slapd[1770]: daemon: added 4r listener=(nil) Sep 5 08:18:33 domain slapd[1770]: daemon: added 6r listener=0x8129238 Sep 5 08:18:33 domain slapd[1770]: daemon: added 7r listener=0x8129300 Sep 5 08:18:33 domain slapd[1770]: daemon: select: listen=6 active_threads=0 tvp=NULL Sep 5 08:18:33 domain slapd[1770]: daemon: select: listen=7 active_threads=0 tvp=NULL Sep 5 08:20:46 domain slapd[1770]: daemon: activity on 1 descriptor Sep 5 08:20:46 domain slapd[1770]: >>> slap_listener(ldap:///) Sep 5 08:20:46 domain slapd[1770]: daemon: listen=7, new connection on 12 Sep 5 08:20:46 domain slapd[1770]: daemon: added 12r (active) listener=(nil) Sep 5 08:20:46 domain slapd[1770]: conn=0 fd=12 ACCEPT from IP=192.168.0.2:2578 (IP=0.0.0.0:389) Sep 5 08:20:46 domain slapd[1770]: daemon: select: listen=6 active_threads=0 tvp=NULL Sep 5 08:20:46 domain slapd[1770]: daemon: select: listen=7 active_threads=0 tvp=NULL Sep 5 08:20:46 domain slapd[1770]: daemon: activity on 1 descriptor Sep 5 08:20:46 domain slapd[1770]: daemon: activity on: Sep 5 08:20:46 domain slapd[1770]: 12r Sep 5 08:20:46 domain slapd[1770]: Sep 5 08:20:46 domain slapd[1770]: daemon: read activity on 12 Sep 5 08:20:46 domain slapd[1770]: connection_get(12) Sep 5 08:20:46 domain slapd[1770]: connection_get(12): got connid=0 Sep 5 08:20:46 domain slapd[1770]: connection_read(12): checking for input on id=0 Sep 5 08:20:46 domain slapd[1770]: ber_get_next on fd 12 failed errno=0 (Success) Sep 5 08:20:46 domain slapd[1770]: connection_read(12): input error=-2 id=0, closing. Sep 5 08:20:46 domain slapd[1770]: connection_closing: readying conn=0 sd=12 for close Sep 5 08:20:46 domain slapd[1770]: connection_close: conn=0 sd=-1 Sep 5 08:20:46 domain slapd[1770]: daemon: removing 12 Sep 5 08:20:46 domain slapd[1770]: conn=0 fd=12 closed (connection lost) Sep 5 08:20:46 domain slapd[1770]: daemon: select: listen=6 active_threads=0 tvp=NULL Sep 5 08:20:46 domain slapd[1770]: daemon: select: listen=7 active_threads=0 tvp=NULL Sep 5 08:20:46 domain slapd[1770]: daemon: activity on 1 descriptor Sep 5 08:20:46 domain slapd[1770]: daemon: waked Sep 5 08:20:46 domain slapd[1770]: daemon: select: listen=6 active_threads=0 tvp=NULL Sep 5 08:20:46 domain slapd[1770]: daemon: select: listen=7 active_threads=0 tvp=NULL What the meaning of the two lines ber_get_next on fd 12 failed errno=0 (Success) connection_read(12): input error=-2 id=0, closing. Sorry for my bad english. thx for help. Any help or pointers would be appreciated. Thanks. Norman

2 1

Compilation on OpenVMS
by Senn, Michael - Acision 06 Sep '08

06 Sep '08

Good Morning, I am currently involved in an investigation to start using OpenLDAP on OpenVMS within our company. Part of this investigation has been digging through the mail lists, I find that there were some questions about compilation on OpenVMS back between 2000 and 2003. Since then it appears to have gone quiet. At the end of the initial questions there was no definitive answer that I was able to find for the following questions: Has anyone successfully compiled OpenLDAP on OpenVMS, the release 2.4 is preferred? An additional question is that since OpenVMS is in the config.guess file is this a start point or does it mean that compilation is supported out of the box? Thanks Michael Senn 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

openldap nightmare
by John Nietzsche 05 Sep '08

05 Sep '08

Dear members, I was trying to use slapd with configurations within itself, i mean: not using /etc/openldap/slapd.conf. Since i could not get authentication working i decided to switch configuration to /etc/opendalp/slapd.conf, and everything worked. My doube is what kinf of error i am doing ? Could some tell me? Here is my ldap.ldif: ################################# # # # Global configuration settings # # # ################################# dn: cn=config objectClass: olcGlobal cn: config olcIdleTimeout: 64 olcLogLevel: -1 olcReferral: ldap://root.openldap.org ############################ # # # Included file directives # # # ############################ dn: cn=include{0},cn=config objectClass: olcIncludeFile cn: include{0} olcInclude: /etc/openldap/schema/core.schema dn: cn=include{1},cn=config objectClass: olcIncludeFile cn: include{1} olcInclude: /etc/openldap/schema/cosine.schema dn: cn=include{2},cn=config objectClass: olcIncludeFile cn: include{2} olcInclude: /etc/openldap/schema/corba.schema dn: cn=include{3},cn=config objectClass: olcIncludeFile cn: include{3} olcInclude: /etc/openldap/schema/dyngroup.schema dn: cn=include{4},cn=config objectClass: olcIncludeFile cn: include{4} olcInclude: /etc/openldap/schema/inetorgperson.schema dn: cn=include{5},cn=config objectClass: olcIncludeFile cn: include{5} olcInclude: /etc/openldap/schema/java.schema dn: cn=include{6},cn=config objectClass: olcIncludeFile cn: include{6} olcInclude: /etc/openldap/schema/misc.schema dn: cn=include{7},cn=config objectClass: olcIncludeFile cn: include{7} olcInclude: /etc/openldap/schema/nis.schema dn: cn=include{8},cn=config objectClass: olcIncludeFile cn: include{8} olcInclude: /etc/openldap/schema/openldap.schema dn: cn=include{9},cn=config objectClass: olcIncludeFile cn: include{9} olcInclude: /etc/openldap/schema/ppolicy.schema ############################################################### # # # If openldap was compiled with support for modules, then ... # # # ############################################################### dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/local/libexec/openldap olcModuleLoad: back_ldbm.la #dn: cn=module{1},cn=config #objectClass: olcModuleList #cn: module{1} #olcModulePath: /usr/local/libexec/openldap #olcModuleLoad: back_ldap.la ################ # # # Schema entry # # # ################ dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: cn=schema #################### # # # Backend # # # #################### dn: olcBackend=ldbm,cn=config objectClass: olcBackendConfig olcBackend: ldbm ############# # # # Databases # # # ############# dn: olcDatabase=ldbm,cn=config objectClass: olcDatabaseConfig objectClass: olcLdbmConfig olcDatabase: ldbm olcSuffix: "dc=cpd,dc=ufv,dc=br" olcDbDirectory: /asd/var/ldap olcDbIndex: objectClass eq olcAccess: to * by users read olcRootDN: "cn=Manager,dc=cpd,dc=ufv,dc=br" olcRootPW: {SSHA}q1mH0pWNnHF0+K4hV5yOV4I7p/VfIIYs END OF ldap.ldif Now, my slapd.conf sioux@etosha$ cat /etc/openldap/slapd.conf # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/core.schema # Define global ACLs to disable default read access. # 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 # Load dynamic backend modules: modulepath /usr/local/libexec/openldap # moduleload back_bdb.la moduleload back_ldap.la moduleload back_ldbm.la # moduleload back_passwd.la # moduleload back_shell.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ####################################################################### # BDB database definitions ####################################################################### database ldbm suffix "dc=cpd,dc=ufv,dc=br" rootdn "cn=Manager,dc=cpd,dc=ufv,dc=br" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw {SSHA}q1mH0pWNnHF0+K4hV5yOV4I7p/VfIIYs # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/openldap-data # Indices to maintain index objectClass eq OpenLDAP works if i am using the slapd.conf, but if i choose -F /x/y/z it does not work. Thanks a lot for your time and cooperation, best regards

5 4

Re: (ITS#5545) Inconsistency in multi-master setup
by Gavin Henry 05 Sep '08

05 Sep '08

Not at all. Don't worry about it. ----- "ST Wong (ITSC)" <ST(a)itsc.cuhk.edu.hk> wrote: > Get it. Sorry for the trouble caused, and thanks a lot. > > Best Regards, > /ST Wong > > -----Original Message----- > From: Gavin Henry [mailto:ghenry@suretecsystems.com] > Sent: Friday, September 05, 2008 2:58 AM > To: ST Wong (ITSC) > Cc: openldap-its(a)openldap.org > Subject: Re: (ITS#5545) Inconsistency in multi-master setup > > ST(a)itsc.cuhk.edu.hk wrote: > > Oops, I tested on both nodes, which is not supposed to do so in > > mirrormode, right? Sorry for the trouble caused. > > > > Thanks. > > > > > > Not at the same time, no. The point is to have one node available to > the > clients at one time and the other in hot standby, whereby your > network > infrastructure redirects clients if one node goes down etc. > > -- > Kind Regards, > > Gavin Henry. > Managing Director. > > T +44 (0) 1224 279484 > M +44 (0) 7930 323266 > F +44 (0) 1224 824887 > E ghenry(a)suretecsystems.com > > Open Source. Open Solutions(tm). > > http://www.suretecsystems.com/ > > Suretec Systems is a limited company registered in Scotland. > Registered > number: SC258005. Registered office: 13 Whiteley Well Place, > Inverurie, > Aberdeenshire, AB51 4FP. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software