Document copyright 2010 Mark Minasi; please see below for info on subscribing, unsubscribing or copying portions of this text.
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:
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.
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
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:
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.
None at the moment... fingers crossed for TechEd!
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.