Some external users not being AutoCreate'd

RT Users
1

RT 4.2.2
RT::Authen::ExternalAuth 0.17
MySQL 5.1.71-1
httpd 2.2.15-29
CentOS 6.5

We have RT-Authen-ExternalAuth working with the organization’s AD server
(LDAP). All personnel on the domain are able to log in with their AD
account and their RT account is automatically created. This is working
flawlessly.

Generally, external users sending an email to create a ticket are having
their unprivileged accounts created as expected. However, there seems to be
an intermittent issue preventing others from having the same result. There
doesn’t appear to be any rhyme or reason to it.

Relevant RT_SiteConfig.pm configuration:

Set($AutoCreate,{Privileged=>0});
Set($AutoCreateNonExternalUsers, 1);

Set($ExternalSettings, {
‘AD’ => {
‘type’ => ‘ldap’,
‘server’ => ‘dc1.example.local’,
‘user’ => ‘RTuser’,
‘pass’ => ‘xxxxxxxx’,
‘base’ => ‘dc=example,dc=local’,
‘filter’ => ‘(objectClass=person)’,
‘attr_match_list’ => [
‘Name’,
‘EmailAddress’,
‘RealName’,
],
‘attr_map’ => {
‘Name’ => ‘sAMAccountName’,
‘EmailAddress’ => ‘mail’,
‘RealName’ => ‘cn’,
},
},
} );

Relevant RT log example:

[15816] [Fri Feb 7 05:29:01 2014] [debug]: Converting ‘cp1252’ to ‘utf-8’
for text/plain - Subjectless message (/opt
/rt4/sbin/…/lib/RT/I18N.pm:295)
[15816] [Fri Feb 7 05:29:01 2014] [debug]: Converting ‘cp1252’ to ‘utf-8’
for text/html - Subjectless message (/opt/
rt4/sbin/…/lib/RT/I18N.pm:295)
[15816] [Fri Feb 7 05:29:01 2014] [debug]: Encode::Guess guessed encoding:
ascii (/opt/rt4/sbin/…/lib/RT/I18N.pm:59
5)
[15816] [Fri Feb 7 05:29:01 2014] [debug]: Encode::Guess guessed encoding:
ascii (/opt/rt4/sbin/…/lib/RT/I18N.pm:59
5)
[15816] [Fri Feb 7 05:29:01 2014] [debug]: Going to create user with
address ‘user.example@gmail.com’
(/opt/rt4/sbin/…/lib/RT/Interface/Email/Auth/MailFrom.pm:100)
[15816] [Fri Feb 7 05:29:01 2014] [debug]:
RT::Authen::ExternalAuth::CanonicalizeUserInfo called by
RT::Authen::ExternalAuth
/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm
702 with: Comments: Autocreated on ticket submission, Disabled: ,
EmailAddress: user.example@gmail.com, Name: user.example@gmail.com,
Password: , Privileged: , RealName: User Example
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:599)
[15816] [Fri Feb 7 05:29:01 2014] [debug]: Attempting to get user info
using this external service: AD
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:607)
[15816] [Fri Feb 7 05:29:01 2014] [debug]: Attempting to use this
canonicalization key: Name
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:621)
[15816] [Fri Feb 7 05:29:01 2014] [debug]: LDAP Search === Base:
dc=example,dc=local == Filter: (&(objectClass=person)(sAMAccountName=
user.example@gmail.com)) == Attrs: cn,mail,sAMAccountName
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:357)
[15816] [Fri Feb 7 05:29:01 2014] [debug]: Attempting to use this
canonicalization key: EmailAddress
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:621)
[15816] [Fri Feb 7 05:29:01 2014] [debug]: LDAP Search === Base:
dc=example,dc=local == Filter: (&(objectClass=person)(mail=
user.example@gmail.com)) == Attrs: cn,mail,sAMAccountName
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:357)
[15816] [Fri Feb 7 05:29:01 2014] [debug]: Attempting to use this
canonicalization key: RealName
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:621)
[15816] [Fri Feb 7 05:29:01 2014] [debug]: LDAP Search === Base:
dc=example,dc=local == Filter: (&(objectClass=person)(cn=User Example)) ==
Attrs: cn,mail,sAMAccountName
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm:357)
[15816] [Fri Feb 7 05:29:01 2014] [info]:
RT::Authen::ExternalAuth::CanonicalizeUserInfo returning Comments:
Autocreated on ticket submission, Disabled: , EmailAddress: user@example.com,
Name: user, Password: , Privileged: , RealName: User Example
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:685)
[15816] [Fri Feb 7 05:29:01 2014] [crit]: User could not be created: User
creation failed in mailgateway: Name in use
(/opt/rt4/sbin/…/lib/RT/Interface/Email.pm:245)
[15816] [Fri Feb 7 05:29:01 2014] [warning]: Couldn’t load user ’
user.example@gmail.com’.giving up
(/opt/rt4/sbin/…/lib/RT/Interface/Email.pm:875)
[15816] [Fri Feb 7 05:29:01 2014] [crit]: User could not be loaded: User ’
user.example@gmail.com’ could not be loaded in the mail gateway
(/opt/rt4/sbin/…/lib/RT/Interface/Email.pm:245)
[15816] [Fri Feb 7 05:29:01 2014] [error]: Could not load a valid user: RT
could not load a valid user, and RT’s configuration does not allow
for the creation of a new user for this email (user.example@gmail.com).

You might need to grant ‘Everyone’ the right ‘CreateTicket’ for the
queue provisioning. (/opt/rt4/sbin/…/lib/RT/Interface/Email.pm:245)
[15816] [Fri Feb 7 05:29:01 2014] [error]: Could not load a valid user: RT
could not load a valid user, and RT’s configuration does not allow
for the creation of a new user for your email.
(/opt/rt4/sbin/…/lib/RT/Interface/Email.pm:245)
[15816] [Fri Feb 7 05:29:01 2014] [error]: Could not record email: Could
not load a valid user (/opt/rt4/share/html/REST/1.0/NoAuth/mail-gateway:75)

The Everyone group already has the CreateTicket and ReplyToTicket rights on
all of the queues that have been configured.

One thing that stands out is [15816] [Fri Feb 7 05:29:01 2014] [crit]:
User could not be created: User creation failed in mailgateway: Name in use
(/opt/rt4/sbin/…/lib/RT/Interface/Email.pm:245). However, if I search on
the user’s email address as the name it says nothing can be found.

I also noticed that the queue being referenced is ‘provisioning’. It
actually is ‘Provisioning’. Is case important?

-Mathew

“When you do things right, people won’t be sure you’ve done anything at
all.” - God; Futurama

“We’ll get along much better once you accept that you’re wrong and neither
am I.” - Me

2

…

[15816] [Fri Feb 7 05:29:01 2014] [debug]: Going to create user with
address ‘user.example@gmail.com mailto:user.example@gmail.com’
(/opt/rt4/sbin/…/lib/RT/Interface/Email/Auth/MailFrom.pm:100)
…
[15816] [Fri Feb 7 05:29:01 2014] [info]:
RT::Authen::ExternalAuth::CanonicalizeUserInfo returning Comments:
Autocreated on ticket submission, Disabled: , EmailAddress:
user@example.com mailto:user@example.com, Name: user, Password: ,
Privileged: , RealName: User Example
(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:685)

If these logs are correct then the user has two or more email addresses
in LDAP and user@example.com is already in the RT database. The user
sends from the second address user.example@gmail.com. This is not
supported (yet).

Users with multiple email addresses in LDAP are not supported (even
though some docs say otherwise). We have just discussed this recently.
See this thread:

http://lists.bestpractical.com/pipermail/rt-users/2014-January/082549.html

The user must use the email address in the RT database. Mails from any
other email address in LDAP is rejected because the user already exists
in the RT database.

You may try to manually create a second RT user with the second email
address and then use the MergeUser extension to merge the accounts.

-Gerald

3

A user who sends in an email for the first time should generate an
unprivileged account which sets the username as the email address. It
doesn’t exist so it should be created.On Feb 9, 2014 9:09 PM, “Gerald Vogt” vogt@spamcop.net wrote:

On 10.02.2014 06:46, Mathew Snyder wrote:
…

[15816] [Fri Feb 7 05:29:01 2014] [debug]: Going to create user with
address ‘user.example@gmail.com mailto:user.example@gmail.com’
(/opt/rt4/sbin/…/lib/RT/Interface/Email/Auth/MailFrom.pm:100)
…
[15816] [Fri Feb 7 05:29:01 2014] [info]:
RT::Authen::ExternalAuth::CanonicalizeUserInfo returning Comments:
Autocreated on ticket submission, Disabled: , EmailAddress:
user@example.com mailto:user@example.com, Name: user, Password: ,
Privileged: , RealName: User Example

(/opt/rt4/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth.pm:685)

If these logs are correct then the user has two or more email addresses
in LDAP and user@example.com is already in the RT database. The user
sends from the second address user.example@gmail.com. This is not
supported (yet).

Users with multiple email addresses in LDAP are not supported (even
though some docs say otherwise). We have just discussed this recently.
See this thread:

[rt-users] RT 4.2.1 - ExternalAuth against LDAP server and users with multiple mail addresses

The user must use the email address in the RT database. Mails from any
other email address in LDAP is rejected because the user already exists
in the RT database.

You may try to manually create a second RT user with the second email
address and then use the MergeUser extension to merge the accounts.

-Gerald

4

A user who sends in an email for the first time should generate an
unprivileged account which sets the username as the email address. It
doesn’t exist so it should be created.

The user has been created with e-mail address user@example.com mapping
to user name “user”.

Now the user sends e-mail from e-mail address user.example@gmail.com
which you map to the same user “user” with LDAP. That’s not supported.
That would mean the same LDAP user has two e-mail addresses.

You match users in LDAP using either of these attributes:

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

If you don’t have the gmail address in LDAP then it’s probably the real
name which matches. With your configuration you can only have one RT
account for each real name. Thus if there is another “Mathew Snyder”
with a different e-mail address it gets rejected because again.

You don’t want RealName in attr_match_list unless you are sure that each
real name will only match to a single person with a single e-mail address.

-Gerald

5

-Mathew

“When you do things right, people won’t be sure you’ve done anything at
all.” - God; Futurama

“We’ll get along much better once you accept that you’re wrong and neither
am I.” - Me

A user who sends in an email for the first time should generate an
unprivileged account which sets the username as the email address. It
doesn’t exist so it should be created.

The user has been created with e-mail address user@example.com mapping
to user name “user”.

Now the user sends e-mail from e-mail address user.example@gmail.com
which you map to the same user “user” with LDAP. That’s not supported.
That would mean the same LDAP user has two e-mail addresses.

You match users in LDAP using either of these attributes:

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

If you don’t have the gmail address in LDAP then it’s probably the real
name which matches. With your configuration you can only have one RT
account for each real name. Thus if there is another “Mathew Snyder”
with a different e-mail address it gets rejected because again.

You don’t want RealName in attr_match_list unless you are sure that each
real name will only match to a single person with a single e-mail address.

I asked the person that is doing most of the grunt work to look into this.
Rather than comment out the RealName setting under attr_match_list he
commented it out under attr_map. This seems to have ad the same effect as
it no longer creates a second account with the same real name as another
that is in LDAP.

I’m not entirely sure why RT should care about a person’s actual name. The
username is really all that is relevant. This seems to be a failure on the
designers part, as far as I’m concerned.

6

I asked the person that is doing most of the grunt work to look into
this. Rather than comment out the RealName setting under attr_match_list
he commented it out under attr_map. This seems to have ad the same

If you do that RT won’t set the real name from LDAP into the RT
database. You won’t see the real name unless the user sets it in
preferences. The attr_map synchronizes data from LDAP into the RT
database…

effect as it no longer creates a second account with the same real name
as another that is in LDAP.

I’m not entirely sure why RT should care about a person’s actual name.

It doesn’t. You have configured it this way. You made RT care about the
real name.

The username is really all that is relevant. This seems to be a failure
on the designers part, as far as I’m concerned.

It’s in the documentation. You have to match the users in LDAP to the RT
database somehow. You have to configure that. Not everyone wants to use
the username. Some people use the email address.

You have to configure it. You get what you configure.

Gerald