How do you tighten up client access?

[Jeff_Jeske]

Lets start off with an example....

1 TSM server with 500 server clients. Of these 500 servers some are databases (containing thousands of customers info), some are files servers with home drives, some are code servers with proprietary code. Other servers are web and apps that are accessed from many different users with local admin rights.

What do you guys do to prevent one of those creative local admins from spoofing the opt file to recover a home drive information to the local disk of some app server?

In many cases the TSM client password is identical across the farm. Others may use a fairly simple pattern to make it easy to access all clients.

What is the most popular way to limit restore access only to TSM admins?

 

[cwilloug]

Set your password expiration period to 1 day.... simple (if you use any data protection clients for your databases check with the DBA on how they set up the passwords for the client)

q system - it will be in the first section

Check out the system admin guide......
SET PASSEXP (Set Password Expiration Date) Use this command to set the expiration period for administrator and client node passwords. You can set a common password expiration period for all administrators and client node passwords or selectively set password expiration periods. You can override this setting for one or more nodes by using the REGISTER NODE or UPDATE NODE command with the PASSEXP parameter. Attention: If you do not specify the NODE or ADMIN parameters, all client node and administrator passwords will use the new password expiration period. If you selectively set a password expiration period for a client node or administrator that does not already have a set password expiration period, it is not modified if you later set a password expiration for all users. The NODE or ADMIN parameters must be specified to change the password expiration period for client nodes or administrators that have selectively set password expiration periods. You can use the RESET PASSEXP command to reset the password expiration period to the common expiration period. Use the QUERY STATUS command to display the common password expiration period, which at installation is set to 90 days. Privilege Class To issue this command, you must have system privilege. Syntax

Set PASSExp days  , Node = node_name

 , Admin = admin_name
 Parameters days (Required) Specifies the number of days that a password remains valid. You can specify from 1 to 9999 if you do not specify the NODE or the ADMIN parameter. If you specify the NODE or the ADMIN parameter, you can specify from 0 to 9999. A value of 0 means that the password never expires. If a password expires, the server prompts for a new password when the administrator or client node contacts the server. Node Specifies the name of the node whose password expiration period you would like to set. To specify a list of nodes, separate the names with commas and no intervening spaces. This parameter is optional. Admin Specifies the name of the administrator whose password expiration period you SET PASSEXP
958 IBM Tivoli Storage Manager for Windows: Administrator’s Reference
would like to set. To specify a list of administrators, separate the names with commas and no intervening spaces. This parameter is optional.Examples Task 1 Set the administrator and client node password expiration period to 45 days. Command set passexp 45Task 2 Set the administrator LARRY’s password expiration period to 120 days. Command set passexp 120 admin=larry

 

[JohanW]

What do you guys do to prevent one of those creative local admins from spoofing the opt file to recovery lets say home drive information to the local disk of some app server?

Nothing.

In many cases the TSM client password is identical across the farm. Others may use a fairly simple pattern to make it easy to access all clients.

What is the most popular way to limit restore access only to TSM admins?

Data in TSM belongs to the client, not the server. Security of that data therefore belongs with the client, not the server. If client admins can guess someone else's password, that's not your problem. Restores should not be restricted to TSM admins, they should be restricted to only the owner/client admin, not even the TSM admin.

The security model in TSM is not very advanced, of course, and practical considerations may very well prevent decent security. Such is life ..

 

[Jeff_Jeske]

Thanks for the replies..... I'm not sure the passexp thing would work. We have 1000 clients the use that password to authenticat their nightly scheduled backup. Wouldn't changing the password to 1 day only allow them to authenticate 1 day?

Johan... I don't think you are understanding the scope of my question. If I gave you a test server called Server1 with password Server1 and I had a corporate file server called Server2 with password Server2 all you would have to do to gain access to every single document on Server2 was spoof the dsm.opt file. That means you have access to everyones home drive data, human resource data, and sometimes non disclosure data that can be restored to the local drive of Server1 without the security that prevented you from accessing it on Server2. In fact anyone that is on the network could download a client and access that data.

Now with 1000 servers you can't really use a unique password for everyone. You certainly don't want to use the servername as the password and if you use the same challenging password for all servers then how do you change it when an admin leaves the company?

 

[cwilloug]

The client changes its password and keeps track of the change, so server1 can not sign into server2. This is how I have my environment setup with no problems. You can change the password every day on the client settings or on the server settings. Try it on a few clients (via the ISC) and see if it works for you.

 

[Jeff_Jeske]

I'll give it a try but every once in awhile I do see client passwords expire and the CAD fails to connect with the following error:

ANR0425W Session #### for node ###### refused. Node password expired.

 

[heada]

Enable client-based encryption and have each client use a unique password. Without that password, you can not decrypt the backups. It gives the added benefit that if the tapes were ever lost, you can't dump any data from them as it is all encrypted.

-Aaron

 

[Jeff_Jeske]

That is similar to giving every node a unique password.

Back to this passexp issue..... how do you get beyond this error:


ANR0425W: Session session number for node node name (client platform) refused - Node password has expired.
Explanation
The server refuses the specified session because the client node’s password has expired.

System action
Server operation continues.

User response
Upon receipt of this error condition, the client program immediately reconnects to the server specifying a password update session and prompts the user for a new password. After the user enters a new password, the client reconnects to the server for normal operations. Alternatively, an authorized administrator can update the client password using the UPDATE NODE command.

 

[Phil_02GT]

Back to this passexp issue..... how do you get beyond this error:

Make sure the clients are using "Password generate" in the options file.
This way, the client changes it's password and sends it to the TSM server automatically every xx days based on the passexp setting.

This way, the only time that the password would be known by someone is when you manually reset it. The day after (or after the passexp setting) it is automatically changed.

 

[cwilloug]

oh, yeah,,, sorry forgot the password generate in the dsm.opt file part,,,,,

That's why you should read more,,, hehe

 

[Jeff_Jeske]

I have password generate in the opt file. I still get the password expired errors.

I'm going to make the passexp change to few test servers and see what happens.

 

[BBB]

Why do the clients need to know the TSM password anyway?

Set it to something random when each client is setup, then forget it. The encrypted password will be the the tsm.pwd file and clients won't need to enter it because its already been stored. Using password generate is good too, however you could have issues in clustered environments if its not setup right.

If you need a password so the clients can do web gui restores, give them individual admin accounts with access to only the clients that are under their control, and they use their own account rather than the client account to log in.

 

[Jeff_Jeske]

Well .... I guess I should say thank you. Setting the client password expiration to 1 day with password generate worked like a champ on my windows test box. This is what I was looking for. Until now we set every client password with expiration of zero meaning it never expired.

Does this work for AIX/Linux as well?

 

[Phil_02GT]

Yes it does.
The only difference between Windows and Unix is where the excrypted password is saved.
On Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\IBM\ADSM\CurrentVersion\BackupClient\Nodes\<nodename>\<TSM servername>\

Unix is in /etc/security/adsm/TSM.PWD