1

Sounds like a similar question (when-i-click-to-run-as-administrator-it-dont-actually-runs-as-administrator) but its something different.

Lets set the background: Active directory environment, large enterprise, windows 10 enterprise, all users are normal users without special privileges, Windows hello enabled.

Since we turned on Windows Hello, which may have gone hand-in-hand with other changes in security that I am not aware of, I noticed that whenever I run an application with "Run as administrator" (or start a process through the process API with UseShellExecute and verb "runas"), I am presented with the UAC dialog, asking for admin authentication (pin, password or fingerprint) then the app starts as expected with, lets say, "more privileges". But, many applications do no longer recognize that they are run as admin (Visual Studio for example), although they work as expected with elevated privileges. We do also use the MakeMeAdmin tool for the "real hardcore admin stuff" where we as developers need really admin privileges.

What I noticed is:

  1. the user is member of "BUILTIN\Network Configuration Operators" which is normally "deny only"
  2. When "Run as administrator" then this group becomes "Mandatory, enabled"
  3. MakeMeAdmin actually adds the "BUILTIN\Administrators" group to the users claims

So, what is happening here with that network configuration operators group and why are applications no longer aware of the "run as admin" status?

I have an application of my own, in which I check for the administrators group membership but also the token integrity level of the process to determine the privilege elevation level, which works pretty fine both on enterprise level and local machine level.

Improve this question

1 Answer 1

Reset to default
1

I believe that the inconsistency is a function of how a program is launched. In Windows, every program has attached a token that defines the owning user account and the allowed permissions.

During login, Explorer is launched to display the desktop with a token derived from the permissions of the user account. This token can never be replaced, unless Explorer is relaunched. The fact that MakeMeAdmin has added the user account to the Administrators group does not replace that token.

Any process launched by Explorer will inherit its original token from before running MakeMeAdmin and will not recalculate it.

It seems to me that if you wish to have a consistent state, once MakeMeAdmin makes its changes you should restart all running processes including Explorer. I can't be sure that this will remove all the ambiguities, but it should help in limiting them.

Improve this answer
4
  • Thanks, and yes this is what I know already, the point is not that. In fact, all processes are launched through explorer (or better the shell process), and thus inheriting its token or at least part of it when we launch it either through the explorer or CreateProcess() with UseShellExecute. The part that confuses me is that "Run as admin" is not what it says, its "run elevated". And it doesnt explain the "Network Configuration Operators" part.
    – Hefaistos68
    Commented Sep 12, 2023 at 11:47
  • Administrators have all permissions, including that of "Network Configuration Operators". This is a by-product when a token is generated from an administrator account so will have this permission. How this permission is reported by Windows applications may be inconsistent.
    – harrymc
    Commented Sep 12, 2023 at 12:20
  • So when I am not in the administrator group, this NCO group should also not be there? Might there be a misconfiguration in the AD?
    – Hefaistos68
    Commented Sep 12, 2023 at 14:53
  • I can't have an opinion about this.
    – harrymc
    Commented Sep 12, 2023 at 15:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .