A question was asked on the maestro-l mailing list recently about how to restrict the actions of a user so that they only have read-only access to objects in the plan and database, and also, they must only be able to “see” a subset of TWS workstations, despite there being additional agents running under the TWS Master.
The 2 ways into the plan are either through conman (which TWS/Webadmin also uses), or through the Tivoli Dynamic Workload Console. Whichever method is used, the TWS security file controls what they can or can’t do. Even if a user can see the jobs and schedules of an agent they shouldn’t have access to, as soon as they try and do anything, the TWS security file will have the final say in what they can actually do. Restricting user access through the security file to affect objects in the plan or database is one thing, but a better situation would be to remove all visibility of the agents, jobs, schedules, calendars etc. that don’t belong to their team or business area. You can do all that with a combination of TWS security file restrictions and using Websphere group membership.
The best situation you can get to, and with the most reduced level of administration, is to have the only way into TWS being governed by your LDAP authentication method, whichever that may be. Most companies use Active Directory, so if you can link Active Directory to your TWS security file and use Websphere administration groups, you can have a situation where when people join a team, their Active Directory group membership means they only see a limited set of menus in the Tivoli Dynamic Workload Console and their conman access (TWS/Webadmin too) only shows them a subset of workstations that you’ve granted them permission to see. By also linking Active Directory to TWS, their AD group membership can be linked by group to a stanza in the TWS security file meaning their AD group membership only allows them to perform a certain set of actions in the plan or database. Even if they can “see” something in TWS, they still can’t do anything, unless the TWS security file permits them to.
If you configure the TWS security file so that they can only see a certain set of objects in the first place, it makes everyone’s life easier, particularly if you’re having to look after hundred of users.
If you move away from local operating system accounts and put all the administration decisions into Active Directory group membership, particularly when you’re dealing with multiple Backup Master Domain managers, you will rarely need to touch the TWS security file at all, but the bonus being when someone leaves the company, their Active Directory account is usually removed immediately meaning they also now no longer have access to TWS. Having local operating system accounts deleted on multiple MDMs and Backup MDMs is often only done much further down the line so if Active Directory group membership controls all ways into TWS, your admin overhead is manageable, even if you’re looking at a large userbase.
Whether you’re using Active Directory or local operating system accounts on your MDM, you can still use the TWS security file examples in the next blog post to ring-fence what a user can see in the plan or database. Changing the menus a user can see in the Tivoli Dynamic Workload Console would be something for another blog post, but locking down the TWS security file will do most of what you want anyway.
If you’re looking to restrict access to certain objects in the plan or database, you can use restrictive clauses in the TWS security file by linking users or groups of users to a particular stanza. TWS works in a top-down fashion, trying to linking any action a user takes with a stanza in the security file. If a user is inadvertently caught twice, the first hit that TWS finds is the access they will get, so with that in mind, put your most restrictive levels of access at the top, and work down. IBM have added the capability for a user to be mentioned twice in the security file in later releases by using the CONTINUE keyword, but that would only be used in a specific set of circumstances.
The security file is extremely powerful and you can lock a user down to a considerable degree. The syntax, and some great examples are here In order to not only restrict actions, but also to remove visibility of items in the plan or database, 2 key items need to be considered:-
– The optman setting enListSecChk. Use optman chg enListSecChk = yes and optman ls should return enListSecChk / sc = YES. This is a global setting so only enable it once you’re happy all of your users have the LIST attribute assigned in the security file.
– The LIST attribute in the security file assigned to their position in the security file stanza.
With List Security Checking enabled, in order for a user to “see” an object in the database or plan, they must have the LIST attribute in the TWS security file at the section where TWS finds them when they perform an action. From the top-down, TWS searches for a user, and if it doesn’t find a match, that user cannot do anything, either in the plan or database. If a match is found, TWS will look to see what actions a user can take on that object (job, CPU, calendar etc.) based on what the security file says. If the security file says only allow this user to perform actions on CPU’s prefixed SERVER, and the user doesn’t have the LIST attribute at that stanza level, they won’t be able to see that agent’s job, schedules, calendars etc. through conman, or the TDWC.
In the next blog post, I will cover linking your Masters and TDWC servers to Active Directory, and touch on why an enforced naming convention is the path to easy admin. There is a definite need to have an additional keyword added to the TWS security file, particularly if your shop has just bought another company who also uses TWS or you host a multi-tenant cloud infrastructure and need separation for your clients. An additional keyword such as DESCRIPTION or LOB would enable this ring-fencing to occur easily and keyword is discussed in a Request for Enhancement here.