Mark Minasi's Windows Networking Tech Page
Issue #86 Later January 2010

Document copyright 2010 Mark Minasi; please see below for info on subscribing, unsubscribing or copying portions of this text.

What's Inside

• News
  • Join Me at a Seminar!
• Tech Section
  • Not Ready to Go to R2 Yet?  You Can Use R2's PowerShell Tools and New AD GUI on 2003!
  • Install Today's IE Patch.  Really. Do it.  Now.
• Conferences
• To Subscribe, Unsubscribe, Read Old Newsletters or Change Your Email Address

News

Hi all —

Ever since my Forum buddy Claus pointed out an obscure little download from Microsoft several months ago, I've been enjoying most of the new Server 2008 R2 Active Directory administration tools, even though I've got a 2008-based AD, not a 2008R2-based one.  Hey, it even works on Server 2003-based Active Directories.  There's also one of those once-a-year security patches that you really, really should install TODAY.  Lots to talk about here but first, a word from our sponsor:

Tech Section

Not Ready to Go to R2 Yet?  You Can Use R2's PowerShell Tools and New AD GUI on 2003!

For an "R2," Server 2008 R2 delivered a fairly impressive list of new goodies for Active Directory (AD) techies.  One of the most important of those goodies was Active Directory's new support of PowerShell scripting, in combination with 73 new AD-related PowerShell cmdlets and their GUI cousin, a brand-new administrative tool for AD called the Active Directory Administrative Center (ADAC).  Why is ADAC a "cousin" of PowerShell?  Simple:  PowerShell 2.0, which Microsoft embedded in Windows Server 2008 R2, offers the new ability to create GUI-based PowerShell tools... and ADAC is one of the first of those.  Sure, ADAC looks like a it's just a better-arranged version of the ten-year-old Active Directory Users and Computers (ADUC) MMC snap-in, but on the inside, the two are as different as night and day.

Now, I haven't had time to put an R2 domain controller (DC) on my internal production network yet, but I really like some of the new PowerShell cmdlets and really like the ADAC GUI tool, so I was pleasantly surprised to learn that you can fairly simply bring R2's PowerShell cmdlets and ADAC to any Active Directory running pre-R2 domain controllers.  In fact, you can even retrofit Powershell and ADAC support on domain controllers as far back Windows Server 2003.

The key lies in the fact that under the hood, Microsoft built PowerShell clients to talk to the Active Directory with a completely new network protocol.  Instead of having ADAC and PowerShell make AD requests to DCs via LDAP, ADSI or some sort of RPC, Microsoft built a brand-new web service for Active Directory.  Thus, every time an administrator sits down and issues some command to AD via R2's PowerShell tools or ADAC, then under the hood that PowerShell cmdlet or ADAC actually transmits the admin's request as a pile of XML data packaged in one or more SOAP (Simple Object Access Protocol) packets,  and then transferred via HTTP/HTTPS to the web service program running on every 2008 R2-based Active Directory DC.

Now, I hear a few heads getting ready to explode out there:  "whaaaat???? Our DCs are web servers?  Nooooooooo...."  Relax; R2's DCs are not web servers, they just run a web service.  Those are two very different things, I promise.  Heck, they don't even use ports 80 and 443; instead, they use TCP port 9389, which is easy to remember if you're leery about the whole web service thing, know a microscopic amount of German and recall the port number normally used by LDAP in Active Directory:  "nein, 389!"  Really, you do not have to run IIS on your DC to make this work. 

Anyway, Microsoft decided to take their R2 AD web service and back-port it to Server 2003, Server 2003 R2, and Server 2008 DCs and, once you've done that, you'll be ADAC-ing to your non-R2 DCs.  There are, of course, a few details, mainly that you've got to download and install a bunch of stuff to make it all work, but it's worth it in the end.

First, you'll need a Windows 7 desktop or a Windows Server 2008 R2 member server.  You need one of them because the only way that I know of to get PowerShell 2.0, the AD PowerShell Module, and ADAC is either to be running a 2008 R2 system, or to download the "Remote Server Administrations Tools for Windows 7" (RSAT) from Microsoft's Download Center and you can unfortunately only install RSAT on a Windows 7 system.  In other words, sorry... you'll have to do the AD administration from a Win 7 system rather than a Vista or XP box.

Second, the client Windows 7 system (or 2008 R2 member server) should be a member of the domain that you aim to do your PowerShelling on.  (You could probably make it work otherwise, but it'd be a pain.)

Third, you need a DC that can support the AD web service.  That would be a DC built upon Server 2003 with SP2 or Server 2008.

Fourth, your DC needs .NET 3.5 SP1.  Search www.microsoft.com/downloads for "Microsoft .NET Framework 3.5 Service Pack 1 " and take the download with that exact name, as it's not only an SP1 that you'd add to .NET 3.5 but instead it is .NET 3.5 with its SP1 already installed. 

Fifth, your DC probably needs a hotfix or two.  Apparently there's something about the way that Windows 7 talks to Server 2003 and 2008-based DCs that confuses them, and these hotfixes address that.

• Server 2003 SP2 systems need the hotfix in KB 969429.  You can't just download it, you've got to "request" it.  (It happens immediately and automatically, you needn't talk to anyone for it, but it takes a minute or two waiting for your "request" to be granted.  Perhaps it's a hotfix with mildly narcotic side-effects and thus is unlawful in some localities?)
• Server 2008 SP1 and 2003 SP2 systems both also need the hotfix in KB 967574.  2008 SP2 systems do not need this hotfix.  The page explaining this hotfix seems to indicate that 2003 systems do not need this hotfix, and that KB 969429 and 967574 are either/or hotfixes, but I tested this on a 2003 R2 DC and it seemed to need both hotfixes before I could proceed.

Sixth, you're ready to install the AD web service on those prepared DCs.  Search for the "AD management gateway service" at Microsoft's Download Center, and note that there are four possible choices of files to download depending on whether you're installing it to 2003 x86, 2003 x64, 2008 x86 or 2008 x64.  It's packaged as an MSU (Microsoft update), so it's a simple install.

Now log onto that Win 7 system with RSAT, fire up ADAC and you're ready to go.  Happy PowerShelling!

Install Today's IE Patch.  Really. Do it.  Now.

Here's a very, very important item.  The short version is that today, 22 January 2010 Microsoft released a patch (MS10-002, KB 978207) for a very dangerous hole in IE, and my advice is to install it today.  (Go to Windows Update, it's there now.)

Here's why I counsel the urgency.

You may know that on the 12th of January, Google reported that someone had launched a large-scale attack on their and other people's servers in an attempt to gather information about Chinese dissidents.  Google's specific example was that the attacker tried to access the dissidents' Gmail accounts, but the buzz on the Web has been that whoever launched the attack was pretty successful at gathering a whole boatload of intellectual property.  But how did the Chinese government attackers unknown hackers do it?  The answer arrived a couple of days later in a blog post by McAfee's CTO George Kurtz:  a zero-day IE exploit.

Apparently the problem involves an invalid pointer inside IE.  What that means in English is that this bug, similar to the "buffer overflow" type bugs we saw in Code Red and SQL Slammer, allows a bad guy to reach into your computer and instruct IE to do, well, anything to your computer:  shut it down, delete files, upload some data from your computer to the bad guy, and the like.

Here's a simple example of how this would work.  Let's suppose that Bad Guy wants to keep you from running Solitaire because Bad Guy once lost $10,000 in Vegas on Blackjack and he figures that computer card games like Solitaire are the "gateway drug" that eventually leads to real cards and real bets.  (Okay, it's a silly example.)  Bad Guy does this by creating a Web page with useful information on it like, say, a complete listing of all of the upcoming shows in Vegas.  (See the clever social engineering?  This guy is an evil genius.)  The web page has text explaining the shows; it's got pictures and videos to keep your attention... and a quiet little browser-side script.  Unless you've got your IE security settings positioned at "I trust no one at all"  -- which sounds great until you actually try to access 99% of the perfectly innocent Web pages out there -- then the script is silently downloaded and executed.  (I am simplifying, but this is basically how it happens.)  The script then uses this invalid pointer to hand IE a bunch of code, and tells IE to execute that code. 

Now, in the case of my silly example, the code would say, "ask the system if a process named 'Solitaire' is running and, if so, tell the system to kill that process," but, as I said earlier, this could be any piece of code at all -- delete files, slow down your system, email your mother all of the JPEGs on your hard drive, you name it.  The only restrictions on the code would be that it runs as you, and so it can't do anything that you can't do.  But even the most limited-power user could shut down apps that she was running look in most folders, or access any credit card information she keeps on her computer.  The generic phrase for this kind of attack is called a "run code of attacker's choice," and anything with that ability is very dangerous.

So why's this different from other "run code of attacker's choice" patches?  I mean, we see about a half-dozen RCOACs out of Microsoft a year, right?  The difference is that this is one of those cases where the attackers knew of the IE bug before Microsoft did, and instead of telling Microsoft about the bug, they wrote their own evil, cowardly program to exploit that bug.  It might have gone like this:

1. Write an exploit that says to IE, "hey, if you happen to be on a network that's connected to Google servers and you happen to be an admin on those servers, go grab any Gmail accounts from the following names and post all of their messages to the following server."
2. Package that exploit into a nice little script.
3. Put that script onto a Web page that a Google employee would be likely to visit.  Or, better yet, put it on lots and lots of Web sites to increase the chances of that ideal victim -- a Google admin with access to Chinese Gmail accounts -- visiting the site.  (Of course, I have no idea what people in China would have the power to direct the folks running well-trafficked Chinese Web sites insert this script.  No idea at all.)
4. And... wait.  In time, something good will appear on the "harvesting server."

The good news is that there is a patch, as I've already said. The bad news is that what I know, the bad guys know, and so at this point there are many, many sites all around the world that have been infected that have nothing to do with the original Google attack, and so viewing those sites with a vulnerable copy of IE would do... well, I have no idea what it'll do, and that's the point.  If you are using IE to view Web pages and your IE is not patched, then you could be letting yourself in for anything, and that's not just a hypothetical case because, again, the exploit code is already on the Web.  A bad guy with half a brain can get it running, and lots of half-brained guys want your credit card number.  What's the probability that one of your employees will visit one of those sites?  I have no idea, but it does occur to me that with every second that goes by, that probability increases.  Tick, tick, tick...

Finally, you will read a lot that this only affects IE6, not IE7 or IE8.  That's not entirely true, as researchers have reported that while IE7 and IE8 still have the invalid pointer bug, the result of viewing infected Web pages is more often an IE lockup or nothing at all... but on some systems, exploit code has been made to work on IE7 and IE8.

Upcoming Conferences

If you can't make it to a Server 2012, Windows 8 or PowerShell seminar, perhaps I'll see you at...

TechMentor Vegas

TechMentor returns to Las Vegas this September 30-October 4 and I'll be doing a bunch of talks, so don't miss it!  Find out more at http://techmentorevents.com/Home.aspx.

Windows Connections Vegas

This year, Connections and TechMentor appear in Vegas on the same week!  Connections will be at the Mandalay Bay and they've got an all-star lineup.  Info at http://www.devconnections.com/dev13/public/mainhall.aspx

TechEd

I'll be at TechEd North America and TE Europe this year doing a talk on Server 2012 networking and Windows 8 goodies, if you'll be at either show please stop by!

To Subscribe/Unsubscribe, Read Old Newsletters or Change Your Email Address

To subscribe, visit http://www.minasi.com/nwsreg.htm. To change e-mail or other info, link to http://www.minasi.com/edit-newsletter-record.htm.  To unsubscribe, link to http://www.minasi.com/unsubs.htm. Visit the Archives at http://www.minasi.com/archive.htm. Please do not reply to this mail; for comments, please link to http://www.minasi.com/gethelp.

All contents copyright 2010 Mark Minasi.  I encourage you to quote this material, SO LONG as you include this entire document; thanks.