April 21, 2006
Interesting RMS Issue
So I'm working on an RMS deployment for a customer and we ran into a weird issue that up until now I'd never seen before so I thought that I'd share the problem and what we finally discovered to be the cause of the problem.
If a user, let's call her Alice since RMS is a cryptographic application, created a piece of protected content using the built-in Office protection methods (IOW not using a custom template) and assigned another user, say Bob, a specific set of limited rights on the content, when Bob opened the content, rather than having the limited rights assigned appeared to have full control of the content. Now if Bob were to create a piece of protected content, and assigned limited rights to Carol, when Carol opened the protected content, she had the correct rights assigned. Similarly, if Carol assigned rights on content to Bob, everything worked as expected. If Bob or Carol assigned rights on content to Alice, Alice had the correct rights when opening the content. So the problem only occurred when Alice was protecting content. Finally, if Alice protected content using a custom template, everything worked as expected.
Examining the EULs issued to Bob or Carol showed that regardless of the protections assigned by Alice, Bob and Carol had the OWNER right, which is similar to NTFS full control, in the EUL.
Cause and Resolution
After opening a case with Microsoft's CSS we discovered what was causing this problem. The customer uses the email attribute of security groups to list the email address of the owner of each group. They do this so that they have a point of contact for adding user accounts to the group in question. This was the cause of the problem we were seeing. It turned out that Alice was the owner of a group that contained Bob and Carol and because of the practice of adding the group owner's email address to the email attribute of the group anyone who was a member of that group was being granted OWNER rights to the content. Removing Alice's email address from the email attribute of the group, and flushing RMS' group cache resolved this problem.
The other side effect of this issue is that any member of a group that contained Alice's email address in the email attribute would have OWNER rights on the content, even if they had not been specifically assigned rights on the content.
The reason that this behaviour did not appear when using custom templates is that the templates used the special RMS group Anyone which obviously doesn't have an email attribute.
The customer in question is going to fix up the security groups that affect their pilot deployment, however, this behaviour may well prevent them from pursuing a broader deployment of RMS.
Hope this helps.
Posted by Paul Adare at April 21, 2006 05:29 AM