date:20131112

Re: [RADIATOR] Net::LDAPS problem with Active Directory on port 636

2013-11-12 Thread Klara Mall

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

2013-11-12 Thread Klara Mall

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/

Re: [RADIATOR] Net::LDAPS problem with Active Directory on port 636

2013-11-12 Thread Klara Mall

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:
> ---
> 
> Identifier ldap123
> AuthByPolicy ContinueWhileAccept
>   
>   Hostkit-dc-04.kit.edu
>   Port636
>   Version 3
>   UseSSL
>   SSLCAFile %D/certificates/ca.pem
>   Timeout 3
>   ...
>   

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

2013-11-12 Thread Klara Mall

Hi Heikki,

many thanks for your reply!

I modified Ldap.pm (debug output for IO::Socket::SSL).

Configuration snippet:
---

Identifier ldap123
AuthByPolicy ContinueWhileAccept

Hostkit-dc-04.kit.edu
Port636
Version 3
UseSSL
SSLCAFile %D/certificates/ca.pem
Timeout 3
...








RewriteFunction file:"%D/hooks/email2sam.pl"
AuthBy ldap123
...


---

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 -log_stdout options, you

Re: [RADIATOR] per-clause vs global Logs

2013-11-12 Thread Heikki Vatiainen

On 11/12/2013 06:12 PM, David Zych wrote:

>>> Now, however, I'm trying to put my Radiator servers behind a server load 
>>> balancer (SLB); every few seconds, the SLB sends a health check request 
>>> which Radiator is configured to REJECT (this is safer than ACCEPT and 
>>> equally effective proof that the server is alive and answering).  The 
>>> problem is that each REJECT generates INFO-level log output which is 
>>> cluttering up my logs:
>>>
>>> Fri Nov  8 16:56:03 2013 416230: INFO: Access rejected for 
>>> SI_radius_keepalive: L7 Health Check from SLB
>>
>> would a good solution be to change the log
>> level of reject messages to something else? What could be done is to
>> make the log level of these messages configurable.
> 
> This would be great!  (ideally as a per-Handler config option, so that I
> could set it to DEBUG for this one Handler but leave it alone for others)

Global option would be possible at least. Lets see what it would take to
have it as a per Handler option. Value for per Handler option should
probably default to the global option so it can be overridden easily.

I'll get back to this when there is something to test.

Thanks,
Heikki

-- 
Heikki Vatiainen 

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

[RADIATOR] per-clause vs global Logs

2013-11-12 Thread David Zych

Heikki Vatiainen wrote:
> On 11/09/2013 01:22 AM, David Zych wrote:
> 
>> Now, however, I'm trying to put my Radiator servers behind a server load 
>> balancer (SLB); every few seconds, the SLB sends a health check request 
>> which Radiator is configured to REJECT (this is safer than ACCEPT and 
>> equally effective proof that the server is alive and answering).  The 
>> problem is that each REJECT generates INFO-level log output which is 
>> cluttering up my logs:
>> 
>> Fri Nov  8 16:56:03 2013 416230: INFO: Access rejected for 
>> SI_radius_keepalive: L7 Health Check from SLB
> 
> would a good solution be to change the log
> level of reject messages to something else? What could be done is to
> make the log level of these messages configurable.

This would be great!  (ideally as a per-Handler config option, so that I
could set it to DEBUG for this one Handler but leave it alone for others)

Thanks,
David

___
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

Re: [RADIATOR] Net::LDAPS problem with Active Directory on port 636

Re: [RADIATOR] Net::LDAPS problem with Active Directory on port 636

Re: [RADIATOR] Net::LDAPS problem with Active Directory on port 636

Re: [RADIATOR] per-clause vs global Logs

[RADIATOR] per-clause vs global Logs

6 matches

Site Navigation

Mail list logo

Footer information