I’m looking at deploying RT (running over apache2 on GNU/Linux) into an
environment that is windows-centric, and to ease administrative overhead I’d
like to use AD for authentication and the provisioning of identities. I’ve
successfully accomplished AD-Authentication a few different ways, but what
I’m running into is that the users RT creates based on AD credentials are
not privileged within AD. To ease service configuration (Group
Creation/Rights Delegation) I’d like to bulk-load identities into RT from AD
before rolling out the service, and have a nightly cron catch any new
additions/changes (names changing due to state-changes in marital status,
etc…). I’m guessing this is a solved problem, but have not stumbled my
away across a tool despite numerous google searches.
Anyone out there who can point me in the right direction or share their
learnings?
Thanks very much!
-Rob
Slight correction:
I’m looking at deploying RT (running over apache2 on GNU/Linux) into an
environment that is windows-centric, and to ease administrative overhead I’d
like to use AD for authentication and the provisioning of identities. I’ve
successfully accomplished AD-Authentication a few different ways, but what
I’m running into is that the users RT creates based on AD credentials
are not privileged within AD.
are not privileged within RT.
To ease service configuration (Group Creation/Rights Delegation) I’d like to
Slight correction:
I'm looking at deploying RT (running over apache2 on GNU/Linux) into an environment that is
windows-centric, and to ease administrative overhead I'd like to use AD for authentication
and the provisioning of identities. I've successfully accomplished AD-Authentication a few
different ways, but what I'm running into is that the users RT creates based on AD
credentials
are not privileged within AD.
are not privileged within RT.
Set($AutoCreate, {Privileged => 1});
in your config
-kevin
Slight correction:
I'm looking at deploying RT (running over apache2 on GNU/Linux) into
an environment that is
windows-centric, and to ease administrative overhead I'd like to use
AD for authentication
and the provisioning of identities. I've successfully accomplished
AD-Authentication a few
different ways, but what I'm running into is that the users RT
creates based on AD
credentials
are not privileged within AD.
are not privileged within RT.
Set($AutoCreate, {Privileged => 1});
in your config
blink Thanks! I missed that one. 
Pre-loading users is something I’d still like to do so I can configure
groups/queues before rolling out the service. I’ll figure something out.
-Rob
> Slight correction:
>
>
> I'm looking at deploying RT (running over apache2 on GNU/Linux) into an environment that
is
> windows-centric, and to ease administrative overhead I'd like to use AD for authentication
> and the provisioning of identities. I've successfully accomplished AD-Authentication a few
> different ways, but what I'm running into is that the users RT creates based on AD
> credentials
>
> are not privileged within AD.
>
> are not privileged within RT.
Set($AutoCreate, {Privileged => 1});
in your config
blink Thanks! I missed that one.
Pre-loading users is something I’d still like to do so I can configure groups/queues before
rolling out the service. I’ll figure something out.
Have you looked at RT-Extension-LDAPImport ?
-kevin
Have you looked at RT-Extension-LDAPImport ?
-kevin
I had not found my way to it yet! Now that I read the cpan page, that looks
very much like what I’m looking for.
Thanks so much, Kevin. I’ll play with this and see how it goes!
-Rob
Hi Kevin,
I finally had time to circle back and work on piloting/configuring RT
Quick Recap - I had asked about solutions for bulk-loading identities from LDAP (active
directory in my case) into RT so that the users appeared in the system as privileged users.
You suggested two things:
- Setting the flag that makes auto-created users privileged.
- Using RT-Extension-LDAPImport
I’ve installed RT-Extension-LDAPImport and was reading the README. What jumped out at me is
that there is both a script to run (presumably to bulk-load identities) and a plug-in. I was
expecting to see a script, but a plugin was unexpected, which lead me to wonder if this module
is both a method for importing users from ldap, and an on-the-fly authentication and
user-creation tool too? If so, that implies I don’t need the 3rd party ldapauth plug-in I
already have installed. (I’d rather use a module from Best Practical if I had a choice).
Rob
Please keep comments on the list rather than in my personal mailbox
If you look at the script, it is 23 lines long. The plugin is where
the import code is stored and organized, the script is just a wrapper.
You still need RT-Authen-ExternalAuth or apache LDAP authentication if
you want to validate passwords against an external source
-kevin
I’ve installed RT-Extension-LDAPImport and was reading the README.
What jumped out at me is
that there is both a script to run (presumably to bulk-load
identities) and a plug-in. I was
expecting to see a script, but a plugin was unexpected, which lead me
to wonder if this module
is both a method for importing users from ldap, and an on-the-fly
authentication and
user-creation tool too? If so, that implies I don’t need the 3rd party
ldapauth plug-in I
already have installed. (I’d rather use a module from Best Practical
if I had a choice).
If you look at the script, it is 23 lines long. The plugin is where
the import code is stored and organized, the script is just a wrapper.
I saw that and I get that the script is a wrapper.
What I was wondering is why the import code is stored in a plug-in and
loaded as a plug-in, but I think I figured it out. Basically the import
code is working against the objects and subsystems in RT, and needs those
objects to exist before it’s loaded, so you load your import code indirectly
via by simply loading the RT runtime via the RT Module, which inspects
RT_SiteConfig.pm, initializes the environment, and then eventually loads
your plug-in, thus making your code available to your script within the
context of a complete RT runtime environment.
Okay, so I get that now.
Once I configured the script the first thing I wanted to do was “test the
config”. I was extremely surprised to see there is no “look before you
leap” flag. Rather, just a comment advising “back up your database first”,
which has this sense of playing russian roulette with a revolver with no
empty cylinders. Having looked at the code I can see some ways to work
around that. Not cleanly, since “fetch users” and “load users” are sitting
inside one api call but it shouldn’t be hard to change that.
-Rob