Best Practices for Combining Users from External Source

MGanon · ‎04-08-2020

Our external (LDAP/AD) user import source includes multiple types of user records. Every user has a standard user account, but some users also have separate accounts to specifically identify elevated rights. Each of these accounts can belong to different groups. Users can only access ServiceNow with the standard user account but that ServiceNow account needs to include groups from the standard users and any active elevated user account. Our AD source has a text field that allows us to associate the standard and elevated accounts during an import. This field is mostly accurate but requires some manual intervention in ServiceNow that we don't want the import to overwrite. If a standard user is inactivated in our AD source, then that users is inactivated in ServiceNow. When an elevated user is inactivated in AD, all groups associated to that elevated users must be automatically removed from the standard user that may still be active. If a user gets a new elevated account, then those groups must be added to the standard user. Because non-admin ServiceNow users (Service Portal, Fulfiller, etc.) must not be able to see the imported elevated accounts in ServiceNow, we import them as to inactive to hide them, but this prevents ServiceNow from knowing if the elevated user is active in AD. We first query the import table for to collect the groups for all of the known associated users then query AD directly if the associated users are not in the import table.

The import scripting grew over time and is no longer efficient.

I am looking some recommendations for an efficient import with these assumptions:

All users have a standard account in AD
Some users have 1 or more separate elevated accounts in AD
All user accounts are imported into ServiceNow
Only standard accounts can be available as caller, for assignment, etc.
Coalesce field must be sys_id to accommodate name changes
Imported standard users must include groups from all associated active AD accounts
Must be mechanism to manually associate imported elevated users with standard users
The mechanism exists to identify active/inactive user status in AD
- We created a variable "this.adstate" to identify and hold active, inactive, ignore
The mechanism exists to identify user records that should be ignore such as system user accounts

My main questions:

Should the import be designed to handle the user association and group combination during the import?
Should business rules handle the user association and group combination after the import?
What are the best methods to store the association of standard and elevated users?
- Custom field added to the sys_user table seems to be most efficient
- Custom parent/child relationship would be challenging because single child (standard user could inherit groups, and roles of those groups, from potentially multiple parents.
Is inactivating elevated users in ServiceNow that are active in AD the best method to hide elevated users from view?

DrewW · ‎04-08-2020

So some items

The coalesce field should be the AD GUID in my opinion, I find that the easiest way to deal with name changes and the only time you will have issues is if someone deletes the account in AD because that will cause the GUID to be different when they are recreated. You can do your first sync on samaccountname or simply user id but that is going to depend on your AD environment(s).

Add a field to the user table to indicate if a user is "Not Standard" and set the value during import.

Us the ""Not Standard" field to put a filter on the caller field or a query BR on the user table that filters them out if the user does not have role X, just like the BR for the admin role and inactive users that is already on the user table.

Make sure you mark the "Not Standard" users as locked out so they cannot login to ServiceNow. Unless you want them to.

Replicate the AD user account control from AD to get your disabled users. You can also use this to add attributes to the users for things like "Password never expires" which allows easy AD reporting for such things.

You have several options for attaching one user to another

Create an M2M table that links user with users
Create a List field that points to the user table and only fill it out for "Standard users"
Add a "Standard user" field to the user table and only show it when the "Not Standard" field is selected. This allows one account to be attached to only one other and I think is the best option. You can then add a related list to the user table that shows the "Not Standard" users associated with the account. You can then show the edit button to relate user manually.

You are going to have to replicate over all of the groups to either the sys_user_group table or a custom table and make sure you get there internal AD name. I forget the name of the attribute but its something like cn=GROUPNAME,ou=OUNAME,ou=OUNAME,ou=OUNAME,ou=domain or some such. You will need this because when you get the users group membership (which is an attribute on the user account in AD) the groups will be listed by there internal LDAP name so when you add them to the groups you can look the group up by this.

Combining groups with the "Not Standard" user maybe tricky because you have two+ lists coming in that could change at different times and have duplicate values, or a group is added to one account and removed from the other. You may want this to be the last thing that you update for the user but that is potentially going to cause you to do a lot of processing of group membership that is not needed because it has not changed. Ideal you only want it to process when it changes. One thought would be to tag the user accounts when there group membership changes using a business rule looking at the AD group membership field that you will have to create and then once a night go thru all of the users that are tagged and verify there group membership and untag them. This way you are not wasting time verifying group membership that has not changed and it will allow you to combine the group lists for the "Standard" and "Not Standard" for processing one time.

Using the Attribute field mentioned above, this will make reporting easier and then you can create an attribute called "System User" and add that when you decide that the user is a system user. I would hope that the AD admins have been putting all of these users in one OU but you will have to figure out how to sort them out based on the data you get from AD.

View solution in original post

MGanon · ‎04-09-2020

Has anyone ever had the requirement to combine users from an external source?

DrewW · ‎04-09-2020

When you say external source do you mean a AD domain that is part of a subsidiary but not your current AD forest? They yes I have done this.

MGanon · ‎04-14-2020

We cannot use the AD GUID directly because a person's record might be deleted due to inactivity then recreated later. Because it is the same person, the new record will have the same samaccountname but different AD GUID. We accommodate this through a script to identify the sys_id in ServiceNow. New records are created when no sys_id can be identified.

To maintain a collective list of groups, I added a u_parent field for the standard user, since there can be only 1 but undefined number of elevated users, then created business ruled triggered by the sys_user_grmember table to track new and deleted records when users/groups are associated/disassociated. This works great in the UI! except... Unfortunately, ServiceNow won't trigger the business rules for sys_user_grmember add/delete actions during the user or group import that generated the sys_user_grmember add/delete actions. Is it possible to trigger sys_user_grmember business rules during a user or group import?

DirkRedeker · ‎04-14-2020

Hi

I think you should change your habits to delete users and recreate them later.

That runs into the issues you described above. It is much better to keep them, but set to "inactive". This same is valid for reusing IDs, which will also run into trouble over the run.

a) Never recycle IDs

b) Never CHANGE someones / some Objects ID (which may/will/was used somewhere else)

Have you ever thought about using an integration of ServiceNow and your AD?

In that way, you can auto-provision users in ServiceNow (automatically create them).
Furthermore, you do not need to separately deactivate them in ServiceNow. As soon as the user cannot log in to AD anymore, ServiceNow will also NOT be accessible anymore.

Let me know.

BR

Dirk

MGanon · ‎04-15-2020

Hi Dirk,

The customer is aware if those recommendations. Unfortunately for too many reasons to list, those options will not be possible, at least in the required timeframe. I am looking for the technical best practices to compensate for current processes that need revision and functionality not purchased.

Have you identified a method to trigger a business rule on a table that is related to a table that is updated through an import? I can pursue other options but I first want to exhaust this one.

Cheers