Limited User Account (LUA) and highest UAC level overkill?

The default rules are created for BUILTIN\Administrators. Not the Administrator user account, but the Built-in Administrators group.



This allows all members of the local admins group to run any file. Obviously an account has to be in this group for the default rule to apply to it. So, if your "admin" account isn't in the local admin group, then the default rule won't apply to it. UAC of course can create confusion here, by creating two tokens for admin accounts that use UAC, one token being a limited user token. And limited users obviously aren't in the local admin group... So, you may be blocked by AppLocker even when you're using an admin account, if you happen to be using the limited user token that UAC creates for the account. If your file manager is running with that limited user token, you can't use it to run something that AppLocker only allows local admins to run. You need to run the file manager as admin so AppLocker won't block you.

As for the One Administrator account, it isn't very special really, although the web seems to be full of people who believe so. It has no special powers. The one difference immediately noticeable is that UAC consent prompts are disabled, so no UAC prompts in that account - everything runs without asking questions. But this is a setting that can be changed at any time for other admin accounts, not a special privilege other admins can't have. There's nothing special, just turned off security features that one could easily turn off in other admin accounts as well. IOW, it's just as god-like as other admin accounts are, with only the default settings being different.

 

Thanks Windchild for clarifying. Not sure I fullly understand; so you mean the token I have for my Windows (not BUILTIN) admin account is limiting its authoratative level? Am I reducing the account's security level if I place it into the BUILTIN admin's group? Also, I seem to rmember with XP if I were to log into the BUILTIN administator account via safe mode, I could reset, for instance, the Windows admin's pw, leading me to believe in the all-encompassing powers of the BUILTIN admin account over that of the Windows admin account. Is the token premise in XP and earlier such as W2K similar to that of recent Vista and now Win 7? Thanks!

BTW, and you might be happy to see this - LOL, but I am realizing the AppLocker rules seem to be rendering the UAC functionality virtually useless. AppLocker is practically forcing me to run menial routine admin tasks from the admin account, since it's not really allowing UAC to elevate me most times. I'll have to play a lot more to fully realize what's happening, but it's quite an eye-opener

 

The whole two tokens for admin accounts thing is due to UAC, so it's been that way since Vista. Back in XP, local admins had just one token and that was "I am the Admin, hear me roar, grrr!". But it's all different now. Those Inside UAC articles by Mark "great master" Russinovich that were discussed earlier in the thread have lots of good info on this topic. And pictures, too.

But in short, when you log in with an admin account that has UAC enabled, Windows creates an additional limited user token for that admin account. That limited user token is causing AppLocker to block your admin account from running files admins are allowed to run, because AppLocker thinks you are a limited user. And AppLocker is kind of right, too: you can use Process Explorer to look at the properties of explorer.exe for example, and you'll find in the Security tab that explorer.exe is running as a limited user - there will be a big ugly Deny flag in local admin group membership (BUILTIN\Administrators). So, if you use this limited user token explorer.exe to browse some folder and run some file, AppLocker will happily apply its rules to you as if you were a limited user and won't let you run anything only admins can run. Hence the problems.

But if you open the usual Local Users and Groups tool, you will find that your account is already in the BUILTIN\Administrators group. UAC is just demoting some processes to limited user for security (and more importantly, to force everyone to be kinda-LUA so developers have to get their act together). In the case of your nVidia control panel, to see the difference, you could, for example, elevate cmd.exe and use that to run the nVidia control panel, and see what AppLocker says then. The general idea being that unless you elevate something, then it's going to run in the limited user token, and AppLocker will prevent it from running anything limited users aren't allowed to run.

UAC can cause a lot of confusion at times.

All admin accounts have all-encompassing powers over pretty much everything, including other admin accounts. If you know the password of one admin account - any admin account - you can do anything: you can create new admin accounts, delete other admin accounts (except the built-in\administrator account that always exists but can be disabled), delete system files, and so on. So the Safe Mode trick is just that: logging into an admin account, where you can then do anything an admin can do, including mess with other admin accounts. You could do exactly the same things by logging into any other admin account in Safe Mode (if you have the passwords, of course).

Yeah, AppLocker and UAC don't exactly play seamlessly well together. And I personally think that for someone, such as myself, who can accept the inconvenience of a default-deny policy for limited user accounts for the sake of increased security, UAC elevations should be easy to give up. It's a pretty big step to block limited users from running anything the AppLocker rules don't allow, after all, and compared to that, ditching UAC elevations is a small inconvenience if even that.

 

Thanks again for not only the quoted but for everything else you explained. You do a great job of presenting things a layman like myself can reasonably grasp On the quoted, yeah, I might just follow your lead and let UAC go if I can't get it to play nice with AppLocker. Somehow no matter how much I argue with you I'll probably end up going with your recommendations I've been reading some MS Technet material on AppLocker to gain a better understanding of it. Very nice addition to this version of Win 7 and certainly does make SRP look old and tired. I'm understanding now how allowed rules with exceptions are actually better than deny rules, especially with Publisher or Hash rules incorporated.

BTW, my apologies for swaying this off-topic from UAC to Applocker

 

If my posts are making some sense to folks, that's good enough for me! I'm kind of surprised that so far I have not found the MS documentation for AppLocker mentioning how AppLocker behaves with UAC. That can cause surprises when people know they're logged in as admin but don't realize that their explorer.exe is running as a limited user instead and being treated like one by AppLocker. And since most people use Explorer as their file manager and use it to run programs, they'll face this issue if they also use AppLocker. With Explorer being so resistant to being elevated to admin, it can cause gray hairs.

In any case, I'm of the opinion that UAC, LUA and AppLocker and its predecessor SRP are "related enough".

 

Windchild, my two administrator accounts; the one created (named Administrator and in the BUILTIN group) during Windows install and the other from within windows User Accounts.

 

Yeah, that's the Users listing. Looking normal. If you view the properties of that account called "Admin" and check the "Member Of" tab, you can see what groups that account belongs to. It should say Administrators there - this means it's a local admin, in the BUILTIN\Administrators group. If it does, and AppLocker still blocks that account from doing something admins are allowed to do, then that's the work of UAC and needs to be solved with some elevation.

You can also just check the Groups listing. If you click on Groups, and view the properties of the Administrators group to see who is a member - your Admin account should be listed there, if it's an admin.

 

Okay, I'm sure it's fine then and I'll check later when at home. I'm pretty sure it was just some rule I created that had blocked the admin account from launching nVidia CP. After ditching the AppLocker rules for the Windows folder, creating via Auto-Generate the combination of Publisher/Hash rules for the two Programs folders (x64 & x86), resetting the UAC to default level and rebooting, things have been working great; UAC seems to be working in better harmony with AppLocker now. I feel like now I've got the best of both worlds with the combination of UAC and AppLocker What I did just before commiting the rules, is I uncheked the programs I didn't want standard users to run such as EasyBCD, ShadowProtect and nVidia CP. I love the Auto-Generate feature; it's so fast and affords the option to uncheck the boxes for programs you don't want the particular users or groups to run

 

Pardon for my late entry is this thread.

A different solution is to allow the specific admin account explicitly in your AppLocker rules, instead of (or in addition to) allowing the Administrators group.

 

Sorry to dredge up an old topic but...MrBrian, right you are. I can't remember when, but some months ago I finally figured this out

 

Just got through reading this thread, glad I did too. Well done everyone!