Sharing Non-Default Outlook Folders in Exchange (Online and On-Premise)

A client came to me one day and asked how he can share his Outlook folder to his executive assistant so that he can have read only access to one folder and its subfolders. Didn’t think it was really that difficult of a task until he showed me his Outlook folder structure. This user literally had over 1,500 folders in Outlook and the hierarchy was intense!

SNAG-0050

The user did not want to share the full mailbox so assigning full mailbox access was out of the question. He only wanted to share the “2011-2015” folder and all the subfolders under it, which itself was a series of at least 50 folders.

One way to do this is to go to each folder, right click and open properties. On the permissions tab, assign the executive assistant Reviewer rights – NOT GOING TO HAPPEN! Too many chances of error and takes too long.

Assigning Permissions to Outlook Folders

After researching online, I came across a blog (https://blogs.technet.microsoft.com/tips_from_the_inside/2011/11/03/set-outlook-folder-permissions-using-powershell/) that had a script doing this same thing. I have attached a copy of this and customized it for this example.

  • The user who wants to share the folder is called BWayne@thebatcave.com
  • His executive assistant is called Alfred@thebatcave.com
  • The folder we want to share is only the 2011-2015 with its subfolders

 

ForEach($f in (Get-MailboxFolderStatistics BWayne@thebatcave.com | where {$_.Folderpath.contains(“/Investments/2011-2015”) -eq $true} ) )
{
 $fname = “BWayne@thebatcave.com:” + $f.FolderPath.Replace(“/”,”\”);
 Add-MailboxFolderPermission $fname -User Alfred@thebatcave.com -AccessRights Reviewer
 Write-Host $fname
 Start-Sleep -Milliseconds 1000
}

Accessing Non-Default Outlook Shared Folders

Now that the permissions have been assigned how can Alfred access these shared folders. In order to do this, Alfred needs to be able to see the folder structure. These next steps must be performed from Outlook – you can either use Bruce Wayne’s machine or being the administrator, give yourself full access to his mailbox and open it in your Outlook

  1. In Outlook, right click the mailbox name and select Data File Properties.
  2. Click the Permissions tab.
  3. Click the Add button to select Alfred from the address list
  4. Select Folder Visible and click OK

    SNAG-0051
    Note: Permission for Alfred is still set to “None”
  5. Go down to the next folder in the hierarchy and open its Properties
  6. Repeat steps 2 to 4. This needs to be done for every folder Alfred needs to traverse through to get to the shared folder. In this example this would be:
    • BWayne@thebatcave.com mailbox \Real Estate\Investments
    • It must be noted that the Folder Visible permission only allows Alfred to view the folder but not its content.

Now that Alfred has been assigned the permission to view the folders (but not their content) he needs to get into the shared folder, he can open them using Outlook.

  1. On Alfred’s Outlook, open the properties of his account settings. Click on the File menu (in Outlook 2013 and 2016), Account Settings\Account Settings    
  2. On the Account Settings window, click Change SNAG-0053
  3. On the Server Settings page, click More Settings   SNAG-0054
  4. Go to the Advanced tab and click the Add button to add BWayne’s mailbox to Alfred’s Outlook. Note that Alfred will not be able to see the entire mailbox – only the folders that have been set to Folder Visible and the ones he has reviewer permissions to.
  5. After adding the mailbox as an additional mailbox, make sure to uncheck the Download Shared Folders  checkbox.              SNAG-0056
  6. Click OK and Next to close the windows.

 

 

Advertisements

Limiting Access to Office 365 Services

A client was looking to limit access to mailboxes from outside the corporate network in order to improve data security. Because Outlook can cache mailbox information on a local machine, they would like their users to be able to connect to Outlook only from corporate machines. These are the requirements:

  • Outlook users can only use corporate laptops to connect as long as they establish a VPN tunnel to the corporate network
  • OWA can be used from any machine without restrictions
  • ActiveSync can be used from any device but the device must be approved by an administrator

Active Directory Federation Services (AD FS) 2.0 provides a way to configure these types of policies. Office 365 customers using Single Sign-On (SSO) who require these policies can now use client access policy rules to restrict access based on the location of the computer or device that is making the request.

To enable client access policy, you must complete the following steps:

Step 1: Install the Update Rollup 2 for AD FS 2.0 package on your AD FS servers

Download the Update Rollup 2 for Active Directory Federation Services (AD FS) 2.0 package and install it on all federation server and federation server proxies. The package can be downloaded from http://support.microsoft.com/kb/2681584

Step 2: Add five claim rules to the Active Directory Claims Provider trust

After the Update Rollup 2 for Active Directory Federation Services (AD FS) 2.0 package has been installed on all federation servers and federation server proxies, and the AD FS Windows service has been restarted, use the following procedure to add a set of claim rules that make the new claim types available to the policy engine.

In this step, you will have to add five acceptance transform rules for each of the new request context claim types using the following procedure.

On the Active Directory claims provider trust, create a new acceptance transform rule to pass through each of the new request context claim types.

  1. Click Start, point to Programs, point to Administrative Tools, and then click AD FS 2.0 Management
  2. In the console tree, under AD FS 2.0\Trust Relationships, click Claims Provider Trusts, right-click Active Directory, and then click Edit Claim Rules
  3. In the Edit Claim Rules dialog box, select the Acceptance Transform Rules tab, and then click Add Rule to start the Rule wizard
  4. On the Select Rule Template page, under Claim rule template, select Pass Through or Filter an Incoming Claim from the list, and then click Next
  5. On the Configure Rule page, under Claim rule name, type the display name for this rule; in Incoming claim type, type the following claim type URL, and then select Pass through all claim values
  6. To verify the rule, select it in the list and click Edit Rule, then click View Rule Language. The claim rule language should appear as follows:
  7. c:[Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip”%5D => issue(claim = c);
  8. Click Finish
  9. In the Edit Claim Rules dialog box, click OK to save the rules

 

  1. Repeat steps 2 through 6 to create an additional claim rule for each of the following claim types shown below until all five rules have been created.
Rule Name Issued Claim
EQ-Forwarded-client-ip http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip
EQ-client-application http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application
EQ-client-user-agent http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent
EQ-Proxy http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy
EQ-endpoint-absolute-path http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path

Step 3: Update the Microsoft Office 365 Identity Platform relying party trust

This step allows you to configure what type of clients to block. At Equitable, we have created a custom block scenario – Block all external access to Office 365, except Exchange ActiveSync and browser-based applications such as Outlook Web Access or SharePoint Online.

Below is the claim rule we configured for this scenario:

exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”%5D) &&

NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”, Value==”Microsoft.Exchange.Autodiscover”]) &&

NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”, Value==”Microsoft.Exchange.ActiveSync”]) &&

NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”, Value == “/adfs/ls/”])

NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip”, Value=~”\b123\.123\.123\.1\b|\b134\.134\.134\.2\b”]) &&

=> issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

Once configured, the ADFS services were restarted and confirmed through testing to be accurate. This change only needed to be done on the first ADFS server installed in the farm as it holds the master copy of the Windows Internal Database (WID).