Oh no! The Domain Admin password was reset using a guide some idiot posted! What do I do?? [Part 2]

Last time(!), some dastardly devil wrote a Part 1 guide on how to reset your administrator password via the On-Screen Keyboard and despite: 

  • It being a handy workaround for forgetful people;
  • and Microsoft treating this as an acceptable risk
...it is still pretty stupid.

And, so, a colleague of mine asked the blindingly obvious... How do you close it?

Something like this should really be closed off in a production environment. Right? 

To be honest, I'd never thought about it before since the method described in Part 1 is completely contingent on having access to the Bitlocker recovery key or Bitlocker not being enabled in the first place. 


That said it is leaving an attack vector unnecessarily open. And for what? Occasionally having to troubleshoot a broken keyboard? Besides, I mean, surely in a professional setting, you have at least two domain administrator accounts! 

So how do we close this and work around the workaround? 

"Easy!" I sniggered to myself, "you just find the right policy and disable it! Ha, you amateur!

Turns out it's not as straight forward as that... and, as far as I can tell, there doesn't seem to be an administrative template that actually supports disabling the on-screen keyboard on the logon screen! Huh. Weird. I'm sure it does exist (I mean.. it must, right?) but for the sake of science I'm pushing forward anyways. 

If everything in Linux is a file, then the Windows equivalent is everything is represented as a value (or key) in the archaic registry. A fact that the same dear colleague was quick to point out: 

So easy 😤

We simply either add (or modify if already present) HKEY_LOCAL_MACHINE > SOFTWARE > Microsoft > Windows > CurrentVersion > Authentication > LogonUI


By pushing this script out as a one-run scheduled task or pushed out through Intune - after testing it first naturally
$registryPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI
$name = "ShowTabletKeyboard"
$value = "0"
$type = "DWORD"
IF(!(Test-Path $registryPath))
{
    New-Item -Path $registryPath -Force | Out-Null
}
New-ItemProperty -Path $registryPath -Name $name -Value $value -PropertyType $type -Force | Out-Null

EXCEPT, in my case at least, not only was the key already present but it was already disabled! 

Which means that you can basically ignore almost everything I just wrote because it didn't work.

I'm keeping it anyway because it's hacky troubleshooting fixes like the above that I've always loved and learned from the most when lurking tech blogs. Gathering these tiny little grains of understanding together that you find slowly shifting into place and forming a foundation. You know?

Anyway.

Querying the registry:

reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI" /v ShowTabletKeyboard

Confirms both that the key is present (d'uh) and that the value is 0x0. 

...which means disabled.

Otherwise it would be 0x1.


OK, so. Now what. I've got a strong, strong suspicion that it has something to do with permissions and osk.exe running as SYSTEM.  

Let's circle back to group policies. What we're going to do is deny file permissions directly to Everyone and SYSTEM in a way that can be applied across the entire domain. 

Selecting the GPO you want to modify for this purpose navigate to Computer Configuration > Policies > Windows Settings > Security Settings > File System

Right click  File system > Add File 

And add C:\Windows\System32\osk.exe


In security permissions window that pops up, select Add, type in Everyone to add that group, and deny the following: Read and Execute, List Folder Contents, and Read.

Apply > Yes

Do the same for SYSTEM.


Select Replace existing permissions... This option will overwrite all the settings on all subfolders and files with the ones on the parent. 


Now either reboot or run gpupdate /force from cmd on the device you targeted with the GPO. 

Now try launching osk.exe from the logon window. 

The option for On-Screen Keyboard will still appear at the logon screen but nothing will happen if you click it. 


And there you have it! Nothing to it! Really easy, and really intuitive!