- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
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:
- check the "Elevated privilege" on the "admin" Role record and save it
- in case you have not done this already, create a Group called "ServiceNow Platform Administrators" or something similar
- add the "admin" and "security_admin" Roles to the Group
- add your administrators to the Group (their LDAP/SSO-linked accounts)
- the users will inherit the 2 Roles from the Group
- add passwords to the administrators accounts and check the "Password needs reset" field
- have your admins log into the instance through the side_door.do page using their LDAP/SSO User ID and new ServiceNow password
- they'll be asked to change their password
- now they are logged into ServiceNow, bypassing any external authentication, with their "regular" everyday permissions
- 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.
- « Previous
-
- 1
- 2
- Next »
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.