Microsoft, quit reinventing role based security in your products!

Last night at the Vancouver SBS UG we had a presention by Scott Colson, CRM-MVP, on the upcoming MS CRM 3.0. I was really looking forward to this, since my last experience in learning about CRM 3.0 was a dismal failure.

This time, it was much better. I now understand the real vs perceived benefits of Microsoft's CRM product, especially with its interaction with the Windows stack. I think the product has a ways to go to be as clean as I would like to see it... but the 3.0 product is way better than what I saw on the 1.2 demo I was given earlier last year.

But that's not the point of this post. I cringed as Scott discussed security of CRM 3.0. Not that the security is weak... but that Microsoft is re-inventing the wheel again with the way it associates security roles in it's products. I complained about this before when I found the same problem with Sharepoint on SBS.

Now Microsoft may have some reasons for doing this, so its hard to be critical here. Especially since CRM is licensed by named user. But their approach seems to go against good infosec principles and practices as it relates to single-point role based security management. Let me explain.

One of the strengths of AD is the fact that you can associate roles through Security Groups. As an example, on our SBS AD at the office our security model has us creating ACE's (Access Control Entries such as users and groups) based upon job function and then using very specific ACL's(Access Control Lists) to lock them down allowing users to have the ability to perform only their job function and nothing more. Least privilege at it's finest.

It is easy to build a "sales" role and a "marketing" role with AD Security Groups and assign the users to those groups as required. What I EXPECTED in Microsoft's CRM package was the ability to respect that associative authorization and allow me to carry that on through CRM. Unfortunatley, that is not what happens.

Microsoft started it right, by having the user authenticate to the AD. So CRM knows user "bob" is currently logged on from that machine, but then it dies there on the AD security role side of things. It AUTHENTICATES user "bob", but doesn't allow AD to AUTHORIZE what he is allowed to do. At this point, CRM looks at its own built-in security roles to determine what privileges "bob" is authorized to have. The association is to the user via the role he is given in CRM, and NOT in AD. It makes sense on it's own, and Microsoft did a great job with the "Security Roles" security matrix for assigning privileges within CRM. But in my mind, the approach is flawed. And let me tell you why.

When using the Windows stack with AD for security, the assignment and control of security privileges should remain in AD. CRM, and every other Microsoft product for that matter, should respect that so changes in AD are immediately reflected throughout the entire security infrastructure of the organization, which should impact privilege levels in the software using that associative authorization. This has HUGE impact whenever a user's job function changes. If I remove user "bob" from the sales role in AD, it should IMMEDIATELY be reflected in CRM that bob is not allowed access to the sales role. Currently, you would have to make the change in AD, then go into CRM and also change it there. However, if the "Security Roles" in CRM were associated to Security Groups instead of Users, this would get around this entire thing.

Does that make sense? You can still build "Security Roles" in CRM so that you can assign privileges to the different Entities within the software. But there should be an option so that those Security Roles can be associated to the "Security Groups" in AD rather than specific users, so that security changes that impact authorization privileges in AD immediately are reflected in any software taking advantage of AD.

Imagine this scenario. User "alice" is in a junior position as a front line salesperson, and her security role in AD has her in the Security Group "Sales". In CRM, this gives her the ability to add new events for leads and hot prospects but does not allow her to query other "Sales" associates to see how they are doing... a privilege that is only afforded to the "SalesManager" role which user "bob" currently has. At the end of this month "bob" is leaving the organization and "alice" will be promoted to his position. All that would have to happen is disable "bob's" account in AD which would prevent him access to the system. And this works now... since login auth is done with AD. But now comes the nice part. By removing "alice" from the "Sales" role and placing her in the "SalesManager" role, she would immediately have the required permissions to do her job. Without anyone having to go into CRM and making a single change. And it would immediately give her access to any other privileged resource for that role within the domain in the same manner.

I don't understand WHY Microsoft feels it has to reinvent how the security model works with each product. The same scenario exists with Sharepoint. It would be much easier to assign roles through Security Groups in AD instead of assigning users to built in roles in there as well.

To be fair, there could be design decisions I don't understand here. I haven't seen a threat model into why they separated authentication and authorization like this. But it seems silly to me to duplicate efforts and require the workflow for security changes to have to take place in two separate places. It is much too easy to forget the CRM step, which could open up the business to unnecessary risk. And it becomes MUCH easier to manage when you have 10's or 100's of users that have to use the software.

Use Active Directory. That is what its for. And Microsoft, you OWN it. You should be leading us here... giving us the option to have the entire Windows stack working together through a single role-based security model when using your software.