REALLY Confused about RT Extension ExternalAuth and LDAP

RT Users
1

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?

If so, what files do I move over from my 3.6.4 files, if anything?

My 3.6.4 RT_SiteConfig “Auth” settings show the following:

Set($AuthMethods, [‘LDAP’, ‘Internal’]);
Set($LdapExternalAuth, 1); # enable LDAP authentication/lookups
Set($LdapExternalInfo, 1);
Set($LdapAutoCreateNonLdapUsers, 0);

So, for 3.8.6 I set up my RT_SiteConfig settings to this:

Now what follows are the settings for LDAP Authorization

Set($AuthMethods, [‘My_LDAP’, ‘Internal’]);
Set($ExternalAuthPriority, [‘My_LDAP’]);
Set($ExternalInfoPriority, [‘My_LDAP’]);
Set($LdapExternalAuth, 1); # enable LDAP authentication/lookups
Set($LdapAutoCreateNonLdapUsers, 0);
Set($CanonicalizeOnCreate , 0);
Set($LdapTLS, 1);
Set($LdapSSLVersion, 3);

And my Plugin array to this:

Set(@Plugins,(qw(Extension::QuickDelete RT::FM RTx::Calendar RT::Extension::Timeline
RT::Authen::ExternalAuth RT::Extension::CommandByMail RT::Extension::ExtractCustomFieldValues
RT::Extension::SearchResults::XLS)));

I saw some bug reports on ExternalAuth v.08. Is that fixed yet?
Do I even need it if I’m using LDAP?

Also, for each Plugin in my array, what corresponding files do I need and where do I put them?

I know this is a lot to ask, but I really need the help or I go nowhere from here.

Thanks.

Kenn
LBNL

2

said:

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?

If so, what files do I move over from my 3.6.4 files, if anything?

I’m not sure what the LDAP auth support was in 3.6.x, I’m using the
ExternalAuth plugin (v0.8) with RT 3.8.x with no issues.

My 3.6.4 RT_SiteConfig “Auth” settings show the following:

Again, not sure about 3.6’s LDAP support, so I can’t comment on
that…but the documentation seems to imply that all LDAP auth support
was moved out of RT and is now soley supported by the ExternalAuth
plugin.

So, for 3.8.6 I set up my RT_SiteConfig settings to this:

Now what follows are the settings for LDAP Authorization

Set($AuthMethods, [‘My_LDAP’, ‘Internal’]);
Set($ExternalAuthPriority, [‘My_LDAP’]);
Set($ExternalInfoPriority, [‘My_LDAP’]);
Set($LdapExternalAuth, 1); # enable LDAP authentication/lookups
Set($LdapAutoCreateNonLdapUsers, 0);
Set($CanonicalizeOnCreate , 0);
Set($LdapTLS, 1);
Set($LdapSSLVersion, 3);

Doesn’t appear correct for ExternalAuth’s configuration, once you
install ExternalAuth you can look at a sample config file in
local/plugins/RT-Authen-ExternalAuth/etc/RT_SiteConfig.pm I’ll attach a
sanitized and commented snippet of my config as well that you can use as
a starting point.

I saw some bug reports on ExternalAuth v.08. Is that fixed yet?
Do I even need it if I’m using LDAP?

I haven’t been bitten by any bugs in it yet, but I’m curious to know
what bugs exist.

Also, for each Plugin in my array, what corresponding files do I need and
where do I put them?

Each plugin you have should have a config and install script…any
configuration they use should be in RT_SiteConfig.pm, so a fresh install
of those plugins into your new RT 3.8 directory should be fine as long
as you copy relevant lines over from your RT 3.6 config.

ldap_config (2.34 KB)

3

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: LdapSummary - Request Tracker Wiki).
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

signature.asc (259 Bytes)