Retrieve LAPS (Microsoft's Local Admin Password Solution) details using VBScript

History

We've been Microsoft's LAPS (Local Admin Password Solution) as a solution to manage the local administrator passwords on the majority of our servers (excepting domain controllers, for obvious reasons) for a while now. The fact that we'd been living with all of our servers having one or two incredibly simplistic passwords that hadn't changed for the best part of a decade, was giving us so many potential problems, from the ex-employee knowing the all the keys to the kingdom problem, to the straightforward pass-the-hash attack, and LAPS has worked well to mitigate those problems. For our server admins the options of reading the raw password from ADU&C, or using the PowerShell module, or even using the barebones LAPS GUI were fairly straightforward.

The Present

Now we're expanding our LAPS usage to manage the local admin passwords on all of our desktops and laptops. I know that most companies roll LAPS out to their laptops first and their servers last, but the fact that we'd been regularly changing the admin passwords on our laptops and desktops roughly twice a year for years meant that it wasn't needed so badly there.

For our desktop admins, and our helpdesk staff, we can't just point them at the installer for the PoSh module and leave them to it, so we're giving them the LAPS GUI client, but also integrating LAPS password lookup into some of the existing tools that we provide them. This means that I needed to retrieve the LAPS info using VBScript, rather than PoSh, to integrate into one of these tools. All of the examples in the LAPS documentation, and in everyone else's web write-ups of LAPS, use PoSh, so I had to pull this together from a few other scripts and tools that I'd used.

Download

Download the script here: GitHub: LAPS-Password.vbs

Find objects within folders in the SCCM Console hierarchy using PowerShell

Frustration

Ever since Microsoft's SCCM got the new-style System Centre console with SCCM 2012, I've been massively frustrated about how difficult it is to find items in the console once you've organised it with folders. Probably not too much of a problem if you're a lone SCCM admin, but as someone who works as part of a larger team who all use SCCM for slightly different reasons it can be a nightmare finding things like collections buried deep in the folder hierarchy.

Yes, I know that the console has a search function, and I know that there's a subtle "All Subfolders" button that magically appears on the Search ribbon bar sometimes. However that "All Subfolders" button has a few major flaws: 1) it doesn't always appear when it ought to, leaving you in a dance of clicking in the search text box, clicking away, clicking back in there, clicking away to another part of the console, clicking back, all the while crossing your fingers that the button will show up; 2) annoyingly clicking the "All Subfolders" button clears out any text that you may have foolishly typed into the search bar already before you remembered that you wanted to search the whole tree; 3) most importantly, the search results don't give you any information about the folder path that it found each item on, so it doesn't help you find that item (or similar items that may be in the same folder) quickly next time.

SCCM console rant over.

Journey

So over time I started casually looking around for ways to access this folder hierarchy info. These days there's a regularly updated set of SCCM PowerShell Cmdlets provided by the ConfgMgr team, this seemed an obvious place to start. Unfortunately, none of them even acknowledge that console folders exist. Next I set off on a hunt through WMI on the site server (using one of my favourite tools WMI Explorer (WMI Explorer downloads), but I couldn't any folder related properties on the collections/packages/etc themselves and couldn't find any obvious looking WMI classes. Real desperation now, open up SQL Management Studio and hunt through the Views in the site database. Nothing obvious. Brick wall hit. I went away and worked on other stuff for a while.

Enlightenment

Then early last week I came across this blog post by Peter van der Woude, that my previous searches had somehow missed: More than just ConfigMgr: Get the folder location of an object in ConfigMgr 2012 via PowerShell. Finally, answers - not only did that post contain this magic phrase: A good thing to know is that all folder information is stored in two classes in WMI, SMS_ObjectContainerNode and SMS_ObjectContainerItem. These two classes are the same for every object type., but it also had a working script linked, find his script in the TechNet gallery here: TechNet Gallery: Get the location of an object in the console via PowerShell

Moving Beyond

As great and useful as Peter's script was, it does have a minor flaw, and doesn't handle some edge cases. So I set off to use his information to write my own. The minor flaw was that his script requires hard coding your SMS Site Code and Site Server names into it. I can see the reason for that, especially as it means that his script has no external dependencies (other than the ConfigMgr infrastructure, obviously) but it still bugged me. More problematically, I hit an edge case that it didn't handle within my first few uses of it. Some objects (of different types) in SCCM can share the same SCCM IDs. So a Collection, a Query and a Package could have the same 8 character ([site code][5 hex digits]) ID, as all of those objects have their own numbering starting from XXX00001 and counting upwards. So using Peter's script, you don't always find the object that you're actually looking for, and, as his doesn't echo the name or type of the object that it's showing the hierarchy for, it can get quite confusing if it's not showing the info for the item that you're expecting.

Nirvana (or Farvana)

So, I've written my own PowerShell function to do this: Get-SCCMObjectLocation, find the code on GitHub, here GitHub: Get-SCCMObjectLocation.ps1. There's a bit more code here than Peter's versions, but this now outputs the object's name and type (so that you know you haven't made any typos, and you really have found the droids object you were looking for), and if there are multiple objects with the same ID, it lists them one by one. It also gets the site code and site server name from the ConfigurationManager PowerShell provider, though this does mean that you need the SCCM console installed on your machine, and you need to change to ConfigurationManager's PSDrive before running it.

Usage:

PS C:\>Get-SCCMObjectLocation -SMSId "ABC001BB"
root\Racked Server Drivers\Dell\PE1950-Microsoft Windows 2008 R2 SP1-OM7.3  [SMS_DriverPackage]

PS C:\>"ABC000CC" | Get-SCCMObjectLocation
WARNING: Multiple objects with ID: ABC000CC
root\x64\Test\Win 7 Ent x64 with Office 2010  [SMS_ImagePackage]
root\Servers\Server roles\All Domain Controllers  [SMS_Collection_Device]

PS C:\>Get-SCCMObjectLocation -SMSId "ABC00166" -SiteCode ABC -SiteServerName sms01.example.com
root\Application Deployment\MS Access App-V  [SMS_Collection_User]

Download

Download the script here: GitHub: Get-SCCMObjectLocation.ps1

---

Music to get through this with: Faithless - Faithless 2.0

Active Directory Group Membership Queries

The problem with being known as the person who can pull a list of group members from AD into a text file in a few seconds, you become a "go-to guy" for other AD queries. Which wouldn’t be such a bad thing, except that there aren't pre-written scripts for them all! I received a request today to ask if I could pull out a list from AD of everyone who was a member of both a departmental group and a security group, here's how I did it.

List the Members of an AD Group

For anyone who doesn't know already, there are a couple of easy ways that I know of to print a list of the members of one active directory group to a text file:

The "Command Line One-Liner"

As always with something that looks simple you need to put in a little work first, this time it’s very easy. First download the very useful psExec utility from the Sysinternals website. This handy little tool lets you run commands on a remote machine as if you're logged directly onto it. Extract that and save it somewhere, preferably in your path.

Now all you need are a few bits of information that you should already know if you’re thinking of running this sort of query: the name of a domain controller on your network, and the username and password of an ID that has admin rights on that DC (unless your normal login account has these rights, in which case you really ought to do a security review ;-) ).

Then run the following command from a command prompt:

psexec \\domain_controller -u domain_slash_userid -p password net group "group name"

This will list all of the group members to the command prompt, to redirect this output to a text file, just add "> c:\temp\groupmembers.txt" to the end, eg:

psexec \\domain_controller -u domain_slash_userid -p password net group "group name" > c:\temp\groupmembers.txt

The VBScript (or Perl) Method

Go to the Active Directory Cookbook's Source Code page and download Script 7.2 "Viewing the direct members of a group" in VBScript format (or Perl if you have Perl installed and are more comfy reading that).

Save the script somewhere, open it up in Notepad and replace the <groupdn> bit with the path to your group. Now change to a command line and run either:
"cscript View_Group_members.vbs" (for the VBScript version) or
"perl View_Group_members.pl" (for the Perl version)

While it is possible to just double-click either file in Explorer to run them, you don’t want to do that; the VBScript version will pop up an alert box on screen for each group member (meaning if you have a group with 100 members, you’ll get 100 alerts on your screen one after the other, each one wanting you to click OK), whereas the Perl version will dump its output to the command line then close the window before you have time to read it. So drop to a command line to run them.

If you want to send the output to a text file then (as above) just append a right facing angle bracket and the name of a text file, eg: cscript View_Group_members.vbs > c:\temp\groupmembers.txt perl View_Group_members.pl > c:\temp\groupmembers.txt

Listing Everyone Who is Both a Member of Group A and Group B

(intersection of groups A and B)

Now listing everyone who is a member of both Group A and Group B is slightly more difficult, and I couldn't find a script online that pulls that out for you - so I wrote one myself. This is a Perl script as I've known Perl for years, and whilst I can read simple VBScript fairly well I wouldn't want to try writing it. So if you want to run it you’ll need to have a version of Perl installed, I can recommend ActiveState’s ActivePerl (see below for download instructions).

This is an adaptation of the above Perl script (http://rallenhome.com/books/adcookbook/src/07.02-view_group_membership.pls.txt for anyone who hasn't downloaded it yet) that pulls out the members of the two groups, hashes them, then prints the intersection to the command line.

The fine print at the bottom of the Cookbook's source code page seems to suggest that it’s ok to modify and distribute the code as long as the acknowledgement and citation are kept intact. So you can click to download my "Viewing the intersection of members of two groups".

---

Note 1: Downloading ActivePerl

• Go to http://www.activestate.com/Products/ActivePerl/
• Click Get ActivePerl
• Select Free Download
• Click "Continue" (no need to fill out the form if you don’t want to)
• And choose a download format.
• Save and install

(Note to self: see also Kbase 1027070447)

At last they're mine!

Remember way back when when I entered the MSN World's Best App competition with my Connect Four game?

Remember just a few months back when the winners were announced?

Well... my second place prizes have (finally) arrived! I'm currently playing around with my Oakley Thump sunnies, loading them up with music and looking just slightly silly :).

Also included in the prize is a nice, shiny copy of MS Visual Studio 2005 Pro (worth more than the rest of the package put together) and every Oakley Thump accessory available (but one). Its like Christmas came in May!

Looks like I'm going to be wearing my sunnies everywhere I go for the next week or two come rain or shine.

Just gotta finish by saying W00t new goggles! Thank you Microsoft!.

Maximum w00tage!

So MSN just announced the winners of their World's Best App contest today (or maybe late yesterday, can't do these timezone calculations in my head

Have a look down the list of winners, see that game in 2nd place called Connect Four? I made that

Edit 11/2/06:
Looks like its official! The official "Inside Windows Live Messenger" blog has just posted an article on Messenger’s Worlds Best App Contest Winners.

The most useful tool ever?

Microsoft XML Diff and Patch 1.0

Alright, maybe its a bit of an exageration, but this really did save my bacon the other day, and it is very useful if its what you need and things are formatted badly enough that WinDiff can't help you.

Play Connect 4 in MSN Messenger!

My first entry to the MSN World's Best App competition, an online, multi-player version of the classic Connect Four game, has just made it through the checking process and is now live on MSN!

Please try it out, have a game with me, or anyone else you know on Messenger: Just click here to play multiplayer Connect Four! (requires Internet Explorer and MSN Messenger) Please play it as much as you can, and if you have any comments, questions about it or problems with it I'd be very grateful if you could please leave me feedback on my MSN Space.

Thanks, and please play it as much as you can, every time you launch the app counts as a vote for me :).

Oh, and if you've got your own MSN Space and you'd like to spread the word, just click the BlogIt! button to put it straight on your Space.

MSN Compo Entered!

Have finally got round to submitting my first entry to the MSN Messenger World's Best App Contest. Thanks to everyone who's helped me out with the testing of this one and the little test apps, especially the people who pointed out my bugs mistakes deliberate errors.

Just got to wait for it to appear now, and see how the world takes me!

So, Javascript is a workable programming language!

I've used a fair bit of JavaScript code in the past to add client-side flourishes to web-pages and build simple, calculator-style apps, but I've never really done anything very complex with it before.

I think that probably the last time that I tried writing any serious kind of an app using JavaScript was back in the Netscape 3/IE 3 days, and it was very, very painful. Since my apparently futile attempts to work around myriad browser bugs, implementation differences, browser differences, DOM differences (not that I even really knew what a DOM was then, did people call them that then?) and so on, I've stuck to simple work with form boxes, style changes and simple things like that.

Then came the MSN Messenger World's Best App competition, and I'm suddenly in the middle of building a really fairly complicated platform for building simple multi-player internet games, and I'm doing it all in JavaScript. Well, I might eventually build in a bit of server-side persistance with Perl, but that's going to be completely independent of the client-side bits and only really for providing the icing on the cake (I'm even thinking of implementing save-game client-side rather than saving on the server).

So obviously one of my first unconscious choices was, just how hard can I make this for myself? Well to answer that I took a look at my favourite web testing platform: Gecko/Mozilla and realised I couldn't do without all the amazing development, testing and debugging tools it gives you, and decided that I was going to make the core of the program totally cross-browser (obviously this can only go so far with an app that is going to eventually use the MSN Messenger API for cross-internet comms, but I'll be going right up to that line). So we have hurdle one, it must work in both IE5 & 6 (as per competition rules), and Mozilla (to allow me to use my favourite tools) and also Opera (as I didn't feel like leaving it out)!

Next choice, if I'm going to make it run on all three web browsers it had better use standards as far as humanly possible (so that theoretically compatibility should just work, no giggling at the back there!), and if I'm going to code it to W3C/ECMA standards, then there's no point in going half-measures, so no browser specific coding allowed. If it's being coded to standards, without any browser-specific code, then why not pick a decent standard? So XHTML 1.1 loose it is (and by that I mean also testing with an XML MIME type to trigger the totally intolerant strict XML processing mode in Mozilla browsers).

Quick summary of choices made simply to make my life harder, but also more challenging and interesting:

1. All parts not dependant on the MSN Activity API must work in:
   • IE 5 & 6
   • Mozilla/Firefox
   • Opera
2. Stick to standards, no browser specific hacks or code paths
3. XHTML 1.1 loose doctype
4. Must also work when served to Mozilla with an XML MIME type.

So, I'm not getting much sleep lately!

Thoughts on default and recommended security modes and what it reveals about the people expected to use the systems.

When you have a large network, with a large number of servers, and a number of network/server administrators there essentially two different ways to set up the supervisor/administrative rights and which route you go down reveals a lot about your overall philosophy.

Method 1: Restrict each person's network rights to exactly what they need for day-to-day work and precisely no more. If they do need to do anything else they can use a specific administrative account (or supervisor account, or superuser depending what world you inhabit) to carry out their business.

Method 2: Give all of your administrator's network accounts full administrative privileges to each resource that they might need (or even everything depending on the size of the network, and the person's role).

There are definite advantages and disadvantages to each approach.

Method one means that your admin's own network accounts only have limited rights, this means that they are a less worrying vector for viruses, they're less likely to cause catastrophic problems by accidentally clicking the wrong thing and you can control who needs the passwords for various resources.

The downside is that you can't control who knows the passwords, someone extra will always need it for some reason, or will notice it whilst it is used for some othert reason and you can only control it by regularly changing your admin passwords, and keeping a (secure) database of them all.

Method two means that you can audit who did what, every admin level action on the network will have an actual person's own ID against it, it means that work for admins is less of a hassle: less passwords, less logging in and out all over the place with 30 different passwords, less time spent performing quick and easy tasks.

The downside is that if any of your admins happen to become infected by a virus, or are simply having a bad day and making an awful lot of mistakes, then they can wreak havoc on an unparalleled scale.

From what I've seen experienced, method one is the method that pretty much every network admin training course reccomends, and most Linux/Unix networks actually carry out ("su" is your friend) whereas despite the official guidelines most Microsoft based shops tend to either be configured as method two (or a mixture of the two).

What really annoys worries me about Windows XP are its silent failures.

I've been using XP Home edition on my personal laptop for about nine months, and I've been using XP Professional at work for four or five months. During this time it's had its little quirks, annoyances and, I'll even grant, it's moments of brilliance and overall I've learned to tolerate it as an operating system, maybe even learned to like it in some ways.

However the one thing that has really made me reserve judgement on it are the silent failures it seems to have at the quirkiest of moments.

What do I mean by silent failure?

I mean all those times that you try to do something, and nothing ever happens: there's no visible feedback, there's no error message, and most of all it just doesn't work.

As an example I regularly use two different applications as part of my job, to protect the (mostly) innocent we'll call them app A and app B. Now I really use these, push them hard and so I've discovered a couple of sure-fire ways to crash them both, this isn't a real show-stopper because both apps have more than one way to accomplish these particular tasks, so I can just avoid the problem and try it the other way.

The thing is that I discovered all of this running the apps on my Windows 2000 box. When app A crashes on my old Windows 2000 box its screen image freezes up, and then 5-30 seconds later up pops an error message, such as "App A: invalid aaaa to bbbb in cccc. [OK]", so I scan the frozen screen image to double-check the reference that I was working on, click [OK], restart the app and carry on working from that reference again. App B's crashes are similar, except it also writes something to the Windows error log as well as giving me an on-screen error message.

Under Windows XP the crashes are slightly different, I'll be happily working away in the app, then, without thinking, I'll click the button that I know will crash the app, and just as the ONM hits, the app just disappears from the screen. No frozen image left on-screen. No error message. No feedback whatsoever, its like it never existed. There are even a few tasks within Windows XP and Explorer itself that can trigger this behaviour (such as assigning groups in the ADS rights to folders and shares in the NTFS file system on a server through the local Windows Explorer) so its certainly not just a problem with 3rd party apps.

I'm sure when the Microsoft programmers demoed this to their managers that everyone starting giving out mutual back-pats and congratulations, "Look, no error messages, so no one can complain any more that Windows is riddled with bugs and freezes all the time!"

Unfortunately no one stepped back from the whole self-congratulatory circle w--- and thought, "Well maybe people will want some feedback when jobs fail? If only so they have a clue what to do/not do next time?"

It's a triumph of marketing over common-sense, and it really signposts some of the thinking behind a lot of Windows XP's interface and features.

If they don't absolutely need to know it, or it might make us look bad if they see it, then hide it from them at all costs.