Atul @Dr Atul G- LNG is correct - "impersonator" is embedded in "admin" OOB.
@NikhilEtikala Further, if you are asking about how a clone can produce different results in terms of user permissions, it likely has to do with table preservers in your clone profile. If there is a table preserver in your clone profile, it could be over-writing your user permissions. Also, it is not always easy to understand table preserver configuration, when it comes to user accounts/roles/permissions/access/groups - as there are 6 tables that you need to consider, which is not intuitive for a lot of folks:
sys_user
sys_user_group
sys_user_role
sys_user_grmember
sys_user_has_role <- likely that this one is the culprit, if your role assignment is off, but group membership is not...especially if the role assignment is not inherited.
sys_group_has_role <- also a possible cause for your problem...if the role assignment is incorrect, but the role is inherited (then, likely group membership is preserved and doesn't match production).
...if you want your subproduction instance to exactly match your production instance (in terms of group membership, users and role assignment), make sure that NONE of the tables listed above has a preserver in the clone profile that you use.
Further, if you are not preserving those tables, but still having issues with your role assignment, group membership or user base (not matching production, as expected)...it could be the case that a previous/other platform admin has set up a connection to an external source (such as a specific ldap user/group import for your subproduction environment).
