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 " Password needs reset:" 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.