RT::Authen::ExternalAuth v0.06 Released - Includes 3.8.x Compatibility

RT Developers
1

Evening All,

I am proud to announce the official release of RT::Authen::ExternalAuth

v0.06 - the first release to be out-of-the-box compatible with RT 3.8.x.
Thanks to everyone for being so patient in waiting for this, I know it
has been a long time since 3.8.0 came out, but as many know I have been
ridiculously busy.

I want to extend MASSIVE thanks to Kevin Falcone for the work he put
into this, it wouldn’t have happened without him - at least not for some
time.

I have uploaded the release to CPAN, but it may take some time for it to
become available and propagate to the mirrors. Once done, you should be
able to install it directly through the CPAN shell or find it here:

Until then, you can install directly from the BPS SVN server’s trunk, I
don’t expect trunk to be changed at least until mid next week, so you
can trust it to be the same as the release at least until it’s available
on CPAN. To get and install it from the SVN server:

$ svn co http://code.bestpractical.com/bps-public/RT-Authen-ExternalAuth
$ cd RT-Authen-ExternalAuth/trunk
$ perl Makefile.PL
$ make
$ make install

Have fun :slight_smile:

BTW, any bugs or feature requests should be submitted through the CPAN
RT system at http://rt.cpan.org.
Kind Regards,

Mike Peachey, IT
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 - Registered In England
http://www.jennic.com

2

Mike Peachey wrote:

Evening All,

I am proud to announce the official release of RT::Authen::ExternalAuth
v0.06

Ok, I was proud.

We seem to have come across a bit of a serious bug in the user
auto-creation mechanism that we are working on resolving at the moment.
If all of your users already exist in RT and you don’t expect to add new
users for some time, or you add your users into RT manually and then
just authenticate them against LDAP, then feel free to upgrade to v0.06.
However if you have been waiting to upgrade to RT-3.8.x until
ExternalAuth was available for it, I recommend holding off while we get
this little issue sorted out and release v0.07.

Sorry for the hold-up.
Kind Regards,

Mike Peachey, IT
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 - Registered In England

3

$ svn co http://code.bestpractical.com/bps-public/RT-Authen-ExternalAuth

You can use

svn co http://code.bestpractical.com/bps-public/RT-Authen-ExternalAuth -r16700

for a stable target to point svn to.

Richard

PS: Yes, this is probably too late as the new version has propagated, but
perhaps it’s useful to someone :slight_smile:

4 
   I am proud to announce the official release of RT::Authen::ExternalAuth

v0.06 - the first release to be out-of-the-box compatible with RT 3.8.x.

Mike,

I’m looking at this module for the first time this weekend. I’m
curous if there is any provision for providing multiple servers for an
LDAP service…We’ll be authenticating against active directory, and
there are multiple servers in a failover relationship. I would
ideally want to be able to provide a list of LDAP URIs to identify
potential services, e.g.L

‘servers’ => [ ‘ldaps://dc1.example.com’,
‘ldaps://ldaps://dc2.example.com/’ ],

Even outside of an AD environment, this makes a lot of sense. Most
LDAP servers provide some sort of replication feature, and it’s common
for an application server to maintain a local LDAP replica. A
configuration like:

‘servers’ => [‘ldapi://%2fvar%2flib%2fldap_sock’,
‘ldaps://dc1.example.com/’ ],

Would allow RT to talk to the local replica over a Unix socket unless
it became unavailable, in which case RT would contact the remote
server.

Lars Kellogg-Stedman lars@oddbit.com

5

‘servers’ => [ ‘ldaps://dc1.example.com’,
‘ldaps://ldaps://dc2.example.com/’ ],

I guess one could accomplish a similar effect by specifying multiple
server entries (“My_LDAP1”, “My_LDAP2”, etc), which is messy but would
at least make sure things keep running if the primary becomes
unavailable. Would this work? The downside is that RT would make
multiple queries for users that are actuall invalid, but the benefits
might be worth it. I will try to poke at this over the next few days.

Lars Kellogg-Stedman lars@oddbit.com

6

Lars Kellogg-Stedman wrote:

‘servers’ => [ ‘ldaps://dc1.example.com’,
‘ldaps://ldaps://dc2.example.com/’ ],

I guess one could accomplish a similar effect by specifying multiple
server entries (“My_LDAP1”, “My_LDAP2”, etc), which is messy but would
at least make sure things keep running if the primary becomes
unavailable. Would this work? The downside is that RT would make
multiple queries for users that are actuall invalid, but the benefits
might be worth it. I will try to poke at this over the next few days.

This is precisely how it is meant to work. I know it’s not perfect, but
it should do the job. The idea of ExternalAuthPriority and
ExternalInfoPriority is that you can specify as many external sources as
you like, be they LDAP or MySQL or Oracle, and you can then have them
checked in whatever order you please for Auth and for Info until a match
is found providing a failover service or multiple source service (i.e.
Auth out of LDAP, but get Info only from a database).

Yes, it does mean that unknown users will be checked against all
sources, but how many unknown users do you have trying to login to RT
every day? Perhaps in the future, this may be implemented a little
better, but as I said, for now at least, it should work.

With regard to using local sockets, it’s not something I have looked
into, however the main concern is the capability of Graham Barr’s
Perl-LDAP (Net::LDAP) because that’s what is used for LDAP
functionality. Anything Net::LDAP can query, ExternalAuth should be able
to query too so long as you pass it the right params from the config. If
there’s anything the ExternalAuth config isn’t correctly constructed to
pass to Net::LDAP, let me know and I’ll look into it.

Worth saying that the databse interface works the same way, Perl-DBI is
used to connect to databases and so anything DBI can connect to,
ExternalAuth should be able to connect to.
Kind Regards,

Mike Peachey, IT
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 - Registered In England

7

We run with DNS round robin for this: we have an ldap CNAME and
associate that with the Windows DCs. I guess you could even make a call
to DNS for the srv records of the DCs if you wanted to.

Regards

John

[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Lars
Kellogg-StedmanSent: 01 November 2008 19:14
To: mike.peachey@jennic.com
Cc: RT Users
Subject: Re: [rt-users] RT::Authen::ExternalAuth v0.06 Released -
Includes3.8.x Compatibility

‘servers’ => [ ‘ldaps://dc1.example.com’,
‘ldaps://ldaps://dc2.example.com/’ ],

I guess one could accomplish a similar effect by specifying multiple
server entries (“My_LDAP1”, “My_LDAP2”, etc), which is messy but would
at least make sure things keep running if the primary becomes
unavailable. Would this work? The downside is that RT would make
multiple queries for users that are actuall invalid, but the benefits
might be worth it. I will try to poke at this over the next few days.

Lars Kellogg-Stedman lars@oddbit.com
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

FMG Support is committed to reducing its impact on the environment. Please don’t print this email unless absolutely necessary.

We have taken all reasonable precautions to ensure that no viruses are transmitted from FMG Support to any third party. FMG Support accept no responsibility for any damage or loss resulting from the use of this e-mail or its contents. This e-mail and any files transmitted with it are confidential and solely for the use of the addressee. Opinions expressed in this e-mail are those of the individual and not those of the Company unless specifically indicated to that effect. If you have received this e-mail in error please inform us and delete it from your mailbox and/or any other storage mechanism.

FMG Support Ltd T:0870 830 3830 mailto:support@fmgsupport.com.
FMG Support Ltd. Registered in England. Company registration number: 3813859. Registered office: FMG House, St Andrews Road, Huddersfield HD1 6NA.