Feb 09 2018
11:39 AM
- last edited on
Jan 14 2022
05:26 PM
by
TechCommunityAP
Feb 09 2018
11:39 AM
- last edited on
Jan 14 2022
05:26 PM
by
TechCommunityAP
A customer recently pointed out that all users have permissions to use PowerShell (with added modules) to run Get-Msol
The problem is that they also can read the data stored in the authentication contact info-fields, used for self-service password reset among other things. This information should not at all be accessible for normal users accept their own stored data.
This customer is a college that also teaches IT-subjects. The staff will probably use private contact details (email, mobile number) for self-service password reset and such. You only need one savvy student to use freely available software to get a lot of private information of teachers.
Using Set-MsolCompanySettings -UsersPermissionToReadOtherUsersEnabled has the effect that users cannot read any profile details, including in Delve and such. If they are a Office 365 Group administrator they also cannot add other users to become a member of this Group.
The question I have: does anybody know of a way to prohibit users to read the authentication contact info of other users, but still be able to read the other profile information? Or a way to prohibit normal users to use PowerShell or other such tools to get all user profile information?
Feb 10 2018 09:13 AM
That's the only option you have. The argument usually goes something like "well you can see all this info in on-premises AD too". And there aren't that many regular users that will try PowerShell anyway, the bigger issue here is some rogue user running scripts to collect this information, etc.
Feb 11 2018 08:55 AM
@VasilMichev, I was afraid that would be the answer. Because that is the way it worked in AD on prem most schools I know had 2 AD's: one for students and one for staff. So students were never able to get the data from the staff AD. In Office 365 they need to be in the same Azure AD.
Feb 11 2018 09:12 AM
Feb 11 2018 09:38 AM
No, it's an org-wide setting. Until we get a proper RBAC support for AAD, that's your only option (and even when/if we do, I'm not sure it will cover "read" permissions).