Mark Minasi's Windows Networking Tech Page
Issue #49 August 2005

To subscribe, visit http://www.minasi.com/nwsreg.htm. To unsubscribe, link to http://www.minasi.com/unsubs.htm. To change e-mail address, switch between HTML or text format, etc., link to http://www.minasi.com/edit-newsletter-record.htm.  Visit the Archives at http://www.minasi.com/archive.htm.  Please do NOT reply to this mail; for comments, please link to www.minasi.com/gethelp.  Document copyright 2005 Mark Minasi.

What's Inside

  • News
    • New CD Set At a Great Price
    • The Security Class is Now Two Days
    • Active Directory and Security Classes in DC This November
    • Join Us At the Forum!
  • Tech Section
    • Can't Get Setup To Format Your Disk?  Use Recovery Console
    • Auditusr.exe:  Fine-Tuned Security Logs
    • Using Security Templates?  Use /generaterollback
  • Conferences
  • Bring a Seminar to Your Site

News

This month brings two articles on little-known but very useful tools built right in to XP and Server 2003, and a tip on how to partition and format a new system's hard disk without having to install an operating system.  If you've ever turned on security auditing but gave it up when you saw how huge the security logs were then you'll love auditusr.exe, and if you've ever wanted to apply a security template, but were a little queasy about not being able to un-do the template if it broke something then you'll really like 2003's /generaterollback feature; I cover them both this month.  But first, a word from our sponsor...

New CD Set At a Great Price

I try to keep the marketing stuff to a minimum but I've got a lot to tell you -- it's amazing how much work gets done when I can get off the road for a while! -- so I'll keep each of these items short.  First, you may know that I do a huge (93-slide) presentation on the built-in SMTP server that's in NT 4, Server 2000, XP and 2003.  The documentation on it is woefully scanty and it is absolutely essential that anyone doing anything e-mail-wise know about this neat tool, as every Exchange server uses it and you can also use it as a backup e-mail receiver, a kind of e-mail firewall for your Exchange servers, and, well, lots of other stuff.  Now that talk's on two CDs and I want everyone to own a copy, so I've priced it at $29.95.  Find out more at www.minasi.com/smtpaudio.htm.

The Security Class is Now Two Days

The Security class has been busting out of its one-day time frame so I finally got the chance to crank it up to two days.  It's coming to DC in November or I can bring it to you.  The new outline is at www.minasi.com/secoutln.htm.

Active Directory and Security Classes in DC This November

I'm trying to stay off the road so I can start working on Server R2 and Vista books, but a fair number of folks have kindly asked for another seminar... so here goes.  The only public seminar I will do for the rest of the year will be in Washington, DC at the Marriott near George Washington University this November 14-17.  I'll be running the Active Directory class and the Security class.  The Security class outline is at www.minasi.com/secoutln.htm, the Active Directory class outline is at www.minasi.com/2003outln.htm, and you can find the seminar registration page at www.minasi.com/pubsems.htm.

Join Us At the Forum!

In case you've never visited, I host an on-line technical forum at www.minasi.com/forum.  We just celebrated our third birthday -- come on by and visit.  A whole bunch of really smart and helpful people hang out there.  Come on by with a question or, better, come answer someone else's question and be a hero to some needy soul!

Tech Section

Can't Get Setup To Format Your Disk?  Use Recovery Console

When I tried to install the recent beta of Windows Vista in a virtual machine, I found that I couldn't convince Vista's setup routine to partition and format the virtual machine's disk.  Hey, it's Beta 1, and besides I was installing it in a VM, so no wonder, right?  Apparently to get Vista to install in a VMWare VM, you've got to install it on an already-formatted disk.

So how to do that?  I almost installed XP in the VM just so I'd have a disk formatted, but that'd take a serious amount of time.  But then I remembered Recovery Console.

I don't know why it is, but I've run across a few hard disks that 2000 or XP's Setup routines can't re-partition and format.  The textual portion of Setup looks like it's working, but just when it looks about finished formatting, you get an error saying that the disk isn't suitable for XP.  In each case, however, I've been able to get XP on that disk with only a little extra work.  The trick?  Just boot the XP install disk and start up Recovery Console.  You then have the commands DISKPART and FORMAT to partition the disk and format it.  Works great for troublesome XP installs, and it solved my Vista problem as well.

Auditusr.exe:  Fine-Tuned Security Logs

We all know that we should adjust the Audit Policy section of our group policies' Windows Settings / Local Policies / Audit Policy component, and to look at our Security event logs regularly, right?  Okay, how many of you do it?  C'mon, now, tell the truth... many of us don't bother with either audit policy settings or Security log because there's so much darn stuff in the Security log.  For example, I like having the wealth of information that I get from auditing both success and failure in logon and account logon events, but finding useful stuff by looking through the logs even on a small network like mine is often about as easy as finding an honest politician.  I don't really care if and when Janie or Johnny logged on; I want to see when someone's tried to log on as Administrator, or perhaps as one of those worrisome service accounts.  But turning on auditing of success and failure in group policies offers no fine-tuning: either the fire hose is on, or it's off.

So it's deluge or drought ... unless you're running XP Service Pack 2 and 2003 Service Pack 1, that is.  Because they include a command-line utility called auditusr.exe that lets you pick and choose what to audit on a per-user basis.

Auditusr Overview

Auditusr lets you turn on security auditing for just some small set of accounts or, inversely, it allows you to audit everything except some small set of accounts.  Basically, here's how it works.

  • To only audit a small set of accounts, then leave auditing turned off in group policies, but then use auditusr to tell your system to audit particular user accounts (not groups, unfortunately). 
  • To audit everyone except for some small set of accounts, then turn on auditing in group policies, which would normally audit every user account, and then use auditusr to exempt particular user accounts.

It's a pretty neat tool and I'm already finding uses for it.  But before we get too excited about auditusr, let's understand its limitations.

  • This only works on XP SP2 and 2003 SP1 or later; you can't make it work on earlier OSes.
  • As I mentioned before, it only works on user accounts, not user groups.  (Ever noticed that more and more things in the Windows world don't support groups, like quotas?  Seems like a bad trend, y'know?)  On the plus side, however, it can track machine accounts.
  • As far as I can see, there is no easy way to deploy this across an enterprise short of login batch scripts.
  • If you opt to enable auditing in group policies and then exclude particular accounts, you cannot exclude the Administrator account.

Auditusr Syntax

That's not so bad a set of limitations.  Here's the syntax for auditusr:

auditusr function accountname:what-to-audit

Where

  • function is what you want audituser to do: audit successes regardless of the group policy auditing settings, audit failures regardless of group policies,  not audit successes regardless of group policies, to audit failures regardless of group policy, to import or export per-user settings, or to remove per-user settings.  We'll auditusr's functions in detail a bit later.
  • accountname is, not surprisingly, an account name (computer or user).  It'll take simple names like "Jane" if they are local accounts, or names like mydomain\Joe if you need to specify where Joe's account is, or Active Directory logon names like sally@bigfirm.com. 
  • what-to-audit is one or more of the familiar auditable things -- system events, logons, policy change, etc.

Auditusr supports eight functions:

  • /is: audit a success for a particular account even if it’s generally disabled in GPOs.  For example, to say that I want the account mydomain\mark's logon successes audited whether the GPO setting turns on logon auditing or not, I'd type
auditusr /is "mydomain\mark":"Logon/Logoff"

And I'll tell you what works besides "Logon/Logoff" in a bit.

  • /if does the same thing as /is, but for auditing failures -- /if says to audit a failure for a particular account even if it’s generally disabled in GPOs -- /is and /if are, then, "include successes" and "include failures"
  • /es: do not audit a success for a particular account even if it’s generally enabled in GPOs.  So, for example, if I had my GPO settings arranged so that I was tracking account management success but didn't care about any account management referring to a local account "Mary" then I would type
auditusr /es mary:"Account Management"

Notice that I did not have to surround Mary's name with quotes, as it didn't contain any spaces, backslashes or the like.

  • /ef: do not audit a failure for a particular account even if it’s generally enabled in GPOs -- /es and /ef are "exclude successes" and "exclude failures."
  • /e filename exports all per-user auditing settings so that you can then use...
  • /i filename imports per-user settings.  This first wipes out any existing per-user auditing setting.  The export/import files are simple ASCII, so I guess that one way to spread per-user settings would be through an auditusr /i command in a login batch file, although that'd be a bit clumsy to set up.
  • /r accountname removes all per-user audit settings that refer to a given account
  • /r removes all per-user audit settings
  • And I should mention that specifying no function causes auditusr to just display every per-user audit setting on the system.

What can you audit?  The same as you see in the Audit Policy folder of group policies:

  • System Event
  • Logon/Logoff
  • Object Access
  • Privilege Use
  • Detailed Tracking
  • Policy Change
  • Account Management
  • Directory Service Access
  • Account Logon

You've got to type those audit targets exactly as you see them above and surround them with double quotes, although the case doesn't matter. 

Auditusr Example Applications

Let's take auditusr out for a spin to see how it works.  We've already seen a couple of simple examples; let's look at few more complete ones. 

Audit Just One User

Suppose I want to audit logons and logoffs as well as account logons for a user named Mark; let's also suppose that his account is a local account on a machine named X1000.  I'd like to audit logon successes and failures for Mark, even if we've got logon/logoff and account logons disabled in general via group policies.  Breaking this down, then, we want to do four things:

  • Audit logon/logoff successes for x1000\mark
  • Audit logon/logoff failures for x100\mark
  • Audit account logon successes for x1000\mark
  • Audit account logon failures for x1000\mark

We can accomplish this with four separate commands.  The first one looks like

auditusr /is "x1000\mark":"logon/logoff"

Note the "/is" option, which says "audit successes even if the group policy settings says not to bother.  Note also that I've typed Mark's account as "x1000\mark."  Let's assume, however, that I'm typing these auditusr commands right on the X1000 system, so from this point on I'll skip the "x1000\" prefix.  Next, there's the command to audit logon/logoff failures for Mark even if group policies says not to bother with auditing logon/logoff failures.  That looks like

auditusr /if mark:"logon/logoff"

Notice that the only difference is that the "/is" -- "include successes" -- option becomes "/if," or "include failures."  To finish, we just create the same commands again, substituting "account logon" for "logon/logoff:"

auditusr /is mark:"account logon"
auditusr /if mark:"account logon"

But actually we needn't have typed four lines; auditusr lets you stack up more than one area to audit.  So we could have alternatively typed just two commands:

auditusr /is mark:"account logon","logon/logoff"
auditusr /if mark:"account logon","logon/logoff"
See Your System's Current Per-User Audits

That all seemed good, but auditusr's idea of feedback is not to produce any output at all when things are fine.  On the one hand I appreciate its close-lipped nature, as I often find garrulous applications annoying, but on the other hand there's often what might be called a Cool Hand Luke aspect to computing... "what we here is a failure to communicate."  (In case you've never seen the movie, the line is most effective when spoken in a slow, intimidating, obnoxious drawl.)  So it's always nice when you can ask a computer, "what do you think we just did?"  We can do that with auditusr by just typing "auditusr" without any options.  That'll spit back all of the per-user auditing options that it knows of, like so:

C:\>auditusr
Auditusr 1.0
X1000\Mark:include:success:Logon/Logoff,Account Logon
X1000\Mark:include:failure:Logon/Logoff,Account Logon
C:\>

Notice that auditusr already knew about that "put more than one thing to audit on the same line" thing.  Unfortunately, that's all that we can do to reduce our work with auditusr -- we can't put, for example, "/is /if" on the same line, nor can we stack up a lot of user accounts on one line.  (Which makes the fact that you can't use this with groups even more annoying.)

Export Per-User Settings

Now suppose I'm decommissioning this system because I've got a new computer, but like my per-user settings.  Here's how to export them to an ASCII file for easy importing to the new system.

First, run auditusr with the /e option followed by the name of a file to export the per-user settings to:

auditusr /e c:\pesettings.txt

Once that runs, take a look at the file and you'll see that it's formatted identically to the output that we got from just typing "auditusr" all by itself.  Copy the file to the new system and import the settings like so:

auditusr /i c:\pesettings.txt

You can then erase the pesettings.txt file.

Remove All User-Specific Settings

Finally, suppose you want to remove all per-user auditing settings?  That's easily done with just one line:

auditusr /r

Typing "auditusr" all by itself will show that there aren't any per-user settings now.

While auditusr isn't an earth-shattering addition to Windows, it fulfills a need that I've seen for a long time, and it's a welcome addition.  My thanks to Roger Grimes, who pointed this SP2/SP1 tool out to me.

Using Security Templates?  Use /generaterollback

If you use security templates -- and if you don't then you should look into them, they're useful -- then you may not know that Server 2003 handles security templates in a slightly different fashion than did 2000 and even XP.  2003 adds a welcome "generate rollback" option.  But I've read quite a bit of misinformation about this option on the Internet, so let's quickly look at what a rollback does.

Security templates are ASCII files that can be applied to Windows 2000, XP or 2003 systems to adjust security-related things.  In fact, security templates let you affect almost everything in the Computer part of the "Security Settings" folder in group policies.  With a security template, you can do things like change NTFS permissions on a system, modify its Registry permissions, control password and audit policies, control who's in a given local group, monkey with the Security Options folder -- the thing that controls null sessions, SMB signing and tons of other things.  Templates can't do everything that a group policy object can, but templates have the virtue of (1) working on a system that's not a member of a domain and (2) not requiring a network connection; some folks like to lock down their security a bit before they ever even plug an Ethernet cable into the back of their systems.

But applying a security template is like applying a security patch:  while it usually makes things more secure, there's a chance that it'll break things.  2003's secedit.exe program contains a "/generaterollback" option which allows you to prepare for applying a given security template by first creating another template, a kind of "anti-template" which, if applied, will un-do almost everything that the template does.  (I'll explain what "almost" means in a minute.)  To use the "/generaterollback" option, then, you'd

  1. First create or acquire a template intended to accomplish something; let's call that "template A."
  2. Use secedit /generaterollback to create an anti-template for "template A;" let's call it "template B."
  3. Apply template A, the original template.
  4. If all's well, then there's nothing else to do.  But if the effects of template A aren't what you wanted, then apply template B, and your system will be almost exactly as it was before you applied template A.

That's the overview; here are the details.

How to Create a Rollback Template

You apply security templates to 2000, XP or 2003 with the "secedit" command-line tool. As I said before, with Server 2003 secedit got a new option, "/generaterollback."  Its syntax looks like

secedit /generaterollback /cfg originaltemplate /rbk rollbacktemplatename

You can also optionally get secedit to log the process by adding "/log logfilename" and you can reduce the amount of chatter that secedit emits with the "/quiet" option.

Rollback Limitations

There are two thingx that rollback templates cannot do, for some reason.  Like the rollback feature of the Security Configuration Wizard, they can roll back everything except for NTFS permissions and Registry permissions.  Could you work around this?  Sure.  Subinacl, a neat tool that you can find at www.microsoft.com/downloads, can record the entirety of permissions on an NTFS volume or, I'd imagine (I've not tried it) a Registry key.  You could record those permissions and stash them away somewhere and, if you needed to roll them back, then subinacl will "play back" permissions that it has stored.  But it's still a pain that /generaterollback can't handle this for you.

How a Rollback Template Works

At first glance, you'd think that building a rollback template would be pretty easy.  If the original template turned on the need for complex passwords, then the anti-template would just turn 'em off, right?  Sure, as the reverse of "enable complex passwords" is "disable complex passwords."  Well, that's right, but what about settings that aren't on/off settings?  Or what about cases where the template flips an on/off switch to "on," even though it's already on.  Or suppose the original template said "set the maximum life of a password to 100 days."  What's the anti-template going to do?  What's the opposite of 100 days?  Of course, there isn't an opposite.  That leads to an important point:

Secedit can't create a rollback password out of thin air.  It can't follow the command "here's a template, create an anti-template."  Instead, it needs a context.  It needs to be told, "here's a template; please create me an anti-template for such-and-such system."  Thus, anti-templates are dependent not only on the original template, but also on the system that the template's about to be applied to.  For example, what's the correct anti-template value for the "set password max age to 100 days?"  Well, if you create an anti-template for that setting on a system that currently has a maximum password age of 70 days, then the anti-template will set the maximum password age to 70 days, which was the default out-of-the box value.

Try It Out

If you've got a Server 2003 system around and want to try it, here's a short exercise.  This will work best if the system is not under the sway of group policies, so a machine who's not a member of a domain would be best.

Start off by creating a template.  Using the Security Templates MMC snap-in, create a security template named "test.inf."  (Chapters 8 and 9 in the Mastering Windows 2003 Server book talk about creating templates.  Failing that, it's all GUI-driven so it's not hard to figure out.)  Give it the following settings:

  • Set the maximum password age to 100 days, and the minimum password age to 30 days.
  • Disable the Smart Card Service.
  • In Computer Configuration / Windows Settings / Local Policies / Security Options, set "network network client: digitally sign communications (if server agrees)" to "Enabled."
  • In the Restricted Groups section, create a policy for the Power Users group that allows only the local Administrator account in Power Users.

Security templates are, of course, just ASCII files.  Look at your new security template (which is in c:\windows\security\templates\test.inf) in Notepad and it'll look like this:

[Unicode]
Unicode=yes
[Version]
signature="$CHICAGO$"
Revision=1
[System Access]
MinimumPasswordAge = 30
MaximumPasswordAge = 100
[Registry Values]
MACHINE\System\CurrentControlSet\Services\LanmanWorkstation\Parameters...
\EnableSecuritySignature=4,1
[Group Membership]
*S-1-5-32-547__Memberof =
*S-1-5-32-547__Members = *S-1-5-32-544
[Service General Setting]
"SCardSvr",4,""

(I broke one of the long lines in the output to make it more readable.)  A look at this lets us guess what's going on.  The password stuff is self-explanatory, and the Registry value is the command that implements our "Microsoft Network Client" policy.  The [Group Membership] section cleans out Power Users and adds Administrator, and I'm guessing that setting a service to 4 disables it, as that'd be its corresponding value in its key under HKLM\SYSTEM\CurrentControlSet\Services.  (Its default value is Manual.)

Now let's create a rollback template.  Type

C:\>secedit /generaterollback /cfg c:\windows\security\templates\test.inf 
/rbk c:\windows\security\templates\rollback.inf /quiet

I've broken the line for readability's sake -- you'd type it as one long line.  A look with Notepad at the rollback template at c:\windows\security\templates\rollback.inf and 

[Unicode]
Unicode=yes
[Version]
signature="$CHICAGO$"
Revision=1
[System Access]
MinimumPasswordAge = 0
MaximumPasswordAge = 42
[Registry Values]
machine\system\currentcontrolset\services\lanmanworkstation\parameters...
\enablesecuritysignature=4,1
[Group Membership]
*S-1-5-32-547__Memberof =
*S-1-5-32-547__Members =
[Service General Setting]
"SCardSvr",3,""

The changes to the password policy are, again, easy to see.  Notice that the Registry setting for Microsoft Network Client are the same as the original template -- that was a trick setting on my part.  You see, I told the template to enable the setting -- but it's enabled by default!  So in this case, setting something to "enabled" causes its corresponding rollback entry to also be "enabled."  The group membership setup looks like the original template's, except notice that there is nothing to the right of "...Members =;" that's because there was no one in the Power Users group before we applied the original template.  The rollback, then, just restored things to the pre-template state.  Finally, the Smart Card Service returns to "3," which is Registry-ese for "manual setting."

Now and then I come across an interesting-looking security template, but put it aside rather than try it out because I don't want to run the risk of breaking something.  But secedit's /generaterollback makes me much more likely to try out new security tweaks... and that makes for more secure systems.  Give it a shot sometime soon!

Conferences

Join me at ...

TechTarget's Web Class on SP2 and SP1.  As they say it...

"Windows School is in session with Mark Minasi Mark Minasi dissects Windows XP SP2 and Windows Server 2003 SP1 in five, 15-minute webcast cram sessions. You can even download a worksheet to follow along with the lesson you're hearing. Find out the good and bad about XP SP2 and Windows 2003 SP1 in Mark's inimitable style. Topics cover: Data execution protection, stack changes, de-anonymizing XP, IE and more."
http://searchwin2000.techtarget.com/general/0,295582,sid1_gci1084934,00.html?offer=minasi

TechMentor Fall 2005 (San Jose):  101 Communication's semi-annual geekfest returns to San Jose this October 17-21.  Follow www.techmentorevents.com for more info as it appears.

Windows Connections Fall 2005 (San Diego):   I'm not sure how California managed to snag three of the four best IT shows this year (Spring Connections in San Francisco, TechMentor in San Jose, Fall Connections in San Diego) but if you're a fan of the Golden State's weather then 2005's the conference-going year for you!  Information on Connections at www.winconnections.com.  Our program chair Amy Eisenberg's trying to out-do herself so it'll be a great show.  I'm doing my SMTP talk, the MSDE talk based on my earlier newsletter, how to fix broken Active Directories, and more.

Bring Mark to your site to teach

I'm keeping busy doing Active Directory and Security seminars and writing, but I've still got time to visit your firm.  In just two days, I'll make your current NT techies into 2000, XP, Active Directory and 2003 experts.  (And better yet they won't have to sit through any Redmondian propaganda.)  To join the large educational, pharmaceutical, agricultural, aerospace, utility, banking, government, telecommunication, law enforcement, publishing, transportation, and other organizations that I've assisted, either take a peek at the course outlines at www.minasi.com/presentations.htm, mail our assistant Jean Snead at Assistant@Minasi.com, or call her at (757) 426-1431 (only between noon-5 Eastern time, weekdays, please).

Until Next Month...

Have a quiet and safe month. 

Please share this newsletter; I'd like very much to expand this periodical into a useful source of NT/2000/2003/XP information.  Please forward it to any associates who might find it helpful, and accept my thanks.  We are now at over 40,000 subscribers and I hope to use this to get information to every single Mastering 2003, XP, NT and 2000 Server reader. Thanks for letting me visit with you, and take care.  Many, many thanks to the readers who have mailed me to offer suggestions, errata, and those kind reviews.  As always, I'm at http://www.minasi.com/gethelp and please join us at the Forum with technical questions at www.minasi.com/forum. 

To subscribe, visit http://www.minasi.com/nwsreg.htm. To change e-mail, format, etc., 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 2005 Mark Minasi. You are encouraged to quote this material, SO LONG as you include this entire document; thanks.