Re: [RADIATOR] help diagnosing failure to connect to LDAP

2016-05-13 Thread Hartmaier Alexander 

Hi,
I'm using 'Debug 12' inside of  to troubleshoot TLS problems.
Have you set the port to 636 and UseSSL? UseTLS should really be named 
UseSTARTTLS because it's quite irritating otherwise.
You also need to configure the root CA (not intermeditate CA!) cert using 
SSLCAFile.

I haven't the need to run Radiator in the foreground, maybe I've missed the 
Net::LDAP errors in the past?!

Cheers, Alex

On 2016-05-11 18:42, Tuure Vartiainen wrote:

Hello,



On 11 May 2016, at 01:49, Jennifer Mehl 
 wrote:

I’m working on setting up a new RADIUS client/handler, and am having trouble 
diagnosing why connections from Radiator to an LDAP server are failing.

Using the ldapsearch command from the same system, using the same 
AuthDN/password yields a successful result.

I’m wondering if there is an error being kicked off somewhere from the LDAP or 
SSL Perl modules that I can’t see.  Or is there an open/broken connection to 
the LDAP server being cached somewhere that needs a “reset?”

I’ve turned on Trace 5 in radius.cfg and “Debug 255” in the AuthByLDAP2 clause, 
but not seeing a lot in the logs about the reason for the failure.




Perl’s LDAP library’s debug output, which is enabled with “Debug 255”,
can only be seen on a console when running Radiator on a foreground.

E.g.

$ perl radiusd -config /etc/radiator/radius.cfg -trace 4 -log_stdout -foreground


BR
--
Tuure Vartiainen 

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



*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] help diagnosing failure to connect to LDAP

2016-05-11 Thread Jennifer Mehl 
Thanks for the information.

The stdout/console logs yielded no additional information from Perl’s LDAP 
library, still only "ERR: Could not open LDAP connection to *redacted*:636. 
Backing off for 60 seconds" so I decided to look into SSL issues as the next 
logical step.

It turns out that the server on which we are running Radiator is using a newer 
version of OpenSSL that enforces against using weak DH keys (to prevent Logjam 
attack).  Using "openssl s_client -showcerts" to connect and show the server 
SSL certificates, I could see openssl reporting that the certificate on the 
LDAP server was using a certificate with a “too small” DH key:

140309439825560:error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh 
key too small:s3_clnt.c:3615:

I resolved this by disallowing DH ciphers sent by the client in the radius 
config:
SSLCiphers DEFAULT:!EXPORT:!LOW:!DH

Radiator is now able to connect (and bind) to the LDAP server over SSL.

—Jennifer




> On May 11, 2016, at 9:42 AM, Tuure Vartiainen  wrote:
> 
> Hello,
> 
>> On 11 May 2016, at 01:49, Jennifer Mehl  wrote:
>> 
>> I’m working on setting up a new RADIUS client/handler, and am having trouble 
>> diagnosing why connections from Radiator to an LDAP server are failing.
>> 
>> Using the ldapsearch command from the same system, using the same 
>> AuthDN/password yields a successful result.
>> 
>> I’m wondering if there is an error being kicked off somewhere from the LDAP 
>> or SSL Perl modules that I can’t see.  Or is there an open/broken connection 
>> to the LDAP server being cached somewhere that needs a “reset?”
>> 
>> I’ve turned on Trace 5 in radius.cfg and “Debug 255” in the AuthByLDAP2 
>> clause, but not seeing a lot in the logs about the reason for the failure.
>> 
> 
> Perl’s LDAP library’s debug output, which is enabled with “Debug 255”,
> can only be seen on a console when running Radiator on a foreground.
> 
> E.g.
> 
> $ perl radiusd -config /etc/radiator/radius.cfg -trace 4 -log_stdout 
> -foreground
> 
> 
> BR
> --
> Tuure Vartiainen 
> 
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] help diagnosing failure to connect to LDAP

2016-05-11 Thread Tuure Vartiainen 
Hello,

> On 11 May 2016, at 01:49, Jennifer Mehl  wrote:
> 
> I’m working on setting up a new RADIUS client/handler, and am having trouble 
> diagnosing why connections from Radiator to an LDAP server are failing.
> 
> Using the ldapsearch command from the same system, using the same 
> AuthDN/password yields a successful result.
> 
> I’m wondering if there is an error being kicked off somewhere from the LDAP 
> or SSL Perl modules that I can’t see.  Or is there an open/broken connection 
> to the LDAP server being cached somewhere that needs a “reset?”
> 
> I’ve turned on Trace 5 in radius.cfg and “Debug 255” in the AuthByLDAP2 
> clause, but not seeing a lot in the logs about the reason for the failure.
> 

Perl’s LDAP library’s debug output, which is enabled with “Debug 255”,
can only be seen on a console when running Radiator on a foreground.

E.g.

$ perl radiusd -config /etc/radiator/radius.cfg -trace 4 -log_stdout -foreground


BR
--
Tuure Vartiainen 

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.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] help diagnosing failure to connect to LDAP

2016-05-10 Thread Jennifer Mehl 
Hello,

I’ve been using Radiator to support various services over the years.  Today, 
I’m working on setting up a new RADIUS client/handler, and am having trouble 
diagnosing why connections from Radiator to an LDAP server are failing.

Using the ldapsearch command from the same system, using the same 
AuthDN/password yields a successful result.

I’m wondering if there is an error being kicked off somewhere from the LDAP or 
SSL Perl modules that I can’t see.  Or is there an open/broken connection to 
the LDAP server being cached somewhere that needs a “reset?”

I’ve turned on Trace 5 in radius.cfg and “Debug 255” in the AuthByLDAP2 clause, 
but not seeing a lot in the logs about the reason for the failure.

I’d appreciate some assistance in tracking this down.

thank you,
Jennifer



Error message:

Tue May 10 15:10:10 2016: DEBUG: Handling with Radius::AuthGROUP:
Tue May 10 15:10:10 2016: DEBUG: Handling with Radius::AuthLDAP2: *redacted*
Tue May 10 15:10:10 2016: INFO: Connecting to *redacted*:636
Tue May 10 15:10:10 2016: ERR: Could not open LDAP connection to 
*redacted*:636. Backing off for 60 seconds.
Tue May 10 15:10:10 2016: DEBUG: Radius::AuthGROUP: redacted result: IGNORE, 
User database access error
Tue May 10 15:10:10 2016: DEBUG: AuthBy GROUP result: IGNORE, User database 
access error




Handler file:



  Identifier *redacted*


   AuthByPolicy ContinueWhileAccept


Include %D/include/*redacted*





Include %D/include/auth-log-common




Include file at %D/include/*redacted*:
--

Identifier *redacted*

Host *redacted*

Debug 255

UseSSL
SSLCAPath /etc/ssl/certs

FailureBackoffTime 60

BaseDN o=*redacted*

# Use privileged DN
AuthDN *redacted*
AuthPassword *redacted*

UsernameAttr uid


# Don't try to look up a DEFAULT user
NoDefault

PasswordAttr userPassword
ServerChecksPassword



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator