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
OpenLDAP and dynalogin (two-factor auth with HOTP)
by Daniel Pocock
Some time ago I created the dynalogin ( http://www.dynalogin.org )
solution for two-factor authentication.
I'm just contemplating how to make it easier to integrate, and making it
convenient to use with OpenLDAP seems like a good strategy: can anyone
comment on that?
The initial thoughts that I have about the subject:
- SASL based solution (dynalogin has digest capability already, so it
could be adapted for SASL PLAIN or DIGEST-MD5)
- should not prevent password logins (user should be able to use either
password or HOTP code)
- should enable people to use it indirectly (e.g. if someone already has
pam_ldap working, they should be able to add dynalogin to their OpenLDAP
server and get immediate benefit)
- use cases: UNIX login, high-security webmail login, VPN and OpenID
provider backed by OpenLDAP
I know that SASL already supports OTP, but that is not HOTP, it is OPIE
(or S/Key) RFC 2289:
http://tools.ietf.org/html/rfc2289
whereas HOTP is RFC 4226:
http://www.ietf.org/rfc/rfc4226.txt
HOTP is considered more secure and more widely implemented.
8 years, 5 months
DIT for an academic institution
by Shali 9846303531
Dear All,
I am new to these LDAP concepts , i have prepared a DIT for our
organization with two academic institutions with each institution having
different branches of study and also there is staff and students . i have
attached the DIT , if am going through a wrong way kindly guide me.
--
Thanks & Regards
Shali.K.R
Server Administrator
9 years, 6 months
Weird DNS round-robin issue
by Dennis Leeuw
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
I hope I am on the right list for the problem I am experiencing.
We have two subnets
192.168.196.
192.168.222.
Our main LDAP servers run in 192.168.196. and are load-balanced by
round-robin DNS.
The 192.168.196. network is exhausted, so we added a new LDAP slave to
192.168.222. and added the IP address to the round-robin pool.
But it seems that it is only used by other servers in the 192.168.222
network and not by servers in the 192.168.196. network
This setup has now been running for 6 days, with nscd.conf:
enable-cache hosts yes
positive-time-to-live hosts 3600
negative-time-to-live hosts 20
suggested-size hosts 211
check-files hosts yes
persistent hosts yes
shared hosts yes
max-db-size hosts 33554432
and nslcd.conf:
uid nslcd
gid ldap
uri ldap://ldap.div.ourdomain.nl/
base dc=div,dc=ourdomain,dc=nl
ssl no
tls_cacertdir /etc/openldap/cacerts
The LDAP server in the 192.168.222 range serves only 33 connections
all from the 192.168.222 range, and the 2 hosts in the 192.168.196
range serve 599 and 706 connections. The last 2 servers do serve the
143.121.222. network also. So might there be some caching issue?
$ getent ahost ldap.div.ourdomain.nl
192.168.196.190 STREAM ldap.div.ourdomain.nl
192.168.196.190 DGRAM
192.168.196.190 RAW
192.168.196.151 STREAM
192.168.196.151 DGRAM
192.168.196.151 RAW
192.168.222.179 STREAM
192.168.222.179 DGRAM
192.168.222.179 RAW
Is this the right list for this question? And if so can someone help
me understand what is going on?
With kind regards,
Dennis Leeuw
- --
ICT Medewerker
Divisie Biomedische Genetica
UMC Utrecht
Heidelberglaan 100 STR2.126
3584 CX Utrecht
The Netherlands
06 27744048
intern: 64048
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTAyjwAAoJEMVYYpdbQscouGsH/3yXjh6zmLMDRaks18qe+yH7
oUrdatkENF7+WyxLz7ZzNL69gXyEwTANGGf9y7CYuqNu47PDs3SvNOM1/kgjy7pr
CSN1t9acVb9i67JgOV2ed5fMHlOzOR+sevNKjsdEdKVXrYvcXnevLOD0KHhGlXeq
Ips0Uqk8cusDXQZSUPab0aQNhWawyT1Tf4SQVAJbJ3OYEiFpHyPJXos2F4DIpYPJ
9FLn/dqV8sUNc9kaOHRjwcVYYAVyey9vX33xbYKr4pXKLd/ujaArBtwE1tyKvR2G
JPz6Gw5sYK5JLjkmr1uzPAze46heiVFY6U1Vv7aMJ4ujuabBiU11Us2k4XuotPI=
=UxBr
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is
uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht
ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct
te informeren door het bericht te retourneren. Het Universitair Medisch
Centrum Utrecht is een publiekrechtelijke rechtspersoon in de zin van de W.H.W.
(Wet Hoger Onderwijs en Wetenschappelijk Onderzoek) en staat geregistreerd bij
de Kamer van Koophandel voor Midden-Nederland onder nr. 30244197.
Denk s.v.p aan het milieu voor u deze e-mail afdrukt.
------------------------------------------------------------------------------
This message may contain confidential information and is intended exclusively
for the addressee. If you receive this message unintentionally, please do not
use the contents but notify the sender immediately by return e-mail. University
Medical Center Utrecht is a legal person by public law and is registered at
the Chamber of Commerce for Midden-Nederland under no. 30244197.
Please consider the environment before printing this e-mail.
9 years, 6 months
Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?
by Turbo Fredriksson
[Sorry Howard for sending it to you personally. It was meant for the list.
I sent a copy to the list as well. I hope you don't mind if I send this reply
to the list. I've included every word, so not to take something out of
context.]
On Jan 30, 2014, at 6:17 PM, Howard Chu wrote:
>> Personally, I think it's spot on. It IS hard to configure an LDAP server, and
>> even harder to understand how it works (the object based part). Took me three
>> months first time, and I'm not an idiot.
>
> The object based part is *LDAP*, so that complaint is not specific to OpenLDAP.
Indeed.
But setting up something like Active Directory is something my aunt can/could
do. It probably won't scale to thousands (or maybe not even hundreds :) of
users, but it can be done with reasonable ease.
> The part about RedHat seems fairly accurate to me, it *is* true that they have their own commercial LDAP server to sell, and they have no great interest in OpenLDAP working well on their platforms.
>
>> Even today, I need to consult either my own book or the howto (or seriously
>> skim through the man pages) to setup a new server.
>
> And I still need to read the docs when configuring an Apache HTTP server. That's why we have manpages, there's nothing wrong about that.
Same here. Not my point (see the part at the bottom)...
>> And even worse if when you want to optimize the backend... There's a lot of
>> magic there....
>
> The LMDB backend has no tuning/optimization. That's one of the reasons it exists today.
Yeah, but isn't it quite slow with lmdb? I haven't tested that in years, so
I don't know. One wouldn't run it in production though?
>> And with the new config backend!? I haven't even had the time or energy to go
>> that far yet!
>>
> I think you (and everyone else) are blowing this way out of proportion. Compare the example from here
I know how it works and I don't really have that much problem with it, it's just
so much more difficult to setup (initially) and then maintain than a simple
text file.
It's way better, but it IS also more complicated (than just fire up an editor,
modify the part you want and then issue a service restart - can't be much
simpler than that)...
> http://www.openldap.org/doc/admin24/slapdconf2.html#Configuration%20Example
>
> to the slapd.conf example
>
> http://www.openldap.org/doc/admin24/slapdconfig.html#Configuration%20File...
>
> They aren't that different, and anyone familiar with slapd.conf and LDIF files should have no trouble mapping concepts from one to the other.
>
> And if you aren't familiar with slapd.conf *and* LDIF then you don't know enough to be an LDAP administrator in the first place, you need to do more homework. That's just life.
I couldn't agree more! I've taken over more than my fair share of badly setup
and maintained OpenLDAP servers to get really pissed at all the ones not having
a clue what they're doing.
It's not just making a config file/backend to allow the server to start, it's
more planning on how the database should look like (where to put what and
what object classes to use and allow), setting up access control etc, etc. The
actually planing of the database (the content) is the most important part, and
it require quite a lot of reading and testing before it's understood properly to
be able to be used to any extent.
But then there's the integration to the rest of the system (pam login and what
not), Kerberos, SASL, etc, etc...
My point wasn't to argue about the validity of how the OpenLDAP server and it's
config file/backend work etc. I fully agree and have no problems with it.
My point was that the website isn't WRONG - it IS hard! Maybe it SHOULD be hard?
The whole concept of an LDAP server is a difficult subject, and shouldn't be
taken lightly.
Unfortunately, it seems that way to many beginners that have been installing
a distribution at home is starting to work as a Linux tech/admin thinking that
just because the've run it at their workstation at home for a couple of months
makes them good enough to work in a professional environment.
I see that in a lot of OpenSource project I'm part of. Complete noobs want to
use something complicated that require quite a lot of homework. And then comes
complaining when things go south! Or even worse, they bad mouth the project or
the technology!
(Open)LDAP is one of those many things that require a lot more from the admin
than say ... installing a mail server locally...
On Debian GNU/Linux that's practically automatic. Just answer a couple of
questions, and it works...
It's sad that the website in question (and from what one could take from this -
that people 'out there') actually thinks that this should be easy. But it's not
(technically) wrong...
--
There are no dumb questions,
unless a customer is asking them.
- Unknown
9 years, 6 months
Problem after migration openldap 2.3.43 to 2.4.23 --> 32 No Such Object
by Jonas Kellens
Hello,
I have a working openLDAP server version 2.3.43. My configuration there
works : the correct users have the correct access.
I have set up a new openLDAP-server with newer version 2.3.43.
I have no working openLDAP on version 2.3.43.
I have tried with the new syntax and with the command /usr/sbin/slaptest
-f /etc/openldap/slapd.conf -v to use the build in converion tool, but I
always got : ldap_bind: Invalid credentials (49)
So I forgot this conversion and continued with the "old" slapd.conf file.
But in this configuration (which is just a copy/paste of my openLDAP
2.3.43) no user can query the LDAP entries.
So this is the setup :
I have a user : cn=U101001,ou=101001,dc=mydomain
This user is member of the group :
cn=tbook1,ou=gebruikers,ou=101001,dc=mydomain
These members can read entries in the tree :
ou=tbook1,ou=contacten,ou=101001,dc=mydomain
I have in slapd.conf :
access to dn.one="ou=tbook1,ou=contacten,ou=101001,dc=mydomain"
by group.exact="cn=admins,ou=101001,dc=mydomain" write
by group.exact="cn=tbook1,ou=gebruikers,ou=101001,dc=mydomain" read
This user cn=U101001,ou=101001,dc=mydomain really exists (if you should
doubt) :
# extended LDIF
#
# LDAPv3
# base <cn=U101001,ou=101001,dc=mydomain> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# U101001, 101001, mydomain
dn: cn=U101001,ou=101001,dc=mydomain
cn: U101001
sn: U101001
objectClass: inetOrgPerson
objectClass: top
userPassword:: e1NTSEF9OVBTNmltR3ZpUEhzK1JRQVpickNVdVR5cS9Iejg5TzY=
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
The group cn=tbook1,ou=gebruikers,ou=101001,dc=mydomain also really
exists (if you should doubt) :
# tbook1, gebruikers, 101001, mydomain
dn: cn=tbook1,ou=gebruikers,ou=101001,dc=mydomain
cn: tbook1
member: cn=U101001,ou=101001,dc=mydomain
objectClass: groupOfNames
objectClass: top
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
When I query the LDAP-tree ou=tbook1,ou=contacten,ou=101001,dc=mydomain
with my root-account (cn=Manager,dc=mydomain), the I get results :
[root@ldap1 ]# ldapsearch -x -D 'cn=Manager,dc=mydomain' -b
"ou=tbook1,ou=contacten,ou=101001,dc=mydomain" -W
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <ou=tbook1,ou=contacten,ou=101001,dc=mydomain> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# tbook1, contacten, 101001, mydomain
dn: ou=tbook1,ou=contacten,ou=101001,dc=mydomain
ou: tbook1
objectClass: organizationalUnit
objectClass: top
...<cut>...
# search result
search: 2
result: 0 Success
# numResponses: 5
# numEntries: 4
But when I query this same LDAP-tree with my user
cn=U101001,ou=101001,dc=mydomain, I get :
[root@ldap1 openldap]# ldapsearch -x -D
'cn=U101001,ou=101001,dc=mydomain' -b "dc=mydomain" -W
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <dc=mydomain> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# search result
search: 2
result: 32 No such object
# numResponses: 1
I also have phpLDAPadmin installed and there I see that there are
definitely enries in the LDAP-directory
ou=tbook1,ou=contacten,ou=101001,dc=mydomain.
So why does my user cn=U101001,ou=101001,dc=mydomain fails to get results ??
Kind regards,
Jonas.
9 years, 7 months
LMDB test assertion failures on Linux/MIPS
by Martin Lucina
Hi,
I've recently started using LMDB in a new project targeted to MIPS (and
later also ARM) architectures. While developing my storage code I found
that test cases which execute perfectly on x86 were failing with assertions
inside LMDB on mips and mipsel devices.
Investigating further, I've found that the "mtest" test program included
with LMDB also fails. Specifically, the failures I'm seeing are any of the
following:
mdb.c:2635: Assertion 'pglast <= env->me_pglast' failed in mdb_freelist_save()
or
mdb.c:5100: Assertion 'IS_BRANCH(mc->mc_pg[mc->mc_top])' failed in mdb_cursor_sibling()
or
mdb.c:5176: Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next()
or
mdb.c:1713: Assertion 'rc == 0' failed in mdb_page_dirty()
etc.
The failures are intermittent in that there's about a 50% chance mtest will
complete successfully. The line numbers are against LMDB 0.9.11 source.
Target devices and toolchain combinations I have tried (all fail):
- mips-sf-linux-musl cross compilers from musl.codu.org, musl libc 0.9.15.
Atheros AR9344 cpu, OpenWRT trunk (Linux 3.10.28).
- mipsel-sf-linux-musl cross compilers from musl.codu.org, musl libc
0.9.15, Broadcom BCM4706, Tomato firmware by "shibby" (Linux 2.6.22.x
based on ASUS SDK).
In all cases the code fails both with and without optimization, and is
compiled as a static executable.
Consulting with a friend who is also developing on MIPS devices he said he
ran into similar problems when trying LMDB. He suggested that I check for
problems with unaligned memory accesses; indeed compiling LMDB with
-Wcast-align produces many warnings regarding such accesses.
My knowledge of LMDB and MIPS internals is not up to debugging this but it
seems like unaligned accesses may(?) be the underlying cause.
What is the status of LMDB on MIPS? Has anyone tried it?
Any help would be much appreciated.
Martin
9 years, 8 months
Works with ldapsearch, but can't get it to work with ldap_search_ext_s()
by Werner - Google
Hi,
Trying to get a ldapclient to authenticate against it, but having a
difficult time trying to figure out what i'm doing wrong. Would appreciate
any tip/help pointing me in the correct direction.
Company has a Microsoft Active Directory structure, like
domain.com
region_a
users
john.doe
marcus.zap
servers
...
...
region_b
users
magaly.frap
roger.smith
...
servers
...
...
Testing with ldapsearch, it works fine, returning the entry of john.doe, if
i do a:
>$ ldapsearch -v -h ldap_srv -p 389 -s sub -z 2 -l 15 -D auth_dn -w pass_dn
-b "DC=domain,DC=com" "(sAMAccountName=john.doe)" sAMAccountName
:: for info
>$ldapsearch -VV
ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.28 (Jul 4 2013 21:48:28) $
root(a)b1026.apple.com:
/private/var/tmp/OpenLDAP/OpenLDAP-208.5~1/clients/tools
(LDAP library: OpenLDAP 20428)
=========
But with a simple code (extract bellow), on the same machine as the
ldapsearch above, i'm unable to make it work.
....
struct timeval timeOut = {15,0}; /* 15 second connection timeout */
char *attrs[] = {"sAMAccountName", NULL};
if ( (ld = ldap_init( "ldap_srv", 389 )) == NULL ) {
return( 1 ); /* error */
}
/* Bind with credentials to the LDAP server. */
rc = ldap_simple_bind_s( ld, auth_dn, pass_dn );
if ( rc != LDAP_SUCCESS ) {
return( 1 ); /* error */
}
/* Search for the entry. */
fprintf(stderr, "ldap_simple_bind_s(): Entering...\n");
rc = ldap_search_ext_s( ld, "DC=domain,DC=com", LDAP_SCOPE_SUBTREE,
"(sAMAccountName=john.doe)", NULL, 0, NULL, NULL, &timeOut,
2, &result );
fprintf(stderr, "ldap_simple_bind_s(): after. rc=%d...\n", rc);
...
...
::::::
The ldap_init(), ldap_simple_bind_s(), both work correctly.
The call to:
ldap_search_ext_s( ld, "DC=domain,DC=com", ....
does never come back from the function call, i have waited for more than
one hour. I never get the 2nd fprintf(...)
Another point, should the ldap_search_ext_s() not return with an error
after the defined "timeOut" (in my case 15 seconds) ?
But, if i change the 2nd parameter (base dn) from: "DC=domain,DC=com" to
"OU=region_a,DC=domain,DC=com", it works fine, returning the entry for
john.doe in a few seconds.
As i need to check users inside all of the "regions", i can't have the
OU=region on the base search, because if i use it with
OU=region_a,dc=domain,dc=com i'm not able to find the users from region_b,
as expected :)
Any tips to help me figure out what i'm doing wrong?
Thanks
werner
9 years, 8 months
Re: LMDB - growing the database
by Nat!
I wanted to resurrect this thread:
>>
>> Hi,
>>
>> I understand that the DB size has an upper limit set by the call to
>> mdb_env_set_mapsize . I wonder what is the best strategy for growing the size.
>>
> The best strategy is to initially pick a large enough size that growing it is never an issue. E.g., set it to the amount of free space on the disk partition where the DB resides. As the docs state, when the DB is actually in use, there's no guarantee that there will be enough free system resources left for a resize attempt to even succeed. I.e., if you initially choose a small size, by the time you need to deal with it it may be too late.
>
>
I have a problem with the "best strategy" because at least on OS X, the reserved file size of "data.mdb" is just the amount set by mdb_env_set_mapsize. Clearly reserving the amount of free space in my user partition would not be desirable, especially if I want to run more than just one lmdb based program.
So I tried to grow my db progressively, by setting mdb_env_set_mapsize first to a small value and the enlarging it. Unfortunately it seems, that whenever I increase the env_mapsize, all the committed data is lost and I start with a clean database (determined by mdb_stat).
So what gives ? The only thing I have come up with is, that I would need to copy the old database(s) into the new one with a cursor, but that sounds lame.
Ciao
Nat!
---------------------------------------------------
Tradition is an easy alternative to thinking what
to do. -- J. Watkinson
9 years, 9 months
replication delay problem
by Cyril Grosjean
I use a couple of OpenLDAP 2.4.36 servers in a multi-master replication setup.
Write operations are sent to a single server, and then replicated to the
second one.
I sometimes have write operations "peaks" of about 900 operations
(modifications of the pwdFailureTime attribute mainly) per hour.
The number of bind failures per user is neither limited nor reset yet and I
especially noticed a script that connects to the directory with the
same service account and (wrong) password. So, until this script is
modified with the right password (which will take time, unfortunately),
it can generate tons of failures, and thus tons of replications.
I noticed a several minutes replication delay between the directories, at
peak time, when comparing the contextCSN attributes.
It looks to me a big delay with regards to the number of modifications.
Anything I could do to limit that delay ?
9 years, 9 months
