Aaron Margosis' "Non-Admin" and App-Compat WebLog

Lucinda Williams radio show...

Aaron Margosis — Tue, 01 May 2012 23:54:37 GMT

Purely personal blog post this time, nothing to do with Windows or Microsoft...

Several lifetimes ago, I was a DJ on WTJU-FM, the free-form/block-programmed radio station at the University of Virginia where the on-air DJ decides what to play rather than a program director (or megacorporations). This Friday, May 4, I will be back to host a 2-hour show of the music of Lucinda Williams during WTJU's week-long Folk Marathon fundraiser. Tune in and enjoy! Call in and donate!

The show will air on Friday, May 4 from 8:00pm to 10:00pm US Eastern time (Saturday midnight to 2am UTC). If you're in central Virginia, you can hear the show on 91.1 FM. Everywhere else, go to http://www.wtju.net/stream and pick the stream of your choice. (I usually tune in to the 256k Ogg Vorbis stream using Foobar 2000.) If you miss the live broadcast, you can listen to the show from the WTJU Tape Vault for up to two weeks after it airs.

Interviewed about the Sysinternals book on Let's Talk Computers

Aaron Margosis — Wed, 21 Mar 2012 17:56:42 GMT

Let's Talk Computers ranks as one of the longest-running computer radio talk shows. I enjoyed it recently when they interviewed me about the Windows Sysinternals Administrator's Reference. They published Part 1 of that interview on March 3. Check it out here:
http://www.lets-talk-computers.com/guests/microsoft_press/windows_systernals_admin_reference/

Interviewed on “Bytes by TechNet”

Aaron Margosis — Fri, 21 Oct 2011 05:52:04 GMT

Last May at TechEd US, I sat down for a six-minute interview with Matt Hester about the Windows Sysinternals Administrators Reference (the book I co-authored with Mark Russinovich) and issues I see in my work with customers.

That interview, part of the Bytes By TechNet series, can now be seen online here. In addition to insights about the book and my work, the interview shows a particularly bad hair day for me during my year-long experiment growing it long again. (That experiment coincidentally ended just a few hours ago.)

Top Ten Deployment Blockers

Aaron Margosis — Tue, 18 Oct 2011 19:45:02 GMT

My colleague Shelly Bird, a highly esteemed Architect in Microsoft Public Sector Services, has years of experience in desktop and server deployments. She has seen what works and a whole lot of what doesn’t. Now she is bringing her observations to the blogosphere, kicking off with a Top Ten list of deployment blockers. I was really excited when she told me about it because it’s not going to be just another tech-oriented blog about scripting how-to, specific security settings and application compatibility. While those issues are important to deployment projects, that’s not where projects tend to run into the most trouble. This is much higher-level and should be read by executives. It’s not really even Windows-specific. It’s about decision-making (or decision-delaying) and organization culture issues.

Forward this link to your management and executives. If you are a manager or an executive, forward it to your colleagues and friends:

The Deploy Depot Blog

FAQ: Where Do I Save Files, and How Exactly Do I Do That?

Aaron Margosis — Sun, 25 Sep 2011 19:35:00 GMT

The correct ways to identify folder paths to store files depends on the programming technology you use. This blog post shows how to do it in C++, C# and VB. NET, PowerShell, Windows Script Host (VBScript and JScript), and as a last resort, environment variables.

One of the more common programming mistakes that lead to compatibility problems is the incorrect specification of folder paths in programs. For example, it is not uncommon for programs to assume that the user’s profile is under “C:\Documents and Settings”. These default paths are always subject to change and have changed across different versions of Windows. User profiles were stored under %SystemDrive%\WINNT\Profiles, then under “%SystemDrive%\Documents and Settings”, and now under %SystemDrive%\Users. The “All Users” profile is now called “Public”, and what was in “%USERPROFILE%\Local Settings\Application Data” is now in “%USERPROFILE%\AppData\Local”. Also, part of what used to be under the “All Users” profile is now in a separate folder location (by default, C:\ProgramData).

How can programs work correctly when these paths keep changing? Well, applications that are written correctly don’t require any modification to get the correct folder locations on all versions of Windows. Some rules you should follow:

Do not hardcode any file system paths.
Do not assume that Windows is installed on the C: drive, that there is a “Documents and Settings” or a “Users” folder, or a “Program Files” folder.
DO use symbolic constants and Windows APIs or environment variables to identify the appropriate place to put file content.
Distinguish between per-user and shared content.
Distinguish between files users should be able to browse in Explorer (e.g., documents that users create) and files that aren’t intended for direct access by users (application configuration settings, for example). These file types get stored in different locations.

Here are the correct ways to identify folder locations using a variety of programming technologies:

C++

Use the SHGetSpecialFolderPath function with CSIDL constants. For programs designed to run only on Windows Vista or newer, use the SHGetKnownFolderPath function with KNOWNFOLDERID constants. See the following links:

SHGetSpecialFolderPath: http://msdn.microsoft.com/en-us/library/bb762204(v=VS.85).aspx
CSIDL: http://msdn.microsoft.com/en-us/library/bb762494(VS.85).aspx
SHGetKnownFolderPath: http://msdn.microsoft.com/en-us/library/bb762188(v=VS.85).aspx
KNOWNFOLDERID: http://msdn.microsoft.com/en-us/library/dd378457(v=VS.85).aspx

These two examples demonstrate retrieving the paths for the current user’s Documents folder and the computer’s shared Documents folder:

HRESULT hr;

TCHAR szPath[MAX_PATH];

hr = SHGetFolderPath(NULL, CSIDL_MYDOCUMENTS, NULL, SHGFP_TYPE_CURRENT, szPath);

if (SUCCEEDED(hr))

{

...

}

hr = SHGetFolderPath(NULL, CSIDL_COMMON_DOCUMENTS, NULL, SHGFP_TYPE_CURRENT, szPath);

if (SUCCEEDED(hr))

{

...

}

C#/VB .NET (using Managed code)

Use the Environment.GetFolderPath method, passing in a Environment.SpecialFolder enumeration. The System.IO.Path.Combine method can be used to combine path parts. For example, the following C# code returns the path to a “MyData” subfolder in the current user’s Documents folder:

string sPath;

sPath = System.IO.Path.Combine(

Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments),

"MyData");

This is the same code implemented in VB .NET:

Dim sPath As String

sPath = System.IO.Path.Combine( _

Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments), _

"MyData")

References:

Environment.GetFolderPath
http://msdn.microsoft.com/en-us/library/system.environment.getfolderpath.aspx
SpecialFolder enumeration:
http://msdn.microsoft.com/en-us/library/system.environment.specialfolder.aspx

PowerShell

Windows PowerShell is built on .NET and can invoke many .NET methods and resources from the PowerShell command line interface or from Notepad-editable script files. This is how to implement the earlier sample building a path to a “MyData” subfolder of the user’s Documents folder using PowerShell:

$sPath = [System.IO.Path]::Combine(

[Environment]::GetFolderPath([Environment+SpecialFolder]::MyDocuments),

"MyData")

C#/VB .NET Using Native Methods (P/Invoke)

You can invoke the native Windows SHGetFolderPath API from C# or VB .NET code using Platform Invoke (a.k.a., P/Invoke) methods. See http://pinvoke.net/default.aspx/shell32/SHGetFolderPath.html for examples. This may be useful because the native CSIDL enumeration includes many more folder locations than the .NET SpecialFolder enumeration did before .NET v4.

Windows Script Host – JScript and VBScript

Windows Script Host defines a SpecialFolders collection that can be used from VBScript or JScript. The following JScript example outputs the path to the common (“all users”) desktop:

    var oWsh = WScript.CreateObject("WScript.Shell");

    var sDesk = oWsh.SpecialFolders("AllUsersDesktop");

    WScript.Echo(sDesk);

And here is the same code in VBScript:

    Dim oWsh, sDesk

    Set oWsh = WScript.CreateObject("WScript.Shell")

    sDesk = oWsh.SpecialFolders("AllUsersDesktop")

    WScript.Echo sDesk

References:

WshShell object: http://msdn.microsoft.com/en-au/library/aew9yb99.aspx
SpecialFolders Property: http://msdn.microsoft.com/en-au/library/0ea7b5xe.aspx

Environment Variables and Batch Files

If none of the above interfaces are available (for example, from a Cmd.exe batch file), Windows defines a relatively small number of environment variables that identify some file system locations. Using these environment variables, at least for partial paths, is better than hardcoding paths. The following table lists the filepath-related environment variables on my Windows 7 SP1 x64 system and their values. Note that these are just example values as found on a particular computer. Do not assume that the same path locations are the same on other computers. See the References for the meanings and intended purposes of these variables.

*Environment variable name*	*Example value*
ALLUSERSPROFILE	C:\ProgramData
APPDATA	C:\Users\username\AppData\Roaming
CommonProgramFiles	C:\Program Files\Common Files
CommonProgramFiles(x86)	C:\Program Files (x86)\Common Files
CommonProgramW6432	C:\Program Files\Common Files
ComSpec	C:\Windows\system32\cmd.exe
HOMEDRIVE	C:
HOMEPATH	\Users\username
LOCALAPPDATA	C:\Users\username\AppData\Local
ProgramData	C:\ProgramData
ProgramFiles	C:\Program Files
ProgramFiles(x86)	C:\Program Files (x86)
ProgramW6432	C:\Program Files
PSModulePath	C:\Windows\system32\WindowsPowerShell\v1.0\Modules\
PUBLIC	C:\Users\Public
SystemDrive	C:
SystemRoot	C:\Windows
TEMP	C:\Users\username\AppData\Local\Temp
TMP	C:\Users\username\AppData\Local\Temp
USERPROFILE	C:\Users\username
windir	C:\Windows

References:

Information about some of the new 64/32 variables:
http://msdn.microsoft.com/en-us/library/aa384274(VS.85).aspx
Definitions of default environment variables on Windows XP:
http://msdn.microsoft.com/en-us/library/bb490954.aspx#ECAA

PrivBar Update

Aaron Margosis — Thu, 01 Sep 2011 18:03:00 GMT

PrivBar is a toolbar I first published over seven years ago (!) for Internet Explorer and Windows Explorer. I updated it three years ago to add support for x64. Today I am updating it to offer better support for Vista and Windows 7 and the corresponding Server versions. Specifically, instead of showing a group name such as Users or Administrators in the toolbar, it shows the integrity level of the current page. One significant benefit is that this helps mitigate the removal of the Protected Mode indicator from the IE9 status bar.

Download the .zip file attached to this post; extract the DLLs to a shared location (e.g., under Program Files) and register each with regsvr32.exe. (Note that PrivBarX64.dll can be used only on x64 editions of Windows.) The toolbars need to be enabled separately for Windows Explorer, Internet Explorer, and Internet Explorer (64 bit): press Alt to display the menu, then choose View | Toolbars | PrivBar x64. (It says “x64” even for the 32-bit version.)

Integrity levels (ILs) were first introduced in Windows Vista and are part of what makes it possible for programs running under a single user account to have different security restrictions. Basically (and oversimplifying), a program running at a particular integrity level cannot modify resources that are marked at a higher integrity level. Its most prominent application is in IE’s Protected Mode. On Windows 7 IE Protected Mode is enabled in the Internet and Restricted Sites security zones, and disabled in the Intranet, Trusted Sites, and Computer (Local Machine) zones. With Protected Mode enabled, IE runs at the Low integrity level and cannot directly write to most areas of the file system or registry (which are marked Medium), or manipulate other programs the user is running such as by sending synthesized keystroke messages. Sysinternals Process Explorer is a great tool for identifying the ILs of processes on your computer (and the Windows Sysinternals Administrator’s Reference is a great book for learning all about Process Explorer and much more. :)

The main ILs you’ll see in Windows are:

Low: less-privileged processes, including Internet Explorer with Protected Mode, as well as Microsoft Office 2010’s Protected View and Adobe Reader X’s sandbox mode.
Medium: most user applications run at the Medium level.
High: user applications running with full administrative rights (e.g., apps launched with UAC’s “Run as administrator”).
System: the integrity level given to Windows services.

Here’s a screenshot of Internet Explorer browsing a site in the Internet zone. Protected Mode is enabled and PrivBar shows “Low IL” with a green circle icon.

If you browse to a site in the Intranet or Trusted Sites zone, Protected Mode is disabled. As this screenshot shows, PrivBar reports “Medium IL” with a yellow circle icon.

The vast majority of desktop applications run at Medium IL, including Windows Explorer, shown here:

By default, UAC’s “Admin Approval Mode” is not applied to the built-in Administrator account, so when you log on with that account, everything runs with full administrative rights. Here are screenshots of Internet Explorer and Windows Explorer, with PrivBar reporting “High IL” and a red circle icon. (Note that in most scenarios, the built-in Administrator account is disabled.)

You can use the new versions on Windows XP and Windows Server 2003. Instead of the Integrity Level, it shows “Users”, “Power Users” or “Administrators” as it did in the past.

IEInternals Reviews the Sysinternals Book

Aaron Margosis — Tue, 16 Aug 2011 07:08:00 GMT

We have a lot of really smart people at Microsoft, but among those there are a handful who are the most knowledgeable and the most helpful, the go-to people upon whom I can reliably depend for accurate and detailed answers to rarely-asked or never-before-asked questions. In the realm of all things Internet Explorer, that person for me is Eric Lawrence, the author of (among many things) the Fiddler web debugging utility and the IEInternals blog. Therefore, I was excited when I heard he had written a review of Mark Russinovich’s and my Sysinternals book, and absolutely thrilled that he liked it. He didn’t just skim the book either – he read it from cover to cover and experimented with the utilities along the way. Thanks, Eric!

Windows Sysinternals Administrator’s Reference – now available!

Aaron Margosis — Tue, 26 Jul 2011 03:28:59 GMT

Many of you have long wished for comprehensive, detailed documentation of the Sysinternals utilities. It has finally arrived. Over two years in the making, the Windows Sysinternals Administrator’s Reference (written by Mark Russinovich and me) is now available for purchase on Amazon.com and available from O'Reilly in 4 ebook formats, or you can read it online through Safari. If you do any technical work on the Windows platform, there are Sysinternals utilities that will help you. And whether you are a novice or a guru, this book will help you use the utilities more effectively.

So how did I get involved in this?

I was one of the technical reviewers of a previous iteration of the book that Mark had been working on with another co-author. On May 6, 2009, we reviewers received an email from the co-author saying he needed to step down from the project because the time commitment was turning out to be too great. My initial thoughts were, “Darn! This book needs to be written. I wish I had the time to do it, but I don’t.” Somehow over the next few hours I convinced myself that maybe I could, and at 3am I sent Mark a note suggesting that I take over the project. (One of these days I’ll absorb the lesson I should have learned many times over that any email composed at 3am should be sat upon, not sent.)

Rather than saying “yes” right away, Mark suggested that I write the Process Monitor chapter so that he could evaluate whether my writing was a good fit for his book, and I could better gauge whether I really wanted to take on the project. Within a few weeks I sent Mark a draft. He loved its organization, thoroughness and tone, so we moved forward.

Writing a book – even for Microsoft Press – is outside of the regular duties of my day job in Microsoft Services, so I could do it only in my “spare time”. I had never written a book before, but I knew from other authors that it’s a big time sink. Being very detail-oriented in my writing, I knew that it would take a lot longer and be a lot harder than whatever I expected, no matter what my estimates were. It actually turned out to be even worse than that. It consumed all my nights and weekends, and – especially – vacations. Yes, all my vacations for the past two years have been spent holed up in my basement office, researching and writing.

I committed that I wouldn’t write anything unless I observed it working as I described it and fully understood what it meant. It’s a good thing that Mark asked me to start with Process Monitor rather than Process Explorer – I might have run from the project screaming if I’d had to write Procexp up first. While Procmon ended up at 44 pages, the Procexp chapter required 62 pages to document. But because Procexp is such a comprehensive tool that touches so many different parts of Windows, it took much more than 40% as long to write. I think the quality of the book reflects the extra effort. Enjoy!

Now I’m looking forward to having a real vacation again, but I don’t know whether I’ll remember how to enjoy it. I’ll probably spend all my time thinking about the Second Edition. :)

Unintended Consequences and Sysinternals at Tech-Ed Available Online

Aaron Margosis — Wed, 25 May 2011 06:30:56 GMT

The two sessions I presented last week at Tech-Ed North America 2011 are now available for on-demand online viewing:

Unintended Consequences of Security Lockdowns (which got an unexpected and appreciated plug from Raymond Chen) is here:
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/SIM304

Sysinternals Primer: Autoruns, Disk2Vhd, ProcDump, BgInfo and AccessChk is here:
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/WCL312

I am pleased to say that both sessions received high marks from attendees. Both were in the top 10%, and the Sysinternals session was in the top 3% and just missed being in the top 10 (out of 454 breakout sessions). I really appreciated the many compliments that people wrote in the comments section of the evaluations, but my favorite was this one: “Mark you need to let Andy's name be the same size as yours on the book cover.” (Yes. “Andy’s”. Nobody ever gets Mark Russinovich’s name wrong. I’ve obviously got a long ways to go before I’m as famous as he is.)

Speaking of Mark, he presented another excellent Case of the Unexplained featuring all new material which you can view here. I particularly liked the part at about 1:11:40 when in reference to the Sysinternals Administrators Reference he said, “This book really exceeded my expectations in terms of the quality of the material that we got, largely because of Aaron’s dedication to it.” Pretty good week. :)

IEZoneAnalyzer updated

Aaron Margosis — Thu, 14 Apr 2011 17:58:55 GMT

I just posted a major update to IEZoneAnalyzer, my IE security zone analysis and comparison utility, over on the Microsoft FDCC/USGCB blog. Lots of new features, including saving settings so they can be viewed and compared later and on other computers, and export to Excel. See that blog post for screenshots and the download.

http://blogs.technet.com/b/fdcc/archive/2011/04/14/iezoneanalyzer-v3.aspx

The Case of the Mysterious Law Manager Startup Error

Aaron Margosis — Thu, 14 Apr 2011 15:08:43 GMT

Getting Law Manager v2.4 to run on Windows 7

Overview

Several of my customers run old versions (circa 2003) of a legal case management application called Law Manager, since acquired by Bridgeway. These customers reported that their old versions of Law Manager “don’t work” on Windows 7 and that the vendor did not support running them on Windows 7. Normally, if the vendor of an incompatible app has a newer version that is compatible with Windows 7, we recommend upgrading to the new version. Sometimes, though, customers will choose for various reasons to try to continue using the version they have at least temporarily, even if it means that they will do so without vendor support. This article describes the troubleshooting and remediation steps I performed to get Law Manager working for one of those customers. The incompatibility turned out to be due to a very subtle change in a single registry value. Two different solutions to the problem are provided.

This case describes troubleshooting and remediation for a specific version of Law Manager. The results may be the same for other legacy versions of Law Manager, but they would each need to be verified separately. Sysinternals SigCheck with the -a command line option reports the following version information for this customer’s copy:

C:\Program Files\Law Manager, Inc\LawManager.Pro\lm2000.exe:
    Verified: Unsigned
    File date: 4:50 PM 10/6/2003
    Publisher: Law Manager, Inc.
    Description: LawManager.Pro
    Product: LawManager.Pro
    Version: 2.4 Service Pack 1 (204)
    File version: 2.4 Service Pack 1 (204)
    Strong Name: Unsigned
    Original Name: lm2000.exe
    Internal Name: lm2000.exe
    Copyright: Copyright ⌐ Law Manager, Inc 1985-2002
    Comments: leader in premier practice management software for large corporate legal departments, government agencies and multi-office law firms

The Diagnosis

After installing Law Manager (with administrative rights), I ran Law Manager from the Start menu as a standard user. It displayed a terse error message and then exited when the dialog was dismissed:

It turns out that this kind of error message is typical of runtime failures from Borland Delphi applications. As far as I can tell, when a Delphi app triggers an otherwise-unhandled exception, the outermost Delphi runtime code captures the exception, displays an error message like the one shown with an error code and a memory address, then exits. In Pascal and Delphi, error code 204 means “invalid pointer operation”. In addition to the Borland-style UI elements in a working version of Law Manager, I confirmed my suspicion that Law Manager is a Delphi application with the Sysinternals Strings utility:

strings -q lm2000.exe | findstr /i delp

SOFTWARE\Borland\Delphi\RTL
Software\Borland\Delphi\Locales
Delphi Picture
Delphi Component
Delphi%.8X
Software\Developer Express\Delphi\Design Forms\
Software\Developer Express\Delphi\Design Forms\
| Compilation Flags: Win32, Production, TimerView, Delphi 6.0

To figure out what the app could be doing that would lead to failure, I turned to Sysinternals Process Monitor, a.k.a. Procmon, the best troubleshooting tool in the universe (well, at least for that part of the universe that runs Microsoft Windows).

Here is a troubleshooting pattern I use all the time. I started Procmon, which began capturing details about all file system and registry events as well as many types of process and network events. When the error message appeared, I stopped the Procmon trace and dragged the crosshairs “Include Process From Window” icon from the Procmon toolbar to the error message. This feature applies a filter to the results so that Procmon displays only those events associated with the process that owns the window; in this case lm2000.exe, process ID 3600. The events of interest are then usually near the end of the trace, so I went to the end of the trace and worked back. One thing to note is that displaying an error dialog usually involves a number of registry accesses. If the Procmon trace has clues, they usually show up right before the events involved in the error message display.

It took some digging, but the evidence turned up and can be seen in the following screenshot. The first event shown in the screenshot is a registry value read that appears to be related to COM component invocation. The retrieved value is a REG_EXPAND_SZ – a text string that can contain environment variables that need to be expanded before use: “%SystemRoot%\System32\hhctrl.ocx”. Two events later is an attempt to open a file system folder with the name “C:\Program Files\Law Manager, Inc\LawManager.Pro\%SystemRoot%\System32\”, which of course fails with “PATH NOT FOUND”. Evidently the program failed to expand the environment variable before calling a file system API with the returned data. The program probably also expected the API to succeed because the error and exit followed very quickly.

(Click on the screenshots in this post to see the full resolution versions.)

We can dig deeper into these two events by double-clicking each to open their Properties dialogs, shown below. Looking at the call stack of the registry read in the first screenshot, we see that lm2000.exe (frame 6) did not invoke a COM API but instead read the value directly by calling the RegQueryValueExA API (frame 5 – note that beginning with Windows 7 and Server 2008 R2 the registry APIs now live in kernel32 instead of advapi32). The file system access shown in the second screenshot occurred when lm2000.exe invoked the FindFirstFileA API (frame 14) which is used to search for file names matching a pattern. (Note that this core function is now exported from KernelBase.dll).

Just for extra verification (and turbo-nerdiness) I ran lm2000.exe again, but this time in Windbg from the Debugging Tools for Windows. Here’s an annotated screenshot:

“bp kernelbase!FindFirstFileA” sets a breakpoint at the entry point to the function we want to see; “g” is the “Go” command that lets the program run.
The FindFirstFileA breakpoint has been hit; “kv 1” shows the top stack frame including parameters (arguments) passed to the function on the stack.
The first value passed to FindFirstFileA is the memory address 0x01b01011c and represents the file name or pattern to search for. “da 01b1011c” displays the data found at that address as an ANSI string, which turns out to be “%SystemRoot%\System32\hhctrl.ocx”, which is not a valid file name or pattern. Combined with the Procmon trace, it appears that because FindFirstFileA didn’t recognize the supplied path as an absolute path, it treated it as a relative path and appended it to the current directory.
“bc 0” clears breakpoint #0, and “g” lets the program continue. It quickly hits a first-chance exception due to an access violation.
The problem is that the instruction pointer (eip) which identifies the next instruction to execute is pointing to address 0, which is invalid. That will always cause a crash.

Why did this code work on Windows XP but fail on Windows 7? Let’s take a look at the registry value as it existed in Windows XP and compare it to Windows 7. The XP screenshot shows that the value had been a REG_SZ with the literal path to the file rather than a REG_EXPAND_SZ containing “%SystemRoot%” as it is in Windows 7. The change makes sense: literal paths like the one on XP need to be customized at installation time depending on where Windows is installed, while “%SystemRoot%\System32\hhctrl.ocx” is correct for all Windows instances.

Solution #1: Overriding the Registry Value

One way to get Law Manager to work the way it did on Windows XP is to change the registry data back to the way it was on Windows XP. That, however, is not a good idea, and Windows will tell you so with an “access denied” if you try. Take a look at the permissions on that registry key:

That’s right: even Administrators and System are granted Read-Only, just like standard users. Because of Windows Resource Protection, only the TrustedInstaller (a.k.a., “Windows Modules Installer”) service is granted Full Control on this key. Objects with permissions set this way belong to Windows and should not be modified except by Windows itself. (Of course, if you have administrative rights, you could take ownership of the resource, change its permissions and then make any changes to the resource you want. It is impossible to restrict what an administrator can do. Just be aware that just because you can doesn’t mean it’s a good idea or that you will have a supportable and serviceable instance of Windows when you’re done. Consider that “access denied” an unsubtle hint that you shouldn’t continue.)

So my first idea was to take advantage of the fact that HKEY_CLASSES_ROOT is actually a merged view of HKEY_LOCAL_MACHINE\Software\Classes and HKEY_CURRENT_USER\Software\Classes. If a value exists under HKCU\Software\Classes, it takes precedence over a corresponding value in HKLM\Software\Classes. I exported the key from HKCR to a file called “fix-law-manager.reg”, opened it with Notepad, changed the beginning of the key name from “HKEY_CLASSES_ROOT” to “HKEY_CURRENT_USER\Software\Classes” and changed the default value from a REG_EXPAND_SZ specified in hexadecimal bytes to a REG_SZ with a literal path:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Classes\CLSID\{ADB880A6-D8FF-11CF-9377-00AA003B7A11}\InprocServer32]
@="C:\\Windows\\System32\\hhctrl.ocx"
"ThreadingModel"="Apartment"

Finally, I imported the edited file into the user’s HKCU with this command line: “reg import fix-law-manager.reg”.

The fix appeared to work: when I started Law Manager again it got past the previous error and displayed a login dialog. (That was as far as I could test it myself without back end systems. The customer tested the application’s full functionality and found no further problems.)

A Procmon trace captured during that test shows that the literal path is picked up from the HKCU side of HKCR, and hhctrl.ocx is then successfully found in the C:\Windows\System32 folder.

I was satisfied that I had found a solution: simply package “fix-law-manager.reg” so that it can be imported into the HKCU of every end user who uses Law Manager one time before they run Law Manager for the first time. It is a pretty simple fix that doesn’t involve breaking permissions on Windows-owned resources. There are some downsides, however:

· The fix-law-manager.reg file needs to be imported by every end user who uses Law Manager prior to first use. If two users share a computer and both use Law Manager, both users need to import the file. Further, because HKCU\Software\Classes doesn’t roam, if an end user logs on to different machines and runs Law Manager, the registry file needs to be imported for that user on each of those computers.

· The overriding of the global value in HKLM\Software\Classes affects all programs that the user runs. While it would seem that a minor change like this is unlikely to cause any problems, you could have said the same about the change from REG_SZ to REG_EXPAND_SZ.

Solution #2: Apply an Application Compatibility Shim

I shared my great app compat sleuthing and my fabulously simple solution with Chris Jackson, The App Compat Guy. I don’t think he was impressed. All he said was, “Are you aware of the HandleRegExpandSzRegistryKeys shim? It’s less risky to target the fix at the particular app, since hhctrl is the HTML Help control, the universe of possible side-effects is smaller than just adding the key and perpetuating the use of a hard-coded Windows path.” Well, no, I wasn’t aware of that shim at all. It’s certainly not one of the most over-documented shims we have. I Bing’d it and found Installation Failure Issues which lists twenty-six fixes (shims) with the symptoms they treat along with one-sentence descriptions. HandleRegExpandSzRegistryKeys is the last one on the page and says it is good for when “You cannot open the Readme.txt file.” However, if I had read and remembered every page of TechNet documentation written since Windows Vista shipped, I would have remembered this valuable description: “Modifies the RegQueryValueEx function of the REG_EXPAND_SZ registry keys so that it automatically expands the environment strings.” That is exactly what we need. Apply this shim to Law Manager so that whenever it reads a REG_EXPAND_SZ from the registry, the shim will expand any environment variables it finds before returning the data to the application.

Note that shims do not modify the executable image. When an application is configured to have shims applied to it, Windows loads one or more additional DLLs into the process’ address space and patches portions of memory to intercept API calls so that the shim DLL can manipulate incoming or outgoing data or change other results.

How do we configure this shim? Here is the step-by-step with lots of screenshots. Install the Application Compatibility Toolkit (ACT) v5.6, then run Compatibility Administrator (32-bit). Select the new custom database (selected by default) and click the “Fix” toolbar icon:

Enter the name and vendor of the program to be shimmed, browse to the file location to identify the executable image, and click Next:

We won’t use any compatibility modes, so click Next without selecting any:

Find and select the HandleRegExpandSzRegistryKeys compatibility fix. No parameters are needed this time. Because the call stack showed that lm2000.exe calls RegQueryValueEx directly, we don’t need to configure other calling modules to be fixed up. (See in the screenshot that the tooltip text says, “Applies to: Windows 95, Windows 98”? Yeah, that’s helpful. And a bug.)

On the Matching Information page, just accept the provided defaults and click Finish.

We now have a fix prepared. Click Save in the Compatibility Administrator toolbar:

Give the new shim database a display name (such as “Law Manager”), and save it to a file location, such as to LawManager.sdb on your desktop.

To install the new shim database on the current computer, right-click the custom database (the label next to the big oil barrel) and choose Install. This is the easiest way to install a shim database on a test system where you have Compatibility Administrator installed. To install it in an unattended fashion – such as in an automated Windows image build as an MDT task sequence, in a computer startup script configured through Group Policy, or incorporated into the application’s installation – use the Sdbinst.exe program that ships in Windows. (For example, “sdbinst.exe -q \\server\sysvol\shims\LawManager.sdb”.)

We now have a fix prepared and installed. As shown in the following screenshot, when Windows loads an executable image called “lm2000.exe” that has a binary file and product version of 2.4.204.1, text product and file version of “2.4 Service Pack 1 (204)”, a company name of “Law Manager, Inc.” and a product name of “LawManager.Pro” in its version resource information, Windows will apply the HandlRegExpandSzRegistryKeys fix to it:

After removing my previous HKCU registry edit, I ran Law Manager with the shim configured while monitoring with Procmon. Again, it ran successfully to the login dialog. Note the difference in the Procmon results. The HKCU\Software\Classes read failed with “Name not found”, followed by a successful read from the corresponding HKCR key. This is a very common pattern in Procmon traces. (In Procmon, HKCR refers to the global HKLM\Software\Classes.) At the low level that Procmon captured the RegQueryValueEx event, it shows that the value was still indeed a REG_EXPAND_SZ with an environment variable:

But opening that event’s Properties, you can see that the lm2000.exe code that had invoked RegQueryValueEx directly has now been redirected through AcLayers.dll, which expands the environment variables in the text to return to lm2000.exe.

LUA Buglight 2.1.1 with support for Win7/2008R2 SP1

Aaron Margosis — Wed, 23 Mar 2011 03:24:00 GMT

LUA Buglight 2.1.1 is attached to this blog post and replaces v2.1. It adds support for Windows 7 SP1 and Windows Server 2008 R2 SP1. It also fixes a localization bug.

Now that I've (pretty much) finished work on the Windows Sysinternals Administrators Reference, maybe I can find time to write documentation for LUA Buglight! :)

Unintended Consequences and Sysinternals at Tech-Ed North America 2011

Aaron Margosis — Thu, 10 Mar 2011 06:02:00 GMT

I'm presenting a couple of sessions at Tech-Ed in Atlanta (May 16-19, 2011):

The first is "Unintended Consequences of Security Lockdowns", which was very highly rated when I presented it last month at TechReady, Microsoft's internal training event.

Security-conscious organizations often lock down their systems based on prescriptive guidance from Microsoft, US Federal government agencies or other security organizations. Sometimes these settings can lead to unpleasant surprises and unexpected side effects. This session will describe and demonstrate some of the common issues that can arise, and whether and how those settings actually help or hurt. Is there benefit to not granting Administrators the “Debug” privilege? Does “Hide mechanisms to remove zone information” break anything? Is the “Require trusted path for credential entry” setting worth the inconvenience? Come see!

It's got several eye-opening demos, including a couple that led to changes in Microsoft's and others' security guidance.

The second session is "Sysinternals Primer: Autoruns, Disk2vhd, ProcDump, BgInfo and AccessChk":

The Sysinternals utilities are vital tools for any computer professional on the Windows platform. Mark Russinovich's popular "Case Of The Unexplained" demonstrates some of their capabilities in advanced troubleshooting scenarios. This complementary tutorial session focuses primarily on the utilities themselves, giving you tips and techniques for using their full functionality for troubleshooting and systems management. This session follows the same format as last year’s highly-rated delivery (*), and covers a different set of the most useful Sysinternals tools.

(*) Last year's session, which I delivered with Tim Reckmeyer, covered Process Explorer, Process Monitor and PsExec.

I guess you might be wondering why I'm delivering a session on Sysinternals utilities. That would be a good question, because I see now that I haven't actually blogged about it yet: I am the co-author with Mark Russinovich of the upcoming Windows Sysinternals Administrators Reference on Microsoft Press, so I've been getting to know the Sysinternals utilities really well :). More info on the book soon. In the meantime, here is the updated cover:

Disabling User Account Control (UAC) on Windows Server

Aaron Margosis — Fri, 04 Mar 2011 19:16:00 GMT

[Update May 17, 2011: this blog post has been republished as Microsoft Knowledge Base article 2526083]

Applies To

Windows Server 2008 (all editions except Server Core)

Windows Server 2008 R2 (all editions except Server Core)

Summary

Under certain constrained circumstances, disabling User Account Control (UAC) on Windows Server can be an acceptable and recommended practice. These circumstances arise only when both of the following are true:

· Only Administrators are allowed to log on to the Windows Server interactively at the console or through Remote Desktop services.

· Administrators log on to the Windows Server only to perform legitimate system administrative functions on the Server.

If either of the above is not true, then UAC should remain enabled. For example, if the Server is configured with the Remote Desktop Services role so that non-administrative users can log on to the Server to run applications, UAC should remain enabled. Similarly, UAC should also remain enabled if administrators run risky applications on the Server such as web browsers, email or instant messaging clients, or perform other operations that should be performed from a client operating system such as Windows 7.

Note that this guidance applies only to Windows Server operating systems such as Windows Server 2008 and Windows Server 2008 R2. UAC should always remain enabled on client operating systems such as Windows Vista and Windows 7.

Note also that UAC is always disabled on Windows Server 2008 R2 Server Core and should always be kept disabled on Windows Server 2008 Server Core. A hotfix is available for Windows Server 2008 Server Core (KB 969371) to prevent UAC from being enabled accidentally.

More Information

User Account Control (UAC) was introduced in Windows Vista and enhanced in Windows 7 to help Windows users move toward using standard user rights by default. UAC includes several technologies to achieve this:

· File and Registry Virtualization. When a “legacy” application tries to write to protected areas of the file system or registry, Windows silently and transparently redirects the access to a portion of the file system or registry that the user is allowed to modify. This enables many applications that required administrative rights on earlier versions of Windows to run successfully with only standard user rights on Windows Vista and Windows 7.

· Same-desktop Elevation. Elevation allows an authorized user to run a program with greater rights than those of the interactive desktop user. Combined with UAC’s “Filtered Token” feature, this allows administrators to run all programs with standard user rights by default and to elevate only those programs that require administrative rights with the same user account. (This feature is also known as “Admin Approval Mode”.) Programs can also be launched with elevated rights under a different user account, so that an administrator can perform administrative tasks on a standard user’s desktop.

· Filtered Token. When a user with administrative or other powerful privileges or group memberships logs on, Windows creates two access tokens representing the user account. One has all the user’s group memberships and privileges, while the “filtered” token represents the user with the equivalent of standard user rights and is used to run the user’s programs by default. The unfiltered token is associated only with elevated programs. An account that is a member of the Administrators group and gets a filtered token at logon is often called a “Protected Administrator” account.

· User Interface Privilege Isolation (UIPI). UIPI prevents a lower-privileged program from sending window messages such as synthetic mouse or keyboard events to a window belonging to a higher-privileged process and thus controlling it.

· Protected Mode Internet Explorer (PMIE). PMIE is a defense-in-depth feature in which Internet Explorer operates in low-privileged “Protected Mode” and cannot write to most areas of the file system or registry. Protected Mode is “on” by default when browsing sites in the Internet or Restricted Sites zones. PMIE makes it more difficult for malware that infects a running instance of IE to change the user’s settings, such as by configuring itself to start every time the user logs on. (PMIE is not actually part of UAC but depends on UAC features such as UIPI.)

· Installer Detection. When an interactive user running with standard user rights starts a program that Windows heuristically determines is likely to be a legacy installation program, Windows proactively prompts the user for elevation, rather than allow the program to run with standard user rights and possibly fail. Note that if the interactive user does not have administrative credentials, the user will not be able to run the program.

In Local Security Policy | Security Settings | Local Policies | Security Options, disabling the policy named “User Account Control: Run all administrators in Admin Approval Mode” disables all the UAC features described above. Legacy applications with standard user rights that expect to write to protected folders or registry keys will fail. Filtered tokens are not created, and all programs run with the logged on user’s full rights. This includes Internet Explorer, as Protected Mode is “off” for all security zones.

One of the common misconceptions about UAC – and same-desktop elevation in particular – is that it prevents malware from being installed or from gaining administrative rights. First, malware can be written not to require administrative rights, and to write only to areas in the user’s profile. More importantly, UAC’s same-desktop elevation is not a security boundary and can be hijacked by unprivileged software running on the same desktop. Same-desktop elevation should be considered a convenience feature, and for security purposes “Protected Administrator” should be considered equivalent to “Administrator”. By contrast, logging in or Fast User Switching to a different session with an administrator account involves a security boundary between it and the standard user session. (See the References section for more information about security boundaries.)

The purpose of the Protected Administrator account on end user client operating systems (Windows Vista and Windows 7) is to encourage developers to write their applications to require only standard user rights while enabling as many applications that share state between administrative components and standard user components to continue working. The stated goal and expectation is that over time end users would see few if any elevation prompts, as the programs they run should never require administrative rights. This becomes increasingly necessary as more enterprises adopt a model in which their end users log on as standard users and do not have credentials for administrative accounts with which to allow elevations.

However, for a Windows Server on which the sole reason for interactive logon is to administer the system, the goal of fewer elevation prompts is neither feasible nor desirable. System administrative tools legitimately require administrative rights. When all the administrative user’s tasks require administrative rights and each task could trigger an elevation prompt, the prompts are only a hindrance to productivity. In this context, they do not and cannot promote the goal of encouraging development of applications that require standard user rights. Nor do they improve security posture. Instead they simply encourage users to click through dialog boxes without reading them.

Note that this guidance applies only to well-managed Servers on which only administrative users are allowed to log on interactively or through Remote Desktop services, and they do so only to perform legitimate administrative functions. If they run risky applications such as web browsers, email or instant messaging clients, or perform other operations that should be performed from a client operating system, then the Server should be considered equivalent to a client system and UAC should remain enabled as a defense-in-depth measure.

Further, if standard users log on to the Server at the console or through Remote Desktop services to run applications, including web browsers, UAC should remain enabled to support file and registry virtualization as well as Protected Mode Internet Explorer.

Another option to avoid elevation prompts without disabling UAC is to set the security policy, “User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode” to “Elevate without prompting.” With this setting, elevation requests are silently approved if the logged-on user is a member of the Administrators group. This also leaves PMIE and other UAC features enabled. However, not all operations that require administrative rights request elevation. This can result in a situation in which some of the user’s programs are elevated and some are not, often with no way to distinguish between them. For example, most console utilities that require administrative rights expect to be launched from an already-elevated Command Prompt or other elevated program. Such utilities simply fail when launched from a non-elevated Command Prompt.

Additional impact of disabling UAC

· With UAC disabled, Windows Explorer continues to display UAC “shield” icons for items that require elevation and to include “Run as administrator” in the context menus of applications and application shortcuts. Because the UAC elevation mechanism is disabled, these have no effect, and applications run in the same security context as the logged-on user.

· With UAC enabled, when the console utility Runas.exe is used to launch a program as a user that is subject to token filtering, the launched program runs with the user’s filtered token. With UAC disabled, the launched program runs with the user’s full token.

· With UAC enabled, local accounts cannot be used for remote administration over network interfaces other than Remote Desktop (e.g., via NET USE or IIS’ Windows authentication). A local account that authenticates over such an interface gets only the privileges granted to the account’s filtered token. With UAC disabled, this restriction is removed. (This feature and a configuration setting to remove it are described in Microsoft KB article 951016.)

References

Inside Windows Vista User Account Control
http://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx

Inside Windows 7 User Account Control
http://technet.microsoft.com/en-us/magazine/2009.07.uac.aspx

PsExec, User Account Control and Security Boundaries
http://blogs.technet.com/b/markrussinovich/archive/2007/02/12/638372.aspx

TechEd sessions on Application Compatibility, Sysinternals utilities, and more

Aaron Margosis — Fri, 21 Jan 2011 07:27:49 GMT

TechEd sessions are available for on-demand viewing. Here are some recent ones that Chris Jackson (The App Compat Guy) and I have delivered recently on Application Compatibility and more...

What Everyone Should Know about Application Compatibility
(Aaron Margosis & Chris Jackson)
http://www.msteched.com/2010/NorthAmerica/WCL204

Inside the Application Compatibility Toolkit 5.6: Finding, Testing and Fixing Applications on Windows 7
(Chris Jackson)
http://www.msteched.com/2010/Europe/WCL404

The Black Art of Fixing Busted Applications Part 1: Win32 Application Compatibility
(Chris Jackson)
http://www.msteched.com/2010/Europe/WCL302

The Black Art of Fixing Busted Applications Part 2: Web Application Compatibility
(Chris Jackson)
http://www.msteched.com/2010/Europe/WCL303

What You Need to Know about Migrating from Internet Explorer 6 to Internet Explorer 8
(Chris Jackson)
http://www.msteched.com/2010/Europe/WCL315

Not for the Faint of Heart: Hard Core App Compat Debugging
(Chris Jackson)
http://www.msteched.com/2009/NorthAmerica/WCL401

Case of the App Compat Bug
(Aaron Margosis)
http://www.msteched.com/2010/NorthAmerica/WCL301

Aaron's Group Policy and Security Utilities (this one's about my Local Group Policy utilities and IEZoneAnalyzer)
(Aaron Margosis)
http://www.msteched.com/2010/Europe/WCL324

Windows Sysinternals Primer: Process Explorer, Process Monitor, and PsExec
(Aaron Margosis & Tim Reckmeyer)
http://www.msteched.com/2010/NorthAmerica/WCL314

Adobe Reader X

Aaron Margosis — Mon, 29 Nov 2010 17:28:00 GMT

Many of our customers make Adobe Reader part of their standard desktop image, or at least have it on the majority of their systems. Because of its ubiquity, Reader has become a major target for cybercriminals, with a scary increase in the number of exploited zero-day vulnerabilities over the last few years. When it’s Reader running on Windows that gets attacked (as it often is), our customers suffer.

Adobe has just released a major upgrade, Adobe Reader X, that should go a long way toward mitigating these attacks. Reader X incorporates a “Protected Mode” sandbox, not unlike the Protected Mode we implemented in Internet Explorer 7 and 8, in the Microsoft Office Isolated Conversion Environment (MOICE), and in Office 2010’s Protected View. Reader X’s Protected Mode should make it substantially harder to mount successful attacks against Windows computers via Adobe Reader. That’s good for our customers.

If you use Adobe Reader, you should begin evaluating Reader X right away.

This Adobe blog post announcing the release of Reader X includes links to additional information about its Protected Mode: http://blogs.adobe.com/asset/2010/11/adobe-reader-x-is-here.html

LUA Buglight tips: opening a report file

Aaron Margosis — Sat, 02 Oct 2010 05:05:21 GMT

I wish I had the time to write up proper documentation for LUA Buglight, the utility I wrote that identifies admin-rights issues in desktop applications. LUA Buglight is one of many "spare time" projects I work on, and for the past year and a half or so, it, like pretty much all my other "spare time" projects, has had to take a back seat to my taking over co-authorship of the Sysinternals Administrators Reference, working with Mark Russinovich. That "spare time" project has also consumed all my vacations. It's taking a long time because I'm very detail-oriented and am making sure to really get it all right. You're going to like this book. (Check out that link -- it references both of the other co-authors who tried and didn't survive. The third co-author is the charm.)

Anyway, no time for proper LUA Buglight documentation, but here's a tip. Say you have a LUA Buglight report file (extension .xml) and you want to view its contents. You can start up LuaBuglight.exe, then open the Reporter by choosing "Run LUA Buglight Reporter" from the Tools menu, then File | Open Report File from the Reporter's menu, and pick a file. OR... just specify the file you want to open on the LuaBuglight.exe command line:

Luabuglight.exe C:\Users\Abby\Documents\LuaBugLogs\MyReportFile.xml

To start the LUA Buglight Reporter directly but without an initial file, run LuaBuglight.exe with the /Reporter option:

Luabuglight.exe /reporter

Finally, you can right-click a LUA Buglight report file, choose Open With, and browse to find LuaBuglight.exe. From that point forward, LuaBuglight.exe will appear on the "Open With" context menu for XML files, as shown here:

Hope this helps!

Aaron Margosis @ Tech*Ed North America 2010

Aaron Margosis — Sat, 05 Jun 2010 15:43:00 GMT

Kind of late to be posting this, but better late than never. I'm presenting three sessions at Tech*Ed in New Orleans this week:

WCL204: What EVERYONE Should Know About Application Compatibility (co-presenting with Chris Jackson)
WCL301: Case of the App Compat Bug
WCL314: Windows Sysinternals Primer: Process Explorer, Process Monitor, and More (co-presenting with Tim Reckmeyer)

See y'all there!

Machine SIDs and Domain SIDs

Aaron Margosis — Thu, 05 Nov 2009 13:37:56 GMT

Microsoft Technical Fellow Mark Russinovich’s recent post “The Machine SID Duplication Myth” confused many readers who didn’t understand the distinction between the two independent SIDs that belong to a domain-joined computer. I’ll take a crack at trying to clarify that.

Machine and domain SIDs consist of a base SID and a Relative ID (RID) that is appended to the base SID. Think of the base SID by itself as identifying an authority within which accounts and groups can be defined. A computer is an authority within which local accounts and groups are defined. The computer has a machine SID, and the local accounts and groups have SIDs consisting of that machine SID plus a RID. For example:

Machine SID for computer DEMOSYSTEM	S-1-5-21-3419697060-3810377854-678604692
DEMOSYSTEM\Administrator	S-1-5-21-3419697060-3810377854-678604692-500
DEMOSYSTEM\Guest	S-1-5-21-3419697060-3810377854-678604692-501
DEMOSYSTEM\CustomAccount1	S-1-5-21-3419697060-3810377854-678604692-1000
DEMOSYSTEM\CustomAccount2	S-1-5-21-3419697060-3810377854-678604692-1001

SIDs (not names) are what are stored in access tokens associated with running code and in security descriptors associated with securable objects, and are what are compared by the security subsystem when performing access checks.

On a workgroup system, local accounts and groups are all there are. Mark’s assertion is that authentication to a remote system using a local account requires a user name and password known to the remote system, and that SIDs are not used. The only way anything resembling single sign on happens with local accounts is that if the remote system has the same user name and password that the caller is using. SIDs are not transmitted and are not used for remote authentication.

If the computer is joined to a domain, then another SID comes into play. The computer still has its own machine SID and its own local accounts and groups. But it is also a member of a domain, and so it has a SID representing its computer account within that domain. The domain is an authority within which accounts and groups (and other entities) can be defined – including computer accounts:

SID for domain BIGDOMAIN	S-1-5-21-124525095-708259637-1543119021
BIGDOMAIN\DEMOSYSTEM$ (computer account)	S-1-5-21-124525095-708259637-1543119021-937822
BIGDOMAIN\JOHNSMITH (user account)	S-1-5-21-124525095-708259637-1543119021-20937

DEMOSYSTEM now has two separate SIDs:

the machine SID which identifies it (locally) as an authority within which accounts and groups are defined (first row in the first table above); and
the computer account SID within the BIGDOMAIN domain (second row in the second table).

You can see the machine SID on your computer by running Sysinternals PsGetSid with no parameters. You can see the second SID on a domain-joined system by passing PsGetSid the computer name followed by a $: psgetsid %COMPUTERNAME%$

Mark’s point is that SIDs must be unique within the authority in which they are used. So while DEMOSYSTEM must have only one local account with the SID S-1-5-21-3419697060-3810377854-678604692-1000, it doesn’t matter if another computer uses the same SID to refer to a local account of its own. However, within the BIGDOMAIN domain, there must be only one computer account with the SID S-1-5-21-124525095-708259637-1543119021-937822. If multiple computers in the domain try to share that computer SID within the domain, problems will occur. So while it’s OK to clone a system before it joins a domain, doing so after it joins a domain (and is assigned a domain computer account and a corresponding domain SID) will cause problems.

Hope this helps!

LUA Buglight 2.1 released

Aaron Margosis — Tue, 03 Nov 2009 21:37:00 GMT

LUA Buglight 2.1, identifies admin-permissions issues ("LUA bugs") in desktop applications. New version supports Windows 7 (x86 and x64), Vista (x86 and x64), XP (x86 only) and corresponding Server OSes.

The download and more information is on this page:

http://blogs.msdn.com/aaron_margosis/pages/LuaBuglight.aspx

Utilities for Local Group Policy and IE Security Zones

Aaron Margosis — Fri, 02 Oct 2009 07:16:24 GMT

Because of my work with the Federal Desktop Core Configuration, I’ve published a set of three utilities that manage Local Group Policy. The newest of these (ImportRegPol) parses registry.pol files and can convert their content to text. I’ve also created a utility to view and compare IE security zone settings that is particularly helpful on a system that has been locked down with Group Policy.

I also wrote a blog post on the FDCC blog describing compatibility problems caused by a widely-deployed registry hack that tries to prevent Autoplay.

Utility	Description and Key Scenarios
Set_FDCC_LGPO	Applies full set of NIST FDCC settings into the Local Group Policy of a Windows XP or Windows Vista computer. Always applies Administrative Templates; FDCC security templates are optional. Current version not supported on versions of Windows other than XP and Vista (Win7 version to be created if/when NIST defines FDCC settings for Windows 7.) Intended for automated use; non-interactive. Intended as part of image building or image maintenance after deployment. Source code provided.
Apply_LGPO_Delta	Allows application of individual policy settings into the Local Group Policy of a Windows computer. These can include administrative template settings or security template settings. All input files are text-based, for ease of editing and customization. Intended for automated use; non-interactive. Designed to work in scenarios with Set_FDCC_LGPO. Primary purpose is to apply an organization’s variances from FDCC after running Set_FDCC_LGPO. Intended for same scenarios as Set_FDCC_LGPO. Source code provided.
ImportRegPol	Reads a registry.pol file and then does one or both of the following: 1) Applies settings from the registry.pol file to the Computer or User Configuration settings in Local Group Policy on the current computer; 2) Writes out the settings to a text file in a format that can be consumed by Apply_LGPO_Delta. Intended for automated use; non-interactive. Intended as part of image building. Source code provided.
IE Zone Comparer	GUI program to graphically display and compare two collections of IE security zone settings (policies or preferences for each of the security zones), highlighting settings that differ between the collections. Useful for seeing what settings are in effect (on a locked down system, the Security tab of the IE Properties dialog is mostly disabled), for comparing differences between zones, and more.

Live, on the internet...

Aaron Margosis — Tue, 16 Jun 2009 05:57:00 GMT

Ahoy, all -- Later this week I'll be appearing at a virtual roundtable hosted by Mark Russinovich, streaming live over the web. The topic is Windows 7 application compatibility. Among other things, I'll be demoing the latest (still-unreleased) updates to LUA Buglight (latest released version here).

Here are the details:

Springboard Series Virtual Roundtable

Windows 7 Application Compatibility: Your Questions Answered (Part 1)

Date: Thursday, June 18

Time: 11:00am Pacific Time

https://ms.istreamplanet.com/springboard

Windows 7, is approaching fast and from the application standpoint is very similar to Windows Vista. We’re going to examine Windows 7 application compatibility not only from the perspective of moving from Windows Vista, but also for those coming from Windows XP. Join us to discuss the most common challenges around application compatibility when coming from a legacy operating system, why changes were made along the way, compatibility technologies inside the OS and methods for getting incompatible applications to run on Windows 7. Along the way we share tips and tricks, demonstrate free tools to analyze and fix applications and answer your specific questions about application compatibility live.

In Part 2 of this Virtual Round Table discussion (planned for later this Summer/Fall), we’ll discuss the options and approaches for using virtualization tools In depth to address application incompatibilities – including presentation virtualization, desktop virtualization and application virtualization. We’ll be sending out more details and posting information to www.microsoft.com/springboard for part 2 as the dates are finalized.

As part of the “virtual” experience, you may submit your questions about Windows 7 Application Compatibility to the panel live during the event—or submit questions in advance to vrtable@microsoft.com.

Springboard Series: The resource for Windows desktop IT professionals

FAQ: How do I start a program as the desktop user from an elevated app?

Aaron Margosis — Sat, 06 Jun 2009 07:19:00 GMT

Common Vista/Win7 scenario: the app you’ve written runs with elevated permissions, but then needs to start another program as the non-elevated desktop user. For example, you want to display web content. Now, you could just launch the web browser from your app, and let the web browser run as admin. What could go wrong? (Hint: the correct answer will include the word “catastrophic”)

A very common mistake that programmers make is to grab a copy of the elevated, High Integrity Level access token from the current process and then “dumb it down”. I.e., disable powerful group memberships, remove powerful privileges, and change the integrity level to Medium. They then launch the new process with that “dumbed down” token. This breaks for a number of reasons.

The new “LUA bug” of Vista/Win7

First and foremost, that approach makes the invalid assumption that the elevated app is running under the same user identity as the desktop user who originally logged on. This is the new “LUA bug” of Vista and Win7. (Refresher: “LUA” = “limited user account”; “LUA bug” = failure that occurs when running as LUA and not administrator. #1 cause of LUA bugs: assumption that the end user will be an administrator.) In Vista/Win7, everything runs as “LUA” by default, unless you specifically allow something to run elevated. If you’re a member of the Administrators group, by default this involves a simple “consent” prompt. The resulting app still runs as you, but with full admin rights. If you’re not a member of Administrators, the elevation prompt requires the credentials of another account that is a member of Administrators. The resulting app then runs as a different user. A number of apps fail to take this second scenario into consideration. “Dumbing down” the current process token is one example of that kind of failure. The new program runs with reduced permissions, but not as the intended user.

There are at least a couple of other failures in that approach too, that are more obscure. Let’s say you are a member of Administrators. When you log on, the Windows LSA (Local Security Authority) generates two access tokens in two separate LSA-managed logon sessions. One is the fully privileged, full-admin token; the other is the standard-user version, which is marked as linked to the full-admin token. When you create a “dumbed-down” copy of the elevated one, the new token is still associated with the elevated session, and marked as being the “high half” of a split token. As a result, if you start Internet Explorer with that token, Protected Mode will be disabled. Also, if your “dumbed-down” process tries to launch an elevated app, it will simply launch the new process with the “dumbed-down” token, since it’s already marked as “elevated.”

“Enough nerditude. Tell me what I need to do.”

So here’s one sequence that works well:

Enable the SeIncreaseQuotaPrivilege in your current token (sample)
Get an HWND representing the desktop shell (GetShellWindow)
Get the Process ID (PID) of the process associated with that window (GetWindowThreadProcessId)
Open that process (OpenProcess)
Get the access token from that process (OpenProcessToken)
Make a primary token with that token (DuplicateTokenEx)
Start the new process with that primary token (CreateProcessWithTokenW)

I’ve attached an example C++ project, built with VS2008 and the MFC AppWizard, and tested with x86 and x64 builds. The meat of the sample is in RunAsDesktopUser_Implementation.cpp. I’m sure it can be done in managed code, but that will be someone else’s project, not mine.

Caveats

Please note that there are a bunch of caveats about this approach:

This runs the new program in the same context as the desktop shell. If the desktop shell process is not running (crashed or intentionally terminated), GetShellWindow fails, and there is no process token to do anything with. Also, GetShellWindow fails if the default shell (Explorer) has been replaced with a custom shell.
If you have terminated the desktop shell and restarted it elevated (strongly discouraged), then the new process will also run elevated – as will pretty much everything else you start.
This code assumes that it is running already elevated. If you’re not running elevated, then there is no need for this code. If you’re not running as admin, then the necessary step of enabling SeIncreaseQuotaPrivilege won’t work anyway.
CreateProcessWithTokenW requires Vista or newer. So: this approach won’t work on pre-Vista (e.g., XP with runas); and if you want to incorporate this code in a program that can run on XP/2003, you need to use LoadLibrary/GetProcAddress to get the CreateProcessWithTokenW entry point.

"LUA Bug" demo app

Aaron Margosis — Fri, 07 Nov 2008 16:55:00 GMT

I do a lot of presentations on how to identify and fix "LUA bugs" in applications (*), both for Windows XP and Windows Vista. I frequently use a little VB6 application to demonstrate writing to various portions of the file system and registry, write to .ini files in protected locations, restart services, explicitly check for admin rights, etc. People have asked me to post that app to my blog so that they can use it too. So here it is, including the VB6 project/source code.

As is, no support, hopefully it's self-explanatory!

Chris Jackson has a more elaborate demo app with full lab script, geared toward application compatibility tools and techniques on Vista. You can get it here.

(*) "LUA" = "limited user account", a.k.a., "non-admin", "standard user"
"LUA bugs" = application or feature of an application that 1) works when run by a member of Administrators or Power Users; 2) fails when run by a standard user; and 3) has no valid business or technical reason for requiring administrative control over the computer.

LUA Buglight 2.0, second preview

Aaron Margosis — Thu, 06 Nov 2008 14:05:00 GMT

LUA Buglight is a utility that helps identify "LUA bugs" in applications -- application features that that fail as standard user but that work as administrator. I work on it in my spare time, so progress has been slow. Attached to this blog post is the second preview version of LUA Buglight 2.0.

Main changes since the previous preview:

Single executable: all the helper DLLs, EXEs, etc., are self-extracted to your temp folder when you run the program. No need to copy lots of files around.
For Vista: the helper program that requires elevation is now signed, so you get the nicer elevation prompt. The driver file for Vista is signed as well, so startup is much faster.
Explicit check for x86 -- sorry, the current version cannot be used on 64-bit versions of Windows.
Various bug fixes.

Some of the improvements of LUA Buglight 2.0 over 1.0:

Much better Vista support
Streamlined UI and improved flow
Identifies more bugs
On XP, not restricted to using a local admin account to create the "this-user-as-admin" context
On Vista, prompts for elevation just one time per session instead of for each test
Log file names autogenerated with timestamp in the name to avoid accidental overwrite of previous logs.
User options saved to the registry.

Updated: Attachment removed, as LUA Buglight 2.1 is now available here.