Reduced Permissions for Add2Exchange and Add2Outlook for Exchange 2007-2019, on premise, hosted or Office 365

First of all, the Sync Service account is a powerful account and its login and password should be highly guarded, no matter whether or not you reduce the permissions.  We have strong permissions for this account in order to provide FULL Automation. If this account were configured the default way, the power it has is safe, as long as the machine is safe and the password is very strong. 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 in order to offer complete automation. Without it, there is a manual onboarding effort or other powerful accounts to consider in the set up creating more moving parts, but can be accomplished easily. The default line is, 'Yes, permissions can be reduced, but full automation suffers.'

Some organizations question the permissions we give to the service account and configuration changes we make on the replication server. This post is an attempt to fully explain each permission and configuration change and why we do it and what is possible to “ratchet down” in the configuration and the ramifications of each setting change. 

Question: We downloaded the trial and read over the documentation, but before installing, we need to determine the security implications of a few things mentioned beforehand such as disabling the UAC on the VM, allowing the programmatic access and enabling macros. Is this required in order to try and / or use the software? Also we do not want to allow the account to be an Exchange Administrator - is this required?

Answers:
Macros - Enabling macros is not needed or required.

Allowing Programmatic Access - We use Outlook for Autodiscover for your Exchange profile, and DiditBetter Software is therefore fault tolerant - assuming your DNS is correct. In Outlook there is an option for “Allowing programmatic access” and this is recommended.  Even though we use a separate thread, and do not require Outlook to be open, in the past Microsoft has sometimes changed their Outlook software, and several times made a change requiring it, and then releasing a fix so it is not needed.  We recommend keeping it off for uninterrupted syncing. 

Disabling User Account Control - UAC must be disabled during the initial install and set up, so the service we create can be set to the actual sync account. Once set up and running, the system could be set with UAC re-enabled. However, when running build updates and upgrades, make sure you would have to temporarily disable UAC, reboot and complete upgrade process before re-enabling.

Permissions
The service account isn’t required to have Exchange Organizational Administration either, as you can manually give permissions with another account.  In this configuration, the sync account can be only a domain user. You can also use another account to set the automatic timed permissions, but if that password changes, you will need to update it on whatever machine you are running it from. We bit lock and encrypt the passwords for any and all accounts we use to run permissions and can run these on this replication server or whatever box we are running permissions from. Normally we run it as a scheduled task on the replication server, but that is not required. If you use another account to assist in giving permissions during onboarding, it will need to be an Exchange Administrator in 365, or if hybrid or only on prem, an Exchange Administrator/Organizational Admin and perhaps a built-in administrator to be able to run those permissions automatically or manually on a CAS server. 

By default, we give full mailbox access to a synced users mailbox. We do this by giving permissions on a timed basis (every 6 hours by default) to the members of the distribution list(s) we are syncing to. 

Some want to add granular permissions instead of giving full mailbox permissions. This is tighter security than giving the Sync Service account permissions to the entire stores with full mailbox access and no auto mapping. This reduced requirement may be necessary as part of compliance or for general enhanced security. This is certainly doable. Specifically, the service account doesn’t need to have full access permissions, it only needs visible to the mailbox default store and visible to any parent folder, publishing editor to the immediate parent, (if any in between) and owner access to the folder we replicate to. We have a PowerShell which does this for you.  If the service account makes the folder, it just needs publishing editor to the folder immediately upline in the folder structure. This can be done manually as part of offboarding.

The advantage of full mailbox access and not granular access is if you add a new user to the distribution list, the system will give permissions automatically and then make the relationship and will sync without intervention. If you are making another kind of relationship to another folder, using the same distribution list, the system will do this automatically, without adjusting the permissions routine. The advantage of a full mailbox access is the service account can make a new relationship to a different folder by just adding the user to a Distribution list and having the sync system make a new relationship and start syncing.  By giving granular permissions, you have to edit the permissions timed execution routine, done from the DiditBetter Support Menu PowerShell and run the granular distribution permissions. 

Offboarding: Removing relationships is the same with both permissions approach, full and granular. Simply removing a user from the managed distribution list will dereplicate that data. You can do it almost immediately by “poking it” or wait a few hours to give the system enough time to dereplicate, or to hide the account from the GAL, remove the license, tombstone, or delete. Whether you poke it or wait for the automation, data will be removed in both cases, for completely automatic operation. This is important for BYOD (Bring your own Devices) configurations, where you don’t want them to leave with your data.

Why does the Add2Exchange Service account need to be part of the AD “Built-in Administrators Group”? If using 365 as Exchange and using Outlook as the protocol for Autodiscover and management, the service account does not have to be part of the local Administrator's group of any exchange server it connects to or the server it replicates to anymore. This account needs no other permissions on the Exchange Server box, but has to have at least granular permissions to mailboxes and folders is syncs to or from within Exchange.   

The account has to be a local administrator of the replication server it is on, but not the AD group. Built in administrators was needed to log in and run permissions PowerShells in on prem or hybrid mode. The service account was needed to be part of the AD “Built-in Administrators Group because if on premises exchange, it would need to be able to log on and do remote permissions PowerShells, but even that is not required if access is given some other way. 

Replication Server Local Administrator and permissions requirements for local SQL install
If the replication server is an on or “off the domain” box, either is fine, but that local account has to be part of local admins of the replication server and at the very least, be able to “log on as a service”.  If we are using the local SQL Express instance, this account would also need to be able to have the default permissions for a SQL installation: “back up files and directories”, “view debug logs” and “Manage auditing and security log”. 

Group Policy of the Replication Server
If the replication box is an “on domain” server, it can be Windows 10, or any version of Windows Server, real machine or virtual, with at least 2 virtual processors, 200 gig hard drive and ideally with 8 gigs of ram.   The replication server should be managed as a server, with minimum Group Policy, and for consistent syncing be able to manually run Windows updates for Critical packages when we do upgrades of our software.  We guarantee the version we are installing works with the current critical service packs for “all Microsoft products” in effect at the time.  We usually ask to download and notify and if using Outlook, we disable automatic updates for consistent syncing.   Yes, Update Management of the replication server can be done remotely with your management software, and usually reboot afterwards.  It is best if we can do them manually as an exception when updating.  Limited Group Policy is ideal.  If antivirus is used on the replication server, it is fine, and we will give you a list of exclusions specific to your installation for maximum utility.

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 fast and effective, but this was not fault tolerant since we were specifying exchange server names.  Since 2012, we have been using Outlook for the Autodiscover record which allowed us to ratchet down those permissions and point 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 a new security group (A2ESecurity) to the top of the store so it makes it easy to add other relationships, but this process certainly was not part of reduced permissions and you don’t have to anymore. 

Currently, and for any supported version of Exchange 2007- 2021, Office 365, hosted exchange where we are using Outlook for Autodiscover, the most reduced permissions possible is 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 or resources.  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 a 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 PowerShell Utilities to assist.  

Again, the trouble with reduced permissions is that the script must be run during every onboarding of a new user, after the mailbox has been created and migrated to its final location. 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 Administrator in 365 or Exchange Organizational Administrator (if on prem or hybrid).  This account giving permissions does not have to be the Sync Service account, but for consistency, it should be run with credentials which do not change or if changed, updated and bit locked on the system it runs from.  
 

Unfortunately, at the time of this post, Automated Permissions on a Schedule does not support granular permissions on a timed basis. Those tasks are currently on the development timeline horizon.

For Granular access to users’ mailbox, the Script is available as an option in the DiditBetter Support Menu.ps1 To run from another system, these files are located in the Support setup from the extracted download, or the \Setup directory of the installed Open Door Software directory. 

For a complete list of commands we use, Open the DiditBetter Support Menu and look to the left top and see DiditBetter Commands.   

For example, the access PowerShell we use 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.
 
$mb=get-mailbox
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

In conclusion, giving full access rights, disabling UAC and allowing programmatic access to the service account is recommended for consistency, ease of management and complete automation, but not required. Making these changes is common for complete sync automation and ease of management and support. 

If you have security concerns including specific questions on the installation requirements for tightened security, pre-requisites and/or use, please open a ticket online so we can have a certified technical specialist address your questions.