[rt-users] RT could not load a valid user
ktm at rice.edu
ktm at rice.edu
Fri Dec 9 16:32:30 EST 2011
On Fri, Dec 09, 2011 at 04:18:29PM -0500, Mike Johnson wrote:
> 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 at nosm.caor
> alias at 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 at nosm.ca and pager =
> alias at 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 at nosm.ca'.giving
> up (/opt/rt3/bin/../lib/RT/Interface/Email.pm:962)
> [Thu Dec 8 20:42:20 2011] [crit]: User 'somebody at 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 at 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
More information about the rt-users
mailing list