Versions Compared

Old Version 2

changes.mady.by.user David Backeberg

Saved on

compared with

New Version Current

changes.mady.by.user David Backeberg

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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).

These users almost never require maintenance, except when something goes wrong with the IST-User import. Find out more about that at: User import issues in ServiceNow

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.

We made a decision in late-2012 or early-2013 to allow inbound email from non-Yale people. We ended up handling this by allowing inbound mail to create new fake user accounts. The netid field is set to the email address from which ServiceNow received the email address.

These are the second most-common kind of accounts. As of July 1, 2014, the count of these users is: 2355. The report is https://yale.service-now.com/sys_user_list.do?sysparm_query=GOTOuser_nameLIKE%40

These accounts follow patterns like:

14154568@bigpond.com

Nobody logs into these accounts, but having them allow us to track issues by a unique id. One nice feature is we can control inbound spam from specific users by then toggling their user account to non-Active (which prevents them from generating incidents via email).

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:

  1. for their regular daily work, as a signed-in Yale employee
  2. for their ServiceNow local-user work (such as admin), as a local user

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.

There are a small handful of user accounts in ServiceNow for various integrations with external systems or services.

...

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.

There are a small number of non-admin user accounts in ServiceNow for various purposes.

...

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.

There are a small number of accounts with admin privileges. 

...

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.

First, go maintain the post-clone. Once you've done that, come back to these instructions.

  1. Go to DEV, User Admininstration -> Users -> New
  2. In the New User dialogue, at minimum, populate the NetID, First name, Last name. If they are a vendor, also populate email address and Business Phone. We will need Business Phone to hand over their login credentials. If you are immediately handing the account over, leave the Active toggle alone. If it will be a few days, toggle Active to false. Also set a temporary password, ideally difficult, which you can remember. Writing it down is okay; this is temporary, and you will need to share it with the user receiving the account. Copy the temporary password to your clipboard, and paste it into the user record. Also set the toggle for "Password needs reset".
  3. Save and Stay, and now you will see Roles.
  4. Edit roles and add any that are required.
  5. Clone this account by: Right Click on colored bar at the top of the user record dialogue, then choose Export -> XML (This record)
  6. Save the record to your local machine
  7. Go to TEST, User Admininstration -> Users
  8. Right click on colored bar at the top of the user records listing, then choose Import XML, and use the browser file picker to retrieve the record you just saved to your local machine
  9. Use the Users people picker tool to pick the record you just added. Manually add back any role(s) you assigned in step 4
  10. Paste in the temporary password.
  11. Save and Stay.
  12. Go to PRE, User Admininstration -> Users
  13. Right click on colored bar at the top of the user records listing, then choose Import XML, and use the browser file picker to retrieve the record you just saved to your local machine
  14. Use the Users people picker tool to pick the record you just added. Manually add back any role(s) you assigned in step 4
  15. Paste in the temporary password.
  16. Save and Stay.
  17. Go to PRD, User Admininstration -> Users
  18. Right click on colored bar at the top of the user records listing, then choose Import XML, and use the browser file picker to retrieve the record you just saved to your local machine
  19. Use the Users people picker tool to pick the record you just added. Manually add back any role(s) you assigned in step 4
  20. Paste in the temporary password.
  21. Save and Stay.
  22. Go to TRN, User Admininstration -> Users
  23. Right click on colored bar at the top of the user records listing, then choose Import XML, and use the browser file picker to retrieve the record you just saved to your local machine
  24. Use the Users people picker tool to pick the record you just added. Manually add back any role(s) you assigned in step 4
  25. Paste in the temporary password.
  26. Save and Stay.

Handing the account to the user.

It is Yale Policy to never email a password or other sensitive information. For Yale affiliates on campus, do the account exchange in person. This also allows you to confirm the user can access their account. For vendors, schedule a phone call, and provide the password verbally over the phone.

The actual handoff algorithm:

At meeting: start with PROD

  1. Direct user receiving account to visit yale.service-now.com/side_door.do
  2. login in with username, and temporary password
  3. 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
  4. 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.
  5. Direct user receiving account to visit yalepreproduction.service-now.com/side_door.do
  6. login in with username, and temporary password
  7. 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
  8. 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.
  9. Direct user receiving account to visit yaletest.service-now.com/side_door.do
  10. login in with username, and temporary password
  11. 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.
  12. Direct user receiving account to visit yaledevelopment.service-now.com/side_door.do
  13. login in with username, and temporary password
  14. You probably need to leave their DEV access.
  15. 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

For regular netid accounts, this is handled by Central Auth. A ServiceNow CAS ticket lasts no longer than 24 hours. When the netid users tries to login, they get bounced to the CAS authentication page. If the account is disabled, they will not receive a CAS ticket, and they are denied access to ServiceNow.

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.

Taking away a local non-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 a 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.