Here's the relevant error:

t/08time.............
#   Failed test 'time_to_generalizedTime('-33358996800') should yield 09121123120000Z'
#   in t/08time.t at line 44.
#          got: '19011213204552Z'
#     expected: '09121123120000Z'
# Looks like you failed 1 test of 40.
dubious
        Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 22

This is on a RHEL 5 server

I experienced a failure in t/46ssl.t like this:

#   Failed test 'start_tls: 1: cannot start TLS when operations are outstanding'
#   at t/46ssl.t line 27.

#   Failed test 'start_tls: 0: Success'
#   at t/46ssl.t line 30.
# Looks like you failed 2 tests of 15.
t/46ssl.t ............ 
Dubious, test returned 2 (wstat 512, 0x200)
Failed 2/15 subtests 

I'm unable to reproduce it. But I suspect that the LDAP server was overloaded and a ldif_populate() call preceding the failed start_tls() call has not yet finished on the server and thus the start_tls() failed. The error message comes from the server https://github.com/openldap/openldap/blob/master/servers/slapd/starttls.c#L52 and it is returned if there are some operations queued.

Would adding sync() at the end of ldif_populate() help?

The 2nd Example shown for option raw => REGEX in LDAP.pod, lines 747-755, seems to belong to elsewhere (presumably LDAP::search's scope=>sub ?)

I have problems establishing connections to an ActiveDirectory server on port 636 with perl-LDAP v0.68 (Fedora 35).
DEBUG: .../IO/Socket/SSL.pm:2950: new ctx 94479025936736
DEBUG: .../IO/Socket/SSL.pm:702: socket not yet connected
DEBUG: .../IO/Socket/SSL.pm:1117: global error: Undefined SSL object
DEBUG: .../IO/Socket/SSL.pm:1117: global error: Undefined SSL object
DEBUG: .../IO/Socket/SSL.pm:704: socket connected
DEBUG: .../IO/Socket/SSL.pm:727: ssl handshake not started
DEBUG: .../IO/Socket/SSL.pm:769: using SNI with hostname stilton.gigl.polymtl.ca
DEBUG: .../IO/Socket/SSL.pm:820: set socket to non-blocking to enforce timeout=120
DEBUG: .../IO/Socket/SSL.pm:834: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:837: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:847: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:857: waiting for fd to become ready: SSL wants a read first
DEBUG: .../IO/Socket/SSL.pm:877: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:834: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:837: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:840: local error: SSL connect attempt failed
DEBUG: .../IO/Socket/SSL.pm:843: fatal SSL error: SSL connect attempt failed
DEBUG: .../IO/Socket/SSL.pm:702: socket not yet connected
DEBUG: .../IO/Socket/SSL.pm:1117: global error: Undefined SSL object
DEBUG: .../IO/Socket/SSL.pm:1117: global error: Undefined SSL object
DEBUG: ...erl5/IO/Socket.pm:50: ignoring less severe local error 'IO::Socket::IP configuration failed', keep 'SSL connect attempt failed'
DEBUG: .../IO/Socket/SSL.pm:2999: free ctx 94479025936736 open=94479025936736
DEBUG: .../IO/Socket/SSL.pm:3010: OK free ctx 94479025936736

If I try the the same code with perl-LDAP v0.66 (CentOS Stream 8), it works fine.

Here's an excerp of my code (sanitized):

$Ad = Net::LDAP->new('example.com',version => 3,scheme => 'ldaps', port => 636, verify=>'never') or die("failed $!");
print "Failed connecting" if(!$Ad);

Any ideas?

Hi. Documentation states:

new ( HOST, OPTIONS )
...
You can also specify a URI, such as 'ldaps://127.0.0.1:666' or 'ldapi://%2fvar%2flib%2fldap_sock'. Note that '%2f's in the LDAPI socket path will be translated into '/'. This is to support LDAP query options like base, search etc. although the query part of the URI will be ignored in this context. If port was not specified in the URI, the default is either 389 or 636 for 'LDAP' and 'LDAPS' schemes respectively.

I tested this with tcpdump. I tried both prepending ldaps:// and appending :636, but neither is respected. It sends unencrypted traffic over the default port (389).

The only way to change the behaviour is with options.

Using Active directory on Windows 2016, I created a user with Password20° as password.
My script is unable to bind, if I enable debug i can see the following error

'errorMessage' => '80090308: LdapErr: DSID-0C09042A, comment: AcceptSecurityContext error, data 52e, v3839',

Changing the password bind works wel.
Can you help me ?

Thank you

Hi,

The BUGS section at https://metacpan.org/source/MARSCHAP/perl-ldap-0.65/lib/Net/LDAPS.pm#L71 says

You cannot have more than one LDAPS connection at any one time, due to
restrictions in the underlying Net::SSLeay code.

I saw http://www.nntp.perl.org/group/perl.ldap/2006/04/msg2091.html, in which Chris said that above statement may be bogus. I personally don't think Net::SSLeay has that kind of restriction, and I doubt that restriction really exists. But presently I don't have an environment to test it myself. I wonder if anyone else know more about this thing. And if this statement is not true, can we remove it from the pod to avoid confusing?

I have been using the 'sslserver' option when calling start_tls or connect_ldaps in certain situations where the target hostname doesn't match the LDAP server's cert but I still want to do TLS validation.

However, I noticed this option is not documented. Was this left out on purpose or just an oversight? If it can be added I'm happy to send a PR.

Description

LDIFs that contain an attribute that is modified to be a null or blank value are not communicated through this library.

Since LDIFs are meant for incremental changes, only the changed attributes are included, so there's no way to assume that a particular attribute exists in the source LDIF, and no way to assume that it has a null value.

Example

Consider the following, for a sample LDIF file:

dn: uid=asdf1234,ou=people,dc=entdir,dc=example,dc=com
changetype: modify
replace: someAttribute
-
replace: anotherAttribute
anotherAttribute: hello world
-
replace: personLastUpdateTime
personLastUpdateTime: 20180827101540Z
-

A sample script, based on the example code from NET::LDAP::LDIF:

#!/usr/bin/perl

use feature ':5.16';
use strict;
use warnings;
use Data::Dumper;

use Net::LDAP::LDIF;

my $ldif = Net::LDAP::LDIF->new( "sample.ldif", "r", onerror => 'undef' );

while ( not $ldif->eof() ) {
    my $entry = $ldif->read_entry();
    if ( $ldif->error() ) {
        print "Error msg: ",    $ldif->error(),       "\n";
        print "Error lines:\n", $ldif->error_lines(), "\n";
    }
    else {
        # do stuff
        say "dump";
        say $entry->dump;
        say "----";
        say "testing key-value:\n";
        exists_and_value( $entry, 'someAttribute' );
        exists_and_value( $entry, 'anotherAttribute' );
        exists_and_value( $entry, 'personLastUpdateTime' );
        say "----";
        say "attrs";
        say Dumper $entry->{attrs};
    }
}
$ldif->done();

sub exists_and_value {
    my ( $entry, $key ) = @_;
    say "  - $key";
    say "    - exists: '" . ( $entry->exists($key) ) . "'";
    say "    - value: '" . ( $entry->get_value($key) || '' ) . "'";
    return "function_name: wip, placeholder";
}    ##    exists_and_value

Results demonstrate that while the someAttribute field was set to a blank/null value, the library does not show this effect.

dump
------------------------------------------------------------------------
dn:uid=asdf1234,ou=people,dc=entdir,dc=example,dc=com

    anotherAttribute: hello world
personLastUpdateTime: 20180827101540Z

----
testing key-value:

  - someAttribute
    - exists: ''
    - value: ''
  - anotherAttribute
    - exists: '1'
    - value: 'hello world'
  - personLastUpdateTime
    - exists: '1'
    - value: '20180827101540Z'
----
attrs
$VAR1 = {
          'personlastupdatetime' => [
                                      '20180827101540Z'
                                    ],
          'anotherattribute' => [
                                  'hello world'
                                ]
        };

[Finished in 0.1s]

Suggested fix

It would be important to distinguish between null values and empty-strings, and so I feel the existing behavior of get_value is fine.

Instead, exists should be modified to return 1 on those null'ed out values, and the ->{attrs} property should be updated to include those keys, with an empty array-ref to indicate no value set.

An argument might be made to change get_value to return an empty array or empty array-ref when the value is null for a given attribute (that is part of the LDIF), but I see where such a similar suggestion was decided against (#46).

I'm having SSL connection issues with perl-ldap.

Here's what I'm trying:

#######################
#!/usr/bin/perl

use warnings;
use Net::LDAP;
use Net::LDAP::Extra qw(AD);
use IO::Socket::SSL qw(debug3);

$Ad = Net::LDAP->new('dc1.foobar.com',version => 3,scheme => 'ldaps', port => 636, verify=>'require', capath => '/etc/ssl/Certs') or die("failed $!");
print "Failed connecting" if(!$Ad);
#######################

And here's the error output:

DEBUG: .../IO/Socket/SSL.pm:2950: new ctx 94033828582432
DEBUG: .../IO/Socket/SSL.pm:702: socket not yet connected
DEBUG: .../IO/Socket/SSL.pm:1117: global error: Undefined SSL object
DEBUG: .../IO/Socket/SSL.pm:1117: global error: Undefined SSL object
DEBUG: .../IO/Socket/SSL.pm:704: socket connected
DEBUG: .../IO/Socket/SSL.pm:727: ssl handshake not started
DEBUG: .../IO/Socket/SSL.pm:769: using SNI with hostname dc1.foobar.com
DEBUG: .../IO/Socket/SSL.pm:804: request OCSP stapling
DEBUG: .../IO/Socket/SSL.pm:820: set socket to non-blocking to enforce timeout=120
DEBUG: .../IO/Socket/SSL.pm:834: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:837: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:847: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:857: waiting for fd to become ready: SSL wants a read first
DEBUG: .../IO/Socket/SSL.pm:877: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:834: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:837: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:840: local error: SSL connect attempt failed
DEBUG: .../IO/Socket/SSL.pm:843: fatal SSL error: SSL connect attempt failed
DEBUG: ...erl5/IO/Socket.pm:48: ignoring less severe local error 'IO::Socket::IP configuration failed', keep 'SSL connect attempt failed'
DEBUG: .../IO/Socket/SSL.pm:2999: free ctx 94033828582432 open=94033828582432
DEBUG: .../IO/Socket/SSL.pm:3003: free ctx 94033828582432 callback
DEBUG: .../IO/Socket/SSL.pm:3010: OK free ctx 94033828582432
failed Connection reset by peer at AD_connect_LDAPS.pl line 8, line 960.

From my tests, it seems that it's a problem with SNI because this works:

perl -e 'use IO::Socket::SSL qw(debug3);IO::Socket::SSL->new(SSL_hostname => '',PeerAddr=>"dc1.foobar.com",PeerPort=> 636,Proto=>"TCP") or die $!'

Is there an option to pass along SSL_hostname => '' through Net::Ldap?

Hi,

I've just seen 40c28e1 and was also trying to use 1.3.6.1.4.1.4203.1.10.1 (Subentries) against the latest OpenLDAP, but can't get it to work. Does it make a difference whether I pass in the control type or if there is a bundled control?

I'm using like so:

        my $subentry_ctrl = Net::LDAP::Control->new(
            type     => '1.3.6.1.4.1.4203.1.10.1',
            value    => 'Subentries',
            critical => 1
        );

        my $deleted = $c->model('LDAPContacts')->delete(
            q{ou=Contacts,} . $user_dn,
            control => [ $subentry_ctrl ]
        );

        if ( $deleted->code ) {
            $c->error( qq{Failed to delete LDAP contact entries for: $user_dn}
                  . $deleted->error
                  . q{ Code: }
                  . $deleted->code );
            return 0;
        }

and I'm getting:

Dec 22 12:53:57 gabriel slapd[31511]: conn=1110022 op=2 SRCH attr=dn
Dec 22 12:53:57 gabriel slapd[31511]: conn=1110022 op=2 ENTRY dn="xxxx"
Dec 22 12:53:57 gabriel slapd[31511]: conn=1110022 op=2 SEARCH RESULT tag=101 err=0 qtime=0.000010 etime=0.001015 nentries=1 text=
Dec 22 12:53:57 gabriel slapd[31511]: conn=1110023 fd=435 ACCEPT from IP=xxx:51082 (IP=0.0.0.0:389)
Dec 22 12:53:57 gabriel slapd[31511]: conn=1110023 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Dec 22 12:53:57 gabriel slapd[31511]: conn=1110023 op=0 STARTTLS
Dec 22 12:53:57 gabriel slapd[31511]: conn=1110023 op=0 RESULT oid= err=0 qtime=0.000007 etime=0.000038 text=
Dec 22 12:53:57 gabriel slapd[31511]: conn=1110023 fd=435 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384
Dec 22 12:53:57 gabriel slapd[31511]: conn=1110023 op=1 BIND dn="xxx" method=128
Dec 22 12:53:57 gabriel slapd[31511]: conn=1110023 op=1 BIND dn="xxx" mech=SIMPLE ssf=0
Dec 22 12:53:57 gabriel slapd[31511]: conn=1110023 op=1 RESULT tag=97 err=0 qtime=0.000017 etime=0.000116 text=
Dec 22 12:53:58 gabriel slapd[31511]: conn=1110023 op=2 RESULT tag=107 err=12 qtime=0.000014 etime=0.000274 text=critical extension is unavailable
Dec 22 12:53:58 gabriel slapd[31511]: conn=1110023 op=2 do_delete: get_ctrls failed

Any ideas? Using ldapdelete with -r works as the same user (so not my ACLs), but I note in the logs that it is doing a base search for subentries and deleting each one. What am I misunderstanding here?

Thanks,
Gavin.

Today I faced an issue by requesting a value by calling $entry->get_value('optional_attribute_key') and try to put it directly in a hash/hashref like:

my $data = (
    ...
    'key' => $entry->get_value('optional_attribute_key'),
    ...
);

perl throws Odd number of elements in hash assignment at ...

The problem is that the whole hash is broken and returns mixed invalid values.

I have researched your library and have found this line: Entry.pm:130
The function returns nothing and not as expected undef like it is written in the documentation. so it seems to be a bug.