Kevin,<br><br>I guess that when I read things, I read them differently. From what I read about ExternalAuth, I assumed it did the authorizing but didn't see where it <i>defaulted back</i> to RT (checking the USERS Table) when an ExternalAuth failed. My mistake, again.<br>
I did figure that if ExternalAuth allowed a non-LDAP to be added (per setting) that the regular AutoCreate,Privileged, 0/1 setting would determine whether they were added as privileged or not, but I didn't realize that if the Auth didn't Pass LDAP, RT would look at the Users DataBase for the User. I just didn't see it that way when I read the documentation. No one's fault but my own. Sorry.<br>
<br>Kenn<br>LBNL<br><br><div class="gmail_quote">On Thu, Jan 13, 2011 at 10:42 AM, Kevin Falcone <span dir="ltr"><<a href="mailto:falcone@bestpractical.com">falcone@bestpractical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Thu, Jan 13, 2011 at 10:37:03AM -0800, Kenneth Crocker wrote:<br>
>    I do have a question as to why all that explanation on My_Oracle and such in the ExternalAuth<br>
>    notes if we should use such settings?<br>
<br>
</div>Because you can validate against some other app's database?<br>
<br>
What gave you the idea that you needed to configure<br>
RT-Authen-ExternalAuth to talk to RT's internal Users table?<br>
Documentation implying that needs to be fixed<br>
<font color="#888888"><br>
-kevin<br>
</font></blockquote></div><br>