Administrators, the "admin" role, licensing and keeping things simple

[Jim Coyne]

Having separate admin accounts has been bugging me for a while now.   Why should we login with one account to do certain work and then another for other work.   We have LDAP/SSO-linked accounts that are usually members of assignment groups with specific roles so we can perform our day-to-day work but have to login with our "admin" account to perform any admin-type work.   Plus it costs 2 licences per administrator.   That's crazy.   So I decided to dig around a bit and came up with a way for your administrators to have just one account and it works quite well.

Try this in dev first, but the following is what you would end up doing in your production instance:

1. check the "Elevated privilege" on the "admin" Role record and save it
   
2. in case you have not done this already, create a Group called "ServiceNow Platform Administrators" or something similar
3. add the "admin" and "security_admin" Roles to the Group
4. add your administrators to the Group (their LDAP/SSO-linked accounts)
5. the users will inherit the 2 Roles from the Group
6. add passwords to the administrators accounts and check the "Password needs reset" field
7. have your admins log into the instance through the side_door.do page using their LDAP/SSO User ID and new ServiceNow password
8. they'll be asked to change their password
9. now they are logged into ServiceNow, bypassing any external authentication, with their "regular" everyday permissions
10. if they need to do any admin-type work, they can just elevate their privileges

This is basically how the "security_admin" role is setup now.   You have to elevate your privileges in order to perform certain tasks.   Why should it be any different for the "admin" role?

You can even add a few of the other "*_admin" roles, like "user_admin", "itil_admin", "knowledge_admin", etc... to the Group record so your admins have a little bit more permissions than they would with just "itil" so they do not have to elevate to "admin" as often.

That is all fine and dandy for your production instance, but what about your sub-prod ones?   You do not want to log into dev and then have to elevate to your admin privileges all the time, right?   There's an easy fix for that - just create a Clone Data Preserver record to preserve your "admin" role record which would not have the "Elevated privilege" field checked.   This way you log into the sub-prod instances and you are an admin immediately without having to elevate.       If you do go this route, check out this post - "View Data to Preserve" Tool.

Benefits:

• simple - 1 user = 1 account = 1 license
• save some $$$ on licensing
• protects us from mistakes, just like the "security_admin" role setup
• cannot bypass built-in processes
• allows you to login using just 1 account with external or internal authentication (crucial if your LDAP/SSO integration is down)
• gives us "admin" role in sub-prod instances immediately

Drawbacks:

• can't think of any

Thoughts?   I'd appreciate any feedback in case I missed something here.

[geoffchristy]

The spawned pages don't inherit the elevated privilege.   So, while it works really well for one page, if you try to do Form Designer for instance all the changes you make aren't really moved into the form.

I would love if they would properly allow us to do this.

[Jim Coyne]

I think that issue only shows up with the Form Designer - is that right?   Have you seen it with other pages?

[geoffchristy]

It's the only page I found before I had to turn it off.   I was worried about the workflow engine and other tabbed pages but didn't really have the time to test.

[paulmorris]

ServiceNow says it is best practice to have separate accounts.

On the other hand, two accounts = two licences, so why would in customer in their right mind do this?

I wish ServiceNow would make exceptions for admin accounts. For example, say that you get 1 admin license per 100 users for free. This gives customers the incentive to follow best practice.

I don't agree with having a single account for admin and operational though.

• I'm not a security admin but it seems like dual purpose account is considered bad practice in all facets of IT.
• Admins need to consume IT services to and are able to bypass process to their whim
• Applications and processes are not tested with 'admin' personas. They are not intended to be run as admins.
• It is easier to audit when privileged accounts are separate

I understand that it becomes a pain with SSO but that is why side_door exists.

[Jim Coyne]

I prefer the term "good practice" over "best practice", especially when it comes to process - what works for one company may not for another.

As far as I know, the only reason they suggest you use two accounts is to be able to log into your instance in case SSO is down.   That's not a very good reason for clients to pay for extra licenses.

Besides, this is how SN has setup the "security_admin" role - you need to elevate your privileges to get it.   It certainly seems like an obvious extension of that setup.

And to be honest, this is really meant to enhance the experience in sub-production instances.   You get to login with your SSO account and have your admin access right away.   You should rarely be elevating to an admin role in production anyways.

[jonathonbarton]

That's not a very good reason for clients to pay for extra licenses.

Exactly.

My first thought runs to "So, following 'recommended practice', what's the real cost per SSO outage?"

At one point, I was on a team that had 3 Admins in the production environment, and we had one brief SSO outage in over a year.

Cost of following "recommended practice"? About $2500-3000/year, or $91 per outage minute...

Our solution was to have our SSO accounts in the ServiceNow Administrators assignment group.

My thinking is that if you have serious concerns about your ServiceNow Administrators bypassing the IT Processes you've set up in your organization when it comes time for them to consume the services they're helping manage, perhaps you should look more closely at the folks you've appointed to the role. *shrug*

[Jim Coyne]

Agreed.   I remember working with a client who wanted to add a whole bunch of extra security so admins could not do some particular thing until I was able to convince them they could just circumvent it all anyways.

At the end of the day, you have to trust the people you hand the keys over to.

[G_Ede]

We were looking at the same thing recently, and the (partial) solution we came up with was to add two UI actions to the Self Service view of the User form.   These buttons are only available to users who have the "can_be_admin" role (a role we created for this purpose), which in itself grants no special privilages except access to the buttons.   One button removes the admin role from the current user via a script and the other adds it (assuming they have the "can_be_admin" role).

Unfortunately so far we've found that for the change to take effect you have to log out and back in again.   Not ideal, but the idea might be helpful.

[veeraveeras]

nice artical keep going on .................

[Jim Coyne]

Good news, there's a workaround for the Form Designer issue - just add the "personalize_form" role to your admin users.