openldap-software September 2008

openldap-software@openldap.org

60 participants
64 discussions

Implementing monitor in DB ldap existent
by Reynaldo Quezada V. 10 Sep '08

10 Sep '08

Hi to everybody! I have a DB Openldap that is OK, but I going to implement monitor. I learn the domumentation slapd-monitor and followed the steeps 1.- add to the slapd.conf database monitor 2.- I configured the ACL's access to dn.subtree="cn=Monitor" by dn.base="cn=Manager,dc=ife.org.mx" write by users read by * read 3.- Check the core.schema is OK But I start the service, made some changes to the users and search the results of the monitoring... ldapsearch -LLL -x -b "cn=Modify,cn=Operations,cn=Monitor" -H ldaps://ldap.resource.net objectclass=* The result: dn: cn=Modify,cn=Operations,cn=Monitor objectClass: monitorOperation cn: Modify Idon't see nothing about the changes that I realized in the monitoring... Is the correct form to start the monitoring in a DB ldap existent? thanks a lot for you help __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.yahoo.com.mx/

3 3

2-way Multimaster replication (including configuration) and TLS certificate
by Mathieu MILLET 10 Sep '08

10 Sep '08

Hi everyone, I was able to make a 2-way Multimaster replication (including configuration) with TLS, by specifying "manually" the certificate (and key) for the 2nd server (certificate different from the 1st server). The servers replicated, OK. But after the "first replication", the cn=config of the 2nd now contains the TLSCertificateFile and TLSCertificateKeyFile of the 1st server, which is point less. The 2nd server can't now start, because it can't find its certificate (and key), which is normal ... Is it possible to specify "multiple" certificates in the cn=config file ? Or should I go with using alternateSubjectAltName in certificates (which is not pretty) ? I would really want to go to multimaster for configuration for the following (source of typing faults) elements : - authz-regexp - schema - acl - overlays configuration$ I'm using OpenLDAP 2.4.11 compiled from source on RHEL4U5. Thanks in advance for any answer, Sincerely yours, Mathieu MILLET. -- Mathieu MILLET mailto:ldap@htam.net -- -- Mathieu MILLET mailto:ldap@htam.net

2 2

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

10 Sep '08

> No where does it say there that it sets the minimum SSF of connections. Stating what it doesn't say is unhelpful. My question is posed because of my misunderstanding of what is does say. > It > says it specifies the minimum or maximum acceptable SSF. I.e., if you set > the minimum SSF to 128, and an incoming connection only uses 56, then XYZ > won't be usable. The distinction between "minimum SSF" and "minimum acceptable SSF" is somewhat non-obvious, and still lost on me. > I've generally used this type of restriction more with ACLs, such as: > > by dn.base="cn=xyz,dc=example,dc=com" sasl_ssf=56 read There's no mention of 'sasl_ssf' in 'man slapd.conf'; Rather, only in 'man slapd.access'. Where, it states: sasl_ssf=<n> set the minimum required Security Strength Factor (ssf) needed to grant access On the 'man slapd.conf' page, minssf=<factor> property specifies the minimum acceptable security strength factor as an integer approximate to effective key length used for encryption Again, the difference is completely unclear. Perhaps someone else might take a helpful stab at clarifying the diff? In the context of my originally posted question, rephrased: Why does *addition* of "maxssf=256" (the maximum acceptable security strength factor) to "sasl-secprops ..." cause the 'SASL SSF' reported "ldapwhoami -ZZ" to change from SASL SSF: 56 --> SASL SSF: 0 ?

2 1

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 08 Sep '08

08 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software September 2008