permissions | Tom's Notes

Utilman.exe to cmd.exe and back

By Tomica Kaniski in Other 03/12/2020 0 Comment

Let’s say you have a Windows (virtual) machine, for which you’ve forgotten your login info, but you want to enter it anyway, because of… reasons. 😀

How can you do it?

Note – if the disk/VM is encrypted, you’ll need the decryption key, of course (if you don’t have it, well… I’m sorry, the following won’t really help you).

Ok, if it’s a virtual machine and you only need to grab some data from it, it’s relatively easy – you’ll just mount the virtual disk, extract the data needed and done.

If you need access to the OS instead, you can maybe use the old trick with replacing the Utilman.exe with cmd.exe, which essentially gives you command prompt with local system permissions, which then gives you… well, everything you need.

One minor obstacle with doing this “hack” would be the fact that the owner of Utilman.exe is actually the TrustedInstaller, so your workflow would be like this:

(e.g. turn off the VM, mount the disk, …)
replace the owner of Utilman.exe
add yourself the needed permissions
replace the Utilman.exe with cmd.exe
do what you need (e.g. change the local Administrator’s password, set this account as active, …)
cleanup (replace the replaced Utilman.exe with the original one)

And we can do this with PowerShell:

$file = "D:\Windows\System32\Utilman.exe"
$user = New-Object System.Security.Principal.NtAccount("tomica")

# replace the owner of Utilman.exe
$acl = Get-Acl -Path $file
$acl.SetOwner($user)
$acl | Set-Acl -Path $file

# add yourself the needed permissions
$acl = Get-Acl -Path $file
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule($user,"Full","Allow")
$acl.SetAccessRule($rule)
$acl | Set-Acl -Path $file
(Get-Acl -Path $file).Access | Format-Table IdentityReference,AccessControlType,FileSystemRights -AutoSize

# replace the Utilman.exe with cmd.exe (and move Utilman.exe to Utilman.exe.bak)
Move-Item -Path $file -Destination "$file.bak"
Copy-Item -Path "D:\Windows\System32\cmd.exe" -Destination "D:\Windows\System32\Utilman.exe"

# unmount disk, start the VM, use Accesibility Wizard icon on logon screen to start up the system/admin command prompt

# change password, enable local Administrator account
net user Administrator MyNewestPass123!
net user Administrator /active:yes

$file = "D:\Windows\System32\Utilman.exe"

$user = New-Object System.Security.Principal.NtAccount("tomica")

# replace the owner of Utilman.exe

$acl = Get-Acl -Path $file

$acl.SetOwner($user)

$acl | Set-Acl -Path $file

# add yourself the needed permissions

$acl = Get-Acl -Path $file

$rule = New-Object System.Security.AccessControl.FileSystemAccessRule($user,"Full","Allow")

$acl.SetAccessRule($rule)

$acl | Set-Acl -Path $file

(Get-Acl -Path $file).Access | Format-Table IdentityReference,AccessControlType,FileSystemRights -AutoSize

# replace the Utilman.exe with cmd.exe (and move Utilman.exe to Utilman.exe.bak)

Move-Item -Path $file -Destination "$file.bak"

Copy-Item -Path "D:\Windows\System32\cmd.exe" -Destination "D:\Windows\System32\Utilman.exe"

# unmount disk, start the VM, use Accesibility Wizard icon on logon screen to start up the system/admin command prompt

# change password, enable local Administrator account

net user Administrator MyNewestPass123!

net user Administrator /active:yes

And now you can login as local Administrator again and do the work you wanted to do in the first place. 😊

To leave things in (somewhat) the way we found them, we can use the following PowerShell:

# replace the owner of Utilman.exe
$file = "C:\Windows\System32\Utilman.exe"
$user = New-Object System.Security.Principal.NtAccount("Administrator")

# remove fake Utilman.exe
Remove-Item -Path $file

# replace the owner of Utilman.exe.bak (we are now under a different user) 
$acl = Get-Acl -Path "$file.bak"
$acl.SetOwner($user)
$acl | Set-Acl -Path "$file.bak"

# add permissions
$acl = Get-Acl -Path "$file.bak"
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule($user,"Full","Allow")
$acl.SetAccessRule($rule)
$acl | Set-Acl -Path "$file.bak"
(Get-Acl -Path $file).Access | Format-Table IdentityReference,AccessControlType,FileSystemRights -AutoSize

# bring back the Utilman.exe
Move-Item -Path "$file.bak" -Destination "$file.exe"

# replace the owner of Utilman.exe

$file = "C:\Windows\System32\Utilman.exe"

$user = New-Object System.Security.Principal.NtAccount("Administrator")

# remove fake Utilman.exe

Remove-Item -Path $file

# replace the owner of Utilman.exe.bak (we are now under a different user)

$acl = Get-Acl -Path "$file.bak"

$acl.SetOwner($user)

$acl | Set-Acl -Path "$file.bak"

# add permissions

$acl = Get-Acl -Path "$file.bak"

$rule = New-Object System.Security.AccessControl.FileSystemAccessRule($user,"Full","Allow")

$acl.SetAccessRule($rule)

$acl | Set-Acl -Path "$file.bak"

(Get-Acl -Path $file).Access | Format-Table IdentityReference,AccessControlType,FileSystemRights -AutoSize

# bring back the Utilman.exe

Move-Item -Path "$file.bak" -Destination "$file.exe"

Cheers!

The backup destination is not writable…

By Tomica Kaniski in Other 21/09/2016 2 Comments

So… you decided to finally configure backup for your servers, and just when you’ve chosen the “backup solution”, troubles start.

What do we need for doing Windows Server backups?

Nothing too fancy – we can use the built-in Windows Server Backup (feature that needs to be installed through Server Manager, PowerShell, …) combined with some location (network share, disk, volume) with enough free space. (yes, we can also use some other backup software, but this is not the topic here)

Let’s say that we have installed Windows Server Backup feature and chosen a network share for our backup location. The one other thing we need on this share are the right permissions for our service account (an account under which the backups will be done – for example, BackupAccount).

So, we go to this share (\\BackupLocation\MyBackups\) and check if our service account has the required permissions:

Everything looks fine (our service account has permissions, folder is shared and accessible from the source server – yes, Windows Firewall is also configured properly ).

We go back to our source server where we configure our backup schedule as a Full Computer backup, once a day, to the backup location previously mentioned, using the service account previously specified for this backup job. Everything goes fine.

Then, just for fun, we try to run our backup schedule (just to see if everything works as it should). We click on the Backup Once option (with Using the previously scheduled… option), and just at the end of this wizard, we receive the following error, saying that our backup destination is not writable (yes, it’s the good old Windows Server 2008 R2, but it really doesn’t matter… the same happens on newer/older versions as well ):

What happened???

We’ve checked (and double-checked) everything – our share, permissions, Windows Firewall, and “who knows what”, and this wizard still says we cannot write to the backup destination! This must be an issue with the free, out-of-the-box backup solution.

Not really.

The issue here is that I’m running the Windows Server Backup console as “myself” (i.e. my user, for example, SERVER\tomica) and I don’t really have the required permissions on the backup share (I’m not a member of the local Administrators group on the backup destination and, as you may remember, only our BackupAccount has the required permissions set).

So, is this an issue?

No, not really because our scheduled backup will complete successfully (it will be running under the user account with correct permissions on a backup share).

And, if we really want to make this first backup right now, we can run it from the Task Scheduler console (by checking the “Allow task to be run on demand” checkbox first, for the backup task).

Hope this helps someone with similar problems (it’s kind of a dumb “issue”, but…).

Cheers!

Playing with folders and permissions

By Tomica Kaniski in Other 11/01/2016 0 Comment

This one will be short and sweet. Smiješak

Imagine you have an Active Directory full of users. You also have a file server in your environment. And, as it happens, each of your users needs to have a folder created just for himself, on this file server. Each folder should have inheritance disabled and each user should get full permissions on his folder.

What do you do?

Well, we can manually create the required folders, or we can use a PowerShell script which will do it for us. Obviously, I’ve chosen PowerShell (maybe not the nicest script in the world, but it does the job), or this post would be… lame. Smiješak

So, the interesting part of this script goes like this (I’ve added a few empty lines to make comments more visible):

# get user/folder names from Active Directory (SamAccountName property)
$users = Get-ADUser -Filter * | Select SamAccountName

foreach($user in $users)
{
    $folder = "D:\Share\$user"
    
    # create a (sub)folder for each user
    New-Item -Path $folder -Type Directory
    
    # read the current access rules applied to a folder
    $acl = Get-Acl -Path $folder

    # disable the inheritance, but leave the inherited access rules in place
    $acl.SetAccessRuleProtection($True, $True)
    
    # add Full access rule for a specific user
    $rule = New-Object System.Security.AccessControl.FileSystemAccessRule("$user","FullControl", "ContainerInherit, ObjectInherit", "None", "Allow")

    # add this rule to existing ruleset
    $acl.AddAccessRule($rule)

    # and finally, apply the new ruleset to a folder
    Set-Acl -Path $folder -AclObject $acl
}

# get user/folder names from Active Directory (SamAccountName property)

$users = Get-ADUser -Filter * | Select SamAccountName

foreach($user in $users)

{

$folder = "D:\Share\$user"

# create a (sub)folder for each user

New-Item -Path $folder -Type Directory

# read the current access rules applied to a folder

$acl = Get-Acl -Path $folder

# disable the inheritance, but leave the inherited access rules in place

$acl.SetAccessRuleProtection($True, $True)

# add Full access rule for a specific user

$rule = New-Object System.Security.AccessControl.FileSystemAccessRule("$user","FullControl", "ContainerInherit, ObjectInherit", "None", "Allow")

# add this rule to existing ruleset

$acl.AddAccessRule($rule)

# and finally, apply the new ruleset to a folder

Set-Acl -Path $folder -AclObject $acl

}

Cheers!