Exchange 5.5 Security
When an Exchange client contacts the Exchange 5.5 store, the Exchange client specifies an Exchange DN to represent the user on the Exchange server. The NT user’s account is validated to ensure that it has the “receive-as” right to that object in the Exchange 5.5 directory service. From that point on, the user is identified by their DN and not by their NT account.
Exchange 5.5 only supported security on folder objects; access rights for the messages in a folder were defined by the access rights on the folder itself.
Exchange 5.5 supports ten distinct access rights. The access rights are:
- frightsReadAny (0x0000001L) – The ability to read any message in the folder.
- frightsCreate (0x0000002L) – The ability to create items within the folder.
- frightsEditOwned (0x0000008L) – The ability to modify items created by the user within the folder
- frightsDeleteOwned (0x0000010L) – The ability to delete items created by the user within the folder.
- frightsEditAny (0x0000020L) – The ability to modify any items in the folder
- frightsDeleteAny (0x0000040L) – The ability to delete any items the folder
- frightsCreateSubfolder (0x0000080L) – The ability to create folders underneath the folder.
- frightsOwner (0x0000100L) – The ability to modify the properties of the folder itself. This includes the right to delete the folder.
- frightsContact (0x0000200L) – This is not an access right at all, instead it is administrative functionality implemented in the ACL on a folder.
- frightsVisible (0x0000400L) – The ability to see the folder in a hierarchy table - this right was added in Exchange 5.0
Careful examination of the access rights reveals that five of the access rights apply to the items in the folder (frightsReadAny, frightsEditOwned, frightsDeleteOwned, frightsEditAny, and fRightsDeleteAny), and five of the access rights apply to the folder itself (frightsCreate, frightsCreateSubfolder, frightsOwner, frightsContact, frightsVisible).
The two “owner” rights (frightsEditOwned and frightsDeleteOwned) are critical when implementing a discussion folder. In that scenario, a user should be allowed to modify (or delete) messages that they created, but they should NOT be allowed to modify (delete) items that another user has created.
Exchange 5.5 ACLs
In Exchange 5.5, an ACL was simply an unordered list of DN’s and their associated Exchange rights. The membership of an ACL was exposed to a client via the IExchangeModifyTable interface and via the PR_ACL_DATA and PR_EXTENDED_ACL_DATA properties.
Exchange 5.5 Access Check
Exchange 5.5 implemented a “most specific”->”least specific” access check algorithm. If a user was explicitly mentioned in an ACE (their DN appeared in the ACL), then the ACE contained the complete set of access rights for that user. If the user was NOT listed in the ACL, then the users rights were calculated by combining (with a logical OR) all the rights for the groups in the ACL of which the user was a member. If the user wasn’t explicitly listed in the ACL, and wasn’t a member of the groups listed in the ACL, then the users rights were calculated from the default rights on the folder.
For example, consider what happens to the following set of 4 users:
- User 1: Member of Group A and Group C
- User 2: Member of Group A
- User 3: Member of Group B
- User 4: Not a member of group.
In addition, Group C is a member of Group A. Pictorally, this can be represented as:
So what happens when each of these users attempts to access a folder with the following ACL:
|Group B: Read, Write|
|User 3: Read, Delete|
|Group C: Delete, Create Items|
|Group A: Read, Create Subfolder|
|Default: Delete Own Item, Edit Own Item|
The access rights for the users in this example are as follows:
- User 1 – Read, Write (from Group B), Delete, Create Items (from Group C), Create Subfolder (from Group A)
- User 2 – Read, Create Subfolder (from Group C)
- User 3 - Read, Delete
- User 4 – Delete Own Item, Edit Own Item