Take actions on a created user at first login

RT Users
1

Hi all - it’s been a realllly long time since I stood up a new RT instance.

I’ve got the server up and running, and it’s (4.4.2) using the now-baked-in LDAP auth. We have three classes of users - admin users (essentially staff) who have admin accounts that LDAP knows are special; user-requestors who will be in LDAP; and user-requestors who are external to this org and will not be in LDAP.

I cannot for the life of me figure out how to scrip or otherwise process users at login such that they go into an appropriate group based on which of the above three possibilities they met. LDAP-authed admin users into Admin Group; LDAP-authed users into User Group; and non-LDAP users (autocreate is on) into External Group.

At the moment, users are created as either the generic top-level “Priv” or “Unpriv,” as per that global config directive; but they must be manually edited and added to groups and whatnot and that can’t be right. What am I forgetting?

Thanks!
Rob

2

Take a look at this documentation the rt-ldapimport utility group mapping. This should let you import not only users but LDAP groups (or a subset thereof using $LDAPGroupFilter) and populate the RT groups based on LDAP group membership. When importing, users are created first IIRC and then groups, followed lastly by group membership.

3

Sounds like it covers part of what’s needed - but for the external users, mapping an LDAP group to an RT group is N/A.

Without depending on there being a unique LDAP group to translate them from, how can an action be created such that “When this user is created, assign them to that internal RT group based on XYZ arbitrary criteria?”

4

I don’t think you need to map LDAP group to RT group when login. Authentization is external (LDAP) but authorization is internal (RT groups). So perhaps you need to run rt-ldapimport script once an hour or something like that to import users and groups to RT and that’s it. Users and groups will be synchronized with RT, you can manage them in LDAP but the rights and authorization should be set in RT.

5

The external users would be in the unprivileged group - they aren’t staff or admins (ie they’re just random requestors). By default the unprivileged group members get limited access to the system (self service view basically).

If you want to make them privileged users you could try:

Set($UserAutocreateDefaultsOnLogin, { Privileged => 1 });

This would mean that they could then be assigned to groups. I’m don’t know if you can add anything to that hash to give them a particular set of groups though - I think its supposed to be the hashref that is passed into RT::User Create() method.

6

Hi, sorry if I wasn’t clear - yes, the “create as priv” option, as given in the example in the docs, is being used. The goal is the “then be assigned to groups” as you say - I want this assignment to happen based on who they are when they log in, not piecemeal by myself manually when I go do it myself via logging into the web interface.

7

But if the external people aren’t in your LDAP system so you don’t know who they are, they should normally go into the unprivileged group so that they are restricted in what they can do. You can’t assign them to other groups because they aren’t in any source that tells you what group to put them in.

You can always have a cronjob that turns some of the unprivileged users into privileged users and put them into specific group(s) if have some subsequent, post login data source that lets you match externals you’re interested in from the mass of spammers, time wasters, etc.

8

Fair point. The lab has external collaborators, researchers, etc., and they won’t be able to reach the web portal, so they’d be operating entirely via email, and won’t be in LDAP. It’ll be a pretty obscure address, but I’m sure at least some of the spambots will find us anyway.

I guess there’s no way around eyeballing newly-created unprivileged users, in this case. I’m guessing it wouldn’t be too hard to scrip a response to email-created new users with some sort of “thanks for contacting us, we’ll verify your account soon?”

I hate when I can’t figure out a way to fully automate something :wink:

9

Thanks for all the help. I have a question I can’t find anywhere: I see plenty of info on mapping RT groups to LDAP groups, but we don’t have distinct LDAP groups. I want to put all privileged users, who auth via LDAP, to be put in my created-in-rt “ClusterUsers” group (whereas admin users are manually placed into AdminUsers), as my first layer of basic permission separation.

Is there any way to do something like “Put this ldap-authed user into this group if they exist in ldap,” or use a wildcard mapping “ClusterUsers = ldapgroup(*)” ? Again, I don’t want whatever ldap says their group is to be the RT group name, as we don’t control AD and it could vary wildly (or be unset).

10

One thought: if you’re comfy with a bit of Perl coding you could make a local copy of lib/RT/Interface/Email/Auth/MailFrom.pm and then add a group membership addition to the end of GetCurrentUser() subroutine. This could work off a pattern match of the $Address variable in that routine to see if the newly created user has an email address from one of your partner organisations. Something like this before the return $CurrentUser;:

if( $Address =~ /\@trusted.org.uk / ||
    $Address =~ /toby\@someplaceelse.com/
  ) {
    $CurrentUser->SetPrivileged(1);
    my $group = RT::Group->new( RT->SystemUser );
    $group->Load( 'External' );
    $group->AddMember( $CurrentUser->Id );
}

I’ve not tried that, but it might give you a starting point. At least doing something like that would mean that you only create new privileged users with membership of the “External” group if their incoming email matches one of the domains of your trusted partners. Just remember to play with it on a local copy of the Perl module, otherwise your changes will get blown away when you upgrade RT.

11

I’m not sure if its what you want, but in lib/RT/LDAPImport.pm it mentions:

Set($LDAPCreatePrivileged, 1);

and

Set($LDAPGroupName,'My Imported Users');

Would that not do what you want for your LDAP imported users by replacing "My Imported Users’ with your ‘ClusterUsers’? Worth a try maybe?

12

Oh both very interesting, thanks. I’ll check them out and report back if one or both of them work well.