Best Practices for Combining Users from External Source

[MGanon]

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 · Accepted solution]

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

1. Create an M2M table that links user with users
2. Create a List field that points to the user table and only fill it out for "Standard users"
3. 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.

[MGanon]

For the three options that you listed to associate users:

• I think that an M2M table would cause another performance impact because I want only a 1 standard-to-many elevated relationship
• I have avoided using lists because they are difficult to query
• I think the most efficient might be creating a parent/child relationship
• • Create a custom field relating the sys_user table to itself
  • Treating the elevated accounts as the child records

We don't have the option to add attributes to AD, only to populate the attributes that already exist.

[DrewW]

I was referring to adding an attributes field to the user table in ServiceNow.  None of what I suggested was intended to add anything to AD, just pull data from AD.

[MGanon]

Sorry for misunderstanding