Running LAPS around local admin credentials

In case you didn’t hear about it, Microsoft released a new tool for management of the Local Administrator passwords for domain joined machines, Local Administrator Password Solution (LAPS) (Support KB, Download page).

This solution is configured via GPO, and causes EACH MACHINE to check the local admin account’s password expiration, and if it’s expired the machine will randomize its own password, and then store the new password in AD! Quoted from the Technet release page:

LAPS stores the password for each computer’s local administrator account in Active Directory, in a confidential attribute in the computer’s corresponding Active Directory object. The computer is allowed to update its own password data in Active Directory, and domain administrators can grant read access to authorized users or groups, such as workstation helpdesk administrators.

After years of telling us to simply disable the local admin account, and pretending domain trust failures didn’t happen, they’ve finally bit the bullet and are now offering a way to simply and easily automate local admin password management. In a single stroke, this solves three or four major security risks for domain joined machines, and automatically handles the largest source of panic admin credentials, the management of which is normally a giant manual hassle for IT departments.

MS seems to be keeping this quiet. I heard about it from the SANS Internet Storm Center Daily Stormcast podcast this morning, who apparently found it 4 days after release by trolling new articles in the Microsoft Security TechCenter.


On Variable names

So Brody, a college of mine, wrote a script to pull the entire history of a work item and all related work items. Those of you who do auditing in service manager, your ears are probably burning right now. This is an incredibly useful feature in the relational object data model that service manager implements. The ability to see, at a glance, all of the edits to a combination work item (like a change request and all of it’s component activities) is SUPER VALUABLE. He asked me to look over the script before he published it.

To paraphrase Joss Whedon; I am very smart. So when I say Brody is almost 10 years my junior, and he has a deeper grasp of the database and low level functionality of Ops Manager and Service Manager then I could hope to develop given those 10 years over again, I want you to take my full meaning.

Next is the bit where I start dumping on him.

The script he sent over was terrible. oh, It worked perfectly and functioned like a charm! but I couldn’t tell you why or how. It’s full of code segments like this:

  $item1 = New-Object PSObject
  $item1 | Add-member -type NoteProperty -Name 'Property' -Value $oldRel.Name
  $item1 | Add-member -type NoteProperty -Name 'OldValueorRemove' -Value $OldObject
  $item1 | Add-member -type NoteProperty -Name 'NewValueorAdd' -Value $NewObject
  $Propa += $item1
  $item1 = $null

There is no way I could tell you what the objective of this code block is. It LOOKS like he’s building a custom PowerShell object, and inserting several key-value pairs, but why this array of members instead of a Hash Table? what does $Item1 mean? If you saw that somewhere else in the code, would you be able to tell what was supposed to be in that variable?  what about $PropA and what’s it’s data type? why are we building this array of custom object anyways?

Code is a language; a way of representing a set of ideas and communicating them. Computer code is a dual purpose language: Your source needs to communicate it’s intent to both the compiler/interpreter/machine, and to other programmers who need to understand, maintain and modify it.

The machine may have no problem understanding the purpose and difference for the variables named $H and $HH, but I can’t. Without that understanding, I can make no comment on if they’re being used effectively, correctly, or meaningfully.

The following two code segments are functionally identical:

  $a |% { if ($_.P) {$b+=$_ }}
  # this takes an input array, looks at each item
  # verifies it has a property Printable that is true
  # and then adds it to the output
  Foreach ($Element in $InputArray) {
    If ($Element.Printable -eq $True) {

But it should be clear which is preferred, and why.

Yes, I know, I use Egyptian brackets. I’m bad. it’s an old habit I developed programming in original basic in high school, where IF statements were declared with English-ish keywords, rather then proper brackets, so i just got used to the condition being on the same line as the code block.

Dependancy Inversion in Service Delivery

My college over in Application Development published a blog post on the corporate blog on the Dependency Inversion Principle, and the benefit of applying this to API contracts. I do a lot of work in System Center Service Manager, which is unsurprising to anyone who has seen this blog, and this post got me thinking about the social contract between service desks and the user base.

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.

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.


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. 

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