Trouble with LDAP authentication (equivalent config)


#1

RT 3.6.4 on redhat linux 4.6

I am attempting to setup a development RT site. The current issue I’m running into is getting the dev. RT to authenticate against LDAP. I have compared my RT_SiteConfig.pm between dev. and production RT (which function fine with LDAP authentication) and the RT_SiteConfig.pm seems fine.

Additionally, local login to the dev. RT is good but not w/LDAP. I did a tcpdump during a login attempt and it shows the dev. RT never makes the call to the LDAP server. Furthermore, I have tested my firewall and make certain that the LDAP server does indeed accept connection from my dev. RT server.

How do I go about troubleshooting why my dev. RT is not sending a LDAP authentication request? Is there a script, command, or “call” within RT that I can execute to confirm? I have the parameter Set($LdapExternalAuth, 1); in my RT_SiteConfig.pm and other parameters equivalent to prod. RT.

Thanks.

Mike


#2

RT 3.6.4 on redhat linux 4.6

I am attempting to setup a development RT site. The current issue
I’m running into is getting the dev. RT to authenticate against
LDAP. I have compared my RT_SiteConfig.pm between dev. and
production RT (which function fine with LDAP authentication) and the
RT_SiteConfig.pm seems fine.

Additionally, local login to the dev. RT is good but not w/LDAP. I
did a tcpdump during a login attempt and it shows the dev. RT never
makes the call to the LDAP server. Furthermore, I have tested my
firewall and make certain that the LDAP server does indeed accept
connection from my dev. RT server.

How do I go about troubleshooting why my dev. RT is not sending a
LDAP authentication request? Is there a script, command, or "call"
within RT that I can execute to confirm? I have the parameter
Set($LdapExternalAuth, 1); in my RT_SiteConfig.pm and other
parameters equivalent to prod. RT.

Thanks.

Mike

Mike,

Do you have SELinux enabled? Check your /var/log/audit/audit.log for
any ‘denied’ messages and repair them. You might need to create a
policy which allows Apache (mod_perl) or FastCGI processes to connect
to LDAP(S) via TCP.

Regards,
Tom


#3

Do you have SELinux enabled? Check your /var/log/audit/audit.log for
any ‘denied’ messages and repair them. You might need to create a
policy which allows Apache (mod_perl) or FastCGI processes to connect
to LDAP(S) via TCP.

SELinux is disabled (from /etc/selinux/config) and I do not have
the /var/log/audit/audit.log file (this is for SELinux specifically
I take it?).

Regards,

Mike

Remember to CC the list.

Yes, audit.log is created by auditd, the selinux auditing daemon.

If that’s not the case, I’m not sure as I haven’t dealt with the LDAP
authentication. However, I’d be checking the RT log for either errors
loading the LDAP module being used (Net::LDAP?), or errors produced by
that module. Also test whether Net::LDAP and RT::Authen::ExternalAuth
are installed (and installed for the correct Perl).

Regards,
Tom


#4

Yes, audit.log is created by auditd, the selinux auditing daemon.

If that’s not the case, I’m not sure as I haven’t dealt with the LDAP
authentication. However, I’d be checking the RT log for either errors
loading the LDAP module being used (Net::LDAP?), or errors produced by
that module. Also test whether Net::LDAP and RT::Authen::ExternalAuth
are installed (and installed for the correct Perl).

I’m running perl 5.8.5 and I just installed the Net::LDAP (forgot) and configure the User_Local.pm file to use LDAP (matched that of prod.).

rt_error returns the below, and I’m wondering if I need to reinstall
fast-cgi?

[Wed Jul 02 15:44:33 2008] [error] [client x.x.x.42] FastCGI: server “/opt/rt3/bin/mason_handler.fcgi” stderr: [Wed Jul 2 20:44:33 2008] [error]: FAILED LOGIN for mike from x.x.x.42 (/opt/rt3/share/html/autohandler:251), referer: http://rt-test.domain.com/

Currently, I’m using port 80 for my test RT server (instead of 443 for
production server).

Thanks.

Mike


#5

mailing list wrote:> — On Wed, 7/2/08, Tom Lanyon tom@netspot.com.au wrote:

Yes, audit.log is created by auditd, the selinux auditing daemon.

If that’s not the case, I’m not sure as I haven’t dealt with the LDAP
authentication. However, I’d be checking the RT log for either errors
loading the LDAP module being used (Net::LDAP?), or errors produced by
that module. Also test whether Net::LDAP and RT::Authen::ExternalAuth
are installed (and installed for the correct Perl).

I’m running perl 5.8.5 and I just installed the Net::LDAP (forgot) and configure the User_Local.pm file to use LDAP (matched that of prod.).

rt_error returns the below, and I’m wondering if I need to reinstall
fast-cgi?

[Wed Jul 02 15:44:33 2008] [error] [client x.x.x.42] FastCGI: server “/opt/rt3/bin/mason_handler.fcgi” stderr: [Wed Jul 2 20:44:33 2008] [error]: FAILED LOGIN for mike from x.x.x.42 (/opt/rt3/share/html/autohandler:251), referer: http://rt-test.domain.com/

You need to turn on debug-level logging to determine the cause.

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


#6

[stuff deleted]

I’m running perl 5.8.5 and I just installed the Net::LDAP (forgot)
and configure the User_Local.pm file to use LDAP (matched that of
prod.).

rt_error returns the below, and I’m wondering if I need to reinstall
fast-cgi?

[Wed Jul 02 15:44:33 2008] [error] [client x.x.x.42]
FastCGI: server "/opt/rt3/bin/mason_handler.fcgi"
stderr: [Wed Jul 2 20:44:33 2008] [error]: FAILED LOGIN for
mike from x.x.x.42 (/opt/rt3/share/html/autohandler:251),
referer: http://rt-test.domain.com/

You need to turn on debug-level logging to determine the cause.

I turned the “DEBUG => 1” but the entry in the rt_error log file is the same as above. I’ve also recompile fast-cgi still no go (every time I
made changes to RT, I stop apache, remove the cache, restart apache).

tcpdump still shows the login page never send a request to the LDAP
server. Is there a command or switch within RT that I can test
(initiates) login without going through the web? (to make certain that
RT uses Net::LDAP to initiates, etc.)

Thanks.

Mike


#7

mailing list wrote:> — On Thu, 7/3/08, Mike Peachey mike.peachey@jennic.com wrote:

[stuff deleted]

I’m running perl 5.8.5 and I just installed the Net::LDAP (forgot)
and configure the User_Local.pm file to use LDAP (matched that of
prod.).

rt_error returns the below, and I’m wondering if I need to reinstall
fast-cgi?

[Wed Jul 02 15:44:33 2008] [error] [client x.x.x.42]
FastCGI: server "/opt/rt3/bin/mason_handler.fcgi"
stderr: [Wed Jul 2 20:44:33 2008] [error]: FAILED LOGIN for
mike from x.x.x.42 (/opt/rt3/share/html/autohandler:251),
referer: http://rt-test.domain.com/

You need to turn on debug-level logging to determine the cause.

I turned the “DEBUG => 1” but the entry in the rt_error log file is the same as above. I’ve also recompile fast-cgi still no go (every time I
made changes to RT, I stop apache, remove the cache, restart apache).

tcpdump still shows the login page never send a request to the LDAP
server. Is there a command or switch within RT that I can test
(initiates) login without going through the web? (to make certain that
RT uses Net::LDAP to initiates, etc.)

You have got the Auth callback that actually calls the LDAP code haven’t
you? It would be in $RTHOME/local/html/Callbacks I think.

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


#8

You have got the Auth callback that actually calls the LDAP code
haven’t you? It would be in $RTHOME/local/html/Callbacks I think.

That was it, thank you. I copied the file for the LDAP callbacks from
production machine and now it functions! What application/file installs
the LDAP callbacks? (The dev. machine was installed with ExternalAuth,
would this have remove the LDAP callbacks?). I’m just curious what puts
the LDAP callbacks there.

Thanks a million. (been troubleshooting this for some time)

Mike


#9

mailing list wrote:> — On Thu, 7/3/08, Mike Peachey mike.peachey@jennic.com wrote:

You have got the Auth callback that actually calls the LDAP code
haven’t you? It would be in $RTHOME/local/html/Callbacks I think.

That was it, thank you. I copied the file for the LDAP callbacks from
production machine and now it functions! What application/file installs
the LDAP callbacks? (The dev. machine was installed with ExternalAuth,
would this have remove the LDAP callbacks?). I’m just curious what puts
the LDAP callbacks there.

Thanks a million. (been troubleshooting this for some time)

Mike

Technically nothing puts it there. ExternalAuth comes as an installable
package and so would put a Callback in place, but it is a callback for
the ExternalAuth package not the basic LDAP overlay.

When using the manual overlay method you must put each file in place
yourself.

I would recommend you get a copy of the original Auth callback. Rather
than mixing and matching between the old and the new. I’m not sure
precisely where it is but I’m sure it’s linked from
http://wiki.bestpractical.com/view/OldLDAP

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