Greetings everyone,
I’ve done a few searches on this and found various individuals that have
come across similar problems, but none of these individuals had a
resolution that fit my situation.
RT 3.8.10
ExternalAuth0.08 (latest is 0.09 but I don’t believe the changes between
these versions are causing the issue)
I have a person in our LDAP that is attempting to send an email in as their
first interaction with RT(that I can tell). The email is rejected and they
get the “could not load user” email response. I’ve had RT running in debug
mode for a while so I have all the logging in our rt.log file.
The basics of our LDAP setup
(shortened to the important info from our RT_SiteConfig)
‘filter’ => ‘(&(objectCategory=User) (ObjectClass=Person))’,
‘d_filter’ =>
‘(userAccountControl:1.2.840.113556.1.4.803:=2)’,
‘group’ =>
‘cn=Staff,ou=Groups,’
. ‘dc=mydomain’
,
‘group_attr’ => ‘member’,
‘attr_match_list’ => [
‘Name’,
‘EmailAddress’,
],
‘attr_map’ => {
‘Name’ => ‘sAMAccountName’,
‘EmailAddress’ => [‘mail’, ‘pager’],
‘RealName’ => ‘cn’,
‘ExternalAuthId’ => ‘sAMAccountName’
Set($AutoCreateNonExternalUsers,1);
So essentially, anyone that is an enabled user, in the Staff group is
allowed to actually login to RT(this person is sending an email, not
logging, but I thought it was relevant). attr_map has “mail” and “pager” in
there because our users could be sending emails from either username@nosm.caor
alias@nosm.ca (mjohnson|mike.johnson @nosm.ca) and Ruslan helped us so that
ExternalAuth would map an email from either address to 1 user in RT
provided the AD account had mail = username@nosm.ca and pager =
alias@nosm.ca
With that said… I’m getting the following error messages in RT’s log
[Thu Dec 8 20:42:19 2011] [crit]: User creation failed in mailgateway:
Name in use (/opt/rt3/bin/…/lib/RT/Interface/Email.pm:244)
[Thu Dec 8 20:42:20 2011] [warning]: Couldn’t load user
‘somebody@nosm.ca’.giving
up (/opt/rt3/bin/…/lib/RT/Interface/Email.pm:962)
[Thu Dec 8 20:42:20 2011] [crit]: User ‘somebody@nosm.ca’ could not be
loaded in the mail gateway (/opt/rt3/bin/…/lib/RT/Interface/Email.pm:244)
[Thu Dec 8 20:42:21 2011] [error]: RT could not load a valid user, and
RT’s configuration does not allow
for the creation of a new user for this email (somebody@nosm.ca).
You might need to grant ‘Everyone’ the right ‘CreateTicket’ for the
queue Helpdesk. (/opt/rt3/bin/…/lib/RT/Interface/Email.pm:244)
[Thu Dec 8 20:42:21 2011] [error]: 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/rt3/bin/…/lib/RT/Interface/Email.pm:244)
I used the RT configuration interface to search for anything with partial
match of the username/alias (4 characters that I know exist in either email
address) and RT’s interface didn’t bring back anything matching for Real
Name, Email Address, or Username.
I decided to do a query at the database level on the Users table on those 3
fields(even though that’s what the RT interface does…), attempting in
some way to find what RT was finding as the “Name in use” error indicates,
but nothing was returned.
I have already granted our “Everyone” the “CreateTicket” right.
Can anyone tell me what I’m missing?
Ruslan, if you read this, can you let me know if you did any customization
to ExternalAuth to allow for the above mentioned matching, or if
ExternalAuth did that already?
Thanks!
Mike.
Hi Mike,
We had a similar problem to this that was caused by our CanonicalizeEmailAddress
function and its interraction with updated LDAP directory information and I
suspect that your problem has similar roots. In our case, we change the Email
address for incoming tickets for any of a user’s mailaltname address to their
preferred Email address. The RT information is however only updated at night
so if a user changed their preferred Email address and created a ticket before
the nightly LDAP sync, it would canonicalize their Email address to their old
preferred address and then would try to create a new user. Of course a user
already existed with their old choice of preferred Email address as their
Email address which led to the same error you received and the failure to
create the new user and ticket.
We fixed it by checking the RT DB for the information so see if it had older
yet valid information, and if so, we returned to data from the RT DB instead
so the ticket would be created and the nightly LDAP update to move their Email
address to the new address. I think that your problem is the same type of
scenario, but using their pager address or Email address. I hope this helps.
Regards,
Ken
–
Hi Mike,
We had a similar problem to this that was caused by our CanonicalizeEmailAddress
function and its interraction with updated LDAP directory information and I
suspect that your problem has similar roots. In our case, we change the Email
address for incoming tickets for any of a user’s mailaltname address to their
preferred Email address. The RT information is however only updated at night
so if a user changed their preferred Email address and created a ticket before
the nightly LDAP sync, it would canonicalize their Email address to their old
preferred address and then would try to create a new user. Of course a user
already existed with their old choice of preferred Email address as their
Email address which led to the same error you received and the failure to
create the new user and ticket.
We fixed it by checking the RT DB for the information so see if it had older
yet valid information, and if so, we returned to data from the RT DB instead
so the ticket would be created and the nightly LDAP update to move their Email
address to the new address. I think that your problem is the same type of
scenario, but using their pager address or Email address. I hope this helps.
Regards,
Ken
Hi Mike,
We had a similar problem to this that was caused by our CanonicalizeEmailAddress
function and its interraction with updated LDAP directory information and I
suspect that your problem has similar roots. In our case, we change the Email
address for incoming tickets for any of a user’s mailaltname address to their
preferred Email address. The RT information is however only updated at night
so if a user changed their preferred Email address and created a ticket before
the nightly LDAP sync, it would canonicalize their Email address to their old
preferred address and then would try to create a new user. Of course a user
already existed with their old choice of preferred Email address as their
Email address which led to the same error you received and the failure to
create the new user and ticket.
We fixed it by checking the RT DB for the information so see if it had older
yet valid information, and if so, we returned to data from the RT DB instead
so the ticket would be created and the nightly LDAP update to move their Email
address to the new address. I think that your problem is the same type of
scenario, but using their pager address or Email address. I hope this helps.
Regards,
Ken
Hi Mike,
We had a similar problem to this that was caused by our CanonicalizeEmailAddress
function and its interraction with updated LDAP directory information and I
suspect that your problem has similar roots. In our case, we change the Email
address for incoming tickets for any of a user’s mailaltname address to their
preferred Email address. The RT information is however only updated at night
so if a user changed their preferred Email address and created a ticket before
the nightly LDAP sync, it would canonicalize their Email address to their old
preferred address and then would try to create a new user. Of course a user
already existed with their old choice of preferred Email address as their
Email address which led to the same error you received and the failure to
create the new user and ticket.
We fixed it by checking the RT DB for the information so see if it had older
yet valid information, and if so, we returned to data from the RT DB instead
so the ticket would be created and the nightly LDAP update to move their Email
address to the new address. I think that your problem is the same type of
scenario, but using their pager address or Email address. I hope this helps.
Regards,
Ken
