Virtual list view problem
by Venish Khant
Hi all
I am using cpan Net::LDAP module to access LDAP entries. I want to
search LDAP entries using Net::LDAP search method. When I do search, I
want some limited number of entries from search result, for
this(searching) process I am using Net::LDAP::Control::VLV module. But
I get error on VLV response control. Please, any one have idea about
this error.
*
Error:* Died at vlv.pl line 50,
This is my example. I changed the font style of line 50
#!/usr/bin/perl -w
use Net::LDAP;
use Net::LDAP::Control::VLV;
use Net::LDAP::Constant qw( LDAP_CONTROL_VLVRESPONSE );
use Net::LDAP::Control::Sort;
sub procentry {
my ( $mesg, $entry) = @_;
# Return if there is no entry to process
if ( !defined($entry) ) {
return;
}
print "dn: " . $entry->dn() . "\n";
@attrs = $entry->attributes();
foreach $attr (@attrs) {
#printf("\t%s: %s\n", $attr, $entry->get_value($attr));
$attrvalue = $entry->get_value($attr,asref=>1);
#print $attr.":". $entry->get_value($attr)."\n";
foreach $value(@$attrvalue) {
print "$attr: $value\n";
}
}
$mesg->pop_entry;
print "\n";
}
$ldap = Net::LDAP->new( "localhost" );
# Get the first 20 entries
$vlv = Net::LDAP::Control::VLV->new(
before => 0, # No entries from before target entry
after => 19, # 19 entries after target entry
content => 0, # List size unknown
offset => 1, # Target entry is the first
);
my $sort = Net::LDAP::Control::Sort->new( order => 'cn' );
@args = ( base => "dc=example,dc=co,dc=in",
scope => "subtree",
filter => "(objectClass=inetOrgPerson)",
callback => \&procentry, # Call this sub for each entry
control => [ $sort, $vlv ],
);
$mesg = $ldap->search( @args );
# Get VLV response control
*($resp) = $mesg->control( LDAP_CONTROL_VLVRESPONSE ) or die;*
$vlv->response( $resp );
# Set the control to get the last 20 entries
$vlv->end;
$mesg = $ldap->search( @args );
# Get VLV response control
($resp) = $mesg->control( LDAP_CONTROL_VLVRESPONSE ) or die;
$vlv->response( $resp );
# Now get the previous page
$vlv->scroll_page( -1 );
$mesg = $ldap->search( @args );
# Get VLV response control
($resp) = $mes
# Now page with first entry starting with "B" in the middle
$vlv->before(9); # Change page to show 9 before
$vlv->after(10); # Change page to show 10 after
$vlv->assert("B"); # assert "B"
$mesg = $ldap->search( @args );g->control( LDAP_CONTROL_VLVRESPONSE ) or
die;
$vlv->response( $resp );
--
Venish Khant
www.deeproot.co.in
6 years, 12 months
Re: (ITS#6666) Feature Request: Triggers implementation
by Buchan Milne
On Thursday, 7 October 2010 20:32:49 Nick Milas wrote:
> It all started for me when I wanted to watch a serial number value from
> an ldap-stored SOArecord (using powerdns with openldap backend) and when
> it changes to fire a bash script. I reached the conclusion it was not
> easy to be done with higher-level means within openldap and I created a
> bash script which scans (using ldapsearch and other linux tools) the
> SOArecords regularly (using cron) to find out if any change has happend
> and do whatever is required. It would be much more elegant if I could
> get a trigger from openldap when the SOArecord changes.
Maybe you need this:
http://memberwebs.com/stef/software/slapi-dnsnotify/
A more generic solution would be nice, but as far as I can tell, this software
satisfies your current need.
Regards,
Buchan
12 years
Certificate authentication and back-ldap proxy
by Ubay Dorta Guerra
Hi,
We have some problems with certificate authentication when the master
server is behind a back-ldap proxy.
We have openldap 2.4.21 on Suse Linux Enterprise Server 10 SP3 and
these are the details of our scenario:
The master server: server1.example.com has the following slapd.conf file:
access to dn.base=""
by * read
access to dn.base="cn=Subschema"
by * read
access to attrs=userPassword,userPKCS12
by self write
by dn.exact="CN=admin_w_cert,O=Internet Widgits Pty
Ltd,ST=Some-State,C=AU" read
by *
auth
access to attrs=shadowLastChange
by self write
by * read
access to *
by * read
#
# Security SSL
#
TLSCipherSuite HIGH:MEDIUM:+SSLv3
TLSCertificateFile /etc/ssl/certs/server1.example.com.pem
TLSCertificateKeyFile /etc/ssl/private/server1.example.com.key
TLSCACertificatePath /etc/ssl/cacerts/
TLSVerifyClient demand
#
#Log level
#
loglevel 256
# Require authentication
require authc
#######################################################################
# HDB database definitions
#######################################################################
database hdb
suffix "dc=example,dc=com"
checkpoint 1024 5
cachesize 10000
rootdn "cn=Manager,dc=example,dc=com"
rootpw secret
# Indices to maintain
index objectClass eq
# Overlay ppolicy
overlay ppolicy
----------------------
Authentication is required, and we give access to the user passwords
for the dn of a certificate.
When we search for passwords using the certificate we get the following:
root# ldapsearch -LLL -b 'uid=user_w_pass,ou=people,dc=example,dc=com'
-H ldaps://server1.example.com userPassword
SASL/EXTERNAL authentication started
SASL username: CN=admin_w_cert,O=Internet Widgits Pty Ltd,ST=Some-State,C=AU
SASL SSF: 0
dn: uid=user_w_pass,ou=people,dc=example,dc=com
userPassword:: e2NyeXB0fTcyMXpQbU4waWdKaU0=
-----------------------
The root user (ldap client) has a ~/.ldaprc file with:
TLS_CACERTDIR /etc/ssl/cacerts/
TLS_CERT /etc/ssl/certs/admin_w_cert.pem
TLS_KEY /etc/ssl/private/admin_w_cert.key
TLS_REQCERT demand
SASL_MECH EXTERNAL
In /var/log/messages we get:
ldap-master[22358]: conn=1000 fd=11 ACCEPT from
IP=server1.example.com:40899 (IP=server1.example.com:636)
ldap-master[22358]: conn=1000 fd=11 TLS established tls_ssf=256 ssf=256
ldap-master[22358]: conn=1000 op=0 BIND dn="" method=163
ldap-master[22358]: conn=1000 op=0 BIND
authcid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
authzid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
ldap-master[22358]: conn=1000 op=0 BIND dn="cn=admin_w_cert,o=internet
widgits pty ltd,st=some-state,c=au" mech=EXTERNAL sasl_ssf=0 ssf=256
ldap-master[22358]: conn=1000 op=0 RESULT tag=97 err=0 text=
ldap-master[22358]: conn=1000 op=1 SRCH
base="uid=user_w_pass,ou=people,dc=example,dc=com" scope=2 deref=0
filter="(objectClass=*)"
ldap-master[22358]: conn=1000 op=1 SRCH attr=userPassword
ldap-master[22358]: conn=1000 op=1 SEARCH RESULT tag=101 err=0
nentries=1 text=
ldap-master[22358]: conn=1000 op=2 UNBIND
ldap-master[22358]: conn=1000 fd=11 closed
This is the correct behavior for us. The problem appears when we
introduce a back-ldap proxy between the client and the master.
The proxy server (proxy-server1.example.com) is listening in port
1636 and its slapd.conf file is:
#
# Security SSL
#
TLSCipherSuite HIGH:MEDIUM:+SSLv3
TLSCACertificatePath /etc/ssl/cacerts/
TLSCertificateFile /etc/ssl/certs/proxy-server1.example.com.pem
TLSCertificateKeyFile /etc/ssl/private/proxy-server1.example.com.key
TLSVerifyClient demand
# Log level
loglevel 256
#######################################################################
# Database definitions
#######################################################################
database ldap
rebind-as-user true
suffix "dc=example,dc=com"
uri "ldaps://server1.example.com"
tls ldaps
tls_cert=/etc/ssl/certs/proxy-server1.example.com.pem
tls_key=/etc/ssl/private/proxy-server1.example.com.key
tls_cacertdir=/etc/ssl/cacerts/
----------------------
If we search for passwords through the proxy we get:
root # ldapsearch -LLL -b 'uid=user_w_pass,ou=people,dc=example,dc=com'
-H ldaps://proxy-server1.example.com:1636 userPassword
SASL/EXTERNAL authentication started
SASL username: CN=admin_w_cert,O=Internet Widgits Pty Ltd,ST=Some-State,C=AU
SASL SSF: 0
Server is unwilling to perform (53)
Additional information: authentication required
In the /var/log/messages the following messages appear:
ldap-proxy[22802]: conn=1001 fd=8 ACCEPT from
IP=proxy-server1.example.com:60712 (IP=proxy-server1.example.com:1636)
ldap-proxy[22802]: conn=1001 fd=8 TLS established tls_ssf=256 ssf=256
ldap-proxy[22802]: conn=1001 op=0 BIND dn="" method=163
ldap-proxy[22802]: conn=1001 op=0 BIND
authcid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
authzid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
ldap-proxy[22802]: conn=1001 op=0 BIND dn="cn=admin_w_cert,o=internet
widgits pty ltd,st=some-state,c=au" mech=EXTERNAL sasl_ssf=0 ssf=256
ldap-proxy[22802]: conn=1001 op=0 RESULT tag=97 err=0 text=
ldap-proxy[22802]: conn=1001 op=1 SRCH
base="uid=user_w_pass,ou=people,dc=example,dc=com" scope=2 deref=0
filter="(objectClass=*)"
ldap-proxy[22802]: conn=1001 op=1 SRCH attr=userPassword
ldap-master[22358]: conn=1008 op=2 SRCH
base="uid=user_w_pass,ou=people,dc=example,dc=com" scope=2 deref=0
filter="(objectClass=*)"
ldap-master[22358]: conn=1008 op=2 SRCH attr=userPassword
ldap-master[22358]: conn=1008 op=2 SEARCH RESULT tag=101 err=53
nentries=0 text=authentication required
ldap-proxy[22802]: conn=1001 op=1 SEARCH RESULT tag=101 err=53
nentries=0 text=authentication required
ldap-proxy[22802]: conn=1001 op=2 UNBIND
ldap-proxy[22802]: conn=1001 fd=8 closed
The /root/.ldaprc file is the same than the previous one.
When we increase the logging level we discover this:
....
ldap-proxy[23008]: conn=1000 op=0 do_bind
ldap-proxy[23008]: >>> dnPrettyNormal: <>
ldap-proxy[23008]: <<< dnPrettyNormal: <>, <>
ldap-proxy[23008]: conn=1000 op=0 BIND dn="" method=163
ldap-proxy[23008]: do_bind: dn () SASL mech EXTERNAL
ldap-proxy[23008]: ==> sasl_bind: dn="" mech=EXTERNAL datalen=0
ldap-proxy[23008]: SASL Canonicalize [conn=1000]:
authcid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
ldap-proxy[23008]: slap_sasl_getdn: conn 1000
id=cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au [len=61]
ldap-proxy[23008]: ==>slap_sasl2dn: converting SASL name
cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au to a DN
ldap-proxy[23008]: <==slap_sasl2dn: Converted SASL name to <nothing>
ldap-proxy[23008]: SASL Canonicalize [conn=1000]:
slapAuthcDN="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
ldap-proxy[23008]: SASL proxy authorize [conn=1000]:
authcid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
authzid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
ldap-proxy[23008]: conn=1000 op=0 BIND
authcid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
authzid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
ldap-proxy[23008]: SASL Authorize [conn=1000]: proxy authorization
allowed authzDN=""
ldap-proxy[23008]: send_ldap_sasl: err=0 len=-1
ldap-proxy[23008]: conn=1000 op=0 BIND dn="cn=admin_w_cert,o=internet
widgits pty ltd,st=some-state,c=au" mech=EXTERNAL sasl_ssf=0 ssf=256
ldap-proxy[23008]: do_bind: SASL/EXTERNAL bind:
dn="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
sasl_ssf=0
ldap-proxy[23008]: send_ldap_response: msgid=1 tag=97 err=0
ldap-proxy[23008]: conn=1000 op=0 RESULT tag=97 err=0 text=
ldap-proxy[23008]: <== slap_sasl_bind: rc=0
....
ldap-proxy[23008]: conn=1000 op=1 SRCH
base="uid=user_w_pass,ou=people,dc=example,dc=com" scope=2 deref=0
filter="(objectClass=*)"
ldap-proxy[23008]: conn=1000 op=1 SRCH attr=userPassword
ldap-proxy[23008]: ==> limits_get: conn=1000 op=1
self="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
this="uid=user_w_pass,ou=people,dc=example,dc=com"
ldap-master[22983]: daemon: activity on 1 descriptor
ldap-master[22983]: daemon: activity on:
ldap-master[22983]:
ldap-master[22983]: slap_listener_activate(7):
ldap-master[22983]: daemon: epoll: listen=7 busy
ldap-master[22983]: >>> slap_listener(ldaps://server1.example.com)
.....
ldap-master[22983]: conn=1000 op=0 do_bind
ldap-master[22983]: >>> dnPrettyNormal: <>
ldap-master[22983]: <<< dnPrettyNormal: <>, <>
ldap-master[22983]: conn=1000 op=0 BIND dn="" method=128
ldap-master[22983]: do_bind: version=3 dn="" method=128
ldap-master[22983]: send_ldap_result: conn=1000 op=0 p=3
ldap-master[22983]: send_ldap_result: err=0 matched="" text=""
ldap-master[22983]: send_ldap_response: msgid=1 tag=97 err=0
ldap-master[22983]: conn=1000 op=0 RESULT tag=97 err=0 text=
ldap-master[22983]: do_bind: v3 anonymous bind
----------------
Therefore the proxy is binding anonymously in the master, instead of
using the dn of the certificate.
Is there any problem with the SASL EXTERNAL method?
If we use SIMPLE authentication through the proxy, there is no problem:
root # ldapsearch -LLL -x -b
'uid=user_w_pass,ou=people,dc=example,dc=com' -H
ldaps://proxy-server1.example.com:1636 -D
'uid=user_w_pass,ou=people,dc=example,dc=com' -W userPassword
Enter LDAP Password:
dn: uid=user_w_pass,ou=people,dc=example,dc=com
userPassword:: e2NyeXB0fTcyMXpQbU4waWdKaU0=
Thanks in advance.
---------------------------------------------------------------------------------------------
ADVERTENCIA: Sobre la privacidad y cumplimiento de la Ley de Protección de Datos, acceda a http://www.iac.es/disclaimer.php
WARNING: For more information on privacy and fulfilment of the Law concerning the Protection of Data, consult http://www.iac.es/disclaimer.php?lang=en
12 years, 5 months
push replication with proxy and rwm overlay
by Gwenn Gueguen
Hi all,
I'm trying to set up push replication from master to slave through a
proxy with rwm overlay. Master, proxy and slave are OpenLDAP 2.4.11
from debian lenny.
On the slave, I don't want samba related attributes so I used the
attrs param on syncrepl to only get attributes I want but entries
still have sambaSamAccount or sambaGroupMapping as objectClass.
I tried using the rwm overlay to remove these references to samba in
objectclass but it did not work and I still get the following error
when proxy tries to add the entries on the slave:
error code 0x15: objectClass: value #3 invalid per syntax
Here is the proxy configuration:
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/samba.schema
include /etc/ldap/schema/authldap.schema
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
loglevel -1
modulepath /usr/lib/ldap
moduleload back_ldap
moduleload syncprov
moduleload rwm
database ldap
suffix "..."
rootdn "cn=admin,..."
uri ldap://ldap-dmz
# Save the time that the entry gets modified, for database #1
lastmod on
#We don't need any access to this DSA
restrict all
overlay rwm
rwm-map objectclass inetOrgPerson *
rwm-map objectclass posixAccount *
rwm-map objectclass shadowAccount *
rwm-map objectclass organizationalPerson *
rwm-map objectclass person *
rwm-map objectclass posixGroup *
# rwm-map objectclass sambaSamAccount
# rwm-map objectclass sambaGroupMapping
rwm-map objectclass *
acl-bind bindmethod=simple
idassert-bind
bindmethod=simple
binddn="cn=admin,..."
credentials="secret"
syncrepl rid=001
provider=ldap://ldap
attrs="@inetOrgPerson,@posixAccount,@shadowAccount,@organizationalPerson,@person"
bindmethod=simple
searchbase="ou=people,..."
type=refreshAndPersist
retry="60 +"
interval=00:00:01:00
schemachecking=off
syncrepl rid=002
provider=ldap://ldap
attrs="@posixGroup"
bindmethod=simple
searchbase="ou=groups,..."
type=refreshAndPersist
retry="60 +"
interval=00:00:01:00
schemachecking=off
overlay syncprov
I tried upgrading OpenLdap on the proxy to 2.4.17 from backports and
also upgraded to squeeze with OpenLdap 2.4.23 but I still get the
error.
Am I doing something wrong or is rwm buggy ?
Thanks,
--
Gwenn
12 years, 5 months
slapcat, PROXIED attributeDescription inserted, and cron jobs
by btb＠bitrate.net
hi-
i'm running slapcat from a daily cron job to back up cn=config and other
databases. i've recently updated from 2.4.21 to 2.4.23, and notice now
in the output of slapcat, messages such as
>slapcat -b 'cn=config' -l 'config.ldif' > /dev/null
PROXIED attributeDescription "OU" inserted.
PROXIED attributeDescription "DC" inserted.
a bit of searching seems to indicate that these shouldn't be cause for
concern, and are just informative messages.
since these messages are written to stderr, cron sends email every time
it runs slapcat. if they're not errors, do they maybe belong in stdout
rather than stderr? alternatively, can these messages be suppressed?
according to the man page, there doesn't appear a way to do so.
thanks
-ben
12 years, 5 months
how to compile recent openldap on Centos 5.5
by Götz Reinicke - IT-Koordinator
Hello,
I tried to compile the Release 2.4.23 of openldap on my centos 5.5 server.
It fails with:
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
checking for Berkeley DB major version in db.h... 4
checking for Berkeley DB minor version in db.h... 3
checking if Berkeley DB version supported by BDB/HDB backends... no
configure: error: BerkeleyDB version incompatible with BDB/HDB backends
I do have db4 installed:
db4-4.3.29-10.el5_5.2
db4-devel-4.3.29-10.el5_5.2
db4-utils-4.3.29-10.el5_5.2
What may I do wrong? Any sugesstions?
Thanks and regards . Götz
--
Götz Reinicke
IT-Koordinator
Tel. +49 7141 969 420
Fax +49 7141 969 55 420
E-Mail goetz.reinicke(a)filmakademie.de
Filmakademie Baden-Württemberg GmbH
Akademiehof 10
71638 Ludwigsburg
www.filmakademie.de
Eintragung Amtsgericht Stuttgart HRB 205016
Vorsitzende des Aufsichtsrats:
Prof. Dr. Claudia Hübner
Geschäftsführer:
Prof. Thomas Schadt
12 years, 5 months
Re: Want interesting restrictions to ldap auth on different servers to different users
by c0re
2010/11/19 Phuong Marie VUONG <mangocphung(a)gmail.com>:
> Hello,
>
> First, im sorry about my English. I share here my experience which worked
> for limit acces host/group of host for user...
>
> In the configuration of ldap client /etc/ldap.conf , i have activate the
> host attribute and a filter in nss_base_passwd
> pam_check_host_attr yes
> nss_base_passwd
> ou=People,dc=xxxxx,dc=xxxx?one?|(host=hostname.domain)(host=PatternofHostGroup)(host=*)
>
> In the user entry, add the host attribute
> And in the host set, you can put the pattern value correpond of the level
> that you want to authorize to connect , for exe :
> hostname.domain
> or
> PatternofHostGroup
> or
> *
>
> Hope that can help
>
>
> 2010/11/19 c0re <nr1c0re(a)gmail.com>
>>
>> can you give an example of usage pam_check_host_attr?
>>
>> And how can I use group of hosts and assign user to this group to
>> permit access user to this group avoiding enumerating hosts in users
>> dn each time I add new user?
>>
>> What should I set in "host:"? Hostname of server? How host attr are
>> sent to pam_ldap?
>>
>> 2010/11/18 Aaron Richton <richton(a)nbcs.rutgers.edu>:
>> > On Thu, 18 Nov 2010, c0re wrote:
>> >
>> >> I mean user user1 can must login only on server1,server2 and server3.
>> >> And user2 can login only on server5 and server2.
>> >
>> > You could probably overload almost anything (dyngroups, OpenLDAP ACLs,
>> > search filters, who knows) to accomplish this, but the cleanest way to
>> > do
>> > this in pam_ldap would utilize pam_check_host_attr. I assume pam_ldap
>> > because you mentioned "pam_groupdn" which is not an OpenLDAP
>> > configuration
>> > directive.
>> >
>
>
>
> --
> Milan&Phuong
> 06.17.34.09.77
> 09.53.57.04.94
> http://www.phuong.fr/photos/
>
>
>
I moved a bit different way.
I used pam_groupdn in ldap.conf and created a group for each server.
Now if I add user to ldap, I need to add to groups "memberUid:
`userdn`". And user will be able to login to those servers in which
groups is user as a member.
But if I got 100-200 servers and want to give access to new user to
all this servers, I should add user to all groups. Of course it's a
waste of time and it's possible to be done via some external
shell/perl script, but may be there another way in openldap?
pam_check_host_attr do almost same. If I add user - I need to add all
hosts to user attr "host:". So it's same work I think.
12 years, 5 months
ssf settings on server restart
by Christian Bösch
hi,
i have an acl set to allow only some ips to connect unencrypted:
{0}to dn.children="dc=abc,dc=net" by peername.ip=10.10.40.100 read break by peername.ip=10.10.8.49 read break by ssf=128 read break by * none
olcSecurity: ssf=0 tls=0 simple_bind=0 update_ssf=0
this works in general, but if i restart slapd i get from the defined ips from above 'confidentially required'. then i have to set ssf=1 then back to ssf=0 to make
it work again?
anyone an idea why?
/thx.chris
12 years, 5 months
syncrepl with accesslog not replicating
by Dieter Klünter
Hi,
I am facing a problem with OpenLDAP-2.4.23. That is I am trying to setup
a delta replication based on accesslog. Although the accesslog database
contains new entries and the log database is successfully read, no
replication ever takes place, while a setup without accesslog replicates successfully.
An excerpt from the systemlogs:
slapd[19170]: conn=1050 fd=20 ACCEPT from IP=192.168.0.8:41487 (IP=0.0.0.0:389)
slapd[19170]: conn=1050 op=0 EXT oid=1.3.6.1.4.1.1466.20037
slapd[19170]: conn=1050 op=0 STARTTLS
slapd[19170]: conn=1050 op=0 RESULT oid= err=0 text=
slapd[19170]: conn=1050 fd=20 TLS established tls_ssf=256 ssf=256
slapd[19170]: conn=1050 op=1 BIND dn="" method=163
slapd[19170]: conn=1050 op=1 BIND authcid="cn=replicator,o=avci,c=de" authzid="cn=replicator,o=avci,c=de"
slapd[19170]: conn=1050 op=1 BIND dn="cn=replicator,o=avci,c=de" mech=EXTERNAL sasl_ssf=0 ssf=256
slapd[19170]: conn=1050 op=1 RESULT tag=97 err=0 text=
slapd[19170]: conn=1050 op=2 SRCH base="cn=log" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))"
slapd[19170]: conn=1050 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
slapd[19170]: conn=1050 op=2 SEARCH RESULT tag=101 err=0 nentries=7 text=
slapd[19170]: conn=1050 op=3 UNBIND
slapd[19170]: conn=1050 fd=20 closed
A ldapsearch -Y EXTERNAL -ZZ -H ldap://localhost -b cn=log -s one "(&(objectClass=auditWriteObject)(reqResult=0))"
provides the expected results, an example
# 20101129144212.000003Z, log
dn: reqStart=20101129144212.000003Z,cn=log
objectClass: auditModify
reqStart: 20101129144212.000003Z
reqEnd: 20101129144212.000004Z
reqType: modify
reqSession: 1007
reqAuthzID: cn=admanager,o=avci,c=de
reqControls: {0}{2.16.840.1.113730.3.4.18 controlValue "646O3K636O3N61646N616O
616765722M6P3N617663692M633N6465"}
reqDN:: Y249U2Now6RmZXIgV29sZmdhbmcsb3U9YWRyZXNzYnVjaCxvPWF2Y2ksYz1kZQ==
reqResult: 0
reqMod: sn:- Wolfgang
reqMod: sn:+ Schaefer
reqMod: entryCSN:= 20101129144212.353910Z#000000#000#000000
reqMod: modifiersName:= cn=admanager,o=avci,c=de
reqMod: modifyTimestamp:= 20101129144212Z
The relevant config files can be found here:
Provider slapd.conf: http://pastebin.de/12273
Consumer slapd.conf: http://pastebin.de/12275
-Dieter
--
Dieter Kl�nter | Systemberatung
sip: 7770535(a)sipgate.de
http://www.dpunkt.de/buecher/2104.html
GPG Key ID:8EF7B6C6
12 years, 5 months
slapcat segfaults when ppolicy overlay added
by Ryan Steele
I've been trying, unsuccessfully, to set up ppolicy in my installation
(2.4.21 on Ubuntu). As soon as I set up the overlay (before I even
configure a user with a password policy or set up a default policy),
slapcatting the database results in a segmentation fault. I tried it on
2.4.23 and 2.4.17 with the same results. Here is the configuration I'm
using, and a backtrace from the 2.4.21 installation:
dn: cn=module{0}
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_hdb.la
olcModuleLoad: {1}autogroup.la
olcModuleLoad: {2}syncprov.la
olcModuleLoad: {3}smbk5pwd.la
olcModuleLoad: {4}ppolicy.la
dn: olcOverlay={3}ppolicy
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: {3}ppolicy
olcPPolicyHashCleartext: FALSE
olcPPolicyUseLockout: TRUE
olcPPolicyForwardUpdates: FALSE
structuralObjectClass: olcPPolicyConfig
(gdb) run
Starting program: /usr/sbin/slapcat -n1
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff242d840 in ppolicy_restrict (op=0x7fffffffd710,
rs=0x7fffffffd670) at
/usr/src/openldap/openldap-2.4.21/servers/slapd/overlays/ppolicy.c:1271
1271
/usr/src/openldap/openldap-2.4.21/servers/slapd/overlays/ppolicy.c: No
such file or directory.
in /usr/src/openldap/openldap-2.4.21/servers/slapd/overlays/ppolicy.c
(gdb) backtrace
#0 0x00007ffff242d840 in ppolicy_restrict (op=0x7fffffffd710,
rs=0x7fffffffd670) at
/usr/src/openldap/openldap-2.4.21/servers/slapd/overlays/ppolicy.c:1271
#1 0x00007ffff7f6ed3a in overlay_op_walk (op=0x7fffffffd710,
rs=0x7fffffffd670, which=<value optimized out>, oi=0x7ffff8320fc0,
on=0x7ffff8340d50)
at /usr/src/openldap/openldap-2.4.21/servers/slapd/backover.c:659
#2 0x00007ffff7f6f8ab in over_op_func (op=0x7fffffffd710,
rs=0xfffffffffffffff0, which=4294957776)
at /usr/src/openldap/openldap-2.4.21/servers/slapd/backover.c:721
#3 0x00007ffff2a4b141 in autogroup_db_open (be=<value optimized out>,
cr=<value optimized out>) at autogroup.c:1754
#4 0x00007ffff7f6e994 in over_db_open (be=<value optimized out>,
cr=0x7fffffffdfc0) at
/usr/src/openldap/openldap-2.4.21/servers/slapd/backover.c:155
#5 0x00007ffff7f1388c in backend_startup_one (be=0x7ffff8314e80,
cr=0x7fffffffdfc0) at
/usr/src/openldap/openldap-2.4.21/servers/slapd/backend.c:224
#6 0x00007ffff7f13a83 in backend_startup (be=0x7ffff8314e80) at
/usr/src/openldap/openldap-2.4.21/servers/slapd/backend.c:278
#7 0x00007ffff7f742cc in slap_tool_init (progname=<value optimized
out>, tool=2, argc=2, argv=0x7fffffffe5b8)
at /usr/src/openldap/openldap-2.4.21/servers/slapd/slapcommon.c:780
#8 0x00007ffff7f7335a in slapcat (argc=-9520, argv=<value optimized
out>) at /usr/src/openldap/openldap-2.4.21/servers/slapd/slapcat.c:51
#9 0x00007ffff7ee84f5 in main (argc=2, argv=0x7fffffffe5b8) at
/usr/src/openldap/openldap-2.4.21/servers/slapd/main.c:657
As soon as I remove olcOverlay={3}ppolicy from the backend database, the
problem disappears. The configuration isn't anything special so I don't
think it's a misconfiguration issue, but I figured I'd get a second
opinion from the list before submitting this issue as a bug to the ITS.
As always, all advice and input is appreciated.
-Ryan
12 years, 5 months
