Run an Admin TI as a Non-Admin User
Run an Admin TI as a Non-Admin User
Im looking to allow apply read-only security to a number of cubes for non-admin users. Simple ! But these users will also be expected to execute TI processes to load data to these same target cubes. Is it possible for a non-admin user to execute a ti process but with the privaleges of an admin user ? Im wondering whether it is possible to call a process as a different user in order to execute the ti routine. Feasible ?
-
- Site Admin
- Posts: 1453
- Joined: Wed May 28, 2008 9:09 am
Re: Run an Admin TI as a Non-Admin User
Sure.
In fact, all TI processes execute with admin rights. You assign read access to groups to allow users (in those groups) to run them.
In fact, all TI processes execute with admin rights. You assign read access to groups to allow users (in those groups) to run them.
Re: Run an Admin TI as a Non-Admin User
David, thanks for that but maybe you misunderstand my predicament.
I have series of cubes where data is loaded from TI process. The target cells are currently open to data entry in cube viewer. What I would like to do is add cell security so in cube viewer the cells are greyed out but then allow the same non-admin users to execute ti processes to load data to these read only cells.
I would presume that if I apply read only cube security the non admin users wont be able to execute the ti routines to update the cube ?
Or does the ti process not respect the cube security of the user ?
Thanks.
I have series of cubes where data is loaded from TI process. The target cells are currently open to data entry in cube viewer. What I would like to do is add cell security so in cube viewer the cells are greyed out but then allow the same non-admin users to execute ti processes to load data to these read only cells.
I would presume that if I apply read only cube security the non admin users wont be able to execute the ti routines to update the cube ?
Or does the ti process not respect the cube security of the user ?
Thanks.
-
- MVP
- Posts: 733
- Joined: Wed May 14, 2008 11:06 pm
Re: Run an Admin TI as a Non-Admin User
Actually, you didn't explain your predicamentBeast wrote:David, thanks for that but maybe you misunderstand my predicament.
See this IBM technoteBeast wrote:I would presume that if I apply read only cube security the non admin users wont be able to execute the ti routines to update the cube ?
Or does the ti process not respect the cube security of the user ?
Robin Mackenzie
-
- Site Admin
- Posts: 1453
- Joined: Wed May 28, 2008 9:09 am
Re: Run an Admin TI as a Non-Admin User
Think I did understand....David, thanks for that but maybe you misunderstand my predicament.
Yes....I have series of cubes where data is loaded from TI process. The target cells are currently open to data entry in cube viewer. What I would like to do is add cell security so in cube viewer the cells are greyed out but then allow the same non-admin users to execute ti processes to load data to these read only cells.
No....I would presume that if I apply read only cube security the non admin users wont be able to execute the ti routines to update the cube ?
Exactly. What was unclear about the passageOr does the ti process not respect the cube security of the user ?
?all TI processes execute with admin rights
Re: Run an Admin TI as a Non-Admin User
Thanks for the link to the technote perfect. Much appreciated.
-
- Community Contributor
- Posts: 217
- Joined: Thu Aug 15, 2013 9:05 am
- OLAP Product: TM1
- Version: 10.2.1.1
- Excel Version: 14.0.6129.5000
Re: Run an Admin TI as a Non-Admin User
Hello Beasts,
another way around this is to fire a TI from a batch script.
You may of heard about the TM1RunTI.exe program. This program allows you to fire a TI outside of TM1. All you need is for the Server to be running.
You only need to use someones username and password to connect to TM1, this will be the same as your normal password or, if you are in run state 1, you would use the admin account.
This solution will allow anyone to fire the batch (or program if you want to make it more sophisticated) which will fire any TI process you want. TM1 user security need not be an issue.
There is alot of documentation around this functionality, but let me know if I can explain in more detail, or if this is no use to you at all.
Thanks.
Trevor.
another way around this is to fire a TI from a batch script.
You may of heard about the TM1RunTI.exe program. This program allows you to fire a TI outside of TM1. All you need is for the Server to be running.
You only need to use someones username and password to connect to TM1, this will be the same as your normal password or, if you are in run state 1, you would use the admin account.
This solution will allow anyone to fire the batch (or program if you want to make it more sophisticated) which will fire any TI process you want. TM1 user security need not be an issue.
There is alot of documentation around this functionality, but let me know if I can explain in more detail, or if this is no use to you at all.
Thanks.
Trevor.
-
- MVP
- Posts: 733
- Joined: Wed May 14, 2008 11:06 pm
Re: Run an Admin TI as a Non-Admin User
Trevor, it's a useful suggestion, but perhaps you missed a subtlety in the OPs question - he was questioning if a users cube security permissions were taken into account by a TI process - the answer being that TI's always run with admin privilege. Running the TI via TM1RunTI.exe doesn't change this.
IBM wrote:Question
When a user runs a TM1 TurboIntegrator process, does the process have the rights of the user running the process?
Answer
A TurboIntegrator process can be created only by an administrator, who has Admin privileges required to create a process. The administrator can assign rights to the process. The TurboIntegrator process has those rights regardless of the rights assigned to any user running the process.
Non-admin users need to have Read access to a TurboIntegrator processes in order to see the process in the interface and to execute the process. But the TurboIntegrator process itself retains the rights assigned by the administrator.
For example consider a user and an administrator where:
User U1 has only Read access to cube_1.
The administrator creates a TurboIntegrator process that does a CellPutN into cube_1, which requires Write access to the cube.
The administrator gives U1 Read access to the TurboIntegrator process.
U1 can run this TurboIntegrator process and it will do the CellPutN even though the user only has Read access to cube_1. The same result is obtained if U1 has None access to cube_1.
A user with only Read access to a TurboIntegrator process can only view and execute the process. The user can't edit the process to change the value being sent or the location where data is being put.
The conditions described above are also true when a user executes a TurboIntegrator process from within a chore.
To prevent U1 from being able to access this TurboIntegrator process, the TM1® administrator should not give U1 Read access to the TurboIntegrator process.
Robin Mackenzie
-
- Community Contributor
- Posts: 217
- Joined: Thu Aug 15, 2013 9:05 am
- OLAP Product: TM1
- Version: 10.2.1.1
- Excel Version: 14.0.6129.5000
Re: Run an Admin TI as a Non-Admin User
rmackenzie,
thanks for your reply and I take your point. My suggestion is more to do with how to run a TI differently rather than the details of cube security in relation to TI processes.
Thanks also for the IBM note, will take on board.
thanks for your reply and I take your point. My suggestion is more to do with how to run a TI differently rather than the details of cube security in relation to TI processes.
Thanks also for the IBM note, will take on board.
- qml
- MVP
- Posts: 1094
- Joined: Mon Feb 01, 2010 1:01 pm
- OLAP Product: TM1 / Planning Analytics
- Version: 2.0.9 and all previous
- Excel Version: 2007 - 2016
- Location: London, UK, Europe
Re: Run an Admin TI as a Non-Admin User
Just to add some more detail to this thread in case anyone finds it of use.
All processes always execute with Admin rights, as David said. However, what does it mean exactly? Firstly, there are 3 types of admin roles in TM1:
If a TI is to make security changes it needs to be executed by a user who is a member of the ADMIN group (SecurityAdmin group should work too, but don't quote me on this, I would need to double check). Alternatively, the TI itself can be set to run with 'Security Access', a parameter that can be set for each process individually from the context menu. When this is done, any user who has at least READ access to that TI can run it successfully.
To sum up, it is not strictly true that regardless of who runs the TI it always runs with the same full access. In the case described the access of the user that runs the process trickles down to the process itself and is not 100% abstracted away (but it gets very close).
All processes always execute with Admin rights, as David said. However, what does it mean exactly? Firstly, there are 3 types of admin roles in TM1:
- ADMIN
DataAdmin
SecurityAdmin
If a TI is to make security changes it needs to be executed by a user who is a member of the ADMIN group (SecurityAdmin group should work too, but don't quote me on this, I would need to double check). Alternatively, the TI itself can be set to run with 'Security Access', a parameter that can be set for each process individually from the context menu. When this is done, any user who has at least READ access to that TI can run it successfully.
To sum up, it is not strictly true that regardless of who runs the TI it always runs with the same full access. In the case described the access of the user that runs the process trickles down to the process itself and is not 100% abstracted away (but it gets very close).
Kamil Arendt
-
- MVP
- Posts: 733
- Joined: Wed May 14, 2008 11:06 pm
Re: Run an Admin TI as a Non-Admin User
Hey QML, it's a good clarification, no doubt. But, it's unusual for a user to get READ access on a TI that's updating security, don't you think?
On a slight tangent, did you ever work on a model where someone was actually assigned into the SecurityAdmin group?
On a slight tangent, did you ever work on a model where someone was actually assigned into the SecurityAdmin group?
Robin Mackenzie
-
- MVP
- Posts: 1815
- Joined: Mon Dec 05, 2011 11:51 am
- OLAP Product: Cognos TM1
- Version: PA2.0 and most of the old ones
- Excel Version: All of em
- Location: Manchester, United Kingdom
- Contact:
Re: Run an Admin TI as a Non-Admin User
I've used this in loads of models to create custom workflow processes from the day's before Contributor started to look somewhat usable; it just allowed you to keep track of who finishes and when (and make sure that they are locked out once they say they are finished.)rmackenzie wrote:But, it's unusual for a user to get READ access on a TI that's updating security, don't you think?
Also tend to do a lot of administration such as period rollforwards etc via TI in websheets to give "super users" control over that sort of thing without them really needing any sort of dangerous admin access.
I can sort of vaguely see in a huge model where the security and data admin groups would be beneficial but then 99 times out of 100 if you trust someone to be in one group you'd hope they'd be trained up/competent enough to be full admins. I have never actually implemented them or seen any model where someone else has.rmackenzie wrote:On a slight tangent, did you ever work on a model where someone was actually assigned into the SecurityAdmin group?
Declan Rodger
- qml
- MVP
- Posts: 1094
- Joined: Mon Feb 01, 2010 1:01 pm
- OLAP Product: TM1 / Planning Analytics
- Version: 2.0.9 and all previous
- Excel Version: 2007 - 2016
- Location: London, UK, Europe
Re: Run an Admin TI as a Non-Admin User
Historically - no doubt. However, TM1 is being used more and more as an Enterprise tool and part of larger suites of applications and often needs to have very specific security considerations to match the IT landscape. I have recently created a TM1 application where there is not a single user with ADMIN/DataAdmin/SecurityAdmin access (except for the native ADMIN user, but it's set up as impossible to log onto). So naturally, READ access to TIs, including those managing security, is the only option left there. (Edit: ok, technically, another option is to grant ADMIN access to individual processes, but that's beside the point.)rmackenzie wrote:But, it's unusual for a user to get READ access on a TI that's updating security, don't you think?
Oh yes. Not on a regular basis, but it does have its uses in certain situations. There are companies out there that are extremely serious about things like 'segregation of duties' and 'data protection'.rmackenzie wrote:On a slight tangent, did you ever work on a model where someone was actually assigned into the SecurityAdmin group?
Kamil Arendt
-
- MVP
- Posts: 733
- Joined: Wed May 14, 2008 11:06 pm
Re: Run an Admin TI as a Non-Admin User
TM1 was quite widely used for resource planning prior to the paradigm shift to 'enterprise', and this was always a concern back then (salary/ bonus confidentiality etc), before the introduction of the SecurityAdmin group.qml wrote:Historically - no doubt. However, TM1 is being used more and more as an Enterprise tool and part of larger suites of applications
So you removed everyone from those groups, just before promoting to Production, but some permissions remain in Test/ Dev environments? I'm just curious about why the 'regular' users would need to change security, via TI, if the system is locked down like that? Or, are these TIs for the 'admins' that just happen not to be in any admin group anymore?qml wrote:I have recently created a TM1 application where there is not a single user with ADMIN/DataAdmin/SecurityAdmin access (except for the native ADMIN user, but it's set up as impossible to log onto). So naturally, READ access to TIs, including those managing security, is the only option left there.
Sorry, one more question! In those situations, do you still have people in the regular Admin group? Or is it a variant of the above where there are no Admin/ DataAdmins in Production and just SecurityAdmins; for people on service desk etc who need to create/ remove users as they come and go?qml wrote:Oh yes. Not on a regular basis, but it does have its uses in certain situations. There are companies out there that are extremely serious about things like 'segregation of duties' and 'data protection'.rmackenzie wrote:On a slight tangent, did you ever work on a model where someone was actually assigned into the SecurityAdmin group?
Robin Mackenzie