Virtual list view problem
by Venish Khant
Hi all
I am using cpan Net::LDAP module to access LDAP entries. I want to
search LDAP entries using Net::LDAP search method. When I do search, I
want some limited number of entries from search result, for
this(searching) process I am using Net::LDAP::Control::VLV module. But
I get error on VLV response control. Please, any one have idea about
this error.
*
Error:* Died at vlv.pl line 50,
This is my example. I changed the font style of line 50
#!/usr/bin/perl -w
use Net::LDAP;
use Net::LDAP::Control::VLV;
use Net::LDAP::Constant qw( LDAP_CONTROL_VLVRESPONSE );
use Net::LDAP::Control::Sort;
sub procentry {
my ( $mesg, $entry) = @_;
# Return if there is no entry to process
if ( !defined($entry) ) {
return;
}
print "dn: " . $entry->dn() . "\n";
@attrs = $entry->attributes();
foreach $attr (@attrs) {
#printf("\t%s: %s\n", $attr, $entry->get_value($attr));
$attrvalue = $entry->get_value($attr,asref=>1);
#print $attr.":". $entry->get_value($attr)."\n";
foreach $value(@$attrvalue) {
print "$attr: $value\n";
}
}
$mesg->pop_entry;
print "\n";
}
$ldap = Net::LDAP->new( "localhost" );
# Get the first 20 entries
$vlv = Net::LDAP::Control::VLV->new(
before => 0, # No entries from before target entry
after => 19, # 19 entries after target entry
content => 0, # List size unknown
offset => 1, # Target entry is the first
);
my $sort = Net::LDAP::Control::Sort->new( order => 'cn' );
@args = ( base => "dc=example,dc=co,dc=in",
scope => "subtree",
filter => "(objectClass=inetOrgPerson)",
callback => \&procentry, # Call this sub for each entry
control => [ $sort, $vlv ],
);
$mesg = $ldap->search( @args );
# Get VLV response control
*($resp) = $mesg->control( LDAP_CONTROL_VLVRESPONSE ) or die;*
$vlv->response( $resp );
# Set the control to get the last 20 entries
$vlv->end;
$mesg = $ldap->search( @args );
# Get VLV response control
($resp) = $mesg->control( LDAP_CONTROL_VLVRESPONSE ) or die;
$vlv->response( $resp );
# Now get the previous page
$vlv->scroll_page( -1 );
$mesg = $ldap->search( @args );
# Get VLV response control
($resp) = $mes
# Now page with first entry starting with "B" in the middle
$vlv->before(9); # Change page to show 9 before
$vlv->after(10); # Change page to show 10 after
$vlv->assert("B"); # assert "B"
$mesg = $ldap->search( @args );g->control( LDAP_CONTROL_VLVRESPONSE ) or
die;
$vlv->response( $resp );
--
Venish Khant
www.deeproot.co.in
7 years, 6 months
Loading LDAP schema files into cn=config
by Mark Cave-Ayland
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
12 years, 1 month
Authenticate Mac OS X users against OpenLDAP on Debian
by Mi
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...
12 years, 3 months
Assigning Groups to LDAP users
by pradyumna dash
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
12 years, 3 months
Slapd-meta stop at the first unreachable candidate
by Michel Gruau
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
12 years, 3 months
RE: N-way multi master configuration issue
by Naga Chaitanya Palle
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.
===============================================================================
12 years, 3 months
OpenLDAP proxy, identity assertion and suffix massage
by Clément OUDOT
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.
12 years, 3 months
OpenLDAP client test program connecting to LDAP server over SSL failed
by daisy.wu＠emc.com
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
12 years, 3 months
Memory Leak in slapd (or did I miss something configuring?)
by Thomas Rasmussen
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
12 years, 3 months
