Score:2

Domain Admins group removed from local Administrators group but gets UAC prompts for non-admin applications

gh flag

So, I have an odd one that I just cannot find on the internet. We are trying to set up Privileged Access Workstations at our company.

We have removed the Domain Admins group from the Local Administrator group on the PAW. When we do that, then several applications will show the UAC prompt even though I did not run as administrator. When you type in the password for the account it works like expected and does not have administrative access. So, the permissions are correct and everything works as expected, but it is quite annoying when opening task manager, the various RSAT tools, and more and having to type your password again. I want to stress that I am NOT running these as administrator yet it still pops up the UAC. Is there some setting somewhere that affects this? I tried this with a fresh machine with absolutely no GPOs applied to the user or computer.

EDIT: I have tried completely disabling UAC via the control panel and GPOs like Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode but I can't get it to go away.

Todd Wilcox avatar
in flag
On a workstation where you don't want domain admins to be local admins, why is it joined to the domain at all? Also if it's a PAW you **should** get a UAC prompt when you open RSAT tools, right? One way to not get tons of UAC prompts with RSAT is to open Server Manager and authenticate to that UAC prompt and then launch each tool from the menu in Server Manager. Tools launched that way shouldn't have a new UAC prompt because the Server Manager prompt has taken care of it.
MasteOfDisaste avatar
gh flag
Almost all PAW implementations I have seen have the PAW joined to the domain. This makes it WAY easier to manage with GPOs. etc. I don't see any point in having the UAC for opening the RSAT tools. If you are already logged in as the user you are launching the tool with, then what does the UAC prompt accomplish by asking for your credentials again? What security hole is that fixing? Opening Server Manager to open the other tools is a good idea to remove some of the UAC prompts, so thank you. But I would still like to see if it is possible to get rid of if it though.
Todd Wilcox avatar
in flag
If you don't see the point for having a UAC prompt when opening a tool then you don't see the point of UAC at all in any context. The point of UAC is to double check that the use of a privilege was initiated and approved by a human user, not a process that is running with the user's credentials and privileges. And now I see why not having domain admins in the local admins group makes sense, but there's a better way (IMO) - Log on to the PAW with a non-admin user, then open tools as admin and enter admin credentials for the UAC prompts.
Todd Wilcox avatar
in flag
It's a good practice (maybe a best practice?) to be logged on to a user session with an account that has no special privileges at all, and then to only elevate privileges for specific processes. With Windows, a great way to do this is to log on to the computer with a normal account and then if you need to perform an admin task, you run as admin and enter admin credentials at the UAC prompt. That way your email client, browser, etc. can't doing anything that requires elevation, but you can perform admin tasks with minimum necessary elevation.
MasteOfDisaste avatar
gh flag
What you are describing is already in place and has been for years but that is not best practice. We already have separate accounts that have admin privileges and ones that do not. We use non-privileged accounts for email, web, etc., and only use the admin account when needed and use UAC to elevate. The point of the PAW is to have a separate machine for admin work that can't be compromised by a lower-level account. If you need to use the PAW, then that means that you need to use admin level privileges.
MasteOfDisaste avatar
gh flag
If you are not using admin level privileges to do something, then you shouldn't be using the PAW. So when we are using applications on the PAW we are intending to use our admin accounts and therefore there is no need for an extra annoying UAC prompt.
Todd Wilcox avatar
in flag
Why not just disable all UAC on the PAW?
MasteOfDisaste avatar
gh flag
That is the problem I am getting at. I have tried disabling it in control panel and it still pops-up, I have tried messing with some GPOs like "Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode" and nothing seems to get rid of the prompt.
Keith Langmead avatar
us flag
Maybe I'm missing something here, but why? All you're achieving is removing local admin (partially) from an individual machine for users who are already domain admins. But if you're a domain admin then there's nothing much preventing you from putting yourself or the Domain Admins group back into local administrators, for instance via GPO from the domain (which you still have full access to as domain admin!).
Keith Langmead avatar
us flag
You say you're logged in as the user you use for UAC... but surely THAT is what you shouldn't be doing as it suggests you're logging into a PC directly with a user that itself is a member of domain admins! You should be logging in as a normal user that doesn't have local or even domain admin permissions, and then for those things you need admin access for you provide different domain admin credentials via UAC for those things.
cn flag
`Is there some setting somewhere that affects this?` The application manifest. Take one application where you can reproduce the symptom, tell us the name, and the permissions on the shortcut/application, and the UAC settings.
MasteOfDisaste avatar
gh flag
I think it is mostly MMC apps and Task Manager. If I go to task manager to the .exe file, it has pretty standard permissions on it: TrustedInstaller = Full Control; Local Administrators group, Local Users group, System, ALL APPLICATION PACKAGES, and ALL RESTRICTED APPLICATION PACKAGES all = Read & Execute. mmc.exe has the exact same permissions set. UAC is currently at the highest level, but I have had it completely off with no change.
MasteOfDisaste avatar
gh flag
Also, if I login to the same computer with a standard user without local admin and open the same mmc.exe and taskmgr,exe it will not ask for the user's password, it just opens the app. This only appears to be happening to users that are in the Domain Admins group and not in the local admin group.
MasteOfDisaste avatar
gh flag
I did just confirm that if Domain Admins is part of the Local Administrators group, then it still prompts on mmc.exe and taskmgr.exe but it is obviously just a yes or no. If I turn off UAC, it then just opens the apps without UAC. This is not the case for normal domain users. So, windows still appears to treat Domain Admins as special even though it is not in the local admins group.
MasteOfDisaste avatar
gh flag
Keith Langmead, are you suggesting that you have three accounts? One for day-to-day web, email, etc. activities. One only for logging into the PAW and then the third is the Domain Admin that you launch the RSAT tools from the PAW with? That is the only way that would make sense. Otherwise, if the account that you use for day-to-day activities is used to login to the PAW then the security of the PAW is compromised.
Bernd Schwanenmeister avatar
au flag
I am quite confident that this is the reason: your account is a member of either "network configuration operators" or "backup operators" (local groups). Then, this is expected behavior.
MasteOfDisaste avatar
gh flag
Thank you for the suggestion. Unfortunately, both those groups are already empty along with most of the local machine groups.
Score:1
us flag

There is a known issue with UAC not properly calculating if a user actually has an admin token or not. Users in high level domain groups, like Domain Admins, will still be considered "administrators" regardless of their local computer group membership and therefore will be prompted for credentials by UAC. One may consider this a bug, or a feature :/

Furthermore, the "User Account Control must automatically deny elevation requests for standard users" policy setting breaks functionality on a Domain Admin Privileged Access Workstation (where Domain Admins are not local administrators). Attempts to open "privileged apps" like RSAT tools result in an immediate block by policy. This is resolved by changing the behavior of the elevation prompt for standard users from 'automatically deny' to 'prompt for credentials'.

For many organizations, these settings must be enabled to pass security audits. Perhaps Microsoft will fix this behavior as Privileged Access Workstations become more mainstream.

There is more discussion on this behavior here and here.

One option available to those in this situation is to use RunAsInvoker to suppress UAC prompts. You can save shortcuts on your PAW desktop to allow running tools without additional elevation prompts. The tool will run with the permission of the logged on user, but not in an elevated context. If you are logged in as a Domain Administrator you will have that level of access within the tools you run. One draw-back I found is if a tool, like Group Policy Management Console, opens additional applications (like the group policy editor snap-in to edit a GPO), those applications will still prompt you for credentials. So, it isn't perfect.

Here is an example that will launch Active Directory Users & Computers without prompting for credentials:

cmd.exe /C "SET __COMPAT_LAYER=RunAsInvoker & START MMC.exe DSA.msc"
MasteOfDisaste avatar
gh flag
Thank you, twconnell, that was the answer I was looking for. I figured that it probably could not be fixed, but I am now satisfied with having the answer as to why.
us flag
Glad it was useful. I updated the answer with a workaround to bypass the UAC prompt.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.