ExternalAuthId changes in 4.4.1

RT Users
1

New RT User tasked with figuring out the upgrade from 4.2.12 to 4.4.1. I’m finding the documentation a bit confusing, but perhaps it’s me. In particular, we are (in 4.2.12) using the RT-Authen-ExternalAuth plugin. I understand it has been moved to core, I’ve read all I can find to try to understand what changes I might need to make in the upgrade, but am still in need of some guidance.

In our instance we use LDAP for user authentication and log-in. One of the fields we get/use is ExternalAuthId, which is the employee ID number and, if I understand correctly, is the ID upon which all else in our RT is based (could be wrong about that) as far as who gets what and can do what. When I create a new user, I just enter the user’s company email address and then auto-populate the rest. ExternalAuthId is stored in our DB (Pg).

When I run, in our test/dev/environment, sudo make upgrade-database, I get the following:

“You have 7348 users(s) with a non-empty value for column ‘ExteranlAuthId’. Core RT does not use this column, so perhaps an extension or local modification makes use of it. Please migrate these user values to a custom field or an attribute because this upgrade will drop these columns. at ./etc/upgrade/4.3.0/content line 67, <$handle> line 1. (./etc/upgrade/4.3.0/content:67)
make: *** [upgrade-database] Error 1”

I believe, from talking to my manager and reading the code, that this column was added to the plugin by us, and is needed for our RT to properly function. If I can’t keep it, major rewrites will need to be done.

How do I keep it? I get that I need to make it a custom field or attribute based on the warning, but it is provided by LDAP and I’m not sure how to proceed.

2

I found the old mail list archives and have been digging through them trying to find some guidance. It appears that I am hardly the only one that has run into this problem, which begs the question, Why was ExternalAuthId eliminated?

It seems that the general consensus is to comment out the ExternalAuthId from my LDAP configuration and null out that column in my database, but if I’m using that value within my various homegrown plugins, then I’ve essentially just broken my RT instance.

FYI: ExternalAuthId is both my attr_match_list and attr_map, and our homegrown SSO and Base plugins use it.

3

Hi,

I’m afraid I’m unable to answer your question as to why it was removed.
However the following may work as a relatively painless alternative.

  1. Create a user customfield and populate it in the same manner as you
    populated ExternalAuthId i.e via attr_match_list and attr_map.
  2. Modify your custom plugins to read the user customfield instead of
    the ExternalAuthId.

Best Regards

Martin

4

I actually just stumbled across that as well Martin. Thanks! I’m also wondering if I can use AuthToken.

As I understand the docs, I can set up our LDAP just as before, but where I had our uid mapped to ExternalAuthId, I could now map it to AuthToken which we were not using. If I then changed all references to ExternalAuthId to AuthToken, and changed the ExternalAuthId column in our Pg DB to AuthToken, would I not only keep the uid of current users but also keep all current functionality? I think the answer is yes, but I’d like to have someone with more experience than I confirm.

5

Hi,

I’m afraid I cannot confirm that as I haven’t examined the code, but
would consider that a good possibility.
However the following is worth a little consideration IMO.

  1. The contents of ExternalAuthId is garnered from your users uid from
    LDAP, thus whether you map to
    a User.CF or AuthToken you won’t need to rename the column you could
    just null out as suggested else where
    as that information will be populated either as the user attempts to
    login/on a ldap import.

  2. I would avoid re purposing an existing field that may have another
    intended use as a update may clobber your changes
    if you use a customfield this isn’t going to happen.

  3. Are you aware you can populate a user customfield using a anonmyous
    subroutine…

    i.e ‘UserCF.external_auth_id’ => sub { return “id123456”; },

Sorry, but I don’t seem to be giving you straight answers :frowning:
Just lots of options.

Best Regards

Martin

6

Martin, thank you for your reply, I’ve been pondering it all morning.

  1. I understand the LDAP mapping, but not sure if I can get away with nulling out the column, think I can since, as you say, it should repopulate on login.

  2. I picked AuthToken as it is a valid key for the attributes of an RT user according to the docs, and we are not presently using that key, plus it is big enough at varchar(16) to handle our id numbers (7 digits) now and well into the future.

  3. I was unaware and, at the moment, don’t understand the syntax, though the concept is quite clear.

7

I finally got back to this issue, was retasked to another project for a while.

I did:

  • copied the values in the ExternalAuthId column to the AuthToken column
  • nulled out the ExternalAuthId column
  • changed RT_SiteConfig.pm LDAP section attr_match and attr_map from ExternalAuthId to AuthToken

This did allow some minor progress, the database now upgrades, I can get RT4.4.1 to start, Apache brings it up, I can get to the login page, but can’t log in. LDAP is not working with this configuration. That would have been too easy.