Tightening security in TSM

[newguy2489]

Hi all,

I am trying to figure out the least offensive way to tighten down security on our TSM environment. We manage around 400 nodes, and there are maybe 15 admins that have their own accounts on the systems.

We currently have 2 TSM servers (ver 5.4.3.2 running on Windows 2003), one backups up Production hosts, one backups up QA/DEV/Test systems. Our admins fall into 3 distinct groups:

1. the DBA group - who deals only with UNIX systems, and mainly with the Oracle and DB2 backups and restores (they do ad hoc backups, and do all of the restores, including re-directed restores to refresh different hosts).

2. The desktop/network group - who deal mainly with Windows servers, and handle nearly all of user restore requests in the organization. The also do some system refreshes from prod systems to their QA equivalents. These folks do all of the B/A and TDP client installs on Windows systems, and they do have a handful of Linux systems to deal with as well.

3. The TSM server admins - who deal with the daily operation of TSM at the server side. They also are directly involved with UNIX backups and restores, and are somewhat involved with DB2 and Oracle backups.

I am interested in keeping the desktop/networking folks and the DBAs from being able to add new nodes, delete existing nodes (or file spaces). I would also like to keep all but the TSM server admins from being able to change TSM schedules. (I have registration closed on both servers).

We don't have any experience tightening security on our system to date, and I would appreciate any suggestions that you may have for us.

Thanks,
Arnie

 

[dms19]

check out the help section of "grant authority"

run "h grant authority" from command line that should give you the different levels of authority and what each can do (system, policy, storage, operator, analyst)

q admin will give you their current status.

hope this helps