What's with the CRM security descriptor?

In response to a number of questions I'm seeing on the Microsoft CRM newsgroup I've gone back through the archives and dug this up. I hope it helps.

There's been lots of speculation around the security descriptors in Microsoft CRM, and none of it is quite right. The “real” story behind the SD columns is talked about in the CRM architecture paper a bit. They really are NT security descriptors and in theory you can manipulate them using standard NT functionality. But... we use some of the access bits differently than they’re doc’d in MSDN and we’ve added some of our own.

As for the “hash” rumor, and the “encrypted” one too – there’s no such thing. We store binary data in the database in base64 encoded text fields. That means that attachments, sales lit, and security descriptors are really binary data wrapped up in standard encoding. Somewhere around here I had a routine that would scan through a table, pull the descriptors, convert them back to the binary format that NT likes, and dump them to the console. It’s an interesting application for learning, but it’s not enough information to figure out which ACEs go into the descriptor itself.

When we tweak an object (create, update, share, assign, etc.) we recalculate the SD values based on the instance’s location in the organization and on roles of security principals somehow related to it. For instance, a sales manager with DEEP READ access to accounts will probably have an ACE in the SD by way of the role membership that granted her the DEEP READ access. Explicit share means that the principal gets an explicit ACE. Implicit means the ACE came from a group (role, team, business, …).

But, don’t go thinking you’ve got it all figured out yet. You would still need to know how object hierarchies affect the SD value. That’s where this thread started. We have the concept of a ‘child entity’ which is essentially unsecure on its own. This means that we need to get the access rights from somewhere, so we pull it from the ‘parent’ instance. You can find these types by looking through the metadata for entities that don’t have security descriptors but still have security behavior and APIs.

Oh, and the idea of creating an instance through the application or API and copying the SD for later SQL inserts will only sometimes work. Actually, it’ll probably not work more often than it will. The reason is that there’s some additional information in the database to track access to entities. It’s not always kept up to date, and it’s not always applied to all entities, but it’s there nonetheless. So, if you try the trick of copying a known SD value when doing a “data migration” at the SQL level, remember caveat emptor.

Hope that clears up some of the fog.