If this is your first time using Add2Exchange or you are upgrading or migrating, post here.

5/12/2010 3:30:57 PM
Total Posts 53
Use the links in the footer below to keep up to date via our newsfeed or Facebook.

Reduced Permissions: Add2Exchange Enterprise 365 and Add2Outlook installations

Reduced Permissions for Add2Exchange Enterprise, Add2Outlook for Exchange 2007-2019, either on Prem, Hosted or O365. 

Many people want to add granular permissions instead of giving full permissions.  This is tighter security than giving the Sync Service account permissions to the stores with full mailbox access and no auto mapping.  This requirement may be necessary as part of compliance or for general enhanced security.  

The trouble with this approach is it isn’t as easy to make a relationship by adding a user to a Dist list and having the sync system make a new relationship and start syncing, as in the default permissions.  Removing relationships is easy, remove from the distribution list (or manually adding or removing relationships) by removing the user from the Dist list and wait 24 hours to hide the account from the GAL for automatic operation. 

This is a requirement, so which permissions can you modify and "ratchet down"?
First of all, the Sync Service account is a powerful account and its login and password should be highly guarded because of the permissions, no matter if you reduce the permissions.  If this account were configured in this way, the power it has is safe.  In fact, much of this power is required for it to do the job it does and there are some things we can’t get around.  Much of the power is for complete automation, so without it, there is a manual onboarding effort to consider.
Why does the Add2Exchange Service account need to be part of the AD “Built-in Administrators Group”?  It doesn’t anymore if you are using Outlook as the communication protocol, but it has to be a local administrator of the replication box it is on.  If it is an off the domain box, that is still ok, but that local account has to be part of local admins and be able to start services.   It also can be further refined, and may not have to be part of built in if you wish to further restrict.  But normally on the domain, the Sync Service account normally is part of the local administrators group of the machine it is installed on (to install software, run services).  UAC has to be off in the registry and the system rebooted before installation. 

If using Outlook as the communication protocol, the service account does not have to be part of the local Administrator's group of any exchange server it connects or that server replicates to anymore. This account needs no other permissions on the Exchange Server box, but has to have granular permissions to mailboxes and folders is syncs to or from.   
Legacy Installs: When syncing to Exchange 2003-2010 using CDO to communicate and not Outlook, and in some cases Exchange 2013, the service account had to be part of the local admins of the Exchange Server and point directly to one.  This was effective, but this was not fault tolerant.  In recent configurations, using Outlook for the autodiscover record allowed us to ratchet down those permissions and point the the Auto Discover record so it was fault tolerant and could also work well with Exchange 365.  

In prior releases of the manual, we suggested adding the a new security group to the top of the store so it makes it easy to add other relationships, but you don’t have to anymore.  For Exchange 2007 and 2010,  we have the script to add permissions to the top of the public folders and mailbox stores, but you can also now add it the individual mailboxes and public folders instead of to the entire store for administrative permissions.  We also do not recommend running the older method, “The Preinstaller” because in newer installations, it automaps accounts in outlook, which is not preferable.

Currently, for any supported version of Exchange 2007- 2019, Office 365, hosted exchange where we are using Outlook for autodiscover, it is now only required that you give the Sync Service account ownership of the source and destination folders we sync to or from, including any public folders.  Additionally, in parent nested folder trees, where the folder we are syncing to or from is a child of the store, including subfolders in a mailbox or public folder, the sync service account now only needs folder visible client access, with no details.  If we are creating a subfolder from a parent folder as we often do in the RGM (Relationship Group Manager) templating system, the Sync Service account must be an Publishing Editor of the parent folder, and it automatically gives owner permissions to the new folder.

To facilitate this, we have created the Diditbetter Support Menu Utilities to assist.  
Specifically, use the Office 365 and  On-Premise Exchange Permissions. 
The Zipped exe files are available here. 

Again, the trouble with this approach is that the script must be run during every onboarding of a new user, after the mailbox has been created. This can be logistically difficult, but possible.
Note that from the Diditbetter Support Menu we also have an option called Automate Permissions on a Schedule.  Presently this option will give full mailbox permissions to all users, to a single account, or to a distribution list, on a configurable timed basis.  This Scheduled Task can be run from anywhere, and must be run as an Exchange Organizational Administrator or Global Admin for 365.  This account giving permissions does not have to be the Sync Service account, but for consistency, must be run with credentials which do not change.  
Unfortunately, at the time of this post,  that Automated Permissions on a Schedule does not support granular permissions on a timed basis, nor MFA authentication.  Those tasks are currently on the development horizon.

For Granular access to users’ mailbox, connect to your domain with powershell
The Script is available in the Support setup from the download, and also is on the Replication Server and may have been updated and modified from this static version, but gives the ghist of it.

For Example: To grant just default Calendar Access use the scripts below and change the service account name “zadd2exchange” to whatever service account we use to sync.  For Contact Sync, replace Contacts where is says Calendar.  If creating a subfolder, Add2Exchange will do it automatically, if the service account is given publishing editor or owner the parent folder.
foreach ($m in $MB){Add-MailboxFolderPermission -Identity $m.identity -User zadd2exchange@Domain.com -AccessRights FolderVisible}
$fl2 = ":\Calendar"
foreach ($m in $MB){Add-MailboxFolderPermission -Identity ([string]::Concat($m.PrimarySmtpaddress,$fl2)) -User zadd2exchange@Domain.com -AccessRights Owner}
Individual scripts
Add-MailboxFolderPermission -Identity user1@Domain.com -User zadd2exchange@Domain.com -AccessRights FolderVisible
Add-MailboxFolderPermission -identity user1@Domain.com:\Calendar -User zadd2exchange@Domain.com -AccessRights Owner