[rt-users] REALLY Confused about RT Extension ExternalAuth and LDAP

[Matthew Seaman]

Ken Crocker wrote:
> To list,
> 
> I'm not an internals/Unix Admin or tech. I've been the Admin for "User 
> Support" for our RT 3.6.4 installation. We successfully use LDAP 
> Authentication.
> I've just been given the responsibility to install 3.8.6 in VM (RHEL 5.3).
> 
> I have some Unix help. However, I have to tell my guy what to 
> download/install.
> 
> So, as I have been reading past Emails about using the plugin 
> RT::Extension::ExteranlAuth, I have become quite confused. For example, 
> when I look at the BestPractical Wiki site for extensions I saw this 
> comment:
> 
> Once installed, you should view the file:
>     
> 3.4/3.6    $RTHOME/local/etc/ExternalAuth/RT_SiteConfig.pm
> 3.8        $RTHOME/local/plugins/RT-Auth-ExternalAuth/etc/RT_SiteConfig.pm
> 
> I went to our 3.6.4 directories and didn't see anything in /local/etc at all.
> 
> So, if I have been using LDAP successfully with my 3.6.4 version,
> what do I need to do in order to have it work in my 3.8.6
> installation?
> 
> Do I even need the "ExternalAuth" extension?

I think part of your confusion is because there were two different methods of hooking up RT to LDAP.  RT itself doesn't have any native LDAP-ness.  The
original method for hooking into LDAP that was popular with 3.6.x was Jim
Meyer's LDAP module (See: http://wiki.bestpractical.com/view/LdapSummary).
This has now been superceeded by RT::Extension::ExternalAuth.  Since you will
be trying out a 3.8.x installation, you should install the latest ExternalAuth,
which is version 0.08 as of this writing.

The settings you will need in RT_SiteConfig.pm for ExternalAuth will look
something like this:

Set( @Plugins, qw(
     RT::Authen::ExternalAuth
     .../other plugins/....
   )
);

# Exactly how to do the LDAP stuff
Set(
    $ExternalSettings,
    {
        'localLDAP' => {
            type            => 'ldap',
            auth            => 1,
            info            => 1,
            server          => 'ldapi://%2fvar%2frun%2fopenldap%2fldapi/',
            base            => 'ou=people,dc=example,dc=org',
            filter          => '(objectclass=inetOrgPerson)',
            d_filter        => '(employmentStatus=Terminated)',
            tls             => 0,
            group           => 'cn=rt-users,ou=people,dc=example,dc=org',
            group_attr      => 'uniqueMember',
            attr_match_list => [ 'Name', 'EmailAddress' ],
            attr_map        => {
                Name         => 'uid',
                EmailAddress => 'mail',
                RealName     => 'cn',
            }
        }
    }
);


That's with OpenLDAP -- AD is much the same idea but uses different object
classes and schema.  One gotcha I found was that you have to define the 
d_filter value to an LDAP search term that will fail for a valid account:
leaving it blank will cause all your user accounts to be discarded as
inactive.

	Cheers,

	Matthew

-- 
Dr Matthew Seaman                        The Bunker, Ash Radar Station
PGP: 0x60AE908C on servers               Marshborough Rd
Tel: +44 1304 814890                     Sandwich
Fax: +44 1304 814899                     Kent, CT13 0PL, UK 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20091117/024a2836/attachment.sig>