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
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=*
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
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.yahoo.com.mx/
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
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 :
- overlays configuration$
I'm using OpenLDAP 2.4.11 compiled from source on RHEL4U5.
Thanks in advance for any answer,
Sincerely yours, Mathieu MILLET.
> 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.
> 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
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
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
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
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
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
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
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.
Any help will be appreciated.
MRV Communications, Inc.
295 Foster Street
Littleton, MA. 01460
> Re-read what the slap.conf(5) man page says.
That's unhelpful. It's of course, already been read.
minssf=<factor> property specifies the minimum acceptable security
maxssf=<factor> property specifies the maximum acceptable security
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.
In 'man slapd.conf',
... 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
SASL SSF: 56
(2) sasl-secprops noanonymous,noplain,noactive,minssf=128
SASL SSF: 56
(3) sasl-secprops noanonymous,noplain,noactive,minssf=128,maxssf=256
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?
I fell across a 2-year old, seemingly-relevant post:
"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?
--On Monday, September 08, 2008 9:26 PM +0200 Hauke Coltzau
> 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.
Principal Software Engineer
Zimbra :: the leader in open source messaging and collaboration
----- "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
> > 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
> > 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
> > control is not supported with relay backend:
> I think you'd be better served by syncing the real data, and
> the back-relay/slapo-rwm identically across your slaves so as to give
> consistent results.
Ing. Pierangelo Masarati
OpenLDAP Core Team
via Dossi, 8 - 27100 Pavia - ITALIA
Office: +39 02 23998309
Mobile: +39 333 4963172
Fax: +39 0382 476497