On 10 Oct 2016, at 16:26, Jan Burian wrote:

Hi all,

we have RT 4.4.0 on CentOS 7 and Perl v5.22.1. And we are starting to
use RT in production.

We configured RT to authenticate users via LDAP
(RT::Authen::ExternalAuth::LDAP). Our LDAP server is MS AD (Win 2008 R2).
Authentication is working fine. Users can log in, if the user doesn't
exist in RT the account is autocreated. All the configured attributes
are transferred.

This is a strong sign that the LDAP part is working correctly. If the LDAP server (AD) and client (Perl's Net::LDAP module) are using mismatched encodings, it is likely to show up in authentication failures due to incompatible encodings of the same (logical) characters that 8-bit encodings assign to byte values 0x80-0xff.

Fortunately, it is somewhere between arcane and impossible to make Net::LDAP use anything other than UTF-8. There's *probably* some way to make it do T.61 for ancient-history compatibility, but that's mostly pointless.

We had similar problem with Moodle. When we configured Moodle against
Active Directory and set cp1250 encoding, then it was doing exactly same
thing. After we changed encoding for LDAP connector to utf-8 then the
names was

Which makes sense: LDAP v3 by default uses UTF-8 and you have a modern system with a mature LDAP client. I know of no way to configure a CentOS 7/Perl 5.22 system such that the LDAP interaction with an AD LDAP server talking UTF-8 would be the source of this sort of encoding conflict. I'm mildly surprised that anything talking LDAPv3 can be made to use cp1250 encoding, but I suppose Microsoft makes their own rules to go along with their own unique code pages.

Also I red thath MS AD in LDAP protocol version 3 returns any string to
LDAP client in utf-8 encoding.
I really don't know where could be a problem.

The most likely place is in your database. I'm guessing that you are using MySQL, which defaults to latin1 encoding. When you store a UTF-8 string into a latin1 table, it breaks any multi-byte characters into 2 or 3 characters, but the right bits are still there. This issue has come up a few times on this list over the past decade and I think Best Practical has documented how to safely convert a RT database with that sort of problem from latin1 to utf8. It is probably worth looking through their docs (possibly one of the UPGRADING* files?) and the RT Wiki for a solution. I expect it could be done with a binary dump of the database, altering of any latin1 tables to use utf8, and a re-import of the binary dump. I'm not enough of a MySQL expert to detail that process (I generally use Postgres where possible.)
RT 4.4 and RTIR training sessions, and a new workshop day! 
* Boston - October 24-26
* Los Angeles - Q1 2017

Reply via email to