Preventing a user from modifying their Account Settings in the Outlook Live Address Book

I was talking to one of our great Outlook Live support engineers, Roman Maddox, recently, and he was telling me that a fairly common request we get from customers has to do with controlling what users can change about themselves in the Shared Address Book in Outlook Live.  We actually document this scenario as an example of Role Based Access Controls and Mailbox Plans quite extensively… but Roman kindly provided some more content for me to post.

The question often comes up around what needs to be done to prevent a student from modifying their Account settings, yet still allowing an Alumni to modify theirs. Since moving to the current release in the Outlook.com datacenter, new PowerShell cmdlets have become available that facilitate the creation of security groups, with which a Tenant administrator can put together a new RBAC role, customize the cmdlets available to the role, and then create a new Role assignment that uses the security group to specify which users are able to perform certain tasks.

Previously in the datacenter, it was only possible to prevent a student from changing account settings by denying them access to the Control Panel (ECP) UI element that handles editing the properties.

Before

After 🙂

In the current release, however, it is possible to deny access to individual properties in the UI element in ECP.  The details are found in http://help.outlook.com/en-us/140/dd335876.aspx.

Specific Example Steps for creating the roles/assignments/security groups to accomplish your task:

In this case, there are two groups of students that have differing requirements. Accordingly, we will need to create two security groups:

New-DistributionGroup <NameforNoChangeGroup> -type: security

New-DistributionGroup <NameforChangeGroup>  -type: security

Groups of -type:security MUST be created via Remote PowerShell (RPS) at this point.  There is no way to modify an existing group to be a security group.  To use Remote Powershell, refer to the following article http://help.outlook.com/en-us/140/cc546278.aspx.

Once the groups are created, we can modify their membership from the ECP – the new groups will show up in the list of groups the TA can manage.  You can also use a CSV file according to the following posting http://liveatedu.spaces.live.com/blog/cns!C76EAE4D4A509FBD!885.entry to bulk add users to a security group.

Now that we have the security context for the role assignments, we need to create/customize the roles for the cmdlets we want the users to be able to use.  We will need one customized role for the group we want to prevent from changing their account settings, while we can still use the existing role for the other group.

To see what roles are available, run Get-Management Role | ft name

To impact Account settings, either MyOptions_DefaultMailboxPlan or MyOptions_GalDisabledMailboxPlan should be used as the Parent role.  For info on Mailbox plans, refer to articles http://help.outlook.com/en-us/140/dd229067.aspx and http://help.outlook.com/en-us/140/dd335876.aspx.

For example purposes, we will use the Default Mailbox plan:

New-ManagementRole -Name <your role name here> –Parent <YourDomainNameHere>\myoptions_defaultmailboxplan

Example:

New-ManagementRole -Name limitedmyoptions_defaultmailboxplan -Parent mydomain.com\myoptions_defaultmailboxplan

Once you have created the new role, we need to remove cmdlets/parameters from it.  In this scenario, we can either deny the students the ability to edit any of their account settings, or individual parameters (Note that when running the cmdlets, you may be prompted to confirm the action):

Remove-ManagementRoleEntry limitedmyoptions_defaultmailboxplan\Set-User   

The preceding will prevent editing any of the parameters, or, we can deny the ability to edit individual parameters:

Set-ManagementRoleEntry limitedmyoptions_defaultmailboxplan\Set-User -Parameters <parameter> -RemoveParameter

Set-ManagementRoleEntry limitedmyoptions_defaultmailboxplan\Set-User -Parameters WorkPhone –RemoveParameter

For account settings, the following parameters can be modified, unless they are required/special fields. We found that a required field can’t be removed, but the cmdlet won’t tell you this…

We can remove one or several parameters, depending on the desired effect.

Once this is done, we need to then remove the existing management role assignment so that we can replace it with the custom role/assignment:

First, run “Get-ManagementRoleAssignment | ft name,role” to find the name of the role assignment to be removed, which should be in the form of “MyOptions-MailboxPlan-DefaultMailboxPlanxxxx…..”

Next run Remove-ManagementRoleAssignment <your default role assignment name here>

At this point, we can create the new role assignment which should make the changes effective for the users:

New-ManagementRoleAssignment -Name <RoleAssignmentName> -Role <limited role created for this scenario> -user <your domain name>\<Security group created for limited users>

Example

New-ManagementRoleAssignment -Name limitedmyoptions-DefaultMailboxPlan -Role limitedmyoptions_defaultmailboxplan -user cloudywithachanceofehlo.info\NochangeGrp4Myoptions

We should now be able to log in with a user account that has been assigned to the “<NameforNoChangeGroup>” security group, and note that the user is neither able to edit any of their account settings, nor they will see the removed parameters.

There are fewer steps for getting the alumni setup:

New-ManagementRoleAssignment -Name <memorable name> -Role MyOptions_DefaultMailboxPlan -user <your domain>\“<NameforNoChangeGroup>”

Essentially, we are assigning the existing role to the security group we created earlier for students who will be able to modify their own account information.

Summary

We have created two email enabled security groups, one new management role that we subsequently customized by either removing the Set-User cmdlet, or individual parameters of the Set-User cmdlet, and two management role assignments that allow us to apply a different ECP experience to differing groups of students.

I would encourage the practice of copying all the cmdlet syntax into Notepad or the equivalent to make sure the group, role, role assignment names, etc. are how they need to be before running through the steps.  I would also encourage copying the name/syntax used for any role assignment/role entry modified or removed, so that if later the need arises to revert them back, this should hopefully make that process quicker.  I would also advocate testing this with a limited number of accounts before rolling it out more broadly – we found in testing that there was in certain instances a time lag between running the cmdlet, and the corresponding UI changes showing up.

This should get you started, and we plan to have additional postings on related RBAC topics soon.

-Roman

Advertisements

2 Responses to Preventing a user from modifying their Account Settings in the Outlook Live Address Book

  1. Deryck says:

    This doesnt seem right to me. The link "In the current release, however, it is possible to deny access to individual properties in the UI element in ECP. The details are found in http://help.outlook.com/en-us/140/dd335876.aspx.&quot; explains how to HIDE the fields, in the same way your blog explains how to HIDE the fields. This blog goes through the same process as that link, basically removing the field from the Set-User parameter (e.g. …\\Set-User -Parameters DisplayName -RemoveParameter). That doesn\’t make it appear but also make it unmodifiable, it makes it disappear completely. "and note that either the user is unable to edit any of their account settings, or they will not see the removed parameters. "How is there an \’or\’ there? I may be wrong, Im just a little confused by the blog… "NochangeGrp4Myoptions", “<NameforNoChangeGroup>”I\’ve successfully removed the fields from the UI, but I dont see how you achieved the BEFORE and AFTER images. Thanks, Neal

  2. US LiveAtedu says:

    HI Deryck,I just realized that the before and after shots are the wrong way round… oops… fixed that now.When you remove cmdlets from a mailbox plan, users that have that plan applying to them will see that the UI changes to reflect what they are able to do… in other words, it does not waste time showing them attributes that they can no longer modify. You can remove entire cmdlets, or remove specific attributes that a cmdlet can work with…. and either/or should be a neither/nor. I did not proof read what Roman sent me…What are you trying to achieve precisely here? Simply prevent the end user from modifying all properties?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: