User Account Control (UAC) and NSUpdate

At work, I run my Vista SP2 system as a standard user with UAC turned on.  For the most part, UAC doesn’t cause me any problems in my day-to-day duties, except for one item.  Our DNS infrastructure runs on a BIND variant.  As such, nsupdate.exe is a common command-line support tool.  Similar to most other remote service management tools, the tool has no local security requirements.  However, attempting to run nsupdate on Vista creates an elevation prompt.  Using Windows Explorer, one can verify the executable is marked with the UAC shield.

However, only nsupdate.exe is marked – none of the other BIND tools are marked.  Additionally, I found that renaming the file to something like nsupdat2.exe caused UAC to no longer prompt for elevation.

It turns out, there’s logic in UAC for elevating based on filename, regardless of local security requirements.  This allows update installers to be elevated appropriately.  However, nsupdate.exe is an innocent victim of a flawed heuristic detection pattern, like a false-positive from an AV signature.

To prevent UAC from forcing elevation of a process that doesn’t require it, this automatic prompting due to Installer Detection, can be turned off.  http://technet.microsoft.com/en-us/library/cc709628(WS.10).aspx provides an overview of the feature and its possible configurations.  In local security policy, navigate to Local Policies, Security Options and set User Account Control: Detect application installations and prompt for elevation to Disabled.  When this policy is enabled, which is the default, any filename which contains “update” will trigger elevation.  When disabled, this detection is turned off, and attempting to use nsupdate.exe no longer causes an elevation prompt.  I see this as a much better solution than renaming the file.  Now I can use nsupdate.exe as a standard user.