Execute PowerShell Scripts with a Restricted Execution Policy

 

By default, PowerShell will default to an execution policy of Restricted.  Hopefully this is not a surprise to anyone.  However, it is possible to execute scripts under this policy.  Simply start the shell using the ExecutionPolicy parameter.

For example, in our server loads, we need to prompt for an administrative password during the post-install process.  Previously, in W2K3, we were able to use the ScriptPW object to mask the input.  The object no longer exists in W2K8, so a different solution was needed.  Powershell provides the Read-Host cmdlet, which includes the AsSecureString parameter.  Using that cmdlet, I created a simple script that would prompt for the password.

I then needed to run the script automatically, but didn’t want to change the default execution policy.  To solve this, one can specify a one-time execution policy when starting the shell.

powershell -ExecutionPolicy RemoteSigned –File c:\postinstall\password.ps1

Happy 10th PromoDay <widgets>.com

 

My forest[1] celebrated the ten-year anniversary of the initial promotion today.  We had upgraded from an NT4 multi-master configuration, so this was a new promotion to become the empty root.  The account domains were slowly upgraded over the next year.  Technically, the domain services as a whole are more than 10 years old, but the official NT4 dates are lost to the sands of time.

c:\>adfind -config -f name="Enterprise Configuration" whencreated -alldc

AdFind V01.40.00cpp Joe Richards (joe@joeware.net) February 2009

Using server: xxxx.xxxx.com:389
Directory: Windows Server 2003
Base DN: CN=Configuration,DC=xxxx,DC=com

dn:CN=Enterprise Configuration,CN=Partitions,CN=Configuration,DC=xxxx,DC=com
>whenCreated: 2000/04/12-19:25:22 Eastern Daylight Time

1 Objects returned

We held a party for it today, and even got a “PromoDay” cake.

 

[1] Not technically “my forest”.  It does belong to the widget company for which I work, and I didn’t even work for them 10 years ago, and had nothing to do with its creation.  joe was responsible for most of it [2].  These days there are 5 EAs with operational responsibility, and me with engineering responsibility who can likely continue to call it “ours”.

[2] There are a lot of good stories about the early days of our AD.  This event brought out a few of them from ensuring joe didn’t promote the forest as joe.com to the buddy builds that were delivered almost daily as we pushed the scalability limits of Windows 2000 beyond what Microsoft had yet seen, but they’re joe’s to tell, not mine.  Go read about them if you want.

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.