openldap-technical August 2011

openldap-technical@openldap.org

87 participants
96 discussions

Virtual list view problem
by Venish Khant 31 May '16

31 May '16

Hi all I am using cpan Net::LDAP module to access LDAP entries. I want to search LDAP entries using Net::LDAP search method. When I do search, I want some limited number of entries from search result, for this(searching) process I am using Net::LDAP::Control::VLV module. But I get error on VLV response control. Please, any one have idea about this error. * Error:* Died at vlv.pl line 50, This is my example. I changed the font style of line 50 #!/usr/bin/perl -w use Net::LDAP; use Net::LDAP::Control::VLV; use Net::LDAP::Constant qw( LDAP_CONTROL_VLVRESPONSE ); use Net::LDAP::Control::Sort; sub procentry { my ( $mesg, $entry) = @_; # Return if there is no entry to process if ( !defined($entry) ) { return; } print "dn: " . $entry->dn() . "\n"; @attrs = $entry->attributes(); foreach $attr (@attrs) { #printf("\t%s: %s\n", $attr, $entry->get_value($attr)); $attrvalue = $entry->get_value($attr,asref=>1); #print $attr.":". $entry->get_value($attr)."\n"; foreach $value(@$attrvalue) { print "$attr: $value\n"; } } $mesg->pop_entry; print "\n"; } $ldap = Net::LDAP->new( "localhost" ); # Get the first 20 entries $vlv = Net::LDAP::Control::VLV->new( before => 0, # No entries from before target entry after => 19, # 19 entries after target entry content => 0, # List size unknown offset => 1, # Target entry is the first ); my $sort = Net::LDAP::Control::Sort->new( order => 'cn' ); @args = ( base => "dc=example,dc=co,dc=in", scope => "subtree", filter => "(objectClass=inetOrgPerson)", callback => \&procentry, # Call this sub for each entry control => [ $sort, $vlv ], ); $mesg = $ldap->search( @args ); # Get VLV response control *($resp) = $mesg->control( LDAP_CONTROL_VLVRESPONSE ) or die;* $vlv->response( $resp ); # Set the control to get the last 20 entries $vlv->end; $mesg = $ldap->search( @args ); # Get VLV response control ($resp) = $mesg->control( LDAP_CONTROL_VLVRESPONSE ) or die; $vlv->response( $resp ); # Now get the previous page $vlv->scroll_page( -1 ); $mesg = $ldap->search( @args ); # Get VLV response control ($resp) = $mes # Now page with first entry starting with "B" in the middle $vlv->before(9); # Change page to show 9 before $vlv->after(10); # Change page to show 10 after $vlv->assert("B"); # assert "B" $mesg = $ldap->search( @args );g->control( LDAP_CONTROL_VLVRESPONSE ) or die; $vlv->response( $resp ); -- Venish Khant www.deeproot.co.in

4 11

Loading LDAP schema files into cn=config
by Mark Cave-Ayland 19 Oct '11

19 Oct '11

Hi all, Having started to look at the changes required to migrate from a slapd.conf setup to a cn=config setup, one of things I'm struggling with is how to load new LDAP schemas into cn=config. I've seen the guides similar to this one here: http://blogger.ziesemer.com/2011/01/ldap-authentication-for-samba.html which suggest hacking together a temporary slapd.conf file containing just the include directives, run slaptest, and then hack the output so that it can be loaded into cn=config using ldapadd. Given that this is a quite a common task, is there no way of generating the LDIF directly to be loaded into the directory, e.g. slaptest -s /etc/ldap/schema/myschema.schema [ -n <schemanum> ] -l myschema.ldif Or then again, is this functionality already there but I just haven't managed to find it yet? I'd be grateful if someone could point me in the right direction and/or give me some hints as to the best way to manage schemas in the new regime. Many thanks, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

13 49

Authenticate Mac OS X users against OpenLDAP on Debian
by Mi 07 Sep '11

07 Sep '11

We added a Mac to our network, and I would like the network users to be able to login with their existing credentials on our Debian openLDAP server. I configured the LDAP access on the Mac, and it can indeed see the users and groups from the openldap server. But when I try to login after clicking "Other...", the login window shakes around, and nothing happens. The server logs show the connection from the Mac and it's searches ( http://pastebin.com/MB2JswAa). (Logging is configured with Parse, Stats, Stats2, Sync. Is there something else I should add to logging that may be useful?) On the Mac, I didn't find anything looking helpful in the logs (http://pastebin.com/yRreFQrJ), but maybe I don't know what to look for. I found many instructions on the Internet which concentrate on mounting user homes from the server over NFS. This is NOT what we want. Users would be authenticated with openldap, but have their homes locally on the Mac, like normal users. I also saw many mentions of adding the apple schema, and I have done that. But maybe I now need to actually use parts of that schema in the user records? Thanks for any help...

3 3

Assigning Groups to LDAP users
by pradyumna dash 06 Sep '11

06 Sep '11

Guys, I have a query, lets take a scenario : Assume we have 2 servers "Server1" and "Server2" and 2 groups "Admin" and "ITTech", What is needed is like say when a user "bob" logging in to "Server1" he will get the group "Admin", but when he logs in to "Server2" he will get group "ITTech". Also it may vary for different users like when "Kris" logs in to Server1 he may get a group called "ITTech" and when he logs in to "Server2" he will get some other group say "Security". Can it be possible by OpenLDAP ? If this is achieved then we are planning to have SUDO files based on the grooups. It would be great if you can provide me some pointers or how-to. Regards, Neo

6 6

Slapd-meta stop at the first unreachable candidate
by Michel Gruau 05 Sep '11

05 Sep '11

Hello, It have a slapd-meta configuration as follows: database meta suffix dc=com uri ldap://server1:389/dc=suffix1,dc=com uri ldap://server2:389/dc=suffix2,dc=com uri ldap://server3:389/dc=suffix3,dc=com I performed numerous tests using "base=com" and changing the order of the above list of uri (in slapd.cnof) and I see that as soon as a candidate directory is unreachable, all other directories located below the directory in failure are not requested by the proxy. For instance, in example below: - if server2 is down, then server 3 is not requeted - if server1 is down, then none of the directories is requested. I have the felling this is a bug ... could you confirm ? FYI, I also tried the "'onerrr continue" config, but did not change annything Thanks in advance. Michel Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net

4 6

RE: N-way multi master configuration issue
by Naga Chaitanya Palle 05 Sep '11

05 Sep '11

Hi, I was able to get the syncronization working between 2 providers. I had to remove data on both the servers and start from beginning. It worked. Now i am facing another issue. In case of single provider-client configuration, fot tls, i used to generate certificate on server and copy the same certificate to client for encrypted communication between provider and client. Now in case of N-way multimaster, i created server1 certificate and copied that certificate to server2 and vice versa. but there is no communication happening between the servers now. Can you please let me know how to use tls with N-way multimaster for N=2 and N>2. Thanks and Regards, Naga Chaitanya ________________________________________ From: Naga Chaitanya Palle Sent: Monday, August 29, 2011 1:37 PM To: Buchan Milne Cc: openldap-technical(a)openldap.org Subject: RE: N-way multi master configuration issue Hi Buchan, After making the changes are per your suggestions, I am still not able to read data between the servers. Also, I deleted DI data on server 2 and restarted to import data from server1 , but no use. Can you please check the slapd.conf files and suggest. Server 1 slapd.conf file # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/share/openldap2.4/schema/sudo.schema include /usr/share/openldap2.4/schema/core.schema include /usr/share/openldap2.4/schema/cosine.schema include /usr/share/openldap2.4/schema/inetorgperson.schema include /usr/share/openldap2.4/schema/nis.schema include /usr/share/openldap2.4/schema/misc.schema include /usr/share/openldap2.4/schema/openldap.schema include /usr/share/openldap2.4/schema/ppolicy.schema include /usr/share/openldap2.4/schema/corba.schema loglevel 296 # Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/ldap2.4/slapd.pid argsfile /var/run/ldap2.4/slapd.args access to attrs=userPassword by self write by users read by anonymous auth #access to attrs=shadowLastChange # by self write # by * auth access to * by * read access to * by dn.base="cn=Manager,dc=comverse-in,dc=com" read by * break # Load dynamic backend modules: # modulepath /usr/lib/openldap # dummy test certificate which you can generate by changing to # /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on # slapd.pem so that the ldap user or group can read it. Your client software # may balk at self-signed certificates, however. # TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt # TLSCertificateFile /etc/pki/tls/certs/slapd.pem # TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem #TLSCipherSuite HIGH:MEDIUM:+SSLv2 #TLSCACertificateFile /etc/openldap2.4/cacerts/cacert.pem #TLSCertificateFile /etc/openldap2.4/cacerts/slapd-cert.pem #TLSCertificateKeyFile /etc/openldap2.4/cacerts/slapd-key.pem # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ####################################################################### # ldbm and/or bdb database definitions ####################################################################### serverId 001 database bdb suffix "dc=comverse-in,dc=com" rootdn "cn=Manager,dc=comverse-in,dc=com" rootpw {SSHA}9tKeVZfgKFCfgIFQxXt5esH0HhQk1dIS # 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}ijFYNcSNctBYg # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap2.4 # Indices to maintain for this database #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 #index sudoUser eq index sudoUser eq index member eq index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub #index objectclass,entryCSN,entryUUID eq # Load dynamic backend modules: # modulepath /usr/lib/openldap modulepath /usr/lib/openldap2.4 # modules available in openldap-servers-overlays RPM package: # moduleload accesslog.la # moduleload auditlog.la # moduleload denyop.la # moduleload dyngroup.la # moduleload dynlist.la # moduleload lastmod.la # moduleload pcache.la moduleload ppolicy.la # moduleload refint.la # moduleload retcode.la # moduleload rwm.la # moduleload smbk5pwd.la moduleload syncprov.la # moduleload translucent.la # moduleload unique.la # moduleload valsort.la # modules available in openldap-servers-sql RPM package: # moduleload back_sql.la syncrepl rid=123 provider=ldap://devonly144.comverse-in.com type=refreshAndPersist interval=00:00:01:00 searchbase="dc=comverse-in,dc=com" filter="(objectClass=*)" scope=sub attrs="*" schemachecking=off bindmethod=simple binddn="cn=Manager,dc=comverse-in,dc=com" credentials=sonora index objectClass,entryCSN,entryUUID eq mirrormode true overlay syncprov syncprov-checkpoint 100 10 overlay ppolicy ppolicy_default "cn=DefaultPassword,ou=pwpolicies,dc=comverse-in,dc=com" ppolicy_hash_cleartext ppolicy_use_lockout #SUDOERS_BASE=ou=SUDOers,dc=comverse-in,dc=com # Replicas of this database #replogfile /var/lib/ldap/openldap-master-replog #replica host=ldap-1.example.com:389 starttls=critical # bindmethod=sasl saslmech=GSSAPI # authcId=host/ldap-master.example.com(a)EXAMPLE.COM #replogfile /var/lib/ldap/openldap-master-replog #replica uri=ldaps://rht144.comverse-in.com:389 starttls=critical Server2 slapd.conf file # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/share/openldap2.4/schema/sudo.schema include /usr/share/openldap2.4/schema/core.schema include /usr/share/openldap2.4/schema/cosine.schema include /usr/share/openldap2.4/schema/inetorgperson.schema include /usr/share/openldap2.4/schema/nis.schema include /usr/share/openldap2.4/schema/misc.schema include /usr/share/openldap2.4/schema/openldap.schema include /usr/share/openldap2.4/schema/ppolicy.schema include /usr/share/openldap2.4/schema/corba.schema loglevel 296 # Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/ldap2.4/slapd.pid argsfile /var/run/ldap2.4/slapd.args access to attrs=userPassword by self write by users read by anonymous auth #access to attrs=shadowLastChange # by self write # by * auth access to * by * read access to * by dn.base="cn=Manager,dc=comverse-in,dc=com" read by * break # Load dynamic backend modules: # modulepath /usr/lib/openldap # dummy test certificate which you can generate by changing to # /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on # slapd.pem so that the ldap user or group can read it. Your client software # may balk at self-signed certificates, however. # TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt # TLSCertificateFile /etc/pki/tls/certs/slapd.pem # TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem #TLSCipherSuite HIGH:MEDIUM:+SSLv2 #TLSCACertificateFile /etc/openldap2.4/cacerts/cacert.pem #TLSCertificateFile /etc/openldap2.4/cacerts/slapd-cert.pem #TLSCertificateKeyFile /etc/openldap2.4/cacerts/slapd-key.pem # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ####################################################################### # ldbm and/or bdb database definitions ####################################################################### serverId 002 #database bdb database bdb #suffix "dc=comverse-in,dc=com" suffix "dc=comverse-in,dc=com" #rootdn "cn=Manager,dc=comverse-in,dc=com" rootdn "cn=Manager,dc=comverse-in,dc=com" rootpw {SSHA}4qLml3DcOyfwiKlN/garIms4a8fmsNkx #rootpw sonora # 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}ijFYNcSNctBYg # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap2.4 # Indices to maintain for this database #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 #index sudoUser eq index sudoUser eq index member eq index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub #index objectclass,entryCSN,entryUUID eq # Load dynamic backend modules: # modulepath /usr/lib/openldap modulepath /usr/lib/openldap2.4 # modules available in openldap-servers-overlays RPM package: # moduleload accesslog.la # moduleload auditlog.la # moduleload denyop.la # moduleload dyngroup.la # moduleload dynlist.la # moduleload lastmod.la # moduleload pcache.la moduleload ppolicy.la # moduleload refint.la # moduleload retcode.la # moduleload rwm.la # moduleload smbk5pwd.la moduleload syncprov.la # moduleload translucent.la # moduleload unique.la # moduleload valsort.la # modules available in openldap-servers-sql RPM package: # moduleload back_sql.la overlay ppolicy ppolicy_default "cn=DefaultPassword,ou=pwpolicies,dc=comverse-in,dc=com" ppolicy_hash_cleartext ppolicy_use_lockout #SUDOERS_BASE=ou=SUDOers,dc=comverse-in,dc=com # Replicas of this database #replogfile /var/lib/ldap/openldap-master-replog #replica host=ldap-1.example.com:389 starttls=critical # bindmethod=sasl saslmech=GSSAPI # authcId=host/ldap-master.example.com(a)EXAMPLE.COM #replogfile /var/lib/ldap/openldap-master-replog #replica uri=ldaps://rht144.comverse-in.com:389 starttls=critical binddn="cn=Manager,dc=comverse-in,dc=com" bindmethod=simple credentials=sonora #serverId 2 syncrepl rid=124 provider=ldap://uplite98.comverse-in.com type=refreshAndPersist interval=00:00:01:00 searchbase="dc=comverse-in,dc=com" filter="(objectClass=*)" scope=sub attrs="*" schemachecking=off bindmethod=simple binddn="cn=Manager,dc=comverse-in,dc=com" credentials=sonora #updateref ldap://uplite98.comverse-in.com index objectClass,entryCSN,entryUUID eq mirrormode true overlay syncprov syncprov-checkpoint 100 10 Thanks and Regards, Naga Chaitanya -----Original Message----- From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net] Sent: Friday, August 26, 2011 7:15 PM To: Naga Chaitanya Palle Cc: openldap-technical(a)openldap.org Subject: Re: N-way multi master configuration issue On Friday, 26 August 2011 15:28:13 Naga Chaitanya Palle wrote: > Hi buchan, > > My server 1 is uplite98.comverse-in.com. In its slapd.conf, I have syncrepl > pointing to server 2 devonly144.comverse-in.com and vice versa for > server2. Then your serverid (and, it should actually be serverId) is wrong: > > serverid 124 ldap://devonly144.comverse-in.com > > syncrepl rid=124 > > > > provider=ldap://devonly144.comverse-in.com:389 The URI form of serverId is useful if you have the same configuration on all your masters, in which case the listening address of your server must match one of the URIs. You may want to use this form for now: serverId 1 If your serverId's weren't correct (check the contextCSNs), you should probably re-import an export of one server on the other one. > I did not exactly understand what you indicated. > Can you please be more specific about what changes needs to be done in the > slapd.conf file? In a multi-master setup, each server should be replicating off *all* servers, including itself. > Thanks and Regards, > Naga Chaitanya > > -----Original Message----- > From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net] > Sent: Friday, August 26, 2011 6:56 PM > To: openldap-technical(a)openldap.org > Cc: Naga Chaitanya Palle > Subject: Re: N-way multi master configuration issue > > On Friday, 26 August 2011 12:56:38 Naga Chaitanya Palle wrote: > > Hi, > > > > I am trying to set up N-way multimaster configuration using syncrepl on > > openldap2.4 for RHEL 5.4 > > > > Currently I am using two masters for testing. > > > > The slapd.conf on server1 is > > moduleload syncprov.la > > serverid 124 ldap://devonly144.comverse-in.com > > syncrepl rid=124 > > > > provider=ldap://devonly144.comverse-in.com:389 > > type=refreshAndPersist > > interval=00:00:01:00 > > searchbase="dc=comverse-in,dc=com" > > filter="(objectClass=*)" > > scope=sub > > attrs="*" > > schemachecking=off > > bindmethod=simple > > binddn="cn=Manager,dc=comverse-in,dc=com" > > credentials=sonora > > > > index objectClass,entryCSN,entryUUID eq > > mirrormode true > > > > overlay syncprov > > syncprov-checkpoint 100 10 > > > > > > The slapd.conf on server2 is > > moduleload syncprov.la > > serverid 123 ldap://uplite98.comverse-in.com > > syncrepl rid=123 > > > > provider=ldap://uplite98.comverse-in.com:389 > > type=refreshAndPersist > > interval=00:00:01:00 > > searchbase="dc=comverse-in,dc=com" > > filter="(objectClass=*)" > > scope=sub > > attrs="*" > > schemachecking=off > > bindmethod=simple > > binddn="cn=Manager,dc=comverse-in,dc=com" > > credentials=sonora > > > > index objectClass,entryCSN,entryUUID eq > > mirrormode true > > > > overlay syncprov > > syncprov-checkpoint 100 10 > > > > But there is no data synchronization happening between the severs. > > Of course not, you have configured each server only to replicate from > itself. > > > When I added test3 user on server1, it is not reflecting on server 2. > > Same way when I added test4 user on server2 it is not reflecting on > > server1. > > > > Please let me know what is missing in this configuration. > > syncrepl statements pointing to the other master. > > Regards, > Buchan > > > > > =========================================================================== > ==== Please refer to http://www.aricent.com/legal/email_disclaimer.html for > important disclosures regarding this electronic communication. > ========================================================================== > ===== =============================================================================== Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. ===============================================================================

4 5

OpenLDAP proxy, identity assertion and suffix massage
by Clément OUDOT 05 Sep '11

05 Sep '11

Hello, I am using OpenLDAP 2.4.26 on GNU/Linux. I would like to configure a simple proxy with identity assertion and suffix massage and assert identity for the rootdn of my LDAP backend, to match the rootdn of the proxied backend (on port 390). Here is my configuration : ------------ database ldap suffix "ou=am,dc=local" rootdn "cn=manager,ou=am,dc=local" rootpw secretproxy uri ldap://127.0.0.1:390 idassert-bind bindmethod=simple binddn="cn=admin,dc=example,dc=com" credentials="secret" mode=none idassert-authzFrom "dn.exact:cn=manager,ou=am,dc=local" overlay rwm rwm-suffixmassage "ou=am,dc=local" "dc=example,dc=com" ------------ When I try to authenticate with "cn=manager,ou=am,dc=local" on the proxy, the bind is forwarded to the proxied directory directly, as "cn=manager,dc=example,dc=com". It seems the rwm overlay has done the substitution, so the idassert-authzFrom does not match. This ended with an LDAP error 48, as we can see here: ------------ >>> dnPrettyNormal: <cn=manager,ou=am,dc=local> => ldap_bv2dn(cn=manager,ou=am,dc=local,0) <= ldap_bv2dn(cn=manager,ou=am,dc=local)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=manager,ou=am,dc=local)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=manager,ou=am,dc=local)=0 <<< dnPrettyNormal: <cn=manager,ou=am,dc=local>, <cn=manager,ou=am,dc=local> conn=1001 op=0 BIND dn="cn=manager,ou=am,dc=local" method=128 do_bind: version=3 dn="cn=manager,ou=am,dc=local" method=128 ==> rewrite_context_apply [depth=1] string='cn=manager,ou=am,dc=local' ==> rewrite_rule_apply rule='((.+),)?ou=am,[ ]?dc=local$' string='cn=manager,ou=am,dc=local' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'cn=manager,dc=example,dc=com'} [rw] bindDN: "cn=manager,ou=am,dc=local" -> "cn=manager,dc=example,dc=com" >>> dnPrettyNormal: <cn=manager,dc=example,dc=com> => ldap_bv2dn(cn=manager,dc=example,dc=com,0) <= ldap_bv2dn(cn=manager,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=manager,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=manager,dc=example,dc=com)=0 <<< dnPrettyNormal: <cn=manager,dc=example,dc=com>, <cn=manager,dc=example,dc=com> ===>slap_sasl_match: comparing DN cn=manager,dc=example,dc=com to rule dn:cn=manager,ou=am,dc=local slap_parseURI: parsing dn:cn=manager,ou=am,dc=local <===slap_sasl_match: comparison returned 48 send_ldap_result: conn=1001 op=0 p=3 send_ldap_result: err=48 matched="" text="" send_ldap_response: msgid=1 tag=97 err=48 ------------ Do you have any suggestion for using the idassert-authzFrom parameter with the suffixmassage? Thanks for your help, Clément.

2 2

OpenLDAP client test program connecting to LDAP server over SSL failed
by daisy.wu＠emc.com 01 Sep '11

01 Sep '11

I am trying to write a simple client test program using OpenLDAP client API to connect to Microsoft Active Directory Server over SSL. Below is code snippet. The program failed to connect. It failed because of this error: ldap_sasl_bind_s: Can't contact LDAP server (-1) error:14090086:SSL routines: SSL3_GET_SERVER_CERTIFICATE:certificate verify failed I know there's no problem with LDAP certificate store /path/to/ldap_certdb because a simple LDAP client test program written in Mozilla LDAP C-SDK worked fine connecting to this same AD server, over SSL. I need to know if I am using the correct OpenLDAP client API calls. Any input would be much appreciated. Thanks. Source Code: ldap_initialize( &ld, uri ); if ( ld == NULL ) { tester_perror( "ldap_initialize", NULL ); exit( EXIT_FAILURE ); } rc = ldap_set_option( ld, LDAP_OPT_PROTOCOL_VERSION, &version ); printf("rc=ldap_set_option(ld, LDAP_OPT_PROTOCOL_VERSION, %d)=%d, error=%s\n", version, rc, ldap_err2string(rc)); rc = ldap_set_option( ld, LDAP_OPT_REFERRALS, chaserefs ? LDAP_OPT_ON : LDAP_OPT_OFF ); printf("rc=ldap_set_option(ld, LDAP_OPT_REFERRALS, %d)=%d, error=%s\n", chaserefs, rc, ldap_err2string(rc)); int debug_flag1 = -1; // LDAP_DEBUG_ANY ; rc = ldap_set_option( ld, LDAP_OPT_DEBUG_LEVEL, &debug_flag1); printf("rc=ldap_set_option(ld, LDAP_OPT_DEBUG_LEVEL, %d)=%d, error=%s\n", debug_flag1, rc, ldap_err2string(rc)); char *cert_path="/path/to/ldap_certdb"; rc = ldap_set_option( ld, LDAP_OPT_X_TLS_CACERTDIR, &cert_path); printf("rc=ldap_set_option(ld, LDAP_OPT_X_TLS_CACERTDIR, %s)=%d, error=%s\n", cert_path, rc, ldap_err2string(rc)); int reqcert = LDAP_OPT_X_TLS_ALLOW; rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, &reqcert); printf("rc=ldap_set_option(ld, LDAP_OPT_X_TLS_REQUIRE_CERT, %d)=%d, error=%s\n", reqcert, rc, ldap_err2string(rc)); rc = ldap_sasl_bind_s( ld, manager, LDAP_SASL_SIMPLE, passwd, NULL, NULL, NULL ); if ( rc != LDAP_SUCCESS ) { tester_ldap_error( ld, "ldap_sasl_bind_s", NULL ); switch ( rc ) { case LDAP_BUSY: case LDAP_UNAVAILABLE: /* fallthru */ default: break; } exit( EXIT_FAILURE ); } Here's program output: rc=ldap_set_option(ld, LDAP_OPT_PROTOCOL_VERSION, 3)=0, error=Success rc=ldap_set_option(ld, LDAP_OPT_REFERRALS, 0)=0, error=Success rc=ldap_set_option(ld, LDAP_OPT_DEBUG_LEVEL, -1)=0, error=Success rc=ldap_set_option(ld, LDAP_OPT_X_TLS_CACERTDIR, /path/to/ldap_certdb)=0, error=Success rc=ldap_set_option(ld, LDAP_OPT_X_TLS_REQUIRE_CERT, 3)=0, error=Success PID=4781 - Search(2): base="OU=people,OU=documentum,DC=adldap112,DC=dctmlabs,DC=com", filter="cn=aduser2*" attr="cn". slapd-search PID=4781: ldap_sasl_bind_s: Can't contact LDAP server (-1) error:14090086:SSL routines: SSL3_GET_SERVER_CERTIFICATE:certificate verify failed From: Wu, Daisy Sent: Friday, August 26, 2011 4:53 PM To: openldap-technical(a)openldap.org; 'openldap-devel-request(a)openldap.org' Subject: Need sample OpenLDAP client test program connecting to LDAP server over SSL Hi, OpenLDAP developers, Do you have any sample test programs (or code snippets) that uses OpenLDAP client API to connect to LDAP server over SSL? Thanks in advance. Daisy

3 11

Status of persistent search in OpenLDAP
by Clément OUDOT 01 Sep '11

01 Sep '11

Hello, I tried to know if the persistent search control (OID 2.16.840.1.113730.3.4.3) was supported in OpenLDAP. The latests messages I read were saying "no", as we can see in this discussion: http://www.openldap.org/lists/openldap-technical/201008/msg00246.html But this blog entry is saying this control was introduced in OpenLDAP 2.2: http://www.connexitor.com/blog/pivot/entry.php?id=112 So can you confirm that OpenLDAP 2.4 does not support persistent search control? Is this feature planned? Thanks for your help, Clément.

4 7

Memory Leak in slapd (or did I miss something configuring?)
by Thomas Rasmussen 01 Sep '11

01 Sep '11

Hello (originally posted to -bugs list, but think this might be the correct list) I have an openldap installation setup which appears to have a memory leak which I have not been able to solve by upgrading software etc. which is why I'm submitting this, if this is the wrong list, please let me know. The setup is: - OpenLDAP server running 2.4.26, compiled against db-5.2.28, heimdal 1.2.1. - Server is SunOS servername 5.10 Generic_141445-09 i86pc i386 i86pc, 6GB of RAM and 5GB of swap (in a VMWare ESX environment) I have the following in my DB_CONFIG file: set_cachesize 0 52428800 0 set_lg_regionmax 1048576 set_lg_max 10485760 set_lg_bsize 2097152 set_lg_dir /pack/openldap/var/openldap-crl-logs In my slapd.conf I have the following entries (I stripped out some restricts and other irrelevant lines) include /pack/openldap/etc/openldap/schema/core.schema include /pack/openldap/etc/openldap/schema/entrust.attributes.cfg include /pack/openldap/etc/openldap/schema/entrust.objectclasses.cfg idletimeout 300 pidfile /pack/openldap/var/run/slapd-crl.pid argsfile /pack/openldap/var/run/slapd-crl.args threads 4 database bdb suffix "c=DK" directory /pack/openldap/var/openldap-crl index objectClass,entryCSN,entryUUID eq checkpoint 128 1 dbnosync overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 serverID 2 monitoring off idletimeout 10 Just FYI, the server is a clone of another server currently running syncprov replication between two nodes, hence the syncprov lines. This server has the same databases as the production ones, but I just moved it to isolated area and removed all sync options from slapd. My database is rather big: vs24n02z2.prl1:/pack/openldap/var/openldap-crl root$ du -sh *.bdb 961M dn2id.bdb 162M entryCSN.bdb 67M entryUUID.bdb 10G id2entry.bdb 4.0M objectClass.bdb but I'd imagine this not beeing a problem (other than some performance issues, but this is not the problem here). Now, when I start up my slapd, it consumes around 6MB RAM, all is fine, I can perform searches and updates without problems. But my memory consumption is going through the roof! If I perform a search through the part of the database having alot of data, I suddenly find slapd using 500+ MB of memory... In our production setup, we actually see that after a couple of weeks, slapd is consuming 3+ GB of memory, and then at some point hits a Out of memory, and crashes. Our production setup is infact a openldap 2.4.22 with berkeley db 4.6.21, and my test server (cloned in a vmware environment) has just upgraded this environment by this recipe: Using db-4.6.21 * db_checkpoint -1 * db_recover -h <path to bdb files> install db-5.2.28 * Loop through all bdb files: db_upgrade <bdb file> * install openldap 2.4.26 (compiled against db-5.2.28) * start slapd The server which updates the LDAP is performing many search and updates, which is probably why memory consumption is exploding after restarts? Now, my main concern is, how (if possible) can we procede with this? We really need to find the problem as this causes production problems whenever the ldap crashes. Regards Thomas

3 7

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical August 2011