Admin as an elevated role … do you have problems with this?

[Mark_Bailey]

Admin as an elevated role … do you have problems with this?

I've always had my Admin role set to elevated for both security reasons and to ensure I am not using my admin rights unless really needed. Twice now ServiceNow has told me I should not have admin set to elevated, it causes lots of problems. In order for me to separate the roles I would need two ID's.  My itil and my. My management is not signing off on me using two paid licenses.

Is anyone else in the same situation as I?

Do you just use two paid licenses?  

[robpickering]

We always had separate 'admin' accounts for use on the development system.

You could log into them on the Dev system and they were automatically admins (no need to elevate for anything but security_admin).

There were only two people that had 'admin' rights in Production and they had separate accounts.   To me, that felt better since they would have to consciously log into those accounts before making any changes.

-Rob

[Goran WitchDoc]

Thats how I always seen it as well.. Two accounts. One admin and one itil. Mostly the admin been local and itil through SSO or similar.

//Göran

[Mwatkins]

I looked through the code that adds elevated roles to a user session and I can't see any reason why it would cause issues. It uses the same method calls that are used during session startup to grant a users' roles to their SecurityManager (a static object in memory tied to a user's session). I'd be interested to see a reproducible case where this causes an issue.

[Mark_Bailey]

Hey Matthew,

Thanks for looking. Here is one example: Inc   3068571

Hi Mark,

Thanks for your patience! I found that your issue was "Admin user cannot delete incidents".

This was caused by the fact your "admin" role was configured as an "Elevated Privilege". This is not recommended, as it can cause issues with "Impersonations", "ACL" admin overrides, and user confusion.

I have revoked the "Elevated Privilege" setting on the "admin" role, and now "Mark Bailey" user can delete incidents.

I hope this solution resolves your issue sufficiently. I am happy to help you further should you have any questions.

[Mwatkins · Accepted solution]

Hi Mark,

I looked at that incident you mentioned. After reading through the notes, I noticed that the last update in the incident is as follows,

"Hi Mark,

I followed up on this issue and found that your out of box "Delete" ui action for list was modified.

There is an update you are missing, so I am attaching the out of box "Delete" ui action. Please import it into your system to resolve your issue.

I have confirmed that deletes on incident work now."

This makes me think the problem was not the elevated admin privileges, but, in fact, the real problem was the modifications to the "Delete" ui action. Could my understanding be correct? I am especially suspicious because on my demo instance, running Helsinki, I was able to successfully use elevated admin to delete multiple incidents.

Steps I took:

1. I activated the "elevated privilege" checkbox on the admin role,

2. logged out, logged back in

3. elevated to admin

4. opened the list of active incidents

5. checked all incidents on the list

6. clicked the "delete" drop down item from the list view

7. clicked the "continue" button in the multiple delete warning message popup

8. confirmed all incidents selected in step #6 were successfully deleted

My best guess is that the problem was actually not caused by the elevated admin role. I don't see any reason to believe that the way you are using the "elevated privilege" checkbox will not work.

Regards, Matthew