OUCH! You're making it too hard!
("not very secure" is an understatement! - I'm astounded your security
folks let you get away with it!)
1) PASSWORDACCESS GENERATE in the dsm.opt file the key here.
Give each node an initial password, and set the TSM password change
interval to 30, 60, or 90 days, whatever your security office
recommends. The TSM server will change the password automatically at
those intervals and and send the new password down to the client as
needed. The password is encrypted and stored on the client (in the
registry for Windows, /etc/security for *IX).
PERSONS DO NOT NEED TO KNOW THIS PASSWORD.
The point of the client password is so that no one on client AAA can
spoof the TSM server and restore files belonging to BBB. When the TSM
scheduler does a backup, it gets the password out of the registry.
When a person LOGGED ON THE CLIENT MACHINE does a restore, the client
code STILL gets the password out of the registry; the person doesn't
need to know it.
2) For PERSONS not logged on the client machine to do restores remotely,
you give them each a TSM ADMINISTRATOR's id. Each PERSON has his own id
and his own password. At password interval change time, they are
prompted to change it.
You use GRANT AUTHORITY to give each helpdesk PERSON doing restores
CLIENT ACCESS or CLIENT OWNERSHIP rights to any machines they should be
doing restores for. That's all their TSM admin id has the right to do;
that's what it's for.
And I believe if you give someone a TSM id with DOMAIN level authority,
they can do web client restores for anyone in the TSM DOMAIN; tsm admins
with SYSTEM authority can do any client.
So PERSONS do restores using a PERSON's admin id and password, not the
CLIENT nodename and password.
Only gotcha: I believe the TDP for Oracle still can't use
PASSWORDACCESS GENERATE; maybe some other TDP's as well.
That one you have to manage differently.
Hope that helps!
Wanda Prather
"I/O, I/O, It's all about I/O" -(me)
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Andrew Carlson
Sent: Monday, May 02, 2005 2:59 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Password Management
This is a little embarassing, so bear with me. Since day one, with ADSM
on
the mainframe, we have used a password that matches the nodename. Yes,
I
know, not very secure.
In our environment, we have a help desk that does restores, as well as a
number of admins that end up doing restores that the help desk cannot
handle. We currently have almost 900 nodes. How do you all manage your
passwords?
The ideas we came up with are:
A standard, but secret password for all nodes - dangerous if someone
gets it, they have access to all servers. Also, if it's changed
periodically, we have to touch all the servers
A separate password per node, but not tied to the nodename. This would
require a protected password list stored somewhere for the people doing
restores to access.
Thanks for any input on this.
--
Andy Carlson - Senior Technical Specialist
BJC Healtcare
------------------------------------------------------------------------
---
Gamecube:$150,PSO:$50,Broadband Adapter: $35, Hunters License:
$8.95/month,
The feeling of seeing the red box with the item you want in
it:Priceless.
|
