Re: Securing TSM Client
>> On Tue, 11 May 2010 17:08:27 -0300, Leandro Mazur >> said: > The problem that we have is that the sysadmins are doing backups/archives > and restores/retrieves without our knowledge, with great impact on our > database (among other things...). Charge them for it, and charge them more if they're out of their window. :) - Allen S. Rout
Re: Securing TSM Client
I've tested this optionit works well, but in cases where the schedule calls a script, didn't worked because the client could not start the session... On Wed, May 12, 2010 at 12:32 PM, Shawn Drew < shawn.d...@americas.bnpparibas.com> wrote: > Intended for firewall security, the "sessioninitiation" property on the > nodes may work for this. > You will have to disable the setting if anyone actually wanted to do a > manual backup or restore > from the client side, but that's a quick "upd n" > > Only the TSM Server would be allowed to start client sessions. > > Regards, > Shawn > > Shawn Drew > > > > > > Internet > leandroma...@gmail.com > > Sent by: ADSM-L@VM.MARIST.EDU > 05/11/2010 04:08 PM > Please respond to > ADSM-L@VM.MARIST.EDU > > > To > ADSM-L > cc > > Subject > [ADSM-L] Securing TSM Client > > > > > > > Hello everyone ! > > I don't know if somebody has this kind of problem, but I have the > following > situation in the company I work for: > > - We have a TSM team to install, configure and maintain the whole backup > process, server and client; > - We have sysadmins that take care of the operational system and the > applications; > - When there's a need for any action to do with backup, they should open a > ticket for the TSM team; > > The problem that we have is that the sysadmins are doing backups/archives > and restores/retrieves without our knowledge, with great impact on our > database (among other things...). We would like to block the access on the > client, but we were not successful. If we use "password generate" on > dsm.sys, the password is prompted only at first access. If we use > "password > prompt", the scheduler doesn't work (ANS2050E)... > Any sugestions from the experts ? Maybe it could be a improvement to IBM > implement on the future... > __ > Leandro Mazur > > > > This message and any attachments (the "message") is intended solely for > the addressees and is confidential. If you receive this message in error, > please delete it and immediately notify the sender. Any use not in accord > with its purpose, any dissemination or disclosure, either whole or partial, > is prohibited except formal approval. The internet can not guarantee the > integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) > not therefore be liable for the message if modified. Please note that > certain > functions and services for BNP Paribas may be performed by BNP Paribas RCC, > Inc. > -- __ Leandro Mazur
Re: Securing TSM Client
Intended for firewall security, the "sessioninitiation" property on the nodes may work for this. You will have to disable the setting if anyone actually wanted to do a manual backup or restore from the client side, but that's a quick "upd n" Only the TSM Server would be allowed to start client sessions. Regards, Shawn Shawn Drew Internet leandroma...@gmail.com Sent by: ADSM-L@VM.MARIST.EDU 05/11/2010 04:08 PM Please respond to ADSM-L@VM.MARIST.EDU To ADSM-L cc Subject [ADSM-L] Securing TSM Client Hello everyone ! I don't know if somebody has this kind of problem, but I have the following situation in the company I work for: - We have a TSM team to install, configure and maintain the whole backup process, server and client; - We have sysadmins that take care of the operational system and the applications; - When there's a need for any action to do with backup, they should open a ticket for the TSM team; The problem that we have is that the sysadmins are doing backups/archives and restores/retrieves without our knowledge, with great impact on our database (among other things...). We would like to block the access on the client, but we were not successful. If we use "password generate" on dsm.sys, the password is prompted only at first access. If we use "password prompt", the scheduler doesn't work (ANS2050E)... Any sugestions from the experts ? Maybe it could be a improvement to IBM implement on the future... __ Leandro Mazur This message and any attachments (the "message") is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. Please note that certain functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.
Re: Securing TSM Client
Humm...that's interesting...I'll take a look ! Thanks Richard ! On Wed, May 12, 2010 at 8:18 AM, Richard Sims wrote: > Leandro - > > The problem you're dealing with is a personnel management one, which can't > be solved by technology alone. The management there is the only avenue of > solution. > > Technology can help, though. You can harvest records from the dsmaccnt.log > to compile a report to management demonstrating the times and data amounts > that inappropriate people have been performing TSM actions on that client, > by virtue of field 7 containing a username whenever dsmc is invoked by an > individual. You could go further by having a dsmadmc-based monitor > performing Query SEssion Format=Detailed to look for sessions from that > node: where the User Name is inappropriate, the monitor could then cancel > the session and send a notification of the usage violation. > >Richard Simsat Boston University > -- __ Leandro Mazur
Re: Securing TSM Client
Leandro - The problem you're dealing with is a personnel management one, which can't be solved by technology alone. The management there is the only avenue of solution. Technology can help, though. You can harvest records from the dsmaccnt.log to compile a report to management demonstrating the times and data amounts that inappropriate people have been performing TSM actions on that client, by virtue of field 7 containing a username whenever dsmc is invoked by an individual. You could go further by having a dsmadmc-based monitor performing Query SEssion Format=Detailed to look for sessions from that node: where the User Name is inappropriate, the monitor could then cancel the session and send a notification of the usage violation. Richard Simsat Boston University
Re: Securing TSM Client
Thanks for the answers ! About the sugestions: - I can't lock the nodes during the day, because several backups run every 2, 4 and 6 hours; - Lock the admin is a good sugetsion, although not possible... - The admins have the administrator/root password, so they can do anything... - Is not the occasional backups that worries me...instead of using the tsm client schedule, we just find out that they are using crontab/task scheduler to do backups (a lot of them !). Our ticket response time is 1 hour at mostFor 99% of the cases we have, it is more than acceptable; - We are having a considerable growth of our data, which causes the impact that I mentioned, but it is managable as long we don't have surprises like that It seems that the only thing I can do is convince the admins to not do...anyway, thanks for the help ! On Tue, May 11, 2010 at 7:22 PM, Remco Post wrote: > On 11 mei 2010, at 22:08, Leandro Mazur wrote: > > > Hello everyone ! > > > > I don't know if somebody has this kind of problem, but I have the > following > > situation in the company I work for: > > > > - We have a TSM team to install, configure and maintain the whole backup > > process, server and client; > > - We have sysadmins that take care of the operational system and the > > applications; > > - When there's a need for any action to do with backup, they should open > a > > ticket for the TSM team; > > > > The problem that we have is that the sysadmins are doing backups/archives > > and restores/retrieves without our knowledge, with great impact on our > > database (among other things...). > > if a system administrator running an occasional backup has _great_ impact > on your database, you need to reconsider your TSM infrastructure. I'm > assuming here that your system administrators have better things to do with > their time than running backups all day, so when they do, there is an actual > need for it. > > > We would like to block the access on the > > client, but we were not successful. If we use "password generate" on > > dsm.sys, the password is prompted only at first access. If we use > "password > > prompt", the scheduler doesn't work (ANS2050E)... > > Any sugestions from the experts ? Maybe it could be a improvement to IBM > > implement on the future... > > have you considered cattle prods? Except for Lindsay's suggestion of > locking everything down during the day (disable sessions at 7:00, enable > sessions at 18:00) there is no way. You may want to think about your > procedures, since they probably do this because raising a ticket takes to > long, and they need to get on with their work. > > > __ > > Leandro Mazur > > -- > Met vriendelijke groeten/Kind Regards, > > Remco Post > r.p...@plcs.nl > +31 6 248 21 622 > -- __ Leandro Mazur
Re: Securing TSM Client
On 11 mei 2010, at 22:08, Leandro Mazur wrote: > Hello everyone ! > > I don't know if somebody has this kind of problem, but I have the following > situation in the company I work for: > > - We have a TSM team to install, configure and maintain the whole backup > process, server and client; > - We have sysadmins that take care of the operational system and the > applications; > - When there's a need for any action to do with backup, they should open a > ticket for the TSM team; > > The problem that we have is that the sysadmins are doing backups/archives > and restores/retrieves without our knowledge, with great impact on our > database (among other things...). if a system administrator running an occasional backup has _great_ impact on your database, you need to reconsider your TSM infrastructure. I'm assuming here that your system administrators have better things to do with their time than running backups all day, so when they do, there is an actual need for it. > We would like to block the access on the > client, but we were not successful. If we use "password generate" on > dsm.sys, the password is prompted only at first access. If we use "password > prompt", the scheduler doesn't work (ANS2050E)... > Any sugestions from the experts ? Maybe it could be a improvement to IBM > implement on the future... have you considered cattle prods? Except for Lindsay's suggestion of locking everything down during the day (disable sessions at 7:00, enable sessions at 18:00) there is no way. You may want to think about your procedures, since they probably do this because raising a ticket takes to long, and they need to get on with their work. > __ > Leandro Mazur -- Met vriendelijke groeten/Kind Regards, Remco Post r.p...@plcs.nl +31 6 248 21 622
Re: Securing TSM Client
When you install TSM, only grant execute access to the TSM team and the account the backup runs under. Andy Huebner -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Leandro Mazur Sent: Tuesday, May 11, 2010 3:08 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Securing TSM Client Hello everyone ! I don't know if somebody has this kind of problem, but I have the following situation in the company I work for: - We have a TSM team to install, configure and maintain the whole backup process, server and client; - We have sysadmins that take care of the operational system and the applications; - When there's a need for any action to do with backup, they should open a ticket for the TSM team; The problem that we have is that the sysadmins are doing backups/archives and restores/retrieves without our knowledge, with great impact on our database (among other things...). We would like to block the access on the client, but we were not successful. If we use "password generate" on dsm.sys, the password is prompted only at first access. If we use "password prompt", the scheduler doesn't work (ANS2050E)... Any sugestions from the experts ? Maybe it could be a improvement to IBM implement on the future... __ Leandro Mazur This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.
Re: Securing TSM Client
Better to lock the admin. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Lindsay Morris Sent: Tuesday, May 11, 2010 3:59 PM To: ADSM-L@vm.marist.edu Subject: Re: [ADSM-L] Securing TSM Client Maybe you could lock all the nodes during the day (LOCK NODE...), and unlock them at night for your scheduled backups ... ? Lindsay Morris CEO, TSMworks Tel. 1-859-539-9900 lind...@tsmworks.com On Tue, May 11, 2010 at 4:08 PM, Leandro Mazur wrote: > Hello everyone ! > > I don't know if somebody has this kind of problem, but I have the following > situation in the company I work for: > > - We have a TSM team to install, configure and maintain the whole backup > process, server and client; > - We have sysadmins that take care of the operational system and the > applications; > - When there's a need for any action to do with backup, they should open a > ticket for the TSM team; > > The problem that we have is that the sysadmins are doing backups/archives > and restores/retrieves without our knowledge, with great impact on our > database (among other things...). We would like to block the access on the > client, but we were not successful. If we use "password generate" on > dsm.sys, the password is prompted only at first access. If we use "password > prompt", the scheduler doesn't work (ANS2050E)... > Any sugestions from the experts ? Maybe it could be a improvement to IBM > implement on the future... > __ > Leandro Mazur >
Re: Securing TSM Client
Maybe you could lock all the nodes during the day (LOCK NODE...), and unlock them at night for your scheduled backups ... ? Lindsay Morris CEO, TSMworks Tel. 1-859-539-9900 lind...@tsmworks.com On Tue, May 11, 2010 at 4:08 PM, Leandro Mazur wrote: > Hello everyone ! > > I don't know if somebody has this kind of problem, but I have the following > situation in the company I work for: > > - We have a TSM team to install, configure and maintain the whole backup > process, server and client; > - We have sysadmins that take care of the operational system and the > applications; > - When there's a need for any action to do with backup, they should open a > ticket for the TSM team; > > The problem that we have is that the sysadmins are doing backups/archives > and restores/retrieves without our knowledge, with great impact on our > database (among other things...). We would like to block the access on the > client, but we were not successful. If we use "password generate" on > dsm.sys, the password is prompted only at first access. If we use "password > prompt", the scheduler doesn't work (ANS2050E)... > Any sugestions from the experts ? Maybe it could be a improvement to IBM > implement on the future... > __ > Leandro Mazur >
