Re: [RADIATOR] Net::LDAPS problem with Active Directory on port 636
On 11/17/2013 11:04 PM, Klara Mall wrote: I reported it as a bug but it was rejected: https://rt.cpan.org/Public/Bug/Display.html?id=90453 I think Steffen didn't understand what I wanted to say but I replied and tried to explain it again. Now he did understand it. :) It's a bug in Net::LDAP: https://rt.cpan.org/Public/Bug/Display.html?id=90459 Hello Klara, thanks for keeping us informed about this. I think we'll have a note in the documentation about this too. I'll keep an eye on the ticket to see what the maintainer says. Thanks, Heikki -- Heikki Vatiainen h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Net::LDAPS problem with Active Directory on port 636
Hi Heikki, On Tue, Nov 19, 2013 at 10:52:34PM +0100, Heikki Vatiainen wrote: On 11/17/2013 11:04 PM, Klara Mall wrote: I reported it as a bug but it was rejected: https://rt.cpan.org/Public/Bug/Display.html?id=90453 I think Steffen didn't understand what I wanted to say but I replied and tried to explain it again. Now he did understand it. :) It's a bug in Net::LDAP: https://rt.cpan.org/Public/Bug/Display.html?id=90459 thanks for keeping us informed about this. I think we'll have a note in the documentation about this too. I'll keep an eye on the ticket to see what the maintainer says. A note in the documentation is a good idea I think. As you said mixing TLS / SSL won't be done very often but if you do, it is likely that you are lost because it's so hard to understand where the problem comes from (if you don't ask here and get the information to enable debug output for IO::Socket::SSL ;) ). I remember that I first faced the problem in June when I upgraded from Debian squeeze to wheezy. I didn't understand it. I just remember that (I have a configuration with very many different authentication scenarios) there were different situations where the LDAP connection failed. The most stupid one was where the error appeared only when the first LDAP server was not responding (because only connecting to the second one caused that the TLS/SSL mix had two different LDAP servers). So the backup server was up and running but it could not be used. I managed it to alter the configuration (by trial and error) until it was working at least when no LDAP server had a problem. But I wasn't able to resolve the thing with the backup LDAP server. It was very confusing and frustrating. But now I know everything was caused by the one faulty line in Net::LDAP. I'm so happy that I finally understand the whole thing. Thanks Klara ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Net::LDAPS problem with Active Directory on port 636
Hi Heikki, thank you very much for your reply. On Wed, Nov 13, 2013 at 04:30:31PM +0100, Heikki Vatiainen wrote: I want to report this to the module maintainers. Please tell if I'm wrong somewhere. I think the module maintainer should be let known of this problem and can tell if there's a problem. It's quite likely he can quickly tell if and what kind of fix is needed. I reported it as a bug but it was rejected: https://rt.cpan.org/Public/Bug/Display.html?id=90453 I think Steffen didn't understand what I wanted to say but I replied and tried to explain it again. As for my radiator configuration I will reconsider it. I think I will find a way to only use SSL so that I have no mix of SSL and TLS. Please let us know how it goes and what additional information you get from module maintainers. radiator is now working perfectly because I've eliminated all plain text + STARTTLS. I only use SSL now. Thanks Klara ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Net::LDAPS problem with Active Directory on port 636
Hi, On Sun, Nov 17, 2013 at 08:09:07PM +0100, Klara Mall wrote: I think the module maintainer should be let known of this problem and can tell if there's a problem. It's quite likely he can quickly tell if and what kind of fix is needed. I reported it as a bug but it was rejected: https://rt.cpan.org/Public/Bug/Display.html?id=90453 I think Steffen didn't understand what I wanted to say but I replied and tried to explain it again. Now he did understand it. :) It's a bug in Net::LDAP: https://rt.cpan.org/Public/Bug/Display.html?id=90459 Regards Klara ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Net::LDAPS problem with Active Directory on port 636
On 11/13/2013 04:02 AM, Klara Mall wrote: Don't know if these fixes are ok, but they show where the problem resides. Yes, that is very impressive work. My understanding is 1.74 (Debian wheezy) does not work and needs the fix but 1.33 (Debian squeeze) works. There's the possibility that the Debian patches have changed something, but my understanding is they actively push their patches to upstream authors, so I think it is a good idea to contact Steffen and let him know about this. I want to report this to the module maintainers. Please tell if I'm wrong somewhere. I think the module maintainer should be let known of this problem and can tell if there's a problem. It's quite likely he can quickly tell if and what kind of fix is needed. I guess mixing successive direct SSL/TLS connections with plain text + start TLS within one process is not very often done and this has remained uncovered so far. As for my radiator configuration I will reconsider it. I think I will find a way to only use SSL so that I have no mix of SSL and TLS. Please let us know how it goes and what additional information you get from module maintainers. BTW: I just verified: with libnet-ldap-perl from Debian squeeze it works. As it seems the reason is that the part of the IO::Socket::SSL code with the identity is not used (no DEBUG output for this). This should narrow down the work to find the change that caused the problem. Thanks, Heikki -- Heikki Vatiainen h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Net::LDAPS problem with Active Directory on port 636
Hi Heikki,
many thanks for your reply!
I modified Ldap.pm (debug output for IO::Socket::SSL).
Configuration snippet:
---
AuthBy GROUP
Identifier ldap123
AuthByPolicy ContinueWhileAccept
AuthBy LDAP2
Hostkit-dc-04.kit.edu
Port636
Version 3
UseSSL
SSLCAFile %D/certificates/ca.pem
Timeout 3
...
/AuthBy
AuthBy ...
/AuthBy
/AuthBy
Handler ...
RewriteFunction file:%D/hooks/email2sam.pl
AuthBy ldap123
...
/Handler
---
file:%D/hooks/email2sam.pl:
In this RewriteFunction I need an LDAPS connection, too. If it's not the same
host the second authentication with this handler (after restart of radiator)
will fail.
email2sam.pl:
--
sub
{
my $host = kit-ad.scc.kit.edu;
require Net::LDAPS;
my $ldap = Net::LDAPS-new(
$host,
port = 636,
timeout = 3,
verify = 'require',
cafile = '/etc/radiator/certificates/ca.pem')
or return $user;
...
my $user_new = ...
return $user_new;
}
--
In the IO::Socket:SSL debug log you see the two connections. The
first is the RewriteFunction's one and the second the AuthBy's one.
* 1st authentication with this handler:
a.) RewriteFunction email2sam
[...]
DEBUG: .../IO/Socket/SSL.pm:1210: identity=kit-ad.scc.kit.edu
cn=kit-ad.scc.kit.edu alt=1 f...@scc.kit.edu
DEBUG: .../IO/Socket/SSL.pm:446: Net::SSLeay::connect - -1
DEBUG: .../IO/Socket/SSL.pm:456: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:466: waiting for fd to become ready: SSL wants a
read first
DEBUG: .../IO/Socket/SSL.pm:486: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:446: Net::SSLeay::connect - 1
DEBUG: .../IO/Socket/SSL.pm:501: ssl handshake done
b.) AuthBy LDAP2
[...]
DEBUG: .../IO/Socket/SSL.pm:1210: identity=kit-dc-04.kit.edu
cn=kit-dc-04.kit.edu alt=2 kit-dc-04.kit.edu 2 kit-dc.kit.edu
DEBUG: .../IO/Socket/SSL.pm:446: Net::SSLeay::connect - -1
DEBUG: .../IO/Socket/SSL.pm:456: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:466: waiting for fd to become ready: SSL wants a
read first
DEBUG: .../IO/Socket/SSL.pm:486: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:446: Net::SSLeay::connect - 1
DEBUG: .../IO/Socket/SSL.pm:501: ssl handshake done
= Everything ok.
* 2nd authentication with this handler:
a.) RewriteFunction email2sam
[...]
DEBUG: .../IO/Socket/SSL.pm:1210: identity=kit-dc-04.kit.edu
cn=kit-ad.scc.kit.edu alt=1 f...@scc.kit.edu
DEBUG: .../IO/Socket/SSL.pm:446: Net::SSLeay::connect - -1
DEBUG: .../IO/Socket/SSL.pm:1328: SSL connect attempt failed with unknown error
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
failed
DEBUG: .../IO/Socket/SSL.pm:452: fatal SSL error: SSL connect attempt failed
with unknown error error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
DEBUG: .../IO/Socket/SSL.pm:1328: IO::Socket::IP configuration failed
error::lib(0):func(0):reason(0)
b.) AuthBy LDAP2
[...]
DEBUG: .../IO/Socket/SSL.pm:1210: identity=kit-dc-04.kit.edu
cn=kit-dc-04.kit.edu alt=2 kit-dc-04.kit.edu 2 kit-dc.kit.edu
DEBUG: .../IO/Socket/SSL.pm:446: Net::SSLeay::connect - -1
DEBUG: .../IO/Socket/SSL.pm:456: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:466: waiting for fd to become ready: SSL wants a
read first
DEBUG: .../IO/Socket/SSL.pm:486: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:446: Net::SSLeay::connect - 1
DEBUG: .../IO/Socket/SSL.pm:501: ssl handshake done
= RewriteFunction's LDAP connection failed because of wrong identity.
It seems that the identity is cached from the AuthBy LDAP2 before. I'm
even not sure what this identity in an SSL connection means. So I'd
be happy if someone has an idea how this can be fixed.
Best Regards
Klara
On Tue, Nov 12, 2013 at 12:23:53AM +0100, Heikki Vatiainen wrote:
On 11/11/2013 11:58 PM, Klara Mall wrote:
With this configuration the connection fails about half of the time (not
always) with:
ERR: Could not open LDAP connection to ad.example.com:636. Backing off
for 600 seconds.
I had a look at Ldap.pm from the radiator code and wrote this little
Perl program:
---
Hello Klara,
If you add the 'use ...' before require and then run the script, do you
get debug output from IO::Socket::SSL? I have not tried this myself, but
my understanding is IO::Socket::SSL is what Net::LDAP uses for LDAPS.
If you do get debug output, you could try modifying Ldap.pm a bit more
and make it load IO::Socket::SSL with debug enabled.
When you then run radiusd with -foreground and
Re: [RADIATOR] Net::LDAPS problem with Active Directory on port 636
Sorry, I told something wrong, see below... On Tue, Nov 12, 2013 at 09:58:08PM +0100, Klara Mall wrote: many thanks for your reply! I modified Ldap.pm (debug output for IO::Socket::SSL). Configuration snippet: --- AuthBy GROUP Identifier ldap123 AuthByPolicy ContinueWhileAccept AuthBy LDAP2 Hostkit-dc-04.kit.edu Port636 Version 3 UseSSL SSLCAFile %D/certificates/ca.pem Timeout 3 ... /AuthBy I noticed that here I use Port 389 with STARTTLS (UseTLS) not UseSSL. It works if I use SSL here. I analyzed now (given two different LDAP server hosts): a. if I use SSL in both connections it works. b. if I use TLS in both connections it works. c. if I use TLS in RewriteFunction and SSL in AuthBy LDAP2 it doesn't work. d. if I use SSL in RewriteFunction and TLS in AuthBy LDAP2 it doesn't work. c: This is what I was describing in this email (2nd authentication fails). d: Not the 2nd authentication fails but the 1st. RewriteFunction is ok: DEBUG: .../IO/Socket/SSL.pm:1210: identity=kit-dc-04.kit.edu cn=kit-dc-04.kit.edu alt=2 kit-dc-04.kit.edu 2 kit-dc.kit.edu AuthBy LDAP2 fails: DEBUG: .../IO/Socket/SSL.pm:1210: identity=kit-dc-04.kit.edu cn=kit-ad.scc.kit.edu alt=1 f...@scc.kit.edu I seems that the first TLS connection after an SSL connection fails. I have to try to reproduce this with a Perl program which does nothing else than such two connections. Regards Klara ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Net::LDAPS problem with Active Directory on port 636
Hi, On Tue, Nov 12, 2013 at 10:29:18PM +0100, Klara Mall wrote: I analyzed now (given two different LDAP server hosts): a. if I use SSL in both connections it works. b. if I use TLS in both connections it works. c. if I use TLS in RewriteFunction and SSL in AuthBy LDAP2 it doesn't work. d. if I use SSL in RewriteFunction and TLS in AuthBy LDAP2 it doesn't work. c: This is what I was describing in this email (2nd authentication fails). d: Not the 2nd authentication fails but the 1st. RewriteFunction is ok: DEBUG: .../IO/Socket/SSL.pm:1210: identity=kit-dc-04.kit.edu cn=kit-dc-04.kit.edu alt=2 kit-dc-04.kit.edu 2 kit-dc.kit.edu AuthBy LDAP2 fails: DEBUG: .../IO/Socket/SSL.pm:1210: identity=kit-dc-04.kit.edu cn=kit-ad.scc.kit.edu alt=1 f...@scc.kit.edu I seems that the first TLS connection after an SSL connection fails. I have to try to reproduce this with a Perl program which does nothing else than such two connections. Sorry, I have mixed this up again (it's very hard to test this without getting confused). What I described in my first email was d. That means that the first SSL connection after a TLS connection fails - i.e the 2nd auth try fails here. c.: The same: the first SSL connection after a TLS connection fails - i.e. the 1st auth try fails here. I could reproduce it: - #!/usr/bin/perl -w use IO::Socket::SSL qw(debug3); my $tls_host = kit-dc-04.kit.edu; my $ssl_host = kit-ad.scc.kit.edu; require Net::LDAP; my $ldap_tls = Net::LDAP-new( $tls_host, port = 389, timeout = 3); $ldap_tls- start_tls( verify = 'require', cafile = 'ca.pem'); require Net::LDAPS; my $ldap_ssl = Net::LDAPS-new( $ssl_host, port = 636, timeout = 3, verify = 'require', cafile = 'ca.pem'); - Result: - DEBUG: .../IO/Socket/SSL.pm:1653: new ctx 22392624 DEBUG: .../IO/Socket/SSL.pm:1061: start handshake DEBUG: .../IO/Socket/SSL.pm:383: ssl handshake not started DEBUG: .../IO/Socket/SSL.pm:433: set socket to non-blocking to enforce timeout=3 DEBUG: .../IO/Socket/SSL.pm:446: Net::SSLeay::connect - -1 DEBUG: .../IO/Socket/SSL.pm:456: ssl handshake in progress DEBUG: .../IO/Socket/SSL.pm:466: waiting for fd to become ready: SSL wants a read first DEBUG: .../IO/Socket/SSL.pm:486: socket ready, retrying connect DEBUG: .../IO/Socket/SSL.pm:446: Net::SSLeay::connect - -1 DEBUG: .../IO/Socket/SSL.pm:456: ssl handshake in progress DEBUG: .../IO/Socket/SSL.pm:466: waiting for fd to become ready: SSL wants a read first DEBUG: .../IO/Socket/SSL.pm:486: socket ready, retrying connect DEBUG: .../IO/Socket/SSL.pm:1641: ok=1 cert=22397184 DEBUG: .../IO/Socket/SSL.pm:1641: ok=1 cert=22521520 DEBUG: .../IO/Socket/SSL.pm:1641: ok=1 cert=22513408 DEBUG: .../IO/Socket/SSL.pm:1641: ok=1 cert=22421632 DEBUG: .../IO/Socket/SSL.pm:1201: scheme=ldap cert=22421632 DEBUG: .../IO/Socket/SSL.pm:1210: identity=kit-dc-04.kit.edu cn=kit-dc-04.kit.edu alt=2 kit-dc-04.kit.edu 2 kit-dc.kit.edu DEBUG: .../IO/Socket/SSL.pm:446: Net::SSLeay::connect - -1 DEBUG: .../IO/Socket/SSL.pm:456: ssl handshake in progress DEBUG: .../IO/Socket/SSL.pm:466: waiting for fd to become ready: SSL wants a read first DEBUG: .../IO/Socket/SSL.pm:486: socket ready, retrying connect DEBUG: .../IO/Socket/SSL.pm:446: Net::SSLeay::connect - 1 DEBUG: .../IO/Socket/SSL.pm:501: ssl handshake done DEBUG: .../IO/Socket/SSL.pm:1653: new ctx 22444320 DEBUG: .../IO/Socket/SSL.pm:363: socket not yet connected DEBUG: .../IO/Socket/SSL.pm:365: socket connected DEBUG: .../IO/Socket/SSL.pm:383: ssl handshake not started DEBUG: .../IO/Socket/SSL.pm:433: set socket to non-blocking to enforce timeout=3 DEBUG: .../IO/Socket/SSL.pm:446: Net::SSLeay::connect - -1 DEBUG: .../IO/Socket/SSL.pm:456: ssl handshake in progress DEBUG: .../IO/Socket/SSL.pm:466: waiting for fd to become ready: SSL wants a read first DEBUG: .../IO/Socket/SSL.pm:486: socket ready, retrying connect DEBUG: .../IO/Socket/SSL.pm:1641: ok=1 cert=22556704 DEBUG: .../IO/Socket/SSL.pm:1641: ok=1 cert=22677424 DEBUG: .../IO/Socket/SSL.pm:1641: ok=1 cert=22669216 DEBUG: .../IO/Socket/SSL.pm:1641: ok=1 cert=22570864 DEBUG: .../IO/Socket/SSL.pm:1201: scheme=ldap cert=22570864 DEBUG: .../IO/Socket/SSL.pm:1210: identity=kit-dc-04.kit.edu cn=kit-ad.scc.kit.edu alt=1 f...@scc.kit.edu DEBUG: .../IO/Socket/SSL.pm:446: Net::SSLeay::connect - -1 DEBUG: .../IO/Socket/SSL.pm:1328: SSL connect attempt failed with unknown error error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed DEBUG: .../IO/Socket/SSL.pm:452: fatal SSL error: SSL
Re: [RADIATOR] Net::LDAPS problem with Active Directory on port 636
Hi,
On Tue, Nov 12, 2013 at 10:55:12PM +0100, Klara Mall wrote:
So is this a bug in IO::Socket::SSL?
Yes, I think so. In this module SSL variables which are not set are
overriden with global variables. But it seems for this one (the
identity is set to $host) it is too early. So I moved this code
block somewhat down which fixes it. (Although I'm wondering if the
identity should be overriden with a global variable at all.)
Fix for version 1.74 (Debian wheezy):
---
--- SSL.pm.orig 2013-11-13 02:11:46.752935483 +0100
+++ SSL.pm 2013-11-13 02:12:44.413920483 +0100
@@ -291,9 +291,6 @@
}
}
- #Replace nonexistent entries with defaults
- %$arg_hash = ( %default_args, %$GLOBAL_CONTEXT_ARGS, %$arg_hash );
-
#Avoid passing undef arguments to Net::SSLeay
defined($arg_hash-{$_}) or delete($arg_hash-{$_}) foreach (keys
%$arg_hash);
@@ -327,6 +324,9 @@
return $rv;
};
}
+
+ #Replace nonexistent entries with defaults
+ %$arg_hash = ( %default_args, %$GLOBAL_CONTEXT_ARGS, %$arg_hash );
${*$self}{'_SSL_arguments'} = $arg_hash;
${*$self}{'_SSL_ctx'} = IO::Socket::SSL::SSL_Context-new($arg_hash) ||
return;
---
Fix for recent version 1.959:
---
--- SSL.pm.orig 2013-11-13 02:05:17.658251025 +0100
+++ SSL.pm 2013-11-13 02:04:55.129862855 +0100
@@ -300,13 +300,6 @@
$is_server = $arg_hash-{SSL_server} = $arg_hash-{Listen} || 0;
}
-# add user defined defaults
-%$arg_hash = (
- %$GLOBAL_SSL_ARGS,
- $is_server ? %$GLOBAL_SSL_SERVER_ARGS : %$GLOBAL_SSL_CLIENT_ARGS,
- %$arg_hash
-);
-
my $ctx = $arg_hash-{'SSL_reuse_ctx'};
if ($ctx) {
if ($ctx-isa('IO::Socket::SSL::SSL_Context') and
@@ -320,6 +313,13 @@
# create context
# this will fill in defaults in $arg_hash
$ctx ||= IO::Socket::SSL::SSL_Context-new($arg_hash);
+
+# add user defined defaults
+%$arg_hash = (
+ %$GLOBAL_SSL_ARGS,
+ $is_server ? %$GLOBAL_SSL_SERVER_ARGS : %$GLOBAL_SSL_CLIENT_ARGS,
+ %$arg_hash
+);
${*$self}{'_SSL_arguments'} = $arg_hash;
${*$self}{'_SSL_ctx'} = $ctx;
---
Don't know if these fixes are ok, but they show where the problem
resides.
I want to report this to the module maintainers. Please tell if I'm
wrong somewhere.
As for my radiator configuration I will reconsider it. I think I
will find a way to only use SSL so that I have no mix of SSL and
TLS.
BTW: I just verified: with libnet-ldap-perl from Debian squeeze it
works. As it seems the reason is that the part of the
IO::Socket::SSL code with the identity is not used (no DEBUG
output for this).
Regards
Klara
--
Karlsruher Institut für Technologie (KIT)
Steinbuch Centre for Computing (SCC)
Klara Mall
Netze und Telekommunikation (NET)
Hermann-von-Helmholtz-Platz 1
76344 Eggenstein-Leopoldshafen
Telefon: +49 721 608-28630
Telefon: +49 721 608-48946
E-Mail: klara.m...@kit.edu
Web: http://www.scc.kit.edu
KIT - Universität des Landes Baden-Württemberg und
nationales Forschungszentrum in der Helmholtz-Gemeinschaft
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Net::LDAPS problem with Active Directory on port 636
Addendum:
On 11/11/2013 10:58 PM, Klara Mall wrote:
I have a problem with connecting to our Active Directory servers (LDAP)
on port 636 with radiator. Port 3269 is working but I have to use 636
for a certain reason.
The mad thing is: I cannot reproduce the problem with a little Perl
program on the same host.
System:
radiator 4.11, Debian wheezy, i386 (all Perl modules from Debian)
Forgot to say: no IPv6 address is configured, only IPv4.
Relevant radiator configuration:
---
Hostad.example.com
Port636
Version 3
UseSSL
SSLCAFile %D/certificates/ca.pem
Timeout 3
---
Forgot to say: I use AuthBy LDAP2.
With this configuration the connection fails about half of the time (not
always) with:
ERR: Could not open LDAP connection to ad.example.com:636. Backing off
for 600 seconds.
I had a look at Ldap.pm from the radiator code and wrote this little
Perl program:
---
require Net::LDAPS;
my $host = ad.example.com;
my $ldap = new Net::LDAPS($host,
port = 636,
verify = 'require',
localaddr = '',
multihomed = 1,
version = 3,
inet6 = 0,
timeout = 3,
cafile =
'/etc/radiator/certificates/deutsche-ca.pem');
This is a typo: it is the same file as above.
if (!$ldap) { print error\n; exit; }
else { print success\n; exit; }
---
I run this program in a while loop several times and the connection
never fails.
I also removed the patch by Raphael Luta (in Ldap.pm) which permits
multiple hostnames. But it made no difference.
I wasn't able to find the difference between the radiator code and my
code. Can you help me?
Best regards
Klara
--
Karlsruher Institut für Technologie (KIT)
Steinbuch Centre for Computing (SCC)
Klara Mall
Netze und Telekommunikation (NET)
Hermann-von-Helmholtz-Platz 1
76344 Eggenstein-Leopoldshafen
Telefon: +49 721 608-28630
Telefon: +49 721 608-48946
E-Mail: klara.m...@kit.edu
Web: http://www.scc.kit.edu
KIT - Universität des Landes Baden-Württemberg und
nationales Forschungszentrum in der Helmholtz-Gemeinschaft
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Net::LDAPS problem with Active Directory on port 636
On 11/11/2013 11:58 PM, Klara Mall wrote:
With this configuration the connection fails about half of the time (not
always) with:
ERR: Could not open LDAP connection to ad.example.com:636. Backing off
for 600 seconds.
I had a look at Ldap.pm from the radiator code and wrote this little
Perl program:
---
Hello Klara,
If you add the 'use ...' before require and then run the script, do you
get debug output from IO::Socket::SSL? I have not tried this myself, but
my understanding is IO::Socket::SSL is what Net::LDAP uses for LDAPS.
If you do get debug output, you could try modifying Ldap.pm a bit more
and make it load IO::Socket::SSL with debug enabled.
When you then run radiusd with -foreground and -log_stdout options, you
should see the debug output when LDAPS connections are created.
Maybe this debug would show what goes wrong.
use IO::Socket::SSL qw(debug3);
require Net::LDAPS;
my $host = ad.example.com;
my $ldap = new Net::LDAPS($host,
port = 636,
verify = 'require',
localaddr = '',
multihomed = 1,
version = 3,
inet6 = 0,
timeout = 3,
cafile =
'/etc/radiator/certificates/deutsche-ca.pem');
if (!$ldap) { print error\n; exit; }
else { print success\n; exit; }
Thanks,
Heikki
--
Heikki Vatiainen h...@open.com.au
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
