Most Microsoft Exchange server directory objects are protected with Windows NT security descriptors. Public folder is a directory object and may have an associated security descriptor. However, client access to its contents is protected by public folder ACL - another binary structure different from Windows NT DACL. You may wonder why. It is a confusing matter.
If we analyze the list of directory access rights, we could find the following available:
Add Child
Modify User Attributes
Modify Admin Attributes
Send As
Mailbox Owner
Logon Rights
Replication
Modify Permissions
Search
Delete
If we take off the rights that don't relate to the matter of client access to folders, we'll end up with the following:
Add Child
Mailbox Owner
Delete
As you see, this list is very short. Also, the Mailbox Owner right, for example, allows to read and delete all mail items belonging to mailbox. Apparently, the list of rights was designed with a mailbox in mind. Mailboxes usually belong to a single user. This user has absolute power over its entire contents.
A public folder is a different concept. It is a shared resource. It is supposed to be accessed by many users. If we want to categorize access, we need to introduce other rights. For example, a right to edit or delete own items, a right to contribute items, etc. Perhaps it would be possible to introduce them in a set of directory access rights?
It turns out to be not possible. Windows NT access masks are DWORDs. Rights
that are specific to any object type such as files, access tokens, or Microsoft
Exchange Directory may only occupy lower 16 bits. Thus, we have only 16
individual access rights possible. If you analyze rights already used - you'll
discover that 9 out of 16 are already taken (the Delete right does not count
because it is standard, its access mask is 0x00010000). We have only 7 rights to
go with. This is not many, especially if we consider evolution of Exchange and
possible need for other rights. But even if we had all 7, that would not
suffice, because public folder ACLs require 10, perhaps more in the future.
How Access Control on Two Levels Works
A user must have Logon Rights to the server, and be assigned a mailbox in order to use public folders. This is enforced by the Directory Access rights. An administrator gives a user Logon Rights to the site, and also creates a mailbox. After that a user can logon to Exchange Server via a MAPI profile and browse contents of public folders, if he/she has enough client permissions as written in public folder ACL.
Thus, it is essentially a two stage protection. Whether a user can logon to an Exchange server is defined by Windows NT security descriptors protecting the Directory. Whether a user can access a specific public folder is then determined by this public folder ACLs.
If a user is not listed explicitly in a public folder ACL, but the Default access allows access, then the user will be given the Default access rights. However, a user may be listed with None rights, in this case access will be denied even if Default permits.
The difference between a Windows NT DACL and a public folder ACL is that the first lists Windows NT security identifiers with their access masks, while the second lists ENTRYIDs. Windows NT DACL is a documented structure. Entries in a DACL must follow certain order (ACCESS_DENIED_ACEs first). A public folder ACLs may be accessed via the two documented interfaces IExchangeFolderACLs or IExchangeModifyTable. Also, ACLs binary data appears to occupy the folder's PR_ACL_DATA property. You may try to modify its contents directly with GetProps and SetProps calls. The format is not documented, though.