Impersonation

[sunny091213]

do  you think Impersonation is an security issue? if yes give me reasons?if not support it?

[Harish Bainsla]

Hi @sunny091213 

In ServiceNow, "impersonation" can be considered a potential security issue because it allows administrators to temporarily log in as another user, which could lead to unauthorized access to sensitive data if not properly managed and monitored, potentially enabling them to bypass access controls and view information they wouldn't normally have access to. 

Key points about impersonation in ServiceNow:

• Functionality:

Impersonation is a feature that allows administrators to temporarily assume the identity of another user within the system, which is useful for troubleshooting and testing user experiences. 

• Potential Risk:

While intended for legitimate use, if not properly controlled, it could enable malicious actors to access sensitive data by impersonating other users with higher permissions. 

• Mitigating factors:
  • Access control: Restricting who can use the impersonation feature and ensuring only authorized administrators have access. 
  •        Logging and auditing: Actively monitoring and logging all impersonation activities to identify suspicious behavior. 
  • Application-specific restrictions: Implementing security settings within specific applications to limit what data can be accessed while impersonating a user. 

 if my response helps you mark helpful and accept solutions 

[sunny091213]

Nice Info.
but Logging and auditing -> to access the logs of a organization   you should have the admin role.
Consider this situation:if a organization has two admins and one impersonated other admin and changed his password and he forgots his password then what happen there is no prove or logs that proves that person changed passwords and he is the cause of that situation then how to solve that kind of situation? 

[Ankur Bawiskar]

@sunny091213 

I agree with Atul here.

It should be given only in DEV and UAT only for testing purposes.

If my response helped please mark it correct and close the thread so that it benefits future readers.

[sunny091213]

Consider this situation:if a organization has two admins and one impersonated other admin and changed his password and he forgots his password then what happen there is no prove or logs that proves that person changed passwords and he is the cause of that situation then how to solve that kind of situation? 

[jeffreyluto]

I tested in my sub-prod when I logged in as test user since I am an admin it shows when I started impersonation and when I ended it.  If the property was created and set to false  "glide.sys_log_impersonation" then I think it would not gather that info.

In regard to the above question: as most ServiceNow instances are in the Cloud call the ServiceNow or create a ticket and they would ask you to prove your identity and they would login as Maint user or tech user and reset both admin users' passwords.  In on-premises situation that can happen too as Maint somehow has a backdoor for limited time logins to on-premises when they use their special creation keys.

The more pressing problem would be on-premises ServiceNow were say both AD, LDAP, Windows or Linux administrators are locked out.  And thus, cannot unlock the ServiceNow admin's account to Linux or Windows to administrator the self-hosted software.  So maybe the portal or front end is not locked out, but the backend of the server is without assess to upgrade, patch or hotfix for security reasons.