On Mon 10 Jan, 2000, "Ginsberg Rainer (QI/INF4) *" <Rainer.Ginsbergat_private> wrote: >ADSM uses a TCP connection. The port is configurable, default >is 1500. TCP connections will be established from both sides. >First, the server tells the client to do the backup, then the >client opens another connection and sends all its data. Here's my understanding of the current situation with ADSM (TSM). As things stand you can't limit where an Admin user can log in from, the admin client makes a connection to the same port 1500. Can someone get an admin client program/binary easily? Yes. Can someone connect from your system as an Admin? Yes, if they know/can deduce a user and password Can someone sit there guessing passwords for an Admin user? If you've not set an invalid signon limit. Can an admin user wreak havoc upon your backups? Yes, if they get one with sufficient privileges. You can stop an ADSM client (node) from being able to delete backup data, though. You've just got to hope that someone doesn't back up enough sets of data to blow a whole in your data retention policies (eg. Ten previous sets of files - make 10 backups of corrupted datafiles) before you notice and get back your off-sites: oh, you'd probably need to restore the database to match them too because it would have dropped all the previous backups. I don't think there's a way around that - talk with your site ADSM expert or try asking the ADSM-users list. (I expect there are similar issues with other backup products.) I can think of a few approaches to tackling the above issues. Maybe a second dedicated server which transfers its data, after the backup window, directly to another server? Or export filesystems inwards to a seperate partitioned network and backup from another node. James.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:56:58 PDT