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
6 years, 9 months
Re: (ITS#6666) Feature Request: Triggers implementation
by Buchan Milne
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
11 years, 10 months
memberof/accesslog overlays together
by Michael Ströder
HI!
Unfortunately for privacy reasons I can't provide example data.
I'm using slapo-memberof, slapo-refint and slapo-access in exactly this order.
Now I'm analysing some strange things where modifications to group entries and
the subsequent modifications by slapo-memberof are not correctly written to
the accesslog DB.
Questions:
1. Is this overlay order a correct setup? Should this work? Or should
slapo-memberof be invoked after slapo-access?
2. CHANGES of release 2.4.24 lists a bunch of fixes to slapo-memberof. Any
changes which possibly affect writing to accesslog DB? (I'm not sure whether
we had problems like this with 2.4.23 or not though.)
Ciao, Michael.
11 years, 11 months
AD sporadically gives LDAP_SERVER_DOWN after the first request
by Markus Sander
My employer ships software for Linux and other Unix-like OSes that binds
to Active Directory in order to, basically, integrate it to AD.
Functionally, it is not too dissimilar to pam_krb5 and nss_ldap.
OpenLDAP 2.4.18 is used to bind to Active Directory LDAP servers.
Authentication (to a machine trust account) is done using a Kerberos
keytab. MIT Kerberos is used.
Group membership data are stored in LDAP objects of class Group which
have the `member' attribute (multiply) filled with the DN of all
members. Those DNs are of type Group or of type User (I'm just chasing
users for now), and their `sAMAccountName' value is what I need to give
to NSS as the group member's name.
My procedure is as follows: First, I bind to one of several configured
LDAP servers using SASL2/GSSAPI, i.e. Kerberos 5. Then I inquire all of
the result set's `member' attributes and resolve the resulting DNs one
by one to build a DN => sAMAccountName map in memory (that's about 10k
entries, so, not a problem here). Then, I request the actual group
entries and look up the DNs in the `member' attribute in the map. Last,
the connection is terminated.
The group members' `sAMAccountName' is inquired one by one with the base
set to the DN (which I already know), the scope set to flat, and the
filter set to (objectClass=*). So that's about 10k single queries in
quick succession. The whole group query typically takes about 6 seconds.
The problem is: OpenLDAP sometimes gives me LDAP_SERVER_DOWN during the
`sAMAccountName' queries. This occurs sporadically but then typically
for the rest of the `sAMAccountName' queries. The group entry query that
follows does succeed. Most of the time the first of those errors
immediately follows a GSSAPI error, nameley, DES key is a weak key,
which may be true but appears unrelated, since only AES512, AES256 and
HMAC are used in the keytab.
The customer's DC admins say that the DCs are not at fault. We asked
them to try to increase the server limits (such as max number of active
queries per worker thread, which defaults to 4 or something), since
about 2k client workstations molest 4 DCs every 30 minutes with the
mentioned query (and others). They are very reluctant to do that and we
have trouble replicating the problem in-house anyway, so overload need
not be the root cause. The DC logs reportedly show nothing unusual.
My software has been in use for about three months now, but the rollout
was still on-going until lately. Customer acceptance tests did not
report the problem. The first incident has been reported about two weeks
ago. They set up monitoring and the bell now rings every couple of
minutes somewhere. Most queries still get through without problem,
though. Other queries, such as those for Netgroups, do not seem to have
any problem. They also doubled the number of DCs (to four) four weeks
ago, since the two they had were quite busy. The new DCs are similar in
hardware but are significantly less under load, which seems odd since
all four of those DCs exist just to serve our software and our software
can be shown to distribute the queries fairly. Restricting our software
to only the old or only the new DCs does not have any effect on the
failure rate.
I increased the OpenLDAP log level, but nothing enlightening turned up.
What could be the cause of the failures during the group member resolution?
11 years, 11 months
Using memberOf overlay with groups that contain uids, not DNs
by Oliver Beattie
Hi,
I realise the documentation for slapo-memberof indicate that this isn't
possible, but I thought it worthwhile asking here anyway — is it possible to
use the memberOf overlay with groups that use memberUid as their membership
attributes, rather than user DNs?
We have a large existing LDAP database that has thousands of groups like
this, and would very much like to use slapo-memberof.
Any pointers (positive or negative) much appreciated — just so I know for
definite.
—Oliver
11 years, 11 months
Dealing with BDB Crash
by ldap＠mm.st
A while ago I posted that we were having what we thought were random bdb
backend crashes with the following in our log:
bdb(o=example.com): PANIC: fatal region error detected; run recovery.
This was on a on our RH5 openldap servers (2.3.43) that we were
rebuilding:
It appears that the crashes were caused by a vulnerability scanner that
was hitting the server (still testing), even though it was suppose to be
safe. We'll have to investigate what is causing it, maybe we will need
an acl to stop whatever the scanner is doing. Once we stopped the
automated scan, the servers seem to be running as expected.
But, this brought up another issue. When the bdb backend failed, the
slapd process continued run and listen on the ldap ports and clients
still tried to connect to the failed server for authentication. The
server accepted and established the connection with the client. Of
course the client could not authenticate since the backend db was down.
The client will not fail over to the other server that is listed in it's
ldap.conf file since it thinks it has a valid connection. If the slap
process is not running then the fail over works fine since no ports are
there for the client to connect to.
I'm thinking that bdb failures will be rare once we solve the scanner
issue, but on a network that relies heavily on ldap, a failed bdb
backend with a running slapd would cause significant issues.
Just trying to restart the slapd service doesn't fix the issue, a manual
recovery is required (slapd_db_recover). I was curious if anyone has
put something in place to deal with this potential issue? Maybe run
slapd_db_status via cron and if it errors due a bdb corruption, just
stop slapd and let the admin know. At least the clients would be able
to failover to the other ldap servers. I guess an automated recovery is
possible via a script, but I'm not sure if that's a good idea. Maybe
dealing with this type of failure is not really required, I was hoping
that some of you that have been do this for a while would have some
insight.
11 years, 11 months
issue with slapadd
by Judith Flo Gaya
Hello,
I'm using openldap-server 2.4.19-15 in a Red Hat 6 box (x86_64), rpm
installation.
This is the very first time I use ldap and I'm having some issues with
the configuration.
I read that the slapd.conf file should not be use, instead the slapd.d
directory is the new system that is meant to be.
As I don't know how this exactly works, I've been reading and folowing
the tutorial in the openldap page. Specifically I read the
Administration guide and I copy and adapt the config.ldif file to suit
my needs.
After a while I manage to run the command:
slapadd -F /etc/openldap/slapd.d -n 0 -l config.ldif
with no problems. I thought that once this was done the slapd should
start smoothly, but instead I'm having an slaptest error saying that my
configuration FILE is wrong. As the slapd.conf doesn't exists, I don't
know where this error comes from. I tried
#slaptest -v -d1 -F ../slapd.d/
[......]
ldif_back_add: "olcDatabase={-1}frontend,cn=config"
oc_check_required entry (olcDatabase={-1}frontend,cn=config),
objectClass "olcDatabaseConfig"
oc_check_required entry (olcDatabase={-1}frontend,cn=config),
objectClass "olcFrontendConfig"
oc_check_allowed type "objectClass"
oc_check_allowed type "olcDatabase"
oc_check_allowed type "olcAddContentAcl"
oc_check_allowed type "olcLastMod"
oc_check_allowed type "olcMaxDerefDepth"
oc_check_allowed type "olcReadOnly"
oc_check_allowed type "olcMonitoring"
oc_check_allowed type "structuralObjectClass"
oc_check_allowed type "entryUUID"
oc_check_allowed type "creatorsName"
oc_check_allowed type "createTimestamp"
oc_check_allowed type "entryCSN"
oc_check_allowed type "modifiersName"
oc_check_allowed type "modifyTimestamp"
ldif_back_add: err: 68 text:
send_ldap_result: conn=-1 op=0 p=0
slaptest: bad configuration directory!
Since the directory structure was built by the slapadd command, where is
the problem?
I'm sure I'm doing something wrong but I can't find it ;(
Permissions are ok (at the beginning I had issues with the include
core.ldif part of my config.ldif, I ended pasting the contents in the
config.ldif)
Thanks in advance for your help, hope you can shed some light on this.
j
--
Judith Flo Gaya
Systems Administrator IMPPC
e-mail: jflo(a)imppc.org
Tel (+34) 93 554-3079
Fax (+34) 93 465-1472
Institut de Medicina Predictiva i Personalitzada del Càncer
Crta Can Ruti, Camí de les Escoles s/n
08916 Badalona, Barcelona,
Spain
http://www.imppc.org
11 years, 11 months
importing ldap database for a BDC
by deconya
Hi list
Im preparing a BDC server using samba with ldap and I start to import the
database. At first I commented and error with the suffix but not was the
last of my problems, Im importing and appears:
<= str2entry: str2ad(sambaLogonTime): attribute type undefined
slapadd: could not parse entry (line=81)
_ 0.09% eta 01m elapsed none spd 64.8
k/s
Closing DB...
What Im making bad?
First I copied all inside /etc/ldap/schema/ to the BDC, and I prepared with
slapcat a bckup from PDC. I installed samba and copied smb.conf modifying
the role. When I go to execute the slapadd -l backup.ldif appears the error.
Any idea?
Thanks And Best Regards
11 years, 11 months
Re: 8 principal limitation in openldap
by Srivatsav M
Hi,
I was triaging this issue and I ran into another mysterious area, it doesn't
look like the number (8) of principals/RDN is the problem and infact the
length/size of the RDN's could be the issue. Please find the /etc/ldap.conf
files attached renamed according to the AD/openldap server being configured.
a. In the ad_ldap_conf_size the number of characters is around 3137 for the
nss_base_<map>. On line 122, if i just make the 80 as 8 in the end of the
string, the command "getent passwd" is working and it lists all the users
registered in the ldap.conf file but otherwise it doesn't show any user.
b. In the open_ldap_conf_size_issue the number of characters is around 3103
for the nss_base_<map>. In the end of the file if i just comment the last
two lines, the "getent passwd" is working and it lists all the users
registered in the ldap.conf file but otherwise it doesn't show any user.
from these findings this looks more like some buffer issue, can you please
help me with the following.
1. Any particular method/file that I should be looking for to check this
buffer size may be even in the nss_ldap library or so
2. If there is a buffer size issue of say around 3137 characters (bytes for
that), what would be the best value to increase it.
appreciate any help
Thanks
Ramakanth
On 30 March 2011 01:17, Srivatsav M <srivatsav.mudumba(a)gmail.com> wrote:
> Please find below the answers to your questions:
>
> 1. > >> We are using OpenLDAP for authenticating users registered in a LDAP
>
> > >> server (Open LDAP, Active Directory).
>
> Which one? Or both?
>
> Our dev environment has openLDAP and AD servers and we have tested this issue against each of them individually and are able to reproduce it against both the types of LDAP servers
>
> 2. Users shouldn't be "registered in the /etc/ldap.conf file".
> >> Can you please help me understand why I shouldn't be using this in the
> ldap.conf file?
>
> 3. Please supply a full copy of your /etc/ldap.conf, or at least a
> representative one, and provide the example output of 'getent passwd
> username' and 'groups
>
> >> attached along with this mail
>
> username' for the user who doesn't authenticate. You may also want to supply
> the relevant PAM configuration files.
>
> $ getent passwd
> root <xxxxxxxxx>
> test_user:somepwd:1002:1002:Test User:/home/testuser:/bin/bash
> test_people1:*:10004:10004:Test People1:/home/test_people1:/bin/bash
>
> >> All external users are not able to login after adding the 8th principal/RDN
>
> /etc/pam.d/common-auth
>
> auth required pam_env.so
> auth sufficient pam_ldap.so use_first_pass
> auth required pam_unix2.so
>
> /etc/pam.d/common-account
>
> account required pam_unix2.so
> account sufficient pam_localuser.so
> account required pam_ldap.so use_first_pass
>
> /etc/pam.d/common-session
>
>
> session required pam_limits.so
> session required pam_unix2.so
> session required pam_mkhomedir.so skel=/etc/skel/
> session optional pam_ldap.so
> session optional pam_umask.so
>
> Also, please provide details of your LDAP client (distribution release, what versions of nss_ldap and pam_ldap you are running).
>
> >> openldap2-client-2.3.32-0.25
> >> nss_ldap-259-4.3
>
> 4. Do we know what the actual problem is? Do we know it would be solved by
> nss-ldapd?
>
> There might be a simple misunderstanding here, or a simple configuration problem, and switching software might not solve that.
>
> Additionally, the distribution in question may have a different preferred LDAP client.
>
> >> based on the above information, would it be possible for pointing any config. issues? , please do let me know if you need any further information.
>
> thanks
>
> Ramakanth
>
>
> On 25 March 2011 20:23, Marco Pizzoli <marco.pizzoli(a)gmail.com> wrote:
>
>> Hi,
>> I could be corrected if I'm wrong, but this problem is not related to
>> OpenLDAP. It's a nss_ldap problem.
>> nss_ldap is a client library that's used by linux vendors to achieves
>> seamless integration of users against *a* LDAP server.
>>
>> I had a similar problem with a complex configuration and bypassed (not
>> solved) the problem by modifying my client configuration.
>>
>> I reduced the number of ldap server configured to be accessed: from 4 to
>> 3.
>> I reduced the number of users defined in *nss_initgroups_ignoreusers*directive: i had about 40 listed in it...
>>
>> Etc...
>>
>> Make some tries and tell me if you can solve it.
>>
>> Marco
>>
>>
>>
>> On Thu, Mar 24, 2011 at 9:25 PM, Srivatsav M <srivatsav.mudumba(a)gmail.com
>> > wrote:
>>
>>> Hi,
>>>
>>> We are using OpenLDAP for authenticating users registered in a LDAP
>>> server (Open LDAP, Active Directory). After adding 8 principals
>>> (/etc/ldap.conf), none of the users registered in the /etc/ldap.conf file
>>> are able to login.
>>>
>>> nss_base_passwd
>>> OU=engg,DC=mycompany,DC=region,DC=someplace,DC=myarea,DC=compname,DC=parentcompname
>>> nss_base_shadow
>>> OU=engg,DC=mycompany,DC=region,DC=someplace,DC=myarea,DC=compname,DC=parentcompname
>>> nss_base_group
>>> OU=engg,DC=mycompany,DC=region,DC=someplace,DC=myarea,DC=compname,DC=parentcompname
>>>
>>>
>>> Can you please share the reason for this 7 limitation in the open ldap
>>> library. or how I can fix this issue. I am looking i for the header file in
>>> the source files whhich has this constant or limitation defined.
>>>
>>> Tried googling, but it appears that no one has encountered this issue.
>>> Some customers are running into this issue and it has become a severity 1
>>> issue to fix.
>>>
>>> Thanks
>>> Ramakanth
>>>
>>
>>
>>
>> --
>> _________________________________________
>> Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi.
>> Jim Morrison
>>
>
>
11 years, 12 months
