If it's just an alias for "runas" that presents a UAC prompt window I will be disappointed.
Seems like it's not an alias.
[1] https://learn.microsoft.com/en-us/windows/sudo/#how-is-sudo-...
Well, now we can sudo them.
But then I read
>When elevating a process from the command-line with sudo, a UAC dialog will appear asking the user to confirm the elevation:
LOL
But it seems like there are other ways to use it without this dialog
>In this configuration, sudo.exe will launch a new elevated console window and run the command in that window. The new window will be launched with the same working directory as the current window. The new window will also be launched with the same environment variables as the current window. This configuration has a similar flow to the runas command.
The whole point of the split token / UAC elevation is to avoid elevation without user interaction. Imagine malware stuck as standard user just running itself like:
cmd.exe /c sudo malware.exe
Along with the UAC dialog, I can't think of a worse way for sudo to behave.
What's wrong with entering your password for sudo? How is UAC more secure than a password?
If you’re logged in as a standard user, UAC prompts you for new username and password to authenticate and authorize the privileged operation.
Having used an unprivileged Windows account, all I can say is no thanks. It's a huge burden if you do anything even slightly more complex than Facebook and email.
As a blanket policy at work, all programmers are admins, everyone else is not. Except when someone is doing a task that requires elevation every five minutes. I'm the only admin on site and it's an unbelievable waste of my time to sit next to someone so I can put in my password every time they click a box. We make those users admins because there's simply no other way to manage it.
And for the record, "don't log in with a local admin account" is a very commonly recommended best practice for Windows environments. It's unusual that you've never encountered it.
And on UNIX, I have worked plenty of times where no one gets root on the shared development servers, other than IT folks themselves.
Counterpoint: I've never heard anyone do what you describe. Therefore no one does it, even though you've just described to me who does.
What exactly is the threat in using a local admin account? I can't think of anything you could do that wouldn't show a UAC prompt. The entire point and purpose of UAC was to prevent malicious elevation without the user's knowledge. I'm really not sure what you accomplish by adding a password to UAC prompt the user wouldn't have read either way. The end result is the same.
I have worked in companies where local admin accounts would be given temporarily for like one hour, after submitting a ticket with a reason.
This was partially automated via a desktop application.
Only every security audit under the sun. If you work for a sufficiently large organization subject to industrial or governmental regulation, or even carry particular insurance policies, third party audits will flag these practices as liabilities, because its boilerplate recommendation for how a managed windows environment is deployed.
You may work for a large organization where you get local windows admin. Exceptions can be made if a good story can be told about compensating systemic and detective controls that sufficiently mitigate the risk.
However I promise you that someone in that organization closer to security strategy and compliance gets grief over the posture at least annually. Those people shelter you from worrying more about it.
UAC is safe from that.