How it works

People in your organization log into the organization’s computers or wireless network by using a user account set up for them by IT when they joined the organization .

Every employee has a user profile in the organization’s directory servers and whenever a user attempts to log into the corporate Wi-Fi their device connects to those directory users to verify that the input credentials match those stored in the directory servers. If they do, access to the network is granted.

The LDAP integration with ServiceNow enables ServiceNow to check with your directory servers whether to let in people into ServiceNow or not. So when an employee attempts to log into ServiceNow, ServiceNow connects to your directory servers and verifies if the input credentials are correct. If so, the user is granted access to ServiceNow.

ServiceNow could also import from your directory servers the user profiles of your employees including details such as email address, location, department, and full names. It could also import group membership details, to know to which user groups the employee belongs.

So besides authentication at the time of login ServiceNow also regularly connects to your directory servers and imports new user profiles into ServiceNow and updates existing ones.

A good thing about the LDAP integration in ServiceNow is that it is only one way, from your directory servers to ServiceNow. That is, ServiceNow will only read user profiles from your LDAP servers but will never create or overwrite data in there. This guarantees the integrity of users’ data in directory servers .

Unique ID

When setting up the integration you will need to decide how to uniquely identify users. That is based on which unique field ServiceNow should use to create a new user profile, or update an existing one.

By default, ServiceNow will identify users by their username (samaccountname in Active Directory), but if your LDAP servers host users from multiple domains (e.g., @aljazeera.com and @subsidiary.org) or if your organization later changes the format of usernames, for example from firstname.lastname to lastname+ initials, or if you change your primary email domain, then the mechanism will fail.

In such scenarios users may be duplicated in ServiceNow while tickets will remain associated with the account with the old email address.

If this applies to you, you should be careful not to use the email address or username to identify and match user profiles; Instead match profiles based on a unique and immutable field ID in your LDAP server (e.g., the objectSID).

End users don’t need to know about this, it’s just something to be set up behind the scenes for the integration to work smoothly.

Security

ServiceNow describes the read-only LDAP integration as secure because it connects “from a single machine that uses a fixed IP address through a specific port on the firewall.”¹

But if you would rather use LDAPS (secure LDAP), you can also do that by uploading a public certificate to be used by ServiceNow for encrypting messages to your directory server.

Alternatively, you can set up a VPN between ServiceNow and your network so that traffic between the two ends is secured by the VPN. At Al Jazeera we use VPN.

As soon as an account is disabled in Active Directory that user will no longer be able to log into ServiceNow. This is because every login attempt in ServiceNow is verified against Active Directory and if the AD servers reply to ServiceNow that the user is disabled the login will not go through.

The disabled user will continue to be sent emails from ServiceNow but they will probably not be received because the mailbox will be disabled or inaccessible .

Performance

Performance can be an issue for large organizations with thousands of users.

To mitigate the performance impact of scheduled synchronizations between directory servers and ServiceNow, ServiceNow recommends that you schedule the sync once daily and outside peak hours.

Syncing only once a day means that updates to user details will not take effect until the sync occurs the next day, unless the individual user profile is individually refreshed from ServiceNow on an on-demand basis.

ServiceNow technical online documentation also lists other optimizations recommendations (such as paging) to speed up the synch .

Availability

In the event that your directory server is down, what do you do?

It won’t be possible for your users to log into ServiceNow but it probably would also be a bigger problem for the entire organization because they will be unable to access other critical systems that also rely on the directory, like email.

In any case, ServiceNow lets you specify a redundant LDAP server to check with in case the primary LDAP server is inaccessible and your organization has more than one LDAP server.

In the event that ServiceNow fails to connect with your directory servers, ServiceNow can also send an email notification to the users you specify in a group called LDAP Admins group (see Figure 3-4).

Figure 3-4. Out-of-box users group to be notified in case of LDAP connection issues.

You also want to make sure that there is a ServiceNow local administrator account that is not an LDAP user so that you may at least log into ServiceNow using that account to resolve the LDAP issues (e.g., update LDAP configuration settings in ServiceNow).

Groups sync

In addition to synchronizing user accounts you could also synchronize user groups .

Every team at your company will most likely have a user group in Active Directory and when new people join the organization they are added to the groups with which they need to collaborate with. Instead of recreating and maintaining those groups in ServiceNow you could have groups in ServiceNow synchronize with those in Active Directory.

There are many benefits for automatically importing groups in ServiceNow:

1. It eliminates the friction that results from having to recreate groups in ServiceNow and update them manually in ServiceNow.

2. It eliminates the need for managing group memberships in ServiceNow; It will be all done in Active Directory and automatically reflected in ServiceNow.

3. It makes it a lot easier to collaborate on tickets with other group and teams, whether they are on ServiceNow already or not (also see Chapter 10).

However, it may be that your directory has many other user groups that are meant for internal processes and that most people do not know about and do not email. Importing them in ServiceNow can make things a bit messier than ideal and it may be worth discussing with your directory administrators a solution to filter those groups out from the sync with ServiceNow.

Also, even more than usernames, the names and email IDs of groups tend to change more frequently (basically with every new manager). To avoid duplicating groups in ServiceNow with old and new names, group profiles in Active Directory have a unique immutable ID (objectSID) that you can use to unequivocally identify groups for your Active Directory sync with ServiceNow .

Location OUs

How do you determine the location of the user?

Directory servers often provide a field to store the location and address but this is seldom accurate, standardized, or even uniformly populated for all users.

However, in many directory servers users tend to be segregated in so called Organizational Units and those OUs normally represent a location, or department.

For example a user profile may be contained in all of IT, Doha, and AwesomeOrg OUs.

Other users will belong to different OUs but all users located in Doha, Qatar will also belong to the Doha OU. Users in New York Manhattan will be in the NYM OU, and so on. Also no user can belong to two geographic OUs.

So in ServiceNow, you can create locations that match the OUs so that they are updated directly from LDAP .

Single Sign-On

Single Sign-On in ServiceNow is one of the steps listed in the ITSM Guided Setup with built-in support in ServiceNow.

Single Sign-On basically means that people at your organization will need to authenticate only once to use your organization’s networks and applications, and that they will do this through one single login screen unified across all applications in your organization.

In other words, users wanting to access ServiceNow will not have to log in because they have already authenticated with your corporate network.

Or if they have not, ServiceNow will redirect them to authenticate with your organization’s login screen, instead of ServiceNow’s. SSO eliminates the need to log in with corporate applications, and allows for a more seamless user experience.

As with the LDAP integration, configuring ServiceNow with SSO is not a configuration on ServiceNow’s end only but requires support from your system and network teams.

At Al Jazeera, we had an implementation of SSO that was incompatible with ServiceNow and it took considerable setup (and more than two years) before we got one that worked with ServiceNow .

Basic access levels

Table 3-1 shows the five key access roles in ServiceNow.

The ITIL role is the access level intended for people expected to manage tickets in ServiceNow. Anyone with it can view any ticket in ServiceNow.

There is no such thing as confidentiality in ServiceNow out-of-box (see Chapter 9 for alternatives); Anyone with ITIL access can view and participate on any ticket in ServiceNow.

The user_admin role instead may be conferred to your Servicedesk team to manage users and groups in ServiceNow, while the admin role (capable of deleting all records) should be granted very restrictively.

A personal story illustrates how harmful the admin role can be on a production environment:

One day, I accidentally deleted my home page in ServiceNow. Normally when an itil user deletes his home page it only affects his view in ServiceNow and ServiceNow will automatically set for him the default home page for itil users.

But when I did it as an admin, I had accidentally deleted the home page for all itil users! And I got called on the issue within five seconds of it occurring. The Servicedesk group were no longer able to view their tickets queue.

Fortunately I was able to restore the home page within minutes by copying from another non-production instance where the same home page was configured (refer to Chapter 8 for advice on managing your ServiceNow environments), but you get the point!

Using ServiceNow with the admin role is risky and can wreak havoc for all users. An admin user that doesn’t need the role in his day-to-day activity may be better off having a separate dedicated admin account to be used on a need basis only.

Managing licenses

How licenses are counted may depend on your particular contract with ServiceNow, so you need to verify the information provided here against your actual contract with ServiceNow.

Service Now does not charge you a license for your callers (those users that your Servicedesk supports). Callers can have a user account in ServiceNow and log in with it to view their own tickets.

Managers and supervisors who receive approval requests from ServiceNow require an approver license, if they are expected to approve (or reject) requests on their own.

A full fulfiller subscription is required for every member of your support teams such as those in the Servicedesk or in the Network team managing ticket queues on ServiceNow. A user assigned a fulfiller license (like itil or contract_admin, for example), could also have other roles assigned to them (e.g., report_admin) and still count as a single fulfiller license. They can also approve (or reject) requests without being counted as an “approver” license.

From a licenses management perspective this means that you need to be careful about:

1. The total number of users accounts in your ServiceNow instance;

2. The number of users to whom an access role is granted, either individually or through membership in a group;

3. Who from your end users you want to be able to approve requests “automatically,” and if those will count as an approver license.

“Automatically” is in quotes because even without assigning the approver_user role to an end-user, you could still send approval requests from ServiceNow. You could then collect the approval from the user by other means and have the support agent record the approval manually. To avoid this hassle, you need an approver license.

LDAP and licenses

Since there is no license fee for users without a role, having all of your organization as users in ServiceNow through LDAP will not increase your costs. It’s free.

You should however be careful with the user groups to which you assign roles. Unless each member of your department needs to log into ServiceNow and manage ticket queues, they should not be in a privileged group in ServiceNow. Only the people actively managing ticket queues warrant such a licensing expense.

If you sync group memberships with ServiceNow, you will have a bit of a problem here. If access roles are attached to groups and are assigned automatically through membership in the group then the access role will be shared with both active and inactive members of the group. You have a couple options to deal with the situation :

Bucket groups

Create bucket groups in ServiceNow and associate access roles to those buckets. Then add and remove members to grant and revoke from them access roles (and thus licenses).

For example, you can have a Support-people group that grants its members the ITIL role and for example the report_group role. You could also have another Support-supervisors group that grants some additional roles. As usage of the application evolves, you can create new bucket groups such as Automatic-approvers, Vendors, Asset-Custodians, etc.

In this manner you continue to have your official groups managed in LDAP but also control which access roles are granted to whom consistently in ServiceNow.

Routine scripts

Periodically run scripts that revoke access roles from inactive members regardless of what the access roles the group membership conferred to the user.

For each user in ServiceNow you can know when it was the last time that they logged into ServiceNow. It would be wise to regularly check for privileged users that have not logged in for a while and consider revoking their privileged access .

Prior to the Eureka release you were able to check on the number of licensed users in your instance. A Subscription Management application was introduced in later editions² but you may still have to check with your ServiceNow sales representative to perform an audit. You can however get an accurate prediction by listing all unique users with a not-empty access role.

To access this list in ServiceNow look up User Roles in the Navigator, filter out users with empty roles (or with just the snc_internal role) and then group the list by users to get a unique count of the users with a role (Figure 3-6).

Figure 3-6. Count of all users with the itil role assigned.

Vendors access

Your Servicedesk will undoubtedly be dealing with external vendors for certain issues. Which ticketing system will you use to track dealings that involve external vendors?

Many vendors like ServiceNow will have their own ticketing system and will expect you to log a ticket through it. But if you have sufficient leverage over your vendors or they themselves don’t use a ticketing system, you may get them to collaborate on tickets in your ServiceNow instance. This is what Dr. Matthias Egelhaaf from Siemens said they do with their vendors.³

Before giving vendors access to manage tickets in your instance consider if it would be enough for them to update tickets via email without actually being able to log into the instance with the ITIL role.

This is because if you give vendors the same access as other teams in your organization, they will by default be able to view and update any ticket in your instance, which could constitute a significant breach of confidentiality of your organization’s day-to-day internal affairs (more on confidentiality in Chapter 9).

If it’s enough for them to receive and update tickets in which they are mentioned then this is easily achievable in ServiceNow without granting your vendors any privileged role to your instance.

At its simplest, all you have to do is add their email address to the ticket watch list so that they receive notifications for the ticket and can update it by replying over email. They could also log in but as users without any role and so could only view the tickets in which they have been listed. The level of access that you give to your vendors depends on the support expectations that you have from them.

When you consult certain vendors about an issue, the responsibility for the ticket before your customer remains with the internal team that escalated the ticket. In such cases, the ticket should remain assigned to the team, which will be responsible to chase the vendor for support or find a solution through other means.

In such cases it would be sufficient if the vendor is white-listed to reply to updates via email (see Figure 3-7).

Figure 3-7. Property to list the email domains of your vendors from which you want to acccept emails in ServiceNow.

In other cases, the vendor is expected to take more responsibility for the escalated ticket and resolve it in a timely manner, directly updating the caller of the ticket (who for such issues may be from within the Technology department).

Such is normally the case with external development partners or outsource service providers who are almost considered an extension of the internal support organization. In those cases it makes sense to have the vendors as a support team to which tickets can be assigned.

In this case you need to give them more than end-user access but you should also restrict their access from seeing all tickets in your system. This is not supported by ServiceNow out-of-box and will have to be customized.

Alternatively, if you implement access on a need-to-know basis as described in Chapter 9 it will restrict access to other team’s tickets and so you could safely grant vendors the same access as other fulfiller teams in your organization .