Preventing users from executing files using Software Restriction Policies

Traditionally I have used NTFS permissions to restrict access for standard user accounts to certain executable files.

Most notably is reg.exe, when providing a managed workstation (SOE) to prevent standard users from accessing the registry. When coupled with Group Policy to restrict access to registry editing tools (regedit) it is effective in preventing access.

One alternative I had overlooked until recently was Software Restriction Policies. These can be applied as per most policies at the local or Group Policy level.

Summary:
A user with full permissions to a directory can be blocked from executing files using the Software Restriction Policies.

Using the "Disallowed" Security level, prevents execution regardless of the NTFS permissions the user holds, using Unrestricted honours the user account NTFS permissions.

Example:
User has Full Control of the folder C:\Test

Create a New Path rule by running GPEdit.msc
Local Security Policy / Software Restriction Policies / Additional Rules (Same location for a GPO)
New Path Rule
Path: C:\Test
Security Level: Disallowed

When the user executes a file from the path, the system prevents execution of the file.

C:\test\notepad.exe
The system cannot execute the specified program.

This could be applied to the SOE reg.exe scenario outlined earlier.

Another use I can see for this is to have a "scripts / tools" directory that the system can execute from Using a local System scheduled task, but those pesky users can't.

The following Microsoft articles list there purported uses of the facility, but this is interesting if nothing else and provides another tool for SOE builds that I hadn't considered using before.


Other rules can be specified to identify software including

Hash. A cryptographic fingerprint of the file
Certificate. A software publisher certificate used to digitally sign a file
Path. The local or universal naming convention (UNC) path of where the file is stored
See also "Registry Paths" as outlined in the reference documents.
Zone. Internet Zone

Using Software Restriction Policies to Protect Against Unauthorized Software
http://technet.microsoft.com/en-us/library/bb457006(TechNet.10).aspx

How Software Restriction Policies Work
http://technet2.microsoft.com/windowsserver/en/library/d24bc8c8-27cc-47ba-9b02-78d9d801e9371033.mspx?mfr=true

SysPrep may not perform FullUnattend as expected

Issue:

When you supply a SysPrep answer file, SysPrep may not process the answer file as you expect. The Mini-Setup wizard stops processing and requests user input.

Cause:

One cause of this may be the use of comments within the SysPrep file. Sysprep.inf comments are denoted by the semi-colon (;) character. When a comment character is included on a line in the Sysprep.inf file, the complete line is omitted from processing.

Workaround:

Move the comment to a separate line of its own.

Example:

AutoMode=PerSeat ; Licensing Mode usually perseat

change the line as follows;

; Licensing Mode usually perseat
AutoMode=PerSeat

Installing device drivers without the device being present

Having completed a number of SOE unattended installations, I have had reason to be able to install device drivers without the device being present. Attempts to install drivers without the device present using well known driver installation tools such as devcon.exe and dpinst.exe, failed to load the device drivers.

During investigation of the process I reviewed the device installation log file, %SystemRoot%\setupapi.log. In hindsight, the log file is quite aptly named in that functions within the setupapi.dll are called to install devices during windows setup and driver installation programs. This was shown by log entries from the devcon and dpinst programs.

Searches for setupapi.dll eventually showed that the SetupCopyOEMInf function is used to install the devices. Which in turn led to Pyron's SetupCopyOEMInf.exe utility. Whilst the utility is fantastic and performs device installation flawlessly, I was after something that could be manipulated if required.

Enter Powershell!

Utilising managed API calls, I was able to write a powershell script that calls the SetupCopyOEMInf function whilst maintaining the flexibility that scripting offers. Whilst by no means the right solution for everyone, this approach further demonstrates the capabilities of powershell.

In summary, the script installs the device drivers without the device being present.

During a standard user session, the device can be plugged in and the device drivers are loaded without prompting for Administrator credentials.

param(
[string] $DriverDir = $(throw "Please specify a directory of drivers to process")
)

$Scripts = Split-Path $Myinvocation.Mycommand.Path
# Copy a Driver to the OEM path (Install driver without the device being present)
#
# 
# References
# http://monadblog.blogspot.com/2005/12/calling-win32-api-functions-through.html
# http://www.pinvoke.net/default.aspx/setupapi.SetupCopyOEMInf
#
# Set Error Handling
$ErrorActionPreference = "SilentlyContinue"
$Me = "SetupCopyOEMInf"
$provider = new-object Microsoft.VisualBasic.VBCodeProvider
$params = new-object System.CodeDom.Compiler.CompilerParameters
$params.GenerateInMemory = $True
$refs = "System.dll","Microsoft.VisualBasic.dll"
$params.ReferencedAssemblies.AddRange($refs)
# Find all the .inf files in the specified directory
$TaskDesc = "Locate INF Files"
$TempDir = Get-ChildItem $DriverDir -filter '*.inf' -recurse
If ($? -eq $False) {
    Write-Host "Invalid directory $($DriverDir)"
    Exit 1
}

$txtCode = @'
Class CopyOEMInf
Private Declare Function SetupCopyOEMInf Lib "setupapi.dll" Alias "SetupCopyOEMInfA" (ByVal SourceInfFileName As String, ByVal OEMSourceMediaLocation As String, ByVal OEMSourceMediaType As Long, ByVal CopyStyle As Long, ByVal DestinationInfFileName As String, ByVal DestinationInfFileNameSize As Long, ByRef RequiredSize As Long, ByVal DestinationInfFileNameComponent As String) As Long

Public Function Main(ByVal sInf As String, ByVal sDir As String) As Long
    Const SP_COPY_NEWER As Integer = &H4
    Dim lngResult As Long
    Dim ret2 As String
    Dim ret3 As String

' Install the driver'
    lngResult = SetupCopyOEMInf(sInf, sDir, 1, SP_COPY_NEWER, ret2, 255, 255, ret3)
    Return(lngResult)
End Function
end class
'@

$cr = $provider.CompileAssemblyFromSource($params, $txtCode)
if ($cr.Errors.Count) {
    $codeLines = $txtCode.Split("`n");
    foreach ($ce in $cr.Errors) {
        Write-Host "Code compilation error, line $($ce.Line - 1)"
        write-host "Error: $($codeLines[$($ce.Line - 1)])"
    write-host $ce
    }
    Throw "INVALID DATA: Errors encountered while compiling code"
} 

$mAssembly = $cr.CompiledAssembly
$i = $mAssembly.CreateInstance("CopyOEMInf")
# Process each inf file found

$TempDir ¦ foreach {
    Write-Host "Installing Driver $($_.Get_FullName().ToString())"
    $r = $i.Main($_.Get_FullName().ToString(), $_.Get_Directory().ToString())
}

References
Troubleshooting Device Installation with the SetupAPI Log File
http://www.microsoft.com/whdc/driver/install/setupapilog.mspx
Pyron setupcopyoeminf
http://www.msfn.org/board/Unlimited-number-of-drivers-keeping-th-t43795.html&p=303959#entry303959

http://waynes-world-it.blogspot.com/
Thanks goes to Wayne for introducing the concept and code snippets for compiling managed code from unmanaged scripts.

Windows XP reboots during setup

Issue:
During an unattended setup of Windows XP, the system reboots at T-30 when configuring the network.

Cause:
One cause of this issue is that a duplicate name exists on the network.

Resolution:
Remove the name conflict by either shutting down the existing computer or renaming the computer you are performing an unattended build on.

Set Location in "Regional and Language Options" control panel applet

Having done my share of unattended XP builds for various, invariably one of the items that I am asked is how to change the Country under the Location Tab found in the "Regional and Language options" Control Panel applet.

Originally, this took some finding as it is doesn't appear to be a supported entry for sysprep.inf or unattend.txt.

HKU\.Default\Control Panel\International\Geo
OR
HKCU\Control Panel\International\Geo
Value: Nation
Type: REG_SZ
Data: "12"

(0xC) 12 is the code for Australia.

Tip: To set this in an unattended build, set the HKU\.Default\Control Panel\International\GEO value, as SysPrep does not apply this setting to all users when the HKCU setting is configured.

A complete list of nation codes can be found at
http://msdn2.microsoft.com/en-us/library/ms776390(VS.85).aspx
GetGeoInfo
http://msdn2.microsoft.com/en-us/library/ms776300(VS.85).aspx

Hiding or Displaying Default Desktop icons

The default desktop icons can be hidden or displayed using the registry or Group policy. However, before they can be managed using Group Policy the icons must have the following registry keys present.

{20D04FE0-3AEA-1069-A2D8-08002B30309D} - My Computer
{450D8FBA-AD25-11D0-98A8-0800361B1103} - My Documents
{208D2C60-3AEA-1069-A2D7-08002B30309D} - My Network Places
{871C5380-42A0-1069-A2EA-08002B30309D} - Internet Explorer
{645FF040-5081-101B-9F08-00AA002F954E} - Recycle Bin

A DWORD value of 0 displays the icon, 1 hides the icon.
Setting this value in HKCU takes precedence over HKLM.

To hide the icons from the Start Menu add the Key and value to - \Software\Microsoft\Windows\CurrentVersion\Explorer\HideDesktopIcons\ClassicStartMenu To hide the icons from the Desktop add the Key and value to - \Software\Microsoft\Windows\CurrentVersion\Explorer\HideDesktopIcons\NewStartPanel