Security → Confused about limited account

I finally did what everyone has urged and changed my normal everyday user account from administrator to limited. I also added a password to my other user account that was also an administrator account. So... 1 administrator account with password and one limited account that I will use for day to day activities.

I thought that as a limited user I could not install programs. I got a notice from Itunes about an upgrade and I downloaded and installed it under my limited account. I didn't even think about it until I was done and started to reboot. Well it installed the upgrade even though I was using the limited account at the time.

What is it I don't understand here besides the fact I don't obviously understand the full difference between limited and administrator user accounts.

Thanks for any help.

Within Microsoft Windows, all processes operate in what's known as a security context. In other words, everything runs based on some kind of account that's assigned a certain privilege level. System services run as one of three "background operation" accounts, and locally-defined accounts (which can interactively log onto the desktop environment) can be assigned one of several levels of privilege ranging from Guest, Users, Power Users, Backup Operators, Administrators, etc. and these are based on which group(s) they are members of. You can see these groups by going to lusrmgr.msc.

While there's a distinction between "logon rights" and "privileges," people tend to use them interchangeably and I will do so here for the sake of simplicity (although "permissions" is very distinct from the other two terms). A lot of the things that differentiate a limited / standard / restricted user vs. an administrative one can be seen through the Local Security Policy:

secpol.msc (go to Local Policies, User Rights Assignment)

In general, restricted accounts are limited in two ways: default NTFS permission settings under the common directory structures (C:\Program Files, C:\Windows, etc.) and process-level operations invoked by a user account.

For example, a limited user cannot install applications, change the system time, edit the local security policies, view the security event log, etc.. When you launch a browser, the browser process impersonates your user token (that is, the privileges assigned to your user account) and if your browser downloads and launches an executable, that executable inherits the same privilege level downstream as well. So if your user account cannot write to C:\Windows\system32, neither can any malware. Most malicious code are written to embed itself in sensitive system areas and if your account accidentally / unknowingly runs such code, any attempt by the malware to modify OS files or place trojans in those places is stopped cold.

Now that said, many applications these days also install a dedicated updater service. Many services (also referred to as "NT services") run within the privilege security context of Local System, one of the three "background operation" accounts I mentioned above. This is an account that no user can log into the machine with, but the OS allows background services / programs to run while a user is logged out, etc.. The Local System account is essentially the "God" account and has access to areas that even an administrative account doesn't have.

Your application (iTunes in this case) might have one of these services that handles the update and is able download and write new software code into the protected areas that limited user accounts typically don't have permission to.

Hope this helps a little.

I really appreciate your extended efforts to explain this to me. Thank You!!

I will study what you have prepared and get a better handle on what I am doing in this area. I would be exaggerating to say I now grasp it all.

I did find another surprise this morning when I tried to print. I have a networked printer and it just would not go. I could however print in my administrator account. I solved it by adding my new limited account to the group in the administrator account.

I have a feeling more surprises are coming.

Again... thank you.

My explanation was primarily based around the mechanisms that exist within Windows XP. Vista and 7 expand on this a little more via User Account Control. Let me back up for a second and explain how Windows handles authentication and authorization...

When the machine boots up and provides you a logon prompt and you provide your credentials, the OS Local Security Authority (LSA) subsystem validates the credentials and then, based on policy settings, determines whether you have the proper logon rights (right to logon interactively, right to logon as a service, etc.). Most people don't think about this too much, but these are what "rights" are in the strictest Microsoft dictionary definition sense, even though the Technet articles use the term interchangeably with "privileges."

As you log onto the desktop environment, the LSA then forms a security token for your account which is determined based on your account's group membership definitions and thus the types of environment operational privileges you are assigned. This info is all listed in your security token. Whenever you do things in Windows (try to change the time, do disk management stuff, create new accounts, etc.), the OS evaluates the contents of your security token to determine whether you're permitted to do this stuff. Basically, it's saying, "Are you good enough for me to give you a pass and let you perform the operation?" Same thing with file permissions. If you try to write to a given directory / folder, the OS looks at the file / folder permissions (access lists and entries, also known as DACL and DACE for "discretionary access control list" and "discretionary access control entry") and sees whether you can perform the requested operation to that location.

In Vista, if you open a command prompt and type in "whoami /all," you'll see the contents of your security token and thus the group membership(s) and assigned privileges towards the bottom. Now open an elevated command prompt and run the same command, and you'll notice that the set of privileges are different and expanded. When a user account is a member of the Administrators group and UAC is running with Admin Approval mode enabled (which it is by default), this means that an administrator-level account gets a split-token.

Vista and 7 (as well as Server 2008) uses the concept of a split / filtered token that allows admin users to log in and work as a restricted user most of the time, but if needed they can choose to elevate a given process run request and use the second side of their access badge to do "admin stuff." This is what most people don't understand when they complain about Vista's prompting because users in general have become accustomed to running with full-access privileges all the time and thus are spoiled. I blame this sorely at Microsoft for disregarding the concept of least-privilege to begin with, as well as software developers for not adhering to fundamental security practices. Anyway...

The Local Security Policy can be configured to allow REAL limited accounts (XP referred to these as "restricted accounts," and Microsoft changed the terminology to "standard account" starting with Vista) to either be prompted for a credential elevation dialog or denied elevation. Accounts that run under Admin Approval mode by default are given convenient consent prompts which don't force the user to input credentials of an admin-level account. Most people run this way, and in my opinion are just lazy admins. When Vista first RTMed, I used a real standard user account to experience the so-called "headache." Entering credentials wasn't that big of a deal for me during elevation, and I used a password that would be relatively difficult to brute-force even if the LM hash was stored locally.

With UAC, there are a couple of other features known as integrity levels and file / registry virtualization. The former refers to a system-wide mandatory access control method (as opposed to discretionary, meaning the owners of objects get to determine who has how much access to it). Here's where we get into the guts of UAC that apparently most people who usually complain about Vista behavior have no knowledge of. I'll let you Google this up before I get onto a lengthy write-up, but essentially the policy of integrity levels overrides the results produced by traditional discretionary access control mechanisms such as NTFS permissions. Internet Explorer runs in "Protected Mode" by default, meaning it's running at a Low integrity level than the user-mode Medium level, so in many sense the app is sandboxed to prevent downloaded objects from modification access to file system and process objects in memory that have a higher integrity level. Processes that you run as a user will generally run at a Medium integrity level by default, even for admin accounts. Elevation causes the process to run at a High integrity level.

If you download Process Explorer from Microsoft / Sysinternals and change the display column options, you can see this happening. I'll let you read up on the whole thing about read-up / write-up policies when comes to processes of different levels accessing file system objects and processes defined at other integrity levels. BTW, Vista includes icacls.exe which might show you the level assigned to file system objects, although a non-definition defaults to Medium.

BTW, I might just re-write all this up in the future on my tech-related website:

»wicked-styles.com/bitsan ··· rticles/

along with some diagrams so it becomes easier to understand. Putting the explanation purely in text is harder to conceptualize vs. putting in illustrations / visuals. As you can tell just by gazing at this page from a distance, I'm just writing down large blobs of text that make readers' eyes glaze over.

I visited your site and it has a lot of good information. That's must have been a lot of work based on a lot of knowledge.

Yes, yes... diagrams are good for those like me who have limited reading skills. I have reviewed your longer post twice now and its getting clearer.

I have to have a good understanding of this issue of user rights and limits if I am going to convert my wife's machine to a limited user account too. I have to set it up so its almost seamless or I will have a hot hornet on my ass. She sees the computer as a work tool (silly girl) and like many (most) has no patience for the art of computers. LOL She feels computers and their programs suffer from the geek factor... IE designed by those who love computers more than they love getting work done. Anyway I digress... thanks again!

I just posted a write-up on this topic, although I didn't get to the Visio diagrams that I had hoped to do (those things take time).

»wicked-styles.com/bitsan ··· windows/

There are instances where having restricted accounts isn't feasible, such as running applications that weren't well-designed to accommodate such environments (this is typically due to poor software development and its project requirements). You have to test limited accounts to see if they work well for your particular situation.

The whole idea of least-privilege is a big deal to me since it's one area that can vastly improve security outright. A big reason why Windows has so many security problems is due to the lack of least-privilege enforcement. This is akin to logging in and doing administrative work as the root account in Unix-based systems. That's why I try to emphasize this point when I talk to non-techie folks.

Hope the article helps clarify things a little more and if need be, please spread the word. Driving the point home becomes easier if you explain that if you hand people firearms with no safety training, there's liable to be a negligent discharge somewhere along the line.