This is part two of a three part series. See part one here.
When we set out to design the Exchange 2000 NT ACLs, the biggest task we faced was to determine what the correct values for the NT access rights should be.
We knew we had to be compatible with the existing 10 Exchange access rights - every access check semantic that could be expressed in Exchange 5.5 had to be able to be expressed in Exchange 2000. So the logical interpretation was to simply bring the 10 access rights over from Exchange 5.5 and just stick them on the NT ACLs. Since the NT access check mechanism allows for 16 access rights, we figured that would be easy.
Then we remembered IFS.
See, there's this amazingly cool feature in Exchange 2000 called IFS. It exposes Exchange folders as if they're filesystem folders. And the IFS team wanted to support security fully on the store, and they wanted to use Exchange's ACLs directly to do it (as opposed to rewriting the ACL before they handed it to the client).
This threw a huge wrench into the works because it added a whole other level of compatibility requirements. Now Exchange access rights had to:
Be able to be mapped bidrectionally between Exchange 5.5 access rights
Be bit-wise compatible with the NT file-system access rights.
Be able to express all the semantics of Exchange that aren't present in the file-system.
Needless to say, we were in quite a pickle. One major issue we had had to do with the NT native access rights themselves. The NT filesystem access rights are as follows:
file & pipe
file & pipe
file & directory
file & directory
NT defines 14 different access rights, but it also overlays the rights. For example, the same access right that allows access to the data streams on a file is used to control if the user can see the contents of a directory. Similarly, the same bit that's used to determine if a file can be opened for append access is used to control the creation of subdirectories. In addition to those access rights, NT also defines 5 "standard" access rights:
These access rights apply to all objects, not just files. The "SYNCHRONIZE" access right isn't a proper "access" right, its an indication that the handle to the object being opened can be used synchronization. The other three access rights protect various parts of the security descriptor in the object.
Fortunately, the Exchange access rights are similarly partionable - 5 of the 10 access rights (frightsReadAny, frightsEditAny, frightsDeleteAny, frightsEditOwned and frightsDeleteOwned) apply to the messages in a folder, 4 of the access rights apply to the folder (frightsCreate, frightsCreateSubfolder, frightsOwner, frightsVisible). The remaining right (frightsContact) isn't really an access right - it's not used to grant or deny access to resources, but just a placeholder used to indicate that a particular user is a contact for the folder.
Taking each of the exchange access rights in turn, we realized that:
frightsReadAny - This right is sort-of a "read" access right. It allows the user to read all the properties on any message in the folder.
frightsEditAny - This right is sort-of a "write" access right. It allows the user to write any property on any message in the folder.
frightsDeleteAny - This maps nicely to the DELETE filesystem access right.
frightsEditOwned - This is "sort-of" like a write access, but it's conditional based on the "owner" of the message.
frightsDeleteOwned - This is "sort-of" like delete access, but again, it's conditional.
frightsCreate - This maps nicely to the FILE_ADD_FILE access right.
frightsCreateSubFolder - This maps nicely to the FILE_ADD_SUBDIRECTORY right.
frightsOwner - This one's kinda tough - it enables write access to all the properties in the folder.
frightsVisible - This property allows read access to the properties in the folder.
Next, we looked at the NT access rights. Our big "aha!" was when we realized that there could be a one-to-many relationship between the exchange access rights and the NT access rights. For example, on a file, there are three access rights that map to "read-like" access rights - FILE_READ_DATA, FILE_READ_EA, and FILE_READ_ATTRIBUTES. Similarly, there are 3 write-like access rights - FILE_WRITE_DATA, FILE_WRITE_EA and FILE_WRITE_ATTRIBUTES. So if we defined Exchange access rights for each of these "read-like" and "write-like" bits, we could simply map the exchange writes to ALL of them. Similarly, we could make the same statements about the frightsOwner and frightsVisible access rights - they can be mapped to FILE_WRITE_ATTRIBUTE and FILE_READ_ATTRIBUTE respectively. So we were 90% of the way done with figuring out what to do.
Once we decided that we were going to map single access rights to multiple access bits, we needed to figure out what each of the NT filesystem access rights would mean to the Exchange store.
We started with the read access rights: FILE_READ_DATA, FILE_READ_EA, and FILE_READ_ATTRIBUTES.
FILE_READ_DATA protects access to the file's data streams. The closest analog to this in Exchange are the properties that make up the "body" of the message. Ok, so far so good. But what are "attributes" and "extended attributes" on a message? Some of the properties like PR_ATTR_READONLY were obvious - it's used to map to the read-only filesystem attribute, so it's clearly an attribute, but what about the other ones.
We decided to make a totally and absolutely arbitrary decision. We defined a specific set of properties as "attributes", a specific set of properties as "body" properties, and all the others we classified as either "extended attributes" or "body" properties depending on whether or not the property was transmittable.
Exchange 2000 Access Mask
When we were finally done and the dust had settled, we had settled on twenty-two access rights, but many of them overlap. We finally ended up with:
The Exchange Platinum access rights are:
The ability to read the “body” of a message.
The ability to open a contents table.
The ability to modify the “body” of a message.
The ability to create new messages
The ability to append data to a message
The ability to create a subfolder
The ability to read properties on the folder/message.
the ability to write properties on the folder/message.
The ability to “execute” the body of a message
The ability to delete arbitrary items under this folder
The ability to read the “attributes” of a folder/message.
The ability to modify the “attributes” of a folder/message.
The ability to modify messages that the principal granted this right has created.
The ability to delete messages that the principal granted this right has created.
The ability to see the items in the folder.
No security semantics, used to indicate the “owner” of a folder.
No security semantics, used to indicate “contacts” for a folder – people that are not the owner, but are responsible for the folder.
Alias for NT “WRITE_DAC” right.
Alias for NT “DELETE” right.
Alias for NT “WRITE_OWNER” right.
Alias for NT “READ_CONTROL” right.
Alias for NT “SYNCHRONIZE” right.
Access rights that apply only to messages have a † symbol after their name; access rights that apply only to folders have a ‡ symbol after their name. If an access right does not have a symbol, it applies to both messages and folders.
Putting it all together
Ok, so now that we've defined the Exchange 2000 access rights, we needed to set up the mapping between Exchange 5.5 access rights and Exchange 2000 access rights. If we can't do that, we can't even begin to attempt to convert ACLs from Exchange 5.5 to Exchange 2000
So here's what we finally came up with:
Exchange 5.5 Rights
Exchange 2000 Rights
fsdrightReadControl fsdrightReadBody fsdrightReadAttributes fsdrightReadProperty fsdrightViewItem fsdrightSynchronize fsdrightExecute
And the reverse mapping table (used when converting between an NT security descriptor into an Exchange ACL):
EXCHANGE 2000 ACCESS RIGHTS
Exchange 5.5 access rightS
frightsVisible for folders, ignored on messages
frightsDeleteAny on messages
A quick note: frightsOwner only granted if ALL the folder owner rights are present – fsdrightOwner fsdrightWriteProperty fsdrightWriteSD fsdrightDelete fsdrightWriteOwner fsdrightWriteAttributes fsdrightViewItem.
Well, that's the basics on access rights. I don't quite know how it got this long but...
The next column pulls it together and describes how we convert from Exchange 5.5 ACLs into Exchange 2000 ACLs. (See first column)