Dear friends, I saw some threads about the better model to create roles and manage user rights onto OVSD. However, try to imagine an IT&C organization with basic ITIL process implemented and over 150 people using OVSD with all it's sections! It is mandatory to modify roles(create new/modify) and user rights according with the following assumptions: 1. The following processes have been implemented: Change, Configuration, Call&Incident, Problem, SLM. 2. Change Management is a distributed process based on assigned WOs. 3. Domain Controllers and Administrators are CI's owners and are responsible with CMDB update only for owned CIs (and only for a limited no. of their attributes). 4. There are too many roles and user rights as a legacy of previously period before mature process implementation or due to a very poor OVSD customization at this level. (ex: a desktop domain controller is able to modify some similar attributes of a network CIs). So, I need an advise in order to have a good approach trying to bring manageability in roles definition and user rights within items category and further, at attributes level. Many thanks in advance. Dan
Set up a Basic role which has the minimum access anyone would need to all items (e.g.can view everything, but only modify while assigned to workgroup). Put access to views, templates, forms and actions on this role.
Then for each item type set up roles such as: Item Type Full (e.g Problem Full, Person Full)
Then when you assign roles to an account you give then basic and any of the others they need for their job. For example, a Change Manager would have Basic and Chnage Full, Project Full and workgroup full probably, and a SD agent would have Basic plus SC full etc.
This makes it quite simple to see who has what access rights and to add more as you need.
to get things going - have a look and identify the common attributes across the board. status, category, classifications etc. Make this your basic role. Look at the level of acces currently set for the attributes for each role. Identify the differences - you may be surprised and see very few differences. Ask the question can I make the differences available to more people in a general template. If you set auditing for the attributes you can audit in each record if needs be to see who changes what and when.
Use this role as a template for all new roles if you can. When creating new roles ask the question again, can I make the differences available to all people in the general template. If yes then don't create a new role. If no what are the security implications of all users accessing the attribute.
Assign in all the basic forms, views and templates as well while you are there.
Solution that Ruth described is best I think, but it is still complicated to restrict access rights to CMDB.
I need to limit access rights of modifying CIs. If person is not in administrator workgroup he should not be able to modify CI, but there are no such possibility to set this kind of limitation. (it is possible to set restrictions based on person who has entered CI). I have found solution, but it is complicated: It is possible to set different rights for CI based on folder in which CI is placed. You can specify different rights for different folders in different roles. CI placement in folders can be organized by rules. This is complicated solution and I'm still testing it. Folders is good possibility to hide some group of objects from part of users.
we looked at giving people access to change CI data on a er role basis and not the assigned to basis. Within normal roles all users will have the ability to change the CI attributes that have defined as user changeable which are the general attributes e.g. IP address, rack location, information
We have a Config role for the CMDB manager and his team which gives then the only rights to change the attributes that we dont want normal users updating and changing as these attributes have been identified as being required to run e.g. management reports against e.g. Cost - Status - SLA - Category (important for billing).
From Dan: "CI's owners and are responsible with CMDB update only for owned CIs (and only for a limited no. of their attributes)."
Problem is that CI owner (administrator person) should be able to modify only his owned CIs not others. For other CIs he should have only read only access. We have problems that person accidentally modifies CI that is not owned by him.
Approach you described is good, but it does not solves this particular problem. We have ~ 300 users on CMDB. Almost every user can be CI owner for some CI. CI owner can modify limited range of attributes for CI - every CI. What I want to do is to group these CIs (3-6 groups). In this case Person can change only these CI that are in his group (his folder) not all. Access rights to folders will be granted trough roles any way.
Hi all, Many thanks for your valuable advices and suggestions! I think that a peculiar track would be to use roles definition mentioned by Ruth combined with a CMDB foldering method indicated by Anda, and of course, a carefully re-design of access forms and templates to bring users restricted rights until CIs attributes level. Thank you all, Kind regards, Dan