using slapo-pcache with an empty attr list
by Toby Blake
Hi all,
I'm doing a bit of playing with slapo-pcache and have it working
fairly well (particularly once I realised that an individual attr can
live in only one proxyattrset).
However, there's one bit that I can't get working - is there any way
to define a template that will match a search which doesn't provide an
attr list?
i.e. I can see quite a few searches (presumably from amd) of the
following form (spacing and formatting changed by me to make it more
readable):
Jul 23 14:54:16 host1 slapd[26671]: conn=49 op=1
SRCH base="dc=inf,dc=ed,dc=ac,dc=uk" scope=2 deref=0
filter="(&(objectClass=amdmap)(amdmapName=home)(amdmapKey=root))"
Jul 23 14:54:16 host1 slapd[26671]: query template of incoming query =
(&(objectClass=)(amdmapName=)(amdmapKey=))
Jul 23 14:54:16 host1 slapd[26671]: QUERY NOT ANSWERABLE
Jul 23 14:54:16 host1 slapd[26671]: QUERY NOT CACHEABLE
Jul 23 14:54:16 host1 slapd[26671]: conn=49 op=1 SEARCH RESULT tag=101
err=0 nentries=0 text=
Note that there's no 'SRCH attr=' line.
I've tried proxyattrset of the following forms...
proxyattrset 1 *
proxyattrset 1
(both of which crash slapd)
And also
proxyattrset 1 <full list of attrs returned when none specified>
.... but this didn't work either.
Thanks in advance for any advice,
Cheers
Toby Blake
School of Informatics
University of Edinburgh
14 years, 12 months
delta-syncrepl replica out of date
by Francis Swasey
I have a master and nine delta-syncrepl replicas all running on RHEL 4
using OpenLDAP 2.3.38 on the master and all replicas.
The master is configured to purge entries from the accesslog after 12
hours (and checks every 2 hours). I forget where I grabbed that from
why I used it.
Anyway, I have discovered that if one of the replicas gets more than 12
hours behind (ie, is shutdown or we reload the database from yesterday),
that it will grab all the updates that have happened in the last 12
hours and then the CSN of the replica and the master will be in
agreement, but the changes that happened more than the 12 hours (of the
accesslog) ago are not present on the replica.
Is this a configuration mistake I have made (other than setting the
accesslog purge time to 12 hours) or is this a limitation (that I likely
knew at one time and then forgot and now have relearned the hard way)?
Is there an option I can set on the replica's so they will refuse to
start if their CSN is older than the oldest record in the accesslog of
the master when they start up?
If this has been discussed in the past, I'm sorry, I did search, but not
certain of the terms to use, I didn't have any luck finding anything
that looked promising.
Here's the relevant parts of the master's slapd.conf
database hdb
suffix cn=accesslog
directory /var/lib/ldap/accesslog
rootdn cn=accesslog
checkpoint 1024 5
index default eq
index entryCSN,objectClass,reqEnd,reqResult,reqStart
overlay syncprov
syncprov-nopresent TRUE
syncprov-reloadhint TRUE
database bdb
suffix dc=example,dc=com
...
overlay syncprov
syncprov-checkpoint 1000 60
overlay accesslog
logdb cn=accesslog
logops writes
logsuccess TRUE
logpurge 12:00 02:00
And from the replica's:
database bdb
suffix dc=example,dc=com
...
syncrepl rid=100
provider=ldaps://ldaprw.example.com
bindmethod=simple
binddn="cn=MySyncUser,dc=example,dc=com"
credentials=NotMyRealPassword
searchbase="dc=example,dc=com"
logbase="cn=accesslog"
logfilter="(&(objectclass=auditWriteObject)(reqResult=0))"
schemachecking=on
type=refreshAndPersist
retry=30,+
syncdata=accesslog
Thanks,
--
Frank Swasey | http://www.uvm.edu/~fcs
Sr Systems Administrator | Always remember: You are UNIQUE,
University of Vermont | just like everyone else.
"I am not young enough to know everything." - Oscar Wilde (1854-1900)
15 years, 6 months
OpenLDAP at Systems Munich
by Dieter Kluenter
Hi,
as in the past few years OpenLDAP will be present at the Systems,
Munich, http://www.systems-world.de/
as part of Open Source Community booth. We (Peter Gietz and me) are in
need of *volunteers* to man the booth. Whoever is willing to join the
team may contact either Peter Gietz or me asap.
-Dieter
--
Dieter Klünter | Systemberatung
http://www.dkluenter.de
GPG Key ID:8EF7B6C6
15 years, 6 months
OpenLDAP 2.4
by Howard Chu
The Admin Guide still has not been updated with all of the relevant changes,
so here are some notes on new features in the 2.4 release... I believe all of
the manpages are up to date, so you can get specifics from them.
More complete cn=config functionality:
There is a new slapd-config(5) manpage for the cn=config backend.
the original design called for auto-renaming of config entries when you
insert or delete entries with ordered names, but that was not implemented in
2.3. It is now in 2.4. This means, e.g., if you have
olcDatabase={1}bdb,cn=config
olcSuffix: dc=example,dc=com
and you want to add a new subordinate, now you can:
ldapadd olcDatabase={1}bdb,cn=config
olcSuffix: dc=foo,dc=example,dc=com
this will insert a new BDB database in slot 1 and bump all following
databases down one, so the original BDB database will now be named
olcDatabase={2}bdb,cn=config
olcSuffix: dc=example,dc=com
In 2.3 you were only able to add new schema elements, not delete or
modify existing elements. In 2.4 you can modify schema at will. (Except for
the hardcoded system schema, of course.)
More sophisticated syncrepl configurations:
the original implementation of syncrepl in OpenLDAP 2.2 was intended to
support multiple consumers within the same database, but that feature never
worked and was removed from OpenLDAP 2.3. I.e., you could only configure a
single consumer in any database.
In 2.4 you can configure multiple consumers in a single database. The
configuration possibilities here are quite complex and numerous. You can
configure consumers over arbitrary subtrees of a database (disjoint or
overlapping). Any portion of the database may in turn be provided to other
consumers using the syncprov overlay. The syncprov overlay works with any
number of consumers over a single database or over arbitrarily many glued
databases.
As a consequence of the work to support multiple consumer contexts, the
syncrepl system now supports full N-way multimaster replication with
entry-level conflict resolution. There are some important constraints, of
course: In order to maintain consistent results across all servers, you must
maintain tightly synchronized clocks across all participating servers (e.g.,
you must use NTP on all servers). The entryCSNs used for replication now
record timestamps with microsecond resolution, instead of just seconds. The
delta-syncrepl code has not been updated to support multimaster usage yet,
that will come later in the 2.4 cycle.
On a related note, syncrepl was explicitly disabled on cn=config in 2.3.
It is now fully supported in 2.4; you can use syncrepl to replicate an entire
server configuration from one server to arbitrarily many other servers. It's
possible to clone an entire running slapd using just a small (less than 10
lines) seed configuration, or you can just replicate the schema subtrees,
etc. Tests 049 and 050 in the test suite provide working examples of these
capabilities.
In 2.3 you could configure syncrepl as a full push-mode replicator by
using it in conjunction with a back-ldap pointed at the target server. But
because the back-ldap database needs to have a suffix corresponding to the
target's suffix, you could only configure one instance per slapd.
In 2.4 you can define a database to be "hidden" which means that its
suffix is ignored when checking for name collisions, and the database will
never be used to answer requests received by the frontend. Using this hidden
database feature allows you to configure multiple databases with the same
suffix, allowing you to set up multiple back-ldap instances for pushing
replication of a single database to multiple targets. There may be other uses
for hidden databases as well (e.g., using a syncrepl consumer to maintain a
*local* mirror of a database on a separate filesystem).
More extensive TLS configuration control:
In 2.3, the TLS configuration in slapd was only used by the slapd
listeners. For outbound connections used by e.g. back-ldap or syncrepl their
TLS parameters came from the system's ldap.conf file.
In 2.4 all of these sessions inherit their settings from the main slapd
configuration but settings can be individually overridden on a
per-config-item basis. This is particularly helpful if you use
certificate-based authentication and need to use a different client
certificate for different destinations.
Various performance enhancements:
Too many to list. Some notable changes - ldapadd used to be a couple of
orders of magnitude slower than "slapadd -q". It's now at worst only about
half the speed of slapadd -q. A few weeks ago I did some comparisons of all
the 2.x OpenLDAP releases; the results are in the slides from my SCALE
presentation and you can find a copy here:
http://www.highlandsun.com/hyc/scale2007.pdf
That compared 2.0.27, 2.1.30, 2.2.30, 2.3.33, and HEAD (as of a couple
weeks ago). Toward the latter end of the "Cached Search Performance" chart it
gets hard to see the difference because the runtimes are so small, but the
new code is about 25% faster than 2.3, which was about 20% faster than 2.2,
which was about 100% faster than 2.1, which was about 100% faster than 2.0,
in that particular search scenario. That test basically searched a 1.3GB DB
of 380836 entries (all in the slapd entry cache) in under 1 second. i.e., on
a 2.4GHz CPU with DDR400 ECC/Registered RAM we can search over 500 thousand
entries per second. The search was on an unindexed attribute using a filter
that would not match any entry, forcing slapd to examine every entry in the
DB, testing the filter for a match.
Essentially the slapd entry cache in back-bdb/back-hdb is so efficient
the search processing time is almost invisible; the runtime is limited only
by the memory bandwidth of the machine. (The search data rate corresponds to
about 3.5GB/sec; the memory bandwidth on the machine is only about 4GB/sec
due to ECC and register latency.)
I think it goes without saying that no other Directory Server in the world is
this fast or this efficient. Couple that with the scalability, manageability,
flexibility, and just the sheer know-how behind this software, and nothing
else is even remotely comparable.
--
-- 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/
15 years, 6 months
LDAP provisioning error.
by Sanjay Vivek
Hello everyone,
I'm involved in a project whereby access groups (with users) are
provisioned to a LDAP server. In a nutshell, the groups should be
provisioned under ""ou=groups,dc=ncl,dc=ac,dc=uk" while the users in
each group are found in ""ou=people,dc=ncl,dc=ac,dc=uk". However, the
groups are not being provisioned over to our LDAP server. Among the
dubious looking lines in the log files include:
bdb_search: 134 does not match filter
(the above entry should match the filter. And similiarly for other
entries)
I'm guessing this has something to do with the ACL control list in
slapd.conf. The relevant section in slapd.conf is given below:
# Allow anyone to write and read to ou=people
access to dn.one="ou=people,dc=ncl,dc=ac,dc=uk"
attr=children
by anonymous read
by anonymous write
# Allow anyone to write and read to ou=grouper
access to dn.one="ou=grouper,dc=ncl,dc=ac,dc=uk"
attr=children
by anonymous read
by anonymous write
So basically what the above configuration is meant to do is that anyone
can read or write to one level below both people and grouper. I realise
this is highly insecure but it's merely for testing purposes.
Any suggestions or help would be greatly appreciated. The complete logs
of this transaction is given below. Thanks again.
Cheers
Sanjay
Oct 16 15:13:34 pen slapd[9559]: daemon: activity on 1 descriptor
Oct 16 15:13:34 pen slapd[9559]: daemon: activity on:
Oct 16 15:13:34 pen slapd[9559]:
Oct 16 15:13:34 pen slapd[9559]: daemon: listen=8, new connection on 13
Oct 16 15:13:34 pen slapd[9559]: daemon: added 13r
Oct 16 15:13:34 pen slapd[9559]: conn=8 fd=13 ACCEPT from
IP=128.240.2.3:51855 (IP=0.0.0.0:389)
Oct 16 15:13:34 pen slapd[9559]: daemon: select: listen=7
active_threads=0 tvp=NULL
Oct 16 15:13:34 pen slapd[9559]: daemon: select: listen=8
active_threads=0 tvp=NULL
Oct 16 15:13:34 pen slapd[9559]: daemon: activity on 1 descriptor
Oct 16 15:13:34 pen slapd[9559]: daemon: activity on:
Oct 16 15:13:34 pen slapd[9559]: 13r
Oct 16 15:13:34 pen slapd[9559]:
Oct 16 15:13:34 pen slapd[9559]: daemon: read active on 13
Oct 16 15:13:34 pen slapd[9559]: connection_get(13)
Oct 16 15:13:34 pen slapd[9559]: connection_get(13): got connid=8
Oct 16 15:13:34 pen slapd[9559]: connection_read(13): checking for input
on id=8
Oct 16 15:13:34 pen slapd[9559]: ber_get_next on fd 13 failed errno=11
(Resource temporarily unavailable)
Oct 16 15:13:34 pen slapd[9559]: daemon: select: listen=7
active_threads=0 tvp=NULL
Oct 16 15:13:34 pen slapd[9559]: daemon: select: listen=8
active_threads=0 tvp=NULL
Oct 16 15:13:34 pen slapd[9559]: do_bind
Oct 16 15:13:34 pen slapd[9559]: >>> dnPrettyNormal:
<cn=Manager,dc=ncl,dc=ac,dc=uk>
Oct 16 15:13:34 pen slapd[9559]: <<< dnPrettyNormal:
<cn=Manager,dc=ncl,dc=ac,dc=uk>, <cn=manager,dc=ncl,dc=ac,dc=uk>
Oct 16 15:13:34 pen slapd[9559]: do_bind: version=3
dn="cn=Manager,dc=ncl,dc=ac,dc=uk" method=128
Oct 16 15:13:34 pen slapd[9559]: conn=8 op=0 BIND
dn="cn=Manager,dc=ncl,dc=ac,dc=uk" method=128
Oct 16 15:13:34 pen slapd[9559]: ==> bdb_bind: dn:
cn=Manager,dc=ncl,dc=ac,dc=uk
Oct 16 15:13:34 pen slapd[9559]: conn=8 op=0 BIND
dn="cn=Manager,dc=ncl,dc=ac,dc=uk" mech=SIMPLE ssf=0
Oct 16 15:13:34 pen slapd[9559]: do_bind: v3 bind:
"cn=Manager,dc=ncl,dc=ac,dc=uk" to "cn=Manager,dc=ncl,dc=ac,dc=uk"
Oct 16 15:13:34 pen slapd[9559]: send_ldap_result: conn=8 op=0 p=3
Oct 16 15:13:34 pen slapd[9559]: send_ldap_result: err=0 matched=""
text=""
Oct 16 15:13:34 pen slapd[9559]: send_ldap_response: msgid=1 tag=97
err=0
Oct 16 15:13:34 pen slapd[9559]: conn=8 op=0 RESULT tag=97 err=0 text=
Oct 16 15:13:34 pen slapd[9559]: daemon: activity on 1 descriptor
Oct 16 15:13:34 pen slapd[9559]: daemon: activity on:
Oct 16 15:13:34 pen slapd[9559]:
Oct 16 15:13:34 pen slapd[9559]: daemon: listen=8, new connection on 15
Oct 16 15:13:34 pen slapd[9559]: daemon: added 15r
Oct 16 15:13:34 pen slapd[9559]: conn=9 fd=15 ACCEPT from
IP=128.240.2.3:36766 (IP=0.0.0.0:389)
Oct 16 15:13:34 pen slapd[9559]: daemon: select: listen=7
active_threads=0 tvp=NULL
Oct 16 15:13:34 pen slapd[9559]: daemon: select: listen=8
active_threads=0 tvp=NULL
Oct 16 15:13:34 pen slapd[9559]: daemon: activity on 1 descriptor
Oct 16 15:13:34 pen slapd[9559]: daemon: activity on:
Oct 16 15:13:34 pen slapd[9559]: 15r
Oct 16 15:13:34 pen slapd[9559]:
Oct 16 15:13:34 pen slapd[9559]: daemon: read active on 15
Oct 16 15:13:34 pen slapd[9559]: connection_get(15)
Oct 16 15:13:34 pen slapd[9559]: connection_get(15): got connid=9
Oct 16 15:13:34 pen slapd[9559]: connection_read(15): checking for input
on id=9
Oct 16 15:13:34 pen slapd[9559]: ber_get_next on fd 15 failed errno=11
(Resource temporarily unavailable)
Oct 16 15:13:34 pen slapd[9559]: daemon: select: listen=7
active_threads=0 tvp=NULL
Oct 16 15:13:34 pen slapd[9559]: daemon: select: listen=8
active_threads=0 tvp=NULL
Oct 16 15:13:34 pen slapd[9559]: do_bind
Oct 16 15:13:34 pen slapd[9559]: >>> dnPrettyNormal:
<cn=Manager,dc=ncl,dc=ac,dc=uk>
Oct 16 15:13:34 pen slapd[9559]: <<< dnPrettyNormal:
<cn=Manager,dc=ncl,dc=ac,dc=uk>, <cn=manager,dc=ncl,dc=ac,dc=uk>
Oct 16 15:13:34 pen slapd[9559]: do_bind: version=3
dn="cn=Manager,dc=ncl,dc=ac,dc=uk" method=128
Oct 16 15:13:34 pen slapd[9559]: conn=9 op=0 BIND
dn="cn=Manager,dc=ncl,dc=ac,dc=uk" method=128
Oct 16 15:13:34 pen slapd[9559]: ==> bdb_bind: dn:
cn=Manager,dc=ncl,dc=ac,dc=uk
Oct 16 15:13:34 pen slapd[9559]: conn=9 op=0 BIND
dn="cn=Manager,dc=ncl,dc=ac,dc=uk" mech=SIMPLE ssf=0
Oct 16 15:13:34 pen slapd[9559]: do_bind: v3 bind:
"cn=Manager,dc=ncl,dc=ac,dc=uk" to "cn=Manager,dc=ncl,dc=ac,dc=uk"
Oct 16 15:13:34 pen slapd[9559]: send_ldap_result: conn=9 op=0 p=3
Oct 16 15:13:34 pen slapd[9559]: send_ldap_result: err=0 matched=""
text=""
Oct 16 15:13:34 pen slapd[9559]: send_ldap_response: msgid=1 tag=97
err=0
Oct 16 15:13:34 pen slapd[9559]: conn=9 op=0 RESULT tag=97 err=0 text=
Oct 16 15:13:34 pen slapd[9559]: daemon: activity on 1 descriptor
Oct 16 15:13:34 pen slapd[9559]: daemon: activity on:
Oct 16 15:13:34 pen slapd[9559]: 15r
Oct 16 15:13:34 pen slapd[9559]:
Oct 16 15:13:34 pen slapd[9559]: daemon: read active on 15
Oct 16 15:13:34 pen slapd[9559]: connection_get(15)
Oct 16 15:13:34 pen slapd[9559]: connection_get(15): got connid=9
Oct 16 15:13:34 pen slapd[9559]: connection_read(15): checking for input
on id=9
Oct 16 15:13:34 pen slapd[9559]: ber_get_next on fd 15 failed errno=0
(Success)
Oct 16 15:13:34 pen slapd[9559]: connection_read(15): input error=-2
id=9, closing.
Oct 16 15:13:34 pen slapd[9559]: connection_closing: readying conn=9
sd=15 for close
Oct 16 15:13:34 pen slapd[9559]: connection_close: deferring conn=9
sd=15
Oct 16 15:13:34 pen slapd[9559]: daemon: select: listen=7
active_threads=0 tvp=NULL
Oct 16 15:13:34 pen slapd[9559]: daemon: select: listen=8
active_threads=0 tvp=NULL
Oct 16 15:13:34 pen slapd[9559]: daemon: activity on 1 descriptor
Oct 16 15:13:34 pen slapd[9559]: daemon: activity on:
Oct 16 15:13:34 pen slapd[9559]:
Oct 16 15:13:34 pen slapd[9559]: daemon: select: listen=7
active_threads=0 tvp=NULL
Oct 16 15:13:34 pen slapd[9559]: daemon: select: listen=8
active_threads=0 tvp=NULL
Oct 16 15:13:34 pen slapd[9559]: do_unbind
Oct 16 15:13:34 pen slapd[9559]: conn=9 op=1 UNBIND
Oct 16 15:13:34 pen slapd[9559]: connection_resched: attempting closing
conn=9 sd=15
Oct 16 15:13:34 pen slapd[9559]: connection_close: conn=9 sd=15
Oct 16 15:13:34 pen slapd[9559]: daemon: removing 15
Oct 16 15:13:34 pen slapd[9559]: conn=9 fd=15 closed
Oct 16 15:13:35 pen slapd[9559]: daemon: activity on 1 descriptor
Oct 16 15:13:35 pen slapd[9559]: daemon: activity on:
Oct 16 15:13:35 pen slapd[9559]:
Oct 16 15:13:35 pen slapd[9559]: daemon: listen=8, new connection on 15
Oct 16 15:13:35 pen slapd[9559]: daemon: added 15r
Oct 16 15:13:35 pen slapd[9559]: conn=10 fd=15 ACCEPT from
IP=128.240.2.3:50097 (IP=0.0.0.0:389)
Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=7
active_threads=0 tvp=NULL
Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=8
active_threads=0 tvp=NULL
Oct 16 15:13:35 pen slapd[9559]: daemon: activity on 1 descriptor
Oct 16 15:13:35 pen slapd[9559]: daemon: activity on:
Oct 16 15:13:35 pen slapd[9559]: 15r
Oct 16 15:13:35 pen slapd[9559]:
Oct 16 15:13:35 pen slapd[9559]: daemon: read active on 15
Oct 16 15:13:35 pen slapd[9559]: connection_get(15)
Oct 16 15:13:35 pen slapd[9559]: connection_get(15): got connid=10
Oct 16 15:13:35 pen slapd[9559]: connection_read(15): checking for input
on id=10
Oct 16 15:13:35 pen slapd[9559]: ber_get_next on fd 15 failed errno=11
(Resource temporarily unavailable)
Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=7
active_threads=0 tvp=NULL
Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=8
active_threads=0 tvp=NULL
Oct 16 15:13:35 pen slapd[9559]: do_bind
Oct 16 15:13:35 pen slapd[9559]: >>> dnPrettyNormal:
<cn=Manager,dc=ncl,dc=ac,dc=uk>
Oct 16 15:13:35 pen slapd[9559]: <<< dnPrettyNormal:
<cn=Manager,dc=ncl,dc=ac,dc=uk>, <cn=manager,dc=ncl,dc=ac,dc=uk>
Oct 16 15:13:35 pen slapd[9559]: do_bind: version=3
dn="cn=Manager,dc=ncl,dc=ac,dc=uk" method=128
Oct 16 15:13:35 pen slapd[9559]: conn=10 op=0 BIND
dn="cn=Manager,dc=ncl,dc=ac,dc=uk" method=128
Oct 16 15:13:35 pen slapd[9559]: ==> bdb_bind: dn:
cn=Manager,dc=ncl,dc=ac,dc=uk
Oct 16 15:13:35 pen slapd[9559]: conn=10 op=0 BIND
dn="cn=Manager,dc=ncl,dc=ac,dc=uk" mech=SIMPLE ssf=0
Oct 16 15:13:35 pen slapd[9559]: do_bind: v3 bind:
"cn=Manager,dc=ncl,dc=ac,dc=uk" to "cn=Manager,dc=ncl,dc=ac,dc=uk"
Oct 16 15:13:35 pen slapd[9559]: send_ldap_result: conn=10 op=0 p=3
Oct 16 15:13:35 pen slapd[9559]: send_ldap_result: err=0 matched=""
text=""
Oct 16 15:13:35 pen slapd[9559]: send_ldap_response: msgid=1 tag=97
err=0
Oct 16 15:13:35 pen slapd[9559]: conn=10 op=0 RESULT tag=97 err=0 text=
Oct 16 15:13:35 pen slapd[9559]: daemon: activity on 1 descriptor
Oct 16 15:13:35 pen slapd[9559]: daemon: activity on:
Oct 16 15:13:35 pen slapd[9559]: 15r
Oct 16 15:13:35 pen slapd[9559]:
Oct 16 15:13:35 pen slapd[9559]: daemon: read active on 15
Oct 16 15:13:35 pen slapd[9559]: connection_get(15)
Oct 16 15:13:35 pen slapd[9559]: connection_get(15): got connid=10
Oct 16 15:13:35 pen slapd[9559]: connection_read(15): checking for input
on id=10
Oct 16 15:13:35 pen slapd[9559]: ber_get_next on fd 15 failed errno=11
(Resource temporarily unavailable)
Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=7
active_threads=0 tvp=NULL
Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=8
active_threads=0 tvp=NULL
Oct 16 15:13:35 pen slapd[9559]: do_search
Oct 16 15:13:35 pen slapd[9559]: >>> dnPrettyNormal:
<ou=people,dc=ncl,dc=ac,dc=uk>
Oct 16 15:13:35 pen slapd[9559]: <<< dnPrettyNormal:
<ou=people,dc=ncl,dc=ac,dc=uk>, <ou=people,dc=ncl,dc=ac,dc=uk>
Oct 16 15:13:35 pen slapd[9559]: SRCH "ou=people,dc=ncl,dc=ac,dc=uk" 2 3
Oct 16 15:13:35 pen slapd[9559]: 0 0 0
Oct 16 15:13:35 pen slapd[9559]: begin get_filter
Oct 16 15:13:35 pen slapd[9559]: AND
Oct 16 15:13:35 pen slapd[9559]: begin get_filter_list
Oct 16 15:13:35 pen slapd[9559]: begin get_filter
Oct 16 15:13:35 pen slapd[9559]: EQUALITY
Oct 16 15:13:35 pen slapd[9559]: end get_filter 0
Oct 16 15:13:35 pen slapd[9559]: begin get_filter
Oct 16 15:13:35 pen slapd[9559]: EQUALITY
Oct 16 15:13:35 pen slapd[9559]: end get_filter 0
Oct 16 15:13:35 pen slapd[9559]: end get_filter_list
Oct 16 15:13:35 pen slapd[9559]: end get_filter 0
Oct 16 15:13:35 pen slapd[9559]: filter:
(&(eduPersonPrincipalName=groupersystem)(objectClass=eduPerson))
Oct 16 15:13:35 pen slapd[9559]: => get_ctrls
Oct 16 15:13:35 pen slapd[9559]: => get_ctrls:
oid="2.16.840.1.113730.3.4.2" (noncritical)
Oct 16 15:13:35 pen slapd[9559]: <= get_ctrls: n=1 rc=0 err=""
Oct 16 15:13:35 pen slapd[9559]: attrs:
Oct 16 15:13:35 pen slapd[9559]: cn
Oct 16 15:13:35 pen slapd[9559]: cn
Oct 16 15:13:35 pen slapd[9559]: eduPersonPrincipalName
Oct 16 15:13:35 pen slapd[9559]:
Oct 16 15:13:35 pen slapd[9559]: conn=10 op=1 SRCH
base="ou=people,dc=ncl,dc=ac,dc=uk" scope=2 deref=3
filter="(&(eduPersonPrincipalName=groupersystem)(objectClass=eduPerson))
"
Oct 16 15:13:35 pen slapd[9559]: conn=10 op=1 SRCH attr=cn cn
eduPersonPrincipalName
Oct 16 15:13:35 pen slapd[9559]: slap_global_control: unavailable
control: 2.16.840.1.113730.3.4.2
Oct 16 15:13:35 pen slapd[9559]: => bdb_search
Oct 16 15:13:35 pen slapd[9559]:
bdb_dn2entry("ou=people,dc=ncl,dc=ac,dc=uk")
Oct 16 15:13:35 pen slapd[9559]: search_candidates:
base="ou=people,dc=ncl,dc=ac,dc=uk" (0x0000004d) scope=2
Oct 16 15:13:35 pen slapd[9559]: => bdb_filter_candidates
Oct 16 15:13:35 pen slapd[9559]: EQUALITY
Oct 16 15:13:35 pen slapd[9559]: => bdb_equality_candidates
(objectClass)
Oct 16 15:13:35 pen slapd[9559]: => key_read
Oct 16 15:13:35 pen slapd[9559]: bdb_idl_fetch_key: [01872a84]
Oct 16 15:13:35 pen slapd[9559]: <= bdb_index_read: failed (-30989)
Oct 16 15:13:35 pen slapd[9559]: <= bdb_equality_candidates: id=0,
first=0, last=0
Oct 16 15:13:35 pen slapd[9559]: <= bdb_filter_candidates: id=0 first=0
last=0
Oct 16 15:13:35 pen slapd[9559]: =>
bdb_dn2idl("ou=people,dc=ncl,dc=ac,dc=uk")
Oct 16 15:13:35 pen slapd[9559]: bdb_idl_fetch_key:
@ou=people,dc=ncl,dc=ac,dc=uk
Oct 16 15:13:35 pen slapd[9559]: <= bdb_dn2idl: id=9 first=77 last=135
Oct 16 15:13:35 pen slapd[9559]: => bdb_filter_candidates
Oct 16 15:13:35 pen slapd[9559]: AND
Oct 16 15:13:35 pen slapd[9559]: => bdb_list_candidates 0xa0
Oct 16 15:13:35 pen slapd[9559]: => bdb_filter_candidates
Oct 16 15:13:35 pen slapd[9559]: AND
Oct 16 15:13:35 pen slapd[9559]: => bdb_list_candidates 0xa0
Oct 16 15:13:35 pen slapd[9559]: => bdb_filter_candidates
Oct 16 15:13:35 pen slapd[9559]: EQUALITY
Oct 16 15:13:35 pen slapd[9559]: => bdb_equality_candidates
(eduPersonPrincipalName)
Oct 16 15:13:35 pen slapd[9559]: <= bdb_equality_candidates:
(eduPersonPrincipalName) index_param failed (18)
Oct 16 15:13:35 pen slapd[9559]: <= bdb_filter_candidates: id=-1 first=1
last=135
Oct 16 15:13:35 pen slapd[9559]: => bdb_filter_candidates
Oct 16 15:13:35 pen slapd[9559]: EQUALITY
Oct 16 15:13:35 pen slapd[9559]: => bdb_equality_candidates
(objectClass)
Oct 16 15:13:35 pen slapd[9559]: => key_read
Oct 16 15:13:35 pen slapd[9559]: bdb_idl_fetch_key: [aef9a643]
Oct 16 15:13:35 pen slapd[9559]: <= bdb_index_read 8 candidates
Oct 16 15:13:35 pen slapd[9559]: <= bdb_equality_candidates: id=8,
first=128, last=135
Oct 16 15:13:35 pen slapd[9559]: <= bdb_filter_candidates: id=8
first=128 last=135
Oct 16 15:13:35 pen slapd[9559]: <= bdb_list_candidates: id=-1 first=128
last=135
Oct 16 15:13:35 pen slapd[9559]: <= bdb_filter_candidates: id=-1
first=128 last=135
Oct 16 15:13:35 pen slapd[9559]: <= bdb_list_candidates: id=8 first=128
last=135
Oct 16 15:13:35 pen slapd[9559]: <= bdb_filter_candidates: id=8
first=128 last=135
Oct 16 15:13:35 pen slapd[9559]: bdb_search_candidates: id=8 first=128
last=135
Oct 16 15:13:35 pen slapd[9559]: => test_filter
Oct 16 15:13:35 pen slapd[9559]: AND
Oct 16 15:13:35 pen slapd[9559]: => test_filter_and
Oct 16 15:13:35 pen slapd[9559]: => test_filter
Oct 16 15:13:35 pen slapd[9559]: EQUALITY
Oct 16 15:13:35 pen slapd[9559]: => access_allowed: search access to
"uid=gene.wilder(a)hotmail.com,ou=people,dc=ncl,dc=ac,dc=uk"
"eduPersonPrincipalName" requested
Oct 16 15:13:35 pen slapd[9559]: <= root access granted
Oct 16 15:13:35 pen slapd[9559]: <= test_filter 5
Oct 16 15:13:35 pen slapd[9559]: <= test_filter_and 5
Oct 16 15:13:35 pen slapd[9559]: <= test_filter 5
Oct 16 15:13:35 pen slapd[9559]: bdb_search: 128 does not match filter
Oct 16 15:13:35 pen slapd[9559]: => test_filter
Oct 16 15:13:35 pen slapd[9559]: AND
Oct 16 15:13:35 pen slapd[9559]: => test_filter_and
Oct 16 15:13:35 pen slapd[9559]: => test_filter
Oct 16 15:13:35 pen slapd[9559]: EQUALITY
Oct 16 15:13:35 pen slapd[9559]: => access_allowed: search access to
"uid=lionel.messi(a)hotmail.com,ou=people,dc=ncl,dc=ac,dc=uk"
"eduPersonPrincipalName" requested
Oct 16 15:13:35 pen slapd[9559]: <= root access granted
Oct 16 15:13:35 pen slapd[9559]: <= test_filter 5
Oct 16 15:13:35 pen slapd[9559]: <= test_filter_and 5
Oct 16 15:13:35 pen slapd[9559]: <= test_filter 5
Oct 16 15:13:35 pen slapd[9559]: bdb_search: 135 does not match filter
Oct 16 15:13:35 pen slapd[9559]: send_ldap_result: conn=10 op=1 p=3
Oct 16 15:13:35 pen slapd[9559]: send_ldap_result: err=0 matched=""
text=""
Oct 16 15:13:35 pen slapd[9559]: send_ldap_response: msgid=2 tag=101
err=0
Oct 16 15:13:35 pen slapd[9559]: conn=10 op=1 SEARCH RESULT tag=101
err=0 nentries=0 text=
Oct 16 15:13:35 pen slapd[9559]: daemon: activity on 1 descriptor
Oct 16 15:13:35 pen slapd[9559]: daemon: activity on:
Oct 16 15:13:35 pen slapd[9559]: 15r
Oct 16 15:13:35 pen slapd[9559]:
Oct 16 15:13:35 pen slapd[9559]: daemon: read active on 15
Oct 16 15:13:35 pen slapd[9559]: connection_get(15)
Oct 16 15:13:35 pen slapd[9559]: connection_get(15): got connid=10
Oct 16 15:13:35 pen slapd[9559]: connection_read(15): checking for input
on id=10
Oct 16 15:13:35 pen slapd[9559]: ber_get_next on fd 15 failed errno=0
(Success)
Oct 16 15:13:35 pen slapd[9559]: connection_read(15): input error=-2
id=10, closing.
Oct 16 15:13:35 pen slapd[9559]: connection_closing: readying conn=10
sd=15 for close
Oct 16 15:13:35 pen slapd[9559]: connection_close: deferring conn=10
sd=15
Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=7
active_threads=0 tvp=NULL
Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=8
active_threads=0 tvp=NULL
Oct 16 15:13:35 pen slapd[9559]: daemon: activity on 1 descriptor
Oct 16 15:13:35 pen slapd[9559]: daemon: activity on:
Oct 16 15:13:35 pen slapd[9559]:
Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=7
active_threads=0 tvp=NULL
Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=8
active_threads=0 tvp=NULL
Oct 16 15:13:35 pen slapd[9559]: do_unbind
Oct 16 15:13:35 pen slapd[9559]: conn=10 op=2 UNBIND
Oct 16 15:13:35 pen slapd[9559]: connection_resched: attempting closing
conn=10 sd=15
Oct 16 15:13:35 pen slapd[9559]: connection_close: conn=10 sd=15
Oct 16 15:13:35 pen slapd[9559]: daemon: removing 15
Oct 16 15:13:35 pen slapd[9559]: conn=10 fd=15 closed
Oct 16 15:13:35 pen slapd[9559]: daemon: activity on 1 descriptor
Oct 16 15:13:35 pen slapd[9559]: daemon: activity on:
Oct 16 15:13:35 pen slapd[9559]: 13r
Oct 16 15:13:35 pen slapd[9559]:
Oct 16 15:13:35 pen slapd[9559]: daemon: read active on 13
Oct 16 15:13:35 pen slapd[9559]: connection_get(13)
Oct 16 15:13:35 pen slapd[9559]: connection_get(13): got connid=8
Oct 16 15:13:35 pen slapd[9559]: connection_read(13): checking for input
on id=8
Oct 16 15:13:35 pen slapd[9559]: ber_get_next on fd 13 failed errno=11
(Resource temporarily unavailable)
Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=7
active_threads=0 tvp=NULL
Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=8
active_threads=0 tvp=NULL
Oct 16 15:13:35 pen slapd[9559]: do_unbind
Oct 16 15:13:35 pen slapd[9559]: conn=8 op=1 UNBIND
Oct 16 15:13:35 pen slapd[9559]: connection_closing: readying conn=8
sd=13 for close
Oct 16 15:13:35 pen slapd[9559]: connection_resched: attempting closing
conn=8 sd=13
Oct 16 15:13:35 pen slapd[9559]: connection_close: conn=8 sd=13
Oct 16 15:13:35 pen slapd[9559]: daemon: removing 13
Oct 16 15:13:35 pen slapd[9559]: conn=8 fd=13 closed
Oct 16 15:13:35 pen slapd[9559]: daemon: activity on 1 descriptor
Oct 16 15:13:35 pen slapd[9559]: daemon: activity on:
Oct 16 15:13:35 pen slapd[9559]: 13r
Oct 16 15:13:35 pen slapd[9559]:
Oct 16 15:13:35 pen slapd[9559]: daemon: read active on 13
Oct 16 15:13:35 pen slapd[9559]: connection_get(13)
Oct 16 15:13:35 pen slapd[9559]: connection_get(13): connection not used
Oct 16 15:13:35 pen slapd[9559]: connection_read(13): no connection!
Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=7
active_threads=0 tvp=NULL
Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=8
active_threads=0 tvp=NULL
Oct 16 15:13:35 pen slapd[9559]: daemon: activity on 1 descriptor
Oct 16 15:13:35 pen slapd[9559]: daemon: activity on:
Oct 16 15:13:35 pen slapd[9559]:
Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=7
active_threads=0 tvp=NULL
Oct 16 15:13:35 pen slapd[9559]: daemon: select: listen=8
active_threads=0 tvp=NULL
Regards
--------------
Sanjay Vivek
Middleware Team
ISS
University of Newcastle Upon Tyne
15 years, 7 months
OpenLDAP as a SASL backend
by Zohar Lev Shani
Hello list
I am trying to use OpenLDAP also as a repository of the user and
password to the SASL mechanism.
The problem I am facing is that it only works if the userPassword is
kept in clear text and not in a hashed form. I would like to use the
hashed form because my application has a proprietary backend where the
data goes over the wire and for that I need userPassword attribute to
be not in clear text.
Below is what I tried to do, based on OpenLDAP 2.3.24 running on RH4
U3 (Nahant).
Any help will be appreciated.
Zohar
> ./configure --prefix=`pwd`
I added to the default slapd.conf with this entry
authz-regexp "uid=([^,]*)" "cn=$1,cn=users,dc=my-domain,dc=com"
The run command
> ./slapd -f slapd.conf -d -1 -h ldap://localhost:9999 1>& slapd.log 2>&1 &
Available SASL mechanism
> ldapsearch -h localhost:9999 -x -b '' supportedSASLMechanisms -s base -LLL
dn:
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: NTLM
Data I am going to add
> cat ./new_user.ldif
dn: dc=my-domain,dc=com
objectclass: dcObject
objectclass: organization
o: my-org
dc: my-domain
dn: cn=Manager,dc=my-domain,dc=com
objectclass: organizationalRole
cn: Manager
dn: cn=users,dc=my-domain,dc=com
objectclass: organizationalRole
cn: users
dn: cn=user1,cn=users,dc=my-domain,dc=com
objectclass: organizationalRole
objectclass: simpleSecurityObject
cn: user1
userPassword: {MD5}pyLGPbjshiWvbPccuMLZOQ==
#password: pass1
dn: cn=user3,cn=users,dc=my-domain,dc=com
objectclass: organizationalRole
objectclass: simpleSecurityObject
cn: user3
userPassword: {CLEARTEXT}pass3
> ldapadd -h localhost:9999 -x -w secret -D cn=Manager,dc=my-domain,dc=com -f ./new_user.ldif
> ldapsearch -h localhost:9999 -x -LLL -b cn=user1,cn=users,dc=my-domain,dc=com
dn: cn=user1,cn=users,dc=my-domain,dc=com
objectClass: organizationalRole
objectClass: simpleSecurityObject
cn: user1
userPassword:: e01ENX1weUxHUGJqc2hpV3ZiUGNjdU1MWk9RPT0=
> ldapsearch -h localhost:9999 -Y DIGEST-MD5 -U user1 -w pass1 -LLL -b cn=user1,cn=users,dc=my-domain,dc=com
SASL/DIGEST-MD5 authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: SASL(-13): user not found: no secret in database
> ldapsearch -h localhost:9999 -Y DIGEST-MD5 -U user3 -w pass3 -LLL -b cn=user1,cn=users,dc=my-domain,dc=com
SASL/DIGEST-MD5 authentication started
SASL username: user3
SASL SSF: 128
SASL installing layers
dn: cn=user1,cn=users,dc=my-domain,dc=com
objectClass: organizationalRole
objectClass: simpleSecurityObject
cn: user1
userPassword:: e01ENX1weUxHUGJqc2hpV3ZiUGNjdU1MWk9RPT0=
15 years, 7 months
how to enable crypt password in Openldap under Windows!!!
by Hang Zhang
Hi All,
I met a big problem! It is Ok when I use slappasswd -h {MD5}or {sha} but
when I use slappasswd -h {CRYPT}, it reminds me that the {CRYPT} scheme
not recognized! I search this problem in google and the answer to this
is --enable -crypt. However, how to do this under windows XP? I would
really appreciate any kinds of help!!
C:\OpenLDAP>slappasswd -h {CRYPT}
New password: Re-enter new password: Password generation failed for
scheme {CRYPT}: scheme not recognized
Hang
15 years, 7 months
When to delete client content during RFC4533 synchronization?
by Erik van Oosten
Hello,
I am writing a RFC4533 client implementation based on JLDAP. I have a
question on how to interpret the rfc as a client, and secondly how the
OpenLDAP server interprets it.
My question is: how can the client determine that it must delete content
at the end of the refresh stage, when a refreshAndPersist is requested
with an initial cookie?
The problem is that I can not defer from the rfc how I can differentiate
between a server that sends an initial content poll and a server that
sends a content update poll. The RFC specifies that the server may choose
to ignore the initial cookie and the reloadHint flag, so either poll mode
may be choosen by the server.
In the case of a refreshOnly the RFC is clear: when refreshDeletes of
syncDoneValue is FALSE, content that is not added, changed, or indicated
as present must be deleted from the client copy (section 1.3.1 paragraph
8).
However, in the case of a refreshAndPersist, there is no similar flag in
the SyncInfoMessage that ends the refresh stage. SyncInfoMessage does have
values named refreshDelete and refreshDeletes, but these are used for
other purposes (see section 3.4.1 and section 3.3.2 paragraph 7 and 9).
Am I missing something?
What is the behavior of the OpenLDAP server in this matter? Does it ever
ignore the reloadHint of the sync request control?
Regards,
Erik.
--
Erik van Oosten
http://2008.rubyenrails.nl/
http://www.day-to-day-stuff.blogspot.com/
15 years, 7 months
Re: setting up admin password on openldap
by Gavin Henry
<quote who="Naufal Sheikh">
> Vi ...
Come on, what sort of answer is that? How can we possibly help if you
don't provide concrete information.
What command do you type to make the modification?
ldapmodify?
What were the exact arguments?
>
> On 10/30/07, Gavin Henry <ghenry(a)suretecsystems.com> wrote:
>>
>> <quote who="Naufal Sheikh">
>> > Hello Piotr,
>> >
>> > I tried to do what you said. Initially my root dn just contained
>> > cn=nsadmin,
>> > and thus I caould not start slapd. Then I added to rootdn my suffix as
>> > well,
>> > and unhashed the rootpw line in slapd.conf. I tried using a clear text
>> > "secret" as well as hashed value created through slappasswd and
>> putting
>> it
>> > in the slapd.conf. In both cases, when I modify the entry and it asks
>> me
>> > to
>> > give ldap password, it says invalid credentials.
>>
>> How are you trying to modify? What tool?
>>
>
15 years, 7 months
Re: how to enable crypt password in Openldap under Windows!!!
by Hang Zhang
Quanah Gibson-Mount wrote:
> --On Wednesday, October 31, 2007 1:16 AM -0600 Hang Zhang
> <hzhang(a)cs.uno.edu> wrote:
>
>> Hi Quanah,
>
> Please read:
>
> <http://www.eyrie.org/~eagle/faqs/questions.html>
>
> --Quanah
>
>
>
> --
>
> Quanah Gibson-Mount
> Principal Software Engineer
> Zimbra, Inc
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
Hi Quanah,
Thanks for your reply. However, I found that cannot bind to the ldap
server with any
types of hashed password. I use the command slappasswd, and copied the
generated {sha} password and then paste this hashed password into my
slapd.conf file. Then I cannot bind to the ldap server anymore unless I use
the clear text version. I do not know why? Thanks.
Hang
15 years, 7 months
