Demoting an Admin account to SU vs Creating a new SUA (W7/8)

I 've been unsuccessfully searching for a definite and final answer about the differences (if any) between demoting an administrator account (specifically, the one created during the installation) to a standard user account and creating a brand new SUA.

I would like to know if setting up a system (Win + Software) under the (default) admin account -> creating a new admin account -> demoting the former admin account to a SUA is essentially the same as creating a new SUA right after Win is installed -> proceeding with software installation (aka, are the 2 resulted SUAs the same in every aspect)? In other words, is W7/8 handling properly the demoting process regarding tokens, permissions, ownership, registry entries, user's files etc., since i already know that XP handles it poorly?

I have yet to find an "official" MS answer, so i put my trust/query in WS community's profound knowledege of how Win's mechanisms work.

I m' not nitpicking here; i 'm just wondering why there are 2 ways to end up to a SUA.

-If the resulted SUAs are identical, wouldn't the first one (demotion) be preferable -even though, the second feels more natural- when setting up a system in order to ensure that the SUA will properly "see" the installed software? (e.g., when installing the admin-privileges-required Qbittorrent, intended for a specific SUA, one has to redefine the download folder's path + manually create an Appdata-Roaming-Start Menu's shortcut in order to ensure that the application will be functional under his desired SUA)

-If the resulted SUAs are different, what's the purpose of each way and would adopting the first one during system's setup be like asking for (security) troubles?

 

Demoting an admin account to Standard will probably result in permissions problems. You're better off leaving it alone and just create a standard account and use it instead. At the very least if you are going that route, you'd first want to create a second admin account before demoting the candidate account.

 

Demoting seems acceptable to the author of http://technet.microsoft.com/en-us/library/ee623984(v=ws.10).aspx.

I think you'll probably be ok if you demote an admin account to a standard account, but you should use accesschk to check for issues. For example, use accesschk to check what your newly demoted standard account can write to in \windows, \program files, and \program files (x86). You can create a new dummy standard account and use accesschk on it also, for comparison purposes. If you need help using accesschk, say so.

 

SetACL may also be useful for auditing.

 

My reasoning for why you shouldn't run into trouble is that:
1. In Vista and later, if using UAC, a UAC-protected admin account already behaves similarly to a limited account when not elevated.
2. Changing an admin account to a limited account is fast and doesn't seem to change many bits in the file system.

 

Thank you both for responding. I really appreciate your input.

@wat0114:

Even though I do reckon that creating a new SUA is the natural, trouble-free way to create a limited privileges' environment, i can't help wondering why there is an alternate way to create such an environment. Furthermore, if the 2 environments were proven to be equivalent, i would choose the demoting way to set up my personal SUA as an easy way to install and configure my basic/resident software in a proper manner.

@MrBrian:

That's what i 'm thinking too. I mean that maybe creating a pure SUA by demoting the default account is feasible just because the latter is a "hybrid" one, as opposed to XP's default account, which is a pure administrative account (iirc).

Regarding the technet's guide that you linked, i 'm familiar with it, since (unfortunately) it's the most cited source that i 've encountered in my web-search. Sadly, it doesn't state anywhere that the 2 SUAs are equivalent -neither that they aren't, though...

First of all, thank you for your kind offer of help.

That's what i 'm going to do, as soon as i have the spare time. I intend to restore my system's baseline image (W7's fresh install) and:

1. create a new SUA, then proceed with the installation of my favorite resident software -> analyze my SUA's (permissions, reg entries, files) using various tools/utilities*

2. proceed with the installation of my favorite resident software, then create a new admin account and demote the former one to an SUA -> analyze my SUA's (permissions, reg entries, files) using various tools/utilities*

3. compare the reports/findings

*I 'm thinking of using:

i. Accesschk, AccessEnum, SetACL (sadly, the 30-day trial of SetACL Studio isn't working properly for me): to check each SUA's file and registry permissions. Maybe i will double-check the filesystem's permissions using AccessScanner.
(Permissions Reporter has a very useful feature. It can compare reports. Sadly, it's available only in the paid version...)

ii. Windows-privesc-check(/2), Dark Elevator (not sure if it's working or not - maybe i have to run it under a pure limited account): to check each SUA for privilege escalation holes.

iii. Regshot: to take each SUA's reg/file snapshots.

Of course, it goes without saying that if it wasn't for your WS threads i would have a tough time finding most of these utilities. So, thanks!

I would appreciate any further suggestions/feedback.

 

You're welcome .

Some notes:
1. You can use SetACL to generate human-readable file/folder permission reports (see the recent SetACL thread). Then you can use any file comparison program (such as WinMerge) to compare two such reports.
2. You can use SetACL to generate reports that show the owner of files/folders. You could then scan for the owner = the user account you're checking.
3. You might wish to do before-and-after comparisons for file/registry (using Regshot, System Explorer, etc.) and permissions (SetACL, etc.) with before=before demoting and after=after demoting. This allows you to check what's happening when Windows demotes an account.
4. If you're using 64-bit Windows, be aware of WOW Effect.

Let us know your results.

 

3. Thanks for the idea.

4. No, i'm using 32-bit.

I will let you know, once i 've finished the comparisons.