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

DrewW · ‎04-15-2020

I'm a little confused on what you are trying to say. Are you saying that each user is only in one group and you used a reference field on the user table to set the value and then use that to set group membership?

If you are just trying to delete users from a group when they are deleted then just go to the sys_user_grmember table and change the "Reference cascade rule" field to Cascade and it will auto delete the records when the user is deleted.

DrewW · ‎04-15-2020

As a side note deleting users from ServiceNow is going to clear out fields in the task table so you will not know who the caller was for instance on the incident record.

MGanon · ‎04-15-2020

Thank you for the discussion points. We do not delete users once created.

Here is my mental status on my original questions to hopefully clarify somewhat:
• Should the import be designed to handle the user association and group combination during the import?
     ◦ I think the best performance would be to use the OOB addMembers and addGroups functions in onAfter scripts only to manage the associations knowns to AD
     ◦ Business rules seem the best most effecient to add the user/group associations not directly stored in AD (adding standard users to the elvated user groups)
     ◦ Works well in the UI, not at all in the import

• Should business rules handle the user association and group combination after the import?
     ◦ I would like to run business rules from the sys_user_grmember table since each association is a single record
     ◦ The idea is a business rule on the sys_user_grmember table can track each user/group association for the elevated users by duplicating the sys_user_grmember to associate the standard user
     ◦ Works well in the UI, not at all in the import
     ◦ Investigating onForeignInsert transform action but I can't get the user or group imports to trigger the sys_user_grmember business rules!
     ◦ Any other ideas?

• What are the best methods to store the association of standard and elevated users?
◦ I think that a custom field (u_parent, u_stnduser, ?) added to the sys_user table seems to be most efficient
◦ Maintain 1-to-many relationship of standard user to elevated users, if elevated users exist

• Is inactivating elevated users in ServiceNow that are active in AD the best method to hide elevated users from view?
     ◦ Good: Inactivating elevated users removes them from user view
     ◦ Bad: Inactivating elevated users prohibits ServiceNow from distinguishing the active/inactive status in AD
     ◦ I am leaning towards other mechanisms to hide the elevated users from standard user view

MGanon · ‎04-15-2020

I found what I think is a bug that causes the import to ignore the sys_user_grmember business rules: the groups involved need a role.

https://community.servicenow.com/community?id=community_question&sys_id=09305be5dbdcdbc01dcaf3231f9619a0

I guess the last open question is the best way to hide the elevated users from view without setting their active status to false.

DrewW · ‎04-16-2020

Some options

- Set the refqual on the reference field(s) to filter them out.

- Create a query business rule so that you have to have role X to see them, similar to the existing query BR for inactive users and admins.

- Something that I did not think of off the top of my head.