Newbie RT/AD setup and priv questions

RT 4.2.3
RedHat Enterprise Linux 6.5

Hi

I have installed RT as a test in hopes of eventually replacing our home-built ticketing system soon-ish. I have RT installed and have a basic configuration that allows anyone in our AD to login. For the moment there is an RT “root” user and my AD account. I have looked in the wiki and the mailing list archive and see a lot about AD issues but not his… or I don’t know enough to know what I am looking for yet.

If I login as the rt-root user and go to Admin > Users there is a list of “Privileged users”. This list only shows the rt-root user. If I then search for my AD account I can see my account and that under “Access control” the box for “Let this user be granted rights (Privileged)” is checked. Shouldn’t this/my account show up in the Admin > Users: “Privileged users” list?

I have seen some threads that talk about an auto create config option. Is the situation that plain AD users are not “real” RT user accounts by default?

Our situation is that of an IT HelpDesk for a large facility. Hundreds of plain AD users should be able to submit tickets and do unprivileged RT actions. A much smaller group of folks, the HelpDesk folks, need to be able to do the real RT work: assign tickets, move them into queues, etc.

I have another unrelated newbie setup question as well. I work for a large facility and again my main focus is replacing an ancient ticket system in my group. I can easily imagine that over time other departments/groups in the facility may want their own RT services. Are there docs that can tell me what to do now to prepare for multi-department use? Should each unit have their own install & config? Can one instance service multiple units with undoubtedly unique needs?

Thanks
Dean

AD users don’t exist in RT until the login.

I use a combination of auto create on login, and a nightly cron job that
runs rtldapimport from this extension:
RT::Extension::LDAPImport - Import Users from an LDAP store - metacpan.org.
That handles creating the users.

As for multi department, I would suggest using separate queues and not
seperate rt instances to divide up the work. Each queue can have a custom
workflow and custom scrip actions.On Tue, Jul 8, 2014 at 1:20 PM, Karres, Dean karres@illinois.edu wrote:

RT 4.2.3

RedHat Enterprise Linux 6.5

Hi

I have installed RT as a test in hopes of eventually replacing our
home-built ticketing system soon-ish. I have RT installed and have a basic
configuration that allows anyone in our AD to login. For the moment there
is an RT “root” user and my AD account. I have looked in the wiki and the
mailing list archive and see a lot about AD issues but not his… or I don’t
know enough to know what I am looking for yet.

If I login as the rt-root user and go to Admin > Users there is a list of
“Privileged users”. This list only shows the rt-root user. If I then
search for my AD account I can see my account and that under “Access
control” the box for “Let this user be granted rights (Privileged)” is
checked. Shouldn’t this/my account show up in the Admin > Users:
“Privileged users” list?

I have seen some threads that talk about an auto create config option. Is
the situation that plain AD users are not “real” RT user accounts by
default?

Our situation is that of an IT HelpDesk for a large facility. Hundreds of
plain AD users should be able to submit tickets and do unprivileged RT
actions. A much smaller group of folks, the HelpDesk folks, need to be
able to do the real RT work: assign tickets, move them into queues, etc.

I have another unrelated newbie setup question as well. I work for a
large facility and again my main focus is replacing an ancient ticket
system in my group. I can easily imagine that over time other
departments/groups in the facility may want their own RT services. Are
there docs that can tell me what to do now to prepare for multi-department
use? Should each unit have their own install & config? Can one instance
service multiple units with undoubtedly unique needs?

Thanks

Dean


RT Training - Boston, September 9-10
Training — Best Practical Solutions

RT 4.2.3

RedHat Enterprise Linux 6.5

Hi

I have installed RT as a test in hopes of eventually replacing our
home-built ticketing system soon-ish. I have RT installed and have a
basic configuration that allows anyone in our AD to login. For the
moment there is an RT “root” user and my AD account. I have looked in
the wiki and the mailing list archive and see a lot about AD issues
but not his… or I don’t know enough to know what I am looking for yet.

If I login as the rt-root user and go to Admin > Users there is a list
of “Privileged users”. This list only shows the rt-root user. If I
then search for my AD account I can see my account and that under
“Access control” the box for “Let this user be granted rights
(Privileged)” is checked. Shouldn’t this/my account show up in the
Admin > Users: “Privileged users” list?

Yes I would think so, it does at my site.

I have seen some threads that talk about an auto create config
option. Is the situation that plain AD users are not “real” RT user
accounts by default?

Read etc/RT_Config, either on the server you installed RT on or on the
bestpractical.com site

Our situation is that of an IT HelpDesk for a large facility.
Hundreds of plain AD users should be able to submit tickets and do
unprivileged RT actions. A much smaller group of folks, the HelpDesk
folks, need to be able to do the real RT work: assign tickets, move
them into queues, etc.

I have another unrelated newbie setup question as well. I work for a
large facility and again my main focus is replacing an ancient ticket
system in my group. I can easily imagine that over time other
departments/groups in the facility may want their own RT services.
Are there docs that can tell me what to do now to prepare for
multi-department use? Should each unit have their own install &
config? Can one instance service multiple units with undoubtedly
unique needs?

I think so, create groups and queues and assign the correct rights. Try
to stay away from the global rights because once given can’t be revoked
on a group level.

Joop