November 2010 - openldap-technical

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

cn=config and authz-regexp
by Julien Vehent 30 Nov '10

30 Nov '10

Hi list, I'm moving a LDAP directory on a freshly installed Debian Squeeze and I'm discovering cn=config. On my former installation, I have SASL configured using : --- authz-regexp "^uid=([^,]+).*,cn=[^,]*,cn=auth$" "ldap:///dc=domain,dc=net??sub?(uid=$1)" authz-policy to password-hash {CLEARTEXT} --- How do I translate this into cn=config directives ? I believe it should be stored into /etc/ldap/slapd.d/cn=config/olcDatabase\=\{1\}hdb.ldif is that correct ? Thanks, Julien

2 2

RE: Problems Enabling Authentication using Cyrus SASL
by Fernando Torrez 29 Nov '10

29 Nov '10

Hi all I got work sasl authentication to access ldap server by correcting two things: 1.- inserting the proxyuser's userpassword in clear text (userPassord=secret) 2.- fixing the proxyuser's authzTo atributte to authzTo: ldap:///ou=people,dc=plainjoe,dc=org??sub?(objectClass=account) (results at the end of this mail) As far as it can be seen, there's no need for cyrus-sasl for these matter but my final purpose is to enable Cyrus-sasl with openldap as backend to authenticate users for cyrus-imapd and postfix services. Any hints would be appreciated. Thanks to all for your support Fernando firewall:~ # ldapwhoami -U proxyuser -X u:test -Y digest-md5 SASL/DIGEST-MD5 authentication started Please enter your password: SASL username: u:test SASL SSF: 128 SASL data security layer installed. dn:uid=test,ou=people,dc=plainjoe,dc=org firewall:~ # ldapsearch -Y digest-md5 -U proxyuser -b 'dc=plainjoe,dc=org' '(objectclass=*)' SASL/DIGEST-MD5 authentication started Please enter your password: SASL username: proxyuser SASL SSF: 128 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <dc=plainjoe,dc=org> with scope subtree # filter: (objectclass=*)

3 4

Re: syncrepl with accesslog not replicating
by Quanah Gibson-Mount 29 Nov '10

29 Nov '10

--On Monday, November 29, 2010 10:46 PM +0100 Dieter Kluenter <dieter(a)dkluenter.de> wrote: > Quanah Gibson-Mount <quanah(a)zimbra.com> writes: > > OK, this is what I had, so going back to original configuration. You had scope specified, and the missing new line between the syncrepl and updateref clauses. Please keep this on the list. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Let user's modify some LDAP entry ?
by Frank Bonnet 29 Nov '10

29 Nov '10

Hello I'm searching for some web based software to let users modify "some" data in our LDAP database after having been authenticated. Typically I would like to let them the possiblity to modify their loginShell , password , phone number ... etc Does such software exists ? Thank you

2 3

Using shell database
by krishan kumar 29 Nov '10

29 Nov '10

Hello, I have compiled openldap-2.4.23 from source. Recently I am learning to use shell database so I try running searchexample.sh script file provided with the openldap sources. But I am not successful in doing so. I think script is not getting executed and I am not getting any search results. Search gives the following result-: #ldapsearch -x -D 'cn=Manager,dc=example,dc=com' -W -b 'dc=shell1,dc=com' '(uid=root)' Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=shell1,dc=com> with scope subtree # filter: (uid=root) # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 --------------------------------------------------------------------------- My slapd.conf section for shell database is as follows-: database shell suffix "dc=shell1,dc=com" search /usr/local/openldap-test/etc/openldap/searchexample.sh ---------------------------------------------------------------------------- When started slapd with -d 1 option, I am getting following debugging information upon executing above search example-: -------------------------------------------------------------------------------------------------------------- <output truncated>.. send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 17connection_get(17): got connid=1002 connection_read(17): checking for input on id=1002 ber_get_next ber_get_next: tag 0x30 len 53 contents: op tag 0x63, time 1291033804 ber_get_next conn=1002 op=1 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <dc=shell1,dc=com> <<< dnPrettyNormal: <dc=shell1,dc=com>, <dc=shell1,dc=com> ber_scanf fmt ({mm}) ber: ber_scanf fmt ({M}}) ber: ==> limits_get: conn=1002 op=1 self="cn=manager,dc=example,dc=com" this="dc=shell1,dc=com" execv failed shell: fgets failed: Success (0) str2result () expecting "RESULT" send_ldap_result: conn=1002 op=1 p=3 send_ldap_response: msgid=2 tag=101 err=0 ber_flush2: 14 bytes to sd 17 connection_get(17): got connid=1002 connection_read(17): checking for input on id=1002 ber_get_next ber_get_next: tag 0x30 len 5 contents: op tag 0x42, time 1291033804 ber_get_next conn=1002 op=2 do_unbind connection_close: conn=1002 sd=17 ---------------------------------------------------------------------------------------------------------------------- Please help me to got shell database working. Thanks.

1 0

OpenLDAP runs OK, Mac Mail and Address book do not display entries.
by Toomas Vendelin 29 Nov '10

29 Nov '10

Hi, I have set up an OpenLDAP server on a CentOS 5.5 machine and uploaded test data from ldif file. Apache directory studio connects to server nicely from my Mac and displays the records. Apple Mail and address book also seem to connect OK, but no search results returned in Address Book, and e-mails are not auto-completed in Mail. At the same time, I successfully connect to other publicly accessible servers, so it is probably a fault in my LDIF data. What is it? Do I need to use some schema specific to Apple? As for now, only the default ones are used. My LDIF data (all characters are fictional): Code: dn: dc=minu,dc=biz dc: minu objectClass: dcObject objectClass: organization o: Vendelin & Barilko dn: ou=people,dc=minu,dc=biz ou: people objectClass: organizationalUnit dn: cn=Deniska Borilko, ou=people,dc=minu,dc=biz cn: Deniska Borilko objectClass: inetOrgPerson sn: Borilko mail: denis(a)somedomain.com My LDAP settings both in Mail and address book: Code: Search base: ou=people,dc=minu,dc=biz Scope: subtree Thanks in advance! Toomas

2 1

Content-Based Access Control?
by Frank Rust 29 Nov '10

29 Nov '10

Hi all, would it be possible to configure a content-based access control? I have following configuration: my ldap contains user data. Some of the users are local ones and have a regular password entry. They shall be able to change their password. Other users are remotely authenticated with saslauthd. They shall not be able to change their 'password' which is just a redirection. Example: dn: uid=remoteuser,ou=People,dc=mydomain,dc=de uid: remoteuser cn: Adam Example uidNumber: 9007 gidNumber: 90 sn: Example userPassword: {SASL}remoteuser dn: uid=localuser,ou=People,dc=mydomain,dc=de uid: localuser cn: Bruce Somename uidNumber: 1001 gidNumber: 10 sn: Somename userPassword: {SHA}03de6c570bfe24bfc328ccd7ca46b76eadaf4334 User localuser shall be able to change his password, user remoteuser not. Can this be done by a fancy ACL entry, rejecting to change passwords starting with '{SASL}' ? Thanks in advance, Frank

2 2

Problem when trying to authenticate squid with openldap server
by Bruno Lamps 26 Nov '10

26 Nov '10

Hi everybody, I spent some days reading the ebook "Ldap for rocket scientists" ( zytrax.com/books/ldap/) and I've succesfully (I think it's a success =3 ) created a VM with debian lenny and openldap running. After that, I created another VM, running IPfire (www.ipfire.org) distro, this will be the firewall of the SMB I'm working for. Now I'm trying to authenticate the squid proxy, installed in IPFire distro, integrating it with my openldap server. A screenshot of my IPFire's webGUI and phpldapadmin webGUI can be seen at this topic: http://forum.ipfire.org/index.php?topic=3404.0 But the authentication isn't running, the browser using squid proxy keeps asking me for username and password. Suspecting that the webGUI could be making some mistake in squid config file, I started editing it's parameters manually. Right now, the ldap authentication line in my squid.conf looks like this: *auth_param basic program /usr/lib/squid/squid_ldap_auth -D "cn=admin,dc=pisolar" -w "mypassword" -b "ou=usuarios,dc=pisolar" -h 192.168.1.7 -v 3* * * *cn=admin,dc=pisolar *= my root user. * * *ou=usuarios,dc=pisolar *= the OU where my users are stored. * * I opened slapd in debug mode (slapd -d 255) in my openldap debian-powered VM, and this is the text shown when I try to authenticate in my browser: daemon: activity on 1 descriptor daemon: activity on: slap_listener_activate(8): daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 busy >>> slap_listener(ldap:///) daemon: listen=8, new connection on 13 daemon: added 13r (active) listener=(nil) daemon: activity on 2 descriptors daemon: activity on: 13r daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero daemon: activity on 1 descriptor daemon: activity on: 13r daemon: read active on 13 daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero connection_get(13) connection_get(13): got connid=0 connection_read(13): checking for input on id=0 ber_get_next ldap_read: want=8, got=8 0000: 30 34 02 01 01 60 2f 02 04...`/. ldap_read: want=46, got=46 0000: 01 03 04 20 75 69 64 3d 6c 61 6d 70 73 2c 6f 75 ... uid=lamps,ou 0010: 3d 75 73 75 61 72 69 6f 73 2c 64 63 3d 70 69 73 =usuarios,dc=pis 0020: 6f 6c 61 72 80 08 6c 34 77 64 30 67 67 30 olar..userpassword ber_get_next: tag 0x30 len 52 contents: ber_dump: buf=0xa0598a0 ptr=0xa0598a0 end=0xa0598d4 len=52 0000: 02 01 01 60 2f 02 01 03 04 20 75 69 64 3d 6c 61 ...`/.... uid=la 0010: 6d 70 73 2c 6f 75 3d 75 73 75 61 72 69 6f 73 2c mps,ou=usuarios, 0020: 64 63 3d 70 69 73 6f 6c 61 72 80 08 6c 34 77 64 dc=pisolar..userpass 0030: 30 67 67 30 word ber_get_next ldap_read: want=8 error=Resource temporarily unavailable daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero conn=0 op=0 do_bind ber_scanf fmt ({imt) ber: ber_dump: buf=0xa0598a0 ptr=0xa0598a3 end=0xa0598d4 len=49 0000: 60 2f 02 01 03 04 20 75 69 64 3d 6c 61 6d 70 73 `/.... uid=lamps 0010: 2c 6f 75 3d 75 73 75 61 72 69 6f 73 2c 64 63 3d ,ou=usuarios,dc= 0020: 70 69 73 6f 6c 61 72 80 08 6c 34 77 64 30 67 67 pisolar..userpasswor 0030: 30 d ber_scanf fmt (m}) ber: ber_dump: buf=0xa0598a0 ptr=0xa0598ca end=0xa0598d4 len=10 0000: 00 08 6c 34 77 64 30 67 67 30 ..userpassword >>> dnPrettyNormal: <uid=lamps,ou=usuarios,dc=pisolar> => ldap_bv2dn(uid=lamps,ou=usuarios,dc=pisolar,0) <= ldap_bv2dn(uid=lamps,ou=usuarios,dc=pisolar)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=lamps,ou=usuarios,dc=pisolar)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=lamps,ou=usuarios,dc=pisolar)=0 <<< dnPrettyNormal: <uid=lamps,ou=usuarios,dc=pisolar>, <uid=lamps,ou=usuarios,dc=pisolar> do_bind: version=3 dn="uid=lamps,ou=usuarios,dc=pisolar" method=128 ==> bdb_bind: dn: uid=lamps,ou=usuarios,dc=pisolar bdb_dn2entry("uid=lamps,ou=usuarios,dc=pisolar") => bdb_dn2id("dc=pisolar") <= bdb_dn2id: got id=0x1 => bdb_dn2id("ou=usuarios,dc=pisolar") <= bdb_dn2id: got id=0xb => bdb_dn2id("uid=lamps,ou=usuarios,dc=pisolar") <= bdb_dn2id: got id=0x10 entry_decode: "uid=lamps,ou=usuarios,dc=pisolar" <= entry_decode(uid=lamps,ou=usuarios,dc=pisolar) => access_allowed: auth access to "uid=lamps,ou=usuarios,dc=pisolar" "userPassword" requested => acl_get: [1] attr userPassword => slap_access_allowed: result not in cache (userPassword) => acl_mask: access to entry "uid=lamps,ou=usuarios,dc=pisolar", attr "userPassword" requested => acl_mask: to value by "", (=0) <= check a_dn_pat: cn=admin,dc=pisolar <= check a_dn_pat: anonymous <= acl_mask: [2] applying none(=0) (stop) <= acl_mask: [2] mask: none(=0) => slap_access_allowed: auth access denied by none(=0) => access_allowed: no more rules send_ldap_result: conn=0 op=0 p=3 send_ldap_result: err=49 matched="" text="" send_ldap_response: msgid=1 tag=97 err=49 ber_flush2: 14 bytes to sd 13 0000: 30 0c 02 01 01 61 07 0a 01 31 04 00 04 00 0....a...1.... ldap_write: want=14, written=14 0000: 30 0c 02 01 01 61 07 0a 01 31 04 00 04 00 0....a...1.... daemon: activity on 1 descriptor daemon: activity on: 13r daemon: read active on 13 daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero connection_get(13) connection_get(13): got connid=0 connection_read(13): checking for input on id=0 ber_get_next ldap_read: want=8, got=7 0000: 30 05 02 01 02 42 00 0....B. ber_get_next: tag 0x30 len 5 contents: ber_dump: buf=0xa0039c0 ptr=0xa0039c0 end=0xa0039c5 len=5 0000: 02 01 02 42 00 ...B. ber_get_next ldap_read: want=8, got=0 ber_get_next on fd 13 failed errno=0 (Success) connection_read(13): input error=-2 id=0, closing. connection_closing: readying conn=0 sd=13 for close daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero connection_close: deferring conn=0 sd=13 conn=0 op=1 do_unbind connection_resched: attempting closing conn=0 sd=13 connection_close: conn=0 sd=13 daemon: removing 13 daemon: activity on 1 descriptor daemon: activity on: slap_listener_activate(8): daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 busy >>> slap_listener(ldap:///) daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero ================================= I tried to set a lot of different config syntaxes at squid.conf, but it always come to the same kind of problem at slapd debug: After reading the user CN and his password, slapd fails to read something else (ldap_read: want=8 error=Resource temporarily unavailable) and then it doesn't authenticates. What I'm doing wrong? Is there any problem with my openldap server? With squid? =( I'd like to thank you all in advance for any support, and say sorry for my broken english. =D

3 5

Re: How to set Multiple base dn
by Hallvard B Furuseth 26 Nov '10

26 Nov '10

Please keep replies on the list. Then others can help when I'm not around. Laurent gobalraja writes: > In fact i need a complete split of the bases. The reason is that i need > duplication of cn in both domain and that is not possible in a single base > as the CN must be unique. I think you mean "dc" instead of "cn" here, but I don't think that's what you're supposed to mean:-) Maybe you mean the part of the DN below the database suffix must include the fully qualified domain name, like this? Domain here.org in database foo and there.org in database bar: database bdb suffix o=foo database bdb suffix o=bar Object names: o=foo dc=org,o=foo dc=here,dc=org,o=foo o=bar dc=org,o=foo dc=there,dc=org,o=bar or o=foo associatedDomain=here.org,o=foo o=bar associatedDomain=there.org,o=bar 'o' is short for organization name. associatedDomain, unlike dc, is for full domain names. For 'o' you need the organization object class, for associatedDomian you need domainRelatedObject from cosine.schema. Anyway, you don't need to use 'dc' if that does not suit you. Look for attributes and object classes that describe the actual structure of your intended directory tree. Though note that 'ou' (organizational unit) is often abused for "container" objects like "ou=people". >> Or write slapd.conf first according to the Admin Guide and then use >> sbin/slaptest -f <slapd.conf filename> -F <slapd.d directory> >> to convert to cn=config format. > > Is it safe to make successives updates of slapd.conf and then convert to the > slapd.d directory directly without removing it each time ? That's not supposed to work. Maybe you should just stay with slapd.conf instead? Or find some tool to help edit cn=config - there are supposed to be several, but I'm not up to date on that. -- Hallvard

1 0

Re: memberof overlay 2.4.08
by Marc Patermann 26 Nov '10

26 Nov '10

Hi, Pierangelo Masarati schrieb am 25.03.2008 18:52 Uhr: > LALOT Dominique wrote: >> I'm testing memberof overlay and I'd like to get it working >> properly for a database migration >> >> My tests showed me that's it's working when adding members in >> groups, but for an initial loading, it does not work. > Correct. This still seams to be true. >> I tested slapadd -q or slapadd without success. Could you tell us, >> or write something in the documentation to explain, the right way >> for an initial loading. > Currently, there is no solution besides writing a script that > populates the memberOf attribute in the LDIF file. > >> When we will be in production, I imagine that sometimes, we can >> get out of sync between members and memberof. What can we do in >> such case. > It should not happen. I have a lot of syncrepl consumers. For disaster recovery these are repopulated with slapadd and a recent provider dump. With overlay memberof this would not work any more, because the memberOf references are lost on this consumer until the "member" object changes, right? > The overlay should be reworked in order to have some means to repair > its connectivity. This is known but not hardly worked at. You could > open an ITS requesting this as an enhancement (or a bug fix, it's a > matter of taste). Is there any yet or do I have to do it? Marc

1 1

memberOF overlay - memberof-memberof-ad
by Marc Patermann 26 Nov '10

26 Nov '10

Hi, I installed a openldap latest 2.4.23 with a basic database setup: include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/yast.schema include /etc/openldap/schema/personaddon.schema loglevel config stats stats2 pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args modulepath /usr/lib/openldap/modules moduleload memberof.la moduleload refint.la access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to attrs=userPassword,userPKCS12 by self write by * auth access to attrs=shadowLastChange by self write by * read access to * by * read database bdb suffix "dc=my-domain,dc=com" checkpoint 1024 5 cachesize 10000 rootdn "cn=Manager,dc=my-domain,dc=com" rootpw secret directory /var/lib/ldap index objectClass eq index uid,cn,mail,member,sn,manager eq Then I included a standard memberof overlay config: overlay memberof memberof-group-oc groupOfNames memberof-member-ad member memberof-memberof-ad memberOf memberof-refint true This works fine (database population below). After that I configured a second memberof overlay like this: overlay memberof memberof-group-oc inetOrgPerson memberof-member-ad manager memberof-memberof-ad owner memberof-refint true memberof-dangling error I pointed from one inetOrgPerson object by attribute manager to another there this should be shown as "owner". For the latter I created a AUXILIARY objectclass to include the owner attribute to the inetOrgPerson object. But memberof-memberof-ad does not work - it is still memberOf and mot owner. Here is the dump (I removed some attributes like creatersname etc.): dn: dc=my-domain,dc=com objectClass: dcObject objectClass: domain dc: my-domain dn: ou=humans,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: humans dn: ou=accounts,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: accounts dn: uid=fa770001,ou=accounts,dc=my-domain,dc=com gidNumber: 9000 objectClass: posixAccount objectClass: top objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person uidNumber: 9000 uid: fa770001 homeDirectory: /home/fa770001 cn: Max Mustermann sn: Mustermann manager: employeeNumber=0001,ou=humans,dc=my-domain,dc=com dn: employeeNumber=0001,ou=humans,dc=my-domain,dc=com objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top objectClass: personAddon employeeNumber: 0001 sn: Mustermann cn: Max Mustermann memberOf: cn=users2,ou=groups,dc=my-domain,dc=com memberOf: uid=fa770002,ou=accounts,dc=my-domain,dc=com memberOf: uid=fa770001,ou=accounts,dc=my-domain,dc=com dn: ou=groups,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: groups dn: cn=users1,ou=groups,dc=my-domain,dc=com objectClass: groupOfNames objectClass: top cn: users1 member: employeeNumber=0002,ou=humans,dc=my-domain,dc=com dn: employeeNumber=0002,ou=humans,dc=my-domain,dc=com objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top objectClass: personAddon employeeNumber: 0002 sn: Hermann cn: Heinz Hermann memberOf: cn=users1,ou=groups,dc=my-domain,dc=com dn: uid=fa770002,ou=accounts,dc=my-domain,dc=com gidNumber: 9001 objectClass: posixAccount objectClass: top objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person uidNumber: 9001 uid: fa770002 homeDirectory: /home/fa770002 sn: Hermann cn: Heinz Hermann manager: employeeNumber=0001,ou=humans,dc=my-domain,dc=com dn: cn=users2,ou=groups,dc=my-domain,dc=com objectClass: groupOfNames objectClass: top cn: users2 member: employeeNumber=0001,ou=humans,dc=my-domain,dc=com And here is a ldapsearch for employeeNumber=0001, who is a member of cn=users2,ou=groups and a manager in uid=fa770001ou=accounts and uid=fa770002,ou=accounts - but the two memberof overlays both effectively use the default memberof-memberof-ad memberOf attribute. # 0001, humans, my-domain.com dn: employeeNumber=0001,ou=humans,dc=my-domain,dc=com objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top objectClass: personAddon employeeNumber: 0001 sn: Mustermann cn: Max Mustermann structuralObjectClass: inetOrgPerson entryUUID: ee628de6-8d8c-102f-9f77-3d86f090c509 creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20101126094021Z memberOf: cn=users2,ou=groups,dc=my-domain,dc=com memberOf: uid=fa770002,ou=accounts,dc=my-domain,dc=com memberOf: uid=fa770001,ou=accounts,dc=my-domain,dc=com modifiersName: cn=Manager,dc=my-domain,dc=com entryCSN: 20101126112349.873160Z#000000#000#000000 modifyTimestamp: 20101126112349Z entryDN: employeeNumber=0001,ou=humans,dc=my-domain,dc=com subschemaSubentry: cn=Subschema hasSubordinates: FALSE Is there something, I did wrong? Marc

1 0

Setting up primary/secondary LDAP servers with TLS/SSL enabled
by Konstantin Boyandin 26 Nov '10

26 Nov '10

Hello, I am using primary/secondary LDAP servers configuration, it works quite normal. I need to make LDAP authentication secure. I.e., I need both LDAP servers to provide LDAP over SSL/TLS, so that both primary and secondary LDAP server be used (mentioned in ldap.conf). I have to use self-signed SSL certificates, since the servers are located in intranet, they have no 'real' domain names. The problem is I can't figure out how to specify ldap.conf SSL parameters so that they could - verify LDAP server certificate - be used with both primary and secondary LDAP servers Also, I'd prefer to use TLS - how do I run slapd so that it provided TLS-aware connection on the standard port? Is it possible to set up slapd so that TLS be optional (for testing/transition purposes). I would greatly appreciate references to the relevant docs on these. Thank you. Sincerely, Konstantin

3 2

can't use godaddy SSL cert
by bluethundr 26 Nov '10

26 Nov '10

Hey list, I was having a similar SSL/openLDAP problem to this last week. I had a chance to look at this again today and it still appears to not be working. I called godaddy and had the last cert cancelled and reissued as I had mis-typed the name of the CN on the last one. I am trying to setup a Godaddy turbo SSL certificate with an openLDAP 2.4 server under FreeBSD 8.1. [root@LBSD2:/usr/home/bluethundr]#pkg_info | grep openldap openldap-sasl-client-2.4.23 Open source LDAP client implementation with SASL2 support openldap-sasl-server-2.4.23 Open source LDAP server implementation I have setup the certificate chain in my slapd.conf like so: [root@LBSD2:/usr/home/bluethundr]#grep -i tls /usr/local/etc/openldap/slapd.conf## TLS options for slapd TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCertificateFile /usr/local/etc/openldap/cacerts/LBSD2.summitnjhome.com.crt TLSCertificateKeyFile /usr/local/etc/openldap/cacerts/slapd.pem TLSCACertificateFile /usr/local/etc/openldap/cacerts/sf_issuing.crt I have tried each of the following certs with no luck in getting my cert to talk to it's CA: -rw-r--r-- 1 root bluethundr 2604 Nov 25 11:37 ca_bundle.crt -r--r----- 1 root ldap 4604 Nov 24 18:57 gd_bundle.crt -r--r----- 1 root ldap 1537 Nov 25 02:00 sf_issuing.crt and I get the same result for each when I attempt to connect to SSL on the LDAP server: [root@LCENT01:/tmp/Foswiki-1.1.2]#openssl s_client -connect ldap.example.com:389 -showcerts -CAfile sf_issuing.crt 13730:error:02001002:system library:fopen:No such file or directory:bss_file.c:122:fopen('sf_issuing.crt','r') 13730:error:2006D080:BIO routines:BIO_new_file:no such file:bss_file.c:125: 13730:error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib:by_file.c:279: CONNECTED(00000003) 13730:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188: ldapsearch -h ldap.example.com -d -1 -ZZ "dc=example,dc=com" TLS certificate verification: depth: 0, err: 20, subject: /O=LBSD2.summitnjhome.com/OU=Domain Control Validated/CN=LBSD2.summitnjhome.com, issuer: /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287 TLS certificate verification: Error, unable to get local issuer certificate tls_write: want=7, written=7 0000: 15 03 01 00 02 02 30 ......0 TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't connect. ldap_perror ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed It seems to indicate that it can't talk to it's CA... does anyone have any suggestions on how to make this work? thanks! -- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys B6D6EAC3

3 2

syncrepl problems
by Bram Cymet 25 Nov '10

25 Nov '10

Hi, I am trying to set up a syncrepl consumer. I have done this a number of times without any problem. The consumer seems to be connecting via TLS to the producer and authenticating but the consumer directory never gets populated. Here is the log from the producer: Nov 22 19:19:57 anubis slapd[24088]: slap_listener_activate(7): Nov 22 19:19:57 anubis slapd[24088]: >>> slap_listener(ldap://) Nov 22 19:19:57 anubis slapd[24088]: conn=1026 fd=15 ACCEPT from IP=172.20.150.141:38831 (IP=0.0.0.0:389) Nov 22 19:19:57 anubis slapd[24088]: connection_get(15) Nov 22 19:19:57 anubis slapd[24088]: connection_get(15): got connid=1026 Nov 22 19:19:57 anubis slapd[24088]: connection_read(15): checking for input on id=1026 Nov 22 19:19:57 anubis slapd[24088]: op tag 0x77, time 1290471597 Nov 22 19:19:57 anubis slapd[24088]: conn=1026 op=0 do_extended Nov 22 19:19:57 anubis slapd[24088]: conn=1026 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Nov 22 19:19:57 anubis slapd[24088]: do_extended: oid=1.3.6.1.4.1.1466.20037 Nov 22 19:19:57 anubis slapd[24088]: conn=1026 op=0 STARTTLS Nov 22 19:19:57 anubis slapd[24088]: send_ldap_extended: err=0 oid= len=0 Nov 22 19:19:57 anubis slapd[24088]: send_ldap_response: msgid=1 tag=120 err=0 Nov 22 19:19:57 anubis slapd[24088]: conn=1026 op=0 RESULT oid= err=0 text= Nov 22 19:19:58 anubis slapd[24088]: connection_get(15) Nov 22 19:19:58 anubis slapd[24088]: connection_get(15): got connid=1026 Nov 22 19:19:58 anubis slapd[24088]: connection_read(15): checking for input on id=1026 Nov 22 19:19:58 anubis slapd[24088]: connection_get(15) Nov 22 19:19:58 anubis slapd[24088]: connection_get(15): got connid=1026 Nov 22 19:19:58 anubis slapd[24088]: connection_read(15): checking for input on id=1026 Nov 22 19:19:58 anubis slapd[24088]: connection_read(15): unable to get TLS client DN, error=49 id=1026 Nov 22 19:19:58 anubis slapd[24088]: conn=1026 fd=15 TLS established tls_ssf=256 ssf=256 Nov 22 19:19:58 anubis slapd[24088]: connection_get(15) Nov 22 19:19:58 anubis slapd[24088]: connection_get(15): got connid=1026 Nov 22 19:19:58 anubis slapd[24088]: connection_read(15): checking for input on id=1026 Nov 22 19:19:58 anubis slapd[24088]: op tag 0x60, time 1290471598 Nov 22 19:19:58 anubis slapd[24088]: conn=1026 op=1 do_bind Nov 22 19:19:58 anubis slapd[24088]: >>> dnPrettyNormal: <uid=syncrepl,ou=system,dc=ls,dc=cbn> Nov 22 19:19:58 anubis slapd[24088]: <<< dnPrettyNormal: <uid=syncrepl,ou=system,dc=ls,dc=cbn>, <uid=syncrepl,ou=system,dc=ls,dc=cbn> Nov 22 19:19:58 anubis slapd[24088]: conn=1026 op=1 BIND dn="uid=syncrepl,ou=system,dc=ls,dc=cbn" method=128 Nov 22 19:19:58 anubis slapd[24088]: do_bind: version=3 dn="uid=syncrepl,ou=system,dc=ls,dc=cbn" method=128 Nov 22 19:19:58 anubis slapd[24088]: ==> hdb_bind: dn: uid=syncrepl,ou=system,dc=ls,dc=cbn Nov 22 19:19:58 anubis slapd[24088]: bdb_dn2entry("uid=syncrepl,ou=system,dc=ls,dc=cbn") Nov 22 19:19:58 anubis slapd[24088]: => access_allowed: result not in cache (userPassword) Nov 22 19:19:58 anubis slapd[24088]: => access_allowed: auth access to "uid=syncrepl,ou=system,dc=ls,dc=cbn" "userPassword" requested Nov 22 19:19:58 anubis slapd[24088]: => acl_get: [2] attr userPassword Nov 22 19:19:58 anubis slapd[24088]: => acl_mask: access to entry "uid=syncrepl,ou=system,dc=ls,dc=cbn", attr "userPassword" requested Nov 22 19:19:58 anubis slapd[24088]: => acl_mask: to value by "", (=0) Nov 22 19:19:58 anubis slapd[24088]: <= check a_dn_pat: uid=syncrepl,ou=system,dc=ls,dc=cbn Nov 22 19:19:58 anubis slapd[24088]: <= check a_dn_pat: * Nov 22 19:19:58 anubis slapd[24088]: <= acl_mask: [2] applying +0 (break) Nov 22 19:19:58 anubis slapd[24088]: <= acl_mask: [2] mask: =0 Nov 22 19:19:58 anubis slapd[24088]: => acl_get: [3] attr userPassword Nov 22 19:19:58 anubis slapd[24088]: => acl_mask: access to entry "uid=syncrepl,ou=system,dc=ls,dc=cbn", attr "userPassword" requested Nov 22 19:19:58 anubis slapd[24088]: => acl_mask: to value by "", (=0) Nov 22 19:19:58 anubis slapd[24088]: <= check a_dn_pat: self Nov 22 19:19:58 anubis slapd[24088]: <= check a_dn_pat: * Nov 22 19:19:58 anubis slapd[24088]: <= acl_mask: [2] applying auth(=xd) (stop) Nov 22 19:19:58 anubis slapd[24088]: <= acl_mask: [2] mask: auth(=xd) Nov 22 19:19:58 anubis slapd[24088]: => slap_access_allowed: auth access granted by auth(=xd) Nov 22 19:19:58 anubis slapd[24088]: => access_allowed: auth access granted by auth(=xd) Nov 22 19:19:58 anubis slapd[24088]: conn=1026 op=1 BIND dn="uid=syncrepl,ou=system,dc=ls,dc=cbn" mech=SIMPLE ssf=0 Nov 22 19:19:58 anubis slapd[24088]: do_bind: v3 bind: "uid=syncrepl,ou=system,dc=ls,dc=cbn" to "uid=syncrepl,ou=system,dc=ls,dc=cbn" Nov 22 19:19:58 anubis slapd[24088]: send_ldap_result: conn=1026 op=1 p=3 Nov 22 19:19:58 anubis slapd[24088]: send_ldap_result: err=0 matched="" text="" Nov 22 19:19:58 anubis slapd[24088]: send_ldap_response: msgid=2 tag=97 err=0 Nov 22 19:19:58 anubis slapd[24088]: conn=1026 op=1 RESULT tag=97 err=0 text= Nov 22 19:19:58 anubis slapd[24088]: connection_get(15) Nov 22 19:19:58 anubis slapd[24088]: connection_get(15): got connid=1026 Nov 22 19:19:58 anubis slapd[24088]: connection_read(15): checking for input on id=1026 Nov 22 19:19:58 anubis slapd[24088]: op tag 0x63, time 1290471598 Nov 22 19:19:58 anubis slapd[24088]: conn=1026 op=2 do_search Nov 22 19:19:58 anubis slapd[24088]: >>> dnPrettyNormal: <dc=ls,dc=cbn> Nov 22 19:19:58 anubis slapd[24088]: <<< dnPrettyNormal: <dc=ls,dc=cbn>, <dc=ls,dc=cbn> Nov 22 19:19:58 anubis slapd[24088]: SRCH "dc=ls,dc=cbn" 2 0 Nov 22 19:19:58 anubis slapd[24088]: 0 0 0 Nov 22 19:19:58 anubis slapd[24088]: filter: (objectClass=*) Nov 22 19:19:58 anubis slapd[24088]: => get_ctrls Nov 22 19:19:58 anubis slapd[24088]: => get_ctrls: oid="1.3.6.1.4.1.4203.1.9.1.1" (noncritical) Nov 22 19:19:58 anubis slapd[24088]: => get_ctrls: oid="2.16.840.1.113730.3.4.2" (critical) Nov 22 19:19:58 anubis slapd[24088]: <= get_ctrls: n=2 rc=0 err="" Nov 22 19:19:58 anubis slapd[24088]: attrs: Nov 22 19:19:58 anubis slapd[24088]: * Nov 22 19:19:58 anubis slapd[24088]: + Nov 22 19:19:58 anubis slapd[24088]: Nov 22 19:19:58 anubis slapd[24088]: conn=1026 op=2 SRCH base="dc=ls,dc=cbn" scope=2 deref=0 filter="(objectClass=*)" Nov 22 19:19:58 anubis slapd[24088]: conn=1026 op=2 SRCH attr=* + Nov 22 19:19:58 anubis slapd[24088]: ==> limits_get: conn=1026 op=2 self="uid=syncrepl,ou=system,dc=ls,dc=cbn" this="dc=ls,dc=cbn" Nov 22 19:19:58 anubis slapd[24088]: <== limits_get: type=DN match=EXACT dn="uid=syncrepl,ou=system,dc=ls,dc=cbn" Nov 22 19:19:58 anubis slapd[24088]: send_ldap_result: conn=1026 op=2 p=3 Nov 22 19:19:58 anubis slapd[24088]: send_ldap_result: err=0 matched="" text="" Nov 22 19:19:58 anubis slapd[24088]: send_ldap_response: msgid=3 tag=101 err=0 Nov 22 19:19:58 anubis slapd[24088]: conn=1026 op=2 SEARCH RESULT tag=101 err=0 nentries=0 text= Nov 22 19:19:58 anubis slapd[24088]: connection_get(15) Nov 22 19:19:58 anubis slapd[24088]: connection_get(15): got connid=1026 Nov 22 19:19:58 anubis slapd[24088]: connection_read(15): checking for input on id=1026 Nov 22 19:19:58 anubis slapd[24088]: op tag 0x42, time 1290471598 Nov 22 19:19:58 anubis slapd[24088]: ber_get_next on fd 15 failed errno=0 (Success) Nov 22 19:19:58 anubis slapd[24088]: conn=1026 op=3 do_unbind Nov 22 19:19:58 anubis slapd[24088]: conn=1026 op=3 UNBIND Nov 22 19:19:58 anubis slapd[24088]: connection_close: conn=1026 sd=15 Nov 22 19:19:58 anubis slapd[24088]: conn=1026 fd=15 closed Here is the log from the consumer: Nov 22 18:22:49 mgaauth1 slapd[12587]: daemon: shutdown requested and initiated. Nov 22 18:22:49 mgaauth1 slapd[12587]: slapd shutdown: waiting for 0 operations/tasks to finish Nov 22 18:22:49 mgaauth1 slapd[12587]: slapd shutdown: initiated Nov 22 18:22:49 mgaauth1 slapd[12587]: ====> bdb_cache_release_all Nov 22 18:22:49 mgaauth1 slapd[12587]: slapd destroy: freeing system resources. Nov 22 18:22:49 mgaauth1 slapd[12587]: syncinfo_free: rid=001 Nov 22 18:22:49 mgaauth1 slapd[12587]: syncinfo_free: rid=002 Nov 22 18:22:49 mgaauth1 slapd[12587]: slapd stopped. Nov 22 18:22:52 mgaauth1 slapd[12638]: @(#) $OpenLDAP: slapd 2.4.20 (Jun 16 2010 10:21:06) $ abuild@anonymi:/usr/src/packages/BUILD/openldap-2.4.20/servers/slapd Nov 22 18:22:52 mgaauth1 slapd[12638]: daemon: IPv6 socket() failed errno=97 (Address family not supported by protocol) Nov 22 18:22:52 mgaauth1 slapd[12638]: daemon: IPv6 socket() failed errno=97 (Address family not supported by protocol) Nov 22 18:22:52 mgaauth1 slapd[12638]: ldif_read_file: read entry file: "/etc/openldap/slapd.d/cn=config/cn=schema.ldif" Nov 22 18:22:52 mgaauth1 slapd[12638]: => str2entry: "dn: cn=schema objectClass: olcSchemaConfig cn: schema structuralObjectClass: olcSchemaConfig entryUUID: 1a05f3b8-8ade-102f-8d02-5da984889200 creatorsName: cn=config createTimestamp: 20101122234350Z entryCSN: 20101122234350.437126Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20101122234350Z " Nov 22 18:22:52 mgaauth1 slapd[12638]: >>> dnPrettyNormal: <cn=schema> Nov 22 18:22:52 mgaauth1 slapd[12638]: <<< dnPrettyNormal: <cn=schema>, <cn=schema> Nov 22 18:22:52 mgaauth1 slapd[12638]: >>> dnNormalize: <cn=config> Nov 22 18:22:52 mgaauth1 slapd[12638]: <<< dnNormalize: <cn=config> Nov 22 18:22:52 mgaauth1 slapd[12638]: >>> dnNormalize: <cn=config> Nov 22 18:22:52 mgaauth1 slapd[12638]: <<< dnNormalize: <cn=config> Nov 22 18:22:52 mgaauth1 slapd[12638]: <= str2entry(cn=schema) -> 0x7ff49ab19758 Nov 22 18:22:52 mgaauth1 slapd[12638]: ldif_read_file: read entry file: "/etc/openldap/slapd.d/cn=config/cn=schema/cn={0}core.ldif" Nov 22 18:22:52 mgaauth1 slapd[12638]: => str2entry: "dn: cn={0}core objectClass: olcSchemaConfig cn: {0}core olcAttributeTypes: {0}( 2.5.4.2 NAME 'knowledgeInformation' DESC 'RFC2256: kno wledge information' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121. 1.15{32768} ) olcAttributeTypes: {1}( 2.5.4.4 NAME ( 'sn' 'surname' ) DESC 'RFC2256: last (f amily) name(s) for which the entity is known by' SUP name ) olcAttributeTypes: {2}( 2.5.4.5 NAME 'serialNumber' DESC 'RFC2256: serial numb er of the entity' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch S YNTAX 1.3.6.1.4.1.1466.115.121.1.44{64} ) olcAttributeTypes: {3}( 2.5.4.6 NAME ( 'c' 'countryName' ) DESC 'RFC4519: two- letter ISO-3166 country code' SUP name SYNTAX 1.3.6.1.4.1.1466.115.121.1.11 S INGLE-VALUE ) olcAttributeTypes: {4}( 2.5.4.7 NAME ( 'l' 'localityName' ) DESC 'RFC2256: loc ality which this object resides in' SUP name ) olcAttributeTypes: {5}( 2.5.4.8 NAME ( 'st' 'stateOrProvinceName' ) DESC 'RFC2 256: state or province which this object resides in' SUP name ) olcAttributeTypes: {6}( 2.5.4.9 NAME ( 'street' 'streetAddress' ) DESC 'RFC225 6: street address of this object' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreS ubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} ) olcAttributeTypes: {7}( 2.5.4.10 NAME ( 'o' 'organizationName' ) DESC 'RFC2256 : organization this object belongs to' SUP name ) olcAttributeTypes: {8}( 2.5.4.11 NAME ( 'ou' 'organizationalUnitName' ) DESC ' RFC2256: organizational unit this object belongs to' SUP name ) olcAttributeTypes: {9}( 2.5.4.12 NAME 'title' DESC 'RFC2256: title associated with the entity' SUP name ) olcAttributeTypes: {10}( 2.5.4.14 NAME 'searchGuide' DESC 'RFC2256: search gui de, deprecated by enhancedSearchGuide' SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 ) olcAttributeTypes: {11}( 2.5.4.15 NAME 'businessCategory' DESC 'RFC2256: busin ess category' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTA X 1.3.6.1.4.1.1466.115.121.1.15{128} ) olcAttributeTypes: {12}( 2.5.4.16 NAME 'postalAddress' DESC 'RFC2256: postal a ddress' EQUALITY caseIgnoreListMatch SUBSTR caseIgnoreListSubstringsMatch SYN TAX 1.3.6.1.4.1.1466.115.121.1.41 ) olcAttributeTypes: {13}( 2.5.4.17 NAME 'postalCode' DESC 'RFC2256: postal code ' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4. 1.1466.115.121.1.15{40} ) olcAttributeTypes: {14}( 2.5.4.18 NAME 'postOfficeBox' DESC 'RFC2256: Post Off ice Box' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3 .6.1.4.1.1466.115.121.1.15{40} ) olcAttributeTypes: {15}( 2.5.4.19 NAME 'physicalDeliveryOfficeName' DESC 'RFC2 256: Physical Delivery Office Name' EQUALITY caseIgnoreMatch SUBSTR caseIgnor eSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} ) olcAttributeTypes: {16}( 2.5.4.20 NAME 'telephoneNumber' DESC 'RFC2256: Teleph one Number' EQUALITY telephoneNumberMatch SUBSTR telephoneNumberSubstringsMat ch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32} ) olcAttributeTypes: {17}( 2.5.4.21 NAME 'telexNumber' DESC 'RFC2256: Telex Numb er' SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 ) olcAttributeTypes: {18}( 2.5.4.22 NAME 'teletexTerminalIdentifier' DESC 'RFC22 56: Teletex Terminal Identifier' SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 ) olcAttributeTypes: {19}( 2.5.4.23 NAME ( 'facsimileTelephoneNumber' 'fax' ) DE SC 'RFC2256: Facsimile (Fax) Telephone Number' SYNTAX 1.3.6.1.4.1.1466.115.12 1.1.22 ) olcAttributeTypes: {20}( 2.5.4.24 NAME 'x121Address' DESC 'RFC2256: X.121 Addr ess' EQUALITY numericStringMatch SUBSTR numericStringSubstringsMatch SYNTAX 1 .3.6.1.4.1.1466.115.121.1.36{15} ) olcAttributeTypes: {21}( 2.5.4.25 NAME 'internationaliSDNNumber' DESC 'RFC2256 : international ISDN number' EQUALITY numericStringMatch SUBSTR numericString SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{16} ) olcAttributeTypes: {22}( 2.5.4.26 NAME 'registeredAddress' DESC 'RFC2256: regi stered postal address' SUP postalAddress SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) olcAttributeTypes: {23}( 2.5.4.27 NAME 'destinationIndicator' DESC 'RFC2256: d estination indicator' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMat ch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{128} ) olcAttributeTypes: {24}( 2.5.4.28 NAME 'preferredDeliveryMethod' DESC 'RFC2256 : preferred delivery method' SYNTAX 1.3.6.1.4.1.1466.115.121.1.14 SINGLE-VALU E ) olcAttributeTypes: {25}( 2.5.4.29 NAME 'presentationAddress' DESC 'RFC2256: pr esentation address' EQUALITY presentationAddressMatch SYNTAX 1.3.6.1.4.1.1466 .115.121.1.43 SINGLE-VALUE ) olcAttributeTypes: {26}( 2.5.4.30 NAME 'supportedApplicationContext' DESC 'RFC 2256: supported application context' EQUALITY objectIdentifierMatch SYNTAX 1. 3.6.1.4.1.1466.115.121.1.38 ) olcAttributeTypes: {27}( 2.5.4.31 NAME 'member' DESC 'RFC2256: member of a gro up' SUP distinguishedName ) olcAttributeTypes: {28}( 2.5.4.32 NAME 'owner' DESC 'RFC2256: owner (of the ob ject)' SUP distinguishedName ) olcAttributeTypes: {29}( 2.5.4.33 NAME 'roleOccupant' DESC 'RFC2256: occupant of role' SUP distinguishedName ) olcAttributeTypes: {30}( 2.5.4.36 NAME 'userCertificate' DESC 'RFC2256: X.509 user certificate, use ;binary' EQUALITY certificateExactMatch SYNTAX 1.3.6.1. 4.1.1466.115.121.1.8 ) olcAttributeTypes: {31}( 2.5.4.37 NAME 'cACertificate' DESC 'RFC2256: X.509 CA certificate, use ;binary' EQUALITY certificateExactMatch SYNTAX 1.3.6.1.4.1. 1466.115.121.1.8 ) olcAttributeTypes: {32}( 2.5.4.38 NAME 'authorityRevocationList' DESC 'RFC2256 : X.509 authority revocation list, use ;binary' SYNTAX 1.3.6.1.4.1.1466.115.1 21.1.9 ) olcAttributeTypes: {33}( 2.5.4.39 NAME 'certificateRevocationList' DESC 'RFC22 56: X.509 certificate revocation list, use ;binary' SYNTAX 1.3.6.1.4.1.1466.1 15.121.1.9 ) olcAttributeTypes: {34}( 2.5.4.40 NAME 'crossCertificatePair' DESC 'RFC2256: X .509 cross certificate pair, use ;binary' SYNTAX 1.3.6.1.4.1.1466.115.121.1.1 0 ) olcAttributeTypes: {35}( 2.5.4.42 NAME ( 'givenName' 'gn' ) DESC 'RFC2256: fir st name(s) for which the entity is known by' SUP name ) olcAttributeTypes: {36}( 2.5.4.43 NAME 'initials' DESC 'RFC2256: initials of s ome or all of names, but not the surname(s).' SUP name ) olcAttributeTypes: {37}( 2.5.4.44 NAME 'generationQualifier' DESC 'RFC2256: na me qualifier indicating a generation' SUP name ) olcAttributeTypes: {38}( 2.5.4.45 NAME 'x500UniqueIdentifier' DESC 'RFC2256: X .500 unique identifier' EQUALITY bitStringMatch SYNTAX 1.3.6.1.4.1.1466.115.1 21.1.6 ) olcAttributeTypes: {39}( 2.5.4.46 NAME 'dnQualifier' DESC 'RFC2256: DN qualifi er' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgno reSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 ) olcAttributeTypes: {40}( 2.5.4.47 NAME 'enhancedSearchGuide' DESC 'RFC2256: en hanced search guide' SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 ) olcAttributeTypes: {41}( 2.5.4.48 NAME 'protocolInformation' DESC 'RFC2256: pr otocol information' EQUALITY protocolInformationMatch SYNTAX 1.3.6.1.4.1.1466 .115.121.1.42 ) olcAttributeTypes: {42}( 2.5.4.50 NAME 'uniqueMember' DESC 'RFC2256: unique me mber of a group' EQUALITY uniqueMemberMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1 .34 ) olcAttributeTypes: {43}( 2.5.4.51 NAME 'houseIdentifier' DESC 'RFC2256: house identifier' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) olcAttributeTypes: {44}( 2.5.4.52 NAME 'supportedAlgorithms' DESC 'RFC2256: su pported algorithms' SYNTAX 1.3.6.1.4.1.1466.115.121.1.49 ) olcAttributeTypes: {45}( 2.5.4.53 NAME 'deltaRevocationList' DESC 'RFC2256: de lta revocation list; use ;binary' SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 ) olcAttributeTypes: {46}( 2.5.4.54 NAME 'dmdName' DESC 'RFC2256: name of DMD' S UP name ) olcAttributeTypes: {47}( 2.5.4.65 NAME 'pseudonym' DESC 'X.520(4th): pseudonym for the object' SUP name ) olcAttributeTypes: {48}( 0.9.2342.19200300.100.1.3 NAME ( 'mail' 'rfc822Mailbo x' ) DESC 'RFC1274: RFC822 Mailbox' EQUALITY caseIgnoreIA5Match SUBSTR ca seIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) olcAttributeTypes: {49}( 0.9.234 Nov 22 18:22:52 mgaauth1 slapd[12638]: >>> dnPrettyNormal: <cn={0}core> Nov 22 18:22:52 mgaauth1 slapd[12638]: <<< dnPrettyNormal: <cn={0}core>, <cn={0}core> Nov 22 18:22:52 mgaauth1 slapd[12638]: >>> dnNormalize: <cn=config> Nov 22 18:22:52 mgaauth1 slapd[12638]: <<< dnNormalize: <cn=config> Nov 22 18:22:52 mgaauth1 slapd[12638]: >>> dnNormalize: <cn=config> Nov 22 18:22:52 mgaauth1 slapd[12638]: <<< dnNormalize: <cn=config> Nov 22 18:22:52 mgaauth1 slapd[12638]: <= str2entry(cn={0}core) -> 0x7ff49ab19758 Nov 22 18:22:52 mgaauth1 slapd[12638]: ldif_read_file: read entry file: "/etc/openldap/slapd.d/cn=config/cn=schema/cn={1}cosine.ldif" Nov 22 18:22:52 mgaauth1 slapd[12638]: => str2entry: "dn: cn={1}cosine objectClass: olcSchemaConfig cn: {1}cosine olcAttributeTypes: {0}( 0.9.2342.19200300.100.1.2 NAME 'textEncodedORAddress' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1. 1466.115.121.1.15{256} ) olcAttributeTypes: {1}( 0.9.2342.19200300.100.1.4 NAME 'info' DESC 'RFC1274: g eneral information' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{2048} ) olcAttributeTypes: {2}( 0.9.2342.19200300.100.1.5 NAME ( 'drink' 'favouriteDri nk' ) DESC 'RFC1274: favorite drink' EQUALITY caseIgnoreMatch SUBSTR caseIgno reSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) olcAttributeTypes: {3}( 0.9.2342.19200300.100.1.6 NAME 'roomNumber' DESC 'RFC1 274: room number' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch S YNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) olcAttributeTypes: {4}( 0.9.2342.19200300.100.1.7 NAME 'photo' DESC 'RFC1274: photo (G3 fax)' SYNTAX 1.3.6.1.4.1.1466.115.121.1.23{25000} ) olcAttributeTypes: {5}( 0.9.2342.19200300.100.1.8 NAME 'userClass' DESC 'RFC12 74: category of user' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMat ch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) olcAttributeTypes: {6}( 0.9.2342.19200300.100.1.9 NAME 'host' DESC 'RFC1274: h ost computer' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTA X 1.3.6.1.4.1.1466.115.121.1.15{256} ) olcAttributeTypes: {7}( 0.9.2342.19200300.100.1.10 NAME 'manager' DESC 'RFC127 4: DN of manager' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115 .121.1.12 ) olcAttributeTypes: {8}( 0.9.2342.19200300.100.1.11 NAME 'documentIdentifier' D ESC 'RFC1274: unique identifier of document' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) olcAttributeTypes: {9}( 0.9.2342.19200300.100.1.12 NAME 'documentTitle' DESC ' RFC1274: title of document' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstri ngsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) olcAttributeTypes: {10}( 0.9.2342.19200300.100.1.13 NAME 'documentVersion' DES C 'RFC1274: version of document' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSu bstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) olcAttributeTypes: {11}( 0.9.2342.19200300.100.1.14 NAME 'documentAuthor' DESC 'RFC1274: DN of author of document' EQUALITY distinguishedNameMatch SYNTAX 1 .3.6.1.4.1.1466.115.121.1.12 ) olcAttributeTypes: {12}( 0.9.2342.19200300.100.1.15 NAME 'documentLocation' DE SC 'RFC1274: location of document original' EQUALITY caseIgnoreMatch SUBSTR c aseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) olcAttributeTypes: {13}( 0.9.2342.19200300.100.1.20 NAME ( 'homePhone' 'homeTe lephoneNumber' ) DESC 'RFC1274: home telephone number' EQUALITY telephoneNumb erMatch SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121 .1.50 ) olcAttributeTypes: {14}( 0.9.2342.19200300.100.1.21 NAME 'secretary' DESC 'RFC 1274: DN of secretary' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.146 6.115.121.1.12 ) olcAttributeTypes: {15}( 0.9.2342.19200300.100.1.22 NAME 'otherMailbox' SYNTAX 1.3.6.1.4.1.1466.115.121.1.39 ) olcAttributeTypes: {16}( 0.9.2342.19200300.100.1.26 NAME 'aRecord' EQUALITY ca seIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {17}( 0.9.2342.19200300.100.1.27 NAME 'mDRecord' EQUALITY c aseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {18}( 0.9.2342.19200300.100.1.28 NAME 'mXRecord' EQUALITY c aseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {19}( 0.9.2342.19200300.100.1.29 NAME 'nSRecord' EQUALITY c aseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {20}( 0.9.2342.19200300.100.1.30 NAME 'sOARecord' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {21}( 0.9.2342.19200300.100.1.31 NAME 'cNAMERecord' EQUALIT Y caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {22}( 0.9.2342.19200300.100.1.38 NAME 'associatedName' DESC 'RFC1274: DN of entry associated with domain' EQUALITY distinguishedNameMatc h SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) olcAttributeTypes: {23}( 0.9.2342.19200300.100.1.39 NAME 'homePostalAddress' D ESC 'RFC1274: home postal address' EQUALITY caseIgnoreListMatch SUBSTR caseIg noreListSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) olcAttributeTypes: {24}( 0.9.2342.19200300.100.1.40 NAME 'personalTitle' DESC 'RFC1274: personal title' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstring sMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) olcAttributeTypes: {25}( 0.9.2342.19200300.100.1.41 NAME ( 'mobile' 'mobileTel ephoneNumber' ) DESC 'RFC1274: mobile telephone number' EQUALITY telephoneNum berMatch SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.12 1.1.50 ) olcAttributeTypes: {26}( 0.9.2342.19200300.100.1.42 NAME ( 'pager' 'pagerTelep honeNumber' ) DESC 'RFC1274: pager telephone number' EQUALITY telephoneNumber Match SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1 .50 ) olcAttributeTypes: {27}( 0.9.2342.19200300.100.1.43 NAME ( 'co' 'friendlyCount ryName' ) DESC 'RFC1274: friendly country name' EQUALITY caseIgnoreMatch SUBS TR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {28}( 0.9.2342.19200300.100.1.44 NAME 'uniqueIdentifier' DE SC 'RFC1274: unique identifer' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.14 66.115.121.1.15{256} ) olcAttributeTypes: {29}( 0.9.2342.19200300.100.1.45 NAME 'organizationalStatus ' DESC 'RFC1274: organizational status' EQUALITY caseIgnoreMatch SUBSTR caseI gnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) olcAttributeTypes: {30}( 0.9.2342.19200300.100.1.46 NAME 'janetMailbox' DESC ' RFC1274: Janet mailbox' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5Subst ringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) olcAttributeTypes: {31}( 0.9.2342.19200300.100.1.47 NAME 'mailPreferenceOption ' DESC 'RFC1274: mail preference option' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) olcAttributeTypes: {32}( 0.9.2342.19200300.100.1.48 NAME 'buildingName' DESC ' RFC1274: name of building' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstrin gsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) olcAttributeTypes: {33}( 0.9.2342.19200300.100.1.49 NAME 'dSAQuality' DESC 'RF C1274: DSA Quality' SYNTAX 1.3.6.1.4.1.1466.115.121.1.19 SINGLE-VALUE ) olcAttributeTypes: {34}( 0.9.2342.19200300.100.1.50 NAME 'singleLevelQuality' DESC 'RFC1274: Single Level Quality' SYNTAX 1.3.6.1.4.1.1466.115.121.1.13 SIN GLE-VALUE ) olcAttributeTypes: {35}( 0.9.2342.19200300.100.1.51 NAME 'subtreeMinimumQualit y' DESC 'RFC1274: Subtree Mininum Quality' SYNTAX 1.3.6.1.4.1.1466.115.121.1. 13 SINGLE-VALUE ) olcAttributeTypes: {36}( 0.9.2342.19200300.100.1.52 NAME 'subtreeMaximumQualit y' DESC 'RFC1274: Subtree Maximun Quality' SYNTAX 1.3.6.1.4.1.1466.115.121.1. 13 SINGLE-VALUE ) olcAttributeTypes: {37}( 0.9.2342.19200300.100.1.53 NAME 'personalSignature' D ESC 'RFC1274: Personal Signature (G3 fax)' SYNTAX 1.3.6.1.4.1.1466.115.121.1. 23 ) olcAttributeTypes: {38}( 0.9.2342.19200300.100.1.54 NAME 'dITRedirect' DESC 'R FC1274: DIT Redirect' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466 .115.121.1.12 ) olcAttributeTypes: {39}( 0.9.2342.19200300.100.1.55 NAME 'audio' DESC 'RFC1274 : audio (u-law)' SYNTAX 1.3.6.1.4.1.1466.115.121.1.4{25000} ) olcAttributeTypes: {40}( 0.9.2342.19200300.100.1.56 NAME 'documentPublisher' D ESC 'RFC1274: publisher of document' EQUALITY caseIgnoreMatch SUBSTR caseIgno reSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcObjectClasses: {0}( 0.9.2342.19200300.100.4.4 NAME ( 'pilotPerson' 'newPilo tPerson' ) SUP person STRUCTURAL MAY ( userid $ textEncodedORAddress $ rfc822 Mailbox $ favouriteDrink $ roomNumber $ userClass $ homeTelephoneNumber $ hom ePostalAddress $ secretary $ personalTitle $ preferredDeliveryMethod $ busine ssCategory $ janetMailbox $ otherMailbox $ mobileTelephoneNumber $ pagerTelep hone Nov 22 18:22:52 mgaauth1 slapd[12638]: >>> dnPrettyNormal: <cn={1}cosine> Nov 22 18:22:52 mgaauth1 slapd[12638]: <<< dnPrettyNormal: <cn={1}cosine>, <cn={1}cosine> Nov 22 18:22:52 mgaauth1 slapd[12638]: >>> dnNormalize: <cn=config> Nov 22 18:22:52 mgaauth1 slapd[12638]: <<< dnNormalize: <cn=config> Nov 22 18:22:52 mgaauth1 slapd[12638]: >>> dnNormalize: <cn=config> Nov 22 18:22:52 mgaauth1 slapd[12638]: <<< dnNormalize: <cn=config> Nov 22 18:22:52 mgaauth1 slapd[12638]: <= str2entry(cn={1}cosine) -> 0x7ff49ab19758 Nov 22 18:22:52 mgaauth1 slapd[12638]: ldif_read_file: read entry file: "/etc/openldap/slapd.d/cn=config/cn=schema/cn={2}inetorgperson.ldif" Nov 22 18:22:52 mgaauth1 slapd[12638]: => str2entry: "dn: cn={2}inetorgperson objectClass: olcSchemaConfig cn: {2}inetorgperson olcAttributeTypes: {0}( 2.16.840.1.113730.3.1.1 NAME 'carLicense' DESC 'RFC279 8: vehicle license or registration plate' EQUALITY caseIgnoreMatch SUBSTR cas eIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {1}( 2.16.840.1.113730.3.1.2 NAME 'departmentNumber' DESC ' RFC2798: identifies a department within an organization' EQUALITY caseIgnoreM atch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {2}( 2.16.840.1.113730.3.1.241 NAME 'displayName' DESC 'RFC 2798: preferred name to be used when displaying entries' EQUALITY caseIgnoreM atch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SI NGLE-VALUE ) olcAttributeTypes: {3}( 2.16.840.1.113730.3.1.3 NAME 'employeeNumber' DESC 'RF C2798: numerically identifies an employee within an organization' EQUALITY ca seIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.12 1.1.15 SINGLE-VALUE ) olcAttributeTypes: {4}( 2.16.840.1.113730.3.1.4 NAME 'employeeType' DESC 'RFC2 798: type of employment for a person' EQUALITY caseIgnoreMatch SUBSTR caseIgn oreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {5}( 0.9.2342.19200300.100.1.60 NAME 'jpegPhoto' DESC 'RFC2 798: a JPEG image' SYNTAX 1.3.6.1.4.1.1466.115.121.1.28 ) olcAttributeTypes: {6}( 2.16.840.1.113730.3.1.39 NAME 'preferredLanguage' DESC 'RFC2798: preferred written or spoken language for a person' EQUALITY caseIg noreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1. 15 SINGLE-VALUE ) olcAttributeTypes: {7}( 2.16.840.1.113730.3.1.40 NAME 'userSMIMECertificate' D ESC 'RFC2798: PKCS#7 SignedData used to support S/MIME' SYNTAX 1.3.6.1.4.1.14 66.115.121.1.5 ) olcAttributeTypes: {8}( 2.16.840.1.113730.3.1.216 NAME 'userPKCS12' DESC 'RFC2 798: personal identity information, a PKCS #12 PFX' SYNTAX 1.3.6.1.4.1.1466.1 15.121.1.5 ) olcObjectClasses: {0}( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' DESC 'RFC2 798: Internet Organizational Person' SUP organizationalPerson STRUCTURAL MAY ( audio $ businessCategory $ carLicense $ departmentNumber $ displayName $ em ployeeNumber $ employeeType $ givenName $ homePhone $ homePostalAddress $ ini tials $ jpegPhoto $ labeledURI $ mail $ manager $ mobile $ o $ pager $ photo $ roomNumber $ secretary $ uid $ userCertificate $ x500uniqueIdentifier $ pre ferredLanguage $ userSMIMECertificate $ userPKCS12 ) ) structuralObjectClass: olcSchemaConfig entryUUID: 1a06766c-8ade-102f-8d05-5da984889200 creatorsName: cn=config createTimestamp: 20101122234350Z entryCSN: 20101122234350.440473Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20101122234350Z " Nov 22 18:22:52 mgaauth1 slapd[12638]: >>> dnPrettyNormal: <cn={2}inetorgperson> Nov 22 18:22:52 mgaauth1 slapd[12638]: <<< dnPrettyNormal: <cn={2}inetorgperson>, <cn={2}inetorgperson> Nov 22 18:22:52 mgaauth1 slapd[12638]: >>> dnNormalize: <cn=config> Nov 22 18:22:52 mgaauth1 slapd[12638]: <<< dnNormalize: <cn=config> Nov 22 18:22:52 mgaauth1 slapd[12638]: >>> dnNormalize: <cn=config> Nov 22 18:22:52 mgaauth1 slapd[12638]: <<< dnNormalize: <cn=config> Nov 22 18:22:52 mgaauth1 slapd[12638]: <= str2entry(cn={2}inetorgperson) -> 0x7ff49ab19758 Nov 22 18:22:53 mgaauth1 slapd[12638]: ldif_read_file: read entry file: "/etc/openldap/slapd.d/cn=config/cn=schema/cn={3}rfc2307bis.ldif" Nov 22 18:22:53 mgaauth1 slapd[12638]: => str2entry: "dn: cn={3}rfc2307bis objectClass: olcSchemaConfig cn: {3}rfc2307bis olcAttributeTypes: {0}( 1.3.6.1.1.1.1.2 NAME 'gecos' DESC 'The GECOS field; th e common name' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatc h SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) olcAttributeTypes: {1}( 1.3.6.1.1.1.1.3 NAME 'homeDirectory' DESC 'The absolut e path to the home directory' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1 466.115.121.1.26 SINGLE-VALUE ) olcAttributeTypes: {2}( 1.3.6.1.1.1.1.4 NAME 'loginShell' DESC 'The path to th e login shell' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.2 6 SINGLE-VALUE ) olcAttributeTypes: {3}( 1.3.6.1.1.1.1.5 NAME 'shadowLastChange' EQUALITY integ erMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: {4}( 1.3.6.1.1.1.1.6 NAME 'shadowMin' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: {5}( 1.3.6.1.1.1.1.7 NAME 'shadowMax' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: {6}( 1.3.6.1.1.1.1.8 NAME 'shadowWarning' EQUALITY integerM atch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: {7}( 1.3.6.1.1.1.1.9 NAME 'shadowInactive' EQUALITY integer Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: {8}( 1.3.6.1.1.1.1.10 NAME 'shadowExpire' EQUALITY integerM atch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: {9}( 1.3.6.1.1.1.1.11 NAME 'shadowFlag' EQUALITY integerMat ch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: {10}( 1.3.6.1.1.1.1.12 NAME 'memberUid' EQUALITY caseExactI A5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {11}( 1.3.6.1.1.1.1.13 NAME 'memberNisNetgroup' EQUALITY ca seExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.11 5.121.1.26 ) olcAttributeTypes: {12}( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple' DESC 'Netgr oup triple' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {13}( 1.3.6.1.1.1.1.15 NAME 'ipServicePort' DESC 'Service p ort number' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE -VALUE ) olcAttributeTypes: {14}( 1.3.6.1.1.1.1.16 NAME 'ipServiceProtocol' DESC 'Servi ce protocol name' SUP name ) olcAttributeTypes: {15}( 1.3.6.1.1.1.1.17 NAME 'ipProtocolNumber' DESC 'IP pro tocol number' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SING LE-VALUE ) olcAttributeTypes: {16}( 1.3.6.1.1.1.1.18 NAME 'oncRpcNumber' DESC 'ONC RPC nu mber' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: {17}( 1.3.6.1.1.1.1.19 NAME 'ipHostNumber' DESC 'IPv4 addre sses as a dotted decimal omitting leading zeros or IPv6 addresses as de fined in RFC2373' SUP name ) olcAttributeTypes: {18}( 1.3.6.1.1.1.1.20 NAME 'ipNetworkNumber' DESC 'IP netw ork as a dotted decimal, eg. 192.168, omitting leading zeros' SUP name SINGLE-VALUE ) olcAttributeTypes: {19}( 1.3.6.1.1.1.1.21 NAME 'ipNetmaskNumber' DESC 'IP netm ask as a dotted decimal, eg. 255.255.255.0, omitting leading zeros' EQU ALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) olcAttributeTypes: {20}( 1.3.6.1.1.1.1.22 NAME 'macAddress' DESC 'MAC address in maximal, colon separated hex notation, eg. 00:00:92:90:ee:e2' EQUALI TY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {21}( 1.3.6.1.1.1.1.23 NAME 'bootParameter' DESC 'rpc.bootp aramd parameter' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1 .26 ) olcAttributeTypes: {22}( 1.3.6.1.1.1.1.24 NAME 'bootFile' DESC 'Boot image nam e' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {23}( 1.3.6.1.1.1.1.26 NAME 'nisMapName' DESC 'Name of a A generic NIS map' SUP name ) olcAttributeTypes: {24}( 1.3.6.1.1.1.1.27 NAME 'nisMapEntry' DESC 'A generic N IS entry' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTA X 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) olcAttributeTypes: {25}( 1.3.6.1.1.1.1.28 NAME 'nisPublicKey' DESC 'NIS public key' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-V ALUE ) olcAttributeTypes: {26}( 1.3.6.1.1.1.1.29 NAME 'nisSecretKey' DESC 'NIS secret key' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-V ALUE ) olcAttributeTypes: {27}( 1.3.6.1.1.1.1.30 NAME 'nisDomain' DESC 'NIS domain' E QUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26) olcAttributeTypes: {28}( 1.3.6.1.1.1.1.31 NAME 'automountMapName' DESC 'automo unt Map Name' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch S YNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) olcAttributeTypes: {29}( 1.3.6.1.1.1.1.32 NAME 'automountKey' DESC 'Automount Key value' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNT AX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) olcAttributeTypes: {30}( 1.3.6.1.1.1.1.33 NAME 'automountInformation' DESC 'Au tomount information' EQUALITY caseExactIA5Match SUBSTR caseExactIA5Substrings Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) olcObjectClasses: {0}( 1.3.6.1.1.1.2.0 NAME 'posixAccount' SUP top AUXILIARY D ESC 'Abstraction of an account with POSIX attributes' MUST ( cn $ uid $ uidNu mber $ gidNumber $ homeDirectory ) MAY ( userPassword $ loginShell $ gecos $ description ) ) olcObjectClasses: {1}( 1.3.6.1.1.1.2.1 NAME 'shadowAccount' SUP top AUXILIARY DESC 'Additional attributes for shadow passwords' MUST uid MAY ( userPassword $ description $ shadowLastChange $ shadowMin $ shadowMax $ shado wWarning $ shadowInactive $ shadowExpire $ shadowFlag ) ) olcObjectClasses: {2}( 1.3.6.1.1.1.2.2 NAME 'posixGroup' SUP top AUXILIARY DES C 'Abstraction of a group of accounts' MUST gidNumber MAY ( userPassword $ me mberUid $ description ) ) olcObjectClasses: {3}( 1.3.6.1.1.1.2.3 NAME 'ipService' SUP top STRUCTURAL DES C 'Abstraction an Internet Protocol service. Maps an IP port and protoc ol (such as tcp or udp) to one or more names; the distinguished value o f the cn attribute denotes the services canonical name' MUST ( cn $ ipServicePort $ ipServiceProtocol ) MAY description ) olcObjectClasses: {4}( 1.3.6.1.1.1.2.4 NAME 'ipProtocol' SUP top STRUCTURAL DE SC 'Abstraction of an IP protocol. Maps a protocol number to one or mor e names. The distinguished value of the cn attribute denotes the protoc ols canonical name' MUST ( cn $ ipProtocolNumber ) MAY description ) olcObjectClasses: {5}( 1.3.6.1.1.1.2.5 NAME 'oncRpc' SUP top STRUCTURAL DESC ' Abstraction of an Open Network Computing (ONC) [RFC1057] Remote Procedur e Call (RPC) binding. This class maps an ONC RPC number to a name. The distinguished value of the cn attribute denotes the RPC services can onical name' MUST ( cn $ oncRpcNumber ) MAY description ) olcObjectClasses: {6}( 1.3.6.1.1.1.2.6 NAME 'ipHost' SUP top AUXILIARY DESC 'A bstraction of a host, an IP device. The distinguished value of the cn a ttribute denotes the hosts canonical name. Device SHOULD be used as a s tructural class' MUST ( cn $ ipHostNumber ) MAY ( userPassword $ l $ descript ion $ manager ) ) olcObjectClasses: {7}( 1.3.6.1.1.1.2.7 NAME 'ipNetwork' SUP top STRUCTURAL DES C 'Abstraction of a network. The distinguished value of the cn attribut e denotes the networks canonical name' MUST ipNetworkNumber MAY ( cn $ ipNetm askNumber $ l $ description $ manager ) ) olcObjectClasses: {8}( 1.3.6.1.1.1.2.8 NAME 'nisNetgroup' SUP top STRUCTURAL D ESC 'Abstraction of a netgroup. May refer to other netgroups' MUST cn MAY ( n isNetgroupTriple $ memberNisNetgroup $ description ) ) olcObjectClasses: {9}( 1.3.6.1.1.1.2.9 NAME 'nisMap' SUP top STRUCTURAL DESC ' A generic abstraction of a NIS map' MUST nisMapName MAY description ) olcObjectClasses: {10}( 1.3.6.1.1.1.2.10 NAME 'nisObject' SUP top STRUCTURAL D ESC 'An entry in a NIS map' MUST ( cn $ nisMapE Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnPrettyNormal: <cn={3}rfc2307bis> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnPrettyNormal: <cn={3}rfc2307bis>, <cn={3}rfc2307bis> Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: <= str2entry(cn={3}rfc2307bis) -> 0x7ff49ab19758 Nov 22 18:22:53 mgaauth1 slapd[12638]: ldif_read_file: read entry file: "/etc/openldap/slapd.d/cn=config/cn=schema/cn={4}yast.ldif" Nov 22 18:22:53 mgaauth1 slapd[12638]: => str2entry: "dn: cn={4}yast objectClass: olcSchemaConfig cn: {4}yast olcObjectIdentifier: {0}SUSE 1.3.6.1.4.1.7057 olcObjectIdentifier: {1}SUSE.YaST SUSE:10.1 olcObjectIdentifier: {2}SUSE.YaST.ModuleConfig SUSE:10.1.2 olcObjectIdentifier: {3}SUSE.YaST.ModuleConfig.OC SUSE.YaST.ModuleConfig:1 olcObjectIdentifier: {4}SUSE.YaST.ModuleConfig.Attr SUSE.YaST.ModuleConfig:2 olcAttributeTypes: {0}( SUSE.YaST.ModuleConfig.Attr:2 NAME ( 'suseDefaultBase' ) DESC 'Base DN where new Objects should be created by default' EQUALITY dis tinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) olcAttributeTypes: {1}( SUSE.YaST.ModuleConfig.Attr:3 NAME ( 'suseNextUniqueId ' ) DESC 'Next unused unique ID, can be used to generate directory wide uniqe IDs' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1. 1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: {2}( SUSE.YaST.ModuleConfig.Attr:4 NAME ( 'suseMinUniqueId' ) DESC 'lower Border for Unique IDs' EQUALITY integerMatch ORDERING integerO rderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: {3}( SUSE.YaST.ModuleConfig.Attr:5 NAME ( 'suseMaxUniqueId' ) DESC 'upper Border for Unique IDs' EQUALITY integerMatch ORDERING integerO rderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: {4}( SUSE.YaST.ModuleConfig.Attr:6 NAME ( 'suseDefaultTempl ate' ) DESC 'The DN of a template that should be used by default' EQUALITY di stinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) olcAttributeTypes: {5}( SUSE.YaST.ModuleConfig.Attr:7 NAME ( 'suseSearchFilter ' ) DESC 'Search filter to localize Objects' SYNTAX 1.3.6.1.4.1.1466.115.121. 1.15 SINGLE-VALUE ) olcAttributeTypes: {6}( SUSE.YaST.ModuleConfig.Attr:11 NAME ( 'suseDefaultValu e' ) DESC 'an Attribute-Value-Assertions to define defaults for specific Attr ibutes' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {7}( SUSE.YaST.ModuleConfig.Attr:12 NAME ( 'suseNamingAttri bute' ) DESC 'AttributeType that should be used as the RDN' EQUALITY caseIgno reIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) olcAttributeTypes: {8}( SUSE.YaST.ModuleConfig.Attr:15 NAME ( 'suseSecondaryGr oup' ) DESC 'seconday group DN' EQUALITY distinguishedNameMatch SYNTAX 1.3.6. 1.4.1.1466.115.121.1.12 ) olcAttributeTypes: {9}( SUSE.YaST.ModuleConfig.Attr:16 NAME ( 'suseMinPassword Length' ) DESC 'minimum Password length for new users' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VAL UE ) olcAttributeTypes: {10}( SUSE.YaST.ModuleConfig.Attr:17 NAME ( 'suseMaxPasswor dLength' ) DESC 'maximum Password length for new users' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VA LUE ) olcAttributeTypes: {11}( SUSE.YaST.ModuleConfig.Attr:18 NAME ( 'susePasswordHa sh' ) DESC 'Hash method to use for new users' EQUALITY caseIgnoreIA5Match SYN TAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) olcAttributeTypes: {12}( SUSE.YaST.ModuleConfig.Attr:19 NAME ( 'suseSkelDir' ) DESC '' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcAttributeTypes: {13}( SUSE.YaST.ModuleConfig.Attr:20 NAME ( 'susePlugin' ) DESC 'plugin to use upon user/ group creation' EQUALITY caseIgnoreMatch SYNTA X 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {14}( SUSE.YaST.ModuleConfig.Attr:21 NAME ( 'suseMapAttribu te' ) DESC '' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {15}( SUSE.YaST.ModuleConfig.Attr:22 NAME ( 'suseImapServer ' ) DESC '' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) olcAttributeTypes: {16}( SUSE.YaST.ModuleConfig.Attr:23 NAME ( 'suseImapAdmin' ) DESC '' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) olcAttributeTypes: {17}( SUSE.YaST.ModuleConfig.Attr:24 NAME ( 'suseImapDefaul tQuota' ) DESC '' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) olcAttributeTypes: {18}( SUSE.YaST.ModuleConfig.Attr:25 NAME ( 'suseImapUseSsl ' ) DESC '' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121 .1.7 SINGLE-VALUE ) olcObjectClasses: {0}( SUSE.YaST.ModuleConfig.OC:2 NAME 'suseModuleConfigurati on' SUP top STRUCTURAL DESC 'Contains configuration of Management Modu les' MUST ( cn ) MAY ( suseDefaultBase )) olcObjectClasses: {1}( SUSE.YaST.ModuleConfig.OC:3 NAME 'suseUserConfiguration ' SUP suseModuleConfiguration STRUCTURAL DESC 'Configuration of user m anagement tools' MAY ( suseMinPasswordLength $ suseMaxPasswordLength $ susePasswordHash $ suseSkelDir $ suseNextUniqueId $ suseMinUniqueId $ suseMaxUniqueId $ suseDefaultTemplate $ suseSearchFilter $ suseMapAttribute )) olcObjectClasses: {2}( SUSE.YaST.ModuleConfig.OC:4 NAME 'suseObjectTemplate' SUP top STRUCTURAL DESC 'Base Class for Object-Templates' MUST ( cn ) M AY ( susePlugin $ suseDefaultValue $ suseNamingAttribute )) olcObjectClasses: {3}( SUSE.YaST.ModuleConfig.OC:5 NAME 'suseUserTemplate' SUP suseObjectTemplate STRUCTURAL DESC 'User object template' MUST ( cn ) MAY ( suseSecondaryGroup )) olcObjectClasses: {4}( SUSE.YaST.ModuleConfig.OC:6 NAME 'suseGroupTemplate' SUP suseObjectTemplate STRUCTURAL DESC 'Group object template' MUST ( cn )) olcObjectClasses: {5}( SUSE.YaST.ModuleConfig.OC:7 NAME 'suseGroupConfiguratio n' SUP suseModuleConfiguration STRUCTURAL DESC 'Configuration of user management tools' MAY ( suseNextUniqueId $ suseMinUniqueId $ suseMaxUni queId $ suseDefaultTemplate $ suseSearchFilter $ suseMapAttribut e )) olcObjectClasses: {6}( SUSE.YaST.ModuleConfig.OC:8 NAME 'suseCaConfiguration' SUP suseModuleConfiguration STRUCTURAL DESC 'Configuration of CA manage ment tools') olcObjectClasses: {7}( SUSE.YaST.ModuleConfig.OC:9 NAME 'suseDnsConfiguration' SUP suseModuleConfiguration STRUCTURAL DESC 'Configuration of mail se rver management tools') olcObjectClasses: {8}( SUSE.YaST.ModuleConfig.OC:10 NAME 'suseDhcpConfiguratio n' SUP suseModuleConfiguration STRUCTURAL DESC 'Configuration of DHCP server management tools') olcObjectClasses: {9}( SUSE.YaST.ModuleConfig.OC:11 NAME 'suseMailConfiguratio n' SUP suseModuleConfiguration STRUCTURAL DESC 'Configuration of IMAP user management tools' MUST ( suseImapServer $ suseImapAdmin $ suseImap DefaultQuota $ suseImapUseSsl )) structuralObjectClass: olcSchemaConfig entryUUID: 1a06ad4e-8ade-102f-8d07-5da984889200 creatorsName: cn=config createTimestamp: 20101122234350Z entryCSN: 20101122234350.441878Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20101122234350Z " Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnPrettyNormal: <cn={4}yast> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnPrettyNormal: <cn={4}yast>, <cn={4}yast> Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: <= str2entry(cn={4}yast) -> 0x7ff49ab19758 Nov 22 18:22:53 mgaauth1 slapd[12638]: ldif_read_file: read entry file: "/etc/openldap/slapd.d/cn=config/cn=schema/cn={5}kerberos.ldif" Nov 22 18:22:53 mgaauth1 slapd[12638]: => str2entry: "dn: cn={5}kerberos objectClass: olcSchemaConfig cn: {5}kerberos olcAttributeTypes:: ezB9KCAyLjE2Ljg0MC4xLjExMzcxOS4xLjMwMS40LjEuMSAgICAgICAgIC AgICAgIE5BTUUgJ2tyYlByaW5jaXBhbE5hbWUnICAgICAgICAgICAgICAgRVFVQUxJVFkgY2FzZUV 4YWN0SUE1TWF0Y2ggCVNVQlNUUiBjYXNlRXhhY3RTdWJzdHJpbmdzTWF0Y2ggICAgICAgICAgICAg ICBTWU5UQVggMS4zLjYuMS40LjEuMTQ2Ni4xMTUuMTIxLjEuMjYp olcAttributeTypes: {1}( 1.2.840.113554.1.4.1.6.1 NAME 'krbCanoni calName' EQUALITY caseExactIA5Match SUBSTR caseEx actSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE) olcAttributeTypes: {2}( 2.16.840.1.113719.1.301.4.3.1 NAME 'krbP rincipalType' EQUALITY integerMatch SYNTAX 1.3.6. 1.4.1.1466.115.121.1.27 SINGLE-VALUE) olcAttributeTypes: {3}( 2.16.840.1.113719.1.301.4.5.1 NAME 'krbU PEnabled' DESC 'Boolean' SYNTAX 1.3.6.1.4.1.1466. 115.121.1.7 SINGLE-VALUE) olcAttributeTypes: {4}( 2.16.840.1.113719.1.301.4.6.1 NAME 'krbP rincipalExpiration' EQUALITY generalizedTimeMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE) olcAttributeTypes: {5}( 2.16.840.1.113719.1.301.4.8.1 NAME 'krbT icketFlags' EQUALITY integerMatch SYNTAX 1.3.6.1. 4.1.1466.115.121.1.27 SINGLE-VALUE) olcAttributeTypes: {6}( 2.16.840.1.113719.1.301.4.9.1 NAME 'krbM axTicketLife' EQUALITY integerMatch SYNTAX 1.3.6. 1.4.1.1466.115.121.1.27 SINGLE-VALUE) olcAttributeTypes: {7}( 2.16.840.1.113719.1.301.4.10.1 NAME 'krb MaxRenewableAge' EQUALITY integerMatch SYNTAX 1.3 .6.1.4.1.1466.115.121.1.27 SINGLE-VALUE) olcAttributeTypes: {8}( 2.16.840.1.113719.1.301.4.14.1 NAME 'krb RealmReferences' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12) olcAttributeTypes: {9}( 2.16.840.1.113719.1.301.4.15.1 NAME 'krb LdapServers' EQUALITY caseIgnoreMatch SYNTAX 1.3. 6.1.4.1.1466.115.121.1.15) olcAttributeTypes: {10}( 2.16.840.1.113719.1.301.4.17.1 NAME 'kr bKdcServers' EQUALITY distinguishedNameMatch SYNT AX 1.3.6.1.4.1.1466.115.121.1.12) olcAttributeTypes: {11}( 2.16.840.1.113719.1.301.4.18.1 NAME 'kr bPwdServers' EQUALITY distinguishedNameMatch SYNT AX 1.3.6.1.4.1.1466.115.121.1.12) olcAttributeTypes: {12}( 2.16.840.1.113719.1.301.4.24.1 NAME 'kr bHostServer' EQUALITY caseExactIA5Match SYNTAX 1. 3.6.1.4.1.1466.115.121.1.26) olcAttributeTypes: {13}( 2.16.840.1.113719.1.301.4.25.1 NAME 'kr bSearchScope' EQUALITY integerMatch SYNTAX 1.3.6. 1.4.1.1466.115.121.1.27 SINGLE-VALUE) olcAttributeTypes: {14}( 2.16.840.1.113719.1.301.4.26.1 NAME 'kr bPrincipalReferences' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12) olcAttributeTypes: {15}( 2.16.840.1.113719.1.301.4.28.1 NAME 'kr bPrincNamingAttr' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE) olcAttributeTypes: {16}( 2.16.840.1.113719.1.301.4.29.1 NAME 'kr bAdmServers' EQUALITY distinguishedNameMatch SYNT AX 1.3.6.1.4.1.1466.115.121.1.12) olcAttributeTypes: {17}( 2.16.840.1.113719.1.301.4.30.1 NAME 'kr bMaxPwdLife' EQUALITY integerMatch SYNTAX 1.3.6.1 .4.1.1466.115.121.1.27 SINGLE-VALUE) olcAttributeTypes: {18}( 2.16.840.1.113719.1.301.4.31.1 NAME 'kr bMinPwdLife' EQUALITY integerMatch SYNTAX 1.3.6.1 .4.1.1466.115.121.1.27 SINGLE-VALUE) olcAttributeTypes: {19}( 2.16.840.1.113719.1.301.4.32.1 NAME 'kr bPwdMinDiffChars' EQUALITY integerMatch SYNTAX 1 .3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE) olcAttributeTypes: {20}( 2.16.840.1.113719.1.301.4.33.1 NAME 'kr bPwdMinLength' EQUALITY integerMatch SYNTAX 1.3. 6.1.4.1.1466.115.121.1.27 SINGLE-VALUE) olcAttributeTypes: {21}( 2.16.840.1.113719.1.301.4.34.1 NAME 'kr bPwdHistoryLength' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE) olcAttributeTypes: {22}( 1.3.6.1.4.1.5322.21.2.1 NAME 'krbPwdMax Failure' EQUALITY integerMatch SYNTAX 1.3.6.1.4. 1.1466.115.121.1.27 SINGLE-VALUE) olcAttributeTypes: {23}( 1.3.6.1.4.1.5322.21.2.2 NAME 'krbPwdFai lureCountInterval' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE) olcAttributeTypes: {24}( 1.3.6.1.4.1.5322.21.2.3 NAME 'krbPwdLoc koutDuration' EQUALITY integerMatch SYNTAX 1.3.6 .1.4.1.1466.115.121.1.27 SINGLE-VALUE) olcAttributeTypes: {25}( 2.16.840.1.113719.1.301.4.36.1 NAME 'kr bPwdPolicyReference' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE) olcAttributeTypes: {26}( 2.16.840.1.113719.1.301.4.37.1 NAME 'kr bPasswordExpiration' EQUALITY generalizedTimeMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE) olcAttributeTypes: {27}( 2.16.840.1.113719.1.301.4.39.1 NAME 'kr bPrincipalKey' EQUALITY octetStringMatch SYNTAX 1 .3.6.1.4.1.1466.115.121.1.40) olcAttributeTypes: {28}( 2.16.840.1.113719.1.301.4.40.1 NAME 'kr bTicketPolicyReference' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE) olcAttributeTypes: {29}( 2.16.840.1.113719.1.301.4.41.1 NAME 'kr bSubTrees' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12) olcAttributeTypes: {30}( 2.16.840.1.113719.1.301.4.42.1 NAME 'kr bDefaultEncSaltTypes' EQUALITY caseIgnoreMatch SY NTAX 1.3.6.1.4.1.1466.115.121.1.15) olcAttributeTypes: {31}( 2.16.840.1.113719.1.301.4.43.1 NAME 'kr bSupportedEncSaltTypes' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15) olcAttributeTypes: {32}( 2.16.840.1.113719.1.301.4.44.1 NAME 'kr bPwdHistory' EQUALITY octetStringMatch SYNTAX 1.3 .6.1.4.1.1466.115.121.1.40) olcAttributeTypes: {33}( 2.16.840.1.113719.1.301.4.45.1 NAME 'kr bLastPwdChange' EQUALITY generalizedTimeMatch SYN TAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE) olcAttributeTypes: {34}( 2.16.840.1.113719.1.301.4.46.1 NAME 'kr bMKey' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4 .1.1466.115.121.1.40) olcAttributeTypes: {35}( 2.16.840.1.113719.1.301.4.47.1 NAME 'kr bPrincipalAliases' EQUALITY caseExactIA5Match SYN TAX 1.3.6.1.4.1.1466.115.121.1.26) olcAttributeTypes: {36}( 2.16.840.1.113719.1.301.4.48.1 NAME 'kr bLastSuccessfulAuth' EQUALITY generalizedTimeMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE) olcAttributeTypes: {37}( 2.16.840.1.113719.1.301.4.49.1 NAME 'kr bLastFailedAuth' EQUALITY generalizedTimeMatch SY NTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE) olcAttributeTypes: {38}( 2.16.840.1.113719.1.301.4.50.1 NAME 'kr bLo Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnPrettyNormal: <cn={5}kerberos> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnPrettyNormal: <cn={5}kerberos>, <cn={5}kerberos> Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: <= str2entry(cn={5}kerberos) -> 0x7ff49ab19758 Nov 22 18:22:53 mgaauth1 slapd[12638]: ldif_read_file: read entry file: "/etc/openldap/slapd.d/cn=config/cn=schema/cn={6}uidnext.ldif" Nov 22 18:22:53 mgaauth1 slapd[12638]: => str2entry: "dn: cn={6}uidnext objectClass: olcSchemaConfig cn: {6}uidnext olcObjectClasses: {0}( 1.1.2.2.1.30 NAME 'uidnext' SUP top STRUCTURAL MUST ( cn $ uidNumber )) structuralObjectClass: olcSchemaConfig entryUUID: 189d1db6-8adf-102f-87a7-a13f60af0032 creatorsName: cn=config createTimestamp: 20101122235057Z entryCSN: 20101122235057.569075Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20101122235057Z " Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnPrettyNormal: <cn={6}uidnext> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnPrettyNormal: <cn={6}uidnext>, <cn={6}uidnext> Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: <= str2entry(cn={6}uidnext) -> 0x7ff49ab19758 Nov 22 18:22:53 mgaauth1 slapd[12638]: ldif_read_file: read entry file: "/etc/openldap/slapd.d/cn=config/olcDatabase={-1}frontend.ldif" Nov 22 18:22:53 mgaauth1 slapd[12638]: => str2entry: "dn: olcDatabase={-1}frontend objectClass: olcDatabaseConfig olcDatabase: {-1}frontend olcAccess: {0}to dn.base="" by * read olcAccess: {1}to dn.base="cn=Subschema" by * read structuralObjectClass: olcDatabaseConfig entryUUID: 1a06c66c-8ade-102f-8d08-5da984889200 creatorsName: cn=config createTimestamp: 20101122234350Z entryCSN: 20101122234350.442520Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20101122234350Z " Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnPrettyNormal: <olcDatabase={-1}frontend> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnPrettyNormal: <olcDatabase={-1}frontend>, <olcDatabase={-1}frontend> Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: <= str2entry(olcDatabase={-1}frontend) -> 0x7ff49ab19758 Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnNormalize: <> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnNormalize: <> Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnNormalize: <cn=Subschema> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnNormalize: <cn=subschema> Nov 22 18:22:53 mgaauth1 slapd[12638]: ldif_read_file: read entry file: "/etc/openldap/slapd.d/cn=config/olcDatabase={0}config.ldif" Nov 22 18:22:53 mgaauth1 slapd[12638]: => str2entry: "dn: olcDatabase={0}config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.base="uid=syncrepl,ou=system,dc=ls,dc=cbn" read by * break olcLimits: {0}dn.exact="uid=syncrepl,ou=system,dc=ls,dc=cbn" size.soft=unlimit ed olcRootDN: cn=config olcRootPW:: e1NTSEF9K3hqNDB5T2U1ZGtyTU45aWVrMGhpSlFMMFVGUlFVNWFXZz09 olcSecurity: simple_bind=128 ssf=71 olcSyncrepl: {0}rid=1 provider="ldap://mgaauth1.ni.ls.cbn/" searchbase="cn=con fig" type="refreshAndPersist" retry="120 +" starttls=critical tls_reqcert=dem and bindmethod="simple" binddn="uid=syncrepl,ou=system,dc=ls,dc=cbn" credenti als="I9BpLVmLdOaL" olcUpdateRef: ldap://mgaauth1.ni.ls.cbn/ structuralObjectClass: olcDatabaseConfig entryUUID: 1a06cd10-8ade-102f-8d09-5da984889200 creatorsName: cn=config createTimestamp: 20101122234350Z entryCSN: 20101122234350.442690Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20101122234350Z " Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnPrettyNormal: <olcDatabase={0}config> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnPrettyNormal: <olcDatabase={0}config>, <olcDatabase={0}config> Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: <= str2entry(olcDatabase={0}config) -> 0x7ff49ab19758 Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnPrettyNormal: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnPrettyNormal: <cn=config>, <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnNormalize: <uid=syncrepl,ou=system,dc=ls,dc=cbn> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnNormalize: <uid=syncrepl,ou=system,dc=ls,dc=cbn> Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnNormalize: <uid=syncrepl,ou=system,dc=ls,dc=cbn> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnNormalize: <uid=syncrepl,ou=system,dc=ls,dc=cbn> Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnPrettyNormal: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnPrettyNormal: <cn=config>, <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnNormalize: <uid=syncrepl,ou=system,dc=ls,dc=cbn> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnNormalize: <uid=syncrepl,ou=system,dc=ls,dc=cbn> Nov 22 18:22:53 mgaauth1 slapd[12638]: ldif_read_file: read entry file: "/etc/openldap/slapd.d/cn=config/olcDatabase={0}config/olcOverlay={0}syncprov.ldif" Nov 22 18:22:53 mgaauth1 slapd[12638]: => str2entry: "dn: olcOverlay={0}syncprov objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 structuralObjectClass: olcSyncProvConfig entryUUID: 1a06d9fe-8ade-102f-8d0a-5da984889200 creatorsName: cn=config createTimestamp: 20101122234350Z entryCSN: 20101122234350.443021Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20101122234350Z " Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnPrettyNormal: <olcOverlay={0}syncprov> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnPrettyNormal: <olcOverlay={0}syncprov>, <olcOverlay={0}syncprov> Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: <= str2entry(olcOverlay={0}syncprov) -> 0x7ff49ab19758 Nov 22 18:22:53 mgaauth1 slapd[12638]: ldif_read_file: read entry file: "/etc/openldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif" Nov 22 18:22:53 mgaauth1 slapd[12638]: => str2entry: "dn: olcDatabase={1}hdb objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=ls,dc=cbn olcAccess: {0}to attrs=userPassword by self write by * auth olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to attrs=userPKCS12 by self read by * none olcAccess: {3}to * by * read olcRootDN: cn=admin,dc=ls,dc=cbn olcRootPW:: e1NTSEF9TkJSVVEyR0FGMlNQN1dsbFh3eS9GK2t5MFBST1UxaEpWQT09 olcUpdateRef: ldap://anubis.ls.cbn/ olcDbCacheSize: 10000 olcDbCheckpoint: 1024 5 olcDbConfig: {0}set_cachesize 0 15000000 1 olcDbConfig: {1}set_lg_regionmax 262144 olcDbConfig: {2}set_lg_bsize 2097152 olcDbConfig: {3}set_flags DB_LOG_AUTOREMOVE olcDbIDLcacheSize: 30000 olcDbIndex: objectclass eq olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq olcDbIndex: member eq olcDbIndex: memberUid eq olcDbIndex: mail eq olcDbIndex: cn eq,sub olcDbIndex: displayName eq,sub olcDbIndex: uid eq,sub olcDbIndex: sn eq,sub olcDbIndex: givenName eq,sub olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq structuralObjectClass: olcHdbConfig entryUUID: 65b86196-8adf-102f-87a8-a13f60af0032 creatorsName: cn=config createTimestamp: 20101122235306Z olcSyncrepl: {0}rid=2 provider="ldap://anubis.ls.cbn/" searchbase="dc=ls,dc=cb n" type="refreshOnly" retry="120 +" interval="00:00:01:00" starttls=critical tls_reqcert=demand bindmethod="simple" binddn="uid=syncrepl,ou=system,dc=ls,d c=cbn" credentials="lieguYwHee" entryCSN: 20101123001649.251496Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20101123001649Z " Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnPrettyNormal: <olcDatabase={1}hdb> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnPrettyNormal: <olcDatabase={1}hdb>, <olcDatabase={1}hdb> Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnNormalize: <dc=ls,dc=cbn> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnNormalize: <dc=ls,dc=cbn> Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnNormalize: <cn=admin,dc=ls,dc=cbn> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnNormalize: <cn=admin,dc=ls,dc=cbn> Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnNormalize: <cn=config> Nov 22 18:22:53 mgaauth1 slapd[12638]: <= str2entry(olcDatabase={1}hdb) -> 0x7ff49ab19758 Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnPrettyNormal: <dc=ls,dc=cbn> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnPrettyNormal: <dc=ls,dc=cbn>, <dc=ls,dc=cbn> Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnPrettyNormal: <cn=admin,dc=ls,dc=cbn> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnPrettyNormal: <cn=admin,dc=ls,dc=cbn>, <cn=admin,dc=ls,dc=cbn> Nov 22 18:22:53 mgaauth1 slapd[12638]: hdb_db_init: Initializing HDB database Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnPrettyNormal: <dc=ls,dc=cbn> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnPrettyNormal: <dc=ls,dc=cbn>, <dc=ls,dc=cbn> Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnPrettyNormal: <cn=admin,dc=ls,dc=cbn> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnPrettyNormal: <cn=admin,dc=ls,dc=cbn>, <cn=admin,dc=ls,dc=cbn> Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnNormalize: <dc=ls,dc=cbn> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnNormalize: <dc=ls,dc=cbn> Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnNormalize: <uid=syncrepl,ou=system,dc=ls,dc=cbn> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnNormalize: <uid=syncrepl,ou=system,dc=ls,dc=cbn> Nov 22 18:22:53 mgaauth1 slapd[12638]: send_ldap_result: conn=-1 op=0 p=0 Nov 22 18:22:53 mgaauth1 slapd[12638]: send_ldap_result: err=0 matched="" text="" Nov 22 18:22:53 mgaauth1 slapd[12638]: >>> dnNormalize: <cn=Subschema> Nov 22 18:22:53 mgaauth1 slapd[12638]: <<< dnNormalize: <cn=subschema> Nov 22 18:22:53 mgaauth1 slapd[12638]: matching_rule_use_init Nov 22 18:22:53 mgaauth1 slapd[12638]: 1.2.840.113556.1.4.804 (integerBitOrMatch): Nov 22 18:22:53 mgaauth1 slapd[12638]: matchingRuleUse: ( 1.2.840.113556.1.4.804 NAME 'integerBitOrMatch' APPLIES ( supportedLDAPVersion $ entryTtl $ uidNumber $ gidNumber $ olcConcurrency $ olcConnMaxPending $ olcConnMaxPendingAuth $ olcIdleTimeout $ olcIndexSubstrIfMinLen $ olcIndexSubstrIfMaxLen $ olcIndexSubstrAnyLen $ olcIndexSubstrAnyStep $ olcIndexIntLen $ olcLocalSSF $ olcMaxDerefDepth $ olcReplicationInterval $ olcSockbufMaxIncoming $ olcSockbufMaxIncomingAuth $ olcThreads $ olcToolThreads $ olcWriteTimeout $ olcDbCacheFree $ olcDbCacheSize $ olcDbDNcacheSize $ olcDbIDLcacheSize $ olcDbSearchStack $ olcDbShmKey $ olcChainMaxReferralDepth $ olcDbProtocolVersion $ olcDbConnectionPoolMax $ olcDDSmaxDynamicObjects $ olcPcacheMaxQueries $ olcRetcodeSleep $ olcSssVlvMax $ olcSssVlvMaxKeys $ olcSpSessionlog $ mailPreferenceOption $ shadowLastChange $ shadowMin $ shadowMax $ shadowWarning $ shadowInactive $ shadowExpire $ shadowFlag $ ipServicePort $ ipProtocolNumber $ oncRpcNumber $ suseNextUniqueId $ suseMinUniqueId $ suseMaxUniqueId $ suseMinPasswordLength $ suseMaxPasswordLength $ suseImapDefaultQuota $ krbPrincipalType $ krbTicketFlags $ krbMaxTicketLife $ krbMaxRenewableAge $ krbSearchScope $ krbMaxPwdLife $ krbMinPwdLife $ krbPwdMinDiffChars $ krbPwdMinLength $ krbPwdHistoryLength $ krbPwdMaxFailure $ krbPwdFailureCountInterval $ krbPwdLockoutDuration $ krbLoginFailedCount ) ) Nov 22 18:22:53 mgaauth1 slapd[12638]: 1.2.840.113556.1.4.803 (integerBitAndMatch): Nov 22 18:22:53 mgaauth1 slapd[12638]: matchingRuleUse: ( 1.2.840.113556.1.4.803 NAME 'integerBitAndMatch' APPLIES ( supportedLDAPVersion $ entryTtl $ uidNumber $ gidNumber $ olcConcurrency $ olcConnMaxPending $ olcConnMaxPendingAuth $ olcIdleTimeout $ olcIndexSubstrIfMinLen $ olcIndexSubstrIfMaxLen $ olcIndexSubstrAnyLen $ olcIndexSubstrAnyStep $ olcIndexIntLen $ olcLocalSSF $ olcMaxDerefDepth $ olcReplicationInterval $ olcSockbufMaxIncoming $ olcSockbufMaxIncomingAuth $ olcThreads $ olcToolThreads $ olcWriteTimeout $ olcDbCacheFree $ olcDbCacheSize $ olcDbDNcacheSize $ olcDbIDLcacheSize $ olcDbSearchStack $ olcDbShmKey $ olcChainMaxReferralDepth $ olcDbProtocolVersion $ olcDbConnectionPoolMax $ olcDDSmaxDynamicObjects $ olcPcacheMaxQueries $ olcRetcodeSleep $ olcSssVlvMax $ olcSssVlvMaxKeys $ olcSpSessionlog $ mailPreferenceOption $ shadowLastChange $ shadowMin $ shadowMax $ shadowWarning $ shadowInactive $ shadowExpire $ shadowFlag $ ipServicePort $ ipProtocolNumber $ oncRpcNumber $ suseNextUniqueId $ suseMinUniqueId $ suseMaxUniqueId $ suseMinPasswordLength $ suseMaxPasswordLength $ suseImapDefaultQuota $ krbPrincipalType $ krbTicketFlags $ krbMaxTicketLife $ krbMaxRenewableAge $ krbSearchScope $ krbMaxPwdLife $ krbMinPwdLife $ krbPwdMinDiffChars $ krbPwdMinLength $ krbPwdHistoryLength $ krbPwdMaxFailure $ krbPwdFailureCountInterval $ krbPwdLockoutDuration $ krbLoginFailedCount ) ) Nov 22 18:22:53 mgaauth1 slapd[12638]: 1.3.6.1.4.1.1466.109.114.2 (caseIgnoreIA5Match): Nov 22 18:22:53 mgaauth1 slapd[12638]: matchingRuleUse: ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' APPLIES ( altServer $ olcDbConfig $ c $ mail $ dc $ associatedDomain $ email $ aRecord $ mDRecord $ mXRecord $ nSRecord $ sOARecord $ cNAMERecord $ janetMailbox $ gecos $ homeDirectory $ loginShell $ memberUid $ memberNisNetgroup $ nisNetgroupTriple $ ipNetmaskNumber $ macAddress $ bootParameter $ bootFile $ nisMapEntry $ nisDomain $ automountMapName $ automountKey $ automountInformation $ suseNamingAttribute $ susePasswordHash $ suseSkelDir $ krbPrincipalName $ krbCanonicalName $ krbHostServer $ krbPrincipalAliases $ krbAllowedToDelegateTo ) ) Nov 22 18:22:53 mgaauth1 slapd[12638]: 1.3.6.1.4.1.1466.109.114.1 (caseExactIA5Match): Nov 22 18:22:53 mgaauth1 slapd[12638]: matchingRuleUse: ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' APPLIES ( altServer $ olcDbConfig $ c $ mail $ dc $ associatedDomain $ email $ aRecord $ mDRecord $ mXRecord $ nSRecord $ sOARecord $ cNAMERecord $ janetMailbox $ gecos $ homeDirectory $ loginShell $ memberUid $ memberNisNetgroup $ nisNetgroupTriple $ ipNetmaskNumber $ macAddress $ bootParameter $ bootFile $ nisMapEntry $ nisDomain $ automountMapName $ automountKey $ automountInformation $ suseNamingAttribute $ susePasswordHash $ suseSkelDir $ krbPrincipalName $ krbCanonicalName $ krbHostServer $ krbPrincipalAliases $ krbAllowedToDelegateTo ) ) Nov 22 18:22:53 mgaauth1 slapd[12638]: 2.5.13.39 (certificateListMatch): Nov 22 18:22:53 mgaauth1 slapd[12638]: 2.5.13.38 (certificateListExactMatch): Nov 22 18:22:53 mgaauth1 slapd[12638]: matchingRuleUse: ( 2.5.13.38 NAME 'certificateListExactMatch' APPLIES ( authorityRevocationList $ certificateRevocationList $ deltaRevocationList ) ) Nov 22 18:22:53 mgaauth1 slapd[12638]: 2.5.13.35 (certificateMatch): Nov 22 18:22:53 mgaauth1 slapd[12638]: 2.5.13.34 (certificateExactMatch): Nov 22 18:22:53 mgaauth1 slapd[12638]: matchingRuleUse: ( 2.5.13.34 NAME 'certificateExactMatch' APPLIES ( userCertificate $ cACertificate ) ) Nov 22 18:22:53 mgaauth1 slapd[12638]: 2.5.13.30 (objectIdentifierFirstComponentMatch): Nov 22 18:22:53 mgaauth1 slapd[12638]: matchingRuleUse: ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch' APPLIES ( supportedControl $ supportedExtension $ supportedFeatures $ ldapSyntaxes $ supportedApplicationContext ) ) Nov 22 18:22:53 mgaauth1 slapd[12638]: 2.5.13.29 (integerFirstComponentMatch): Nov 22 18:22:53 mgaauth1 slapd[12638]: matchingRuleUse: ( 2.5.13.29 NAME 'integerFirstComponentMatch' APPLIES ( supportedLDAPVersion $ entryTtl $ uidNumber $ gidNumber $ olcConcurrency $ olcConnMaxPending $ olcConnMaxPendingAuth $ olcIdleTimeout $ olcIndexSubstrIfMinLen $ olcIndexSubstrIfMaxLen $ olcIndexSubstrAnyLen $ olcIndexSubstrAnyStep $ olcIndexIntLen $ olcLocalSSF $ olcMaxDerefDepth $ olcReplicationInterval $ olcSockbufMaxIncoming $ olcSockbufMaxIncomingAuth $ olcThreads $ olcToolThreads $ olcWriteTimeout $ olcDbCacheFree $ olcDbCacheSize $ olcDbDNcacheSize $ olcDbIDLcacheSize $ olcDbSearchStack $ olcDbShmKey $ olcChainMaxReferralDepth $ olcDbProtocolVersion $ olcDbConnectionPoolMax $ olcDDSmaxDynamicObjects $ olcPcacheMaxQueries $ olcRetcodeSleep $ olcSssVlvMax $ olcSssVlvMaxKeys $ olcSpSessionlog $ mailPreferenceOption $ shadowLastChange $ shadowMin $ shadowMax $ shadowWarning $ shadowInactive $ shadowExpire $ shadowFlag $ ipServicePort $ ipProtocolNumber $ oncRpcNumber $ suseNextUniqueId $ suseMinUniqueId $ suseMaxUniqueId $ suseMinPasswordLength $ suseMaxPasswordLength $ suseImapDefaultQuota $ krbPrincipalType $ krbTicketFlags $ krbMaxTicketLife $ krbMaxRenewableAge $ krbSearchScope $ krbMaxPwdLife $ krbMinPwdLife $ krbPwdMinDiffChars $ krbPwdMinLength $ krbPwdHistoryLength $ krbPwdMaxFailure $ krbPwdFailureCountInterval $ krbPwdLockoutDuration $ krbLoginFailedCount ) ) Nov 22 18:22:53 mgaauth1 slapd[12638]: 2.5.13.27 (generalizedTimeMatch): Nov 22 18:22:53 mgaauth1 slapd[12638]: matchingRuleUse: ( 2.5.13.27 NAME 'generalizedTimeMatch' APPLIES ( createTimestamp $ modifyTimestamp $ pwdChangedTime $ pwdAccountLockedTime $ pwdFailureTime $ pwdGraceUseTime $ krbPrincipalExpiration $ krbPasswordExpiration $ krbLastPwdChange $ krbLastSuccessfulAuth $ krbLastFailedAuth ) ) Nov 22 18:22:53 mgaauth1 slapd[12638]: 2.5.13.24 (protocolInformationMatch): Nov 22 18:22:53 mgaauth1 slapd[12638]: matchingRuleUse: ( 2.5.13.24 NAME 'protocolInformationMatch' APPLIES protocolInformation ) Nov 22 18:22:53 mgaauth1 slapd[12638]: 2.5.13.23 (uniqueMemberMatch): Nov 22 18:22:53 mgaauth1 slapd[12638]: matchingRuleUse: ( 2.5.13.23 NAME 'uniqueMemberMatch' APPLIES uniqueMember ) Nov 22 18:22:53 mgaauth1 slapd[12638]: 2.5.13.22 (presentationAddressMatch): Nov 22 18:22:53 mgaauth1 slapd[12638]: matchingRuleUse: ( 2.5.13.22 NAME 'presentationAddressMatch' APPLIES presentationAddress ) Nov 22 18:22:53 mgaauth1 slapd[12638]: 2.5.13.20 (telephoneNumberMatch): Nov 22 18:22:53 mgaauth1 slapd[12638]: matchingRuleUse: ( 2.5.13.20 NAME 'telephoneNumberMatch' APPLIES ( telephoneNumber $ homePhone $ mobile $ pager ) ) Nov 22 18:22:53 mgaauth1 slapd[12638]: 2.5.13.17 (octetStringMatch): Nov 22 18:22:53 mgaauth1 slapd[12638]: matchingRuleUse: ( 2.5.13.17 NAME 'octetStringMatch' APPLIES ( userPassword $ olcDbCryptKey $ pwdHistory $ nisPublicKey $ nisSecretKey $ krbPrincipalKey $ krbPwdHistory $ krbMKey $ krbExtraData ) ) Nov 22 18:22:53 mgaauth1 slapd[12638]: 2.5.13.16 (bitStringMatch): Nov 22 18:22:53 mgaauth1 slapd[12638]: matchingRuleUse: ( 2.5.13.16 NAME 'bitStringMatch' APPLIES x500UniqueIdentifier ) Nov 22 18:22:53 mgaauth1 slapd[12638]: 2.5.13.14 (integerMatch): Nov 22 18:22:53 mgaauth1 slapd[12638]: matchingRuleUse: ( 2.5.13.14 NAME 'integerMatch' APPLIES ( supportedLDAPVersion $ entryTtl $ uidNumber $ gidNumber $ olcConcurrency $ olcConnMaxPending $ olcConnMaxPendingAuth $ olcIdleTimeout $ olcIndexSubstrIfMinLen $ olcIndexSubstrIfMaxLen $ olcIndexSubstrAnyLen $ olcIndexSubstrAnyStep $ olcIndexIntLen $ olcLocalSSF $ olcMaxDerefDepth $ olcReplicationInterval $ olcSockbufMaxIncoming $ olcSockbufMaxIncomingAuth $ olcThreads $ olcToolThreads $ olcWriteTimeout $ olcDbCacheFree $ olcDbCacheSize $ olcDbDNcacheSize $ olcDbIDLcacheSize $ olcDbSearchStack $ olcDbShmKey $ olcChainMaxReferralDepth $ olcDbProtocolVersion $ olcDbConnectionPoolMax $ olcDDSmaxDynamicObjects $ olcPcacheMaxQueries $ olcRetcodeSleep $ olcSssVlvMax $ olcSssVlvMaxKeys $ olcSpSessionlog $ mailPreferenceOption $ shadowLastChange $ shadowMin $ shadowMax $ shadowWarning $ shadowInactive $ shadowExpire $ shadowFlag $ ipServicePort $ ipProtocolNumber $ oncRpcNumber $ suseNextUniqueId $ suseMinUniqueId $ suseMaxUniqueId $ suseMinPasswordLength $ suseMaxPasswordLength $ suseImapDefaultQuota $ krbPrincipalType $ krbTicketFlags $ krbMaxTicketLife $ krbMaxRenewableAge $ krbSearchScope $ krbMaxPwdLife $ krbMinPwdLife $ krbPwdMinDiffChars $ krbPwdMinLength $ krbPwdHistoryLength $ krbPwdMaxFailure $ krbPwdFailureCountInterval $ krbPwdLockoutDuration $ krbLoginFailedCount ) ) Nov 22 18:22:53 mgaauth1 slapd[12638]: 2.5.13.13 (booleanMatch): Nov 22 18:22:53 mgaauth1 slapd[12638]: matchingRuleUse: ( 2.5.13.13 NAME 'booleanMatch' APPLIES ( hasSubordinates $ olcAddContentAcl $ olcGentleHUP $ olcHidden $ olcLastMod $ olcMirrorMode $ olcMonitoring $ olcReadOnly $ olcReverseLookup $ olcSyncUseSubentry $ olcDbChecksum $ olcDbNoSync $ olcDbDirtyRead $ olcDbLinearIndex $ olcChainCacheURI $ olcChainReturnError $ olcDbRebindAsUser $ olcDbChaseReferrals $ olcDbProxyWhoAmI $ olcDbSingleConn $ olcDbUseTemporaryConn $ olcDbNoRefs $ olcDbNoUndefFilter $ olcAccessLogSuccess $ olcDDSstate $ olcMemberOfRefInt $ pwdReset $ olcPPolicyHashCleartext $ olcPPolicyForwardUpdates $ olcPPolicyUseLockout $ olcPcachePersist $ olcPcacheValidate $ olcPcacheOffline $ olcRetcodeInDir $ olcRwmNormalizeMapped $ olcRwmDropUnrequested $ olcSpNoPresent $ olcSpReloadHint $ olcTranslucentStrict $ olcTranslucentNoGlue $ olcTranslucentBindLocal $ olcTranslucentPwModLocal $ olcUniqueStrict $ suseImapUseSsl $ krbUPEnabled ) ) Nov 22 18:22:53 mgaauth1 slapd[12638]: 2.5.13.11 (caseIgnoreListMatch): Nov 22 18:22:53 mgaauth1 slapd[12638]: matchingRuleUse: ( 2.5.13.11 NAME 'caseIgnoreListMatch' APPLIES ( postalAddress $ registeredAddress $ homePostalAddress ) ) Nov 22 18:22:53 mgaauth1 slapd[12638]: 2.5.13.8 (numericStringMatch): Nov 22 18:22:53 mgaauth1 slapd[12638]: matchingRuleUse: ( 2.5.13.8 NAME 'numericStringMatch' APPLIES ( x121Address $ internationaliSDNNumber ) ) Nov 22 18:22:53 mgaauth1 slapd[12638]: 2.5.13.7 (caseExactSubstringsMatch): Nov 22 18:22:53 mgaauth1 slapd[12638]: matchingRuleUse: ( 2.5.13.7 NAME 'caseExactSubstringsMatch' APPLIES ( serialNumber $ destinationIndicator $ dnQualifier ) ) Nov 22 18:22:53 mgaauth1 slapd[12638]: 2.5.13.6 (caseExactOrderingMatch): Nov 22 18:22:53 mgaauth1 slapd[12638]: matchingRuleUse: ( 2.5.13.6 NAME 'caseExactOrderingMatch' APPLIES ( serialNumber $ destinationIndicator $ dnQualifier ) ) Nov 22 18:22:53 mgaauth1 slapd[12638]: 2.5.13.5 (caseExactMatch): Nov 22 18:22:53 mgaauth1 slapd[12638]: matchingRuleUse: ( 2.5.13.5 NAME 'caseExactMatch' APPLIES ( supportedSASLMechanisms $ vendorName $ vendorVersion $ ref $ name $ cn $ uid $ labeledURI $ description $ olcConfigFile $ olcConfigDir $ olcAccess $ olcAllows $ olcArgsFile $ olcAttributeOptions $ olcAttributeTypes $ olcAuthIDRewrite $ olcAuthzPolicy $ olcAuthzRegexp $ olcBackend $ olcDatabase $ olcDisallows $ olcDitContentRules $ olcInclude $ olcLdapSyntaxes $ olcLimits $ olcLogFile $ olcLogLevel $ olcModuleLoad $ olcModulePath $ olcObjectClasses $ olcObjectIdentifier $ olcOverlay $ olcPasswordCryptSaltFormat $ olcPasswordHash $ olcPidFile $ olcPlugin $ olcPluginLogFile $ olcReferral $ olcReplica $ olcReplicaArgsFile $ olcReplicaPidFile $ olcReplogFile $ olcRequires $ olcRestrict $ olcRootDSE $ olcRootPW $ olcSaslAuxprops $ olcSaslHost $ olcSaslRealm $ olcSaslSecProps $ olcSecurity $ olcServerID $ olcSizeLimit $ olcSortVals $ olcSubordinate $ olcSyncrepl $ olcTCPBuffer $ olcTimeLimit $ olcTLSCACertificateFile $ olcTLSCACertificatePath $ olcTLSCertificateFile $ olcTLSCertificateKeyFile $ olcTLSCipherSuite $ olcTLSCRLCheck $ olcTLSCRLFile $ olcTLSRandFile $ olcTLSVerifyClient $ olcTLSDHParamFile $ olcTLSProtocolMin $ olcUpdateRef $ olcDbDirectory $ olcDbCheckpoint $ olcDbCryptFile $ olcDbPageSize $ olcDbIndex $ olcDbLockDetect $ olcDbMode $ olcChainingBehavior $ olcDbURI $ olcDbStartTLS $ olcDbACLPasswd $ olcDbACLBind $ olcDbIDAssertPasswd $ olcDbIDAssertBind $ olcDbIDAssertMode $ olcDbIDAssertAuthzFrom $ olcDbTFSupport $ olcDbTimeout $ olcDbIdleTimeout $ olcDbConnTtl $ olcDbNetworkTimeout $ olcDbCancel $ olcDbQuarantine $ olcAccessLogOps $ olcAccessLogPurge $ olcAccessLogOld $ olcAccessLogOldAttr $ olcAuditlogFile $ olcCollectInfo $ olcConstraintAttribute $ olcDDSmaxTtl $ olcDDSminTtl $ olcDDSdefaultTtl $ olcDDSinterval $ olcDDStolerance $ olcDGAttrPair $ olcDlAttrSet $ olcMemberOfDangling $ olcMemberOfGroupOC $ olcMemberOfMemberAD $ olcMemberOfMemberOfAD $ olcMemberOfDanglingError $ olcPcache $ olcPcacheAttrset $ olcPcacheTemplate $ olcPcachePosition $ olcPcacheBind $ olcRefintAttribute $ olcRetcodeItem $ olcRwmRewrite $ olcRwmTFSupport $ olcRwmMap $ olcSpCheckpoint $ olcTranslucentLocal $ olcTranslucentRemote $ olcUniqueIgnore $ olcUniqueAttribute $ olcUniqueURI $ olcValSortAttr $ knowledgeInformation $ sn $ serialNumber $ c $ l $ st $ street $ o $ ou $ title $ businessCategory $ postalCode $ postOfficeBox $ physicalDeliveryOfficeName $ destinationIndicator $ givenName $ initials $ generationQualifier $ dnQualifier $ houseIdentifier $ dmdName $ pseudonym $ textEncodedORAddress $ info $ drink $ roomNumber $ userClass $ host $ documentIdentifier $ documentTitle $ documentVersion $ documentLocation $ personalTitle $ co $ uniqueIdentifier $ organizationalStatus $ buildingName $ documentPublisher $ carLicense $ departmentNumber $ displayName $ employeeNumber $ employeeType $ preferredLanguage $ ipServiceProtocol $ ipHostNumber $ ipNetworkNumber $ nisMapName $ suseSearchFilter $ suseDefaultValue $ susePlugin $ suseMapAttribute $ suseImapServer $ suseImapAdmin $ krbLdapServers $ krbPrincNamingAttr $ krbDefaultEncSaltTypes $ krbSupportedEncSaltTypes ) ) Nov 22 18:22:53 mgaauth1 slapd[12638]: 2.5.13.4 (caseIgnoreSubstringsMatch): Nov 22 18:22:53 mgaauth1 slapd[12638]: matchingRuleUse: ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' APPLIES ( serialNumber $ destinationIndicator $ dnQualifier ) ) Nov 22 18:22:53 mgaauth1 slapd[12638]: 2.5.13.3 (caseIgnoreOrderingMatch): Nov 22 18:22:53 mgaauth1 slapd[12638]: matchingRuleUse: ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' APPLIES ( serialNumber $ destinationIndicator $ dnQualifier ) ) Nov 22 18:22:53 mgaauth1 slapd[12638]: 2.5.13.2 (caseIgnoreMatch): Nov 22 18:22:53 mgaauth1 slapd[12638]: matchingRuleUse: ( 2.5.13.2 NAME 'caseIgnoreMatch' APPLIES ( supportedSASLMechanisms $ vendorName $ vendorVersion $ ref $ name $ cn $ uid $ labeledURI $ description $ olcConfigFile $ olcConfigDir $ olcAccess $ olcAllows $ olcArgsFile $ olcAttributeOptions $ olcAttributeTypes $ olcAuthIDRewrite $ olcAuthzPolicy $ olcAuthzRegexp $ olcBackend $ olcDatabase $ olcDisallows $ olcDitContentRules $ olcInclude $ olcLdapSyntaxes $ olcLimits $ olcLogFile $ olcLogLevel $ olcModuleLoad $ olcModulePath $ olcObjectClasses $ olcObjectIdentifier $ olcOverlay $ olcPasswordCryptSaltFormat $ olcPasswordHash $ olcPidFile $ olcPlugin $ olcPluginLogFile $ olcReferral $ olcReplica $ olcReplicaArgsFile $ olcReplicaPidFile $ olcReplogFile $ olcRequires $ olcRestrict $ olcRootDSE $ olcRootPW $ olcSaslAuxprops $ olcSaslHost $ olcSaslRealm $ olcSaslSecProps $ olcSecurity $ olcServerID $ olcSizeLimit $ olcSortVals $ olcSubordinate $ olcSyncrepl $ olcTCPBuffer $ olcTimeLimit $ olcTLSCACertificateFile $ olcTLSCACertificatePath $ olcTLSCertificateFile $ olcTLSCertificateKeyFile $ olcTLSCipherSuite $ olcTLSCRLCheck $ olcTLSCRLFile $ olcTLSRandFile $ olcTLSVerifyClient $ olcTLSDHParamFile $ olcTLSProtocolMin $ olcUpdateRef $ olcDbDirectory $ olcDbCheckpoint $ olcDbCryptFile $ olcDbPageSize $ olcDbIndex $ olcDbLockDetect $ olcDbMode $ olcChainingBehavior $ olcDbURI $ olcDbStartTLS $ olcDbACLPasswd $ olcDbACLBind $ olcDbIDAssertPasswd $ olcDbIDAssertBind $ olcDbIDAssertMode $ olcDbIDAssertAuthzFrom $ olcDbTFSupport $ olcDbTimeout $ olcDbIdleTimeout $ olcDbConnTtl $ olcDbNetworkTimeout $ olcDbCancel $ olcDbQuarantine $ olcAccessLogOps $ olcAccessLogPurge $ olcAccessLogOld $ olcAccessLogOldAttr $ olcAuditlogFile $ olcCollectInfo $ olcConstraintAttribute $ olcDDSmaxTtl $ olcDDSminTtl $ olcDDSdefaultTtl $ olcDDSinterval $ olcDDStolerance $ olcDGAttrPair $ olcDlAttrSet $ olcMemberOfDangling $ olcMemberOfGroupOC $ olcMemberOfMemberAD $ olcMemberOfMemberOfAD $ olcMemberOfDanglingError $ olcPcache $ olcPcacheAttrset $ olcPcacheTemplate $ olcPcachePosition $ olcPcacheBind $ olcRefintAttribute $ olcRetcodeItem $ olcRwmRewrite $ olcRwmTFSupport $ olcRwmMap $ olcSpCheckpoint $ olcTranslucentLocal $ olcTranslucentRemote $ olcUniqueIgnore $ olcUniqueAttribute $ olcUniqueURI $ olcValSortAttr $ knowledgeInformation $ sn $ serialNumber $ c $ l $ st $ street $ o $ ou $ title $ businessCategory $ postalCode $ postOfficeBox $ physicalDeliveryOfficeName $ destinationIndicator $ givenName $ initials $ generationQualifier $ dnQualifier $ houseIdentifier $ dmdName $ pseudonym $ textEncodedORAddress $ info $ drink $ roomNumber $ userClass $ host $ documentIdentifier $ documentTitle $ documentVersion $ documentLocation $ personalTitle $ co $ uniqueIdentifier $ organizationalStatus $ buildingName $ documentPublisher $ carLicense $ departmentNumber $ displayName $ employeeNumber $ employeeType $ preferredLanguage $ ipServiceProtocol $ ipHostNumber $ ipNetworkNumber $ nisMapName $ suseSearchFilter $ suseDefaultValue $ susePlugin $ suseMapAttribute $ suseImapServer $ suseImapAdmin $ krbLdapServers $ krbPrincNamingAttr $ krbDefaultEncSaltTypes $ krbSupportedEncSaltTypes ) ) Nov 22 18:22:53 mgaauth1 slapd[12638]: 1.2.36.79672281.1.13.3 (rdnMatch): Nov 22 18:22:53 mgaauth1 slapd[12638]: 2.5.13.1 (distinguishedNameMatch): Nov 22 18:22:53 mgaauth1 slapd[12638]: matchingRuleUse: ( 2.5.13.1 NAME 'distinguishedNameMatch' APPLIES ( creatorsName $ modifiersName $ subschemaSubentry $ entryDN $ namingContexts $ aliasedObjectName $ dynamicSubtrees $ distinguishedName $ seeAlso $ olcDefaultSearchBase $ olcRootDN $ olcSchemaDN $ olcSuffix $ olcUpdateDN $ olcDbACLAuthcDn $ olcDbIDAssertAuthcDn $ olcRelay $ olcAccessLogDB $ memberOf $ olcMemberOfDN $ pwdPolicySubentry $ olcPPolicyDefault $ olcRefintNothing $ olcRefintModifiersName $ olcRetcodeParent $ olcUniqueBase $ member $ owner $ roleOccupant $ manager $ documentAuthor $ secretary $ associatedName $ dITRedirect $ suseDefaultBase $ suseDefaultTemplate $ suseSecondaryGroup $ krbRealmReferences $ krbKdcServers $ krbPwdServers $ krbPrincipalReferences $ krbAdmServers $ krbPwdPolicyReference $ krbTicketPolicyReference $ krbSubTrees $ krbObjectReferences $ krbPrincContainerRef ) ) Nov 22 18:22:53 mgaauth1 slapd[12638]: 2.5.13.0 (objectIdentifierMatch): Nov 22 18:22:53 mgaauth1 slapd[12638]: matchingRuleUse: ( 2.5.13.0 NAME 'objectIdentifierMatch' APPLIES ( supportedControl $ supportedExtension $ supportedFeatures $ supportedApplicationContext ) ) Nov 22 18:22:53 mgaauth1 slapd[12651]: slapd startup: initiated. Nov 22 18:22:53 mgaauth1 slapd[12651]: backend_startup_one: starting "cn=config" Nov 22 18:22:53 mgaauth1 slapd[12651]: config_back_db_open Nov 22 18:22:53 mgaauth1 slapd[12651]: send_ldap_result: conn=-1 op=0 p=0 Nov 22 18:22:53 mgaauth1 slapd[12651]: send_ldap_result: err=0 matched="" text="" Nov 22 18:22:53 mgaauth1 slapd[12651]: backend_startup_one: starting "dc=ls,dc=cbn" Nov 22 18:22:53 mgaauth1 slapd[12651]: hdb_db_open: "dc=ls,dc=cbn" Nov 22 18:22:53 mgaauth1 slapd[12651]: hdb_db_open: database "dc=ls,dc=cbn": dbenv_open(/var/lib/ldap). Nov 22 18:22:53 mgaauth1 slapd[12651]: hdb_monitor_db_open: monitoring disabled; configure monitor database to enable Nov 22 18:22:53 mgaauth1 slapd[12651]: slapd starting Nov 22 18:22:53 mgaauth1 slapd[12651]: =>do_syncrepl rid=002 Nov 22 18:22:53 mgaauth1 slapd[12651]: => bdb_entry_get: ndn: "dc=ls,dc=cbn" Nov 22 18:22:53 mgaauth1 slapd[12651]: => bdb_entry_get: oc: "(null)", at: "contextCSN" Nov 22 18:22:53 mgaauth1 slapd[12651]: bdb_dn2entry("dc=ls,dc=cbn") Nov 22 18:22:53 mgaauth1 slapd[12651]: => hdb_dn2id("dc=ls,dc=cbn") Nov 22 18:22:53 mgaauth1 slapd[12651]: <= hdb_dn2id: got id=0x1 Nov 22 18:22:53 mgaauth1 slapd[12651]: entry_decode: "" Nov 22 18:22:53 mgaauth1 slapd[12651]: <= entry_decode() Nov 22 18:22:53 mgaauth1 slapd[12651]: bdb_entry_get: rc=0 Nov 22 18:22:53 mgaauth1 slapd[12651]: =>do_syncrep2 rid=002 Nov 22 18:22:53 mgaauth1 slapd[12651]: do_syncrep2: rid=002 LDAP_RES_SEARCH_RESULT Nov 22 18:22:54 mgaauth1 slapd[12651]: slap_listener_activate(7): Nov 22 18:22:54 mgaauth1 slapd[12651]: >>> slap_listener(ldap://) Nov 22 18:22:54 mgaauth1 slapd[12651]: conn=1000 fd=13 ACCEPT from IP=127.0.0.1:33205 (IP=0.0.0.0:389) Nov 22 18:22:54 mgaauth1 slapd[12651]: connection_get(13) Nov 22 18:22:54 mgaauth1 slapd[12651]: connection_get(13): got connid=1000 Nov 22 18:22:54 mgaauth1 slapd[12651]: connection_read(13): checking for input on id=1000 Nov 22 18:22:54 mgaauth1 slapd[12651]: op tag 0x60, time 1290471774 Nov 22 18:22:54 mgaauth1 slapd[12651]: conn=1000 op=0 do_bind Nov 22 18:22:54 mgaauth1 slapd[12651]: >>> dnPrettyNormal: <> Nov 22 18:22:54 mgaauth1 slapd[12651]: <<< dnPrettyNormal: <>, <> Nov 22 18:22:54 mgaauth1 slapd[12651]: conn=1000 op=0 BIND dn="" method=128 Nov 22 18:22:54 mgaauth1 slapd[12651]: do_bind: version=3 dn="" method=128 Nov 22 18:22:54 mgaauth1 slapd[12651]: send_ldap_result: conn=1000 op=0 p=3 Nov 22 18:22:54 mgaauth1 slapd[12651]: send_ldap_result: err=0 matched="" text="" Nov 22 18:22:54 mgaauth1 slapd[12651]: send_ldap_response: msgid=1 tag=97 err=0 Nov 22 18:22:54 mgaauth1 slapd[12651]: conn=1000 op=0 RESULT tag=97 err=0 text= Nov 22 18:22:54 mgaauth1 slapd[12651]: do_bind: v3 anonymous bind Nov 22 18:22:54 mgaauth1 slapd[12651]: connection_get(13) Nov 22 18:22:54 mgaauth1 slapd[12651]: connection_get(13): got connid=1000 Nov 22 18:22:54 mgaauth1 slapd[12651]: connection_read(13): checking for input on id=1000 Nov 22 18:22:54 mgaauth1 slapd[12651]: op tag 0x63, time 1290471774 Nov 22 18:22:54 mgaauth1 slapd[12651]: conn=1000 op=1 do_search Nov 22 18:22:54 mgaauth1 slapd[12651]: >>> dnPrettyNormal: <> Nov 22 18:22:54 mgaauth1 slapd[12651]: <<< dnPrettyNormal: <>, <> Nov 22 18:22:54 mgaauth1 slapd[12651]: SRCH "" 0 0 Nov 22 18:22:54 mgaauth1 slapd[12651]: 0 0 0 Nov 22 18:22:54 mgaauth1 slapd[12651]: filter: (objectClass=*) Nov 22 18:22:54 mgaauth1 slapd[12651]: attrs: Nov 22 18:22:54 mgaauth1 slapd[12651]: Nov 22 18:22:54 mgaauth1 slapd[12651]: conn=1000 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Nov 22 18:22:54 mgaauth1 slapd[12651]: => send_search_entry: conn 1000 dn="" Nov 22 18:22:54 mgaauth1 slapd[12651]: conn=1000 op=1 ENTRY dn="" Nov 22 18:22:54 mgaauth1 slapd[12651]: <= send_search_entry: conn 1000 exit. Nov 22 18:22:54 mgaauth1 slapd[12651]: send_ldap_result: conn=1000 op=1 p=3 Nov 22 18:22:54 mgaauth1 slapd[12651]: send_ldap_result: err=0 matched="" text="" Nov 22 18:22:54 mgaauth1 slapd[12651]: send_ldap_response: msgid=2 tag=101 err=0 Nov 22 18:22:54 mgaauth1 slapd[12651]: conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Nov 22 18:22:54 mgaauth1 slapd[12651]: connection_get(13) Nov 22 18:22:54 mgaauth1 slapd[12651]: connection_get(13): got connid=1000 Nov 22 18:22:54 mgaauth1 slapd[12651]: connection_read(13): checking for input on id=1000 Nov 22 18:22:54 mgaauth1 slapd[12651]: op tag 0x42, time 1290471774 Nov 22 18:22:54 mgaauth1 slapd[12651]: conn=1000 op=2 do_unbind Nov 22 18:22:54 mgaauth1 slapd[12651]: conn=1000 op=2 UNBIND Nov 22 18:22:54 mgaauth1 slapd[12651]: connection_close: conn=1000 sd=13 Nov 22 18:22:54 mgaauth1 slapd[12651]: conn=1000 fd=13 closed Any idea what could be going on? Thanks, -- Bram Cymet Software Developer Canadian Bank Note Co. Ltd. Cell: 613-608-9752

2 2

Is it possible to prevent many loggings on many computer from only one user?
by Olivier PAVILLA 25 Nov '10

25 Nov '10

Hi everyone I would like to know if it's possible to prevent many loggings on many computers from only one user? I have LDAP/Samba server. Anyone must connect with LDAP to acces its home. So I have user who opened 12 computers, logged on those 12 computers and ran boinc-client on those 12 computers... I want to prevent this kind of behaviour... Thanks in advance. Regards. -- Olivier Pavilla << 仕事を探しています。求職中です。>> S.C.I.R.C. Orléans (Bourgogne) - I.U.F.M. Centre-Val de Loire 72 Rue du Faubourg Bourgogne -45044 ORLEANS Cedex 1 Tel : 02-38-49-26-20 , mailto:olivier.pavilla@univ-orleans.fr http://blog.linux-squad.com - 僕の傑作です。 http://gallery.linux-squad.com - 僕の傑作です。

2 1

How to set Multiple base dn
by Laurent gobalraja 25 Nov '10

25 Nov '10

Hi ! I'm new to openldap 2.4 and have set up a running server. 1) How can i add a second base DN using the new cn=config files ? I've got a "dn=domain1.org,dn=org", i'd like to add a "dn=domain2,dn=org" base. 2) How can i set TLS using the new cn=config style ? System : Debian/Squeeze Thx for any help.

2 1

dynamic groups
by Christian Bösch 25 Nov '10

25 Nov '10

Hi, I have built my ldap groups with dynlist overlay. _If i search for a group i can see the members: ldapsearch -Y EXTERNAL -b 'ou=Groups,dc=abc,dc=net' 'cn=ou-is' dn: cn=ou-is,ou=Groups,dc=abc,dc=net objectClass: groupOfURLs objectClass: fhvGroup cn: ou-is memberURL: ldap:///ou=People,dc=abc,dc=net??sub?(fhvIsAISMemberOf=cn=ou-is,ou=Groups,dc=abc,dc=net) member: uid=cb,ou=fhv,ou=People,dc=abc,dc=net _But if i search for members i only get empty results: ldapsearch -Y EXTERNAL -b 'ou=Groups,dc=abc,dc=net' '(member=uid=cb,ou=fhv,ou=People,dc=abc,dc=net)' cn member Is this not working with dynamic groups? And does it make sense to build indexes for dynamic member attributes? /thx,chris

3 6

RE: About locked LDAP user
by Sotomayor, Vicente (ITD) 24 Nov '10

24 Nov '10

>Message: 4 >Date: Mon, 22 Nov 2010 06:02:53 -0800 (PST) >From: "=?gb2312?B?R2FyeS5qc3o=?=" <gary.jsz(a)gmail.com> >To: openldap-technical(a)openldap.org >Subject: About locked LDAP user >Message-ID: <4cea780d.1e30dc0a.1b96.77a5(a)mx.google.com> >Content-Type: text/plain; charset="gb2312" >Hi,ALL > I'm new openLDAP user. But now, I have a problem about LDAP user manager. > > > I want stop a specify user in LDAP system,but I don't want to delete this user and change the user's password. > > How to locked this user? such as Linux system "passwd -l xxx" to locked system users. > > Help me,please! Use lusermode -L username to to lock it down. That's how I do it in RH.

1 0

About locked LDAP user
by Gary.jsz 23 Nov '10

23 Nov '10

Hi,ALL I'm new openLDAP user. But now, I have a problem about LDAP user manager. I want stop a specify user in LDAP system,but I don't want to delete this user and change the user's password. How to locked this user? such as Linux system "passwd -l xxx" to locked system users. Help me,please! Thanks.

2 1

Issues migrating from openLDAP 2.0.27-11 to 2.3.43-12.el5_5.2
by Chris Beach 23 Nov '10

23 Nov '10

I've purchased a new server to replace my current domain controller, one issue I'm having is migrating LDAP from my old server to the new one, I've worked out a lot of the problems I've had, but I'm not having any luck with this one. Please keep in mind, I am not very knowledgeable with LDAP in general, so I may have missed things more experienced people may not have. I had two objectClasses that were conflicting: account and inetOrgPerson, apparently in my old LDAP version it allowed this, but the new one was giving errors ( (65) invalid structural object class chain (inetOrgPerson/account)), so I simply removed all of the account objectClasses to see what it would do, this did get rid of half the errors, and all of my users now show up in LDAP, but I find now that all of my ou=Computers are erroring out with: slapadd: dn="uid=STCQA01$,ou=Computers,dc=pin,dc=com" (line=10425): (65) no structural object class provided I can only assume this is because I've removed the account object class from the file, but if I add it back in I get: slapadd: dn="uid=STCQA01$,ou=Computers,dc=pin,dc=com" (line=10426): (65) invalid structural object class chain (inetOrgPerson/account) Any suggestions on what I'm doing wrong here? Here is my includes in slapd.conf: include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /usr/share/doc/samba-3.0.33/LDAP/samba.schema include /etc/openldap/schema/RADIUS-LDAPv3.schema I really would appreciate any feedback, thanks!

2 2

Passwords in DIT after MOD from Solaris Client
by Ben Rockwood 22 Nov '10

22 Nov '10

Hello, I'm using pam_ldap on a Solaris 10 client and an OpenLDAP server. Everything works great, with one little exception. I can create new accounts from an LDIF specifying the password as {SSHA} and everything works fine. Users can login, etc. However, if a user changes their password from Solaris ('passwd -r ldap') the password is now stored in the directory as plaintext. The user can still login, change their password, etc, it works fine... but I don't want plaintext passwords in the directory. I tried adding "password-hash {SSHA}" to slapd.conf, but that didn't do anything... nor would I expect it to because its the default setting. Can anyone point me in the right direction? benr.

2 2

self signed certificate
by Márcio Luciano Donada 22 Nov '10

22 Nov '10

Hi list, When using TLS, I have information that I'm using a self-signed certificate, as shown below: # ldapsearch -x -d5 -b 'ou=Usuarios,dc=xx,dc=com,dc=br' -H ldaps://121.1.1.97/ '(objectclass=*)' ldap_url_parse_ext(ldaps://121.1.1.97/) ldap_create ldap_url_parse_ext(ldaps://121.1.1.97:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP 121.1.1.97:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 121.1.1.97:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 0, err: 18, subject: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=ldap.xx.com.br, issuer: -State/O=Internet Widgits Pty Ltd/CN=ldap.xx.com.br TLS certificate verification: Error, self signed certificate TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self signed certificate). ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) My slapd.conf: TLSRandFile /dev/random TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCertificateFile /usr/local/etc/openldap/ssl/cert.crt TLSCertificateKeyFile /usr/local/etc/openldap/ssl/cert.key TLSCACertificateFile /usr/local/etc/openldap/ssl/cert.crt my ldap.conf pam_login_attribute uid base dc=xxxx,dc=com,dc=br uri ldap://127.0.0.1/ PORT 636 HOST 127.0.0.1 TLS_REQCERT allow TLS_CACERT /usr/local/etc/openldap/ssl/cert.crt TLS_CACERTDIR /usr/local/etc/openldap/ssl -- Márcio Luciano Donada <mdonada -at- auroraalimentos -dot- com -dot- br> Aurora Alimentos - Cooperativa Central Oeste Catarinense Departamento de T.I.

5 5

HDB Index Corruption
by Alejandro Imass 22 Nov '10

22 Nov '10

Hi, I searched the archives of openldap-software and openldap-technical for the terms "hdb index corruption", "hdb index", and "idex" and got zero results. I have a simple master-slave setup and my indexes are getting corrupted. We have software that ties RDBMS entries with the entryUUID because the DN can change. Of course, we use moddn to avoid changing the entryUUID. So here is the set-up: old_ldap ----> new_ldap_master ------> new_ldap_slave We run a cron that scans the old_ldap and updates information on all the records on the new_ldap_master. The information is mostly the same, but the structures of the DIT differ a lot. Ok, so the first cron updates information (attributes) that have changed in the old ldap and updates the ldap master entries. Another cron searches some info in a database and may perform many moddns if people have moved from departments, etc. The new_ldap_slave is just a replica of the first, using the methods described in the docs for MirrorMode replication. All writes AFAIK are always being done in the master. Anyway, the problem is that the HDB indexes seem to be getting corrupted. That is, if I query for and entryUUID I get a DN and if I query the DN I may get another entryUUID. If I reconstruct the indexes the problem is gone. Has anyone had a similar problem? What may be causing these problems? Is it too many wirtes? Is it common pratice to reconstruct the indexes after the massive updates? Any comments greatly appreciated ! Thanks, -- Alejandro Imass

1 0

ACL short hand notation @objectClass has side effects
by Isaac Hailperin 22 Nov '10

22 Nov '10

I have again trouble understanding ACLs: Consider the following schema: objectclass ( acmeLDAP:4.2 NAME 'acmeUserLimits' DESC 'Limits for acme Users' SUP top AUXILIARY MAY ( limitMaxUserProc $ limitMaxCpuTime $ limitMaxOpenFiles $ limitMaxCorefileSize $ limitMaxStackSize $ limitMaxMemorySize $ limitMaxVirtualMemory $ limitMaxDatasegSize $ limitMaxPipeSize $ limitMaxFileLocks $ userAttrChanged ) ) and the following ACL: [...] access to dn.subtree="ou=people,ou=unix,dc=acme,dc=org" attrs=limitMaxUserProc,limitMaxCpuTime,limitMaxOpenFiles,limitMaxCorefileSize,limitMaxStackSize,limitMaxMemorySize,limitMaxVirtualMemory,limitMaxDatasegSize,limitMaxPipeSize,limitMaxFileLocks,userAttrChanged by group="cn=useradmins,ou=group,ou=unix,dc=acme,dc=org" write by group="cn=consultants,ou=group,ou=unix,dc=acme,dc=org" write by self read by * none [...] This one works, it lets users authenticate, and restricts access to the attributes mentioned. Now as the attribute list is a bit long, I thought I could replace it with the short hand notation: access to dn.subtree="ou=people,ou=unix,dc=acme,dc=org" attrs=@acmeUserLimits (since all listet attributes are only in acmeUserLimits). Unfortunatly this does not work, it blocks users from loggin in (via ssh). One time I got the message "Permissions on the password database may be too restrictive." Obviously the shorthand notation affects other attributes as well. But looking at the object class definition, I don't see why. Can any one enlighten me about this? Isaac

1 0

back-ldap core dump
by CHIROSSEL, Olivier 22 Nov '10

22 Nov '10

Hi I have to migrate from a openldap 2.3.x to openldap 2.4. During this migration phase i want my openldap 2.3.x master replicate with slurpd to my new openldap 2.4.x master mirror mode architecture with some rewriting rules for split my big directory. I configure a proxy ldap using back-ldap with slapo-rwm overlay, but operational attributes related to entry creation and modification are proxied, even when i put < lastmod off > in the conf, contrary of the man of slapd-ldap ... So i put rw-map directives in the conf for strip operationnal attributes but this kind of operation generate a core dump ... dn: neufDhcpIP=10.145.250.119,suffix=9,o=auth,dc=neuf,dc=fr changetype: modify delete: neufDhcpOption neufDhcpOption: 1;255.255.255.0 - replace: entryCSN entryCSN: 20100511215647Z#000024#00#000000 - replace: modifiersName modifiersName: cn=manager,dc=neuf,dc=fr - replace: modifyTimestamp modifyTimestamp: 20100511215647Z dn: neufDhcpIP=10.145.250.119,suffix=9,o=auth,dc=neuf,dc=fr changetype: modify add: neufDhcpOption neufDhcpOption: 1;255.255.255.128 - replace: entryCSN entryCSN: 20100511215647Z#000024#00#000000 - replace: modifiersName modifiersName: cn=manager,dc=neuf,dc=fr - replace: modifyTimestamp modifyTimestamp: 20100511215647Z Core was generated by `openldap-2.4.23/servers/slapd/slapd -F /etc/openldap/slapd-ldap.d -h ldap://10.'. Program terminated with signal 6, Aborted. [New process 7995] [New process 7994] [New process 7990] [New process 7989] #0 0x00007f01373f9ed5 in raise () from /lib/libc.so.6 (gdb) bt #0 0x00007f01373f9ed5 in raise () from /lib/libc.so.6 #1 0x00007f01373fb3f3 in abort () from /lib/libc.so.6 #2 0x00007f0137436408 in __libc_message () from /lib/libc.so.6 #3 0x00007f013743b9a8 in malloc_printerr () from /lib/libc.so.6 #4 0x00007f013743dab6 in free () from /lib/libc.so.6 #5 0x000000000055b8e2 in ber_bvarray_free_x (a=0x26de840, ctx=0x0) at memory.c:737 #6 0x000000000046e3a1 in slap_mod_free (mod=0x26d07f0, freeit=0) at mods.c:461 #7 0x000000000046e42d in slap_mods_free (ml=0x26d07f0, freevals=1) at mods.c:481 #8 0x0000000000437960 in do_modify (op=0x25d02e0, rs=0x41d24cb0) at modify.c:187 #9 0x000000000041f6ef in connection_operation (ctx=0x41d24e00, arg_v=<value optimized out>) at connection.c:1109 #10 0x00000000004203dd in connection_read_thread (ctx=0x41d24e00, argv=<value optimized out>) at connection.c:1245 #11 0x0000000000534080 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #12 0x00007f0137f21fc7 in start_thread () from /lib/libpthread.so.0 #13 0x00007f013749764d in clone () from /lib/libc.so.6 #14 0x0000000000000000 in ?? () (gdb) My conf : database ldap suffix "dc=neuf,dc=fr" rootdn "cn=manager,dc=neuf,dc=fr" rootpw secret updatedn "cn=manager,dc=neuf,dc=fr" uri "ldap://127.0.0.1/" idassert-bind bindmethod=simple binddn="cn=manager,dc=neuf,dc=fr" credentials=secret overlay rwm rwm-rewriteEngine on rwm-rewriteContext default rwm-rewriteRule "neufDhcpIP=([0-9\\.]+)([0-9]{1}),ou=People,o=auth,dc=neuf,dc=fr$" "neufDhcpIP=$1$2,suffix=$2,o=auth,dc=neuf,dc=fr" rwm-map attribute neufDhcpIP neufDhcpIP rwm-map attribute neufDhcp82 neufDhcp82 rwm-map attribute neufDhcpOption neufDhcpOption rwm-map attribute neufDhcp60 neufDhcp60 rwm-map attribute neufDhcpRelay neufDhcpRelay rwm-map attribute neufDhcpComment neufDhcpComment rwm-map attribute neufDhcpUnique neufDhcpUnique rwm-map attribute neufDhcpProvider neufDhcpProvider rwm-map attribute neufDhcpFQDN neufDhcpFQDN rwm-map attribute neufDhcp82b neufDhcp82b rwm-map attribute neufDhcpMac neufDhcpMac rwm-map attribute neufDhcpSiaddr neufDhcpSiaddr rwm-map attribute neufDhcpBootfilename neufDhcpBootfilename rwm-map attribute neufBTID neufBTID rwm-map attribute neufBTOption neufBTOption rwm-map attribute neufTWINOption neufTWINOption rwm-map attribute neufE28Option neufE28Option rwm-map attribute circuitid circuitid rwm-map attribute clientid clientid rwm-map attribute device device rwm-map attribute clientoffer clientoffer rwm-map attribute ispid ispid rwm-map attribute suspended suspended rwm-map attribute neufDhcpIPb neufDhcpIPb rwm-map attribute neufDhcpOptionb neufDhcpOptionb rwm-map attribute idworkflow idworkflow rwm-map attribute neufDhcpRelayIP neufDhcpRelayIP rwm-map attribute interceptID interceptID rwm-map attribute interceptEndpoint interceptEndpoint rwm-map attribute neufDhcpRadiusOption neufDhcpRadiusOption rwm-map attribute suffix suffix rwm-map attribute dc dc rwm-map attribute o o rwm-map attribute ou ou rwm-map attribute cn cn rwm-map objectclass neufDhcpOption1 neufDhcpOption1 rwm-map objectclass neufDhcpOption5 neufDhcpOption5 rwm-map objectclass neufDhcpOption1R neufDhcpOption1R rwm-map objectclass neufDhcpOption35 neufDhcpOption35 rwm-map objectclass neufBTOption neufBTOption rwm-map objectclass neufDhcpOptionwifi neufDhcpOptionwifi rwm-map objectclass Dhcp82 Dhcp82 rwm-map objectclass ClientDevice ClientDevice rwm-map objectclass DhcpDevice DhcpDevice rwm-map objectclass suffixobj suffixobj rwm-map objectclass OrganizationalUnit OrganizationalUnit rwm-map objectclass Organization Organization rwm-map objectclass dcObject dcObject rwm-map objectclass domain domain rwm-map objectclass device device rwm-map attribute * rwm-map objectclass * Thank's in avance for your help Regards, Olivier

2 2

LDAP clients fail to connect with SSL enabled
by bluethundr 21 Nov '10

21 Nov '10

LDAP clients fail to connect with SSL enabled I am attempting to setup SSL/TLS support on my openLDAP 2.4 server on FreeBSD. LBSD2# pkg_info | grep openldap openldap-sasl-client-2.4.23 Open source LDAP client implementation with SASL2 support openldap-sasl-server-2.4.23 Open source LDAP server implementation I put my cert file, key file and CA certfile in a directory called /usr/local/etc/openldap/cacerts Here's how it looks: [root@LBSD2:/usr/local/etc/openldap/cacerts]#ls -l total 48 dr--r----- 2 root ldap 512 Nov 21 17:12 bak -r--r----- 1 root ldap 1960 Nov 21 07:05 bsd2.summitnjhome.com.crt -r--r----- 1 root ldap 4604 Nov 21 17:16 gd_bundle.crt -r--r----- 1 root ldap 4689 Nov 21 18:59 sf_bundle.crt -r--r----- 1 root ldap 1537 Nov 21 17:16 sf_issuing.crt -r--r----- 1 root ldap 1090 Nov 21 12:29 slapd.csr -r--r----- 1 root ldap 1743 Nov 21 12:26 slapd.key -r--r----- 1 root ldap 1675 Nov 21 17:25 slapd.pem My cert flie is a GoDaddy turbo-ssl certfile named bsd2.summitnjhome.com.crt. slapd.key is the key file and slapd.pem is the same thing only with the password removed. I'm a little unsure of which CA file to use but I think that sf_issuing.crt _should_ work as this is the CA file that I used to setup a similar SSL enabled LDAP server for a client recently. Although I have tried all three CA files in this directory: (gd_bundle.crt, sf_bundle.crt, and sf_issuing.crt). I put the various cert/key files into my slapd.conf file like this: LBSD2# cat slapd.conf | grep -i tls ## TLS options for slapd TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCertificateFile /usr/local/etc/openldap/cacerts/bsd2.summitnjhome.com.crt TLSCertificateKeyFile /usr/local/etc/openldap/cacerts/slapd.pem TLSCACertificateFile /usr/local/etc/openldap/cacerts/sf_issuing.crt Slapd restarts cleanly! LBSD2# /usr/local/etc/rc.d/slapd restart Stopping slapd. Waiting for PIDS: 81924. Starting slapd. Then I attempt to setup a virtual instance of CentOS 5.5 on the client side and that's where things fall apart...I attempt to ssh to localhost as an LDAP account: [root@VIRTCENT08:/etc/openldap/cacerts]#ssh bluethundr@localhost [...tectonic plates drift, careers begin and end, babies learn to walk, talk and grow to adulthood..] Connection closed by 127.0.0.1 [root@VIRTCENT08:/etc/openldap/cacerts]#getent passwd | grep ldapAccount [same interminable wait as above] This is what my /etc/ldap.conf file looks like on the client: [root@VIRTCENT08:/etc/openldap/cacerts]#cat /etc/ldap.conf # Your LDAP server. Must be resolvable without using LDAP. # Multiple hosts may be specified, each separated by a # space. How long nss_ldap takes to failover depends on # whether your LDAP client library supports configurable # network or connect timeouts (see bind_timelimit). #host 127.0.0.1 # The distinguished name of the search base. base dc=summitnjhome,dc=com # stored in /etc/ldap.secret (mode 600) #rootbinddn cn=manager,dc=example,dc=com # The port. # Optional: default is 389. #port 389 # Search timelimit #timelimit 30 timelimit 120 # Bind/connect timelimit #bind_timelimit 30 bind_timelimit 120 # Idle timelimit; client will close connections # (nss_ldap only) if the server has not been contacted # for the number of seconds specified below. #idle_timelimit 3600 idle_timelimit 3600 # Netscape SDK LDAPS #ssl on # Netscape SDK SSL options #sslpath /etc/ssl/certs # OpenLDAP SSL mechanism # start_tls mechanism uses the normal LDAP port, LDAPS typically 636 #ssl start_tls #ssl on # OpenLDAP SSL options # Require and verify server certificate (yes/no) # Default is to use libldap's default behavior, which can be configured in # /etc/openldap/ldap.conf using the TLS_REQCERT setting. The default for # OpenLDAP 2.0 and earlier is "no", for 2.1 and later is "yes". #tls_checkpeer yes # CA certificates for server certificate verification # At least one of these are required if tls_checkpeer is "yes" #tls_cacertfile /etc/ssl/ca.cert #tls_cacertdir /etc/ssl/certs # SSL cipher suite # See man ciphers for syntax #tls_ciphers TLSv1 # Client certificate and key # Use these, if your server requires client authentication. #tls_cert #tls_key # SASL mechanism for PAM authentication - use is experimental # at present and does not support password policy control uri ldap://ldap.summitnjhome.com/ ssl start_tls tls_cacertdir /etc/openldap/cacerts pam_password crypt This is how my nsswitch on the client side is setup: passwd: files ldap shadow: files ldap group: files ldap And here is the cert dir on my CentOS client: [root@VIRTCENT08:/etc/openldap/cacerts]#ls -l total 72 lrwxrwxrwx 1 root root 13 Nov 21 09:44 97552d04.0 -> gd_bundle.crt lrwxrwxrwx 1 root root 14 Nov 21 09:44 b737b221.0 -> sf_issuing.crt dr--r--r-- 2 root root 4096 Nov 21 2010 bak -r--r--r-- 1 root root 1960 Nov 21 07:05 bsd2.summitnjhome.com.crt lrwxrwxrwx 1 root root 25 Nov 21 09:44 c75be861.0 -> bsd2.summitnjhome.com.crt -r--r--r-- 1 root root 4604 Nov 21 2010 gd_bundle.crt -r--r--r-- 1 root root 1537 Nov 21 2010 sf_issuing.crt -r--r--r-- 1 root root 1090 Nov 21 12:29 slapd.csr -r--r--r-- 1 root root 1743 Nov 21 12:26 slapd.key -r--r--r-- 1 root root 1675 Nov 21 2010 slapd.pem Back on the server side there is a lot of activity in the ldap logs (here is an excerpt) Nov 21 20:21:38 LBSD2 slapd[81972]: daemon: read activity on 11 Nov 21 20:21:38 LBSD2 slapd[81972]: daemon: select: listen=6 active_threads=0 tvp=NULL Nov 21 20:21:38 LBSD2 slapd[81972]: daemon: select: listen=7 active_threads=0 tvp=NULL Nov 21 20:21:38 LBSD2 slapd[81972]: connection_read(11): input error=-2 id=1017, closing. Nov 21 20:21:38 LBSD2 slapd[81972]: connection_closing: readying conn=1017 sd=11 for close Nov 21 20:21:38 LBSD2 slapd[81972]: daemon: activity on 1 descriptor I've encloses a more complete log file as an attachment. I then try to show the CA files with an openssl command. First with sf_issuing.crt - slapd.conf: TLSCACertificateFile /usr/local/etc/openldap/cacerts/sf_issuing.crt On the client: [root@VIRTCENT08:/etc/openldap/cacerts]#openssl s_client -connect ldap.summitnjhome.com:389 -showcerts -CAfile sf_issuing.crt CONNECTED(00000003) 3143:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188 Next with sf_bundle.crt - slapd.conf: TLSCACertificateFile /usr/local/etc/openldap/cacerts/sf_bundle.crt [root@VIRTCENT08:/etc/openldap/cacerts]#openssl s_client -connect ldap.summitnjhome.com:389 -showcerts -CAfile sf_bundle.crt 3149:error:02001002:system library:fopen:No such file or directory:bss_file.c:122:fopen('sf_bundle.crt','r') 3149:error:2006D080:BIO routines:BIO_new_file:no such file:bss_file.c:125: 3149:error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib:by_file.c:279: CONNECTED(00000003) 3149:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188: Next with gd_bundle.crt - TLSCACertificateFile /usr/local/etc/openldap/cacerts/gd_bundle.crt [root@VIRTCENT08:/etc/openldap/cacerts]#openssl s_client -connect ldap.summitnjhome.com:389 -showcerts -CAfile gd_bundle.crt CONNECTED(00000003) 3156:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188: Disabling TLS on the client side authentication works again! [root@VIRTCENT08:/etc/openldap/cacerts]#ssh bluethundr@localhost bluethundr@localhost's password: Last login: Sun Nov 21 09:41:34 2010 from 192.168.1.50 ######################################################### # SUMMITNJHOME.COM # # TITLE: VIRTCENT08 BOX # # LOCATION: SUMMIT BASEMENT # # # ######################################################### Any thought on how to resolve the current situation would be most appreciated! ;) -- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 Share and enjoy!!

2 2

Re: ubuntu sudoers won't talk to LDAP
by bluethundr 19 Nov '10

19 Nov '10

> Why are you screwing with /etc/ldap/ldap.conf or /etc/ldap/conf? Neither of > these files are used by sudo on debian/ubuntu. > > --Quana root@ubuntu3:~# cat /etc/ldap.conf > /etc/sudo-ldap.conf root@ubuntu3:~# su - bluethundr bluethundr@ubuntu3:~$ sudo bash That did it! Thank you for catching that.. this was a change from 8.04 to 9.10.. 8.04 looks to /etc/ldap/ldap.conf... Best regards and I sincerely appreciate your input! On Fri, Nov 19, 2010 at 7:43 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Friday, November 19, 2010 7:14 PM -0500 bluethundr > <bluethundr(a)gmail.com> wrote: > >> This move had no effect: >> >> root@ubuntu3:~# mv /etc/ldap/ldap.conf /etc/ldap/ldap.conf.bak >> root@ubuntu3:~# ln -s /etc/ldap.conf /etc/ldap/ldap.conf > > Your output from sudo on that box *clearly* states that sudo-ldap uses > "/etc/sudo-ldap.conf". > > Why are you screwing with /etc/ldap/ldap.conf or /etc/ldap/conf? Neither of > these files are used by sudo on debian/ubuntu. > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > -- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 Share and enjoy!!

1 0

Re: ubuntu sudoers won't talk to LDAP
by bluethundr 19 Nov '10

19 Nov '10

>> --On Friday, November 19, 2010 6:35 PM -0500 bluethundr <bluethundr(a)gmail.com> wrote: >> I check /etc/ldap/ldap.conf: >> root@ubuntu3:~# cat /etc/ldap/ldap.conf >> ldap.conf path: /etc/sudo-ldap.conf > Hm, these two files don't match. Looks to me like you are editing the wrong file. Thank you Quanah This move had no effect: root@ubuntu3:~# mv /etc/ldap/ldap.conf /etc/ldap/ldap.conf.bak root@ubuntu3:~# ln -s /etc/ldap.conf /etc/ldap/ldap.conf root@ubuntu3:~# su - bluethundr bluethundr@ubuntu3:~$ sudo bash sudo: no valid sudoers sources found, quitting On Fri, Nov 19, 2010 at 7:12 PM, bluethundr <bluethundr(a)gmail.com> wrote: > sorry meant that for the list.. > > On Fri, Nov 19, 2010 at 7:12 PM, bluethundr <bluethundr(a)gmail.com> wrote: >> Thank you Quanah >> >> This move had no effect: >> >> root@ubuntu3:~# mv /etc/ldap/ldap.conf /etc/ldap/ldap.conf.bak >> root@ubuntu3:~# ln -s /etc/ldap.conf /etc/ldap/ldap.conf >> >> >> root@ubuntu3:~# su - bluethundr >> bluethundr@ubuntu3:~$ sudo bash >> sudo: no valid sudoers sources found, quitting >> >> >> :( >> >> On Fri, Nov 19, 2010 at 6:48 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: >>> --On Friday, November 19, 2010 6:35 PM -0500 bluethundr >>> <bluethundr(a)gmail.com> wrote: >>> >>>> I check /etc/ldap/ldap.conf: >>>> >>>> root@ubuntu3:~# cat /etc/ldap/ldap.conf >>> >>>> ldap.conf path: /etc/sudo-ldap.conf >>> >>> >>> Hm, these two files don't match. Looks to me like you are editing the wrong >>> file. >>> >>> --Quanah >>> >>> -- >>> >>> Quanah Gibson-Mount >>> Principal Software Engineer >>> Zimbra, Inc >>> -------------------- >>> Zimbra :: the leader in open source messaging and collaboration >>> >> >> >> >> -- >> Here's my RSA Public key: >> gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 >> >> Share and enjoy!! >> > > > > -- > Here's my RSA Public key: > gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 > > Share and enjoy!! > -- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 Share and enjoy!!

2 1

ubuntu sudoers won't talk to LDAP
by bluethundr 19 Nov '10

19 Nov '10

Hello Ubuntu On our network we have our sudoers stored in LDAP. This works fine on the CentOS 5.4 clients by placing into /etc/ldap.conf sudoers_base ou=sudoers,ou=Services,dc=example,dc=net and in /etc/nsswitch.conf we have the entry: sudoers: ldap (setting this setting to just 'ldap' instead of 'files ldap' does not render the machine unbootable as happens if you set passwd and group this way). However I am attempting to set this up on an Ubuntu 9.10 client and getting no joy so far. I have the same settings in /etc/ldap.conf and /etc/nsswitch.conf and cannot get sudoers to work. On the Ubuntu box, I can get LDAP entries by typing in getent passwd | grep ldapAccount, however when you attempt to sudo it fails: bluethundr@ubuntu3:~$ sudo bash >>> /etc/sudoers: syntax error near line 0 <<< sudo: parse error in /etc/sudoers near line 0 sudo: no valid sudoers sources found, quitting We leave our sudoers file blank intentionally in order to manage this via LDAP. Again, this problem is ONLY happening under Ubuntu and not under Centos 5.4. The only real difference that I see between the two clients is the sudo version. Could it be that under ubuntu LDAP sudo support isn't compiled in? if so how to recompile it so that it does? CentOS 5.4 sudo version: [root@ldap2 ~]# sudo -V Sudo version 1.7.2p1 Ubuntu 9.10 sudo version: root@ubuntu3:~# sudo -V Sudo version 1.7.0 [root@ldap2 ~]# sudo -V Sudo version 1.7.2p1 And here are the linkages: CentOS 5.4: [root@ldap2 ~]# ldd $(which sudo) libselinux.so.1 => /lib64/libselinux.so.1 (0x00002aaaaacc8000) libcap.so.1 => /lib64/libcap.so.1 (0x00002aaaaaee0000) libpam.so.0 => /lib64/libpam.so.0 (0x00002aaaab0e4000) libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaab2f0000) libldap-2.3.so.0 => /usr/lib64/libldap-2.3.so.0 (0x00002aaaab4f4000) libc.so.6 => /lib64/libc.so.6 (0x00002aaaab72e000) libaudit.so.0 => /lib64/libaudit.so.0 (0x00002aaaaba86000) liblber-2.3.so.0 => /usr/lib64/liblber-2.3.so.0 (0x00002aaaabc9e000) libsepol.so.1 => /lib64/libsepol.so.1 (0x00002aaaabeac000) /lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00002aaaac0f3000) libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00002aaaac308000) libssl.so.6 => /lib64/libssl.so.6 (0x00002aaaac521000) libcrypto.so.6 => /lib64/libcrypto.so.6 (0x00002aaaac76e000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002aaaacabf000) libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00002aaaaccf7000) libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002aaaacf26000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002aaaad1bb000) libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00002aaaad3bd000) libz.so.1 => /usr/lib64/libz.so.1 (0x00002aaaad5e3000) libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00002aaaad7f7000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00002aaaad9ff000) Ubuntu 9.10 bluethundr@ubuntu3:~$ ldd $(which sudo) linux-gate.so.1 => (0x00914000) libpam.so.0 => /lib/libpam.so.0 (0x00753000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x00223000) libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2 (0x00fa1000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x004f1000) liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 (0x00f35000) /lib/ld-linux.so.2 (0x00d75000) libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0x00345000) libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x008d0000) libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0x00b77000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x002e3000) libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0x001df000) libz.so.1 => /lib/libz.so.1 (0x007d6000) libgcrypt.so.11 => /lib/libgcrypt.so.11 (0x003f3000) libgpg-error.so.0 => /lib/libgpg-error.so.0 (0x00110000) Thanks for any input you may have! -- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 Share and enjoy!!

5 7

Re: Replication Through A DMZ
by Anton Chu 19 Nov '10

19 Nov '10

I'm having a hard time understanding it. I'm using the latest openldap on ubuntu 10.10 and I can't pinpoint the exact master configuration syntax that sets up the provider to push changes to the consumers. On Fri, Nov 19, 2010 at 2:40 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Friday, November 19, 2010 2:31 PM -0800 Anton Chu < > anton.chu(a)telecommand.com> wrote: > > FYI, I've installed a conumser server in the dmz today using refreshOnly >> replication and it didn't work. >> > > Why would it? You need to set up the provider to push changes, as detailed > in the Admin guide section I sent to you yesterday. > > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

2 1

Re: Replication Through A DMZ
by Anton Chu 19 Nov '10

19 Nov '10

FYI, I've installed a conumser server in the dmz today using refreshOnly replication and it didn't work. On Thu, Nov 18, 2010 at 11:31 AM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Thursday, November 18, 2010 11:14 AM -0800 Anton Chu < > anton.chu(a)telecommand.com> wrote: > > Thanks I've read the replication section many times at the site and >> logically it doesn't make sense when you look at the configuration. My >> Master has this configuration: >> > > Then apparently you haven't read it closely. Plase read < > http://www.openldap.org/doc/admin24/replication.html#Syncrepl%20Proxy> > > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

2 1

Want interesting restrictions to ldap auth on different servers to different users
by c0re 18 Nov '10

18 Nov '10

Hey all! I made simple ldap auth on my servers via pam_ldap. It's ok. Now I want to add users that can auth on several servers. BUT. I want to control on what servers user can login only on ldap server. I mean user user1 can must login only on server1,server2 and server3. And user2 can login only on server5 and server2. Theoretically It's possible to do with "pam_groupdn", set it it ldap.conf to server name and create as many groups as I have servers in openldap. Then I add users to some groups that they has to have access. I can group servers in some group like "city1_group" that contain all servers in city1 and add user to that group and it will have access to all servers in city1. May be anyone know another practice? Looking for best practice or something like it. Share your experience please. Thanks!!!

2 2

Replication Through A DMZ
by Anton Chu 18 Nov '10

18 Nov '10

I have a provider server in the intranet and I want to add a consumer server in a DMZ for replication. The problem is that a connection can only be initiated from the intranet to the DMZ. I've read both refreshandpersist and refesh-only replications both require an initial connection from the consumer server which will be in the DMZ. Should I put the provider server in the DMZ instead? TIA Regards..

3 4

Authenticating with an alias entry
by Angel L. Mateo 18 Nov '10

18 Nov '10

Hi, Is it possible to authenticate with openldap (version 2.4.21) using an entry that is actually an alias to another entry? -- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información _o) y las Comunicaciones Aplicadas (ATICA) / \\ http://www.um.es/atica _(___V Tfo: 868887590 Fax: 868888337

2 1

RE: Pass-Through authentication
by Paulo Jorge N. Correia (paucorre) 17 Nov '10

17 Nov '10

Jonathan and all, Need your support ..... what should be the configuration of saslauthd.conf in the case where I have a slapd.conf configuration where I use a back-meta to aggregate different hdb databases that are synchronized against AD Domain Controllers. Paulo -----Original Message----- From: Paulo Jorge N. Correia (paucorre) Sent: Tuesday, November 16, 2010 7:01 PM To: Jonathan Clarke; openldap-technical(a)openldap.org Subject: RE: Pass-Through authentication Johanathan, I decide to follow both of the options, and test which one is better :) : 1 - back-meta 2 - change the saslauthd from ldap to Kerberos Regarding back meta I need help :( In the slapd.conf I have an database created for back-meta..... ( strange thing is that it didn't worked when I create a separate conf file per each database "include /etc/openldap/slapd_domain1.conf", only working if I add all the database in the same file as showed below ) No what should I configure in the saslauthd.conf file..... if I direct ldap_servers how does it know which AD is associated with each user ? ________________________________________________________________________ ___ [root@openam-ldap openldap]# more ../saslauthd.conf ldap_servers: ldap://localhost ldap_search_base: dc=cisco,dc=com ldap_timeout: 10 ldap_filter: uid=%u ldap_bind_dn: cn=admin,dc=cisco,dc=com ldap_password: Cisco,123 ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: no ldap_start_tls: no ldap_version: 3 ldap_auth_method: bind ____________________________________________________________________ [root@openam-ldap openldap]# more slapd.conf # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/java.schema include /etc/openldap/schema/openldap.schema allow bind_v2 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args sasl-host localhost sasl-secprops none database meta suffix "dc=cisco,dc=com" uri "ldap://localhost/ou=domain1,dc=cisco,dc=com" suffixmassage "ou=domain1,dc=cisco,dc=com" "ou=domain1" uri "ldap://localhost/ou=domain2,dc=cisco,dc=com" suffixmassage "ou=domain2,dc=cisco,dc=com" "ou=domain2" database hdb suffix "ou=domain1" directory "/var/lib/ldap/domain1" rootdn "cn=admin,ou=domain1" rootpw "Cisco,123" index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uid eq,pres,sub database hdb suffix "ou=domain2" directory "/var/lib/ldap/domain2" rootdn "cn=admin,ou=domain2" rootpw "Cisco,123" index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uid eq,pres,sub _______________________________________________________________ Thank you, Paulo -----Original Message----- From: openldap-technical-bounces(a)OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Jonathan Clarke Sent: Monday, November 15, 2010 12:13 PM To: openldap-technical(a)openldap.org Subject: Re: Pass-Through authentication On 14/11/10 18:29, Paulo Jorge N. Correia (paucorre) wrote: > Hi all, > > I'm just starting with openLDAP and saslauth, and I'm trying to > replicate what I can achieve with ADAM/AD LDS in Windows platform. > > > > I'm trying to use openldap to aggregate user information from several > AD servers under different forests. > > > > So single point of contact from an LDAP perspective for an > organization, and then openldap should pass-through the authentication > request that receives to the AD DC of the respective user. > > > > This works well with /saslauthd /for a single domain/, but if I need > to do this with multiple domains, I don't know how to configure > saslauthd./ saslauthd can only launch one LDAP search to find a user and check his password. So if you're using several AD domains, you need to be able to perform a single search over all those domains : set up a back-meta with all the AD forests under it, and point saslauthd at that. Jonathan

1 0

RE: Problems Enabling Authentication using Cyrus SASL
by Fernando Torrez 17 Nov '10

17 Nov '10

Hi all Thanks for all your suggestions I tried the suggested command (thanks Moorthi): ldapwhoami -U proxyuser -X u:test -Y digest-md5 -I with no success. I got this error: firewall:~ # ldapwhoami -U proxyuser -X u:test -Y digest-md5 -I SASL/DIGEST-MD5 authentication started SASL Interaction Default: u:test Please enter your authorization name: test Default: proxyuser Please enter your authentication name: proxyuser Please enter your password: ldap_sasl_interactive_bind_s: Insufficient access (50) additional info: SASL(-14): authorization failure: unable authorization ID (Logs are at the bottom of this mail for details) I also realized that the logs changed almost nothing either the command below is running or not: saslauthd -d -V -a ldap -r -O /etc/saslauthd.conf so I can say that unfortunately there's no comunication between SASLAUTHD and LDAP. Now I will try the suggestion to separate saslauthd and ldapdb (thanks Dieter) But I'm still wondering if there's a way to work ldap server and cyrus-sasl together. Let's be more accuratte 1.- Connect to ldap server throught cyrus-sasl (let's say authenticated/authorized proxyuser connected to ldap server) 2.- Once connected to the ldap server, authenticate/authorize other user (or any object ) saved on ldap server using previous connection done in step 1 Is that posible? Or, Am I driving crazy for nothing? Thanks in advance Fernando Torrez LDAP LOGS Nov 17 10:10:44 firewall slapd[2901]: daemon: activity on 1 descriptor Nov 17 10:10:44 firewall slapd[2901]: daemon: activity on: Nov 17 10:10:44 firewall slapd[2901]: Nov 17 10:10:44 firewall slapd[2901]: slap_listener_activate(8): Nov 17 10:10:44 firewall slapd[2901]: daemon: epoll: listen=7 active_threads=0 tvp=zero Nov 17 10:10:44 firewall slapd[2901]: daemon: epoll: listen=8 busy Nov 17 10:10:44 firewall slapd[2901]: >>> slap_listener(ldap://) Nov 17 10:10:44 firewall slapd[2901]: daemon: listen=8, new connection on 13 Nov 17 10:10:44 firewall slapd[2901]: daemon: added 13r (active) listener=(nil) Nov 17 10:10:44 firewall slapd[2901]: conn=1002 fd=13 ACCEPT from IP=[::1]:39399 (IP=[::]:389) Nov 17 10:10:44 firewall slapd[2901]: daemon: activity on 1 descriptor Nov 17 10:10:44 firewall slapd[2901]: daemon: activity on: Nov 17 10:10:44 firewall slapd[2901]: Nov 17 10:10:44 firewall slapd[2901]: daemon: epoll: listen=7 active_threads=0 tvp=zero Nov 17 10:10:44 firewall slapd[2901]: daemon: epoll: listen=8 active_threads=0 tvp=zero Nov 17 10:10:44 firewall slapd[2901]: daemon: activity on 1 descriptor Nov 17 10:10:44 firewall slapd[2901]: daemon: activity on: Nov 17 10:10:44 firewall slapd[2901]: 13r Nov 17 10:10:44 firewall slapd[2901]: Nov 17 10:10:44 firewall slapd[2901]: daemon: read active on 13 Nov 17 10:10:44 firewall slapd[2901]: daemon: epoll: listen=7 active_threads=0 tvp=zero Nov 17 10:10:44 firewall slapd[2901]: daemon: epoll: listen=8 active_threads=0 tvp=zero Nov 17 10:10:44 firewall slapd[2901]: connection_get(13) Nov 17 10:10:44 firewall slapd[2901]: connection_get(13): got connid=1002 Nov 17 10:10:44 firewall slapd[2901]: connection_read(13): checking for input on id=1002 Nov 17 10:10:44 firewall slapd[2901]: op tag 0x60, time 1290003044 Nov 17 10:10:44 firewall slapd[2901]: conn=1002 op=0 do_bind Nov 17 10:10:44 firewall slapd[2901]: >>> dnPrettyNormal: <> Nov 17 10:10:44 firewall slapd[2901]: <<< dnPrettyNormal: <>, <> Nov 17 10:10:44 firewall slapd[2901]: conn=1002 op=0 BIND dn="" method=163 Nov 17 10:10:44 firewall slapd[2901]: do_bind: dn () SASL mech DIGEST-MD5 Nov 17 10:10:44 firewall slapd[2901]: ==> sasl_bind: dn="" mech=DIGEST-MD5 datalen=0 Nov 17 10:10:44 firewall slapd[2901]: SASL [conn=1002] Debug: DIGEST-MD5 server step 1 Nov 17 10:10:44 firewall slapd[2901]: send_ldap_sasl: err=14 len=182 Nov 17 10:10:44 firewall slapd[2901]: send_ldap_response: msgid=1 tag=97 err=14 Nov 17 10:10:44 firewall slapd[2901]: conn=1002 op=0 RESULT tag=97 err=14 text=SASL(0): successful result: Nov 17 10:10:44 firewall slapd[2901]: <== slap_sasl_bind: rc=14 Nov 17 10:10:44 firewall slapd[2901]: daemon: activity on 1 descriptor Nov 17 10:10:44 firewall slapd[2901]: daemon: activity on: Nov 17 10:10:44 firewall slapd[2901]: Nov 17 10:10:44 firewall slapd[2901]: daemon: epoll: listen=7 active_threads=0 tvp=zero Nov 17 10:10:44 firewall slapd[2901]: daemon: epoll: listen=8 active_threads=0 tvp=zero Nov 17 10:10:44 firewall ldapwhoami: DIGEST-MD5 client step 2 Nov 17 10:11:02 firewall ldapwhoami: DIGEST-MD5 client step 2 Nov 17 10:11:02 firewall slapd[2901]: daemon: activity on 1 descriptor Nov 17 10:11:02 firewall slapd[2901]: daemon: activity on: Nov 17 10:11:02 firewall slapd[2901]: 13r Nov 17 10:11:02 firewall slapd[2901]: Nov 17 10:11:02 firewall slapd[2901]: daemon: read active on 13 Nov 17 10:11:02 firewall slapd[2901]: daemon: epoll: listen=7 active_threads=0 tvp=zero Nov 17 10:11:02 firewall slapd[2901]: daemon: epoll: listen=8 active_threads=0 tvp=zero Nov 17 10:11:02 firewall slapd[2901]: connection_get(13) Nov 17 10:11:02 firewall slapd[2901]: connection_get(13): got connid=1002 Nov 17 10:11:02 firewall slapd[2901]: connection_read(13): checking for input on id=1002 Nov 17 10:11:02 firewall slapd[2901]: op tag 0x60, time 1290003062 Nov 17 10:11:02 firewall slapd[2901]: conn=1002 op=1 do_bind Nov 17 10:11:02 firewall slapd[2901]: >>> dnPrettyNormal: <> Nov 17 10:11:02 firewall slapd[2901]: <<< dnPrettyNormal: <>, <> Nov 17 10:11:02 firewall slapd[2901]: conn=1002 op=1 BIND dn="" method=163 Nov 17 10:11:02 firewall slapd[2901]: do_bind: dn () SASL mech DIGEST-MD5 Nov 17 10:11:02 firewall slapd[2901]: ==> sasl_bind: dn="" mech=<continuing> datalen=294 Nov 17 10:11:02 firewall slapd[2901]: SASL [conn=1002] Debug: DIGEST-MD5 server step 2 Nov 17 10:11:02 firewall slapd[2901]: SASL Canonicalize [conn=1002]: authcid="proxyuser" Nov 17 10:11:02 firewall slapd[2901]: slap_sasl_getdn: conn 1002 id=proxyuser [len=9] Nov 17 10:11:02 firewall slapd[2901]: slap_sasl_getdn: u:id converted to uid=proxyuser,cn=DIGEST-MD5,cn=auth Nov 17 10:11:02 firewall slapd[2901]: >>> dnNormalize: <uid=proxyuser,cn=DIGEST-MD5,cn=auth> Nov 17 10:11:02 firewall slapd[2901]: <<< dnNormalize: <uid=proxyuser,cn=digest-md5,cn=auth> Nov 17 10:11:02 firewall slapd[2901]: ==>slap_sasl2dn: converting SASL name uid=proxyuser,cn=digest-md5,cn=auth to a DN Nov 17 10:11:02 firewall slapd[2901]: [rw] authid: "uid=proxyuser,cn=digest-md5,cn=auth" -> "uid=proxyuser,ou=people,dc=plainjoe,dc=org" Nov 17 10:11:02 firewall slapd[2901]: slap_parseURI: parsing uid=proxyuser,ou=people,dc=plainjoe,dc=org Nov 17 10:11:02 firewall slapd[2901]: >>> dnNormalize: <uid=proxyuser,ou=people,dc=plainjoe,dc=org> Nov 17 10:11:02 firewall slapd[2901]: <<< dnNormalize: <uid=proxyuser,ou=people,dc=plainjoe,dc=org> Nov 17 10:11:02 firewall slapd[2901]: <==slap_sasl2dn: Converted SASL name to uid=proxyuser,ou=people,dc=plainjoe,dc=org Nov 17 10:11:02 firewall slapd[2901]: slap_sasl_getdn: dn:id converted to uid=proxyuser,ou=people,dc=plainjoe,dc=org Nov 17 10:11:02 firewall slapd[2901]: SASL Canonicalize [conn=1002]: slapAuthcDN="uid=proxyuser,ou=people,dc=plainjoe,dc=org" Nov 17 10:11:02 firewall slapd[2901]: => bdb_search Nov 17 10:11:02 firewall slapd[2901]: bdb_dn2entry("uid=proxyuser,ou=people,dc=plainjoe,dc=org") Nov 17 10:11:02 firewall slapd[2901]: => access_allowed: auth access to "uid=proxyuser,ou=people,dc=plainjoe,dc=org" "entry" requested Nov 17 10:11:02 firewall slapd[2901]: daemon: activity on 1 descriptor Nov 17 10:11:02 firewall slapd[2901]: daemon: activity on: Nov 17 10:11:02 firewall slapd[2901]: Nov 17 10:11:02 firewall slapd[2901]: daemon: epoll: listen=7 active_threads=0 tvp=zero Nov 17 10:11:02 firewall slapd[2901]: daemon: epoll: listen=8 active_threads=0 tvp=zero Nov 17 10:11:02 firewall slapd[2901]: => acl_get: [2] attr entry Nov 17 10:11:02 firewall slapd[2901]: => acl_mask: access to entry "uid=proxyuser,ou=people,dc=plainjoe,dc=org", attr "entry" requested Nov 17 10:11:02 firewall slapd[2901]: => acl_mask: to all values by "", (=0) Nov 17 10:11:02 firewall slapd[2901]: <= check a_dn_pat: * Nov 17 10:11:02 firewall slapd[2901]: <= acl_mask: [1] applying read(=rscxd) (stop) Nov 17 10:11:02 firewall slapd[2901]: <= acl_mask: [1] mask: read(=rscxd) Nov 17 10:11:02 firewall slapd[2901]: => slap_access_allowed: auth access granted by read(=rscxd) Nov 17 10:11:02 firewall slapd[2901]: => access_allowed: auth access granted by read(=rscxd) Nov 17 10:11:02 firewall slapd[2901]: base_candidates: base: "uid=proxyuser,ou=people,dc=plainjoe,dc=org" (0x00000011) Nov 17 10:11:02 firewall slapd[2901]: => test_filter Nov 17 10:11:02 firewall slapd[2901]: PRESENT Nov 17 10:11:02 firewall slapd[2901]: => access_allowed: auth access to "uid=proxyuser,ou=people,dc=plainjoe,dc=org" "objectClass" requested Nov 17 10:11:02 firewall slapd[2901]: => acl_get: [2] attr objectClass Nov 17 10:11:02 firewall slapd[2901]: => acl_mask: access to entry "uid=proxyuser,ou=people,dc=plainjoe,dc=org", attr "objectClass" requested Nov 17 10:11:02 firewall slapd[2901]: => acl_mask: to all values by "", (=0) Nov 17 10:11:02 firewall slapd[2901]: <= check a_dn_pat: * Nov 17 10:11:02 firewall slapd[2901]: <= acl_mask: [1] applying read(=rscxd) (stop) Nov 17 10:11:02 firewall slapd[2901]: <= acl_mask: [1] mask: read(=rscxd) Nov 17 10:11:02 firewall slapd[2901]: => slap_access_allowed: auth access granted by read(=rscxd) Nov 17 10:11:02 firewall slapd[2901]: => access_allowed: auth access granted by read(=rscxd) Nov 17 10:11:02 firewall slapd[2901]: <= test_filter 6 Nov 17 10:11:02 firewall slapd[2901]: => access_allowed: auth access to "uid=proxyuser,ou=people,dc=plainjoe,dc=org" "userPassword" requested Nov 17 10:11:02 firewall slapd[2901]: => acl_get: [1] attr userPassword Nov 17 10:11:02 firewall slapd[2901]: => acl_mask: access to entry "uid=proxyuser,ou=people,dc=plainjoe,dc=org", attr "userPassword" requested Nov 17 10:11:02 firewall slapd[2901]: => acl_mask: to all values by "", (=0) Nov 17 10:11:02 firewall slapd[2901]: <= check a_dn_pat: self Nov 17 10:11:02 firewall slapd[2901]: <= check a_dn_pat: anonymous Nov 17 10:11:02 firewall slapd[2901]: <= acl_mask: [2] applying auth(=xd) (stop) Nov 17 10:11:02 firewall slapd[2901]: <= acl_mask: [2] mask: auth(=xd) Nov 17 10:11:02 firewall slapd[2901]: => slap_access_allowed: auth access granted by auth(=xd) Nov 17 10:11:02 firewall slapd[2901]: => access_allowed: auth access granted by auth(=xd) Nov 17 10:11:02 firewall slapd[2901]: slap_ap_lookup: str2ad(cmusaslsecretDIGEST-MD5): attribute type undefined Nov 17 10:11:02 firewall slapd[2901]: send_ldap_result: conn=1002 op=1 p=3 Nov 17 10:11:02 firewall slapd[2901]: send_ldap_result: err=0 matched="" text="" Nov 17 10:11:02 firewall slapd[2901]: SASL Canonicalize [conn=1002]: authzid="test" Nov 17 10:11:02 firewall slapd[2901]: slap_sasl_getdn: conn 1002 id=test [len=4] Nov 17 10:11:02 firewall slapd[2901]: SASL [conn=1002] Failure: Inappropriate authentication Nov 17 10:11:02 firewall slapd[2901]: SASL [conn=1002] Failure: unable authorization ID Nov 17 10:11:02 firewall slapd[2901]: send_ldap_result: conn=1002 op=1 p=3 Nov 17 10:11:02 firewall slapd[2901]: send_ldap_result: err=50 matched="" text="SASL(-14): authorization failure: unable authorization ID" Nov 17 10:11:02 firewall slapd[2901]: send_ldap_response: msgid=2 tag=97 err=50 Nov 17 10:11:02 firewall slapd[2901]: daemon: activity on 1 descriptor Nov 17 10:11:02 firewall slapd[2901]: daemon: activity on: Nov 17 10:11:02 firewall slapd[2901]: 13r Nov 17 10:11:02 firewall slapd[2901]: Nov 17 10:11:02 firewall slapd[2901]: daemon: read active on 13 Nov 17 10:11:02 firewall slapd[2901]: daemon: epoll: listen=7 active_threads=0 tvp=zero Nov 17 10:11:02 firewall slapd[2901]: daemon: epoll: listen=8 active_threads=0 tvp=zero Nov 17 10:11:02 firewall slapd[2901]: connection_get(13) Nov 17 10:11:02 firewall slapd[2901]: connection_get(13): got connid=1002 Nov 17 10:11:02 firewall slapd[2901]: connection_read(13): checking for input on id=1002 Nov 17 10:11:02 firewall slapd[2901]: ber_get_next on fd 13 failed errno=0 (Success) Nov 17 10:11:02 firewall slapd[2901]: connection_read(13): input error=-2 id=1002, closing. Nov 17 10:11:02 firewall slapd[2901]: connection_closing: readying conn=1002 sd=13 for close Nov 17 10:11:02 firewall slapd[2901]: connection_close: deferring conn=1002 sd=13 Nov 17 10:11:02 firewall slapd[2901]: daemon: activity on 1 descriptor Nov 17 10:11:02 firewall slapd[2901]: daemon: activity on: Nov 17 10:11:02 firewall slapd[2901]: Nov 17 10:11:02 firewall slapd[2901]: daemon: epoll: listen=7 active_threads=0 tvp=zero Nov 17 10:11:02 firewall slapd[2901]: daemon: epoll: listen=8 active_threads=0 tvp=zero Nov 17 10:11:02 firewall slapd[2901]: conn=1002 op=1 RESULT tag=97 err=50 text=SASL(-14): authorization failure: unable authorization ID Nov 17 10:11:02 firewall slapd[2901]: <== slap_sasl_bind: rc=50 Nov 17 10:11:02 firewall slapd[2901]: connection_resched: attempting closing conn=1002 sd=13 Nov 17 10:11:02 firewall slapd[2901]: connection_close: conn=1002 sd=13 Nov 17 10:11:02 firewall slapd[2901]: daemon: removing 13 Nov 17 10:11:02 firewall slapd[2901]: conn=1002 fd=13 closed (connection lost) Nov 17 10:11:13 firewall sshd[2983]: Accepted keyboard-interactive/pam for root from 192.168.0.2 port 1622 ssh2 Nov 17 10:11:13 firewall sshd[2983]: subsystem request for sftp

3 2

understanding ACLs: dn.subtree vs. attrs=@something
by Isaac Hailperin 17 Nov '10

17 Nov '10

Hi, I am trying to build acls suitable to my setup: I have posix accounts in ou=people,ou=unix,dc=acme,dc=org and some more information about users (defined in an object class called "acmeUserAccount") in ou=people,ou=useradm,dc=acme,dc=org. Each posix account has a corresponding record in ou=useradm. These record pairs are connected by having the uid attribute defined equally. Now I want to restrict access to the ou=useradm tree, but not the ou=unix tree. As far as I can understand, there are at least two ways to do so: 1. using something like access to dn.subtree="ou=useradm,dc=acme,dc=org" by group="cn=useradmins,ou=group,ou=unix,dc=acme,dc=org" write by group="cn=consultants,ou=group,ou=unix,dc=acme,dc=org" read by * none This works as expected - giving write access to members of useradmins, and read access to members of consultants. 2. using something like access to attrs=@acmeUserAccount by group="cn=useradmins,ou=group,ou=unix,dc=acme,dc=org" write by group="cn=consultants,ou=group,ou=unix,dc=acme,dc=org" read by * none This also works as expected with regards to acmeUserAccount, but has funny side effects on ou=unix. To my understanding these two methods should have the same effect, as I only have records of type acmeUserAccount underneth ou=useradm. But: if I use 2), users don't have access to their data underneth ou=unix. Only the two groups mentioned have access to ou=unix as defined for acmeUserAccount. I read that using attrs=@someObjectClass affects also attributes that are defined in object classes that someObjectClass inherits from. My object class is defined as follows: objectclass ( managementOC:1 NAME 'acmeUserAccount' DESC 'Attributes needed for acme user management' SUP top STRUCTURAL MUST ( uid $ email ) MAY ( $ givenName $ surname $ federalState ) ) So it should inherit only from top, which I thought of as some abstract class without any attributes. Can someone explain this behaviour to me? Regards, Isaac

2 4

ITS#6459 syncprov memory leak work-around question
by Aaron Bennett 17 Nov '10

17 Nov '10

Hi, I'm bitten by the syncprov memory leak in ITS#6459. I'm hoping that the Ubuntu server team will backport this from upstream -- if they don't, I'll rebuild the package. In the meantime I'm wondering if switching from RefreshAndPersist to RefreshOnly would prevent this leak. Does this seem possible? Thanks, Aaron --- Aaron Bennett Manager of Systems Administration Clark University ITS

1 0

Debian 5 x OpenLDAP
by Márcio Luciano Donada 17 Nov '10

17 Nov '10

I'm using debian 5 (Linux ldap 2.6.26-2-686 #1 SMP Thu Sep 16 19:35:51 UTC 2010 i686 GNU/Linux) e OpenLDAP (2.4.11-1+lenny2), but I have had problems at times for the same, and always at dawn, I find nothing in the logs that can help me and it has to happen one day, is very variable. The only message I got in the logs is: Nov 17 05:36:19 ldap slapd[5728]: connection_read(50): no connection! Nov 17 05:53:50 ldap slapd[5728]: connection_read(27): no connection! Nov 17 08:04:19 ldap slapd[21558]: @(#) $OpenLDAP: slapd 2.4.11 (Jul 24 2010 08:14:20) $#012#011@murphy:/build/buildd-openldap_2.4.11-1+lenny2-i386-H5BDjb/openldap-2.4.11/debian/build/servers/slapd Nov 17 08:04:20 ldap slapd[21559]: slapd starting -- Márcio Luciano Donada <mdonada -at- auroraalimentos -dot- com -dot- br> Aurora Alimentos - Cooperativa Central Oeste Catarinense Departamento de T.I.

2 1

Role Based Attribute
by Anton Chu 16 Nov '10

16 Nov '10

Hi, I'm trying to find a way to setup ROLES instead of GROUPS. Roles are needed for certain applications access with additional permissions. Thanks in advance. Regards

2 1

Newly configured replication (master / slave) on 2.3 not quite working..
by Michael March 16 Nov '10

16 Nov '10

Entries are taking a LONG time to propagate (if they do at all).. I'm getting a TON of entries in the log like this on the slave side (continuously): Nov 16 21:03:54 sfo-dns-01 slapd[11864]: <= root access granted Nov 16 21:03:54 sfo-dns-01 slapd[11864]: <= test_filter 5 Nov 16 21:03:54 sfo-dns-01 slapd[11864]: bdb_search: 2629 does not match filter Nov 16 21:03:54 sfo-dns-01 slapd[11864]: entry_decode: "uid=mwatson,ou=People,dc=acme,dc=com" Nov 16 21:03:54 sfo-dns-01 slapd[11864]: <= entry_decode(uid=mwatson,ou=People,dc=acme,dc=com) Nov 16 21:03:54 sfo-dns-01 slapd[11864]: => test_filter Nov 16 21:03:54 sfo-dns-01 slapd[11864]: EQUALITY Nov 16 21:03:54 sfo-dns-01 slapd[11864]: => access_allowed: search access to "uid=mwatson,ou=People,dc=acme,dc=com" "entryUUID" requested Nov 16 21:03:54 sfo-dns-01 slapd[11864]: <= root access granted Nov 16 21:03:54 sfo-dns-01 slapd[11864]: <= test_filter 5 Nov 16 21:03:54 sfo-dns-01 slapd[11864]: bdb_search: 2630 does not match filter Nov 16 21:03:54 sfo-dns-01 slapd[11864]: entry_decode: "cn=mwatson,ou=Group,dc=acme,dc=com" Nov 16 21:03:54 sfo-dns-01 slapd[11864]: <= entry_decode(cn=mwatson,ou=Group,dc=acme,dc=com) Nov 16 21:03:54 sfo-dns-01 slapd[11864]: => test_filter Nov 16 21:03:54 sfo-dns-01 slapd[11864]: EQUALITY Nov 16 21:03:54 sfo-dns-01 slapd[11864]: => access_allowed: search access to "cn=mwatson,ou=Group,dc=acme,dc=com" "entryUUID" requested Nov 16 21:03:54 sfo-dns-01 slapd[11864]: <= root access granted Nov 16 21:03:54 sfo-dns-01 slapd[11864]: <= test_filter 5 Nov 16 21:03:54 sfo-dns-01 slapd[11864]: bdb_search: 2631 does not match filter Nov 16 21:03:54 sfo-dns-01 slapd[11864]: entry_decode: "ou=Contacts,uid=mwatson,ou=People,dc=acme,dc=com" Nov 16 21:03:54 sfo-dns-01 slapd[11864]: <= entry_decode(ou=Contacts,uid=mwatson,ou=People,dc=acme,dc=com) Nov 16 21:03:54 sfo-dns-01 slapd[11864]: => test_filter Nov 16 21:03:54 sfo-dns-01 slapd[11864]: EQUALITY Nov 16 21:03:54 sfo-dns-01 slapd[11864]: => access_allowed: search access to "ou=Contacts,uid=mwatson,ou=People,dc=acme,dc=com" "entryUUID" request ed Here's the slave config: include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/ldapab.schema include /etc/openldap/schema/ppolicy.schema allow bind_v2 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args modulepath /usr/lib64/openldap moduleload ppolicy.la TLSCertificateFile /etc/openldap/ldap.cert TLSCertificateKeyFile /etc/openldap/ldap.key database bdb suffix "dc=acme,dc=com" rootdn "uid=helpdesk,ou=People,dc=acme,dc=com" rootpw {SHA}FOOOOOO+pZB93s06zAM1vQo= directory /var/lib/ldap overlay ppolicy ppolicy_default "cn=default,ou=policies,dc=acme,dc=com" ppolicy_use_lockout sizelimit 2500 loglevel -1 directory /var/lib/ldap index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub syncrepl rid=123 provider=ldap://ldap-stage.acme.com:389 #type=refreshAndPersist type=refreshOnly interval=00:00:02:00 searchbase="dc=acme,dc=com" # filter="(objectClass=organizationalPerson)" filter="(objectClass=*)" updatedn "uid=helpdesk,ou=People,dc=acme,dc=com" scope=sub schemachecking=off bindmethod=simple binddn="uid=helpdesk,ou=People,dc=acme,dc=com" credentials=FOOOBAR updateref ldap://ldap-stage.acme.com -- <cowmix>

1 0

Problems with ppolicy_forward_updates and starttls with certificate-based auth
by Kartik Subbarao 16 Nov '10

16 Nov '10

I'm trying to get a consumer server to forward ppolicy-related updates to its provider server, and to use certificate-based authentication (SASL EXTERNAL) over STARTTLS when authenticating to the provider. This is with 2.4.23 on a Debian 5.0.5 system (I've seen similar issues reported elsewhere so I doubt this is platform specific). I'm running into multiple problems here. The core problem seems to be that enabling ppolicy_forward_updates breaks the chaining overlay such that it binds anonymously instead of with SASL EXTERNAL. Another problem is that bind operations to the consumer server start to return two result messages -- one with the error code of the chained operation, and one with the error code of the bind operation. This latter problem seems to the cause of the (still unresolved?) errors from this message thread earlier this year: http://www.mail-archive.com/openldap-technical@openldap.org/msg01215.html To simplify reproducing the problem, I've worked with test022-ppolicy in the openldap test framework. I've submitted ITS 6711 based on this. Here, I ran into another issue. I can't seem to be able to configure sasl external/starttls chaining properly with the cn=config style configuration that test022-ppolicy applies. The self-signed cert that I'm using works fine with replication, but it doesn't seem to work with chaining. This may or may not be another issue that needs to be resolved. In any case, with the attached files in the ITS, I hope that what I'm trying to do and the results that I'm getting should be as clear and unambiguous as possible. I'd appreciate any feedback on whether there is something else I need to configure or if there are bugs here that need to be fixed. Thanks, -Kartik

1 0

password problems
by Stef Coene 16 Nov '10

16 Nov '10

Hi, I can not figure out why my AIX box does not want to authenticate with my ldap server. I think I have a problem with the ldap setup so I can only bind to ldap with anonymous bind or with olcRoot. Checking password for cn=admin,dc=axi,dc=intra (my LDAP manager account): root@ldap1:/etc # ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=admin,dc=axi,dc=intra SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 # extended LDIF # # LDAPv3 # base <cn=admin,dc=axi,dc=intra> with scope subtree # filter: (objectclass=*) # requesting: ALL # # admin, axi.intra dn: cn=admin,dc=axi,dc=intra cn: admin objectClass: simpleSecurityObject objectClass: organizationalRole description: LDAP administrator userPassword:: e1NTSEF9UkJXSitCZy92V2ZLNlJ5Rzdwa1pvOStpQUh5aSt4NG0= # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Changing password: root@ldap1:/etc # ldappasswd -Y EXTERNAL -H ldapi:/// -s secret cn=admin,dc=axi,dc=intra SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 Checking that the password is changed: root@ldap1:/etc # ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=admin,dc=axi,dc=intra SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 # extended LDIF # # LDAPv3 # base <cn=admin,dc=axi,dc=intra> with scope subtree # filter: (objectclass=*) # requesting: ALL # # admin, axi.intra dn: cn=admin,dc=axi,dc=intra cn: admin objectClass: simpleSecurityObject objectClass: organizationalRole description: LDAP administrator userPassword:: e1NTSEF9TnBIK0hBN2JpWEczb0FSU1YwQm5HWmZSVll3S0NaTms= # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Using the password: root@ldap1:/etc # ldapsearch -D "cn=admin,dc=axi,dc=intra" -w secret ldap_bind: Invalid credentials (49) So I change the password but I can not use it ? Stef ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

2 3

Pass-Through authentication
by Paulo Jorge N. Correia (paucorre) 16 Nov '10

16 Nov '10

Hi all, I'm just starting with openLDAP and saslauth, and I'm trying to replicate what I can achieve with ADAM/AD LDS in Windows platform. I'm trying to use openldap to aggregate user information from several AD servers under different forests. So single point of contact from an LDAP perspective for an organization, and then openldap should pass-through the authentication request that receives to the AD DC of the respective user. This works well with saslauthd for a single domain, but if I need to do this with multiple domains, I don't know how to configure saslauthd. Can someone help ? Thank you, Paulo

3 7

I'm completely confused by ACLs ... @-)
by Götz Reinicke - IT-Koordinator 16 Nov '10

16 Nov '10

Hi, it should be so simple ... I thought. At first some things worked, but than I messed something up and now I'm completely confused. What I want (sooner or later): - users should authenticate using posix and samba accounts. - they may change there password. - they may look up other mail, phone, ... addresses in the ldap using Thunderbird or apple Addressbook - they may change there phone number and (may be) there postal address - admin users should be able to write and read everything. - anonymous users may later read the mail and cn/sn attribute. May be someone has such ACLs already set up and like to share them or can help me? Would be great, cause reading the docs and experiment is helpful, but I did not ended in a working secure, flexible, understandable setup. Thanks a lot and best 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

2 1

Problems Enabling Authentication using Cyrus SASL
by Fernando Torrez 16 Nov '10

16 Nov '10

Hi all I tried to enable SASL authentication using Cyrus SASL to both connect to openldap server and to authenticate users as this document explains: http://www.arschkrebs.de/slides/surviving_cyrus_sasl-handout.pdf I studied openldap and Cyrus SASL documentations with no success when I try to test my configuration with ldapwhoami I get this error: (with a second terminal running this cyrus sasl command: saslauthd -d -V -a ldap -r -O /etc/saslauthd.conf) firewall:~ # ldapwhoami -U proxyuser -X u:test -Y digest-md5 SASL/DIGEST-MD5 authentication started Please enter your password: ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): user not found: no secret in database I enabled full login (please see OPENLDAP LOGS below) and I realized that the 'proxyuser' is handled perfectly according to my configuration, but when trying to authenticate then 'test' user gets the error show above (OPENLDAP LOGS lines 138 to 141). I also realized that there is an strange error on line 123 (OPENLDAP LOGS): Nov 11 17:19:10 firewall slapd[11011]: slap_ap_lookup: str2ad(cmusaslsecretDIGEST-MD5): attribute type undefined I will appreciate any hints to fix this problem thanks in advance Below are all software used, configuration files, data stored on ldap server and the openldap logs SOFTWARE USED Opensuse 11.3 openldap2-client-2.4.21-9.1.i586 openldap2-2.4.21-9.1.i586 cyrus-sasl-gssapi-2.1.23-11.1.i586 cyrus-sasl-ldap-auxprop-2.1.23-11.2.i586 cyrus-sasl-saslauthd-2.1.23-11.2.i586 cyrus-sasl-2.1.23-11.1.i586 cyrus-sasl-plain-2.1.23-11.1.i586 cyrus-sasl-digestmd5-2.1.23-11.1.i586 cyrus-sasl-crammd5-2.1.23-11.1.i586 CONFIGURATION FILES /etc/saslauthd.conf ldap_servers: ldap://127.0.0.1/ ldap://192.168.1.2/ ldap_search_base: ou=people,dc=plainjoe,dc=org ldap_filter: (userPrincipalName=%u) ldap_bind_dn: uid=proxyuser,ou=people,dc=plainjoe,dc=org ldap_password: secret /etc/openldap/slapd.conf include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/yast.schema loglevel -1 pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args access to attrs=userPassword,userPKCS12 by self write by anonymous auth by dn.base="uid=proxyuser,ou=people,dc=plainjoe,dc=org" manage by users read by * none access to * by * read database bdb suffix "dc=plainjoe,dc=org" checkpoint 1024 5 cachesize 10000 rootdn "cn=Manager,dc=plainjoe,dc=org" # the password is: secret rootpw {MD5}Xr4ilOzQ4PCOq3aQ0qbuaQ== directory /var/lib/ldap index objectClass eq index cn,sn,mail eq,sub index departmentNumber eq password-hash {CLEARTEXT} authz-regexp uid=([^,]*),cn=[^,]*,cn=auth uid=$1,ou=people,dc=plainjoe,dc=org authz-policy to sasl-authz-policy to sasl-regexp uid=(.*),cn=DIGEST-MD5,cn=auth uid=$1,ou=people,dc=plainjoe,dc=org sasl-auxprops slapd sasl-host localhost /etc/sasl2/slapd.conf log_level: 7 mech_list: DIGEST-MD5 pwcheck_method: saslauthd saslauthd_path: /var/run/sasl2/mux #pwcheck_method: auxprop #auxprop_plugin: slapd # auxprop_plugin: ldapdb ldapdb_uri: ldap://localhost ldapdb_id: proxyuser ldapdb_pw: secret ldapdb_mech: DIGEST-MD5 DATA STORED ON LDAP SERVER firewall:~/openldap # slapcat bdb_monitor_db_open: monitoring disabled; configure monitor database to enable dn: dc=plainjoe,dc=org dc: plainjoe objectClass: dcObject objectClass: organizationalUnit ou: PlainJoe Dot Org structuralObjectClass: organizationalUnit entryUUID: 0335be26-7c73-102f-8bd2-599020d843b8 creatorsName: cn=Manager,dc=plainjoe,dc=org createTimestamp: 20101104152159Z entryCSN: 20101104152159.733766Z#000000#000#000000 modifiersName: cn=Manager,dc=plainjoe,dc=org modifyTimestamp: 20101104152159Z dn: ou=people,dc=plainjoe,dc=org ou: people objectClass: organizationalUnit structuralObjectClass: organizationalUnit entryUUID: 033e9352-7c73-102f-8bd3-599020d843b8 creatorsName: cn=Manager,dc=plainjoe,dc=org createTimestamp: 20101104152159Z entryCSN: 20101105231448.878588Z#000000#000#000000 modifiersName: cn=Manager,dc=plainjoe,dc=org modifyTimestamp: 20101105231448Z dn: cn=Gerald W. Carter,ou=people,dc=plainjoe,dc=org cn: Gerald W. Carter sn: Carter mail: jerry(a)plainjoe.org labeledURI: http://www.plainjoe.org/ roomNumber: 1234 Dudley Hall departmentNumber: Engineering telephoneNumber: 222-555-2345 pager: 222-555-6789 mobile: 222-555-1011 objectClass: inetOrgPerson structuralObjectClass: inetOrgPerson entryUUID: 6d8be49c-7c7a-102f-8bd4-599020d843b8 creatorsName: cn=Manager,dc=plainjoe,dc=org createTimestamp: 20101104161504Z entryCSN: 20101104162307.381290Z#000000#000#000000 modifiersName: cn=Manager,dc=plainjoe,dc=org modifyTimestamp: 20101104162307Z dn: cn=Gerry Carter,ou=people,dc=plainjoe,dc=org sn: Carter mail: carter(a)nowhere.net objectClass: inetOrgPerson structuralObjectClass: inetOrgPerson entryUUID: 6da59928-7c7a-102f-8bd5-599020d843b8 creatorsName: cn=Manager,dc=plainjoe,dc=org createTimestamp: 20101104161504Z labeledURI: http://www.plainjoe.org/~jerry/ telephoneNumber: 234-555-6789 begin_of_the_skype_highlighting 234-555-6789 end_of_the_skype_highlighting cn: Gerry Carter userPassword:: Z2Vycnk= entryCSN: 20101104212850.439996Z#000000#000#000000 modifiersName: cn=Manager,dc=plainjoe,dc=org modifyTimestamp: 20101104212850Z dn: uid=fernandito,ou=people,dc=plainjoe,dc=org uid: fernandito cn: Fernandito Torrez gidNumber: 10000 uidNumber: 10000 homeDirectory: /dev/null objectClass: account objectClass: posixAccount userPassword:: e21kNX1kZDAyYzdjMjIzMjc1OTg3NGUxYzIwNTU4NzAxN2JlZA== structuralObjectClass: account entryUUID: 44afffcc-7f90-102f-8d26-bf24473f4596 creatorsName: cn=Manager,dc=plainjoe,dc=org createTimestamp: 20101108142858Z entryCSN: 20101108142858.480384Z#000000#000#000000 modifiersName: cn=Manager,dc=plainjoe,dc=org modifyTimestamp: 20101108142858Z dn: uid=test,ou=people,dc=plainjoe,dc=org uid: test cn: testeo principal gidNumber: 10001 uidNumber: 10001 homeDirectory: /dev/null objectClass: account objectClass: posixAccount structuralObjectClass: account entryUUID: b3b5d6f4-8133-102f-9b9b-294e4b3fed35 creatorsName: cn=Manager,dc=plainjoe,dc=org createTimestamp: 20101110163123Z userPassword:: e01ENX1DWTlyelVZaDAzUEszazZESmllMDlnPT0= entryCSN: 20101110190152.065873Z#000000#000#000000 modifiersName: cn=Manager,dc=plainjoe,dc=org modifyTimestamp: 20101110190152Z dn: uid=proxyuser,ou=people,dc=plainjoe,dc=org uid: proxyuser cn: proxyuser gidNumber: 10002 uidNumber: 10002 homeDirectory: /dev/null objectClass: account objectClass: posixAccount userPassword:: e01ENX1YcjRpbE96UTRQQ09xM2FRMHFidWFRPT0= authzTo: dn.regex:uniqueIdentifier=(.*),ou=people,dc=plainjoe,dc=org structuralObjectClass: account entryUUID: 85999ef4-8214-102f-9c1d-411cc739a95b creatorsName: cn=Manager,dc=plainjoe,dc=org createTimestamp: 20101111192043Z entryCSN: 20101111192043.279474Z#000000#000#000000 modifiersName: cn=Manager,dc=plainjoe,dc=org modifyTimestamp: 20101111192043Z OPENLDAP LOGS 1 Nov 11 17:19:07 firewall slapd[11011]: daemon: activity on 1 descriptor 2 Nov 11 17:19:07 firewall slapd[11011]: daemon: activity on: 3 Nov 11 17:19:07 firewall slapd[11011]: 4 Nov 11 17:19:07 firewall slapd[11011]: slap_listener_activate(8): 5 Nov 11 17:19:07 firewall slapd[11011]: daemon: epoll: listen=7 active_threads=0 tvp=zero 6 Nov 11 17:19:07 firewall slapd[11011]: daemon: epoll: listen=8 busy 7 Nov 11 17:19:07 firewall slapd[11011]: >>> slap_listener(ldap://) 8 Nov 11 17:19:07 firewall slapd[11011]: daemon: listen=8, new connection on 12 9 Nov 11 17:19:07 firewall slapd[11011]: daemon: added 12r (active) listener=(nil) 10 Nov 11 17:19:07 firewall slapd[11011]: conn=1001 fd=12 ACCEPT from IP=[::1]:47665 (IP=[::]:389) 11 Nov 11 17:19:07 firewall slapd[11011]: daemon: activity on 1 descriptor 12 Nov 11 17:19:07 firewall slapd[11011]: daemon: activity on: 13 Nov 11 17:19:07 firewall slapd[11011]: 14 Nov 11 17:19:07 firewall slapd[11011]: daemon: epoll: listen=7 active_threads=0 tvp=zero 15 Nov 11 17:19:07 firewall slapd[11011]: daemon: epoll: listen=8 active_threads=0 tvp=zero 16 Nov 11 17:19:07 firewall slapd[11011]: daemon: activity on 1 descriptor 17 Nov 11 17:19:07 firewall slapd[11011]: daemon: activity on: 18 Nov 11 17:19:07 firewall slapd[11011]: 12r 19 Nov 11 17:19:07 firewall slapd[11011]: 20 Nov 11 17:19:07 firewall slapd[11011]: daemon: read active on 12 21 Nov 11 17:19:07 firewall slapd[11011]: daemon: epoll: listen=7 active_threads=0 tvp=zero 22 Nov 11 17:19:07 firewall slapd[11011]: daemon: epoll: listen=8 active_threads=0 tvp=zero 23 Nov 11 17:19:07 firewall slapd[11011]: connection_get(12) 24 Nov 11 17:19:07 firewall slapd[11011]: connection_get(12): got connid=1001 25 Nov 11 17:19:07 firewall slapd[11011]: connection_read(12): checking for input on id=1001 26 Nov 11 17:19:07 firewall slapd[11011]: op tag 0x60, time 1289510347 27 Nov 11 17:19:07 firewall slapd[11011]: conn=1001 op=0 do_bind 28 Nov 11 17:19:07 firewall slapd[11011]: >>> dnPrettyNormal: <> 29 Nov 11 17:19:07 firewall slapd[11011]: <<< dnPrettyNormal: <>, <> 30 Nov 11 17:19:07 firewall slapd[11011]: conn=1001 op=0 BIND dn="" method=163 31 Nov 11 17:19:07 firewall slapd[11011]: do_bind: dn () SASL mech DIGEST-MD5 32 Nov 11 17:19:07 firewall slapd[11011]: ==> sasl_bind: dn="" mech=DIGEST-MD5 datalen=0 33 Nov 11 17:19:07 firewall slapd[11011]: SASL [conn=1001] Debug: DIGEST-MD5 server step 1 34 Nov 11 17:19:07 firewall slapd[11011]: send_ldap_sasl: err=14 len=182 35 Nov 11 17:19:07 firewall slapd[11011]: send_ldap_response: msgid=1 tag=97 err=14 36 Nov 11 17:19:07 firewall slapd[11011]: conn=1001 op=0 RESULT tag=97 err=14 text=SASL(0): successful result: 37 Nov 11 17:19:07 firewall slapd[11011]: <== slap_sasl_bind: rc=14 38 Nov 11 17:19:07 firewall slapd[11011]: daemon: activity on 1 descriptor 39 Nov 11 17:19:07 firewall slapd[11011]: daemon: activity on: 40 Nov 11 17:19:07 firewall slapd[11011]: 41 Nov 11 17:19:07 firewall slapd[11011]: daemon: epoll: listen=7 active_threads=0 tvp=zero 42 Nov 11 17:19:07 firewall slapd[11011]: daemon: epoll: listen=8 active_threads=0 tvp=zero 43 Nov 11 17:19:07 firewall ldapwhoami: DIGEST-MD5 client step 2 44 Nov 11 17:19:10 firewall ldapwhoami: DIGEST-MD5 client step 2 45 Nov 11 17:19:10 firewall slapd[11011]: daemon: activity on 1 descriptor 46 Nov 11 17:19:10 firewall slapd[11011]: daemon: activity on: 47 Nov 11 17:19:10 firewall slapd[11011]: 12r 48 Nov 11 17:19:10 firewall slapd[11011]: 49 Nov 11 17:19:10 firewall slapd[11011]: daemon: read active on 12 50 Nov 11 17:19:10 firewall slapd[11011]: daemon: epoll: listen=7 active_threads=0 tvp=zero 51 Nov 11 17:19:10 firewall slapd[11011]: daemon: epoll: listen=8 active_threads=0 tvp=zero 52 Nov 11 17:19:10 firewall slapd[11011]: connection_get(12) 53 Nov 11 17:19:10 firewall slapd[11011]: connection_get(12): got connid=1001 54 Nov 11 17:19:10 firewall slapd[11011]: connection_read(12): checking for input on id=1001 55 Nov 11 17:19:10 firewall slapd[11011]: op tag 0x60, time 1289510350 56 Nov 11 17:19:10 firewall slapd[11011]: conn=1001 op=1 do_bind 57 Nov 11 17:19:10 firewall slapd[11011]: >>> dnPrettyNormal: <> 58 Nov 11 17:19:10 firewall slapd[11011]: <<< dnPrettyNormal: <>, <> 59 Nov 11 17:19:10 firewall slapd[11011]: conn=1001 op=1 BIND dn="" method=163 60 Nov 11 17:19:10 firewall slapd[11011]: do_bind: dn () SASL mech DIGEST-MD5 61 Nov 11 17:19:10 firewall slapd[11011]: ==> sasl_bind: dn="" mech=<continuing> datalen=296 62 Nov 11 17:19:10 firewall slapd[11011]: SASL [conn=1001] Debug: DIGEST-MD5 server step 2 63 Nov 11 17:19:10 firewall slapd[11011]: SASL Canonicalize [conn=1001]: authcid="proxyuser" 64 Nov 11 17:19:10 firewall slapd[11011]: slap_sasl_getdn: conn 1001 id=proxyuser [len=9] 65 Nov 11 17:19:10 firewall slapd[11011]: slap_sasl_getdn: u:id converted to uid=proxyuser,cn=DIGEST-MD5,cn=auth 66 Nov 11 17:19:10 firewall slapd[11011]: >>> dnNormalize: <uid=proxyuser,cn=DIGEST-MD5,cn=auth> 67 Nov 11 17:19:10 firewall slapd[11011]: <<< dnNormalize: <uid=proxyuser,cn=digest-md5,cn=auth> 68 Nov 11 17:19:10 firewall slapd[11011]: ==>slap_sasl2dn: converting SASL name uid=proxyuser,cn=digest-md5,cn=auth to a DN 69 Nov 11 17:19:10 firewall slapd[11011]: [rw] authid: "uid=proxyuser,cn=digest-md5,cn=auth" -> "uid=proxyuser,ou=people,dc=plainjoe,dc=org" 70 Nov 11 17:19:10 firewall slapd[11011]: slap_parseURI: parsing uid=proxyuser,ou=people,dc=plainjoe,dc=org 71 Nov 11 17:19:10 firewall slapd[11011]: >>> dnNormalize: <uid=proxyuser,ou=people,dc=plainjoe,dc=org> 72 Nov 11 17:19:10 firewall slapd[11011]: <<< dnNormalize: <uid=proxyuser,ou=people,dc=plainjoe,dc=org> 73 Nov 11 17:19:10 firewall slapd[11011]: <==slap_sasl2dn: Converted SASL name to uid=proxyuser,ou=people,dc=plainjoe,dc=org 74 Nov 11 17:19:10 firewall slapd[11011]: slap_sasl_getdn: dn:id converted to uid=proxyuser,ou=people,dc=plainjoe,dc=org 75 Nov 11 17:19:10 firewall slapd[11011]: SASL Canonicalize [conn=1001]: slapAuthcDN="uid=proxyuser,ou=people,dc=plainjoe,dc=org" 76 Nov 11 17:19:10 firewall slapd[11011]: => bdb_search 77 Nov 11 17:19:10 firewall slapd[11011]: bdb_dn2entry("uid=proxyuser,ou=people,dc=plainjoe,dc=org") 78 Nov 11 17:19:10 firewall slapd[11011]: => bdb_dn2id("dc=plainjoe,dc=org") 79 Nov 11 17:19:10 firewall slapd[11011]: daemon: activity on 1 descriptor 80 Nov 11 17:19:10 firewall slapd[11011]: daemon: activity on: 81 Nov 11 17:19:10 firewall slapd[11011]: 82 Nov 11 17:19:10 firewall slapd[11011]: daemon: epoll: listen=7 active_threads=0 tvp=zero 83 Nov 11 17:19:10 firewall slapd[11011]: daemon: epoll: listen=8 active_threads=0 tvp=zero 84 Nov 11 17:19:10 firewall slapd[11011]: <= bdb_dn2id: got id=0x1 85 Nov 11 17:19:10 firewall slapd[11011]: => bdb_dn2id("ou=people,dc=plainjoe,dc=org") 86 Nov 11 17:19:10 firewall slapd[11011]: <= bdb_dn2id: got id=0x2 87 Nov 11 17:19:10 firewall slapd[11011]: => bdb_dn2id("uid=proxyuser,ou=people,dc=plainjoe,dc=org") 88 Nov 11 17:19:10 firewall slapd[11011]: <= bdb_dn2id: got id=0x10 89 Nov 11 17:19:10 firewall slapd[11011]: entry_decode: "uid=proxyuser,ou=people,dc=plainjoe,dc=org" 90 Nov 11 17:19:10 firewall slapd[11011]: <= entry_decode(uid=proxyuser,ou=people,dc=plainjoe,dc=org) 91 Nov 11 17:19:10 firewall slapd[11011]: => access_allowed: auth access to "uid=proxyuser,ou=people,dc=plainjoe,dc=org" "entry" requested 92 Nov 11 17:19:10 firewall slapd[11011]: => acl_get: [2] attr entry 93 Nov 11 17:19:10 firewall slapd[11011]: => acl_mask: access to entry "uid=proxyuser,ou=people,dc=plainjoe,dc=org", attr "entry" requested 94 Nov 11 17:19:10 firewall slapd[11011]: => acl_mask: to all values by "", (=0) 95 Nov 11 17:19:10 firewall slapd[11011]: <= check a_dn_pat: * 96 Nov 11 17:19:10 firewall slapd[11011]: <= acl_mask: [1] applying read(=rscxd) (stop) 97 Nov 11 17:19:10 firewall slapd[11011]: <= acl_mask: [1] mask: read(=rscxd) 98 Nov 11 17:19:10 firewall slapd[11011]: => slap_access_allowed: auth access granted by read(=rscxd) 99 Nov 11 17:19:10 firewall slapd[11011]: => access_allowed: auth access granted by read(=rscxd) 100 Nov 11 17:19:10 firewall slapd[11011]: base_candidates: base: "uid=proxyuser,ou=people,dc=plainjoe,dc=org" (0x00000010) 101 Nov 11 17:19:10 firewall slapd[11011]: => test_filter 102 Nov 11 17:19:10 firewall slapd[11011]: PRESENT 103 Nov 11 17:19:10 firewall slapd[11011]: => access_allowed: auth access to "uid=proxyuser,ou=people,dc=plainjoe,dc=org" "objectClass" requested 104 Nov 11 17:19:10 firewall slapd[11011]: => acl_get: [2] attr objectClass 105 Nov 11 17:19:10 firewall slapd[11011]: => acl_mask: access to entry "uid=proxyuser,ou=people,dc=plainjoe,dc=org", attr "objectClass" requested 106 Nov 11 17:19:10 firewall slapd[11011]: => acl_mask: to all values by "", (=0) 107 Nov 11 17:19:10 firewall slapd[11011]: <= check a_dn_pat: * 108 Nov 11 17:19:10 firewall slapd[11011]: <= acl_mask: [1] applying read(=rscxd) (stop) 109 Nov 11 17:19:10 firewall slapd[11011]: <= acl_mask: [1] mask: read(=rscxd) 110 Nov 11 17:19:10 firewall slapd[11011]: => slap_access_allowed: auth access granted by read(=rscxd) 111 Nov 11 17:19:10 firewall slapd[11011]: => access_allowed: auth access granted by read(=rscxd) 112 Nov 11 17:19:10 firewall slapd[11011]: <= test_filter 6 113 Nov 11 17:19:10 firewall slapd[11011]: => access_allowed: auth access to "uid=proxyuser,ou=people,dc=plainjoe,dc=org" "userPassword" requested 114 Nov 11 17:19:10 firewall slapd[11011]: => acl_get: [1] attr userPassword 115 Nov 11 17:19:10 firewall slapd[11011]: => acl_mask: access to entry "uid=proxyuser,ou=people,dc=plainjoe,dc=org", attr "userPassword" requested 116 Nov 11 17:19:10 firewall slapd[11011]: => acl_mask: to all values by "", (=0) 117 Nov 11 17:19:10 firewall slapd[11011]: <= check a_dn_pat: self 118 Nov 11 17:19:10 firewall slapd[11011]: <= check a_dn_pat: anonymous 119 Nov 11 17:19:10 firewall slapd[11011]: <= acl_mask: [2] applying auth(=xd) (stop) 120 Nov 11 17:19:10 firewall slapd[11011]: <= acl_mask: [2] mask: auth(=xd) 121 Nov 11 17:19:10 firewall slapd[11011]: => slap_access_allowed: auth access granted by auth(=xd) 122 Nov 11 17:19:10 firewall slapd[11011]: => access_allowed: auth access granted by auth(=xd) 123 Nov 11 17:19:10 firewall slapd[11011]: slap_ap_lookup: str2ad(cmusaslsecretDIGEST-MD5): attribute type undefined 124 Nov 11 17:19:10 firewall slapd[11011]: send_ldap_result: conn=1001 op=1 p=3 125 Nov 11 17:19:10 firewall slapd[11011]: send_ldap_result: err=0 matched="" text="" 126 Nov 11 17:19:10 firewall slapd[11011]: SASL Canonicalize [conn=1001]: authzid="u:test" 127 Nov 11 17:19:10 firewall slapd[11011]: slap_sasl_getdn: conn 1001 id=u:test [len=6] 128 Nov 11 17:19:10 firewall slapd[11011]: slap_sasl_getdn: u:id converted to uid=test,cn=DIGEST-MD5,cn=auth 129 Nov 11 17:19:10 firewall slapd[11011]: >>> dnNormalize: <uid=test,cn=DIGEST-MD5,cn=auth> 130 Nov 11 17:19:10 firewall slapd[11011]: <<< dnNormalize: <uid=test,cn=digest-md5,cn=auth> 131 Nov 11 17:19:10 firewall slapd[11011]: ==>slap_sasl2dn: converting SASL name uid=test,cn=digest-md5,cn=auth to a DN 132 Nov 11 17:19:10 firewall slapd[11011]: [rw] authid: "uid=test,cn=digest-md5,cn=auth" -> "uid=test,ou=people,dc=plainjoe,dc=org" 133 Nov 11 17:19:10 firewall slapd[11011]: slap_parseURI: parsing uid=test,ou=people,dc=plainjoe,dc=org 134 Nov 11 17:19:10 firewall slapd[11011]: >>> dnNormalize: <uid=test,ou=people,dc=plainjoe,dc=org> 135 Nov 11 17:19:10 firewall slapd[11011]: <<< dnNormalize: <uid=test,ou=people,dc=plainjoe,dc=org> 136 Nov 11 17:19:10 firewall slapd[11011]: <==slap_sasl2dn: Converted SASL name to uid=test,ou=people,dc=plainjoe,dc=org 137 Nov 11 17:19:10 firewall slapd[11011]: slap_sasl_getdn: dn:id converted to uid=test,ou=people,dc=plainjoe,dc=org 138 Nov 11 17:19:10 firewall slapd[11011]: SASL Canonicalize [conn=1001]: slapAuthzDN="uid=test,ou=people,dc=plainjoe,dc=org" 139 Nov 11 17:19:10 firewall slapd[11011]: SASL [conn=1001] Failure: no secret in database 140 Nov 11 17:19:10 firewall slapd[11011]: send_ldap_result: conn=1001 op=1 p=3 141 Nov 11 17:19:10 firewall slapd[11011]: send_ldap_result: err=49 matched="" text="SASL(-13): user not found: no secret in database" 142 Nov 11 17:19:10 firewall slapd[11011]: send_ldap_response: msgid=2 tag=97 err=49 143 Nov 11 17:19:10 firewall slapd[11011]: daemon: activity on 1 descriptor 144 Nov 11 17:19:10 firewall slapd[11011]: daemon: activity on: 145 Nov 11 17:19:10 firewall slapd[11011]: 12r 146 Nov 11 17:19:10 firewall slapd[11011]: 147 Nov 11 17:19:10 firewall slapd[11011]: daemon: read active on 12 148 Nov 11 17:19:10 firewall slapd[11011]: daemon: epoll: listen=7 active_threads=0 tvp=zero 149 Nov 11 17:19:10 firewall slapd[11011]: daemon: epoll: listen=8 active_threads=0 tvp=zero 150 Nov 11 17:19:10 firewall slapd[11011]: connection_get(12) 151 Nov 11 17:19:10 firewall slapd[11011]: connection_get(12): got connid=1001 152 Nov 11 17:19:10 firewall slapd[11011]: connection_read(12): checking for input on id=1001 153 Nov 11 17:19:10 firewall slapd[11011]: ber_get_next on fd 12 failed errno=0 (Success) 154 Nov 11 17:19:10 firewall slapd[11011]: connection_read(12): input error=-2 id=1001, closing. 155 Nov 11 17:19:10 firewall slapd[11011]: connection_closing: readying conn=1001 sd=12 for close 156 Nov 11 17:19:10 firewall slapd[11011]: connection_close: deferring conn=1001 sd=12 157 Nov 11 17:19:10 firewall slapd[11011]: daemon: activity on 1 descriptor 158 Nov 11 17:19:10 firewall slapd[11011]: daemon: activity on: 159 Nov 11 17:19:10 firewall slapd[11011]: 160 Nov 11 17:19:10 firewall slapd[11011]: daemon: epoll: listen=7 active_threads=0 tvp=zero 161 Nov 11 17:19:10 firewall slapd[11011]: daemon: epoll: listen=8 active_threads=0 tvp=zero 162 Nov 11 17:19:10 firewall slapd[11011]: conn=1001 op=1 RESULT tag=97 err=49 text=SASL(-13): user not found: no secret in database 163 Nov 11 17:19:10 firewall slapd[11011]: <== slap_sasl_bind: rc=49 164 Nov 11 17:19:10 firewall slapd[11011]: connection_resched: attempting closing conn=1001 sd=12 165 Nov 11 17:19:10 firewall slapd[11011]: connection_close: conn=1001 sd=12 166 Nov 11 17:19:10 firewall slapd[11011]: daemon: removing 12 167 Nov 11 17:19:10 firewall slapd[11011]: conn=1001 fd=12 closed (connection lost)

2 1

No object has been found error message
by Darouichi, Aziz 15 Nov '10

15 Nov '10

Hi all, Friday last week before I left for the week end LDAP was working fine with no problems. This morning When I tried to do an ldapsearch, I get error no such object (32) error. I checked ldap services and they are running fine. Plus I have a script that sends emails and restarts ldap services if there is a problem on the week end or a night. No emails were generated and no changes have been made. FY this is openldap-2.3.43-12.el5_5.2 Thanks, Aziz

2 1

AIX as openldap client
by Stef Coene 15 Nov '10

15 Nov '10

Hi, Some time ago, I configured an ubuntu intrepid as openldap server and I was able to use it as authentication server for AIX 6.1. I tried the same with an ubuntu maverick server, but I can not get it working anymore. I can see all the user information on the AIX server. I can do 'su - <user>' to become the user. But I can not login so I think there is a problem with the password. When I change the password of a user on the AIX server, I get these errors in the logfile on the openldap server: Oct 26 20:44:12 ldap1 slapd[28664]: Entry (uid=xxx,ou=people,dc=xxx,dc=xxx), attribute 'shadowLastChange' not allowed Oct 26 20:44:12 ldap1 slapd[28664]: entry failed schema check: attribute 'shadowLastChange' not allowed Is this important? The intrepid has version 2.4.11-0ubuntu6.2, the maverick has version 2.4.21-0ubuntu5.3. I didn't noted down what I did on the intrepid server, but I can remember that it asked a bunch of questions when I installed slapd. These initial steps are removed from the maverick version. I also remember using the ldapinit command. How can I debug the difference between these 2 versions? Using slapcat, I can see some differeces, but nothing that is important in my opinion. How can I debug the openldap server to see what's going on? I can use the openldap server on a linux ldap client without problems. Stef PS I also tried to post this message to openldap-software(a)openldap.org, but I got a 'Delivery status notification' saying that the user does not exist.

6 17

Performance issues lately.
by Jorgen Lundman 14 Nov '10

14 Nov '10

Hello list, Solaris 10u8 db-4.8.30.NC openldap-2.4.23 So in the last week, simple queries have been really slow. For example: # time /usr/local/bin/ldapsearch -h 0 -D cn=admin,dc=company,dc=com -x -w pass -b ou=mail,dc=company,dc=com mail=testlookup(a)domain.com 1m21s Of course "mail" in indexed. The server is dedicated to LDAP (test server) so there are no other connections. Not even syncrepl connection. I have checked the usual things, memory usage, BDB cache, and disk IO. All seem to be within reasonable limits. Then I went deeper. I started trussing it, and it seems to send the query reply nearly right away, then sit around 200 seconds before we send a few more bytes and exit. I tried out db_stat on various db, and found it is also really slow on stat on "id2entry.bdb". For example: # time /usr/local/BerkeleyDB.4.8/bin/db_stat -d id2entry.bdb 2m32s So, trussing that call (including all calls in libdb-4.2): 19700/1@1: 0.0001 -> libdb-4.8:__db_stat_print_pp(0x419920, 0x0, 0x412c30, 0x4146a0, 0xfffffd7fffdff880, 0xfffffd7fffdff824) 19700/1: 0.0009 time() = 128972 5450 19700/1: 0.0001 brk(0x0041EC20) = 0 19700/1: 0.0001 brk(0x00422C20) = 0 19700/1: 0.0001 open("/usr/share/lib/zoneinfo/Japan", O_RDONLY) = 4 19700/1: 0.0000 fstat(4, 0xFFFFFD7FFFDFF880) = 0 19700/1: 0.0001 read(4, 0xFFFFFD7FFEEA0880, 125) = 125 19700/1: T Z i f\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\003\0\0\003\0\0\0 \0 19700/1: \0\0\0\t\0\0\003\0\0\0\fC3CE85 pD7 >1E90D7EC1680D8F91690D9CBF8 80 19700/1: DB071D10DBABDA80DCE6FF10DD8BBC80020102010201020102\0\0 ~90\0\0 \0 19700/1: \08CA00104\0\0 ~90\0\b C J T\0 J D T\0 J S T\0\0\0\0\0\0\0 19700/1: 0.0000 close(4) = 0 19700/1: 0.0002 ioctl(1, TCGETA, 0xFFFFFD7FFFDFE8B0) = 0 19700/1: 0.0000 fstat(1, 0xFFFFFD7FFFDFE840) = 0 19700/1: 0.0001 write(1, 0xFFFFFD7FFF006764, 36) = 36 19700/1: S u n N o v 1 4 1 8 : 0 4 : 1 0 2 0 1 0\t L o c a l t 19700/1: i m e\n 19700/1: 589.8794 write(1, 0xFFFFFD7FFF006764, 25) = 25 19700/1: 5 3 1 6 2\t B t r e e m a g i c n u m b e r\n 19700/1: 0.0046 write(1, 0xFFFFFD7FFF006764, 23) = 23 Not entirely sure why a write (everything leading up) to stdout takes 589 seconds. I have tried rebuilding the whole database with slapadd but made no difference. I put all DB files in /tmp on x4540 (has 32G RAM) and yet, still 2mins to do db_stat. General db_stat -m output: 4GB Total cache size 8 Number of caches 8 Maximum number of caches 512MB Pool individual cache size 0 Maximum memory-mapped file size 0 Maximum open file descriptors 0 Maximum sequential buffer writes 0 Sleep after writing maximum sequential buffers 0 Requested pages mapped into the process' address space 407M Requested pages found in the cache (99%) 38 Requested pages not found in the cache 425405 Pages created in the cache 38 Pages read into the cache 425427 Pages written from the cache to the backing file 0 Clean pages forced from the cache 0 Dirty pages forced from the cache 0 Dirty pages written by trickle-sync thread 425427 Current total page count 425427 Current clean page count 0 Current dirty page count 524296 Number of hash buckets used for page location 4096 Assumed page size used 407M Total number of times hash chains searched for a page (407904893) 32 The longest hash chain searched for a page 466M Total number of hash chain entries checked for page (466861223) 0 The number of hash bucket locks that required waiting (0%) 0 The maximum number of times any hash bucket lock was waited for (0%) 0 The number of region locks that required waiting (0%) 0 The number of buffers frozen 0 The number of buffers thawed 0 The number of frozen buffers freed 425538 The number of page allocations 0 The number of hash buckets examined during allocations 0 The maximum number of hash buckets examined for an allocation 0 The number of pages examined during allocations 0 The max number of pages examined for an allocation 0 Threads waited on page I/O 0 The number of times a sync is interrupted Pool File: id2entry.bdb 16384 Page size 0 Requested pages mapped into the process' address space 13M Requested pages found in the cache (99%) 2 Requested pages not found in the cache 163449 Pages created in the cache 2 Pages read into the cache 163451 Pages written from the cache to the backing file Pool File: mail.bdb 4096 Page size 0 Requested pages mapped into the process' address space 2797594 Requested pages found in the cache (99%) 2 Requested pages not found in the cache 3335 Pages created in the cache 2 Pages read into the cache 3337 Pages written from the cache to the backing file -rw-r--r-- 1 root root 168 Nov 14 12:54 DB_CONFIG -rw------- 1 root root 3.8M Nov 14 14:03 DNSData.bdb -rw------- 1 root root 5.4M Nov 14 14:03 DNSHostName.bdb -rw------- 1 root root 3.3M Nov 14 14:03 DNSIPAddr.bdb -rw------- 1 root root 2.7M Nov 14 14:03 DNSType.bdb -rw------- 1 root root 24K Nov 14 12:54 __db.001 -rw------- 1 root root 180M Nov 14 18:28 __db.002 -rw------- 1 root root 512M Nov 14 13:45 __db.003 -rw------- 1 root root 512M Nov 14 14:35 __db.004 -rw------- 1 root root 512M Nov 14 14:40 __db.005 -rw------- 1 root root 512M Nov 14 13:45 __db.006 -rw------- 1 root root 512M Nov 14 13:45 __db.007 -rw------- 1 root root 512M Nov 14 13:45 __db.008 -rw------- 1 root root 512M Nov 14 14:35 __db.009 -rw------- 1 root root 512M Nov 14 14:27 __db.010 -rw------- 1 root root 160K Nov 14 12:54 __db.011 -rw------- 1 root root 1.2M Nov 14 18:25 __db.012 -rw------- 1 root root 32K Nov 14 12:54 __db.013 -rw------- 1 root root 2.1M Nov 14 14:03 accountStatus.bdb -rw-r--r-- 1 root root 2.0K Nov 14 16:12 alock -rw------- 1 root root 536K Nov 14 14:03 deliveryMode.bdb -rw------- 1 root root 621M Nov 14 14:07 dn2id.bdb -rw------- 1 root root 172M Nov 14 14:03 entryCSN.bdb -rw------- 1 root root 125M Nov 14 14:03 entryUUID.bdb -rw------- 1 root root 17M Nov 14 14:03 gecos.bdb -rw------- 1 root root 1.8M Nov 14 14:03 gidNumber.bdb -rw------- 1 root root 2.5G Nov 14 14:40 id2entry.bdb -rw------- 1 root root 50M Nov 14 16:12 log.0000000266 -rw------- 1 root root 13M Nov 14 14:03 mail.bdb -rw------- 1 root root 3.2M Nov 14 14:03 mailAlternateAddress.bdb -rw------- 1 root root 8.7M Nov 14 14:03 o.bdb -rw------- 1 root root 4.9M Nov 14 14:03 objectClass.bdb -rw------- 1 root root 1.3M Nov 14 14:03 radiusGroupName.bdb -rw------- 1 root root 20M Nov 14 14:03 uid.bdb -rw------- 1 root root 17M Nov 14 14:03 uidNumber.bdb checkpoint 128 15 cachesize 5000 idlcachesize 15000 overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 1000 # DB_CONFIG FILE. Warning, these entries are only written if the DB_CONFIG # file DOES NOT EXIST. So if you change any of these values, you will need # to remove the file, then restart slapd. dbconfig set_lk_detect DB_LOCK_DEFAULT dbconfig set_lg_max 52428800 dbconfig set_cachesize 4 0 8 dbconfig set_flags db_log_autoremove dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 # DB_CONFIG FILE. Any suggestions? Must have hit some limit somewhere I guess. Lund

4 9

Chaining not working
by Jaap Winius 14 Nov '10

14 Nov '10

Hi folks, While testing the current Debian squeeze version of OpenLDAP, v2.4.23-6, in a provider/consumer syncprov/syncrepl (refreshAndPersist) configuration, using a patch(1) written by Pierangelo, I have not been able to get chaining to work. The consumer, ldaps2, was configured with a referral(2) to the provider, ldaps1, as well as a chaining configuration(3). A couple of authzTo rules(4) were added to its entry in the DIT, which immediately replicated to the consumer, and the provider was configured with an olcAuthzPolicy directive for "to"(5). So far, so good. However, when using ldapmodify on the consumer to test that an entry in the DIT could actually be modified (the description attr of the consumer's entry) from there as a result, I got this response: ------------------------------------------------------------ modifying entry "cn=ldaps2,dc=example,dc=com" ldap_modify: Referral (10) referrals: ldap://ldaps.example.com/cn=ldaps2,dc=example,dc=com ------------------------------------------------------------ I know ldapmodify doesn't understand referrals; this is where chaining should have worked instead. So, I removed the referral from the consumer's configuration to see what would then happen with the same command: ------------------------------------------------------------ modifying entry "cn=ldaps2,dc=example,dc=com" ldap_modify: Server is unwilling to perform (53) additional info: shadow context; no update referral ------------------------------------------------------------ (shadow context?). In both cases, this shows up in the syslog as a result: ------------------------------------------------------------ Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 fd=19 ACCEPT from IP=127.0.1.1:43982 (IP=0.0.0.0:389) Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=0 BIND dn="cn=admin,dc=example,dc=com" method=128 Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=0 BIND dn="cn=admin,dc=example,dc=com" mech=SIMPLE ssf=0 Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=0 RESULT tag=97 err=0 text= Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=1 MOD dn="cn=ldaps2,dc=example,dc=com" Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=1 MOD attr=description Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=1 RESULT tag=103 err=53 text=shadow context; no update referral Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=2 UNBIND Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 fd=19 closed ------------------------------------------------------------ Have I made a mistake somewhere, or could this be another bug? Thanks, Jaap 1) ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-29-chain.1.patch 2) LDIF applied to ldaps2 (the consumer) to create the referral to ldaps1 (the provider) via an alias (ldaps): --------------------------------- dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcUpdateref olcUpdateref: ldap://ldaps.example.com --------------------------------- 3) LDIF applied to ldaps2 to create the chaining configuration: --------------------------------- dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: {1}back_ldap dn: olcOverlay={0}chain,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain olcChainReturnError: TRUE dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: ldap://ldaps.example.com olcDbRebindAsUser: TRUE olcDbIDAssertBind: bindmethod=simple binddn="cn=ldaps2,dc=example,dc=com" credentials=bilineatus mode=self --------------------------------- 4) LDIF to create a couple of authzTo rules for the consumer: --------------------------------- dn: cn=ldaps2,dc=example,dc=com changetype: modify add: authzTo authzTo: {0}dn.regex:^uid=[^,]+,ou=people,dc=example,dc=com$ authzTo: {1}dn.exact:cn=admin,dc=example,dc=com --------------------------------- 5) LDIF to add an olcAuthzPolicy directive to the provider, ldaps1: --------------------------------- dn: cn=config changetype: modify add: olcAuthzPolicy olcAuthzPolicy: to ---------------------------------

2 2

Re: Trying to understand an error message
by Khaled Blah 13 Nov '10

13 Nov '10

Thanks for your reply, Hallvard. Do I understand it correctly that I can re-use LDAP structures on which a bind has already been done? Do you know of any other stateful data I would have to look at? Regards, Khaled 2010/11/12 Hallvard B Furuseth <h.b.furuseth(a)usit.uio.no>: > Khaled Blah writes: >> My application creates LDAP structures (using ldap_init) and re-uses >> these structures whenever possible so that the least number of LDAP >> binds have to done. Is there anything I need to do after an LDAP >> operation has finished or maybe do I have to unbind at some point to >> make sure the LDAP structure remains in a valid state? I would be >> happy to receive any insight into this. > > With LDAP *ld, call ldap_unbind(ld) when you are finished with ld, and > not before. ldap_unbind() is actually the destructor for an LDAP*, in > addition to sending an Unbind message. > > -- > Hallvard >

2 2

Out of memory Errors when starting up Slurpd: Openldap-server-2.3.43
by Traiano Welcome 13 Nov '10

13 Nov '10

Hi List We're using openldap-server 2.3.43 on FreeBSD 6.2-RELEASE-p9 #0. When trying to start up slurpd (/usr/local/etc/rc.d/slurpd start), slurpd runs for a while then dies at various points during it's replication with error "Out of memory". The following are various attempts to start slurpd, with the last messages it dies with before "Out of Memory". My question is: Is this a known bug? What could be the cause of these out of memory errors in Slurpd? Test one: --- Initializing session to ldap://server.ops.aanet.co.za:389 Error: ldap_initialize(0, ldap://server.ops.aanet.co.za:389) failed: Out of memory --- Test two: --- malloc of 3 bytes failed Error: ldap_modify_s failed modifying DN "uid=sherbert.buth,ou=mycast.co.za,ou=AuthSystem,dc=za,dc=oo,dc=com": Out of memory --- Test three: ---- Error: ldap operation failed, data written to "/var/db/openldap-slurp/replica/server.ops.aanet.co.za:389.rej" ---- Test four: --- Error: ldap_modify_s failed modifying DN "uid=bruce,ou=fatnet.co.za,ou=AuthSystem,dc=za,dc=uu,dc=net": Out of memory --- Test 5: --- Error: ldap operation failed, data written to "/var/db/openldap-slurp/replica/server.ops.aanet.co.za:389.rej" --- Test 6: --- ldif_parse_line: type malloc failed Error: malformed replog line "replace: sn" Warning: freeing re (dn: uid=dericks,ou=anb.co.za,ou=AuthSystem,dc=za,dc=uu,dc=net) with nonzero refcnt error: malformed replog entry (begins with "replica: server.ops.aanet.co.za:389") Error: ldap_modify_s failed modifying DN "uid=tyrone,ou=business.net,ou=AuthSystem,dc=za,dc=,dc=net": Out of memory Error: ldap operation failed, data written to "/var/db/openldap-slurp/replica/server.ops.aanet.co.za:389.rej" ldif_parse_line: value malloc failed Error: malformed replog line "olcPasswordHash: 92XXXXXXXXXXXXXXXXXXXX" Warning: freeing re (dn: uid=adi,ou=anb.co.za,ou=AuthSystem,dc=za,dc=oo,dc=net) with nonzero refcnt error: malformed replog entry (begins with "replica: server.ops.aanet.co.za:389") malloc of 12 bytes failed malloc of 8 bytes failed --- Thanks in Advance, Traiano Welcome

2 1

Assigning a Member to Multiple Groups
by Anton Chu 12 Nov '10

12 Nov '10

Unfortunately there's can only be one GID number per user entry into the DIT, how can I assign multiple groups to one user? So when that user logs into a server, he or she will have multiple group IDs.

2 1

How to convert Solaris m5 passwords to LDAP?
by Christian Schmidt 12 Nov '10

12 Nov '10

Hi all, we want to switch a server machine from Solaris (credentials stored in "traditional" passwd and shadow file) to Debian with OpenLDAP for authentication. Creating LDIF files from /etc/passwd and /etc/shadow using PADL's migrationtools is working fine. The only problem is, that many user passwords on the Solaris machine have been encrypted using Sun's md5 scheme which results in hashes beginning with the characters "$md5$". These hashes can be "imported" into our LDAP directory, but they cannot be used for authentication: Each attempt results in "access denied" on the client side and LDAP bind errors on the server side. Even when adding the user information to /etc/passwd and /etc/shadow on the Linux machine, there's no success. With CRYPT password hashes, everything works fine. Do you know any means to "convert" these Solaris-md5-hashed password strings into something we can use with OpenLDAP? I appreciate your helpful answers. Thanks in advance! Gruss/Regards, Christian Schmidt -- You have an ability to sense and know higher truth.

4 7

Syncrepl from OSX slapd to Centos5 slapd
by Markku Tavasti 12 Nov '10

12 Nov '10

Hi! We have OSX as primary ldap server (slapd 2.3.27). Schema is OSX tuned schema, with Apple provided extensions. I'm trying to set up backup-ldap to Centos5 server (slapd 2.3.43). I have copied schemas from OSX /etc/openldap/schema, and edited & commented out attributetype 'authAuthority' definition from apple.schema. OSX is running with configuration from cn=config, so how I can check if schema it uses is 100% same as in schema files? Here is my syncrepl config on client side: syncrepl rid=23 provider=ldap://xxxx.domain.com type=refreshOnly interval=00:00:10:00 retry="60 10 300 +" searchbase="dc=xxxx,dc=domain,dc=com" scope=sub schemachecking=off bindmethod=simple binddn="uid=replicator,cn=users,dc=xxxx,dc=domain,dc=com" credentials=secret Client-slapd starts ok, and replication gets only one entry: # xxxx, computers, xxxx.domain.com dn: cn=xxxx,cn=computers,dc=xxxx,dc=domain,dc=com To log on client side I get only these: Nov 11 05:31:46 xxxx slapd[13962]: do_syncrep2: rid 023 LDAP_RES_SEARCH_RESULT Nov 11 05:41:46 xxxx slapd[13962]: daemon: epoll: listen=7 active_threads=0 tvp =zero Nov 11 05:41:46 xxxx slapd[13962]: daemon: epoll: listen=8 active_threads=0 tvp =zero Any ideas what is problem? -- M. Tavasti / tavasti(a)tavasti.fi / +358-40-5078254

1 1

Trying to understand an error message
by Khaled Blah 12 Nov '10

12 Nov '10

Hello all, I have written an application which uses OpenLDAP and I keep receiving this error message: "sasl.c:75: ldap_sasl_bind: Assertion `( (ld)->ld_options.ldo_valid == 0x2 )' failed." The code at this position says the following: "assert( LDAP_VALID( ld ) );" My application creates LDAP structures (using ldap_init) and re-uses these structures whenever possible so that the least number of LDAP binds have to done. Is there anything I need to do after an LDAP operation has finished or maybe do I have to unbind at some point to make sure the LDAP structure remains in a valid state? I would be happy to receive any insight into this. Regards, Khaled

1 0

German Umlauts are converted and also not accepted
by Götz Reinicke - IT-Koordinator 11 Nov '10

11 Nov '10

Hallo, I'v searched for an answer but did not found one yet. I do have a openldap-2.3.43 server (centos 5.5.) in test and tried to add a ldif-file with my data using the apache directory studio (on mac os x). As my name contains a german umlaut I do get an error adding 'Götz Reinicke' for the gecko. Also for 'displayName', 'cn' and 'givenName' the 'ö' is automatically replaced by 'oe'. If I change the entry in the ldap by hand in the apache DS, the 'ö' is accepted accept for the geckos. An 'ü' in 'o' is manually accepted to. Any hints, explanations, suggestions? Thanks and best 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

3 3

olcDbURI error
by Jaap Winius 11 Nov '10

11 Nov '10

Hi folks, After applying some changes to a consumer server used for testing purposes, my attempts to run slapcat result in the following error: #################################### slapd-chain: first underlying database "olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config" cannot contain attribute "olcDbURI". config error processing olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config: slapcat: bad configuration file! #################################### (Debian squeeze, slapd v2.4.23-6) After having configure syncrepl on the same host, I used slapcat to compare its newly replicated database to the one on the provider. At that point it still worked and the databases proved to be identical. I then proceeded to configure chaining and a referral. The above slapcat error appeared after I made the following changes (which applied successfully): ########################################################################### # 1. dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcUpdateref olcUpdateref: ldap://ldaps.example.com # 2. dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: {1}back_ldap # 3. dn: olcOverlay={0}chain,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain olcChainReturnError: TRUE # 4. dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: ldap://ldaps.example.com olcDbRebindAsUser: TRUE olcDbIDAssertBind: bindmethod=simple binddn="cn=ldaps2,dc=example,dc=com" credentials=bilineatus mode=self ########################################################################### Afterwards, slapd could no longer be restarted either, with the same error showing up in the syslog. I am aware that this is a known bug: http://www.openldap.org/its/index.cgi/Software%20Bugs?id=6540;selectid=6540 According to the report, a patch was made available on April the 29th, but I'm not sure if it actually fixed anything. At any rate, my Debian slapd version is dated from the 23rd of September and still has this problem. However, Followup 17 (31 July) in the bug report refers to a "simple fix". Unfortunately, I haven't yet been able to find what that's supposed to be. This seems to me to be a serious bug, but for the time being I'd be happy with simple workaround. Can anyone help? Thanks, Jaap

2 3

Asynchronicity
by William Ahern 11 Nov '10

11 Nov '10

Excepting DNS, is the latest release of OpenLDAP fully asynchronous-capable, even with TLS? Perusing the source code I can't find any obvious places other than DNS where things might block, but it's harder to prove the negative. I remember many years ago this wasn't the case, and I had to thread the connect phase, but the ChangeLog suggests that things have changed considerably.

3 5

number of contextcsn entries per database
by PJunod＠mediageneral.com 11 Nov '10

11 Nov '10

I have setup two ldap servers for authentication and access control in a multi-master configuration. I am concerned about the number of contextcsn entries that are supposed to be present in each database. Right now there are two servers participating in the multi-master configuration. From my understanding, there should be one contextCSN entry per database per host. My cn=config database has two contextCSN entries as I would expect. One for each syncrepl rid configured. My bdb database only has one contextCSN entry though, with an rid of just "000". (my rid's are 001, 002, 101, and 102) Replication seems to work fine on both databases. I can write to either one and the changes are replicated over immediately. I am just curious about this discrepancy in the number of contextCSN entries. Could someone confirm the number of contextCSN entries per database and if it should match the number of hosts participating in the multi-master replication? Here are some relevant settings for the replication: dn: cn=config olcServerID: 1 ldap://<server1> olcServerID: 2 ldap://<server2> ####################### # module{0}, config dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib64/openldap2.4 olcModuleLoad: {0}syncprov.la ####################### # {0}config, config dn: olcDatabase={0}config,cn=config olcSyncrepl: {0}rid=001 provider=ldap://<server1> binddn="cn=Ma nager,cn=config" bindmethod=simple credentials=<password> searchbase="cn=config " type=refreshAndPersist retry="5 500 5 +" timeout=1 starttls=yes olcSyncrepl: {1}rid=002 provider=ldap://<server2> binddn="cn=Ma nager,cn=config" bindmethod=simple credentials=<password> searchbase="cn=config " type=refreshAndPersist retry="5 500 5 +" timeout=1 starttls=yes olcMirrorMode: TRUE ####################### # {0}syncprov, {0}config, config dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov ####################### # {1}bdb, config dn: olcDatabase={1}bdb,cn=config olcSyncrepl: {0}rid=101 provider=ldap://<server1> binddn="cn=Ma nager,dc=mgcorp,dc=net" bindmethod=simple credentials=<password> searchbase="dc =mgcorp,dc=net" type=refreshAndPersist interval=00:00:00:10 retry="5 500 5 +" timeout=1 starttls=yes olcSyncrepl: {1}rid=102 provider=ldap://<server2> binddn="cn=Ma nager,dc=mgcorp,dc=net" bindmethod=simple credentials=<password> searchbase="dc =mgcorp,dc=net" type=refreshAndPersist interval=00:00:00:10 retry="5 500 5 +" timeout=1 starttls=yes olcMirrorMode: TRUE ############################## Here are the results of searches for contextCSN in cn=config and dc=mgcorp,dc=net: ldapsearch -x -W -s base -D "cn=Manager,cn=config" -h "<server2>" -b "cn=config" contextCSN contextCSN: 20101110214932.998233Z#000000#000#000000 contextCSN: 20101028121213.444193Z#000000#001#000000 ldapsearch -x -W -s base -D "cn=Manager,dc=mgcorp,dc=net" -h "<server2>" -b "dc=mgcorp,dc=net" contextCSN contextCSN: 20101110213409.736943Z#000000#000#000000

2 1

Attributes for filtering OS logins
by Anton Chu 11 Nov '10

11 Nov '10

I have a scenario where I want to setup two LDAP groups where one group can access a file on the server while the other one cannot after they login. Can some PAM tweaks make this happen if not on the ldap side?

3 3

Re: ldapsearch performance degradation
by Tim Dyce 11 Nov '10

11 Nov '10

Hi Dieter, Thanks for the tips on tuning, sadly the problem is still haunting us :( Andrey Kiryanov at CERN has been doing a lot of work on this performance degradation problem as well. He has tried BDB 4.8.30 and OpenLDAP 2.4.23 but the problem is still apparent. The basic test we are running (sent earlier) creates 100 ou entries in the root, each with 250 child ou entries, then deletes 20-35% of these and re-adds them. For each deletion cycle the ldapsearch performance degrades, taking longer to complete the search each time. The performance is consistent, across restarts of slapd, and tied to the current state of the database. I have tried rsyncing out the database, and returning it later, and the performance is consistent with the number of deletion cycles the database has undergone. The only clue I have is that when dumping the databases which db_dump it's clear that the ordering of the database becomes increasingly less aligned with the order of the output data when doing a full tree search as we are. Which suggests that the database is writing frequently accessed entires too often instead of holding them in cache? I have run cachegrind against the server at 2, 20 and 1000 deletion iterations and the results are very different - http://www.ph.unimelb.edu.au/~tjdyce/callgrind.tar.gz The number of fetches grows massively over time. Anything you guys can suggest would be much appreciated, it's started to affect quite a number of our grid sites. Cheers, Tim > On 04/11/10 02:56, Dieter Kluenter wrote: >>> Hi Dieter, >>> >>> I've done some more testing with openldap 2.3 and 2.4, on Redhat and >>> Ubuntu. >>> I even went as far as placing the BDB database directory in a ramdisk. >>> But the performance still seems to degrade over time as data is added >>> then deleted repeatedly from the ldap server. >>> >>> It looks like the BDB database starts to fragment or lose structure >>> over time? >>> I've tried a few DB options that seem to have some impact. >>> >>> Any ideas on what I can do from here? >> Quite frankly, I have no clue, all i can do is guessing. First let's >> define the problem: you have measured the presentation of search >> Results the client side, and you observered an increase of time >> required to present the results. >> Mostlikely it is either a caching problem, a disk problem or a network >> problem. >> As far as openldap related, there are four caches to watch: >> 1. the bdb/hdb database (DB_CONFIG, cachesize) >> 2. the DN cache (dncachesize) >> 2. the cache of searched and indexed attribute types (idlcachesize) >> 3. the frontside cache of search results (cachesize) >> >> please check slapd.conf whether appropriate sizes are configured, see >> man slapd-bdb(5) and slapd.conf(5) for more information. >> >> But I must admit, a misconfiguration of any of this caches would not >> lead to such a degrading in presenting search results. >> >> An other approach would be to check the caching behaviour of clients, >> to check the network cache and the disk cache. >> >> -Dieter >> > -- ---------- Tim Dyce Research Computing EPP Group The School of Physics The University of Melbourne +61 3 8344 5462 +61 431 485 166

2 7

LDAPCon 2011?
by xsun 10 Nov '10

10 Nov '10

Hi there, There is something planned to 2011 about an LDAP Conference? I couldn't attend at 2009 and I think is too late for the conference on this year. Thanks, Matheus Morais

2 2

pamL-dap configuration guide
by Tim Dunphy 10 Nov '10

10 Nov '10

Hey List, I was just wondering if anyone happened to know of a good guide to use for configuring centos clients to authenticate pam modules (such as su, sudoers, ssh, system authentication and the like) against openLDAP? I am running a FreeBSD openLDAP server, but I believe that shouldn't affect the clients ability to log in via pam/ldap. At the moment I am googling this to not much avail! Thanks! -- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 Share and enjoy!!

3 3

tls
by Christian Bösch 10 Nov '10

10 Nov '10

Hi Can someone tell me if it's possible to require strong encryption like TLS except from one IP address? /chris

3 5

uniqueMember attribute is not suffixmassaged if attribute is not mapped and changed
by Arvo Jari-Pekka 09 Nov '10

09 Nov '10

Hi. My configuration is like this: --------- database meta suffix "ou=a,dc=c,dc=b" uri "ldap://host:port/ou=a,dc=c,dc=b" suffixmassage "ou=a,dc=c,dc=b" "dc=a,dc=b" ... --------- This works fine in everything else but the uniqueMembers of groupOfUniqueNames gets not rewritten (they are still in dc=a,dc=b domain). If I however add a mapping --------- map objectClass groupOfNames groupOfUniqueNames map attribute member uniqueMember --------- then the "member" attributes are correctly rewritten. The problem of course is that I do not want to change the objectclass. Mapping the attribute to itself does not help either. So --------- map objectClass groupOfUniqueNames * map attribute uniqueMember * --------- does not have any effect. I must have missed something crucial on the documentation. Can someone please tell me what it is and how can I get uniqueMembers rewritten without changing the objectclass. OpenLDAP version is 2.4.11 for both the real and the meta server. BR, Jari-Pekka Arvo

3 2

Is ldap_bind() mandatory before each ldap_search() call?
by Shankar Anand R 09 Nov '10

09 Nov '10

Hi all, I see that most LDAP utilities (openldap included) do a ldap_bind() before every ldap_search(). Is this mandatory? If LDAP descriptor (ld) is valid and can be used for multiple ldap_search() calls, when does it become invalid? Is it time based, say ld becomes invalid after 10 minutes? I have an application which needs to search the LDAP server for some specific attributes of users. The user name is taken as input from the command line. Is it necessary to do a ldap_bind() before each ldap_search() call? Doesn't this make it costly? Can I do ldap_bind() once and call ldap_search() many times? When does my "bind" become invalid? Can my application do this: #1 - bind to a LDAP server during initialization #2- then do an ldap_search() whenever required #3- then invalidate the ld after 10 minutes #4- do a ldap_bind() again and repeat from #2? Can someone kindly clarify? Thanks, Shankar

3 7

pam services under LDAP
by bluethundr 09 Nov '10

09 Nov '10

Hello List I am attempting to setup various pam modules to consult our new LDAP services in order to do what it needs to do. My LDAP server is FreeBSD but the clients are CentOS... I have setup my /etc/pam.d sudo file on the client (for example) this way in the attempt to accomplish this via LDAP: [root@VIRCENT03:~]#cat /etc/pam.d/sudo #%PAM-1.0 auth include system-auth auth required pam_ldap.so account include system-auth account required pam_ldap.so password include system-auth password required pam_ldap.so session optional pam_keyinit.so revoke session required pam_limits.so session required pam_ldap.so but even tho the user is part of the %wheel group under LDAP it is unable to sudo to any other account (including root). If I try to sudo this is what happens: [bluethundr@VIRCENT03:~]#sudo bash [sudo] password for bluethundr: bluethundr is not in the sudoers file. This incident will be reported. It would appear that sudo support for ldap is compiled in: [root@VIRCENT03:~]#ldd $(which sudo)| grep -i ldap libldap-2.3.so.0 => /usr/lib/libldap-2.3.so.0 (0x00552000) This is how I setup my ldap.conf file [root@VIRCENT03:~]#cat /etc/openldap/ldap.conf # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=example, dc=com #URI ldap://ldap.example.com ldap://ldap-master.example.com:666 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never URI ldap://ldap.acadaca.net/ BASE dc=acadaca,dc=net TLS_CACERTDIR /etc/openldap/cacerts sudoers_base ou=sudoers,ou=Services,dc=acadaca,dc=net In my openldap logs on the LDAP server there appears to be no activity when I sudo. however in the secure logs on the client I do.. Nov 8 16:05:34 VIRCENT03 su: pam_unix(su-l:session): session opened for user root by bluethundr(uid=500) Nov 8 16:05:37 VIRCENT03 su: pam_unix(su-l:session): session opened for user bluethundr by bluethundr(uid=0) Nov 8 16:05:44 VIRCENT03 sudo: bluethundr : user NOT in sudoers ; TTY=pts/5 ; PWD=/home/bluethundr ; USER=root ; COMMAND=/bin/bash Conversely when I sudo via LDAP on my FreeBSD ldap server this is what I see... Nov 8 19:44:25 LBSD2 sudo: bluethundr : TTY=pts/11 ; PWD=/usr/home/bluethundr ; USER=root ; COMMAND=/bin/bash Nov 8 19:44:51 LBSD2 sudo: bluethundr : TTY=pts/10 ; PWD=/usr/home/bluethundr ; USER=root ; COMMAND=/bin/bash Works there! I do see other events in secure.log that appear to be pam successes however. am i interpreting this correctly that at least part of the system is communicating with pam on the ldap server? thanks -- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 Share and enjoy!!

6 7

Openladp is very very slow with log activated
by Couturier Jean-Louis 09 Nov '10

09 Nov '10

2 2

Re: unable to perform authenticated binds
by Tim Dunphy 08 Nov '10

08 Nov '10

Hey List, I found the cause of the failure to import ldif entries with references to the suDoers object class: include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/misc.schema inlcude /etc/openldap/schema/sudoers.schema include /etc/openldap/schema/openldap.schema If you look closely there is a type-o for the /etc/openldap/sudoers.schema include directive. It's spelled 'inlcude'. Sorry about that and sorry for all the grief! Fixing that and restarting ldap I was able to import the ldifs I wanted. Thanks again for your help!

1 0

reordering email aliases ?
by Frank Bonnet 08 Nov '10

08 Nov '10

Hello I'm facing a cosmetic problem with email aliases. Some users has aliases for their email adresses some has not. For example a professor named Jean Dupont has two valid email adresses : dupontj(a)domain.tld ( which is unixlogin(a)domain.tld ) j.dupont(a)domain.tld ( which is the alias that point to duponj(a)domain.tld ) Students have only one email adress of the form : unixlogin(a)domain.tld In many applications we use LDAP to fetch the user's email address and other data. The problem is sometime we get unixlogin(a)domain.tld and sometime we get emailalias(a)domain.tld I would like to do the following : if a user has an alias of the form emailalias(a)domain.tld then display it first Is it possible to reorder my LDAP database to do so ? Thanks a lot !

3 4

Abou 'make test'
by su heng 07 Nov '10

07 Nov '10

Hi All, I encountered an error when I was installing openLDAP. I mean 'make test' It gave me a message at the end of the output message: ... ... No race errors found after 10 iterations Found 2 errors >>>>>> Exiting with a false success status for now >>>>> ./scripts/test058-syncrepl-asymmetric completed OK for hdb. make[2]: Leaving directory `/home/suheng/Downloads/openldap-2.4.23/tests' make[1]: Leaving directory `/home/suheng/Downloads/openldap-2.4.23/tests' He said I had 2 errors encountered, however, I couldn't locate where the error is. Although I can install it, I worried about if it works fine. So, How can I locate the error location when I do 'make test'? Thanks & Best Regards, Su Heng

2 2

Configuring the chain overlay with cn=config
by Jaap Winius 07 Nov '10

07 Nov '10

Hi folks, My old chain configuration in slapd.conf works fine and looks like this: ################################################# moduleload back_ldap overlay chain chain-uri ldap://ldaps.example.com:389/ chain-rebind-as-user TRUE chain-idassert-bind bindmethod=simple binddn="cn=ldaps2,dc=example,dc=com" credentials=bilineatus mode=self chain-return-error TRUE ################################################# (Debian lenny, slapd v2.4.11-1) Some research has led me to believe that the proper cn=config equivalent in LDIF format would start like this: ################################################# dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: {1}back_ldap dn: olcOverlay={0}chain,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain ################################################# (Debian squeeze, slapd v2.4.23-6) Does that look correct? If so, could someone please explain how to translate the other chain overlay directives I've used as well? I've tried translating the old configuration with slaptest, but it seems to ignore the existing chain configuration completely -- not even the back_ldap module gets loaded as a result. I've also tried searching the schema for them with this command: ~# ldapsearch -LLQY EXTERNAL -H ldapi:/// -b cn=schema,cn=config \ -s base | grep -A 2 -i chain However, the list of candidates that I've found with it seems incomplete: slapd.conf chain overlay directive => cn=config equivalent attribute ---------------------------------------------------------------------- chain-cache-uri => olcChainCacheURI chain-chaining => olcChainingBehavior chain-idassert-bind => ?? chain-max-depth => olcChainMaxReferralDepth chain-rebind-as-user => ?? chain-return-error => olcChainReturnError chain-uri => ?? ?? => olcChainConfig ?? => olcChainDatabase Can anyone fill in what's missing? Thanks, Jaap

1 1

Syncprov checkpoint and sessionlog with cn=config
by Jaap Winius 06 Nov '10

06 Nov '10

Hi folks, When configuring a sync provider with cn=config, it was not too difficult to figure out how to load the syncprov module and create the entry for its overlay, but it is unclear how to configure two associated statements that appear as follows when using slapd.conf: syncprov-checkpoint 100 10 syncprov-sessionlog 100 Can anyone say how this might be accomplished? Thanks, Jaap

4 8

Syncrepl filtering
by Bram Cymet 06 Nov '10

06 Nov '10

Hi, I would like to control what gets replicated to my ldap slaves. How would I specify what I don't want to be replicated? Is this even possible or do I have to create a filter that finds everything that I want to send down? Thanks, -- Bram Cymet Software Developer Canadian Bank Note Co. Ltd. Cell: 613-608-9752

2 2

Accesslog overlay to get IP from user connection
by Alberto Frontera 06 Nov '10

06 Nov '10

Hello this is my scenario: - Centos 5.2 - ldap 2.420 - Mysql 5.07 Ldap is used to authenticate users from Ubuntu systems. We want to storage some info from the connections: - date - IP I can see this info on ldap logs, but i want to save this info on a ldap DB (mysql backend if possible). Actually i have configured accesslog overlay, but i think this info is not registered or i can not see it. :p The question is: is access overlay the tool to register this info? (i think the answer is no) ... and if it is not, how can i do this? I need some advice on this. Thx

2 1

Re: unable to perform authenticated binds
by Tim Dunphy 05 Nov '10

05 Nov '10

Hey guys, And sorry to Quanah for the type-o. ;) At any rate thanks for the ldapsearch. It did return a ton of information on the attributes defined in my schema: [root@ldap2 ~]# ldapsearch -x -h ldap.acadaca.net -s base -b "cn=subschema" + | more # extended LDIF # # LDAPv3 # base <cn=subschema> with scope baseObject # filter: (objectclass=*) # requesting: + # # Subschema dn: cn=Subschema structuralObjectClass: subentry createTimestamp: 20101105183240Z modifyTimestamp: 20101105183240Z ldapSyntaxes: ( 1.3.6.1.1.16.1 DESC 'UUID' ) ldapSyntaxes: ( 1.3.6.1.1.1.0.1 DESC 'RFC2307 Boot Parameter' ) ldapSyntaxes: ( 1.3.6.1.1.1.0.0 DESC 'RFC2307 NIS Netgroup Triple' ) ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' ) ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' ) ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.49 DESC 'Supported Algorithm' X-BIN ARY-TRANSFER-REQUIRED 'TRUE' X-NOT-HUMAN-READABLE 'TRUE' ) ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.45 DESC 'SubtreeSpecification' ) ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' ) However, nothing shows up under the search regarding sudoRole. [root@ldap ldif]# ldapsearch -x -h ldap.acadaca.net -s base -b "cn=subschema" | grep sudoRole [root@ldap ldif]# This is curious to me as the sudoers.schema file (which has sudoRole defined) is most definitely entered correctly into my slapd.conf file. # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/misc.schema inlcude /etc/openldap/schema/sudoers.schema include /etc/openldap/schema/openldap.schema I checked the modes and permissions on sudoers.schema: [root@ldap ~]# ls -l /etc/openldap/schema/sudoers.schema -r--r--r-- 1 ldap ldap 1655 Nov 4 18:38 /etc/openldap/schema/sudoers.schema But when I try to add this LDIF entry to my directory: # defaults, sudoers, Services, acadaca.net dn: cn=defaults,ou=sudoers,ou=Services,dc=acadaca,dc=net objectClass: top objectClass: sudoRole cn: defaults description: Default sudoOption's go here I am still getting this error: [root@ldap ldif]# ldapadd -h ldap.acadaca.net -a -W -x -D "cn=Manager,dc=acadaca,dc=net" -f /home/tim/txt/ldif/acadaca2.ldif Enter LDAP Password: adding new entry "cn=defaults,ou=sudoers,ou=Services,dc=acadaca,dc=net" ldapadd: Invalid syntax (21) additional info: objectClass: value #1 invalid per syntax And these errors in the logs: Nov 5 15:00:33 ldap slapd[4429]: daemon: activity on 1 descriptor Nov 5 15:00:33 ldap slapd[4429]: daemon: activity on: Nov 5 15:00:33 ldap slapd[4429]: Nov 5 15:00:33 ldap slapd[4429]: slap_listener_activate(7): Nov 5 15:00:33 ldap slapd[4429]: daemon: epoll: listen=7 busy Nov 5 15:00:33 ldap slapd[4429]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Nov 5 15:00:33 ldap slapd[4429]: >>> slap_listener(ldap:///) Nov 5 15:00:33 ldap slapd[4429]: daemon: listen=7, new connection on 12 Nov 5 15:00:33 ldap slapd[4429]: daemon: added 12r (active) listener=(nil) Nov 5 15:00:33 ldap slapd[4429]: conn=5 fd=12 ACCEPT from IP=75.101.129.124:55873 (IP=0.0.0.0:389) Nov 5 15:00:33 ldap slapd[4429]: daemon: activity on 2 descriptors Nov 5 15:00:33 ldap slapd[4429]: daemon: activity on: Nov 5 15:00:33 ldap slapd[4429]: 12r Nov 5 15:00:33 ldap slapd[4429]: Nov 5 15:00:33 ldap slapd[4429]: daemon: read active on 12 Nov 5 15:00:33 ldap slapd[4429]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Nov 5 15:00:33 ldap slapd[4429]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Nov 5 15:00:33 ldap slapd[4429]: connection_get(12) Nov 5 15:00:33 ldap slapd[4429]: connection_get(12): got connid=5 Nov 5 15:00:33 ldap slapd[4429]: connection_read(12): checking for input on id=5 Nov 5 15:00:33 ldap slapd[4429]: do_bind Nov 5 15:00:33 ldap slapd[4429]: >>> dnPrettyNormal: <cn=Manager,dc=acadaca,dc=net> Nov 5 15:00:33 ldap slapd[4429]: <<< dnPrettyNormal: <cn=Manager,dc=acadaca,dc=net>, <cn=manager,dc=acadaca,dc=net> Nov 5 15:00:33 ldap slapd[4429]: do_bind: version=3 dn="cn=Manager,dc=acadaca,dc=net" method=128 Nov 5 15:00:33 ldap slapd[4429]: conn=5 op=0 BIND dn="cn=Manager,dc=acadaca,dc=net" method=128 Nov 5 15:00:33 ldap slapd[4429]: ==> bdb_bind: dn: cn=Manager,dc=acadaca,dc=net Nov 5 15:00:33 ldap slapd[4429]: conn=5 op=0 BIND dn="cn=Manager,dc=acadaca,dc=net" mech=SIMPLE ssf=0 Nov 5 15:00:33 ldap slapd[4429]: do_bind: v3 bind: "cn=Manager,dc=acadaca,dc=net" to "cn=Manager,dc=acadaca,dc=net" Nov 5 15:00:33 ldap slapd[4429]: send_ldap_result: conn=5 op=0 p=3 Nov 5 15:00:33 ldap slapd[4429]: send_ldap_result: err=0 matched="" text="" Nov 5 15:00:33 ldap slapd[4429]: send_ldap_response: msgid=1 tag=97 err=0 Nov 5 15:00:33 ldap slapd[4429]: conn=5 op=0 RESULT tag=97 err=0 text= Nov 5 15:00:33 ldap slapd[4429]: daemon: activity on 1 descriptor Nov 5 15:00:33 ldap slapd[4429]: daemon: activity on: Nov 5 15:00:33 ldap slapd[4429]: Nov 5 15:00:33 ldap slapd[4429]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Nov 5 15:00:33 ldap slapd[4429]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Nov 5 15:00:33 ldap slapd[4429]: daemon: activity on 1 descriptor Nov 5 15:00:33 ldap slapd[4429]: daemon: activity on: Nov 5 15:00:33 ldap slapd[4429]: 12r Nov 5 15:00:33 ldap slapd[4429]: Nov 5 15:00:33 ldap slapd[4429]: daemon: read active on 12 Nov 5 15:00:33 ldap slapd[4429]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Nov 5 15:00:33 ldap slapd[4429]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Nov 5 15:00:33 ldap slapd[4429]: connection_get(12) Nov 5 15:00:33 ldap slapd[4429]: connection_get(12): got connid=5 Nov 5 15:00:33 ldap slapd[4429]: connection_read(12): checking for input on id=5 Nov 5 15:00:33 ldap slapd[4429]: do_add Nov 5 15:00:33 ldap slapd[4429]: >>> dnPrettyNormal: <cn=defaults,ou=sudoers,ou=Services,dc=acadaca,dc=net> Nov 5 15:00:33 ldap slapd[4429]: <<< dnPrettyNormal: <cn=defaults,ou=sudoers,ou=Services,dc=acadaca,dc=net>, <cn=defaults,ou=sudoers,ou=services,dc=acadaca,dc=net> Nov 5 15:00:33 ldap slapd[4429]: do_add: dn (cn=defaults,ou=sudoers,ou=Services,dc=acadaca,dc=net) Nov 5 15:00:33 ldap slapd[4429]: conn=5 op=1 ADD dn="cn=defaults,ou=sudoers,ou=Services,dc=acadaca,dc=net" Nov 5 15:00:33 ldap slapd[4429]: send_ldap_result: conn=5 op=1 p=3 Nov 5 15:00:33 ldap slapd[4429]: send_ldap_result: err=21 matched="" text="objectClass: value #1 invalid per syntax" Nov 5 15:00:33 ldap slapd[4429]: send_ldap_response: msgid=2 tag=105 err=21 Nov 5 15:00:33 ldap slapd[4429]: conn=5 op=1 RESULT tag=105 err=21 text=objectClass: value #1 invalid per syntax Nov 5 15:00:33 ldap slapd[4429]: daemon: activity on 1 descriptor Nov 5 15:00:33 ldap slapd[4429]: daemon: activity on: Nov 5 15:00:33 ldap slapd[4429]: Nov 5 15:00:33 ldap slapd[4429]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Nov 5 15:00:33 ldap slapd[4429]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Nov 5 15:00:33 ldap slapd[4429]: daemon: activity on 1 descriptor Nov 5 15:00:33 ldap slapd[4429]: daemon: activity on: Nov 5 15:00:33 ldap slapd[4429]: 12r Nov 5 15:00:33 ldap slapd[4429]: Nov 5 15:00:33 ldap slapd[4429]: daemon: read active on 12 Nov 5 15:00:33 ldap slapd[4429]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Nov 5 15:00:33 ldap slapd[4429]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Nov 5 15:00:33 ldap slapd[4429]: connection_get(12) Nov 5 15:00:33 ldap slapd[4429]: connection_get(12): got connid=5 Nov 5 15:00:33 ldap slapd[4429]: connection_read(12): checking for input on id=5 Nov 5 15:00:33 ldap slapd[4429]: ber_get_next on fd 12 failed errno=0 (Success) Nov 5 15:00:33 ldap slapd[4429]: connection_read(12): input error=-2 id=5, closing. Nov 5 15:00:33 ldap slapd[4429]: connection_closing: readying conn=5 sd=12 for close Nov 5 15:00:33 ldap slapd[4429]: connection_close: deferring conn=5 sd=-1 Nov 5 15:00:33 ldap slapd[4429]: do_unbind Nov 5 15:00:33 ldap slapd[4429]: conn=5 op=2 UNBIND Nov 5 15:00:33 ldap slapd[4429]: connection_resched: attempting closing conn=5 sd=12 Nov 5 15:00:33 ldap slapd[4429]: connection_close: conn=5 sd=-1 Nov 5 15:00:33 ldap slapd[4429]: daemon: removing 12 Nov 5 15:00:33 ldap slapd[4429]: conn=5 fd=12 closed Nov 5 15:00:33 ldap slapd[4429]: daemon: activity on 1 descriptor Nov 5 15:00:33 ldap slapd[4429]: daemon: activity on: Nov 5 15:00:33 ldap slapd[4429]: Nov 5 15:00:33 ldap slapd[4429]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Nov 5 15:00:33 ldap slapd[4429]: daemon: epoll: listen=8 active_threads=0 tvp=NULL And as mentioned this exact schema configuration is working fine under OpenLDAP 2.4 under FreeBSD and behaving as you saw under OpenLDAP 2.3 CentOS 5.4 And everything looks correct to me. Any further ideas on why this isn't working? Thanks! On Thu, Nov 4, 2010 at 6:03 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Thursday, November 04, 2010 5:47 PM -0400 Tim Dunphy > <bluethundr(a)gmail.com> wrote: > >> however when I do a search for sudoRole it doesn't seem to show up >> >> [root@ldap openldap]# ldapsearch -b '' -s base '(objectclass=*)' >> sudoRole -x -W -D "cn=Manager,dc=acadaca,dc=net" > > That is not a valid search of the cn=subschema entry. I would note you fail > to offer a -h or -H option, so who knows what LDAP server it is talking to. > > ldapsearch -x -h zre-ldap001 -s base -b "cn=subschema" + > > for example, searches the subschema entry on my system. > > > And my name has only one "n" in it. > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > -- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 Share and enjoy!!

2 1

Re: Issue with OpenLDAP shared libraries complie on AIX 6.1 using IBM xL Compiler
by Peter Lambrechtsen 05 Nov '10

05 Nov '10

On Wed, Nov 3, 2010 at 4:28 AM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > Examine config.log to see why it failed. > As per what I get in the config.log configure:8474: checking if cc_r -qlanglvl=extc89 static flag works configure:8502: result: yes configure:8570: checking for cc_r -qlanglvl=extc89 option to produce PIC configure:8774: result: configure:8841: checking if cc_r -qlanglvl=extc89 supports -c -o file.o configure:8862: cc_r -qlanglvl=extc89 -c -I/opt/openldap/include -I/opt/openldap/include -o out/conftest2.o conftest.c >&5 configure:8866: $? = 0 configure:8888: result: yes configure:8914: checking whether the cc_r -qlanglvl=extc89 linker (/usr/ccs/bin/ld) supports shared libraries configure:9790: result: no --- Any way to get a more verbose output from what it's trying to do?? configure:9861: checking dynamic linker characteristics configure:10415: result: no configure:10419: checking how to hardcode library paths into programs configure:10444: result: unsupported configure:10458: checking whether stripping libraries is possible configure:10479: result: no configure:10586: checking for shl_load configure:10642: cc_r -qlanglvl=extc89 -o conftest -I/opt/openldap/include -I/opt/openldap/include -L/opt/openldap/lib conftest.c >&5 ld: 0711-317 ERROR: Undefined symbol: .shl_load -- I think this is the prolbem, shl_load, looks like I may need another include or figure out why it's complaining. ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. configure:10648: $? = 8 configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "" | #define PACKAGE_TARNAME "" | #define PACKAGE_VERSION "" | #define PACKAGE_STRING "" | #define PACKAGE_BUGREPORT "" | #define OPENLDAP_PACKAGE "OpenLDAP" | #define OPENLDAP_VERSION "2.4.23" | #define LDAP_VENDOR_VERSION 20423 | #define LDAP_VENDOR_VERSION_MAJOR 2 | #define LDAP_VENDOR_VERSION_MINOR 4 | #define LDAP_VENDOR_VERSION_PATCH 23 | #define HAVE_MKVERSION 1 | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_DLFCN_H 1 | /* end confdefs.h. */ | /* Define shl_load to an innocuous variant, in case <limits.h> declares shl_load. | For example, HP-UX 11i <limits.h> declares gettimeofday. */ | #define shl_load innocuous_shl_load | | /* System header to define __stub macros and hopefully few prototypes, | which can conflict with char shl_load (); below. | Prefer <limits.h> to <assert.h> if __STDC__ is defined, since | <limits.h> exists even on freestanding compilers. */ | | #ifdef __STDC__ | # include <limits.h> | #else | # include <assert.h> | #endif | | #undef shl_load | | /* Override any GCC internal prototype to avoid an error. | Use char because int might match the return type of a GCC | builtin and then its argument prototype would still apply. */ | #ifdef __cplusplus | extern "C" | #endif | char shl_load (); | /* The GNU C library defines this for functions which it implements | to always fail with ENOSYS. Some functions are actually named | something starting with __ and the normal name is an alias. */ | #if defined __stub_shl_load || defined __stub___shl_load | choke me | #endif | | int | main () | { | return shl_load (); | ; | return 0; | } configure:10665: result: no configure:10670: checking for shl_load in -ldld configure:10705: cc_r -qlanglvl=extc89 -o conftest -I/opt/openldap/include -I/opt/openldap/include -L/opt/openldap/lib conftest.c -ldld >&5 ld: 0706-006 Cannot find or open library file: -l dld ld:open(): No such file or directory configure:10711: $? = 255 configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "" | #define PACKAGE_TARNAME "" | #define PACKAGE_VERSION "" | #define PACKAGE_STRING "" | #define PACKAGE_BUGREPORT "" | #define OPENLDAP_PACKAGE "OpenLDAP" | #define OPENLDAP_VERSION "2.4.23" | #define LDAP_VENDOR_VERSION 20423 | #define LDAP_VENDOR_VERSION_MAJOR 2 | #define LDAP_VENDOR_VERSION_MINOR 4 | #define LDAP_VENDOR_VERSION_PATCH 23 | #define HAVE_MKVERSION 1 | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_DLFCN_H 1 | /* end confdefs.h. */ | | /* Override any GCC internal prototype to avoid an error. | Use char because int might match the return type of a GCC | builtin and then its argument prototype would still apply. */ | #ifdef __cplusplus | extern "C" | #endif | char shl_load (); | int | main () | { | return shl_load (); | ; | return 0; | } configure:10729: result: no configure:10734: checking for dlopen configure:10790: cc_r -qlanglvl=extc89 -o conftest -I/opt/openldap/include -I/opt/openldap/include -L/opt/openldap/lib conftest.c >&5 configure:10796: $? = 0 configure:10813: result: yes configure:11046: checking whether a program can dlopen itself configure:11118: cc_r -qlanglvl=extc89 -o conftest -I/opt/openldap/include -I/opt/openldap/include -DHAVE_DLFCN_H -L/opt/openldap/lib conftest.c >&5 configure:11121: $? = 0 configure:11139: result: no configure:11260: checking if libtool supports shared libraries configure:11262: result: no configure:11265: checking whether to build shared libraries configure:11286: result: no configure:11289: checking whether to build static libraries configure:11293: result: yes Also found something similar for Samba: http://samba.2283325.n4.nabble.com/Failing-to-make-Samba-3-5-4-on-AIX-5-3-t… So going to do more digging, or suggestions are welcome ;)

3 4

loglevel question / problem
by Aaron Bennett 05 Nov '10

05 Nov '10

Hi, I have two reasonably identical Ubuntu Server 10.04 boxes running OpenLdap 2.4.21. ( I say reasonable identical because one is a master and the other pulls via syncrepl ). The master box is sending copious amount of query log info to syslog -- it looks like it's logging every search and connection. The other box looks like it's only logging syncrepl information to the debug facility. What I can't figure out is how this is happening. When I started, neither machine had olcLogLevel entries in cn=config.ldif ; I have since added olcLogLevel: none (no effect) and even olcLogLevel: 0 to the master, restarting slapd each time. I've verified that it's not getting any "-d" switch on startup, both by looking at the SLAPD_OPTIONS in /etc/default/slapd and with ps -ax (which shows /usr/sbin/slapd -h ldaps:/// ldap:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d). Here's sample syslog output from the master: Nov 5 07:48:06 nyx slapd[5100]: conn=1008 op=1357 SRCH attr=mailRoutingAddress Nov 5 07:48:06 nyx slapd[5100]: conn=1008 op=1357 SEARCH RESULT tag=101 err=0 nentries=0 text= Nov 5 07:48:06 nyx slapd[5100]: conn=1008 op=1358 SRCH base="dc=clarku,dc=edu" scope=2 deref=0 filter="(|(mail=@clarku.edu)(mailAlternateAddress=@clarku.edu))" Nov 5 07:48:06 nyx slapd[5100]: conn=1008 op=1358 SRCH attr=mailRoutingAddress Nov 5 07:48:06 nyx slapd[5100]: conn=1008 op=1358 SEARCH RESULT tag=101 err=0 nentries=1 text= Nov 5 07:48:06 nyx slapd[5100]: conn=1007 op=10647 SRCH base="dc=clarku,dc=edu" scope=2 deref=0 filter="(|(mail=clarku.edu)(mailAlternateAddress=clarku.edu))" And here's sample from the slave: Nov 5 07:54:21 erebus slapd[7913]: syncrepl_entry: rid=001 be_modify uid=dgoldman,ou=Users,dc=clarku,dc=edu (0) Nov 5 07:54:21 erebus slapd[7913]: slap_queue_csn: queing 0x7f730550e7e0 20101105115421.300608Z#000000#000#000000 Nov 5 07:54:21 erebus slapd[7913]: slap_graduate_commit_csn: removing 0x7f730407f560 20101105115421.300608Z#000000#000#000000 Nov 5 07:54:21 erebus slapd[7913]: do_syncrep2: rid=001 cookie=rid=001,csn=20101105115421.483388Z#000000#000#000000 Nov 5 07:54:21 erebus slapd[7913]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) Is there some other place that this information could be living? Thanks, Aaron Bennett Clark University ITS

1 0

openldap 2.4.2[13] socket close bug ?
by Arjan Filius 05 Nov '10

05 Nov '10

Hello openldap ml, while researching more or less regular xen/centos/openldap crash situation, i ran into a situation which i think is a (openldap) bug. Tested with self compiled/packed openldap 2.4.21 and 2.4.23 on centos 5.2 64 bits The most easy way to explain and test (for me) is: 1) Set threads to 2 in slapd.conf 2) Start a ldap search query which takes some time (say longer then a minute or so) ps: local or remote ldapsearch doesn't matter ps: i used ldapsearch and a "slowcat" to simulate 3) start a second ldap search querry as with 2) 4) Try to start a third ldapsearch query, which you may notice would connect (tcp backlog), but not yet handled by slapd. Normally when the first ldapsearch session would stop, the third session will be handled by slapd, which works just fine as expected, no need to test that now. >From now on you have some slightly different situations, which i will number 5a ....) 5a) while those first 2 sessions are still running, and session 3 is waiting, lets kill session 1 or 2, and here it happens: -slapd won't log the killed session, and the third session isn't going to handled. -The third session is going to be handled as soon as the second session finishes in a normal way. 5b) while those first 2 sessions are still running, and session 3 is waiting, kill all ldap search querries (press ^C within your ldapsearch for example) , and here it happens: -slapd won't log died sessions -new ldapsearch sessions are accepted by the backlog buffer, but are never going to be accepted by the slapd process. -when stopping slapd it complains about closing already died sessions/socket. So it looks like killed sessions, are not quite handled correctly within slapd, and i noticed as soon there is one session which finishes in a normal way, it will also clear and free the killed sessions. The other way arond, when killing all sessions, you've a denial of service, and no session will ever be cleared. Please confirm or deny, feedback welcome. Regards, -- Arjan Filius iafilius(a)xs4all.nl

1 1

Re: unable to perform authenticated binds
by Tim Dunphy 04 Nov '10

04 Nov '10

hi quannah, well from the includes in slapd.conf it certainly would appear to have been installed include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/misc.schema inlcude /etc/openldap/schema/sudoers.schema include /etc/openldap/schema/openldap.schema however when I do a search for sudoRole it doesn't seem to show up [root@ldap openldap]# ldapsearch -b '' -s base '(objectclass=*)' sudoRole -x -W -D "cn=Manager,dc=acadaca,dc=net" Enter LDAP Password: # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: sudoRole # # dn: # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 On Thu, Nov 4, 2010 at 5:41 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > Are you certain the schema for sudoRole has really been added? Have you > browsed the subschema entry while the server is running to verify it is > present? > > --Quanah > > --On Thursday, November 04, 2010 5:25 PM -0400 Tim Dunphy > <bluethundr(a)gmail.com> wrote: > >> My bad Quannah in sending to your direct email .. and my apologies >> >> >> Well it seems that I am running version 2.3 on the CentOS box and >> version 2.4 on the FreeBSD box.. >> >> >> Here's the class definition for sudoRole >> >> objectclass ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top STRUCTURAL >> DESC 'Sudoer Entries' >> MUST ( cn ) >> MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ >> sudoRunAsUser $ sudoRunAsGroup $ sudoOption $ >> description ) >> ) >> >> >> could it be just that the older version is running under CentOS? any >> advice on how to get sudoRole working under openldap 2.3? > > Are you certain the schema for sudoRole has really been added? Have you > browsed the subschema entry while the server is running to verify it is > present? > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > -- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 Share and enjoy!!

2 1

Re: unable to perform authenticated binds
by Tim Dunphy 04 Nov '10

04 Nov '10

My bad Quannah in sending to your direct email .. and my apologies Well it seems that I am running version 2.3 on the CentOS box and version 2.4 on the FreeBSD box.. Here's the class definition for sudoRole objectclass ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top STRUCTURAL DESC 'Sudoer Entries' MUST ( cn ) MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoRunAsUser $ sudoRunAsGroup $ sudoOption $ description ) ) could it be just that the older version is running under CentOS? any advice on how to get sudoRole working under openldap 2.3? thanks On Thu, Nov 4, 2010 at 5:11 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Thursday, November 04, 2010 5:04 PM -0400 Tim Dunphy > <bluethundr(a)gmail.com> wrote: > >> hmm... so basically it's a syntax error in the LDIF? interesting.. >> that is the exact same entry I have under my working FreeBSD >> configuration... > > Keep your questions to the list please. My guess is that the FreeBSD > configuration is using an older version of OpenLDAP with schema checking > disabled? Since I don't know what the definition of that objectClass is, as > you haven't supplied it, I can't really say why that error is being > generated. > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > -- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 Share and enjoy!!

2 1

Re: unable to perform authenticated binds
by Quanah Gibson-Mount 04 Nov '10

04 Nov '10

--On Thursday, November 04, 2010 5:04 PM -0400 Tim Dunphy <bluethundr(a)gmail.com> wrote: > hmm... so basically it's a syntax error in the LDIF? interesting.. > that is the exact same entry I have under my working FreeBSD > configuration... Keep your questions to the list please. My guess is that the FreeBSD configuration is using an older version of OpenLDAP with schema checking disabled? Since I don't know what the definition of that objectClass is, as you haven't supplied it, I can't really say why that error is being generated. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: unable to perform authenticated binds
by Tim Dunphy 04 Nov '10

04 Nov '10

sorry for the oversight Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 busy Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: listen=7, new connection on 12 Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: added 12r (active) listener=(nil) Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 fd=12 ACCEPT from IP=10.203.49.140:51779 (IP=0.0.0.0:389) Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: 12r Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: read active on 12 Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 op=0 BIND dn="cn=Manager,dc=acadaca,dc=net" method=128 Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 op=0 BIND dn="cn=Manager,dc=acadaca,dc=net" mech=SIMPLE ssf=0 Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 op=0 RESULT tag=97 err=0 text= Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: 12r Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: read active on 12 Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 op=1 ADD dn="cn=defaults,ou=sudoers,ou=Services,dc=acadaca,dc=net" Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 op=1 RESULT tag=105 err=21 text=objectClass: value #1 invalid per syntax Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: 12r Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: read active on 12 Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 op=2 UNBIND Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: removing 12 Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 fd=12 closed Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL On Thu, Nov 4, 2010 at 3:49 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Thursday, November 04, 2010 3:37 PM -0400 Tim Dunphy > <bluethundr(a)gmail.com> wrote: > >> Thanks all.. I have read the man of ldif.... your advice has gotten me >> quite far both in my current implementation and in my overall >> understanding of LDAP which I am hoping grows with each passing day. >> >> In my attempt to build my current directory, I have taken a dump of >> my last successful implementation (which was created on FreeBSD 8.1) >> and substituted values for the dc=company and dc=com values with the >> correct ones for the current directory (attempting to implement under >> CentOS 5.4) and even tho the correct schemas are in place it is >> choking on this entry: >> >> # defaults, sudoers, Services, acadaca.com >> dn: cn=defaults,ou=sudoers,ou=Services,dc=acadaca,dc=net >> objectClass: top >> objectClass: sudoRole >> cn: defaults >> description: Default sudoOption's go here > > Since you fail to provide the error message you encountered, I see no way to > help you. > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > -- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 Share and enjoy!!

2 1

Re: unable to perform authenticated binds
by Tim Dunphy 04 Nov '10

04 Nov '10

sorry for the frustration all... removing the leading space in front of rootpw did the trick :) the directory is now populating, however I cannot understand why it is choking on this entry # pam_ldap, Services, acadaca.net dn: cn=pam_ldap,ou=Services,dc=acadaca,dc=net cn: pam_ldap objectClass: top objectClass: inetOrgPerson sn: PAM userPassword:: {SSHA}secret AFAIK I have ALL the scemas I need to import this entry yet ldapadd chokes [root@ldap openldap]# ldapadd -h ldap -x -D "cn=Manager,dc=acadaca,dc=net" -w secret -f /home/tim/acadaca2.ldif ldapadd: invalid format (line 6) entry: "cn=pam_ldap,ou=Services,dc=acadaca,dc=net" include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/misc.schema inlcude /etc/openldap/schema/sudoers.schema I am sorry to ask for help again.. this sucks On Wed, Nov 3, 2010 at 12:20 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Tuesday, November 02, 2010 7:59 PM -0700 Chris Jacobs > <Chris.Jacobs(a)apollogrp.edu> wrote: > >> If you're not calling me out via "thanks so much for the exceedingly >> useful insight" then feel free to skip the rest of this. > > I didn't think he was calling you out, myself. ;) Just noting that things > are documented, and people who don't take the time to read the official > project documentation (which happens a lot, unfortunately) don't deserve > sympathy on it. We get a lot of people who spend their time reading > documents from other sources such as Zytrax, which contain completely wrong > information, and then come here to talk about how bad the documentation is. > It gets frustrating. > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > -- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 Share and enjoy!!

4 6

pwdChangedTime: and system timestamp
by Michael Starling 04 Nov '10

04 Nov '10

When looking at the value of pwdChangedTime on my openldap system everything seems to be correct except for the hours/minutes/seconds fields. If I have a value of pwdChangedTime: 20101104165037Z in LDAP The date command shows Thu Nov 4 13:04:30 EDT 2010 How are these the same or relatively close? -Mike

2 2

Re: Error 18: Solaris 10 Native LDAP-Client
by Benjamin Griese 04 Nov '10

04 Nov '10

Correction: -w <passwd> or -w - instead of -W On Thu, Oct 28, 2010 at 15:02, Benjamin Griese <der.darude(a)gmail.com> wrote: > Hello Günther, > > sorry for my late reply, I hate sun cluster panics after patching > those beasts. :( > > Here is the content of solaris_profile: > > dn: cn=solaris_profile,ou=profile,dc=example,dc=de > objectClass: DUAConfigProfile > objectClass: top > cn: solaris_profile > authenticationMethod: simple > bindTimeLimit: 10 > credentialLevel: proxy > defaultSearchBase: dc=example,dc=de > defaultSearchScope: sub > defaultServerList: exampleldap01 exampleldap02 (syncrepl, configured > to mirrormode) > followReferrals: FALSE > profileTTL: 3600 > searchTimeLimit: 30 > serviceSearchDescriptor: sudoers:ou=SUDOers,dc=example,dc=de?sub > serviceSearchDescriptor: group:ou=groups,dc=example,dc=de?sub > serviceSearchDescriptor: passwd:ou=people,dc=example,dc=de?sub > > > Regarding to the sorting I found this in man ldapsearch: > > "-F sep > > Use sep as the field separator between attribute names > and values. If this option has been specified, the -L > option is ignored. > > > -S [-]attribute > > Specify an attribute for sorting the entries returned by > the search. The sort criteria is alphabetical on the > attribute's value or reverse alphabetical with the form > -attribute. You can give multiple -S options to refine > the sorting, For example: > > -S sn -S givenname > > By default, the entries are not sorted. Use the -x > option to perform server-side sorting." > > If I use -x for server side sorting, I get the complete list of > uid-Objects, but not sorted in any obvious way: > # ldapsearch -v -x -b dc=example,dc=de -h exampleldap01 -D > cn=proxyuser,ou=system,ou=people,dc=example,dc=de -W '(uid=*)' > > ldapsearch: started Thu Oct 28 12:16:49 2010 > ldap_init( exampleldap01, 389 ) > filter pattern: (uid=*) > returning: ALL > filter is: (uid=*) > version: 1 > > If I use this string I get the complete list of uid-objects sorted by uidNumber > # ldapsearch -v -S uidnumber -b dc=example,dc=de -h exampleldap01 -D > cn=proxyuser,ou=system,ou=people,dc=example,dc=de -W '(uid=*)' > > ldapsearch: started Thu Oct 28 12:37:11 2010 > ldap_init( exampleldap01, 389 ) > filter pattern: (uid=*) > returning: ALL > filter is: (uid=*) > version: 1 > > If I try to search with -x and -S uidnumber I get the same message > that appears in the OpenLDAP logfile: > # ldapsearch -v -x -S uidNumber -b dc=example,dc=de -h exampleldap01 > -D cn=proxyuser,ou=system,ou=people,dc=example,dc=de -W '(uid=*)' > > ldapsearch: started Thu Oct 28 12:25:50 2010 > ldap_init( exampleldap01, 389 ) > filter pattern: (uid=*) > returning: ALL > filter is: (uid=*) > ldap_search: Inappropriate matching > ldap_search: additional info: serverSort control: No ordering rule > ldap_parse_sort_control: Requested LDAP control not found > > Finally I still have no clue how to prevent the client from doing > these kinds of searches. > And I couldn't find any templates regarding the ldapclient on my test machine. > > Any other clues or ideas? > > Bye, Benjamin. > > On Sat, Oct 23, 2010 at 19:17, Dieter Kluenter <dieter(a)dkluenter.de> wrote: >> Benjamin Griese <der.darude(a)gmail.com> writes: >> >>> Hey thanks for quick reply, >>> >>> I put the config of the ldapclient on the ML some days ago, >>> but I can't figure out how I may have set such a rule on client side. >>> Probably it is something hardcoded. >>> >>> ldapclient config: >>> NS_LDAP_FILE_VERSION= 2.0 >>> NS_LDAP_BINDDN= cn=proxyuser,ou=system,ou=people,dc=example,dc=de >>> NS_LDAP_BINDPASSWD= secret >>> NS_LDAP_SERVERS= ldap01 >>> NS_LDAP_SEARCH_BASEDN= dc=example,dc=de >>> NS_LDAP_AUTH= simple >>> NS_LDAP_SEARCH_REF= FALSE >>> NS_LDAP_SEARCH_SCOPE= sub >>> NS_LDAP_SEARCH_TIME= 30 >>> NS_LDAP_CACHETTL= 60 >>> NS_LDAP_PROFILE= solaris_profile >>> NS_LDAP_CREDENTIAL_LEVEL= proxy >>> NS_LDAP_SERVICE_SEARCH_DESC= passwd: ou=people,dc=example,dc=de?sub >>> NS_LDAP_SERVICE_SEARCH_DESC= group: ou=groups,dc=example,dc=de?sub >>> NS_LDAP_SERVICE_SEARCH_DESC= sudoers: ou=SUDOers,dc=example,dc=de?sub >>> >>> That's all I setup, its like defaultest of the defaultest I guess :) >>> >>> And thanks for describing EQUALITY. >> >> I must admit I am not that familiar with old netscape tools, but the >> openldap log ist quite clear, there is a request for a Server Side >> Sorting extended operation, which in fact is quite unusual. You really >> should check Solaris 10 setup for appropriate templates, i.e. what is >> the content of solaris_profile? By the way, AFAIR the flag for sss is >> -F so you may check any templates, Redhat provides these in >> /usr/share/dirsrv, Solaris might be different. >> >> -Dieter >> >> -- >> Dieter Klünter | Systemberatung >> sip: 7770535(a)sipgate.de >> http://www.dpunkt.de/buecher/2104.html >> GPG Key ID:8EF7B6C6 >> > > > > -- > To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To > be is to do -- Sartre | Do be do be do -- Sinatra > -- To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is to do -- Sartre | Do be do be do -- Sinatra

4 11

unable to perform authenticated binds
by Tim Dunphy 03 Nov '10

03 Nov '10

I am attempting to setup an LDAP server under CentOS 5.4. However I am unable to search my ldap directory even tho I am supplying the proper credentials for the Manager account: [root@ldap openldap]# ldapsearch -x -h ldap -D 'cn=Manager,dc=example,dc=net' -W -b 'dc=example,dc=net' Enter LDAP Password: ldap_bind: Invalid credentials (49) Anonymous searches do work however: ldapsearch -x -h ldap -b "dc=example,dc=net" -s sub "objectclass=*" [root@ldap openldap]# ldapsearch -x -h ldap -b "dc=example,dc=net" -s sub "objectclass=*" # extended LDIF # # LDAPv3 # base <dc=example,dc=net> with scope subtree # filter: objectclass=* # requesting: ALL # # search result search: 2 result: 32 No such object I am currently attempting to use the actual word 'secret' to authenticate the Manager account: database bdb suffix "dc=example,dc=net" rootdn "cn=Manager,dc=example,dc=net" # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw secret # rootpw {CRYPT}secret And yet I am still getting error 49's in my openldap logs with loglevel set to 296 /var/log/openldap.log Nov 2 15:45:58 ldap slapd[3522]: slapd starting Nov 2 15:46:14 ldap slapd[3522]: conn=0 fd=11 ACCEPT from IP=127.0.0.1:44552 (IP=0.0.0.0:389) Nov 2 15:46:14 ldap slapd[3522]: conn=0 op=0 BIND dn="cn=Manager,dc=example,dc=net" method=128 Nov 2 15:46:14 ldap slapd[3522]: conn=0 op=0 RESULT tag=97 err=49 text= Nov 2 15:46:14 ldap slapd[3522]: conn=0 fd=11 closed (connection lost) this is how I have configured my ldap.conf BASE dc=example,dc=net HOST localhost URI ldap://ldap.example.net thanks in advance for your help -- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 Share and enjoy!!

5 8

{SOLVED] Error 18: Solaris 10 Native LDAP-Client
by Benjamin Griese 03 Nov '10

03 Nov '10

Hello Ralf, thank you very much for your help! :) In the first place it didn't work and I was sure you have tested the functionality, so I checked what I may have configured differently/wrong. So I checked my list of supportedControls which are presented to the clients: ldapsearch -x -b "" -s base supportedControl before: supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 supportedControl: 2.16.840.1.113730.3.4.9 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 1.3.6.1.4.1.4203.666.5.16 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 This shows the list of supportedControls and the denied Controls were still visible. To make it work I had to put olcAccess: {1}to dn.base="" by * read further down to olcAccess: {3}to dn.base="" by * read below the two denied Controls. after: supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 supportedControl: 1.3.6.1.4.1.4203.666.5.16 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 After that the supportedControls weren't visible anymore when requesting the list. Finally, my working frontend: dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: {0}to dn.base="cn=subschema" by * read olcAccess: {1} to dn.base="" attrs=supportedControl val/objectIdentifierMatc h=1.2.840.113556.1.4.473 by * none olcAccess: {2} to dn.base="" attrs=supportedControl val/objectIdentifierMatc h=2.16.840.1.113730.3.4.9 by * none olcAccess: {3}to dn.base="" by * read olcAccess: {4}to attrs=userPassword,userPKCS12 by self write by * auth olcAccess: {5}to attrs=shadowLastChange by self write by * read olcAccess: {6}to * by * read olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcMonitoring: FALSE olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSyncUseSubentry: FALSE Now requesting passwd/group/sudoers/etc with the Solaris 10 native client works like a charm, to me its like "less is more". :) Thanks to all of you who tried to help and fix the problem, especially Ralf and Dieter. Have a nice day, Benjamin. On Wed, Nov 3, 2010 at 12:07, Ralf Haferkamp <rhafer(a)suse.de> wrote: > Am Mittwoch 03 November 2010, 09:52:26 schrieb Benjamin Griese: >> Hello Ralf, >> > [..] >> In the meantime I set the ACL, but unfortunatly it didn't help solving >> the problem, you may take a look at my example: >> >> DN: olcDatabase={1}hdb,cn=config >> olcAccess: {0}to attrs=userPassword,shadowLastChange by >> dn="cn=ldapadm,dc=example,dc=de" write by >> dn="cn=proxyuser,ou=system,ou=people,dc=example,dc=de" read by >> anonymous auth by self write by * none >> olcAccess: {1} to dn.base="" attrs=supportedControl >> val/objectIdentifierMatch=1.2.840.113556.1.4.473 by * none >> olcAccess: {2} to dn.base="" attrs=supportedControl >> val/objectIdentifierMatch=2.16.840.1.113730.3.4.9 by * none >> olcAccess: {3}to dn.base="" by * read >> olcAccess: {4}to * by dn="cn=ldapadm,dc=example,dc=de" write by * read >> >> If I remember right {4} is not opening up the access when it is >> explicitly denied in the ACLs {1} & {2}, am I right? > Yes, you are right. > >> But I'm not sure if this is the right place for this kind of ACL, >> cn=config instead should be wrong too I guess. > It has to be in the global ACL, i.e. you have to add it to > olcDatabase={-1}frontend,cn=config. > >> Bye, Benjamin. > [..] > > Ralf > -- > SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) > -- To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is to do -- Sartre | Do be do be do -- Sinatra

1 0

ACL permission issue
by Eduardo Santos 03 Nov '10

03 Nov '10

Hi everyone, I'm facing an ACL problem for a long time, and I got to the point that I'm out of ideas. The problem is related to write in a specific branch of DIT. My DIT has the following hierachy dc=spi,dc=net -> c=cl -->ou=users --->ou=regular --->ou=admin The ACL should allow the users under the admin subtree to write in the regular subtree (admin and regular users model). SO, I have the following ACL includes in slapd.conf: include /etc/ldap/acls/acl.conf.default include /etc/ldap/acls/acl.conf The ACL files have the following lines: # /etc/ldap/acls/acl.conf.default # The userPassword by default can be changed # by the entry owning it if they are authenticated. # Others should not be able to see it, except the # admin entry below # These access lines apply to database #1 only access to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=spi,dc=net" write by anonymous auth by self write by * none # Ensure read access to the base for things like # supportedSASLMechanisms. Without this you may # have problems with SASL not knowing what # mechanisms are available and the like. # Note that this is covered by the 'access to *' # ACL below too but if you change that as people # are wont to do you'll still need this if you # want SASL (and possible other things) to work # happily. access to dn.base="" by * read # The admin dn has full write access, everyone else # can read everything. access to * by dn="cn=admin,dc=spi,dc=net" write by * read # /etc/ldap/acls/acl.conf access to dn.children="ou=regular,ou=users,c=cl,dc=spi,dc=net" attrs="children" by dn.sub="ou=admins,ou=users,c=cl,dc=spi,dc=net" manage by * read So, I created an user under the admin subtree with the following DN: uid=cl-admin,ou=admins,ou=users,c=cl,dc=spi,dc=net To test, I'm trying to add an user with the following LDIF file: # Teste description: Test dn: uid=test,ou=regular,ou=users,c=cl,dc=spi,dc=net objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: spi # Customized class cn: Teste sn: teste givenName: Teste uid: teste url: http://mysite.com mail: test(a)mysite.com l: City TimeZone: GMT-4 area: Gov st: State organization: Organization o: SPI preferredLanguage: en-US However, when I try to add the user (ldapadd -x -D "uid=cl-admin,ou=admins,ou=usuarios,c=cl,dc=spi,dc=net" -W -f /tmp/test.ldif I get the following error: ldap_add: Insufficient access (50) additional info: no write access to parent The debug output log for ACL's show me the following sequence of information: Nov 3 12:00:47 nodo108 slapd[16629]: hdb_referrals: tag=104 target="uid=test,ou=regular,ou=users,c=cl,dc=spi,dc=net" matched="ou=regular,ou=users,c=cl,dc=spi,dc=net" Nov 3 12:00:47 nodo108 slapd[16629]: ==> hdb_add: uid=test,ou=regular,ou=users,c=cl,dc=spi,dc=net Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_required entry (uid=test,ou=regular,ou=users,c=cl,dc=spi,dc=net), objectClass "spi" Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type "objectClass" Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type "cn" Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type "sn" Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type "givenName" Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type "uid" Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type "url" Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type "mail" Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type "l" Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type "timeZone" Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type "area" Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type "st" Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type "organization" Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type "o" Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type "preferredLanguage" Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type "structuralObjectClass" Nov 3 12:00:47 nodo108 slapd[16629]: slap_queue_csn: queing 0xb6603a32 20101103140047.629760Z#000000#000#000000 Nov 3 12:00:47 nodo108 slapd[16629]: bdb_dn2entry("uid=test,ou=regular,ou=users,c=cl,dc=spi,dc=net") Nov 3 12:00:47 nodo108 slapd[16629]: => hdb_dn2id("uid=test,ou=regular,ou=users,c=cl,dc=spi,dc=net") Nov 3 12:00:47 nodo108 slapd[16629]: <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30990) Nov 3 12:00:47 nodo108 slapd[16629]: => access_allowed: add access to "ou=regular,ou=users,c=cl,dc=spi,dc=net" "children" requested Nov 3 12:00:47 nodo108 slapd[16629]: => dn: [1] ou=regular,ou=users,c=cl,dc=spi,dc=net Nov 3 12:00:47 nodo108 slapd[16629]: => dn: [3] Nov 3 12:00:47 nodo108 slapd[16629]: => acl_get: [4] attr children Nov 3 12:00:47 nodo108 slapd[16629]: => acl_mask: access to entry "ou=regular,ou=users,c=cl,dc=spi,dc=net", attr "children" requested Nov 3 12:00:47 nodo108 slapd[16629]: => acl_mask: to all values by "uid=cl-admin,ou=admins,ou=users,c=cl,dc=spi,dc=net", (=0) Nov 3 12:00:47 nodo108 slapd[16629]: <= check a_dn_pat: cn=admin,dc=spi,dc=net Nov 3 12:00:47 nodo108 slapd[16629]: <= check a_dn_pat: * Nov 3 12:00:47 nodo108 slapd[16629]: <= acl_mask: [2] applying read(=rscxd) (stop) Nov 3 12:00:47 nodo108 slapd[16629]: <= acl_mask: [2] mask: read(=rscxd) Nov 3 12:00:47 nodo108 slapd[16629]: => slap_access_allowed: add access denied by read(=rscxd) Nov 3 12:00:47 nodo108 slapd[16629]: => access_allowed: no more rules Nov 3 12:00:47 nodo108 slapd[16629]: hdb_add: no write access to parent Nov 3 12:00:47 nodo108 slapd[16629]: send_ldap_result: conn=26 op=1 p=3 Nov 3 12:00:47 nodo108 slapd[16629]: send_ldap_result: err=50 matched="" text="no write access to parent" Nov 3 12:00:47 nodo108 slapd[16629]: send_ldap_response: msgid=2 tag=105 err=50 Nov 3 12:00:47 nodo108 slapd[16629]: conn=26 op=1 RESULT tag=105 err=50 text=no write access to parent I tried a lot of different solutions, but nothing seels to work. Anybody have a clue about how to fix it? -- Eduardo Santos Analista de Sistemas http://eduardosan.wordpress.com http://twitter.com/eduardosan

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical November 2010