[rt-users] RT could not load a valid user
Mike Johnson
mike.johnson at nosm.ca
Mon Dec 12 09:32:57 EST 2011
I looked deeper into the issue and the LDAP account doesn't have anything
in the pager attribute.
I'm wondering if ExternalAuth is getting confused on that...
I'll try to populate the pager attribute and get the user to attempt send a
new email...
I'll report back.
Thanks!
Mike.
On Fri, Dec 9, 2011 at 4:32 PM, ktm at rice.edu <ktm at rice.edu> wrote:
> 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
>
--
Mike Johnson
Datatel Programmer/Analyst
Northern Ontario School of Medicine
955 Oliver Road
Thunder Bay, ON P7B 5E1
Phone: (807) 766-7331
Email: mike.johnson at nosm.ca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20111212/ec218902/attachment.htm>
More information about the rt-users
mailing list