We’ve used the Priasoft PF Sync solution to sync some folders between environments. We have found afterwards that users who previously could see the folder tree, could not after sync. We have also had some other users that never could see some folders that are now able.
During investigation, we found that the Default permissions on the folders were changed and affected users as described.
Can this behavior be explained? What can be done for future syncs?
Priasoft’s PF Sync solution can obviously synchronize permissions, including the Default and Anonymous permissions on folders. Understanding how sync handles permissions generally and specifically for Default/Anonymous may help answer this question as well and show how to handle this going forward.
What does Priasoft know about permissions?
Since the Priasoft PF Sync is a MAPI based tool, the product can only work with information that can be accessed using MAPI. When it comes to permissions on folders, there is very little information actually recorded on a folder.
Permissions on Exchange folders are stored in a special “table” property, on the folder itself. This table has one row for each unique account and the specific rights for it. Default and Anonymous are also listed as rows in this table. For each row in the table, there are only a few of columns of information that are of any value: a numeric “row id” value, the EntryID of the object with rights, and the actual numeric “rights” value. The “EntryID” is a binary value that uniquely describes a recipient from the Global Address List in Exchange. Embedded in this binary value is a string value that is the X500 value of the recipient (aka legacyExchangeDN). The “row id” is a very large integer value that identifies the position of the permission in the table.
The Default and Anonymous permissions don’t actually map to any object in the Exchange GAL. The identification of these permissions are done solely by their “row id” values. Default always has a row id of zero and Anonymous always has a value of -1 (0xFFFFFFFFFFFFFFFF).
So, in the list of permissions, there is no column for “Last Modified” or “Created”. As such, Priasoft (nor anyone else) is able to determine when a permission was added or changed. The modified time of the folder is changed when permissions change, but such is unreliable since ANY CHANGE causes the folder’s modified time to change.
How does Priasoft know what to do?
Since there’s no reliable way to understand which side of a sync changed, Priasoft adds some intelligence here to try to figure this out. If a LEFT side folder is seen as unmodified since last sync, we can assume that none of the permissions have changed. If the linked RIGHT side folder does show that the folder has been modified, it *could* be that permissions have changed on the RIGHT side folder. In this case, the tools will carry the permissions of the RIGHT side folder back to the LEFT. This is a normal and expected pattern.
However, if, at the time of sync, both folders are found to have been modified since the last sync, we are unable to determine which specific permissions have changed. Even further to that, we are unable to determine which permission is more recent between the two sides.
In this case, Priasoft takes a position of not interrupting end users by choosing the least restrictive permission and copying the rights to the other side. This idea was chosen since it has the least impact to users.
Consider that with any first sync, all “target” data will be new and have a more recent modified time.
This is important to consider for Default and Anonymous permissions for the following reasons. If prior to first sync the policy in an environment is: no user shall see or have access to a folder except that they have explicit rights given to the folder, there can be a surprise after the first sync.
When a new folder is created in Exchange, whether by a user or by a tool, the new folder “inherits” a few values from the parent folder. Upon creation, all permissions of the parent folders (that are allowed to be inherited) are copied from the parent folder and applied to the new child folder. While this is not really “inheritance” as most would expect or understand, this is the reality of Exchange folders. After a folder is created, any changes to the parent do not cascade down to children.
Since the parent folder will have values for Default and Anonymous, the child folder will receive the same rights for those pseudo-accounts. If the parent is set with Default = Folder Visible, the child will also be visible. This inheritance starts from the root of the folder tree (All Public Folders, for example).
If the “target” environment in a given public folder sync setup is set with Default=Visible from the very beginning, the first sync might cause all the “source” folders to become visible as well. This happens because of the rule of sync: last change wins. Since all the folder will have just been created in the target environment by sync, they will most likely have the most recently modified timestamp causing permissions that are set on these new target folders to flow back to the source environment. Unlike a user permission, Default and Anonymous will exist on both sides and the process will synchronize those permissions, causing the source folders to receive the Default=Visible value.
User changes can cause this to happen.
In a similar way as described above, if a user on the RIGHT side were to modify permissions, including an adjustment to Default or Anonymous, and if (at the time of sync) that change is seen as more recent, then the actions of that user would flow back to the source.
A reminder here that the rule mentioned above about the least restrictive permission only comes in to play if both the LEFT and RIGHT side folders have been modified since the last sync.
