Anatomy of a view

I posted this over on Technet Forums, but I figured it would be a good idea to archive it here as a reference. I’ll probably be doing this a lot more, At least until a pay the Aaron back for Helping Me

The question came up how to Copy a view. this gave me a good opportunity to drone on a bit about how a view works in XML, and what each part means, at a high level. Forewarned: we’re going to get dirty and crawl into the XML.
(more…)

Advertisements

Things Service Manager needs

In light of The Phoenix Post over at Technet blogs, I figured now would be a good time to start recording things I wanted to see in SM. This is my running list of improvements, advancements and enhancements that I want to see in service manager.

It should be noted that I don’t think any of these are required or essential. Service Manager is extremely flexible and has the ability to compete with the best ticketing systems on the market. Moreover, it’s the only ticket system (to the limits of my knowledge) that is both strongly typed enough to implement ITIL best practices, and flexible enough to allow companies to completely ignore them. That being said, it’s also kinda rough in some places, and these are the places I want to see polished for Service Manager V.Next: (more…)

Why Orchestrator is incredible and I will probably never use it.

System Center Orchestrator is a wonderful product; A visual automation tool with arbitrary integration into dispirit systems that allows vendors to define high-level tasks that can be bound together into business specific automation packages that can react to changes in the environment. The use case for a global integration system is huge, and a well supported automation system has massive benefits to every organization. What’s not to love?

well, I have a few issues with Orch: (more…)

Role Based Security, Part 4 of 4

This is the fourth part in the continuing story of Bob, a builder, our example of Role based security in a realistic example general construction contracting company. Take a look at Part 1 to get an understanding of the basics, and Part 2 to look at cases where job roles don’t align, or Part 3 where we look at promotions and transfers.

The Audit:

And now it’s inspection time. Mr. A E Pessimal is here from the audit firm to check our SoX compliance. A E is an old fashioned guy, and it takes a bit of doing to explain the new security model, but A E also does financial auditing, so he can easily equate this to the role model used in most ERP/MRP/Financial system security (especially oracle). Once A E is on-board with job role definitions, this makes the job A LOT easier.
(more…)

Role Based Security, Part 3 of 4

This is the third part in the continuing story of  Bob, a builder, our example of Role based security in a realistic example general construction contracting company. Take a look at Part 1 to get an understanding of the basics, and Part 2 to look at cases where job roles don’t align.

Promotion:

Bobs been an excellent employee, and he’s showing particular skill with blueprints, so Mr. Vila transfers him over to the architects group as an apprentice to Frank. This means that he’s no longer a builder, and is now an architect. But hang on, Bob has a bunch of other security that may or may not be right. 
(more…)

Role Based Security, Part 2 of 4

This is the second part in a series on Job Role Security. Bob is a builder, working for Mr. Vila on the builder team, and bob is our example of Role based security in a real company. Take a look at Part 1 to get an understanding of the basics.

The Certificate Case:

OK, so Bob has been on the job about 6 months, and he’s just passed his hazardous materials handling course, and he’s now allowed access to the insulation shed.  (more…)

Role Based Security, Part 1 of 4

One of my favorite management concepts is Job Role security.

The core of job role security is the logical extension of Role Based Access Control that comes from aligning job function (more specifically task oriented work groups) to security rights.   This alignment both accelerates IMAC operations and reduces complexity of compliance events by directly relating the majority cause of permissions changes to the resulting effective permissions. It’s a methodology for concrete tactical security based on a heuristic simplification of implied access, but it’s rarely implemented (probably because it is based on heuristics, not on definition or queried permissions, which are both easier to CYA).

This concludes the buzzword portion of our broadcast.

In simple(-er) English, it means that the access a user is granted by the company is connected to the job that company has asked them to do.

  1. We have hired you to do job A.
  2. Job A requires access rights B.
  3. Therefore we will grant you the access rights B as long as you are doing job A

(more…)