missing Permission/Background process for the admin user ??

[Martin Ermel]

LMS 3.0.1; Login Module: CiscoWorks Local;

RME > Reports > Custom Report Templates

- shows a table whith all Templates generated by any user - no matter if they are created with a public or private scope;

- a user can edit only templates created by himself - this is ok;

- *every* user can click on the template name and view the template summary (even if it is private)

this - at least - is worth a discussion ....

- the admin account is not authorized to edit the templates generated by any other users; no matter if they are private or public; this is the error message:

CRIN0002: Not authorized to modify template sysUptime public.Contact your system administrator for further help.

==> the admin account should have access to *ALL* reports, rules, groups etc.....

RME Group Administration

RME > Devices > Group Administration

- for RME Groups every *public* group can be edit by any user; this is ok

- private groups can be viewed and edit only by the creator - even not the admin account can view private groups!

so far so good (or not so good) but the clue comes when you delete a user...

the report templates still belongs to the (removed) user name; if they need to be changed it is not possible,- but you can delete them....(and recreate them with an existing account - as you can view the template summary...)

for User defined Groups in RME its different:

- for groups with a public scope all is ok as other users can edit or delete them as before

- but for groups with a private scope it is tricky as they disappear from the GUI but still exists in the database and can consume some space depending on the number of devices they contain (**OgsGroupCacheTable);

recreating the deleted user account gives you back the old permissions and brings back the invisible private groups in RME...

I cannot believe that this works as designed...

I am not sure if upgrade procedures from previous versions of LMS respect these issues and clean up the databases (in terms of access privileges for reports or invisible private OGSGroups..)

Is it possible to change the behaviour that if a user is deleted the ownership of all his reports, groups, etc are moved to the admin account ? With this procedure no information would be lost and the admin can decide what to do.

Another idea is to move the ownership to a special named account (e.g. Zombie) which has no GUI login permission but the admin can see the reports and groups and move them to other accounts (like Unix chown).

A last idea is to force the admin to move reports and groups to existing accounts when the user is deleted...

[Joe Clarke]

The zombie group thing is fixable now. Just run NMSROOT/bin/DeleteStaleGroups.sh (or bat). That will remove groups for deleted users.

From what I have taken away from your description, it sounds like OGS is working as designed.

The report issue does seem a bit suspect. Everything sounds okay except:

"*every* user can click on the template name and view the template summary (even if it is private)"

This I cannot reproduce, and it is clearly wrong behavior. Only the creator and system admin can view private templates. Are you certain the users being tested are not admins themselves?

[Martin Ermel]

Does NMSROOT/bin/DeleteStaleGroups.sh remove all groups created by deleted users or only those with a private scope?

Why does OGS not respect the rights of a system admin and does not show private groups of a user to the system admin - I thought he should be able to have full control.

I double-checked the user roles - you are right,- sorry. The roles of the tested users have been changed in the past to include the system admin role as well. So admins can view private templates but they cannot edit them, again I thought a system admin should be able to do so.

[Joe Clarke]

It deletes all groups which are owned by the specified stale user.

This was discussed internally, and the conclusion was that private should mean that non-owners should not be able to modify private objects. However, system admins must be allowed to delete private objects. This scope of access of private objects is documented in the online help.

[Martin Ermel]

this is not good.

Imagine user_A created a public group and a private group. Other users can use the public group as a parent group to their own group. If user_A is deleted his private group will become invisible, his public group not - so the public group can still be used.

If I run DeleteStaleGroups.sh it will delete the 'sub-groups' which have the public group from user_A as parent as well. I highly doubt that this is ok in all situations.

I also think that private should be private but at least the in-build admin account (which is still marked as a special user with role 'F') should have the permission to control *everything*. In the past especially OGS could fire up the 'Device Selector'. Currently the admin account cannot even see private groups.

[Joe Clarke]

It would certainly be possible to add an option to the DeleteStaleGroups command to only delete private groups.

I happen to agree that the admin should have full access. I actually argued this point when DeleteStaleGroups came into existence. I lost, and thus DeleteStaleGroups was born.

[Martin Ermel]

So, I think it is the common way to get this feature implemented: rising a PERS and wait?

I still need to send Ashish a list with some open issues - now the list is longer...

will the upcoming OGS import/export feature help in any way?

[Joe Clarke · Accepted solution]

Maybe with a PERS, this approach could be revisited. The import/export feature will allow you (or should allow you) to move groups from one user to another, so it should help with some of this, yes.

[Martin Ermel]

thanks!