[rt-users] LDAP ExternalAuth broken after upgrade from 4.0.2 to 4.0.4

2011-11-23 Thread Karl Boyken
We run RT on RedHat Enterprise Server 6.1, with Perl 5.14.2.  We set up 
RT::ExternalAuth to authenticate against our OpenLDAP server, and it 
works fine with RT 4.0.2.  But after upgrading to RT 4.0.4, LDAP 
authentication breaks.  I'd appreciate any helpful ideas.  Here's the 
relevant log entry--it's an LDAP bind() error:



Nov 23 11:27:28 serv07 RT: 
RT::Authen::ExternalAuth::LDAP::_GetBoundLdapObj Can't bind: 
LDAP_OPERATIONS_ERROR 1 
(/path_to_our_RT/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:467)



This is the relevant section of our RT_SiteConfig.pm file (where values 
beginning with our have been changed for posting):



# To enable RT::Authen::ExternalAuth
Set(@Plugins, qw(RT::Authen::ExternalAuth));

# RT::Authen::ExternalAuth settings
# For information on configuring RT::Authen::ExternalAuth, see
# $RT_HOME/local/plugins/RT-Authen-ExternalAuth/etc/RT_SiteConfig.pm

Set($ExternalAuthPriority, ['DIVMS_LDAP',]);
Set($ExternalInfoPriority, ['DIVMS_LDAP',]);
Set($ExternalServiceUsesSSLorTLS, 1);
Set($AutoCreateNonExternalUsers, 1);
Set($ExternalSettings,
{
 'DIVMS_LDAP' = {
  'type' = 'ldap',
  'server' = 'our_server',
  'user' = 'our_cn',
  'pass' = 'our_password',
  'base' = 'our_base',
  'filter' = '(objectClass=*)',
  'd_filter' = '(objectClass=FooBarBaz)',
  'tls' = 1,
  'ssl_version' = 1,
  'net_ldap_args' = [ port = 389, version = 3 ],
  'group' = '',
  'group_attr' = '',
  'attr_match_list' = [ 'Name', 'EmailAddress', ],
  'attr_map' = {
 'Name' = 'uid',
 'EmailAddress' = 'mail',
 'RealName' = 'gecos',
 'ExternalAuthId' = 'uid',
 'Gecos' = 'uid',
}
 }
}
);

--
Karl Boyken, system administrator 
karl-boy...@uiowa.edu
303A MLH, Dept. of Comp. Sci. 
http://www.cs.uiowa.edu/~boyken/
The U. of Iowa, Iowa City, IA  52242   319-335-2730 (voice) 
319-335-3668 (fax)


RT Training Sessions (http://bestpractical.com/services/training.html)
*  Barcelona, Spain  November 28  29, 2011


Re: [rt-users] LDAP ExternalAuth broken after upgrade from 4.0.2 to 4.0.4

2011-11-23 Thread Karl Boyken
From the LDAP server logs, it looks like a TLS negotiation failure. 
So, how does upgrading to 4.0.4 break RT::ExternalAuth TLS negotiation? 
 I'm using the same settings for 4.0.4 as I do for 4.0.2.  I reverted 
to 4.0.2, and LDAP works.


Karl


Message: 6 Date: Wed, 23 Nov 2011 13:53:22 -0500 From: Kevin Falcone 
falc...@bestpractical.com To: rt-users@lists.bestpractical.com Subject: Re: [rt-users] LDAP 
ExternalAuth broken after upgrade from 4.0.2 to 4.0.4 Message-ID: 
2023185322.gu1...@jibsheet.com Content-Type: text/plain; charset=us-ascii On 
Wed, Nov 23, 2011 at 11:46:44AM -0600, Karl Boyken wrote:

 We run RT on RedHat Enterprise Server 6.1, with Perl 5.14.2.  We set
 up RT::ExternalAuth to authenticate against our OpenLDAP server, and
 it works fine with RT 4.0.2.  But after upgrading to RT 4.0.4, LDAP
 authentication breaks.  I'd appreciate any helpful ideas.  Here's
 the relevant log entry--it's an LDAP bind() error:


 Nov 23 11:27:28 serv07 RT:
 RT::Authen::ExternalAuth::LDAP::_GetBoundLdapObj Can't bind:
 LDAP_OPERATIONS_ERROR 1 
(/path_to_our_RT/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:467)

This usually means that the LDAP server rejected you in some way.
You may find more information in the server logs, you may also set
net_ldap_args = [ debug = 2 or 8 ] in addition to your current args
to get back the full dumps of packets coming over the wire.
Please note that the debug dumps may contain privileged info, so it's
really just a debugging shim.

-kevin


--
Karl Boyken, system administrator 
karl-boy...@uiowa.edu
303A MLH, Dept. of Comp. Sci. 
http://www.cs.uiowa.edu/~boyken/
The U. of Iowa, Iowa City, IA  52242   319-335-2730 (voice) 
319-335-3668 (fax)


RT Training Sessions (http://bestpractical.com/services/training.html)
*  Barcelona, Spain  November 28  29, 2011


Re: [rt-users] LDAP ExternalAuth broken after upgrade from 4.0.2 to 4.0.4

2011-11-23 Thread mjames
I just upgraded from 4.0.2 to 4.0.4 without issue. Simple questions - did you 
remember to upgrade the database as well? Also, perhaps you should run make 
testdeps and make sure all your dependencies are still fulfilled. After the 
upgrade, I had a different problem where the permissions on the mason_data 
folder had changed and that caused a permissions failure.

Just nitpicking, since your config worked previously, but you shouldn't need a 
trailing comma in these 2 settings.
Set($ExternalAuthPriority, ['DIVMS_LDAP',]);
Set($ExternalInfoPriority, ['DIVMS_LDAP',]);

Mike

-Original Message-
From: rt-users-boun...@lists.bestpractical.com 
[mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of Karl Boyken
Sent: Wednesday, November 23, 2011 12:47 PM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] LDAP ExternalAuth broken after upgrade from 4.0.2 to 4.0.4

We run RT on RedHat Enterprise Server 6.1, with Perl 5.14.2.  We set up 
RT::ExternalAuth to authenticate against our OpenLDAP server, and it works fine 
with RT 4.0.2.  But after upgrading to RT 4.0.4, LDAP authentication breaks.  
I'd appreciate any helpful ideas.  Here's the relevant log entry--it's an LDAP 
bind() error:


Nov 23 11:27:28 serv07 RT: 
RT::Authen::ExternalAuth::LDAP::_GetBoundLdapObj Can't bind: 
LDAP_OPERATIONS_ERROR 1
(/path_to_our_RT/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:467)


This is the relevant section of our RT_SiteConfig.pm file (where values 
beginning with our have been changed for posting):


# To enable RT::Authen::ExternalAuth
Set(@Plugins, qw(RT::Authen::ExternalAuth));

# RT::Authen::ExternalAuth settings
# For information on configuring RT::Authen::ExternalAuth, see
# $RT_HOME/local/plugins/RT-Authen-ExternalAuth/etc/RT_SiteConfig.pm

Set($ExternalAuthPriority, ['DIVMS_LDAP',]);
Set($ExternalInfoPriority, ['DIVMS_LDAP',]);
Set($ExternalServiceUsesSSLorTLS, 1);
Set($AutoCreateNonExternalUsers, 1);
Set($ExternalSettings,
 {
  'DIVMS_LDAP' = {
   'type' = 'ldap',
   'server' = 'our_server',
   'user' = 'our_cn',
   'pass' = 'our_password',
   'base' = 'our_base',
   'filter' = '(objectClass=*)',
   'd_filter' = '(objectClass=FooBarBaz)',
   'tls' = 1,
   'ssl_version' = 1,
   'net_ldap_args' = [ port = 389, version = 3 ],
   'group' = '',
   'group_attr' = '',
   'attr_match_list' = [ 'Name', 'EmailAddress', ],
   'attr_map' = {
  'Name' = 'uid',
  'EmailAddress' = 'mail',
  'RealName' = 'gecos',
  'ExternalAuthId' = 'uid',
  'Gecos' = 'uid',
 }
  }
 }
);

-- 
Karl Boyken, system administrator 
karl-boy...@uiowa.edu
303A MLH, Dept. of Comp. Sci. 
http://www.cs.uiowa.edu/~boyken/
The U. of Iowa, Iowa City, IA  52242   319-335-2730 (voice) 
319-335-3668 (fax)

RT Training Sessions (http://bestpractical.com/services/training.html)
*  Barcelona, Spain  November 28  29, 2011

RT Training Sessions (http://bestpractical.com/services/training.html)
*  Barcelona, Spain  November 28  29, 2011


Re: [rt-users] LDAP ExternalAuth broken after upgrade from 4.0.2 to 4.0.4

2011-11-23 Thread Kevin Falcone
On Wed, Nov 23, 2011 at 02:20:14PM -0600, Karl Boyken wrote:
 From the LDAP server logs, it looks like a TLS negotiation failure.
 So, how does upgrading to 4.0.4 break RT::ExternalAuth TLS
 negotiation?  I'm using the same settings for 4.0.4 as I do for
 4.0.2.  I reverted to 4.0.2, and LDAP works.

There have been some weird interaction with the crypt/ssl libs under
mod_perl and the gnupg libs.  It's possible that there is also
something going on with Net::LDAP's ssl settings, but that's pure
speculation.  It'd be interesting to know your apache config.

 Message: 6 Date: Wed, 23 Nov 2011 13:53:22 -0500 From: Kevin Falcone 
 falc...@bestpractical.com To: rt-users@lists.bestpractical.com Subject: 
 Re: [rt-users] LDAP ExternalAuth broken after upgrade from 4.0.2 to 4.0.4 
 Message-ID: 2023185322.gu1...@jibsheet.com Content-Type: text/plain; 
 charset=us-ascii On Wed, Nov 23, 2011 at 11:46:44AM -0600, Karl Boyken 
 wrote:
  We run RT on RedHat Enterprise Server 6.1, with Perl 5.14.2.  We set
  up RT::ExternalAuth to authenticate against our OpenLDAP server, and
  it works fine with RT 4.0.2.  But after upgrading to RT 4.0.4, LDAP
  authentication breaks.  I'd appreciate any helpful ideas.  Here's
  the relevant log entry--it's an LDAP bind() error:
 
 
  Nov 23 11:27:28 serv07 RT:
  RT::Authen::ExternalAuth::LDAP::_GetBoundLdapObj Can't bind:
  LDAP_OPERATIONS_ERROR 1 
  (/path_to_our_RT/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:467)
 This usually means that the LDAP server rejected you in some way.
 You may find more information in the server logs, you may also set
 net_ldap_args = [ debug = 2 or 8 ] in addition to your current args
 to get back the full dumps of packets coming over the wire.
 Please note that the debug dumps may contain privileged info, so it's
 really just a debugging shim.


pgppfBGOEGycC.pgp
Description: PGP signature

RT Training Sessions (http://bestpractical.com/services/training.html)
*  Barcelona, Spain — November 28  29, 2011

Re: [rt-users] LDAP ExternalAuth broken after upgrade from 4.0.2 to 4.0.4

2011-11-23 Thread Alex Vandiver
On Wed, 2011-11-23 at 16:15 -0500, Kevin Falcone wrote:
 On Wed, Nov 23, 2011 at 02:20:14PM -0600, Karl Boyken wrote:
  From the LDAP server logs, it looks like a TLS negotiation failure.
  So, how does upgrading to 4.0.4 break RT::ExternalAuth TLS
  negotiation?  I'm using the same settings for 4.0.4 as I do for
  4.0.2.  I reverted to 4.0.2, and LDAP works.
 
 There have been some weird interaction with the crypt/ssl libs under
 mod_perl and the gnupg libs.  It's possible that there is also
 something going on with Net::LDAP's ssl settings, but that's pure
 speculation.  It'd be interesting to know your apache config.

Being the same bug would require that you be running Apache with SSL
support, RT be running under mod_perl, and GPG be enabled.  If it _is_
the same bug, the following patch might help, as might switching to
FastCGI or disabling RT's GPG support.
 - Alex

8---
From e96831cf8f457b1601dc778cc336d43105f7a38b Mon Sep 17 00:00:00 2001
From: Alex Vandiver ale...@bestpractical.com
Date: Wed, 9 Nov 2011 02:35:34 -0500
Subject: [PATCH] Restore database disconnection state after successful
safe_run_child

RT::Util's safe_run_child sets its database handles to not disconnect
themselves if they are destroyed, before calling the provided function
which may fork and exec.  It explicitly re-enables those bits prior to
die'ing if the exec fails, to ensure that the database handle is torn
down correctly during the global destruction that would shortly ensue.

However, it fails to re-instate those bits after a _successful_ call.
This leaves the main database handle in a state where it does not tear
down the connection during global destruction.

This is particularly destructive in the case where:
  (a) RT uses PostgreSQL as its backend database
  (b) The database connection to PostgreSQL uses SSL, as is the default
  if the server supports it
  (c) The RT server is embedded into the Apache server using mod_perl
  (c) Apache has also loaded the SSL libraries for HTTPS support

This causes libcrypto.so to be used in two places in the Apache process,
by both Perl's binary PostgreSQL driver as well as core Apache's; they
thus share some internal state.  The lack of orderly teardown of the
SSL-enabled database connection causes corruption in the SSL engine's
internal state during the Apache shutdown process, which could lead to
segmentation faults in Apache.

Resolve this by explicitly re-instating the disconnect-on-destroy flags
after a successful safe_run_child.
---
 lib/RT/Util.pm |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/lib/RT/Util.pm b/lib/RT/Util.pm
index d2220c8..70d4625 100644
--- a/lib/RT/Util.pm
+++ b/lib/RT/Util.pm
@@ -93,6 +93,8 @@ sub safe_run_child () {
 #TODO we need to localize this
 die 'System Error: ' . $err;
 };
+$dbh-{'InactiveDestroy'} = 0 if $dbh;
+$RT::Handle-{'DisconnectHandleOnDestroy'} = 1;
 return $want? (@res) : $res[0];
 }
 
8---


RT Training Sessions (http://bestpractical.com/services/training.html)
*  Barcelona, Spain  November 28  29, 2011