IC5Notice: We have upgraded developerWorks Community to the latest version of IBM Connections. For more information, read our upgrade FAQ.
Topic
  • 4 replies
  • Latest Post - ‏2013-02-04T23:41:51Z by SystemAdmin
SystemAdmin
SystemAdmin
2038 Posts

Pinned topic How to avoid a mass mistake

‏2013-01-30T15:34:20Z |
Guys:
I have a question for the more experienced TEM amdinistrators. What safeguards can you put in place to avoid mistakes by a TEM master operator? By mistake I mean, performing an operation against a large amount of machines, like a mass shutdown for example. I'm interested on technical controls and not procedural, like for example, delaying the contact with the TEM clients so an action can be recalled.
I'm trying to deploy TEM across a wide organization, however a smaller sub organization was using TEM and accidentally performed an action against a large group of machines. Now management is a little afraid of deploying the tool against the wider organization and have it happen again on a bigger scale.
My plan is to deploy one TEM infrastructure and use the Master Operator to perform only userid management and permissions. All other endpoint related operations would be done by individual operator ids owned by the sub organizations. Any tips on maybe preventing the master operator from performing operations against machines? Any way to delay the sending of commands to endpoints? Or maybe a way to throttle contacting endpoint command execution when is executed against a large set of machines?
Thanks
Paulo
Updated on 2013-02-04T23:41:51Z at 2013-02-04T23:41:51Z by SystemAdmin
  • SystemAdmin
    SystemAdmin
    2038 Posts

    Re: How to avoid a mass mistake

    ‏2013-01-30T19:50:20Z  
    If you want to go with an Ultra Paranoid, someone check what I'm about to do method, look into "Four eyes Authentication".
    It's a little extreme, and I don't think it can be applied to a Master Operator, but I use it for one of our ISO Staff that didn't want to risk deploying something by accident. Because they needed to "see all computers" I thought that was the best route, that and I couldn't find any other way to make a Read-Omly user account.

    Truthfully, I don't think there IS any way to restrict a Master Operator. Hence the word MASTER.

    I'm in the final stages of setting up a new TEM environment and migrating an older one into it. In the new environment, we made use of Roles and linked them to AD groups so I won't have to create accounts by hand, only add a Domain user to a Domain group. Can you go that route?
  • SystemAdmin
    SystemAdmin
    2038 Posts

    Re: How to avoid a mass mistake

    ‏2013-02-04T14:41:29Z  
    If you want to go with an Ultra Paranoid, someone check what I'm about to do method, look into "Four eyes Authentication".
    It's a little extreme, and I don't think it can be applied to a Master Operator, but I use it for one of our ISO Staff that didn't want to risk deploying something by accident. Because they needed to "see all computers" I thought that was the best route, that and I couldn't find any other way to make a Read-Omly user account.

    Truthfully, I don't think there IS any way to restrict a Master Operator. Hence the word MASTER.

    I'm in the final stages of setting up a new TEM environment and migrating an older one into it. In the new environment, we made use of Roles and linked them to AD groups so I won't have to create accounts by hand, only add a Domain user to a Domain group. Can you go that route?
    Tim:
    Thanks for the response. I'll look at the "Four Eyes authentication"!
    I'm thinking in going the route you are suggesting, but I'll be using a generic LDAP server.
    Thanks
    Paulo
  • MBARTOSH
    MBARTOSH
    36 Posts

    Re: How to avoid a mass mistake

    ‏2013-02-04T15:13:35Z  
    Tim:
    Thanks for the response. I'll look at the "Four Eyes authentication"!
    I'm thinking in going the route you are suggesting, but I'll be using a generic LDAP server.
    Thanks
    Paulo
    Limit the number of users who do mass deployments to two or three, and have close communication between those doing deployment. Discuss the the deployments before you take them.

    If you are taking an action against an automatic group and you are making adjustments to the automatic group be sure to stop the action while you are making changes. Then wait a couple of cycles before restarting the action in order to make sure the automatic group is correct.

    I wish there were an option in TEM to limit the number of machines that could be targeted in one action. We have about 30 console operators, and it is dangerous that any of them could take an action against the all computers group, or any other larger group. An enhancement I would like to see is that console operators could only select computers or enter computer names and not select a group, as well as, limit the number of computers per action per operator. I realize that there is a concept of sites and site assignment, but that really doesn't fit our model. I would limit our console operators to no more than 20 machines per action.
  • SystemAdmin
    SystemAdmin
    2038 Posts

    Re: How to avoid a mass mistake

    ‏2013-02-04T23:41:51Z  
    • MBARTOSH
    • ‏2013-02-04T15:13:35Z
    Limit the number of users who do mass deployments to two or three, and have close communication between those doing deployment. Discuss the the deployments before you take them.

    If you are taking an action against an automatic group and you are making adjustments to the automatic group be sure to stop the action while you are making changes. Then wait a couple of cycles before restarting the action in order to make sure the automatic group is correct.

    I wish there were an option in TEM to limit the number of machines that could be targeted in one action. We have about 30 console operators, and it is dangerous that any of them could take an action against the all computers group, or any other larger group. An enhancement I would like to see is that console operators could only select computers or enter computer names and not select a group, as well as, limit the number of computers per action per operator. I realize that there is a concept of sites and site assignment, but that really doesn't fit our model. I would limit our console operators to no more than 20 machines per action.
    Check out http://www.ibm.com/developerworks/forums/thread.jspa?threadID=452604 for a web based Console that, when I last tested it, only allows single actions against single machines.