I need to setup a request tracking system that can authenticate agains our
AD domain. We are currently using winbind/PAM on a number of linux
systems for authentication, providing a large number of variable services
all utilizing the same login info. Can RT be setup to use PAM?
Thanks,
Brett
Setup APache to use PAM and then setup RT to use Apache for auth.
-ToddOn Tue, Jan 25, 2005 at 10:41:10AM -0500, Brett Harris wrote:
I need to setup a request tracking system that can authenticate agains our
AD domain. We are currently using winbind/PAM on a number of linux
systems for authentication, providing a large number of variable services
all utilizing the same login info. Can RT be setup to use PAM?Thanks,
Brett
RT Administrator and Developer training is coming to your town soon! (Boston, San Francisco, Austin, Sydney) Contact training@bestpractical.com for details.
Be sure to check out the RT Wiki at http://wiki.bestpractical.com
Here is the way I would optimally like it to look.
Group A, Admins, can see all requests, run reports, re-assign requests,
and what not.
Group B, tech support staff, can see unassigned requests and requests
assigned to them, but not everyone’s requests.
Group C, everyone else. Create requests and see own requests.
Will RT recognize users and groups pulled from AD and allow you to set
permisions in this way? Do you have to setup each user? Will the users
show up automatically in the admin interface, or is there something
special I would have to do?
Thanks,
Brett
Todd Chapman said:
Step one is getting RT/Apache to use AD for authentication. You
would then have to create the users in RT manually, or automatically
using the RT API. Then you would have to script group
synchronization between RT and AD.
You might want to consider a support contract with Best Practical.
-ToddOn Tue, Jan 25, 2005 at 12:08:50PM -0500, Brett Harris wrote:
Here is the way I would optimally like it to look.
Group A, Admins, can see all requests, run reports, re-assign requests,
and what not.Group B, tech support staff, can see unassigned requests and requests
assigned to them, but not everyone’s requests.Group C, everyone else. Create requests and see own requests.
Will RT recognize users and groups pulled from AD and allow you to set
permisions in this way? Do you have to setup each user? Will the users
show up automatically in the admin interface, or is there something
special I would have to do?Thanks,
BrettTodd Chapman said:
Setup APache to use PAM and then setup RT to use Apache for auth.
-Todd
On Tue, Jan 25, 2005 at 10:41:10AM -0500, Brett Harris wrote:
I need to setup a request tracking system that can authenticate agains
our
AD domain. We are currently using winbind/PAM on a number of linux
systems for authentication, providing a large number of variable
services
all utilizing the same login info. Can RT be setup to use PAM?Thanks,
Brett
RT Administrator and Developer training is coming to your town soon!
(Boston, San Francisco, Austin, Sydney) Contact
training@bestpractical.com for details.Be sure to check out the RT Wiki at http://wiki.bestpractical.com
RT Administrator and Developer training is coming to your town soon! (Boston, San Francisco, Austin, Sydney) Contact training@bestpractical.com for details.
Be sure to check out the RT Wiki at http://wiki.bestpractical.com
Would it be possible to setup a “default” user level that takes the
persons login information and spits back the cases related to their user?
Then we would only need to manually configure the admins and tech support
staff accounts, which are relatively static.
-Brett
Todd Chapman said:
I don’t understand.On Tue, Jan 25, 2005 at 03:17:01PM -0500, Brett Harris wrote:
Would it be possible to setup a “default” user level that takes the
persons login information and spits back the cases related to their user?
Then we would only need to manually configure the admins and tech support
staff accounts, which are relatively static.-Brett
Todd Chapman said:
Step one is getting RT/Apache to use AD for authentication. You
would then have to create the users in RT manually, or automatically
using the RT API. Then you would have to script group
synchronization between RT and AD.You might want to consider a support contract with Best Practical.
-Todd
On Tue, Jan 25, 2005 at 12:08:50PM -0500, Brett Harris wrote:
Here is the way I would optimally like it to look.
Group A, Admins, can see all requests, run reports, re-assign requests,
and what not.Group B, tech support staff, can see unassigned requests and requests
assigned to them, but not everyone’s requests.Group C, everyone else. Create requests and see own requests.
Will RT recognize users and groups pulled from AD and allow you to set
permisions in this way? Do you have to setup each user? Will the users
show up automatically in the admin interface, or is there something
special I would have to do?Thanks,
BrettTodd Chapman said:
Setup APache to use PAM and then setup RT to use Apache for auth.
-Todd
On Tue, Jan 25, 2005 at 10:41:10AM -0500, Brett Harris wrote:
I need to setup a request tracking system that can authenticate
agains
our
AD domain. We are currently using winbind/PAM on a number of linux
systems for authentication, providing a large number of variable
services
all utilizing the same login info. Can RT be setup to use PAM?Thanks,
Brett
RT Administrator and Developer training is coming to your town soon!
(Boston, San Francisco, Austin, Sydney) Contact
training@bestpractical.com for details.Be sure to check out the RT Wiki at http://wiki.bestpractical.com
RT Administrator and Developer training is coming to your town soon!
(Boston, San Francisco, Austin, Sydney) Contact
training@bestpractical.com for details.Be sure to check out the RT Wiki at http://wiki.bestpractical.com
RT Administrator and Developer training is coming to your town soon! (Boston, San Francisco, Austin, Sydney) Contact training@bestpractical.com for details.
Be sure to check out the RT Wiki at http://wiki.bestpractical.com
I’m trying to save myself the trouble of constantly keeping the entire
company’s userbase updated in the database.
Group A, Admins, can see all requests, run reports, re-assign
requests,
and what not.Group B, tech support staff, can see unassigned requests and requests
assigned to them, but not everyone’s requests.
These two groups of users I can add into the database manually, setting up
permisions and whatnot.
Group C, everyone else. Create requests and see own requests.
This group I’d like to just set with a “default” permission set, and not
have to setup each user whether by hand or by automatic script.
Does that make any more sense?
-Brett
I’m trying to save myself the trouble of constantly keeping the entire
company’s userbase updated in the database.
Your going to need to script it or hack RT’s automatic creation of users.
Group A, Admins, can see all requests, run reports, re-assign
requests,
and what not.Group B, tech support staff, can see unassigned requests and requests
assigned to them, but not everyone’s requests.These two groups of users I can add into the database manually, setting up
permisions and whatnot.
OK
Group C, everyone else. Create requests and see own requests.
This group I’d like to just set with a “default” permission set, and not
have to setup each user whether by hand or by automatic script.
You still need the users created in RT somehow. Once that is done,
setting permissions should be easy.
There are two parts to your problem
Authenticating users via the web interface. Dunno about AD, we do it
with LDAP and external auth and it is relatively easy.
Authenticating users via the email interface and recognising them as
valid users. This one is hard, because the user Joe.Smoe may have an
email of Joe.Shmoe, jsmoe, js1, SuperMan or whatever else you like. You
need a replacement for the RT::Interface::Auth::Mail module that reads
all mail aliases from somewhere (AD?) and resolves a Joe.Shmoe to his
real UID - jsmoe.
Once this is done you can easily setup users to be autocreated as
unprivileged via the mail or web interface. After that you go in
manually and add them to the admin group for the relevant queue.
The hard part is 2. I had a module working for 3.0/NIS which no longer
works under 3.2 and I have not had the time to sort it out.
A.