openldap-technical November 2010

openldap-technical@openldap.org

86 participants
113 discussions

Virtual list view problem
by Venish Khant 31 May '16

31 May '16

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

4 11

Re: (ITS#6666) Feature Request: Triggers implementation
by Buchan Milne 23 May '11

23 May '11

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

7 18

Certificate authentication and back-ldap proxy
by Ubay Dorta Guerra 27 Dec '10

27 Dec '10

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

3 4

push replication with proxy and rwm overlay
by Gwenn Gueguen 13 Dec '10

13 Dec '10

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

1 1

slapcat, PROXIED attributeDescription inserted, and cron jobs
by btb＠bitrate.net 09 Dec '10

09 Dec '10

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

4 4

how to compile recent openldap on Centos 5.5
by Götz Reinicke - IT-Koordinator 06 Dec '10

06 Dec '10

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

8 12

Re: Want interesting restrictions to ldap auth on different servers to different users
by c0re 01 Dec '10

01 Dec '10

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.

2 2

ssf settings on server restart
by Christian Bösch 01 Dec '10

01 Dec '10

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

2 6

syncrepl with accesslog not replicating
by Dieter Klünter 30 Nov '10

30 Nov '10

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

3 11

slapcat segfaults when ppolicy overlay added
by Ryan Steele 30 Nov '10

30 Nov '10

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

2 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical November 2010