Role-based security has been evolving on the Windows platform since Windows NT 3.1. You will find user roles in SQL Server and Exchange; role-based security is also part of Windows Server 2003. OpsMgr 2007 uses roles to determine whether a process (an instance of an executing program) is privileged, by checking the security context for a particular user or group.
Back when security was simple, a basic security implementation might just be to authorize users to access a particular application. This usually isn't enough, as you may want to define the type of access one has within that application. Think of that as different security roles.
A simplistic mapping of roles would be:
[User] has a [Role]
However, different roles often have overlapping tasks within an application, so now our mapping would be:
[User] has [Role] is allowed to execute [Tasks] made up of [Operations]
With this mapping (or model), an application can check if a given user has permission to execute a certain application and not worry about everything in-between.
Applying this to OpsMgr, a user role that grants authoring rights may limit its scope to a particular list of classes, while a user role that grants monitoring rights may limit that scope to a list of monitoring groups and views. In addition, specific tasks or operations are grouped into profiles.
A role is a combination of a profile (capabilities) and a scope (the breadth of data and objects one is able to access).
OpsMgr comes out of the box with a number of pre-defined roles. These built-in roles are associated with specific profiles, although they do not limit scopes. To narrow scope, you can create your own custom roles based on the built-in roles (with the exception of the Administrator profile, which cannot be customized). There is no limit to the number of user-defined roles you can create.
OpsMgr also incorporates Run As Profiles and Run As Accounts. A Run As Profile allow you to take a Windows user account and apply it to a specified profile in OpsMgr. Run As Profiles allow a management pack author to associate an identity other than the default action account with a particular module so it can run using the credentials of that identity. Run As Accounts typically map to Active Directory user accounts, and represent an identity that can be associated with a Run As Profile.
Kerrie Meyler, a Microsoft MOM MVP, is an independent consultant and trainer with more than 15 years of Information Technology experience. A previous senior technology specialist at Microsoft, she focused on infrastructure and management solutions, presenting at numerous product launches. More recently, she presented on Operations Manager 2007 and gave several podcasts at TechEd 2007.
Kerrie has worked with Microsoft Learning to develop Microsoft Official Curriculum (MOC) for several courses, including the Implementing Microsoft Operations Manager 2000 course, and did the beta teach for that course.
Kerrie is the lead author of Microsoft Operations Manager 2005 Unleashed and Microsoft System Center Operations Manager 2007 Unleashed
Check out an excerpt from System Center Operations Manager 2007 Unleashed, Chapter 3: Looking Inside OpsMgr.
The opinions expressed in this Weblog are those of the writer and may not represent the opinions of Network World.
|
|
Maybe I'm just moody today
But I am a little offended of "Back when security was simple, a basic security implementation might just be to authorize users to access a particular application." - when was that? Can you clarify a little the time frame?
Yes, it is great that role based authentication and authorization is coming back but it is nothing new.
Back in 70's our management wanted that and got it. It controlled the user terminals, printers, remote connections (yes, there were world wide connections in 70's), transactions, even partial transactions if the user was allowed to see only parts of information or read but not write or not print (on that location or on that printer),etc - all role based.
But it did even more, when the role changed for any reason so did the information the role owner had access, mails(microfilmed in computer format), faxes, files, and so on. It was backed up, secured for auditing, etc. Any private data was separated from corporate data and (at that time) only I had access to that to do what had to be done. If the individual left the company it also generated transactions to system to recalculate new rates, cancel corporate rebates, charge backs for pre-allowances, deleted the user access to any system, cancel access cards, etc. If the individual stayed in company, either old credential were inherited or new credentials for the new role were generated, access card credentials generated, new ID, etc delivered usually personally or some other secure way, etc. And even I controlled the system only HR was able to change the roles, be it a security guard, lawyer or a CxO in our company. Of course, in emergency which actually happened a couple of times I was able to do that middle of the night, HR works 8-5!
And it did work even for development, operations, documentation, QA, etc. You had access to the part you were responsible and it followed the role, today you can only touch that part / read those documents / run those tests / etc but get a promotion and you may have access to much more in seconds (and maybe better discounts of our products, next day on your table with a printaout explaining what your new role really means.)
So, once I see another (large) corporate infrastructure working like that today I will admit that role based security is catching up the old ways. And trust me, it is complicated but not overwhelmingly so if you have the top management behind you. Sorry, I am a little moody but I hate when vendors try to sell something as a total solution when in reality it is only a small part and often doesn't even work with the rest of the infrastructure, and I don't mean just IT infrastructure but business.
Sorry if the rhetorical comment offended you :-|
Maybe I was just being rhetorical. Actually, the next article I was plannig to write about was comparing and contrasting MOM 2005 security with OpsMgr 2007 security. And MOM 2005 security was ... yep, just at the application level. It was slightly better than that, but not much, as there was very limited granularity.
I wasn't meaning to imply that in the 70's etc it was impossible to have granular security (although that was before my time). I know many large packaged applications had their own security, down at the specific transaction level, etc. And systems such as RACF could let you get very detailed in what you limited access to.
As far as vendors trying to sell something as a total solution that isn't even close ... that definitely isn't new - be it software or just about anything else. And as you say, typically vendor "solutions" don't work with the rest of the infrastructure without a lot of tweaks, and often they don't even work with other software by the same vendor! Pretty annoying.
Kerrie Meyler
Post new comment