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, 12 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.
7 years, 11 months
Data is not getting replicated correctly in multimaster configuration
by Gurjot Kaur
Hi,
I have configured two instances of LDAP in multimaster mode.
I am creating 100 members and wait for 5 seconds and then deleting those 100 members.
In case of creation the data is getting replicated correctly.
But in deletion, all the 100 members are getting deleted from primary, but not from secondary server.
As a result the data is inconsistent in both the instances.
Please give any suggestion.
Thanks and Regards,
Gurjot Kaur
Sofware Engineer
gurjot.kaur(a)aricent.com
[http://static.johnmcneilstudio.com/aricent/email_signature/aricent-footer...]
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
8 years
About RDN values starting with #
by Pofelski, Lech
Hello openLDAP gurus,
According to the RFC 4514, an RDN value may start with # and to be followed by a number of "hex pair" (pairs of hexadecimal values), representing octets of some binary value.
There are two use cases involving such RDN syntax:
· Case 1, where the RDN is of the form:
<attribute OID (called also as attribute desc in dotted form)>=#<BER encoded attribute value in form of a sequence of hex pairs >
· Case 2, where the RDN is of the form:
<attribute name>=#<attribute value in form of a sequence of hex pairs>
Case 1 is explicitly illustrated in the RFC 4514 by the example:
1.3.6.1.4.1.1466.0=#04024869
Although Case 2 is not explicitly illustrated in the RFC4514, it is implicitly correct, as it is in the conformity with the RDN syntax provided by this RFC.
The example of Case2 equivalent to the example of Case1 given in the RFC would be:
<name of the attribute with OID 1.3.6.1.4.1.1466.0>=#4869
I have tested using openLDAP 2.4.39 a number of cases involving RDNs starting with #, including an example very close to the example from the RFC.
The results show that:
· If RDN value is provided as e.g. string value, LDAP operations like add, search and delete work well
· If RDN value is provided as # prefixed hexadecimal value corresponding to the cases 1 and 2, none of this cases work and in all the cases I get the error "Invalid DN syntax"
The schema file, scripts used to run the test and the test results are in the attached zip file.
I would like to know:
· If you share our understanding of the problem and in particular our interpretation of the Case2, for which there is no explicit example in the RFC4514.
· If this is a known limitation in openLDAP.
· If there is already a plan to fix the problem. If not, I'd be glad to contribute to fixing it.
Thanks in advance for your answer.
Regards,
Lech POFELSKI
Lech POFELSKI,
Software Development Engineer
Hewlett-Packard Centre de Compétences France
5 Avenue Raymond Chanas
38320 Eybens - France
lech.pofelski(a)hp.com<mailto:lech.pofelski@hp.com>
8 years
HP-UX: mdb_txn_commit and MDB_WRITEMAP
by Kristian Amlie
We have enabled MDB_WRITEMAP on our HP-UX 11.23 Itanium after previous
discussions on the list, and that worked nicely for the most part.
However now we face a different issue: Occasionally, mdb_txn_commit will
return "Resource temporarily unavailable". I have not been able to
determine exactly which resource it's talking about; I suspected shared
memory limits, but raising this limit did not solve the problem. This
issue did not occur without MDB_WRITEMAP.
Any idea what else it could be? I can probably insert debug code into
LMDB if that's needed.
--
Kristian
8 years
RE24 testing call (2.4.41)
by Quanah Gibson-Mount
If you know how to build OpenLDAP manually, and would like to participate
in testing the next set of code for the 2.4.41 release, please do so.
Generally, get the code for RE24:
<http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs...>
Configure & build.
Execute the test suite (via make test) after it is built.
Thanks!
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
8 years
Significance of name forms.
by dE
Suppose a name form is attached to a structural object class. Then, when
referring to entries belonging to that object class (which has no DIT
Structure Rules associated to it), is using the MUST attributes as
defined in the name form to construct AVA still necessary?
No DIT Structure Rules refer to this name form.
8 years
getent passwd only catch local user passwd
by Yingbo Li
Hi,
I am new to LDAP. The company's IT own LDAP server, I tried to configure openldap client but failed. My OS is CentOS 7, openldap is 2.4.39.
I configured ldap and ldaps. I can use ldapsearch to find out full ldap info of my LDAP account. I configured with authconfig-tui. I also modified /etc/pam.d/system-auth and password-auth, change pam_sss.so to pam_ldap.so. While when I tried getent passwd, I can only find local users. I cannot su to my LDAP account. Why?
I google online it looks like CentOS 7 has problem to configure ldap client. Cent0S 7 does not have pam_ldap module. But I can find pam_ldap.so in the system. What should I do to fix it? Switch to CentOS 6.6?
Your help is really appreciated! Thank you!
Yingbo
8 years
Ldap challenge
by Ross, Daniel B.
Ok I have looked a couple options but I really dont know how to accomplish what I need to do.
Here is what I am trying to do.
I have a greater organization that is stuck on using Microsoft products namely Microsoft LDS. To make matters worse they present the data to my linux servers in a completely non-standard way. Its driving my solaris and linux box nuts and they simply dont want to work with it.
What i need to do is continue to use the campus usernames and passwords but present the Data in a format that my linux/unix hosts can use. Is this possible?
i.e. userid would still be samwise but instead of a bizzarre OU=monkeypeople,dc=example,dc=com I want it to present as people,dc=example,dc=com.
I looked at referral and aliasing but it does not seem to be doing what I am trying to do. Passthrough authentication looks close but I cant find sufficient documentation to actually configure a system to use it.
Thanks
Daniel
8 years
Re: modifying cn=config with ldapmodify
by Abdelhamid Meddeb
Hi,
In your ssl.ldif file there is a *blank* line too after changetype: modify
This is not reported in your first post but it apear in seconde one.
I have reproduced the same symptoms with this empty line
More details bellow
Cheers.
Le 29/04/2015 12:56, Robert Munn a écrit :
> My replies inline...
>
> On Apr 26, 2015, at 2:28 AM, Abdelhamid MEDDEB <abdelhamid(a)meddeb.net
> <mailto:abdelhamid@meddeb.net>> wrote:
>
>> Hi,
>>
>>
>> Le 25/04/2015 15:10, Robert Munn a écrit :
>>> I have been trying to replace the SSL cert settings on my OpenLDAP
>>> instance running on Ubuntu using ldapmodify.
>>>
>>>
>>> I followed directions on the Ubuntu wiki:
>>>
>>> https://help.ubuntu.com/lts/serverguide/openldap-server.html#openldap-tls
>>>
>>> using a modified ldif file for the replace:
>>>
>>> |dn: cn=config
>>> changetype: modify
>>> replace: olcTLSCACertificateFile
>>> olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem
>>> -
>>> replace: olcTLSCertificateFile
>>> olcTLSCertificateFile: /etc/ssl/certs/ldap01_slapd_cert.pem
>>> -
>>> replace: olcTLSCertificateKeyFile
>>> olcTLSCertificateKeyFile: /etc/ssl/private/ldap01_slapd_key.pem|
>> |All right|
Empty line is not reported here.
>>> When it didn’t work on my existing instance I built a new instance
>>> in a new Ubuntu VM (14.04) and tried the original directions from
>>> Ubuntu. That did not work either.
>> May be you've missed some settings at build time like --with-tls
>
> I installed OpenLDAP using apt. The .deb package must include TLS
> because I added the certificates manually.
>
>
>>>
>>> The ldapmodify command executes correctly but it seems that the
>>> change is not registered by the server. This is the case in both the
>>> new instance and the old instance of OpenLDAP.
>> No error message like "Insufficient access (50)" ? and you should
>> check the write (manage)rights to cn=config database.
>
> The command I ran (as sudo) and the message:
>
> ldapmodify -Y EXTERNAL -H ldapi:/// -f ssl.ldif
> SASL/EXTERNAL authentication started
> SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> SASL SSF: 0
> modifying entry "cn=config”
>
> and ssl.ldif :
>
> dn: cn=config
> changetype:modify
>
> replace: olcTLSCACertificateFile
> olcTLSCACertificateFile: /etc/ssl/certs/CAcert
> -
> replace: olcTLSCertificateFile
> olcTLSCertificateFile: /etc/ssl/certs/cert
> -
> replace: olcTLSCertificateKeyFile
> olcTLSCertificateKeyFile: /etc/ssl/private/cert.key
>
But we show it here, and content changes (strangely) the cn=config.ldif
last modified timestamp, but do nothing realy
> cn=config.ldif is being modified by the ldapmodify process, I verified
> that by changing file permissions on cn=config.ldif, running the
> ldapmodify command, and then checking cn=config.ldif. ldapmodify
> updated the timestamp and file permissions on the file. The file
> changed, but the configuration changes in ssl.ldif were not made in
> cn=config.ldif.
>
>
>>> I ended up replacing the values (or adding them in the new instance)
>>> in the /etc/ldap/slapd.d/cn=config.ldif file manually. Making the
>>> changes manually and restarting slapd works, but my understanding
>>> was that changes to cn=config should be made through ldapmodify.
>> Bad practice, it's best to avoid.
>
> Yes, and when I can modify the configuration using ldapmodify, I will
> no longer make the changes manually.
>
> I found a note about enabling logging using ldapmodify:
>
> https://help.ubuntu.com/lts/serverguide/openldap-server.html
>
> logging.ldif:
>
> dn: cn=config
> changetype: modify
> replace: olcLogLevel
> olcLogLevel: stats
>
> ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f logging.ldif
>
> I executed this command on my first instance and it added the logging
> to cn=config. I executed this command on the second instance, where
> olcLogLevel already existed, and it did not alter the log level.
>
> I have also been experimenting with this script:
>
> https://github.com/cepharum/slapd-config
>
> With it, I was able to delete the TLS entries from cn=config:
>
> slapd-config raw delete cn=config olcTLSCACertificateFile 1
>
> but when I tried to add the entries back, I got this error:
>
> slapd-config raw insert cn=config olcTLSCACertificateFile 1
> "/etc/ssl/certs/cert.pem"
> modifying entry ""
> ldap_modify: Server is unwilling to perform (53)
> additional info: modify upon the root DSE not supported
>
I have not looked at the details but it seems that there is a bug in
this script. (modifying entry "")
>
> I was able to change the olcLogLevel back to its original state vi
> ldapmodify, so maybe there is something particular about the TLS
> entries, perhaps having to do with permissions on the certs and keys
> themselves?
>
> I have come across this bug in several forums and have yet to see
> someone who solved it in the “correct” manner using ldapmodify.
>
>
> Robert
>
>
>
>>>
>>> I also found a tech note at CentOS:
>>>
>>> https://www.centos.org/docs/5/html/CDS/cli/8.0/Configuration_Command_File...
>>> in section 2.2.2.2 that indicates changes to cn=config will be ignored:
>>>
>>> "If an attribute is added to |cn=config|, the server ignores it."
>>>
>>>
>>> So am I mistaken? Do I need to do something different? I would
>>> prefer to manage the config with ldapmodify, but since I don’t
>>> change cn=config that often, I can change it manually.
>>>
>>>
>>>
>>> Robert
>>>
>>>
>>
>> Cheers,
>> --
>> *Abdelhamid MEDDEB*
>> http://www.meddeb.net
>
--
*Abdelhamid Meddeb*
http://www.meddeb.net
8 years, 1 month
