LDAP CONTRIB: Looking for a few good guinea pigs

RT Users
1

Hello!

It’s been stable for a few weeks, so I’m making available for beta
testing a new, integrated approach to LDAP user auth and info services.
It’s a huge refactor of the approaches previously contributed, with a
new approach to the authentication bits and a lot of new code. See below
for a short list of changes, things which need to be tested, and things
left to do.

The odd hitch is that the code I’m releasing actually factors out some
ugly hacks that I’m using to account for our, er, unique LDAP
configuration at present. This means I can’t test it here until the
reason for those hacks goes away, which should be moderately soon. While
the code I’m releasing is very, very similar, and while I’ve been very,
very careful, it’s not been tested beyond being sure that perl -c User_Local.pm succeeds. Ugh.

If you’re feeling brave, please have a go at:

http://wiki.bestpractical.com/index.cgi?LDAP

… and let me know how it pans out. I’ll try to turn around any bug
fixes quickly.

Thanks!

–j

Things which need to be tested:

  • Drop-in replacement of previous contrib implementations
  • SSL (TLS) LDAP connections
  • Non-Linux installations

Changes in this implementation:

  • Added $RT::AuthMethods as basis for auth method lists;
    currently supports LDAP, Internal
  • Implemented Phillip Cole’s suggested $RT::LdapAttrMap
  • Implemented $RT::LdapRTAttrMatchList and $RT::LdapEmailAttrMatchList
    to help guide LDAP searches more effectively
  • Added LdapAuth* and LdapInfo* variables to allow authentication
    and information from separate LDAP servers; didn’t invalidate
    older Ldap{Server,Base,User,Pass,etc} variables.
  • Added LdapConfigInfo() to get integrated config info

To do:

  • LdapConfigInfo() should take an optional list of required
    config vars and fail if they’re not all defined
  • Refactor code to eliminate goofy $ldap_foo = $ldap_config{foo}
    statements.
  • Refactor auth methods to use LookupExternalUserInfo()
  • Make LDAP-sourced user information immutable in all RT interfaces
    (web and CLI)
  • Cause LDAP-sourced user info stored in the RT database to behave
    as a cache, auto-updating after some (admin-configurable) time period.
    Will need to deal with failure modes such as:
    o LDAP server down
    o LDAP server up but failing catastrophically
    (e.g. presenting no results when searched for valid record)
    o User record has been removed
    o uid or other identifying info changes (e.g. Jane Doe with
    login jdoe marries John Smith, changes login to jsmith)
    Jim Meyer, Geek at Large purp@acm.org
2

Hello!On Mon, 2006-01-09 at 15:24, Mike Ely wrote:

Hey, Jim, thanks for this. I’ve implemented it on my RT-3.4 setup
running on a debian server, connecting to an openldap server that’s also
used for our samba backend. User authentication works fine with ldap
password information (if the user is allready granted rights in RT),
but, and this is kind of a whopper, I can’t login to RT as root any
longer! No, there is not nor will there be a root user in LDAP, so how
do I work around this? Or what more information do you need?

No worries re: having root in LDAP; it shouldn’t be required as long as
root has a password in the RT database (which it usually does =). First,
let’s check ${RTHOME}/etc/RT_SiteConfig.pm to see that you’ve set
$RT::AuthMethods as would be needed:

Set($AuthMethods, [‘LDAP’, ‘Internal’]);

If that’s already set, could you step up logging to the debug level and
send me what shows up there when root tries to log in? If you’re logging
to a file, look for this in your RT_SiteConfig.pm:

Set($LogToFile , ‘debug’);

…and if it doesn’t say ‘debug’, change it to do so. =] Restart your
instance, then try to log in as root and let’s see what comes up in the
logs.

Thanks!

–j
Jim Meyer, Geek at Large purp@acm.org

3

Jim Meyer wrote:

Hello!
…
… and let me know how it pans out. I’ll try to turn around any bug
fixes quickly.

Hey, Jim, thanks for this. I’ve implemented it on my RT-3.4 setup
running on a debian server, connecting to an openldap server that’s also
used for our samba backend. User authentication works fine with ldap
password information (if the user is allready granted rights in RT),
but, and this is kind of a whopper, I can’t login to RT as root any
longer! No, there is not nor will there be a root user in LDAP, so how
do I work around this? Or what more information do you need?

Cheers,
Mike

4

Hello!On Mon, 2006-01-09 at 15:50, Mike Ely wrote:

I’ve tried using the steps on the wiki to reset the root password using
mysql, but apparently something hasn’t taken:
Q: I lost the root password how can i reset it?
A: mysql> update Users set Password=‘X03MO1qnZdYdgyfeuILPmQ’ where
Name=‘root’;
Resets the root password to “password”

I did a bit of research and found that, if you’re using a modern version
of MySQL (v4.1.x or later, at least), the password encryption scheme
changed. I’ve updated the FAQ with the encrypted string that was set in
a fresh install of RT 3.4.4 using MySQL 4.1.11. Please give that a try
and see if you’re able to log in as root. =]

Cheers!

–j
Jim Meyer, Geek at Large purp@acm.org

5

Hello!

It’s not mysql or the root password - if I revert my configuration back
to non-ldap auth, the root password works perfectly. It’s just that for
some reason, the fallback to IsInternalPassword isn’t working. I’ll go
ahead and paste the error from rt.log that a failed login just
generated.

Okay, I didn’t understand that from earlier, then. I’m setting up a test
instance so I can validate it works in vanilla RT 3.4.4 and MySQL; once
I’ve got that, I’ll insert a bit more debug and we’ll go from there.

Also, a quick question: is this mod intended to be used in
place of CurrentUser_Local.pm or will that even work with this? The
whole purpose of me doing this is so that I don’t have to create an
account for each and every person I want to give rights to post a
helpdesk query, but don’t want the issues associated with queue granting
to “everyone.”

This contrib is intended to:

  • authenticate existing accounts against LDAP
  • bootstrap auto-created accounts with user info from LDAP

You’d still have to give CreateTicket to the Everyone group (which you
could grant per queue or globally) if you want to allow people who don’t
already have an RT account to generate a new ticket; when they do, RT
will auto-create their account using info from LDAP.

Hopefully that’s what you’re looking for. =]

Meanwhile, I’ll let you know when I’ve either validated this on a
vanilla RT 3.4.4 setup or found the problem. =]

Thanks!

–j
Jim Meyer, Geek at Large purp@acm.org