RT 3.6.5 LDAP authentication and Active Directory

Hi,

I’m trying to get our rt install to authenticate with Active Directory.

I’ve got the configuration from these two links into our RT_SiteConfig.pm:

http://wiki.bestpractical.com/view/LDAP

http://wiki.bestpractical.com/view/LdapSiteConfigSettingsForActiveDirectory

At this point, I’m just trying to get authentication to work, I’m not trying to add create users or anything like that. I’ve stripped the configuration down to a minimum and I’m still getting:

[Wed Mar 19 17:57:02 2008] [debug]: Trying LDAP authentication (/usr/local/rt/local/lib/RT/User_Local.pm:155)
[Wed Mar 19 17:57:02 2008] [debug]: RT::User::IsPassword auth method IsLDAPPassword FAILED (/usr/local/rt/local/lib/RT/User_Local.pm:293)
[Wed Mar 19 17:57:02 2008] [info]: RT::User::IsInternalPassword AUTH FAILED: FOO (/usr/local/rt/local/lib/RT/User_Local.pm:257)
[Wed Mar 19 17:57:02 2008] [debug]: RT::User::IsPassword auth method IsInternalPassword FAILED (/usr/local/rt/local/lib/RT/User_Local.pm:293)
[Wed Mar 19 17:57:02 2008] [error]: FAILED LOGIN for FOO from 172.16.9.188 (/usr/local/rt/share/html/autohandler:251)

I’ve increased the logging level to debug but it isn’t pointing me any closer to a resolution. Is there any increased logging that I can enable to attempt to find the actual problem?

I can still login to rt using the internal authentication method just not LDAP.

I’ve got the utility called Active Directory Explorer from sysinternals.com - there are three attributes named badPwdCount, badPasswordTime and logonCount stored in Active Directory. None of those three have changed in all of my testing.

I did make a slight change to $LdapUser and started getting an additional error in the log that led me to believe that I had at least that parameter and LdapPass correct (again, I’m using my userid to view AD).

Thanks in advance,

Kevin

I think I got it to work, changed LdapFilter to * rather than just commenting the line out. I knew we didn’t have posixAccount in that attribute but didn’t know I would actually need it enabled.

sorry for the wasted bandwidth,

Kevin

At 02:19 PM 3/19/2008, Kevin Sheen wrote:

I’ve recently upgraded to rt3.8.3 from 3.6.5 and everything is working
very well except that I’ve just discovered that a query based on
"Content" is case sensitive. I’ve tried other queries based on
"Subject" and “Requestor” etc and they are all case insensitive.
Looking at the mysql upgrade script, I think that Content has been
changed to longblob and that type is case sensitive according to mysql
documentation.

Has anyone else noticed this behaviour and are there suggestions for a
workaround?

Thanks,
Dan

I’ve noticed that using the query builder with the “Content” field is
case sensitive. I’ve tried other queries based on fields such as
"Subject" and “Requestor” etc and they are all case INsensitive.
Looking at the mysql upgrade script, I think that Content has been
changed to longblob in RT 3.8.3 and that type is case sensitive
according to mysql documentation. Everything I’ve found on the wiki
seems to imply that queries should all be case INsensitive.

Has anyone else noticed this behaviour and are there suggestions for a
workaround?

Thanks,
Dan

This document (or software if applicable) may contain data whose export/transfer/disclosure is restricted by U.S. or Canadian law. Dissemination may require an export license or other authorization.
CONFIDENTIALITY NOTICE: The information in this message, as well as any attachments, previous e-mail messages and /or any links provided herein, is Proprietary/Confidential information belonging to ELCAN Optical Technologies, and its affiliates, and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error.
WARNING: Malicious code including viruses can be transmitted via email. Although ELCAN has taken reasonable precautions to ensure no malicious code is present in this email, non-encrypted electronic transmissions cannot be guaranteed to be secure or error-free as information could be intercepted and manipulated therefore ELCAN does not accept any responsibility for any loss or damage arising from the use of this email or attachments.

Hello,

It’s side effect of conversion to blob instead of text. Content can
not be of text type cuz it can contain binary data. May be we can come
up with some patch that workaround this for full text searches, but
I’m afraid that will make searches even slower.On Tue, Jul 14, 2009 at 4:02 PM, Lamers, Dandlamers@elcan.com wrote:

I’ve noticed that using the query builder with the “Content” field is
case sensitive. I’ve tried other queries based on fields such as
"Subject" and “Requestor” etc and they are all case INsensitive.
Looking at the mysql upgrade script, I think that Content has been
changed to longblob in RT 3.8.3 and that type is case sensitive
according to mysql documentation. Everything I’ve found on the wiki
seems to imply that queries should all be case INsensitive.

Has anyone else noticed this behaviour and are there suggestions for a
workaround?

Thanks,
Dan

Best regards, Ruslan.