I did track down the LDAP problem, and it didn’t have anything specifically to do with RT.
We use Novell eDirectory here. Some of our older accounts were apparently created with NWADMIN, which does not create a UID for those users. Following the instructions on the wiki (Request Tracker Wiki ) I had set the attribute ‘Name’ = ‘uid’ and it worked for 95% of the users. Turns out that a few users did not have uid’s defined in their LDAP accounts.
Fixed their LDAP accounts, and now everything is cool. Thanks for your help!
As far as logging on with LDAP or password, see the above wiki page.
Line 2 of the code there says:
What auth methods do you like and in what order?
Set($AuthMethods, [‘LDAP’, ‘Internal’]);
So, users with internal RT passwords can still get in.
Thanks, Mike
The information in this message may be proprietary and/or confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify Stonebridge Bank immediately by replying to this message and deleting it from your computer.
“Scott Golby” sgolby@freshdirect.com 3/26/2007 12:27 PM >>>
Hi, I have an instance of RT 3.4.6 running nicely, thank you, that
serves
as our internal Helpdesk. I use LDAP to authenticate users, and I’m
having
a problem with some users. I think these users were created before I
got
the LDAP mods installed.
We have almost the opposite here, accounts created before the LDAP was
installed can login with either their LDAP password or their old RT
password. It does a fall through, you can see it in the logs, I did a
quick look and I don’t spot a config which turns that on or off.
One issue I came up against with the LDAP / Email causing account
creation was userids would get created as username@emailaddress.com,
where our Active Directory server would only allow ‘username’. I wrote
a little cleaner script to go into the Database and strip the
@emailaddress.com out of the name.users table.
Doesn’t sound like your exact problem, but maybe your LDAP wants those
user-id’s in Format A. and your historical pre-LDAP accounts are in
Format B. and what is actually happening is they are falling through to
the RT password (which you mention you set) and that’s how they get in ?
Turning the debug on gives quite a lot of useful info
Set($LogToFile , ‘debug’);
Good luck.
Scott
Manager, Corporate IT