Implementing monitor in DB ldap existent
by Reynaldo Quezada V.
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/
15 years
2-way Multimaster replication (including configuration) and TLS certificate
by Mathieu MILLET
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
15 years
Re: sasl-secprops' minssf not setting SASL SSF correctly
by PGNet
> 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
?
15 years
delta-syncrepl, accesslog logpurge, slapadd -w problem
by David Hawes
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.
15 years
Problem with 2.4.11 configure
by Philip Bellino
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/>
15 years
Re: sasl-secprops' minssf not setting SASL SSF correctly
by PGNet
> 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.
15 years
sasl-secprops' minssf not setting SASL SSF correctly
by PGNet
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?
15 years
Re: AW: Re: AW: Re: SASL bind with Kerberos: (was: Simple binds with SASL/GSSAPI (Resource temporarily unavailable))
by Quanah Gibson-Mount
--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
15 years
Re: virtual view strategies: replying differently to different clients
by Pierangelo Masarati
----- "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
-----------------------------------
15 years
Problem with tls connections
by Norman Gies
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
15 years
