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