Auth::ExternAuth (LDAP) and disabled users

RT Users
1

I’m using Auth::ExternalAuth with RT 3.6.6.

I have a d_filter set in RT_SiteConfig.pm which identifies users who should be
marked ``disabled’’ - but this isn’t picked up until the first time a user
tries to log in to the Web interface.

I’d rather be able to mark a user disabled in LDAP and have RT pick it up the
next time there was any activity at all by the user.

It feels as though perhaps I should be looking at the User->Load method (or
near there at least) - but before I start fiddling, does anyone have any
advice for me?

Jonathan

2

Jonathan McKeown wrote:

I’m using Auth::ExternalAuth with RT 3.6.6.

I have a d_filter set in RT_SiteConfig.pm which identifies users who should be
marked ``disabled’’ - but this isn’t picked up until the first time a user
tries to log in to the Web interface.

I’d rather be able to mark a user disabled in LDAP and have RT pick it up the
next time there was any activity at all by the user.

It feels as though perhaps I should be looking at the User->Load method (or
near there at least) - but before I start fiddling, does anyone have any
advice for me?

This is a little bit of a design flaw that I have also had to work
around rather than spend time reprogramming. At the moment, user
information (i.e. whether or not they are disabled as well as other
info) is queried from the LDAP server at login. To disable them
immediately would mean checking if the user is disabled every time an
action is performed which would be quite a performance hit and would
take quite a bit of reprogramming. I’m not sure what else to tell you
other than good luck if you decide to try to reprogramme :slight_smile:

Kind Regards,

Mike Peachey, IT
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 - Registered In England

3

Jonathan McKeown wrote:

I’m using Auth::ExternalAuth with RT 3.6.6.

I have a d_filter set in RT_SiteConfig.pm which identifies users who
should be marked ``disabled’’ - but this isn’t picked up until the first
time a user tries to log in to the Web interface.

I’d rather be able to mark a user disabled in LDAP and have RT pick it up
the next time there was any activity at all by the user.

It feels as though perhaps I should be looking at the User->Load method
(or near there at least) - but before I start fiddling, does anyone have
any advice for me?

This is a little bit of a design flaw that I have also had to work
around rather than spend time reprogramming. At the moment, user
information (i.e. whether or not they are disabled as well as other
info) is queried from the LDAP server at login. To disable them
immediately would mean checking if the user is disabled every time an
action is performed which would be quite a performance hit and would
take quite a bit of reprogramming. I’m not sure what else to tell you
other than good luck if you decide to try to reprogramme :slight_smile:

I may have overstated my case in my original message: if I need someone’s
account disabled immediately, my team and I will be going through all our
systems making damn sure the account is manually locked out everywhere.

What I would like to do is make it possible for an account which has been
disabled in LDAP (under friendly circumstances) to disable itself in RT with
minimum effort.

As it stands, only an attempt to log in to RT trips the switch. Ideally, I’d
like attempted ticket-creation to do the same thing (creating a ticket is the
other big thing I don’t want ex-users doing).

More to the point, a user who exists as a disabled account in LDAP, but
doesn’t exist in RT, should never be autocreated in RT - especially not as a
non-disabled account. (This one surprised me in testing today).

My installation is tiny: 80 users averaging 5 tickets a day or so. I wonder if
anyone could share some profiling information (even just to the nearest order
of magnitude)?

To lock out a user who is flagged disabled in LDAP, I can imagine hooking in
to RT at:

  1. HasRights call;
  2. User->Load call;
  3. Ticket->Create call.

Any of these would probably achieve what I want: I would guess that I’ve
listed them from the most frequently-called to the least, but I’d be hapy to
be corrected - or hear a suggestion as to where I might plant a more
efficient hook.

Another option, of course, would be some sort of helper program/plugin which
can bulk-update RT’s internal disabled flags from the external source - then
I could run that either manually or via cron.

Jonathan