Permissions can be synchronized between folders as well with the Priasoft PF Toolbox. Similar to how one can either create a new job or modify and existing one for contents sync, one can do the same for permissions.
The permissions sync process is one that will enumerate every folder in the hierarchy and for each folder enumerate the list of delegates that have rights on each folder, from both sides of the sync and differences applied. Note that because this will make folder-level changes it will also create a “dust cloud” of activity. There should be a “dust settling” time period to allow the permissions to replicate across the public folder mailboxes.
Unfortunately, the previous method of tracking progress cannot be used. The Get-PublicFolderMailboxDiagnostics PowerShell command does nott provide any metrics or values relating to the quantity of unsynchronized changes. Priasoft recommends waiting for the same period of time as the combined durations of both “dust settling” periods from steps #2 and #3 before any production use of the new folders is made.
How does it work?
The permission sync works in one of two ways depending on the following two scenarios:
- Same-Forest Migration
- Cross-Forest/Cross-Premises (Office365) Migration
In a same-forest scenario the process is automatic and simple. The Exchange address-book (GAL) is simply a representation of Active Directory’s Global Catalog. Since the GAL’s data source is Active Directory, the synchronization process can simply read and write the same values for permissions because the delegate info will point to the same underlying object.
However, in a cross-forest or cross-premises synchronization the process is a bit more complicated. The permission sync works by capturing a specific value from each delegate on one side and then performing an address-book lookup for a matching object on the other side. If the delegate from one side cannot be found in the address-book on the other side, no sync is performed, and no permissions are removed or added. Folder permissions are only removed if a previous sync was able to link a source delegate to a target delegate and the delegate was removed after a previous sync.
Each delegate in the access control list of a folder has a value know as the legacyExchangeDN (also know as X500 address). It is this value that is capture and for which a search is made. Subsequently this means that in order for permissions to be synchronized, the X500 addresses of the delegates must have been migrated to the target environment. Modern mailbox and address-book migration tools already to this for you, including Priasoft mailbox migration tools. It has been a longstanding element of Exchange migrations to copy the legacyExchangeDN of a mail-enabled object (mailbox, mail-user, contact, or distribution group) to its counterpart in the new system. The value is typically added to the list of additional email addresses (proxyAddresses in LDAP and EmailAddresses in PowerShell) as and X500: type. Mapi is able to find and access ANY recipient in the GAL if the X500 address of the object is known, regardless of whether the value is the primary address or a secondary address and also regardless of if the object is “hidden from address lists”.
This is of special importance for distribution groups (aka mail-enabled security groups, MESG). There are many deployments that use MESGs to control access to public folders. However, in many cases as well those same groups are not synchronized to the new Exchange environment (on-premises or Office 365). In such cases the Priasoft PF Toolbox would not be able to restore permissions for those because they would not be discoverable in the address-book. Priasoft highly recommends a review of all MESGs and to ensure existence of a complementary object in the other environment.
The permission sync task of the PF sync always analyzes both sides of the sync. However, in nearly all cases the address-book lookup of ‘target’ delegates in the source address-book will fail because the legacyExchangeDN values are not copied backwards in a migration. As such, one ends up generally with a one-way sync of permissions. If it is determined that permissions need to sync in both directions, a separate process (and out of the scope of the Priasoft tools) would need to be performed to copy the legacyExchangeDN values to the ‘source’ objects. Afterwards a resync of permissions on folders can be made.
A note about conflicts with permission sync. Unfortunately, Microsoft exchange does not have a timestamp per delegate that relates to a last modification time. When permissions are changed on a folder, the folder’s last modification time is changed but there is no way to tell which delegate changed sole by the change of the modification time. Also, just because the modification time of a folder changes doesn’t necessarily mean that permissions were changed…it could simply mean the folder was renamed or some other property of the folder changed. When synchronizing permissions, the sync task will record the timestamp of the sync action. On a subsequent sync of the same folder the current modified time of the folder is compared with the recorded time of the last sync and if different the application knows the folder has been modified since the last sync. If the LEFT side folder shows that it has been modified since the list sync, but the RIGHT-side folder show that no modifications have occurred, any difference in permissions are flowed left-to-right. The reverse will happen if the RIGHT-side folder shows as modified since the last sync and the LEFT side as unchanged.
If both sides show as modified since the last sync and if there is a difference in the rights of any delegates, the side with the least restrictive set of rights is chosen as the source value and is copied to the other side. This should be a very rare occurrence, one where permissions of a folder are changed on both sides for the same delegate and in between synchronization sessions.
ANONYMOUS and DEFAULT permissions
Every folder in Exchange – public or mailbox – is supposed to have to special delegates named ANONYMOUS and DEFAULT. The anonymous delegate maps to the special Active Directory group ‘Anonymous Users’ and the default delegate maps to the ‘Authenticated Users’ group. The anonymous delegate is primarily used by the hub transport service for mail delivery by external senders. In order for mail to delivery to a mail-enabled public folder (MEPF) from an external sender, the anonymous delegate MUST have the CreateItems right on the folder. Microsoft Exchange automatically adds the CreateItems right to the ANONYMOUS delegate of the folder. However, it does not update the DEFAULT delegate with this right.
If an internal sender sends mail to a MEPF, that user must have the CreateItems right on the folder. A user can receive this right by having their account directly added to the folder with this right, through a group membership that has the right, or lastly by the DEFAULT delegate having the CreateItems right. There is a quirk in this regard with external senders that map to a mailbox or mail-enabled user in the environment. Even though the mail originates from an external source, the Exchange hub transport will map the sender’s email address to the mailbox or mail-user and since both object types derive from an Active Directory user account, the same rules apply as if it was from an internal sender. If the external sender maps to an internal Mail-Contact object, the ANONYMOUS delegate is still used.
When creating the sync job, a question is prompted regarding the handling of the DEFAULT and ANONYMOUS delegates. The common answer to the question is to sync the rights for each from LEFT-to-RIGHT on the first sync and then to base the direction of flow on the last modified time of the folder on any subsequent sync. This ensures that for the most common if scenarios these permissions are copied to the new environment as expected.
However, it is important to note that on a new deployment of modern public folders Microsoft Exchange sets the DEFAULT delegate at the root of the hierarchy (the ‘\’ folder) with Author rights and not NONE. This may be different than the current expectation or usage and should be considered at the beginning of the project. If steps #2 and #3 occur without considering this, all of the folders created will initially have Author rights for all authenticated users. When the permissions sync runs, the DEFAULT delegate will be updated, but up until that time if any users are redirected to use the new public folders, they may have more rights to folders than they do in the source.
Furthermore, since the root folder ‘\’ defaults this way, any new root-level folders create after the migration would also start with Author rights for all users. Priasoft recommends setting the root folder ‘\’ to have the DEFAULT delegate set to NONE before running steps #2 and #3.
The process to change the DEFAULT or ANONYMOUS delegate permissions can only be done by Exchange PowerShell and is performed by Remove-PublicFolderClientPermission. Oddly and with frustration, Exchange’s web based ECP does not provide access to these delegates. When this command is run for the DEFAULT or ANONYMOUS delegate, it does not remove the delegate off the folder but instead sets the rights value to NONE. In contrast, running the same command for a user or group will actually remove that delegate from the folder and users’ access would be determined by the DEFAULT delegate. If DEFAULT has rights other than NONE and you want to block a user from having any rights to the same folder, the user must be added to the folder with a rights value of NONE.
Orphaned Delegates
Over time it is very common for delegates on public folders to become orphaned. An orphaned delegate happens when the underlying user or group is either deleted from Active Directory or when it is mail-disabled (all exchange attributes removed). When a user or group is deleted or mail disabled, Exchange has no backlinks in this regard and so has no ability to go from the Active Directory object directly to the public folder for update and thus orphaned delegates occur.
Permission on an exchange folder – public or mailbox – actually store the SID of the Active Directory object in a standard security descriptor structure. Exchange presents its own translation of this data as an ACL (access control list). When the request is made to provide the ACL, Exchange will request the Active Directory object from a Domain Controller based on the stored SID value.
Orphaned delegates appear in one of two ways:
- NT USER: Domain\username
- NT USER: S-1-5-000-000000000000000000000000-0000000000000-00000000
The first pattern occurs when the underlying Active Directory object still exists but is not mail-enabled. Exchange is able to return the domain\username value because it was able to receive the object and pull its SamAccountName value.
The second pattern – a textual SID value – indicates that Exchange’s attempt to retrieve an Active Directory object failed, usually because it doesn’t exist, and the only meaningful value left that it could provide is the SID value.
There is no requirement to do any cleanup of these objects on any of the public folders. Orphaned permissions will inherently fail to sync because they do not contain an X500 address which is used for the lookup on the other side. However, since the likelihood of orphaned permissions is very high in most environments it will mean that reporting and auditing of the sync processing will be difficult or impossible to fully account without enumerating and listing every delegate on every folder.
Priasoft PF Toolbox has a consistency report task that can report on permissions and will do so simply by counts. It does not list out all delegates in the report as it often is simply too much data to present. The report will show the number of permissions that were synchronized versus not. However, the unsynchronized permissions are often orphans.
