Prevent sub-account admins from acting as specific user (top-level admin)

[michael5]

Hello

I'm having a bit of a security issue. I just reviewed our different account and sub-account roles and permissions and in our instance, it appears we have teachers who are able to Act as (ie. masquerade as) a top-level admin.

In our instance, I'm the only top-level account admin. Teachers are regular (preset) account admins for specific sub-accounts. The reason they can Act as me is because I've added myself as account admin to every sub-account for easy access - basically, so I can click Admin on the left-menu and select the sub-account I need to work with. If I remove myself as administrator from every sub-account, the teachers in question lose their permission to act as me.

So it appears account admins can as other account admins, and once they do, they can access anything within the given account they are acting as exactly as if they were actually signed in as me, never mind whatever privileges the masquerading user originally had. Even if I don't believe any of our teachers would abuse this, it's still a massive security issue (on our instance, not in general). 

So, what I'm trying to achieve is the following: Make it impossible for any user anywhere in the entire system to act as me specifically without having to remove my own account as admin from every sub-account. Is there any built-in way to achieve this or some kind of best practice that I didn't get the memo about?

I can't revoke the "Act as" permission from the teachers because it's such a great feature that actually enables them to solve a lot of problems on their own.

I realise the easy solution would be to remove myself from every sub-account and maybe bookmark the different accounts for easy access, or I could make two different accounts, one for top-level administration and one for sub-account maintenance work. But I'm thinking there must be an easier way.

[adam_c_voyton]

I’d recommend revoking teacher’s access to act as account roles with higher permission. Unless an account role has the same permissions or higher, they shouldn’t even be able to masquerade as an account admin with greater access/permissions. You may want to review permissions and do more testing, or simply remove yourself from the sub-accounts and install this Chrome extension to have easier access to sub-accounts you’re not added directly to: https://chrome.google.com/webstore/detail/canvas-lms-mods-basic/bnpdolbpbjiniodlbahddbnkollgojon

Definitely a security concern, I hope you get it all sorted out. 

[michael5]

In the end I added our top-level teachers as administrators for the root account but revoked the "Act as" permission (along with many other). This gives them access to searching for courses and students across our entire instance which is what I needed to retain. Having done this, they were still able to mask as me.

Then I removed myself as administrator from every sub-account in our instance where the teachers are also admins and able to mask, and then, they lost the ability to mask as me. So the only way to achieve it is to make sure that the account you're trying to protect from being masked as is not present on any account along sub-account admins that have the right to "Act as".

If I needed to maintain myself as sub-account admin as well as top-level admin, I think the easiest solution would be to make a separate admin account and revoke my own rights to mask as from the top-level.

I just wish there was a way to block any "acting as" any user who appear as an admin of any account at all.

[adam_c_voyton]

It sounds like you've taken some thoughtful steps to address the issue. Ensuring that top-level teachers have the necessary access without compromising security is indeed a delicate balance.

Your suggestion of creating separate sub-accounts and carefully assigning permissions to top-level teachers as sub-admins seems like a strategic move. It adds an extra layer of control and minimizes the risk of unauthorized access or masking.

Your decision to limit the number of account roles with "Act As" permission is also a prudent measure, as it helps to restrict the scope of individuals who can potentially assume the identity of others.

Overall, your approach demonstrates a proactive stance toward security and access control in your Canvas instance. It's a good practice to regularly review and fine-tune these settings to ensure the integrity of user roles and permissions.

If the option to block "acting as" any user with admin privileges in any account at all is not currently available, you might consider providing feedback to the Canvas support team. They may take user feedback into account when developing future updates or features.

[JamesSekcienski]

@michael5 

I'm not sure how your account roles/permissions are fully designed, but it kind of sounds like you are assigning the teachers the same account role as you but they are only assigned it at certain sub-accounts.  This is concerning that they are able to act as you even if they don't have access to all the same areas as you so this should be submitted as a Canvas Support ticket as soon as possible to ensure it is investigated.

In the meantime, i would recommend making a custom account role that you assign to other users that always has less permissions than the Account Admin role in all sub-accounts.  As long as the account role you are assigned has more permissions than the account role that teachers are assigned, they shouldn't be able to act as you anymore.  You should then be able to keep your admin role in the sub-accounts too as long as their role in the sub-accounts has less permissions than your account.

[adam_c_voyton]

Well said, and I definitely agree with the idea of granting users with an account role with the minimum level of access or permissions they needed to perform their tasks, reducing the potential for security risks or unauthorized activities. This ensures that sub-admins should only have the access necessary for their roles and responsibilities.

[michael5]

Yes, correct - I need them to be full, normal admins with access to everything but only for the sub-accounts they manage.

I thought I had this figured out but it turns out it's more complicated than originally assumed and now I'm not sure it's possible at all. First off, two things cause a lot of confusion and false positives/negatives when testing:

1. Specifically with the "Act as" permission, it can take up to 20 minutes before changes to this permission are in effect in the instance.
2. When masking as another admin to test their permissions, you're not getting a real representation. If I mask as a sub-account admin I am able to "Act as" anyone, but if I actually sign in to their accounts, I am not.

So with that out of the way, I'm still very confused because today I received a message from a teacher who was now unable to "Act as" anyone at all. She is currently:

1. Root-level limited admin with access to viewing courses, students and SIS data.
   
   
2. Sub-account full admin (system standard admin) for the three sub-accounts she manages.

So basically, this means that you need full, system standard admin rights to be able to mask as anyone. Anything less removes the option completely, even if it's toggled on. This seems like a bug but I'm actually not sure - if you read the description of the "Act as" permission in the permissions page it says the following:

---

Users with this permission may be able to use the Act as feature to manage account settings, view and adjust grades, access user information, etc. This permissions also allows admins designated to a sub-account to access settings and information outside of their sub-account.

---

---

So maybe it's actually working as intended... I'm not sure, but it seems to be an all or nothing feature. Meaning that in order to mask as anyone, you need full, system-standard, root level administrative rights.

It's just kinda misleading that I can even toggle "Act as" on and off if that's the case. And I still don't understand why a full, normal admin can "Act as" but a limited admin on the root level with "Act as" enabled can't.

Can anyone confirm/disprove this? At this point it seems I'll have to make a choice between security and usability which is an organizational conflict I was hoping to avoid. 😞