Allow only the Entra integration user to update the read-only Manager field

[Priya Singh 2 2]

Currently, the Manager field on the User [sys_user] table is maintained by an external source and is configured as read-only. As part of the Entra integration enhancement, this field needs to be populated during user creation rather than waiting for a subsequent update process.

The challenge is that write access needs to be granted exclusively to the Entra integration account for updating the Manager field during user creation. Even though the integration account has the admin role, the requirement is to prevent all other users, including administrators, from modifying this field manually while still allowing the Entra integration to update it. The current access controls are not enforcing this distinction as expected and require further evaluation.

[Hanna_G]

Hi  @Priya Singh 2 2 

Admin users will override any of the ACL's that you put upon the global records - you may have to handle this through process with the admin users, as opposed to adding unnecessary complexity through scripting. 

To investigate why other users can do this and which ACLs are allowing this then @Sagar Pagar has done an excellent article on how to debug ACLs: How to Debug the ACLs Like a Pro developer in Serv... - ServiceNow Community

This should help you work out what you need to change. You could consider creating a role for the Entra integration account and adding that onto the Manager field and create an ACL for must have this role. But you'll need to understand the other ACLs that manage the access there. 

[Vikram Reddy]

Hi @Priya Singh 2 2,

First thing to check: whatever is currently making Manager read-only. If it's the dictionary-level Read only attribute on the field (rather than an ACL), that flag blocks writes for every identity, including your integration account, and it blocks them through the Table API and GlideRecord too, not just the form. You can't leave that checked and expect a scoped ACL to punch a hole through it for one user, it has to come off first.

With that off, the restriction needs to live entirely in a scripted write ACL on sys_user.manager, keyed to identity instead of role, something like:

answer = (gs.getUserID() == gs.getProperty('entra.integration_user_sysid'));

Stash the integration account's sys_id in a system property rather than hardcoding it in the script, saves you a hunt later if that account ever gets recreated.

Now the part that's probably the actual reason your current controls "aren't enforcing this as expected": ACL evaluation across multiple applicable rules is OR logic. Even with a scripted ACL and Admin overrides unchecked on it, if there's another Write ACL on that same field, or a broader sys_user.* Write ACL, that has Admin overrides checked, an admin still gets through because that other rule passes. Unchecking the box on your new ACL alone doesn't cut it if a more permissive one is sitting next to it.

• Field ACL: check whether a sys_user.manager Write ACL already exists with Admin overrides checked
• Table ACL: check the sys_user.* Write ACL for the same setting, it can silently grant access your new field ACL was meant to block
• Debug it: use System Diagnostics > Session Debug > Debug Security (or the glide.security.debug property) while impersonating an admin, it lists every ACL that fired and whether it passed or failed instead of you guessing

Once those competing ACLs are tightened up alongside your new one, the write should stay locked to the integration user and everyone else, admin included, gets denied.

Thank you,
Vikram Karety
Octigo Solutions INC

[mohammedafi]

Hi @Priya Singh 2 2 ,

You can create a "deny unless" ACL that will allow only the integration user to write on the Manager field, and make sure the Admin overrides checkbox is unchecked — this will not allow admins to bypass this ACL.

Thanks,
Mohammed Afif

[Tanushree Maiti]

Hi @Priya Singh 2 2 

Create a field-level Write ACL that explicitly grants permission only to your Entra integration user.

• Navigate to System Security > Access Control (ACL).
• Type: record
• Operation: write
• Name: sys_user
• Field: Manager
• Under the Requires role list, select admin (assuming your Entra account operates with the admin role).
• In the Script section,

answer = gs.getUserID() == '<sys_id_of_entra_integration_user>';