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

Effective permissions may be reported incorrectly

Scenario

Using a Domain member computer, the "Advanced / Effective Permissions"
tab is used to evaluate permissions for specific user on a folder.

In this example, \\[Server]\[Share]\[Folder] and the user specified is a member of the local Administrators group on the Domain Member computer. The "effective permissions"
tab reports that the user holds Full Control for the folder.

Cause
Member computers of a domain are only able to perform group expansion for Built-in groups locally. Thus when the account context is evaluated the Built-In\Administrators membership is returned.

Universally, the SID for Builtin\Administrators is S-1-5-32-544, which cannot be distinguished between the local computer group membership and local server group membership by the "Effective Permissions" tab.

More Information
Permissions for user accounts that are not members of the local computer Administrators group are not affected by this issue.

This issue does not occur if the computer used to evaluate permissions is a domain controller or the server hosting the resource.



Access control lists may report incorrect information in Windows Server
2003
http://support.microsoft.com/kb/884049

Access a Network Resource Alias using Computer Account

Using a centralised Windows source location, we received "Access Denied", whilst trying to access the network resource using the "System" computer account context.

The SMS package was running in the system account context and attempting to access a network resource using an Alias (CName) record.

Example: \\ALIASNAME\Share

Issue:

A process running as the local system reports "Access Denied" when trying to access an alias network resource.

Access using an interactive account is successful as the "DisableStrictNameChecking" registry modification has been applied to the machine hosting the network resource.

Resolution:

Register the SPN for the alias name.

setspn -A HOST/ALIASNAME.domain.com SERVERNAME

Registering ServicePrincipalNames for
CN=SERVERNAME,DC=domain,DC=com
HOST/ALIASNAME.domain.com
Updated object

The workstation accessing the resource may need to be restarted in order for access using the new SPN to be successful, with the reboot requirement possibly due to caching of the SPN entries. Alternatively, the computer account tickets may be purged.

The Windows Support tool, klist.exe may be used to view the list of tickets that the computer has been granted.
Usage;
klist tickets

Further Information:

By default, when accessing resources in a Windows 2000 or later environment, Kerberos is the preferred authentication method and if unsuccessful the authentication falls back to NTLM.

As part of the Kerberos authentication, the user (in this case the computer account) is unable to receive a valid service ticket for the resource hosted on the alias computer.
Accessing the same resource using the actual host name \\ServerName\Share is successful as the Kerberos AS is able to locate a registered service principal name (SPN) for the service. Once located, the requesting user is granted a valid service ticket for the machine hosting the resource.

In the case of the computer accessing the resource using the alias, the computer supplies an unknown SPN (ALIASNAME) during Kerberos authentication, from which Kerberos authentication subsequently fails.

Authentication then falls back to NTLM, which also fails for the process running in the computer account context.
Connections to network resources using the computer account are established using a Null session with no credentials manifesting in the "Anonymous Logon" context.
The use of "Anonymous Logon" results in Access Denied. Whilst it is possible to configure the server to allow Anonymous Logons the security of the system is considerably weakened.

Refer to the "Local Service account" section in the "Service account permissions" article for information on Null Session and accessing Network resources.

Thanks goes to http://waynes-world-it.blogspot.com/ for his assistance.

Alias management

A collegeague asked what would happen if the DNS alias was changed to point to a different host?

Well of course we both knew that it wouldn't work properly, but the real question was about finding out the detail and how an Administrator would work out that the SPN also required changing.

As expected if the DNS alias is modified to point to a different host, the following error is returned when accessing the share.

Logon Failed: The target account name is incorrect.

As I implemented the SPN it was obvious enough that the SPN needed to be modified, however, for someone that didn't implement the SPN, it would be understandable that it may take a bit of finding...

A dump of the tickets information showed that a valid ticket had been granted for the ALIASNAME.domain.com which may not be enough to jog the memory of the administrator.

The following DSQuery command shows the host that holds the SPN associated with the alias name.

dsquery * domainroot -limit 0 -filter "(&(objectCategory=Computer)(servicePrincipalName=*ALIASNAME*))" -attr cn

The output verified that the incorrect host was holding the SPN for the Alias, and using the SetSPN command the Service Principal Name can be correctly added to the correct host.

References:

Kerberos Explained
http://technet.microsoft.com/en-us/library/bb742516.aspx
Users experience authentication issues when they access a Web page in IIS 6.0 or query Microsoft SQL Server 2000 after you install Windows Server 2003 Service Pack 1
http://support.microsoft.com/kb/887993
Kerberos is not used when you connect to SMB shares by using IP address
http://support.microsoft.com/kb/322979
Kerberos protocol registry entries and KDC configuration keys in Windows Server 2003
http://support.microsoft.com/kb/837361
Kerberos Authentication Tools and Settings http://technet2.microsoft.com/windowsserver/en/library/b36b8071-3cc5-46f
a-be13-280aa43f2fd21033.mspx?mfr=true
Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name
http://support.microsoft.com/kb/281308
Overview of Server Message Block signing
http://support.microsoft.com/kb/887429
Windows Authentication
http://technet2.microsoft.com/windowsserver2008/en/library/f3cd26b1-a948
-46b7-a8ee-f2fde84f93f81033.mspx?mfr=true
NTLM user authentication in Windows
http://support.microsoft.com/kb/102716
MSV1_0_LM20_LOGON Structure
http://msdn2.microsoft.com/en-us/library/aa378762(VS.85).aspx
PRB: Access Denied When Opening a Named Pipe from a Service
http://support.microsoft.com/kb/126645
Service Running as System Account Fails Accessing Network http://support.microsoft.com/kb/124184/
Service account permissions
http://technet2.microsoft.com/windowsserver/en/library/a958b9d2-3ec1-4ab
0-9f9f-7cb396605f3e1033.mspx?mfr=true

Ever needed an Automated RunAs?

I went down this path for a Microsoft Deployment Toolkit (BDD) SOE build, as it was running in the wrong context for inserting details into a SQL database (computers and members of an Active Directory Group had access but the local administrator account didn't).

This powershell script accepts a number of arguments and then launches the process as the specified user;

Usage:
Start-RunAs.ps1 process Path [Arguments] [Domain] [User] [Password]

Examples;
Start-RunAs.ps1 "notepad.exe" "$($Env:SystemRoot)\System32"
Start-RunAs.ps1 "notepad.exe" "$($Env:SystemRoot)\System32" "" "domain"
"user"
Start-RunAs.ps1 "notepad.exe" "$($Env:SystemRoot)\System32" ""
"password" "user" "password"


The script could do with some tidying up for day to day use, but you get the idea...


Whilst I have some misgivings about the security of the "SecureString" it may be useful for some user's who wish to run their shell using Principle of Least Privilege...

Probably most notably though was the exercise and the way the PSH team decided to implement the SecureString concept.

It doesn't seem too secure, but as the PSH team offer, it wasn't meant to be, after all the owner of the process (interactive user) already knows the password they just typed in.

The following Powershell code snippet suggests that the password entry is secure. However, in the current session, the password can be found.

$PWD = Read-Host "Enter your password" -assecurestring[Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServi
ces.Marshal]::SecureStringToBSTR($PWD))

Running the above commands results in;
Enter your password:: ****
System.Security.SecureString
Test

Still from the angle of security by obscurity, it would stop most prying eyes.


A simpler Runas I hear you ask?

$psi = New-Object System.Diagnostics.ProcessStartInfo "notepad.exe"
$psi.Verb = "runas"
[System.Diagnostics.Process]::Start($psi)

This launches the RunAs GUI, and then the process.

ConvertTo-SecureString
http://technet.microsoft.com/en-us/library/bb978707.aspx

http://www.leeholmes.com/blog/PowerShellCredentialsAndGetNetworkCredential.aspx

Windows PowerShell Securing the Shell
http://technet.microsoft.com/en-us/magazine/cc137808.aspx


param( [string] $FileName = $(throw "Please specify a filename to execute"),
[string] $FilePath = $(throw "Please specify a path to the filename"),
[string] $Arguments,
[string] $UserDomain,
[string] $UserName,
[string] $UserPassword
)

$Scripts = Split-Path $Myinvocation.Mycommand.Path
# Start a specified process as a specific user (RunAs)
#Set Error Handling
$ErrorActionPreference = "SilentlyContinue"
$Me = "Start-RunAs"
# Ensure the supplied filename/path exists
$TaskDesc = "Verify FileName exists"
get-item $FilePath\$FileName
If ($? -eq $False) {
Write-Host " $($TaskDesc) $($Error[0])"
Exit 1
}
# When a username but no password has been supplied, request credentials from user
If ($UserName -ne "" -and $UserPassword -eq "") {
$TaskDesc = "Request User Credentials for $($UserName)"
$UserCred = Get-Credential "$($UserDomain)\$($UserName)"
If ($? -eq $True) {
$UserDomain = $UserCred.UserName.Split("\")[0]
$UserName = $UserCred.UserName.Split("\")[1]
$UserPassword = $UserCred.GetNetworkCredential().Password
} Else {
Write-Host " $($TaskDesc): $($Error[0])"
Exit 2
}
$UserPassword = $UserCred.GetNetworkCredential().Password
} Else {
# present a blank credentials window for the user to populate
$TaskDesc = "Request User Credentials"
$UserCred = Get-Credential
If ($? -eq $True) {
$UserDomain = $UserCred.UserName.Split("\")[0]
$UserName = $UserCred.UserName.Split("\")[1]
$UserPassword = $UserCred.GetNetworkCredential().Password
} Else {
Write-Host " $($TaskDesc): $($Error[0])"
Exit 2
}
}

# A local domain can also be specified
$DOMAINUSER = $UserName
$DOMAINUSERPASSWORD = $UserPassword
$DOMAINUSERDOMAIN = $UserDomain

$SleepInterval = 2
# Number of seconds to wait for process to exit
$psi = New-Object System.Diagnostics.ProcessStartInfo "$($FileName)"
# Configure other process execution parameters
$psi.UseShellExecute = $False
$psi.UserName = $DOMAINUSER
$psi.Password = ConvertTo-SecureString "$($DOMAINUSERPASSWORD)" -AsPlainText -Force
$psi.Domain = $DOMAINUSERDOMAIN
$psi.WorkingDirectory = $FilePath
# $psi.WindowStyle = "Hidden"
$psi.Arguments = $Arguments

$TaskDesc = "Execute process;
"Write-Host "$($TaskDesc)"
Write-Host "$($psi.WorkingDirectory)\$($psi.FileName) $($psi.Arguments) as user $($psi.Domain)\$($psi.UserName)"
$ProcessStart = [System.Diagnostics.Process]::Start($psi)
If ($?) {
While ($ProcessStart.HasExited -ne $TRUE) {
Start-Sleep -s $SleepInterval
}
$ProcessStart.HasExited
} Else {
Write-Host "$($TaskDesc) failed, $($Error[0])"
}

Permissions for Moving a Computer Account

How to Grant Permission to Move Computer Accounts to a User or Group

http://support.microsoft.com/kb/818091

Summarising this article, the permissions you need to allocate to an account object for creating and moving (deleting!) computer accounts in the domain.

Create account in OU
Read access for OU's from the top-level domain, down the tree to the OU. Very Important
Create/Delete "Computer Objects"
Reset/Change Password for "Computer Objects"

Move account out of an OU (Delete!!)
As per Create
Write all properties this is the key permission that allows objects to be moved out of the OU