ExternalAuth and AutoCreateNonExternalUsers

typical “i want people who aren’t authenticated via ldap to be autocreated”.

seems every problem is solved with

Set($AutoCreateNonExternalUsers, 1);

I just can’t get it to go. I always get the emails back from mailer-daemon “Could not load a valid user”. I am running rt 3.8.9 with ExternaulAuth 0.08_01. externalauth was working fine for me auth’ing to ldap even wtihout upgrading to the latest version but i decided to try it anyway to see if it would fix. my config is below. Am i doing something unobviously wrong?

Set($rtname, ‘rt.***.com’);
Set($Organization , “***.com”);
Set($MaxAttachmentSize , 10000000);
Set($WebBaseURL, “http://rt.***.com”);
Set($OwnerEmail , ‘bdial@***.com’);
Set($AutoCreate,{Privileged=>1});

DB Config

Set($DatabaseType, ‘mysql’);
Set($DatabaseUser , ‘rt_user’);
Set($DatabasePassword , ‘*********’);
Set($DatabaseName , ‘rt3’);

#Set(@Plugins,(qw(Extension::QuickDelete RT::FM)));
Set( @Plugins, qw(RT::Authen::ExternalAuth) );
Set($ExternalAuthPriority, [ ‘My_LDAP’ ] );
Set($ExternalInfoPriority, [ ‘My_LDAP’ ] );
Set($ExternalServiceUsesSSLorTLS, 0);
Set($AutoCreateNonExternalUsers, 1);
Set($ExternalSettings, {
‘My_LDAP’ => {
‘type’ => ‘ldap’,
‘server’ => ‘ldap.***.com’,
‘user’ => ‘cn=**,dc=,dc=com’,
‘pass’ => '
’,
‘base’ => ‘dc=**,dc=com’,
‘filter’ => '(uidNumber=
)’,
‘d_filter’ => ‘(objectClass=butt)’,
‘tls’ => 0,
‘ssl_version’ => 3,
‘attr_match_list’ => [ ‘Name’,
‘EmailAddress’,
‘RealName’,
],
‘attr_map’ => { ‘Name’ => ‘uid’,
‘EmailAddress’ => ‘mail’,
‘RealName’ => ‘displayName’,
}
}
}
);

1;

“RK&K” and “RK&K Engineers” are registered trade names of Rummel, Klepper & Kahl, LLP, a Maryland
limited liability partnership. This message contains confidential information intended only for
the person or persons named above. If you have received this message in error, please immediately
notify the sender by return email and delete the message. Thank you.

typical “i want people who aren’t authenticated via ldap to be autocreated”.

seems every problem is solved with

Set($AutoCreateNonExternalUsers, 1);

I just can’t get it to go. I always get the emails back from mailer-daemon “Could not load a valid user”. I am running rt 3.8.9 with ExternaulAuth 0.08_01. externalauth was working fine for me auth’ing to ldap even wtihout upgrading to the latest version but i decided to try it anyway to see if it would fix. my config is below. Am i doing something unobviously wrong?

You also need to make sure that the newly created users would be able to
CreateTicket or Reply, etc. Look at your RT logs too.

Thomas

Hi all,

the following problem is very annoying:

RT Encodes Subject lines using the following concept:

Original example Header

=?UTF-8?B?cmjDtmh1bmcgd2FzbWFpbjogNTAwIEdC?=

The header is split into 2 parts:

1st part decoded: "[Queue Name #Ticket nubmer] First part of subject line"
2nd part decoded: “Second part of subject line”

Completely decoded string: “[Queue Name #Ticket nubmer] First part of
subject line”_“Second part of subject line”

The underscore (_) marks an additional space character which is
introduced into ALL emails on decoding the two UTF parts.

I double checked with decoding UTF in python. Results: When using 2 UTF
parts, a decode introduces an additional space. When using only ONE
UTF-string (the above subject w/o padding and UTF header) the decode is
done correctly!

If would be very glad the resolve this problem. If RT could use only one
UTF string, the problem would go away.
How can we do that?
And: does anyone have the same problem with email clients (we use
evolution and thunderbird, but most likely other clients are also affected).

p.s. It’s unclear to me when UTF encoding is used. Sometimes the Subject
line is not UTF encoded and uses ASCII. Perhaps it depends on non-ASCII
characters within the subject.

greetings,
l.r.

the following problem is very annoying:
RT Encodes Subject lines using the following concept:

Which version of RT

Sorry,

forgot that… :frowning:

It is v3.8.8 (clean install)

greetings,
l.r.On 03/18/2011 03:28 PM, Kevin Falcone wrote:

On Fri, Mar 18, 2011 at 03:14:17PM +0100, Lars Reimann wrote:

the following problem is very annoying:
RT Encodes Subject lines using the following concept:
Which version of RT

Original example Header

Subject: =?UTF-8?B?W3NlcnZpY2UubWV0YXdheXMubmV0ICM2NzAyOF0gU3BlaWNoZXJwbGF0eiBF?=
=?UTF-8?B?cmjDtmh1bmcgd2FzbWFpbjogNTAwIEdC?=

The header is split into 2 parts:

1st part decoded: "[Queue Name #Ticket nubmer] First part of subject line"
2nd part decoded: “Second part of subject line”

Completely decoded string: “[Queue Name #Ticket nubmer] First part
of subject line”_“Second part of subject line”

The underscore (_) marks an additional space character which is
introduced into ALL emails on decoding the two UTF parts.

I double checked with decoding UTF in python. Results: When using 2
UTF parts, a decode introduces an additional space. When using only
ONE UTF-string (the above subject w/o padding and UTF header) the
decode is done correctly!

If would be very glad the resolve this problem. If RT could use only
one UTF string, the problem would go away.
How can we do that?
And: does anyone have the same problem with email clients (we use
evolution and thunderbird, but most likely other clients are also
affected).

p.s. It’s unclear to me when UTF encoding is used. Sometimes the
Subject line is not UTF encoded and uses ASCII. Perhaps it depends
on non-ASCII characters within the subject.

greetings,
l.r.

Lars Reimann
System Engineer

Metaways Infosystems GmbH
Pickhuben 2, 20457 Hamburg

Tel: +49 (0)40 31 70 31 - 527
Fax: +49 (0)40 31 70 31 - 927

l.reimann@metaways.de
www.metaways.de

Metaways Infosystems GmbH - Sitz: D-22967 Tremsb�ttel
Handelsregister: Amtsgericht L�beck, HRB 4508 AH
Gesch�ftsf�hrung: Hermann Thaele, L�der-H. Thaele

Hi all,

the following problem is very annoying:

RT Encodes Subject lines using the following concept:

Original example Header

Subject:
=?UTF-8?B?W3NlcnZpY2UubWV0YXdheXMubmV0ICM2NzAyOF0gU3BlaWNoZXJwbGF0eiBF?=
=?UTF-8?B?cmjDtmh1bmcgd2FzbWFpbjogNTAwIEdC?=

The header is split into 2 parts:

1st part decoded: "[Queue Name #Ticket nubmer] First part of subject line"
2nd part decoded: “Second part of subject line”

Completely decoded string: “[Queue Name #Ticket nubmer] First part of
subject line”_“Second part of subject line”

The underscore (_) marks an additional space character which is
introduced into ALL emails on decoding the two UTF parts.

I think this is actually a bug in Encode::MIME::Header’s
parsing/generation of the encoded header lines. I tracked it down when
it broke a test in other code. I believe it was introduced with the fix
for https://rt.cpan.org/Public/Bug/Display.html?id=40027.

I’ve copied this mail to the bug tracker for Encode.

I double checked with decoding UTF in python. Results: When using 2 UTF
parts, a decode introduces an additional space. When using only ONE
UTF-string (the above subject w/o padding and UTF header) the decode is
done correctly!

If would be very glad the resolve this problem. If RT could use only one
UTF string, the problem would go away.
How can we do that?

If you’re really, really annoyed by it, I believe you can downgrade to
an older Encode. But you’ll regain other bugs that have been fixed as
well, and I can’t suggest it.

And: does anyone have the same problem with email clients (we use
evolution and thunderbird, but most likely other clients are also
affected).

p.s. It’s unclear to me when UTF encoding is used. Sometimes the Subject
line is not UTF encoded and uses ASCII. Perhaps it depends on non-ASCII
characters within the subject.

It’s used when there are characters other than ascii in a mail header.

Thomas

i thik i figured out the problem. It seems ExternalAuth was matching me to an existing ldap user based on the real name.

I sent the message to rt queue from my comcast account and it appears as Brian Dial briandial@comcast.net
My ldap entry is real name Brian Dial and mail bdial@rkk.com

in the logs i see

[Thu Mar 17 20:37:36 2011] [error] [client 192.168.93.195] FastCGI: server “/opt/rt/bin/mason_handler.fcgi” stderr: [Fri Mar 18 00:37:36 2011] [info]: RT::Authen::ExternalAuth::CanonicalizeUserInfo returning Comments: Autocreated on ticket submission, Disabled: 0, EmailAddress: bdial@rkk.com, Name: bdial, Password: , Privileged: 0, RealName: Brian Dial (/opt/rt/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:536)
[Thu Mar 17 20:37:36 2011] [error] [client 192.168.93.195] FastCGI: server “/opt/rt/bin/mason_handler.fcgi” stderr: [Fri Mar 18 00:37:36 2011] [crit]: User creation failed in mailgateway: Name in use (/opt/rt/bin/…/lib/RT/Interface/Email.pm:244)

is htis because i have the following in my config?

                            'attr_match_list' => [ 'Name',
                                                   'EmailAddress',
                                                   'RealName',
                                                 ],

I tested it from a random msn.com address that has no real name and the autocreate worked fine.----- Original Message -----
On 17 Mar 2011 20:53, Brian Dial wrote:

typical “i want people who aren’t authenticated via ldap to be autocreated”.

seems every problem is solved with

Set($AutoCreateNonExternalUsers, 1);

I just can’t get it to go. I always get the emails back from mailer-daemon “Could not load a valid user”. I am running rt 3.8.9 with ExternaulAuth 0.08_01. externalauth was working fine for me auth’ing to ldap even wtihout upgrading to the latest version but i decided to try it anyway to see if it would fix. my config is below. Am i doing something unobviously wrong?

You also need to make sure that the newly created users would be able to
CreateTicket or Reply, etc. Look at your RT logs too.

Thomas

“RK&K” and “RK&K Engineers” are registered trade names of Rummel, Klepper & Kahl, LLP, a Maryland
limited liability partnership. This message contains confidential information intended only for
the person or persons named above. If you have received this message in error, please immediately
notify the sender by return email and delete the message. Thank you.

i thik i figured out the problem. It seems ExternalAuth was matching me to an existing ldap user based on the real name.

I sent the message to rt queue from my comcast account and it appears as Brian Dial briandial@comcast.net
My ldap entry is real name Brian Dial and mail bdial@rkk.com

in the logs i see

[Thu Mar 17 20:37:36 2011] [error] [client 192.168.93.195] FastCGI: server “/opt/rt/bin/mason_handler.fcgi” stderr: [Fri Mar 18 00:37:36 2011] [info]: RT::Authen::ExternalAuth::CanonicalizeUserInfo returning Comments: Autocreated on ticket submission, Disabled: 0, EmailAddress: bdial@rkk.com, Name: bdial, Password: , Privileged: 0, RealName: Brian Dial (/opt/rt/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:536)
[Thu Mar 17 20:37:36 2011] [error] [client 192.168.93.195] FastCGI: server “/opt/rt/bin/mason_handler.fcgi” stderr: [Fri Mar 18 00:37:36 2011] [crit]: User creation failed in mailgateway: Name in use (/opt/rt/bin/…/lib/RT/Interface/Email.pm:244)

is htis because i have the following in my config?

                            'attr_match_list' => [ 'Name',
                                                   'EmailAddress',
                                                   'RealName',
                                                 ],

As the example ExternalAuth config says above attr_match_list:

The list of RT attributes that uniquely identify a user

If RealName isn’t supposed to be unique, then you probably shouldn’t
include it in that list.

Thomas

i thik i figured out the problem. It seems ExternalAuth was matching me to an existing ldap user based on the real name.

Yep - matching on RealName is seldom what you want.

Hi all.,

it seems to me like this problem is becoming more serious, as I recently
recognized:

  • If a ticket queue name has the appropriate length
    (e.g. [longqueuename.longexampledomain.com #67894] Email Subject )
    it happens, that the split occurs right in the middle of the ticket
    number, thus fragmenting it. This makes the RT unable to assign an
    fragmented answer to the correct ticket queue.

Please consider fixing it and consider the problem serious.

References
https://rt.cpan.org/Public/Bug/Display.html?id=66713
https://rt.cpan.org/Public/Bug/Display.html?id=40027

greetings,
l.r.On 03/18/2011 03:32 PM, Lars Reimann wrote:

Sorry,

forgot that… :frowning:

It is v3.8.8 (clean install)

greetings,
l.r.

On 03/18/2011 03:28 PM, Kevin Falcone wrote:

On Fri, Mar 18, 2011 at 03:14:17PM +0100, Lars Reimann wrote:

the following problem is very annoying:
RT Encodes Subject lines using the following concept:
Which version of RT

Original example Header

Subject:
=?UTF-8?B?W3NlcnZpY2UubWV0YXdheXMubmV0ICM2NzAyOF0gU3BlaWNoZXJwbGF0eiBF?=

=?UTF-8?B?cmjDtmh1bmcgd2FzbWFpbjogNTAwIEdC?=

The header is split into 2 parts:

1st part decoded: "[Queue Name #Ticket nubmer] First part of subject
line"
2nd part decoded: “Second part of subject line”

Completely decoded string: “[Queue Name #Ticket nubmer] First part
of subject line”_“Second part of subject line”

The underscore (_) marks an additional space character which is
introduced into ALL emails on decoding the two UTF parts.

I double checked with decoding UTF in python. Results: When using 2
UTF parts, a decode introduces an additional space. When using only
ONE UTF-string (the above subject w/o padding and UTF header) the
decode is done correctly!

If would be very glad the resolve this problem. If RT could use only
one UTF string, the problem would go away.
How can we do that?
And: does anyone have the same problem with email clients (we use
evolution and thunderbird, but most likely other clients are also
affected).

p.s. It’s unclear to me when UTF encoding is used. Sometimes the
Subject line is not UTF encoded and uses ASCII. Perhaps it depends
on non-ASCII characters within the subject.

greetings,
l.r.

Lars Reimann
System Engineer

Metaways Infosystems GmbH
Pickhuben 2, 20457 Hamburg

Tel: +49 (0)40 31 70 31 - 527
Fax: +49 (0)40 31 70 31 - 927

l.reimann@metaways.de
www.metaways.de

Metaways Infosystems GmbH - Sitz: D-22967 Tremsb�ttel
Handelsregister: Amtsgericht L�beck, HRB 4508 AH
Gesch�ftsf�hrung: Hermann Thaele, L�der-H. Thaele

Hi all.,

it seems to me like this problem is becoming more serious, as I
recently recognized:

  • If a ticket queue name has the appropriate length
    (e.g. [longqueuename.longexampledomain.com #67894] Email Subject )
    it happens, that the split occurs right in the middle of the ticket
    number, thus fragmenting it. This makes the RT unable to assign an
    fragmented answer to the correct ticket queue.

Please consider fixing it and consider the problem serious.

As Tom mentioned in the ticket you link and in earlier mail, the
problem appears to be in Encode, not in our code, so we’re waiting on
the bug to be resolved upstream.

As Tom also mentioned, you can downgrade Encode, but you may have
other bugs.

-kevin