There are multiple procedures for this, and it depends on the kinds of user, and the privileges they should have.
| Table of Contents |
|---|
Creating an account
NetID-based Yale affiliate users
The vast majority of ServiceNow users are Yale affiliates with netid-based login credentials. The settings for these kind of users come from multiple data imports. The main user information import is IST-User, which gets netid and related user fields. There are also two LDAP (Active Directory) imports that come from Yale Central Auth. The Yale-User LDAP import includes phone number information and related fields. The Yale-Group LDAP import contains mappings between netids and ServiceNow Assignment Groups (and Groups that serve no purpose except to assign roles).
...
Creation and disabling of these accounts is fully automated by integrations with Central Auth and Active Directory.
Fake user accounts to handle inbound email
These cases are people who have a business need to correspond with Yale, but do not have a netid (and should not have a netid). Examples are people who need to communicate with the webmaster for abuse complaints, certain vendors, etc. These people should be tracked in ServiceNow, and by having unique ids associated with them, we can track their historical issues. Especially useful if they ask for something from one person, the Yale employee says no, and then they come back and try to ask for the same thing from a different person.
...
Creation of these accounts is fully automated by integrations with email and scripts we wrote at Yale.
Caveat for all local accounts
For any kind of local accounts, we must first evade Yale Single Sign On (SSO) technology. To do this, we must NOT have a CAS ticket in the browser we use for accessing ServiceNow as a local user. Most people who need to use ServiceNow admin on a regular basis end up using TWO browsers:
...
In this manner, there is a separation of duties, and it's quick to verify work you performed as a privileged user by checking the feature as a non-privileged user.
Local Service accounts
Before trying to access local accounts, read the Caveat for all local accounts.
...
These accounts almost never require maintenance. Various accounts require certain rights; the most tricky one is the SOAP role (and associated roles with the name soap in them) if the account requires access to the API.
Local named non-admin user accounts
Before trying to access local accounts, read the Caveat for all local accounts.
...
Because these accounts have high levels of privilege, we manage them with entries in the post-clone script. Post-Clone Procedure
Local admin user accounts
Before trying to access local accounts, read the Caveat for all local accounts.
...
Notice that many admin accounts are non-Active in most environments. We retain these accounts as non-active in certain environments because cloning down will change the properties of local accounts, including their credentials. If we didn't have the accounts in the higher environments, we would need to recreate the users manually each time after we did a clone, and that would be a waste of time for everybody involved.
Maintaining the post-clone
The post-clone is stored at: Post-Clone Procedure
...
Obviously, this will only capture logic code errors, and not failures of writing the script properly to do what you meant it to do.
Creating a new account, and cloning it around
Different people have different opinions about how to do this. None is correct absolutely, so here's an algorithm.
...
- Direct user receiving account to visit yale.service-now.com/side_door.do
- login in with username, and temporary password
- confirm they have reset their password. You can tell by reviewing the user record. The toggle for 'Password needs reset' will untoggle after they have successfully changed their password
- toggle off their PRD access by untoggling the Active flag on their user record. Alternatively, force a run of the post-clone to untoggle their PROD Active flag on their user record.
- Direct user receiving account to visit yalepreproduction.service-now.com/side_door.do
- login in with username, and temporary password
- confirm they have reset their password. You can tell by reviewing the user record. The toggle for 'Password needs reset' will untoggle after they have successfully changed their password
- toggle off their PRE access by untoggling the Active flag on their user record. Alternatively, force a run of the post-clone to untoggle their PROD Active flag on their user record.
- Direct user receiving account to visit yaletest.service-now.com/side_door.do
- login in with username, and temporary password
- toggle off their TST access by untoggling the Active flag on their user record. Alternatively, force a run of the post-clone to untoggle their PROD Active flag on their user record.
- Direct user receiving account to visit yaledevelopment.service-now.com/side_door.do
- login in with username, and temporary password
- You probably need to leave their DEV access.
- Don't worry about TRAIN unless this is a trainer. In most cases, we leave TRAIN access toggled off, and we just wait for the next PROD clone to create the account (which is disabled from the PROD clone, and further never enabled by the post-clone script)
Deleting / disabling an account
NetID-based Yale affiliate users
We retain the netid account in our system for data tracking, and the account will be marked inactive when Central Auth (IST and Active Directory) toggle it accordingly and we run the next import against that data.
Fake user accounts to handle inbound email
These are non-login accounts. These accounts do default to Active. At times we may want to toggle them to in-Active. Doing so will prevent them from ingressing new Incidents via email. This is a useful feature if particular email addresses are sending spam into ServiceNow.
Local Service accounts
These are local accounts, and they're pretty useless unless they are toggled Active. If we toggle them inActive, or we take away Roles / Group associations, we may also render the account useless for the purpose it was created for. Don't disable these unless we've already spoken to the group that manages the application they were created for.
Local named non-admin user accounts
These are local accounts, and there are only a handful of them. Generally, if these accounts exist, it's because the user does not have admin in that environment. Once we trust a user enough to grant them admin, we should probably take away their non-admin local account.
...
If all we are doing is granting or denying a specific instance, that can be done with changing post-clone (see procedure) and then running post-clone again manually in the environment where the access is getting granted. If access is getting taken away in a specific instance, we still need to change post-clone, but we will need to manually toggle off the access in the environment losing the access.
Local admin user accounts
These accounts are most easily found by going to the admin role, and then looking for accounts associated with the role.
Notice that many admin accounts are non-Active in most environments. We retain these accounts as non-active in certain environments because cloning down will change the properties of local accounts, including their credentials. If we didn't have the accounts in the higher environments, we would need to recreate the users manually each time after we did a clone, and that would be a waste of time for everybody involved.
Taking away a local admin account requires editing post-clone. See Post-Clone Procedure
It's safe to delete these accounts when we no longer need them. It's unlikely we would ever re-grant an admin local account.
If all we are doing is granting or denying a specific instance, that can be done with changing post-clone (see procedure) and then running post-clone again manually in the environment where the access is getting granted. If access is getting taken away in a specific instance, we still need to change post-clone, but we will need to manually toggle off the access in the environment losing the access.
Changing passwords
Most users (regular netid accounts and fake user accounts)
Regular netid Yale affiliates are fully automated, and authenticate via CAS. Therefore, they don't actually talk directly to ServiceNow, and they don't set their credentials in ServiceNow, but rather login with their Central Auth credentials.
The fake accounts we have that are email based, and have the naming convention account@domain.tld are fake users, and cannot login to ServiceNow. Their user accounts do not count for licensing purposes, and they cannot reach the system, because it is behind CAS and they do not have a netid login.
Local users (service accounts, local non-admins, local admins)
See the caveat for all local accounts above.
Only local accounts authenticate to ServiceNow directly. To do so, we first have to evade CAS and go to the side door. See the handoff algorithm section for a complete set of links to the side door interface.
There is a self-service module for Service Now, to allow local users to do a self-reset on their password from the side door login screen. We have never enabled the plugin. If we change our mind in the future, info available at: http://wiki.servicenow.com/index.php?title=Self_Service_Password_Reset
Instead, we can do this directly from the local user record.
We can set a temporary password directly by going to the local user record, setting a password in the password field, toggling the " " variable, and then Save on the record. Now when the user goes to login at side door, they will use the temporary password you provided, and will immediately be prompted to set their own password. This is the same technique we use when we hand over local accounts for the first time.
If the admin user knows their own password and wants to change it, they can modify their own user record password directly.