Many sysadmins might question how this app ever got accepted into our environment with such a huge security flaw. The answer is simple: corporate policy didn't include running all desktops in limited-user mode. We still had a large selection of systems running on Windows 98 (for which "basic user" was not an option), and allowed users to run on Windows 2000 and Windows XP as local admins. We never caught the limitation during initial acceptance testing.
We were finally standardized on Windows XP when the policy change came that allowed us to switch end users from administrative to limited-user, but because the application was in limited distribution through our user base, it wasn't in the original test cases for switching to limited users. After the handful of users started submitting the same issue, we spent a while troubleshooting the app before we realized the common thread: it misbehaved only when running in the context of a limited user. While looking for a solution, we left the handful that required the app to continue to run their sessions in administrative mode. Remaining an administrative user was not an acceptable solution.
Luckily, Windows XP provides the "runas" utility, which permitted us to create a dedicated domain user that could have local admin rights as well as network access (a requirement of the application). With some limited, additional configuration, the special user account credentials could be used in an obfuscated batch file, and the primary user account could remain "limited". It worked beautifully.
Enter Windows 7.
Actually, the problem started with Windows Vista and the introduction of UAC (user account control), but because we never accepted Vista into the corporate environment, it wasn't an issue until Windows 7.
Being security conscious, we never considered disabling UAC for systems; however, that nicety became a burden on our use of our misbehaving application and the XP-type workaround: We could still use the alternate user, but UAC remained a barrier to the application, even when logged on as a local administrator.
So we experimented with ways to get an elevated session:
- We tried 3rd-party tools, but they didn't work unless you were already in an administrative session
- We tried "XP Mode", which was fine as long as we didn't try to access network resources; the standard user in the virtual environment is a local administrator for the system—something that should bother everyone using it.
After much trial-and-error, we discovered that a "nested" execution would work:
- we use "runas" to create the execution environment for an administrative user
- inside the session "bubble" that runas creates, we use the 3rd-party tool "NirCMD" to launch the pesky application in an elevated session.
The shortcut looks a bit like this:
runas /user:domain\special /savecred "c:\windows\system32\nircmd.exe elevate c:\progra~2\pesky\pesky.exe"
You can get nircmd.exe at nirsoft.net; they have a number of nice, free utilities that can make your life easier.
The solution isn't perfect—a basic UAC prompt is still displayed—but it requires no user to remember alternate credentials. There are also setup requirements for preparing the administrative user's local profile (for network printers) and saving the administrative user credentials (prompted at first run), but until we can retire the application, we now have a working solution.
UPDATE: Changed link for NirSoft; the original post was incorrect.
