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
Certificate authentication and back-ldap proxy
by Ubay Dorta Guerra
Hi,
We have some problems with certificate authentication when the master
server is behind a back-ldap proxy.
We have openldap 2.4.21 on Suse Linux Enterprise Server 10 SP3 and
these are the details of our scenario:
The master server: server1.example.com has the following slapd.conf file:
access to dn.base=""
by * read
access to dn.base="cn=Subschema"
by * read
access to attrs=userPassword,userPKCS12
by self write
by dn.exact="CN=admin_w_cert,O=Internet Widgits Pty
Ltd,ST=Some-State,C=AU" read
by *
auth
access to attrs=shadowLastChange
by self write
by * read
access to *
by * read
#
# Security SSL
#
TLSCipherSuite HIGH:MEDIUM:+SSLv3
TLSCertificateFile /etc/ssl/certs/server1.example.com.pem
TLSCertificateKeyFile /etc/ssl/private/server1.example.com.key
TLSCACertificatePath /etc/ssl/cacerts/
TLSVerifyClient demand
#
#Log level
#
loglevel 256
# Require authentication
require authc
#######################################################################
# HDB database definitions
#######################################################################
database hdb
suffix "dc=example,dc=com"
checkpoint 1024 5
cachesize 10000
rootdn "cn=Manager,dc=example,dc=com"
rootpw secret
# Indices to maintain
index objectClass eq
# Overlay ppolicy
overlay ppolicy
----------------------
Authentication is required, and we give access to the user passwords
for the dn of a certificate.
When we search for passwords using the certificate we get the following:
root# ldapsearch -LLL -b 'uid=user_w_pass,ou=people,dc=example,dc=com'
-H ldaps://server1.example.com userPassword
SASL/EXTERNAL authentication started
SASL username: CN=admin_w_cert,O=Internet Widgits Pty Ltd,ST=Some-State,C=AU
SASL SSF: 0
dn: uid=user_w_pass,ou=people,dc=example,dc=com
userPassword:: e2NyeXB0fTcyMXpQbU4waWdKaU0=
-----------------------
The root user (ldap client) has a ~/.ldaprc file with:
TLS_CACERTDIR /etc/ssl/cacerts/
TLS_CERT /etc/ssl/certs/admin_w_cert.pem
TLS_KEY /etc/ssl/private/admin_w_cert.key
TLS_REQCERT demand
SASL_MECH EXTERNAL
In /var/log/messages we get:
ldap-master[22358]: conn=1000 fd=11 ACCEPT from
IP=server1.example.com:40899 (IP=server1.example.com:636)
ldap-master[22358]: conn=1000 fd=11 TLS established tls_ssf=256 ssf=256
ldap-master[22358]: conn=1000 op=0 BIND dn="" method=163
ldap-master[22358]: conn=1000 op=0 BIND
authcid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
authzid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
ldap-master[22358]: conn=1000 op=0 BIND dn="cn=admin_w_cert,o=internet
widgits pty ltd,st=some-state,c=au" mech=EXTERNAL sasl_ssf=0 ssf=256
ldap-master[22358]: conn=1000 op=0 RESULT tag=97 err=0 text=
ldap-master[22358]: conn=1000 op=1 SRCH
base="uid=user_w_pass,ou=people,dc=example,dc=com" scope=2 deref=0
filter="(objectClass=*)"
ldap-master[22358]: conn=1000 op=1 SRCH attr=userPassword
ldap-master[22358]: conn=1000 op=1 SEARCH RESULT tag=101 err=0
nentries=1 text=
ldap-master[22358]: conn=1000 op=2 UNBIND
ldap-master[22358]: conn=1000 fd=11 closed
This is the correct behavior for us. The problem appears when we
introduce a back-ldap proxy between the client and the master.
The proxy server (proxy-server1.example.com) is listening in port
1636 and its slapd.conf file is:
#
# Security SSL
#
TLSCipherSuite HIGH:MEDIUM:+SSLv3
TLSCACertificatePath /etc/ssl/cacerts/
TLSCertificateFile /etc/ssl/certs/proxy-server1.example.com.pem
TLSCertificateKeyFile /etc/ssl/private/proxy-server1.example.com.key
TLSVerifyClient demand
# Log level
loglevel 256
#######################################################################
# Database definitions
#######################################################################
database ldap
rebind-as-user true
suffix "dc=example,dc=com"
uri "ldaps://server1.example.com"
tls ldaps
tls_cert=/etc/ssl/certs/proxy-server1.example.com.pem
tls_key=/etc/ssl/private/proxy-server1.example.com.key
tls_cacertdir=/etc/ssl/cacerts/
----------------------
If we search for passwords through the proxy we get:
root # ldapsearch -LLL -b 'uid=user_w_pass,ou=people,dc=example,dc=com'
-H ldaps://proxy-server1.example.com:1636 userPassword
SASL/EXTERNAL authentication started
SASL username: CN=admin_w_cert,O=Internet Widgits Pty Ltd,ST=Some-State,C=AU
SASL SSF: 0
Server is unwilling to perform (53)
Additional information: authentication required
In the /var/log/messages the following messages appear:
ldap-proxy[22802]: conn=1001 fd=8 ACCEPT from
IP=proxy-server1.example.com:60712 (IP=proxy-server1.example.com:1636)
ldap-proxy[22802]: conn=1001 fd=8 TLS established tls_ssf=256 ssf=256
ldap-proxy[22802]: conn=1001 op=0 BIND dn="" method=163
ldap-proxy[22802]: conn=1001 op=0 BIND
authcid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
authzid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
ldap-proxy[22802]: conn=1001 op=0 BIND dn="cn=admin_w_cert,o=internet
widgits pty ltd,st=some-state,c=au" mech=EXTERNAL sasl_ssf=0 ssf=256
ldap-proxy[22802]: conn=1001 op=0 RESULT tag=97 err=0 text=
ldap-proxy[22802]: conn=1001 op=1 SRCH
base="uid=user_w_pass,ou=people,dc=example,dc=com" scope=2 deref=0
filter="(objectClass=*)"
ldap-proxy[22802]: conn=1001 op=1 SRCH attr=userPassword
ldap-master[22358]: conn=1008 op=2 SRCH
base="uid=user_w_pass,ou=people,dc=example,dc=com" scope=2 deref=0
filter="(objectClass=*)"
ldap-master[22358]: conn=1008 op=2 SRCH attr=userPassword
ldap-master[22358]: conn=1008 op=2 SEARCH RESULT tag=101 err=53
nentries=0 text=authentication required
ldap-proxy[22802]: conn=1001 op=1 SEARCH RESULT tag=101 err=53
nentries=0 text=authentication required
ldap-proxy[22802]: conn=1001 op=2 UNBIND
ldap-proxy[22802]: conn=1001 fd=8 closed
The /root/.ldaprc file is the same than the previous one.
When we increase the logging level we discover this:
....
ldap-proxy[23008]: conn=1000 op=0 do_bind
ldap-proxy[23008]: >>> dnPrettyNormal: <>
ldap-proxy[23008]: <<< dnPrettyNormal: <>, <>
ldap-proxy[23008]: conn=1000 op=0 BIND dn="" method=163
ldap-proxy[23008]: do_bind: dn () SASL mech EXTERNAL
ldap-proxy[23008]: ==> sasl_bind: dn="" mech=EXTERNAL datalen=0
ldap-proxy[23008]: SASL Canonicalize [conn=1000]:
authcid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
ldap-proxy[23008]: slap_sasl_getdn: conn 1000
id=cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au [len=61]
ldap-proxy[23008]: ==>slap_sasl2dn: converting SASL name
cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au to a DN
ldap-proxy[23008]: <==slap_sasl2dn: Converted SASL name to <nothing>
ldap-proxy[23008]: SASL Canonicalize [conn=1000]:
slapAuthcDN="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
ldap-proxy[23008]: SASL proxy authorize [conn=1000]:
authcid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
authzid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
ldap-proxy[23008]: conn=1000 op=0 BIND
authcid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
authzid="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
ldap-proxy[23008]: SASL Authorize [conn=1000]: proxy authorization
allowed authzDN=""
ldap-proxy[23008]: send_ldap_sasl: err=0 len=-1
ldap-proxy[23008]: conn=1000 op=0 BIND dn="cn=admin_w_cert,o=internet
widgits pty ltd,st=some-state,c=au" mech=EXTERNAL sasl_ssf=0 ssf=256
ldap-proxy[23008]: do_bind: SASL/EXTERNAL bind:
dn="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
sasl_ssf=0
ldap-proxy[23008]: send_ldap_response: msgid=1 tag=97 err=0
ldap-proxy[23008]: conn=1000 op=0 RESULT tag=97 err=0 text=
ldap-proxy[23008]: <== slap_sasl_bind: rc=0
....
ldap-proxy[23008]: conn=1000 op=1 SRCH
base="uid=user_w_pass,ou=people,dc=example,dc=com" scope=2 deref=0
filter="(objectClass=*)"
ldap-proxy[23008]: conn=1000 op=1 SRCH attr=userPassword
ldap-proxy[23008]: ==> limits_get: conn=1000 op=1
self="cn=admin_w_cert,o=internet widgits pty ltd,st=some-state,c=au"
this="uid=user_w_pass,ou=people,dc=example,dc=com"
ldap-master[22983]: daemon: activity on 1 descriptor
ldap-master[22983]: daemon: activity on:
ldap-master[22983]:
ldap-master[22983]: slap_listener_activate(7):
ldap-master[22983]: daemon: epoll: listen=7 busy
ldap-master[22983]: >>> slap_listener(ldaps://server1.example.com)
.....
ldap-master[22983]: conn=1000 op=0 do_bind
ldap-master[22983]: >>> dnPrettyNormal: <>
ldap-master[22983]: <<< dnPrettyNormal: <>, <>
ldap-master[22983]: conn=1000 op=0 BIND dn="" method=128
ldap-master[22983]: do_bind: version=3 dn="" method=128
ldap-master[22983]: send_ldap_result: conn=1000 op=0 p=3
ldap-master[22983]: send_ldap_result: err=0 matched="" text=""
ldap-master[22983]: send_ldap_response: msgid=1 tag=97 err=0
ldap-master[22983]: conn=1000 op=0 RESULT tag=97 err=0 text=
ldap-master[22983]: do_bind: v3 anonymous bind
----------------
Therefore the proxy is binding anonymously in the master, instead of
using the dn of the certificate.
Is there any problem with the SASL EXTERNAL method?
If we use SIMPLE authentication through the proxy, there is no problem:
root # ldapsearch -LLL -x -b
'uid=user_w_pass,ou=people,dc=example,dc=com' -H
ldaps://proxy-server1.example.com:1636 -D
'uid=user_w_pass,ou=people,dc=example,dc=com' -W userPassword
Enter LDAP Password:
dn: uid=user_w_pass,ou=people,dc=example,dc=com
userPassword:: e2NyeXB0fTcyMXpQbU4waWdKaU0=
Thanks in advance.
---------------------------------------------------------------------------------------------
ADVERTENCIA: Sobre la privacidad y cumplimiento de la Ley de Protección de Datos, acceda a http://www.iac.es/disclaimer.php
WARNING: For more information on privacy and fulfilment of the Law concerning the Protection of Data, consult http://www.iac.es/disclaimer.php?lang=en
12 years, 2 months
AIX as openldap client
by Stef Coene
Hi,
Some time ago, I configured an ubuntu intrepid as openldap server and I was
able to use it as authentication server for AIX 6.1.
I tried the same with an ubuntu maverick server, but I can not get it working
anymore. I can see all the user information on the AIX server. I can do 'su
- <user>' to become the user. But I can not login so I think there is a
problem with the password.
When I change the password of a user on the AIX server, I get these errors in
the logfile on the openldap server:
Oct 26 20:44:12 ldap1 slapd[28664]: Entry (uid=xxx,ou=people,dc=xxx,dc=xxx),
attribute 'shadowLastChange' not allowed
Oct 26 20:44:12 ldap1 slapd[28664]: entry failed schema check: attribute
'shadowLastChange' not allowed
Is this important?
The intrepid has version 2.4.11-0ubuntu6.2, the maverick has version
2.4.21-0ubuntu5.3.
I didn't noted down what I did on the intrepid server, but I can remember that
it asked a bunch of questions when I installed slapd. These initial steps are
removed from the maverick version. I also remember using the ldapinit
command.
How can I debug the difference between these 2 versions?
Using slapcat, I can see some differeces, but nothing that is important in my
opinion.
How can I debug the openldap server to see what's going on?
I can use the openldap server on a linux ldap client without problems.
Stef
PS I also tried to post this message to openldap-software(a)openldap.org, but I
got a 'Delivery status notification' saying that the user does not exist.
12 years, 4 months
Asynchronicity
by William Ahern
Excepting DNS, is the latest release of OpenLDAP fully asynchronous-capable,
even with TLS? Perusing the source code I can't find any obvious places
other than DNS where things might block, but it's harder to prove the
negative.
I remember many years ago this wasn't the case, and I had to thread the
connect phase, but the ChangeLog suggests that things have changed
considerably.
12 years, 4 months
uniqueMember attribute is not suffixmassaged if attribute is not mapped and changed
by Arvo Jari-Pekka
Hi.
My configuration is like this:
---------
database meta
suffix "ou=a,dc=c,dc=b"
uri "ldap://host:port/ou=a,dc=c,dc=b"
suffixmassage "ou=a,dc=c,dc=b" "dc=a,dc=b"
...
---------
This works fine in everything else but the uniqueMembers of groupOfUniqueNames gets not rewritten (they are still in dc=a,dc=b domain).
If I however add a mapping
---------
map objectClass groupOfNames groupOfUniqueNames
map attribute member uniqueMember
---------
then the "member" attributes are correctly rewritten. The problem of course is that I do not want to change the objectclass.
Mapping the attribute to itself does not help either. So
---------
map objectClass groupOfUniqueNames *
map attribute uniqueMember *
---------
does not have any effect.
I must have missed something crucial on the documentation. Can someone please tell me what it is and how can I get uniqueMembers rewritten without changing the objectclass.
OpenLDAP version is 2.4.11 for both the real and the meta server.
BR,
Jari-Pekka Arvo
12 years, 4 months
Re: Error 18: Solaris 10 Native LDAP-Client
by Benjamin Griese
Correction:
-w <passwd> or -w - instead of -W
On Thu, Oct 28, 2010 at 15:02, Benjamin Griese <der.darude(a)gmail.com> wrote:
> Hello Günther,
>
> sorry for my late reply, I hate sun cluster panics after patching
> those beasts. :(
>
> Here is the content of solaris_profile:
>
> dn: cn=solaris_profile,ou=profile,dc=example,dc=de
> objectClass: DUAConfigProfile
> objectClass: top
> cn: solaris_profile
> authenticationMethod: simple
> bindTimeLimit: 10
> credentialLevel: proxy
> defaultSearchBase: dc=example,dc=de
> defaultSearchScope: sub
> defaultServerList: exampleldap01 exampleldap02 (syncrepl, configured
> to mirrormode)
> followReferrals: FALSE
> profileTTL: 3600
> searchTimeLimit: 30
> serviceSearchDescriptor: sudoers:ou=SUDOers,dc=example,dc=de?sub
> serviceSearchDescriptor: group:ou=groups,dc=example,dc=de?sub
> serviceSearchDescriptor: passwd:ou=people,dc=example,dc=de?sub
>
>
> Regarding to the sorting I found this in man ldapsearch:
>
> "-F sep
>
> Use sep as the field separator between attribute names
> and values. If this option has been specified, the -L
> option is ignored.
>
>
> -S [-]attribute
>
> Specify an attribute for sorting the entries returned by
> the search. The sort criteria is alphabetical on the
> attribute's value or reverse alphabetical with the form
> -attribute. You can give multiple -S options to refine
> the sorting, For example:
>
> -S sn -S givenname
>
> By default, the entries are not sorted. Use the -x
> option to perform server-side sorting."
>
> If I use -x for server side sorting, I get the complete list of
> uid-Objects, but not sorted in any obvious way:
> # ldapsearch -v -x -b dc=example,dc=de -h exampleldap01 -D
> cn=proxyuser,ou=system,ou=people,dc=example,dc=de -W '(uid=*)'
>
> ldapsearch: started Thu Oct 28 12:16:49 2010
> ldap_init( exampleldap01, 389 )
> filter pattern: (uid=*)
> returning: ALL
> filter is: (uid=*)
> version: 1
>
> If I use this string I get the complete list of uid-objects sorted by uidNumber
> # ldapsearch -v -S uidnumber -b dc=example,dc=de -h exampleldap01 -D
> cn=proxyuser,ou=system,ou=people,dc=example,dc=de -W '(uid=*)'
>
> ldapsearch: started Thu Oct 28 12:37:11 2010
> ldap_init( exampleldap01, 389 )
> filter pattern: (uid=*)
> returning: ALL
> filter is: (uid=*)
> version: 1
>
> If I try to search with -x and -S uidnumber I get the same message
> that appears in the OpenLDAP logfile:
> # ldapsearch -v -x -S uidNumber -b dc=example,dc=de -h exampleldap01
> -D cn=proxyuser,ou=system,ou=people,dc=example,dc=de -W '(uid=*)'
>
> ldapsearch: started Thu Oct 28 12:25:50 2010
> ldap_init( exampleldap01, 389 )
> filter pattern: (uid=*)
> returning: ALL
> filter is: (uid=*)
> ldap_search: Inappropriate matching
> ldap_search: additional info: serverSort control: No ordering rule
> ldap_parse_sort_control: Requested LDAP control not found
>
> Finally I still have no clue how to prevent the client from doing
> these kinds of searches.
> And I couldn't find any templates regarding the ldapclient on my test machine.
>
> Any other clues or ideas?
>
> Bye, Benjamin.
>
> On Sat, Oct 23, 2010 at 19:17, Dieter Kluenter <dieter(a)dkluenter.de> wrote:
>> Benjamin Griese <der.darude(a)gmail.com> writes:
>>
>>> Hey thanks for quick reply,
>>>
>>> I put the config of the ldapclient on the ML some days ago,
>>> but I can't figure out how I may have set such a rule on client side.
>>> Probably it is something hardcoded.
>>>
>>> ldapclient config:
>>> NS_LDAP_FILE_VERSION= 2.0
>>> NS_LDAP_BINDDN= cn=proxyuser,ou=system,ou=people,dc=example,dc=de
>>> NS_LDAP_BINDPASSWD= secret
>>> NS_LDAP_SERVERS= ldap01
>>> NS_LDAP_SEARCH_BASEDN= dc=example,dc=de
>>> NS_LDAP_AUTH= simple
>>> NS_LDAP_SEARCH_REF= FALSE
>>> NS_LDAP_SEARCH_SCOPE= sub
>>> NS_LDAP_SEARCH_TIME= 30
>>> NS_LDAP_CACHETTL= 60
>>> NS_LDAP_PROFILE= solaris_profile
>>> NS_LDAP_CREDENTIAL_LEVEL= proxy
>>> NS_LDAP_SERVICE_SEARCH_DESC= passwd: ou=people,dc=example,dc=de?sub
>>> NS_LDAP_SERVICE_SEARCH_DESC= group: ou=groups,dc=example,dc=de?sub
>>> NS_LDAP_SERVICE_SEARCH_DESC= sudoers: ou=SUDOers,dc=example,dc=de?sub
>>>
>>> That's all I setup, its like defaultest of the defaultest I guess :)
>>>
>>> And thanks for describing EQUALITY.
>>
>> I must admit I am not that familiar with old netscape tools, but the
>> openldap log ist quite clear, there is a request for a Server Side
>> Sorting extended operation, which in fact is quite unusual. You really
>> should check Solaris 10 setup for appropriate templates, i.e. what is
>> the content of solaris_profile? By the way, AFAIR the flag for sss is
>> -F so you may check any templates, Redhat provides these in
>> /usr/share/dirsrv, Solaris might be different.
>>
>> -Dieter
>>
>> --
>> Dieter Klünter | Systemberatung
>> sip: 7770535(a)sipgate.de
>> http://www.dpunkt.de/buecher/2104.html
>> GPG Key ID:8EF7B6C6
>>
>
>
>
> --
> To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To
> be is to do -- Sartre | Do be do be do -- Sinatra
>
--
To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To
be is to do -- Sartre | Do be do be do -- Sinatra
12 years, 4 months
LDAP filter question
by Antonio Batovanja
Hi,
I'm having problems finding documentation for range filters.
Can someone explain to me how to use a range filter on shadowExpire?
From nis.schema:
attributetype ( 1.3.6.1.1.1.1.10 NAME 'shadowExpire'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
so it's an integer value.
from my slapd.conf (openldap 2.3.38):
index shadowExpire pres,eq
I'd like to find entries where either shadowExpire is not present, or
shadowExpire is present and greater than or equal to X.
# ldapsearch -x '(&(objectclass=shadowaccount)(shadowexpire=*))' dn
returns 978 entries.
# ldapsearch -x '(&(objectclass=shadowaccount)(!(shadowexpire=*)))' dn
returns 311 entries.
But:
# ldapsearch -x '(&(objectclass=shadowaccount)(shadowexpire>1000))' dn
gives me ldap_search_ext: Bad search filter (-7)
and
# ldapsearch -x '(&(objectclass=shadowaccount)(shadowexpire>=1000))' dn
returns no results.
At least one entry has shadowExpire > 1000:
# ldapsearch -x -LLL uid=toni objectclass shadowexpire
dn: cn=Batovanja Antonio,ou=People,ou=EDV Zentrale,dc=humanomed,dc=at
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
objectClass: hmUserExtention
objectClass: organizationalPerson
shadowExpire: 20000
My final filter should be
(|(shadowExpire=0)(shadowExpire>=14910)(!(shadowExpire=*)))
but that's not working
What am I doing wrong?
Cheers,
Toni
12 years, 4 months
tag=97 error in openLDAP
by Tim Dunphy
Hello,
I recently had a "knowledgeable" friend work on my openldap server.
he made some
changes to the cofigs without backing them up and now users are unable
to authenticate against this openldap 2.4 server where previously they
could. I am running on FreeBSD 8.1. I am a student trying to learn and
be comfortable with openLDAP.
when a user ssh's to any machine on the network that is configured to
listen to this ldap server now gets an error in the LDAP logs:
Oct 29 22:49:41 LBSD2 slapd[1085]: <= bdb_equality_candidates: (uid) not indexed
Oct 29 22:49:41 LBSD2 slapd[1085]: conn=1001 op=7 SEARCH RESULT
tag=101 err=0 nentries=1 text=
Oct 29 22:49:41 LBSD2 slapd[1085]: conn=1002 op=4 BIND
dn="uid=bluethundr,ou=summitnjops,ou=staff,dc=summitnjhome,dc=com"
method=128
Oct 29 22:49:41 LBSD2 slapd[1085]: conn=1002 op=4 RESULT tag=97 err=49 text=
Oct 29 22:49:41 LBSD2 slapd[1085]: conn=1002 op=5 BIND dn="" method=128
Oct 29 22:49:41 LBSD2 slapd[1085]: conn=1002 op=5 RESULT tag=97 err=0 text=
it looks like it's failing to bind:
conn=1003 op=3 BIND dn="" method=128
and I think this error may be key but I am unsure of it's meaning:
tag=97
my ldap.conf reads as so:
host ldap.summitnjhome.com
base dc=summitnjhome,dc=com
scope sub
pam_password exop
nss_base_passwd ou=staff,dc=summitnjhome,dc=com
nss_base_shadow ou=staff,dc=summitnjhome,dc=com
sudoers_base ou=sudoers,ou=Services,dc=summitnjhome,dc=com
And why would the uid not be indexed?
and this is the user id in LDAP:
[root@LBSD2:/home/bluethundr/txt/ldif]#cat bluethundr.ldif
dn: uid=bluethundr,ou=summitnjops,ou=staff,dc=summitnjhome,dc=com
uid: bluethundr
cn: Timothy P.
givenName: Timothy P.
sn:
mail: bluethundr(a)blah.com
mailRoutingAddress: bluethundr(a)mail.blah.com
mailHost: mail.blah.com
objectClass: inetLocalMailRecipient
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
userPassword: {CRYPT}secret
loginShell: /usr/local/bin/bash
uidNumber: 1001
gidNumber: 1002
homeDirectory: /home/bluethundr
gecos: Timothy P.
and these are my ACL's in slapd.conf:
access to *
by read
access to attrs=userPassword by self write
by anonymous auth
access to * by self write
by dn.children="ou=summitnjops,ou=staff,dc=summitnjhome,dc=com"
write
by users read
by anonymous auth
access to * by self write
I would certainly appreciate any help to get this working again!
thank you
--
Here's my RSA Public key:
gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9
Share and enjoy!!
12 years, 4 months
Push-based syncrepl + slapo-rwm
by Raphael Ordinas
Hi,
I'd like to replicate with syncrepl a master directory and change the
naming context on the consumer.
I try setup a syncrepl push-based synchronization, with a proxy and
slapo-rwm overlay.
Here's what my config looks like :
MASTER LDAP (suffix : dc=suffix1,dc=com)
|
|
|
PROXY push-based syncrepl and slapo-rwm (rewrite "dc=suffix1,dc=com" to
"dc=suffix2,dc=com")
|
|
|
SLAVE (suffix : dc=suffix2,dc=com)
I can't get rewriting working on the proxy, data are pushed to my slave
directory with the suffix "dc=suffix1,dc=com".
So replication don't work because of different naming context.
PROXY's slapd.conf looks like this :
##############################
database ldap
hidden on
suffix "dc=suffix2,dc=com"
rootdn "cn=admin,dc=suffix2,dc=com"
uri ldap://slave/
lastmod on
restrict all
acl-bind
bindmethod=simple
binddn="cn=admin,dc=suffix2,dc=com"
credentials=secret
overlay rwm
rwm-rewriteEngine on
rwm-suffixmassage "dc=suffix2,dc=com" "dc=suffix1,dc=com"
overlay syncprov
syncrepl rid=001
provider=ldap://master/
binddn="cn=admin,dc=suffix2,dc=com"
bindmethod=simple
credentials=secret
searchbase="dc=suffix2,dc=com"
type=refreshAndPersist
retry="5 5 300 5"
##############################
What's wrong ?
Thank you for your help.
Regards
Raphael
12 years, 4 months
