The phrase “user account” refers to something which is often referred to simply as a “user”, but the longer phrase is meant to help distinguish a “user account” from the person, a.k.a. the “end user”, who is anticipated to be likely to use the user account. (Although those concepts are typically easy to keep separate in one's own mind, sometimes communication about an account may sound like a reference to the end user. Comments about “deleting the user” may be viewed as impersonal and unintentionally rude.)

[#useradd]: Adding user account(s)
The above hyperlink goes to a page dedicated to adding user accounts.
[#lsusers]: Listing users
In Unix

The most official way would be to check the password file. For example, cat /etc/passwd may be one method. (That method also provides additional data about each user. The information may scroll off of the screen: redirecting output to a file or piping it, and using a method to view a file or a similar stream, may help with that.) Note that this method tends to show all user accounts, including service accounts used by automated processes.

Another common method would be to check for where users have the directories that their data is stored in. This could be their home directories, or perhaps an alternative such as the directories where they store web pages (if that isn't in their home directories). The most commonly compatible method to do this would be:

ls /home/*
In Microsoft Windows

There are some various techniques. Information may be obtained using:

WMIC UserAccount Get /ALL >> output.txt

To see what users have created a local profile on the machine (by logging in the machine), in Windows Vista and newer, see C:\Users\ and in some older operating systems, see “C:\Documents and Settings\.”. “ net localgroup Users ” may show most local users. (There may be some better ways. The ways mentioned so far don't really cover what users may be on the domain, if the current machine is part of an Active Directory domain.)

Another method may be to use a graphical interface. Note: In AD, finding the user in the heirarchy can take a while if being done by manually viewing the entire tree. A faster way may be to search for the user. Once the user has been located, the user properties may show an “Object” tab. If that tab isn't visible, then in the main AD screen (not the Properties screen for the user), enable Advanced features. (This tip was written by memory, and it would be better if exact info was provided.)

[#userdel]: Removing a user account

Note: before removing an account, consider whether any information in that account needs to be saved. In some cases, it may be better to disable the account.

If the user being removed had superuser access, and if the plan is to use a new account for ongoing superuser access, see a warning: why using a long-term account should be used to remove/disable superuser access from an older account.

[#userauth]: Authenticating User accounts (Keys, Passphrases, affecting whether enabled/disabled)
Authentication Implementations

Authentication can be quite basic, or it can be a bit more complex. However, as each user generally needs some sort of credentials, the section about user authentication is listed here in the sections about basic user operations sections.

[#usrdsabl]: Enabling/Disabling user accounts
(See page hyperlinked above.)
Simple logins: Username and basic passphrase
(Covered in the user authentication page.)
[#authkeyf]: Key files
These are typically more secure than basic typed passphrases due to a substantially longer “secret”. They can also be automated, so once implemented, can even be easier to use than simple logins.
[#otpauth]: One-time passwords

A mixture of a neat/new technology (one time credentials) and an archaic technology that is best replaced (passwords).

Biometric reading technology
Some laptops have a fingerprint scanner.
[#authusag]: Authentication Usage

The most commonly understood use of authentication may be for a user to be identified to allow the user to “log in” so that the user may then access resources on that computer. The idea is that once the user is logged in, and as long as the user stays logged in, the user will then be able to access resources that require authentication.

Authentication may also be provided on an as-needed basis when access a resource such as a file or a web page. After access to the resource is provided, the access may stop being provided. This means that the user may need to re-authenticate, perhaps manually.

Resources, such as files, may have authentication requirements. Details vary. For information about restricting access to files on a local file system, see file attributes/ownerships/permissions. Running processes, and/or other “resources”, may have “owners” and/or permissions similar to files.

Privilege limiting
[#privdrop]: Privilege dropping

This is generally the easiest to take advantage of: the system administrator doesn't need to do anything. Some programs will document that they need administrative privileges for a certain task, but then after performing the task, the program drops privileges. This way, if the program ends up being compromised in some fashion, the running program has fewer rights that might be exploited by an attacker.

Of course, just because a program's documentation has claims to not use available rights, the reality could potentially be different than what is documented.

sandbox (e.g. chroot / jail)

(This section does not yet have extensive information. However, at the time of this writing, the topic is covered a bit by guide to setting up Apache.)

[#usracctl]: Microsoft Windows User Account Control (“UAC”)

With Microsoft Windows Vista, Microsoft included “User Account Control” (“UAC”). The original implementation tended to ask the user for interaction so frequently that Vista's implementation was considered to be “broken” by many technicians, and the feature was quickly disabled on many machines.

CNN's article: “Microsoft: Vista feature designed to 'annoy users'” quotes “David Cross, a product unit manager at Microsoft,” who “was the group program manager in charge of designing User Account Control (UAC)”. He said, “The reason we put UAC into the (Vista) platform was to annoy users--I'm serious”. The article goes on to say, “Cross claimed that annoying users had been part of a Microsoft strategy to force independent software vendors (ISVs) to make their code more secure, as insecure code would trigger a prompt, discouraging users”.

When UAC is enabled, when running programs in the graphical interface, performing an action that requires UAC may result in a UAC prompt. The action cannot be performed unless an end user, using the GUI, interacts with UAC and specifies that the desired action should be allowed. The UAC prompt is generally not difficult for the user to locate, because the entire screen may dim with the exception of the UAC prompt. The user may also be relatively unable to perform any other task, such as Task Switching, with the GUI until the UAC prompt is handled (either by accepting the request, or cancelling the request). (This dimming feature uses functionality called “Secure Desktop”, as noted by MSDN UACBlog: “User Account Control Prompts on the Secure Desktop”.)

It is possible to interact with UAC over the network by using a remote access method (like a program that uses the VNC protocol).

Not a security boundary

In YouTube video: “Halt hackers: do those tricks still work with Windows 10?”, 14min33sec, the speaker says these words, approximately:

User Account Control was introduced with Windows Vista. Latest feature by that time. The clear message from Microsoft by then was: this is not a security boundary. It [User Account Control] is still there in Windows 10, and it's still not a security boundary. It is still very easy to circumvent User Account Control and get a full priviledged user account available for your processes.

A very fast demonstration was done, using a door built into the Task Scheduler program, without even fully creating a task.

  1. Run Task Scheduler (e.g., “ MMC TaskSchd.msc ”)
  2. Choose “Create Basic Task...”
  3. Type in a name for the task, and press Next four times, which gets the program to the “Start a Program” screen (within the “Action” section, as shown on the left side bar)
  4. Press the “Brrowse...” button
    • The program creates a window titled “Open”. This may conveniently point to C:\Windows\System32
  5. Find the executable file for a nice program to run. e.g., cmd.exe can be used.
  6. Access that file's “context-sensitive menu”/“context menu”/“shortcut menu”/“alternate menu”/“secondary menu”/“right-click menu”.
  7. On that menu, choose the menu option just above that, which says “Open”. Or choose the shielded “Run as administrator” option. Either one will open the requested program using UAC elevation.

Chris Jackson's “Mapped Network Drives with UAC on Windows Vista” says, “For a discussion of why this is a convenience feature, rather than a security feature, see Mark Russinovich's blog entry” which is available at Wayback Machine @ Archive.org: Mark Russinovich's technical blog: PsExec, User Account Control and Security Boundaries.

Colors

UAC doc describes different shield types (mainly, different color schemes) found in Windows 7.

In Windows Vista (which introduced UAC), the shield could be seen colored similar to the Microsoft Windows flag: red in upper-left, green in upper-right, blue in lower-left, and yellow in lower-right.

[#uaccmdpr]: Interacting with UAC from the command line
Overview

When trying to perform actions on a command line, UAC may block access to perform certain activities. When this occurs, an error message will be displayed. The error message might display a message such as “The requested operation requires elevation.”

In such a case, UAC must be dealt with. UAC is requiring user interaction.

In some cases, a program may simply give different results if the command line is not recognized by UAC as being an “Administrator”. The program might indicate an issue with permissions, such as if SC reports access being denied. However, the results could simply just be different, such as when a WMIC command might look at Hyper-V and then list just the host server, and not list all the virtual machines on a server that runs Hyper-V. The command may appear to be successful, but may provide different results compared to what happens when the command is run from an elevated command prompt.

SS64.com: ShellExecute notes that when a program “is run with elevated permissions several aspects of the user environment may change: The current directory, the current TEMP folder and any mapped drives will be disconnected.” This may be true even from a command prompt that is started as an Administrator (as verified when running JPSoft's TCC/LE).

See: Ways to deal with UAC.

[#uaccmdok]: Ways to deal with UAC

Here are some approaches which might work.

Avoiding the UAC prompt (or at least frequent occurrences of the UAC prompt)
  • MSDN page about UAC provides a couple of methods:
    • “Run the script using the built-in Administrator account.”
    • Schedule a task with Task Manager
  • Note that once a program has been elevated, that program can generally run other elevated programs (without requiring any steps to elevate again through UAC).

  • Adjust UAC settings so that the prompt doesn't occur in the first place. (If UAC is effectively disabled, then the limitations caused by UAC may not exist.) Consider details like what other potential consequences may exist if UAC protection is lowered (possibly even to the point of being entirely removed). Disabling such security features will prevent those features from being able to help implement security. There may be other impacts, such as article about Windows 8 noting, “You will not be able to run any apps from the Windows store. So disabling UAC for real does have its drawbacks”...

    Also consider whether the change should be permanent or just temporary. If temporary is desired, then remember to re-adjust settings. If “permanent” is desired, it may be worthwhile to consider whether there are other computers in the area that should also have the same setting change performed.

  • MSDN page about UAC discusses requirements for running a script. Computers that are part of a Microsoft Windows Active Directory domain may benefit by using an account that is in the system's local Administrators group. Computers that are not part of such an Active Directory may require providing more permissions as described by that referenced web page.
Other methods of dealing with UAC restrictions

  • One method that may work is to specify that a program, such as a command prompt, should be “Run as administrator”. This is done by manually interacting with the GUI, using instructions that are about to be described. Then the limits that existed before may simply not be a problem. The command prompt's interpretor/shell, or whatever other program was run from the command prompt, may be considered by UAC to be authorized, and so UAC might just not get in the way.

    There may be multiple ways to do this. One way is to find an icon for the command prompt, access that icon's shortcut/context menu (by right-clicking it, or by using Shift-F10 when it is selected (and highlighted)). See if an option exists that says, “Run as administrator”. If not, use the mouse and keyboard together. Hold the Ctrl key on the keyboard, and then right-click the item that was selected to bring up the context menu. That may bring up a different menu that does show the “Run as administrator” prompt.

    Another method is to type a command into the “Search” box (not the “Run” box) and then press Ctrl-Shift-Enter.

  • Use the GUI to perform the task another way. For instance, if the command line is trying to copy a file to a protected directory, try copying the file from the GUI. The GUI may act differently: instead of denying access, the GUI may provide a UAC prompt. By interacting with the UAC prompt and allowing the action, the action might be able to be successfully completed, instead of acting like what happens from the command line. That is better, since trying this from a command line may simply result in aborting due to an error from insufficient elevation/permissions. This solution doesn't help much for people wanting to automate a process, but it might help a person who is using the computer interactively and is trying to get access to a file.
Task Scheduler

Sometimes, certain operations might require acknowledgement by an administrator that the user should have permission to perform an action. Administrators may want to circumvent this sort of requirement for automated tasks. This might be doable using Microsoft Windows Task Scheduler. UAC and WMI may mention doing this.

Other ways of trying to deal with UAC
The old theory

(Some of this text might be slightly repetitive...)

When a technician comes across this, especially if the technician writes computer code and plans to need to repeat the steps on other machines, there may be a desire to find a way to automatically interact with UAC to let UAC know that permission is granted. This is, by intentional design, not the easiest available solution. (There may be an available solution for dealing with UAC from a command prompt, but automated interaction with UAC a prompt is not the intended way to deal with UAC's requirements.) The whole point of UAC is that UAC was specifically designed to try to prevent certain actions, especially automated actions, from being able to happen until user interaction clearly provides permission. If UAC is active, then user input may be required. The easy solution is not to figure out a way to automatically fake interaction by a user. The easier solution would be to make some adjustment(s), possibly by simply adjusting UAC, so that UAC isn't requiring this sort of interaction.

Microsoft may have quite intentionally not provided another way to deal with UAC. There is no command line program that will, without needing to interact with the GUI, simply acknowledge UAC's need for permission. The UAC dialog box cannot be interacted with automatically, and a program cannot be started using UAC's “Run as administrator” setting without using the GUI. There is a clear reason why there is no such command line program: this is because such a command would allow a high degree of automation. Allowing such automation would completely destroy the intended design of what UAC is doing. Really, leaving UAC enaled and then working around it doesn't make a lot more sense than disabling UAC.

How does one interact with UAC in a highly automated fashion? One does NOT do so! Well, at least according to the old theory, the answer is simple (even if it initially sounds relatively unpleasant). A person, quite simply, does NOT do this! One deals with the situation by simply takes whatever steps are necessarily, possibly by using automated methods to adjust UAC settings so that UAC interaction isn't required. However, if UAC is actively interacting, automated interaction with UAC is not likely going to be the easiest solution.

The newer reality

There are third party services that can help to disable UAC prompts.

Before providing those details, a quick reminder of some facts is in order. This is third party software. This does not seem to be the general approach that Microsoft recommends. That might mean that Microsoft is more prone to break this solution, possibly with newer versions of Microsoft Windows. If a person can find a right way of disabling the prompts, by using Microsoft's official designs to let Microsoft Windows know that action is authorized or that prompts are undesirable, that may be a “cleaner” soluition that could work better in the long term.

However, for those who are still interested in a workaround...

Note that the author of this text has not tried any of these solutions at the time of this writing.

HelpDeskGeek: Turning off UAC for a specific application recommends using ITKnowledge24.com'1s “UAC Trust Shortcut” software. The software may be a bit less pleasant in the short term, as this may require installing .NET 4.0 (which then requires a reboot) before the main part of UAC Trust Shortcut 1.0 gets installed. However, with a bit of setup, this may allow a way to have UAC's dialog boxes be effectively disabled. Furthermore, this can be done on a per-application basis, so one program of interest can have UAC be silenced while UAC still remains active to protect other software interaction.

The way this software operates is by running a custom service. Another alternative, SuRun, also uses a service. (The SuRun home page (in German) starts with a hyperlink to an English translation of SuRun home page.)

UAC Trust Shortcut 1.0 has two installers: one for x64 and one for x86.

Other solutions may include:

Another approach

The Shell.Application object, which is available via Windows Script Host (meaning that it can be used with JavaScript or VBScript), provides a ShellExecute function. (This hasn't been tested by the author of this text yet, but this is being documented here anyway because this method is mentioned by multiple sources that are generally reliable.) Guide demonstrates, SS64 discusses.

Misc UAC resources/comments
UAC and WMIC

MSDN: User Account Control and WMI states, “The first time you run Wmic after system installation, it must be run from an elevated command prompt. The elevated mode may not be required for subsequent executions of Wmic unless the WMI operations require administrator privilege.” So, a program may alter its behavior (in this case, based on what has happened before).

Elevation Programs (for Microsoft Windows (UAC))

None of these are necessarily recommended, but are provided as potential resource. Plan to investigate/test before relying on the software. (That is generally a good idea to do anyway, but especially when there is reason to suspect that the software might not do exactly what is being sought.)

Ben Armstrong blog: Self elevating PowerShell, “Hey, Scripting Guy!” article mentioning UAC, Script Elevation Powertoys (2007 article), Elevation Powertoys, Elevation Powertoys Update, Relaunch Elevated. MSDN: User Account Control and WMI says that one approach is to “Run the script using the built-in Administrator account.”

[#uaclismb]: Handling network “shared” drives
Description of the problem

A command prompt using UAC “Administrator” access does not see mapped drives by default. This is described by MS 937624 (Alternate URL: MS KB 937624: Programs may be unable to access some network locations after you turn on User Account Control in Windows Vista or newer operating systems. The article discusses how separate security access tokens are created for when the user is acting like a “standard user” and when the user is using administrative credentials. The following:

“When network shares are mapped, they are linked to the current logon session for the current process access token. This means that, if a user uses the command prompt (Cmd.exe) together with the filtered access token to map a network share, the network share is not mapped for processes that run with the full administrator access token.”

So, that causes the issue. Microsoft might have been able to design the more modern approach of Microsoft Windows by having drives mapped to the AT (“Administrative Token”) as well when they get mapped to the SUT (“Standard User Token”). Because Microsoft did not do such a friendly thing, the result is that when a user successfully maps a shared folder to a drive letter, the Administrative Token is completely unable to see that mapping.

As for why Microsoft didn't take that sort of more freindly approach, Chris Jackson's “Mapped Network Drives with UAC on Windows Vista” explains that UAC is a specific implementation of a more widely implemented separation between tokens, and that Microsoft Windows does “put a mitigation in place for the scenario of launching from the shell. If you double click on an executable that is either detected as a setup or is manifested as requireAdministrator, we can detect that we just elevated and suddenly are getting an error message indicating that the path was not found,”, which can be responded to by having Windows “copy that drive mapping over from the original LUID. However, that is the only scenario that we can automate.” However, that doesn't seem to happen if the shell is running a batch file, as the shell used for the batch file ends up being found and then the batch file itself isn't found.

As an example of this impact, if a program is run from a drive letter mapped to the SUT, and then the program self-elevates, the program may not be able to easily find itself when the drive letter disappears. (This has been known to break some batch files. The issue might be something that could be worked around if the user accessed the batch file via a UNC instead of a mapped drive letter. However, users should not need to go through such imposed difficulties just to run a file that they can see. If they see a batch file when looking at a mapped drive, they shouldn't need to type in the UNC as a workaround just because the UNC is notably more reliable than the drive letter. The specific issue here, which should have been avoided, is that the drive letter breaks during the elevation process.)

Sometimes people have griped about the network drives not being available, and then they are told the reason is because of different security tokens. Then, the griper felt out of their league, because such a complainer realized that they don't know much about security tokens, and so they don't want to be complaining more about something a topic that they are aware they know very little about. However, as described above, the issue might not be that elevation causes a different token to be checked. The issue is that the network drive mappings weren't mapped in a way that would also work with the Administrative Token. That is the design choice which seems to have led to little benefit, but significant aggrevation.

One solution, which should work for the immediate short term, may be to simply re-map the drive from that command prompt.

There are some claims that certain parameters to the “net use” command line may be helpful. For example, another solution, which may be helpful in longer term, may be to use the /user: parameter to “net use”. e.g.: “net use \\sysname\sharedir /user:username”. (The idea of this being helpful is noted by MS KB 937624)

EnableLinkedConnections

Commentary about mapped drives from elevated command prompt has some comments about a workaround by using an “EnableLinkedConnections” registry entry. However, another article, how to make elevated programs recognize network drives, indicates that does not work well with Windows 8. People who use Windows 7 seem to be reporting relative success.

Commentary about mapped drives from elevated command prompt provided some sort of warning referencing malware. The threat seems low: if malware is running on a system, then there are already problems. However, because of this warning, some people have expressed caution about using this setting.

To try this modify the registry and then reboot. One way to make the appropriate modification to the registry is to run:

REG ADD HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System /t DWORD /d EnableLinkedConnections /v 1

Then, as noted already, don't forget to reboot.

ShutDown /i /r /p /t 1

This is also described by: Microsoft “social” thread: specific location.

(That concludes this section which is specifically about using SMB/CIFS with UAC enabled. Further details about SMB/CIFS are also available.)

Adjusting UAC settings

There may be more than one way to do this. Specific options might vary a bit based on one operating system is being used.

One way is to use the graphical interface, by running “C:\WINDOWS\System32\UserAccountControlSettings.exe”. (This is what is typically run in Windows 7 when going to msconfig and using the “Tools” tab and highlighting the “Change UAC Settings” option. A more compatible way is likely to run “%windir%\System32\UserAccountControlSettings.exe”

Detecting UAC blocks

One way to detect whether a program was run with UAC limitations is to try running a program that acts different depending on whether UAC is imposing limits. For example, running “net session” returns an error code of 2 if UAC prevents the program from gathering information to report details. If the same program is run from a command prompt that was started using the “Run as administrator” UAC-related option, then the program succeeds and returns a value of 0.

Using whoami.exe

Another way could be to use the whoami.exe command. This command may have historically been rather simple in what it could report, similar to the simple usage of the whoami command in Unix, but starting with Windows Vista (which, perhaps not entirely coincidentally, was when UAC was released, the whoami.exe command has some more capabilities.)

Sample One
whoami.exe /groups /fo list

As an elevated user, the final group may be "Mandatory Label\High Mandatory Level" S-1-16-12288

As a standard user, one of the groups (possibly the final group, or even possibly the first group) may be “Mandatory Label\Medium Mandatory Level” using a security identifier, a.k.a. a “SID”, of “S-1-16-8192”.

(Thanks to http://www.itprotoday.com/windows-8/rise-whoami for pointing this out, and discussing slightly further)

Another option
whoami.exe /priv
Shows far fewer when using SUT (Standard User Token) rather than AT (administative token)
More info about UAC
Some information, likely meant for programmers, has been published at MSDN article about UAC.
Some related (or similar) technologies
Windows File Protection

A simple way of dealing with this is to run a program with UAC-elevation. For instance, if a Command Prompt is run with UAC-elevation, then that copy can write to the protected directories. Also, if a Command Prompt is run with UAC-elevation, and that command prompt runs a copy of Notepad, then that copy of Notepad will be able to write to the directories.

If you ran a copy of Notepad without realizing that a file is protected by System/File Protection, you can opt to save the file to another location, and then try to move the file to the desired location with a UAC-elevated program. Or, if you try to move the file to the desired destination with File Explorer, the Explorer window may self-elevate (after prompting the user), and then be able to write the desired file.

Perhaps see also: File and Registry Virtualization

“Windows File Protection” (for Win2K/XP/2003) was also named “System File Protection” from Windows ME. (See: Wikipedia: Windows File Protection, replaced by Windows Resource Protection in Windows Vista - Wikipedia: Windows Resource Protection).

Windows “System Protection”

Some people may refer to “System Protection” as if it is a feature related to protecting you from writing files.

That seems to be a misunderstanding. “System Protection” is related to System Restore. e.g., Tutorial about System Protection shows how if you go to System Properties, there is a “System Protection” tab. (You can also run this using “ control sysdm.cpl,,4 ” or, on newer versions of Microsoft Windows, “ %windir%\system32\SystemPropertiesProtection.exe ”.

The reason for people confusingly referring to the directory-writing restrictions with the name “System Protection” might be related to some old names. In Windows ME, this feature was named “System File Protection”. Other operating systems have used other names, such as “Windows File Protection”.

Perhaps see also: File and Registry Virtualization

File and Registry Virtualization

If you've tried to write to the “C:\Program Files\” (or the “C:\Program Files(x86)\” directory) then you may have found access seems denied unless interacting with a program that is running UAC-elevated. A key reason for this may be a feature alled “File Virtualization”, or, more elaborately, “File and Registry Virtualization”.

This is related to the fact that the directories are known directories that are given special properties. (As a quick example, such directories may commonly have names, e.g. KNOWNFOLDERID, previously known as constant special item ID list (“CSIDL”) (where the “i” in “item” appears to not be part of the acronym/abbreviation), and the fact this folder is pointed to by one of the special environment variables (e.g., “User State Migration Tool”-recognized Environment Variables).

File and Registry Virtualization may have some ties/interaction/relations with UAC. Wikipedia's article on User Account Control says “UAC” tries “using File and Registry Virtualization” to impose limits on writing to certain location. (This was quoted by Mokubai's answer to Dan's SuperUser.com question.)

Possibly related: MS KB/“Article ID” 927387: Common file and registry virtualization issues in Windows Vista or in Windows 7. This may cause a “Compatibility Files” button to show up in Explorer. (The button won't be visible if this “Compatibility Files” feature is not being used.)

Possibly related is “Windows Integrity”/“Integrity Mechanism”[/“Windows Integrity Mechanism”]. e.g., Windows Vista Integrity Mechanism Technical Reference

Microsoft Docs: Previous Versions states, “Virtualization is not supported on native Windows 64-bit applications. These applications are required to be compatible with UAC and to write data into the correct locations.”

From some reading, it seems this was a bit easier to disable system-wide in Windows or Windows 7.

C:\> REG QUERY HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System /v EnableVirtualization
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System     EnableVirtualization    REG_DWORD    0x1

C:\> REG QUERY HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System     EnableLUA    REG_DWORD    0x1

C:\>

A book called Windows Internals Part 1, “System architecture, processes, threads, memory management, and more” Seventh Edition (by Pavel Yosifovich, Alex, Ionescu, Mark E. Russinovich, and David A. Solomon) discusses how this may be affected by going to Task Manager, and on the Details tab, right-clicking on a task (to pull up a “context-sensitive menu”/“context menu”/“shortcut menu”/“alternate menu”/“secondary menu”/“right-click menu” related to just that task), and checking “UAC Virtualization”.

SmartScreen
For details, see: troubleshooting page which has some details on this.
Attachment Manager

When downloading from Microsoft Internet Explorer, an “Open File - Security Warning” may appear. For details, see: troubleshooting page which has some details on this.

Code signing

Code signing?

Handling groups
See User groups.
Adjusting other user properties (e.g. home directory, etc.)
[#homedir]: Home directory

Specifying where the user's home directory is located:

In Unix
This sixth colon-separated field of /etc/passwd specifies the home directory for that user. If the user is named “example”, then many shells will implement ~example to be a directory name which refers to the directory of that specific end user. (This notation does work for one user to be able to specify the home directory of a different user.) Additionally, if the user is logged in, most shells will have ~ (which is simply a tilde by itself) points to the home directory of the logged in user, and also the $HOME environmental variable will also point to the home directory of the logged in user.
Historical Unix
Wikipedia's article on “PWB shell”: section called “Notable features” notes that $s was the predecessor of the $HOME environment variable (in Unix platforms).
Microsoft Windows

(Some of the following info is based on imperical evidence, rather than citing a clear official standard.)

The home directory would be %HOMEPATH% which in Windows Vista and newer is likely set to C:\Users\%USERPROFILE% while Windows XP and Server 2003 are likely going to have this be set to C:\Documents and Settings\%USERPROFILE% (without any quotation marks). Note that the value of %USERPROFILE% is expanded, not included as a reference, so if %USERPROFILE% was initially set to “example” then the value in Windows XP, without quotation marks, may be “C:\Documents and Settings\example.

Before Windows uses a directory as a user's home directory, a check is made to see if that directory already exists and appears to be another user's directory. If so, then a different default is used for %HOMEPATH%. Instead of the portion which is “%USERPROFILE%”, instead what is used is something similar to “%USERPROFILE%.%LOGONSERVER%” except the first two characters of %LOGONSERVER% (the double-backslash) are discarded.

To re-locate a user's home directory, make sure that you are logged in as another Administrative user. Then locate the Registry Key related to that user account, underneath "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList". You can see what is there in RegEdit or by running:

REG QUERY "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList" /s

Here is some documentation showing that, at least for Windows Vista, 7, 8, Server 2008, and Server 2012, the Users directory and ProgramData directory should go onto %SYSTEMDRIVE% to prevent some problems: MS Support Help 949977: Relocation of the Users directory and the ProgramData directory to a drive other than the drive that contains the Windows directory

Access/Permissions
Files, printers, etc.
Files and directories
Commonly set permissions include permissions for a user's home directory, and determining whether this user has access to network-shared folders. (For network shares, the user's access is often determined by providing permissions to a group and then determining whether the new user is part of a group.)
Printer objects
Users may need to be granted access to a printer.
Properties

A key characteristic about a user account is what user groups the user may be in. Examples of other details which may be stored and modified may include a user's name, location, and contact info.

Note that location and contact info may commonly be implemented in a way that allows such info to be commonly shared. Some properties, such as an end user's first name, might not be something that a typical end user has any way to change without going through an authorized staff member of the network administration. Others, such as a preferred E-Mail address or what shell is run with remote command lines, may be something more commonly allowing a user to edit.

Details about changing some properties may be documented in other sections. For examples, see: user authentication details (for modifying credentials other than the user account name, such as changing passwords), and enabling/disabling user accounts (to change whether an account is considered to be “enabled”).

[#userid]: User IDs
[#uidunix]: Unix's User ID (“UID”) (and Group ID (“GID”) fields

In Unix, user accounts are typically assigned to a “user ID” number, commonly abbreviated as UID. These numbers may have some common patterns on various systems, such as UID 0 referencing the superuser. It is common that lower-numbered UIDs may be meant for automated software installed as part of the operating system, or other software that is added by an administrator. Debian manual section 9.2, a section of documentation called “Users and groups”, has a subsection about commonly followed ranges to use. Wikipedia's List of Fedora versions: section about Fedora 16 notes “Fedora will now use UID/GIDs of up to 1000 for system accounts”.

On a similar note, groups have something extremely similar. Each group has a “group ID”, which is commonly abbreviated as GID.

UIDs are typically looked up by looking at the user database (generally at /etc/passwd (which may simply be a file that has limited information that is derived from another database), and the GID typically corresponds to a group name that is in /etc/group (which may simply be a file that has limited information that is derived from another database). Note that these files may not be the preferred source for defining usernames: these files may be updated, rather automatically, from other files that the operating system uses when a user is authenticating (when a user logs in). (For details about where the official central information is stored, see the section about backing up users.)

[#winntsid]: SIDs in Microsoft Windows NT (and descendents)

A SID uses a GUID. (The term GUID stands for a globally unique identifier, although as described in the glossary entry for “GUID”, it might more accurately be thought of as a globally unique-ish identifier.)

(Admittedly, this section does not have a lot of information at this time.)

Preferences
Some of these settings may have defaults based on various factors such as: end user's typical physical location (such as which printers show up and which one is used by default), or other characteristics such as the person's position within an organization (such as setting the default printer for a graphics designer to a slower printer that prints with higher quality or more expensive paper, but having a financial user default to a printer that prints with lower quality but lower cost and higher speed.) Policies, including permissions, can certainly have an effect on what preferences make sense as defaults. Another example: Default outgoing E-Mail address.
[#bakupusr]: Backing up/importing/exporting users
This could mean backing up the user's data and settings stored in the user's configuration area (in Unix: ~/.*, which may be files and/or directories; in Windows: the profile, HKEY_CURRENT_USER, perhaps more...), but would also include having the basic information specific about each user (such as the username, authentication credentials, person's name, and other settings and information which may likely be unique for the user). For now, see the Disaster recovery section as it might have some related info.
Backing up the user database in Unix
Determining what to back up

There are multiple standards about where the user data may be at. The following command might show the needed files:

ls -1aF /etc/*group /etc/*passwd* /etc/*pwd.db* /etc/*shadow* 2>&1 | grep -v "No such file or directory"

(That command line includes a digit one (“1”) just after the first hyphen.)

This example may use generalizations that may not apply to a specific operating system. To elaborate on how the above command is meant to address different standards: The reference to /etc/*pwd.db* is related to the pwd.db methods as used by OpenBSD's man page for pwd_mkdb. Some other systems also use this, and some don't. /etc/*passwd* will also grab the /etc/master.passwd file: /etc/ptmp is intentionally not being backed up (even though it may be mentioned in some documentation) because this locking file won't be needed later even if it does presently exist. Kernel.org's man page for passwd says “These days many people run some version of the shadow password suite,” and so the reference to /etc/*shadow* should take care of a /etc/shadow file and a /etc/gshadow file.)

To try to find all files related to passwords, check for various documentation. The following is/are some example(s) for specific operating system(s):

User database files in OpenBSD
OpenBSD's files are listed by the operating system FAQ at FAQ 10.8: info about password files, and also in man pages such as FILES section of the man page for vipw, also FILES section of man page for passwd in section 1 of the OS manuals, OpenBSD manual page for pwd_mkdb, and the OpenBSD manual page for /etc/passwd file: this manual page may be be viewed by running “ man 5 passwd ” or looking online for the man page for master.passwd and finding FILES section of man page for master.passwd (and passwd) in section 5 of the OS manuals.)

Man page for pwd_mkdb: older versions of OpenBSD used mkpasswd rather than pwd_mkdb.

Backup process

As a generalization, details are available in the generalized section on backups. The following example shows a quick implmentation for those Unix users who have created the cpytobak script file, as described by the backups: section on copying files. (That implementation uses a fairly simple script that relies only on software that is likely to be found in a Unix system.) The first command to run, in this example, is:

for x in $( ls -1aF /etc/*group /etc/*passwd* /etc/*pwd.db* /etc/*shadow* 2>&1 | grep -v "No such file or directory" | xargs ) ; do echo \#cpytobak $x ; done

If the results look promising, then remove the word phrase “echo \#” from the sample command line, and re-run the command with that phrase removed.

(This paragraph notes old notes from an old idea for a process.) One process, which may be a bit cumbersome, is as follows: The process used by this documentation is to store things underneath /origbak/ver*. If four files are going to be backed up, and only one of those files was previously backed up, and it had been backed up twice (to /origbak/ver1 and /origbak/ver2), then /origbak/ver3 is used (and is created if needed). Since all four files are being backed up to /origbak/ver3 in order to conveniently have all these related files put into one location, three of the files being backed up to /origbak/ver3 may not have versions in /origbak/ver2 but that is okay. Also, files in /origbak/ver1 are not necessarily backed up around the same time as other files in /origbak/ver1.

(This paragraph notes old notes from an old idea for a process.) The process used by this documentation is to store the files and subdirectories of first-level subdirectories underneath a location named after a version number, so “/dirone/dirtwo/dirthree/filename” would go under “/dirone/ver*/dirtwo/dirthree/filename”.

Quick backup guide for files that are about to be changed
ls -td1 /origbak/ver* | head -n 1

(If the output of this command is “ls: /origbak/ver*: No such file or directory” then /origbak/ver1 may be used. If the output had said “/origbak/ver36” then we would be using the next higher number: “/origbak/ver37.”)

This may require root access to be making a new subdirectory directory under the root directory. Normally such a process can be done with sudo. However, it may make sense to back up the user database before setting up sudo. If that is being done, simply try su and use the password of the root account.

Then, once root access is obtained, copy the files.

In this example code, we will be using /origbak/etc/ver1/.

mkdir -p /origbak/ver1/etc
 chmod go-rwx /origbak/ver1/etc /origbak/ver1 /origbak
 cp -p /etc/*group /etc/*passwd* /etc/*pwd.db* /etc/*shadow* /origbak/ver1/etc/.

(As it is quite possible that systems using master.passwd and pwd.db typically do not use the shadow password suite (and vice versa), the above example command line probably will generate at least one harmless error message about a file not existing. (Information, about files that may be used, has been moved from here to higher in the text.)

If the current shell is still an elevated, privileged login, and if that is not needed in the foreseeable future, then the recommended habit is to return to a standard login.

exit

Backing up individual users in Unix

First, be fully familiar with how the database is stored in the version of Unix being used. For example, the file /etc/pwd.db may be what is used by login, however that file and /etc/passwd might be automatically created, and easily creatable, by using the data in /etc/master.passwd. In that case, /etc/master.passwd might be the only file that is really needed to extract a single user account. (On such systems, the other files can be re-created on an as-needed basis as long as the data in /etc/master.passwd is right.) However, other systems might not even use /etc/master.passwd nor /etc/pwd.db at all, and may instead use /etc/shadow and /etc/gshadow to store the information as well as being able to re-create the /etc/master.passwd file on the fly. So, the first step is to find out what file(s) are the primary source of information. If, like most modern implementations of /etc/passwd, a file is automatically generated by a process and, significantly, if the file lacks some key information like the user's authentication credentials, then backing up that file may not be sufficient, and backing up that file in addition to what is needed may simply be redundant.

Further details on what files are required may be located in the following blurbs of information which are specific to the operating system. Following the operating-specific information are some more generalize details.

OpenBSD
See OpenBSD man page on /etc/master.passwd (and /etc/passwd) and pwd_mkdb.

And now, back to the more generic info.

If the information, including the authentication credentials, are in a text file, then simply extract the information from the text file. In some cases, that may be able to be done with a command line such as:

grep -i username /etc/master.passwd
However, that could turn up multiple results if the searched for username is a substring of another user's name. Perhaps instead using the following could work better:
grep -i \^username\: /etc/master.passwd >> mybackup

That variation may help it so that other users aren't found, although that may be a bit more shell-dependant. The \^ is recognized by grep to mean the start of a line. (A modification would be needed to this example if trying to search for a different field.) The grep will simply output the data to stdout. It will be up the user to redirect that to a desired text file (as the previous example is meant to do) and to make sure that backup file is in a sufficient location.

[#runasrt]: Running programs as a “superuser”

This information is on a separate page: Running programs as a “superuser”.

[#runasusr]: Running a program as another user
The straightforward ways
In Unix

See the sudo command (and the su command). Details of these commands are provided in the sections about running a command as a super-user.

In Windows

Use RunAs, which may be “%windir%\system32\RunAs.exe”. Specifically, something similar to the following complicated syntax may be used somewhat frequently:

RunAs /user:MYDOMAIN\Administrator "Notepad \"my file.txt\""

(That example used Notepad, and used quotation marks to surround the filename (since Notepad supports such a syntax to specify a filename that contains a space). If such information didn't need to be passed to the program, it could be skipped.

Alternatively, there may be a graphical approach to run as a username that can be configured. There might also be another graphical option to run a program as an Administrator.

Some documentation about EPAL discusses a program called “Microsoft Elevated Privileges Application Launcher”. The documentation makes this seem like it was a downloadable program meant for use with Windows 2000. (Presumably this indicates that Win2K did not have RunAs.)

Other ways may include taking other steps, such as causing a program to run as a certain user when initiating remote access in a certain fashion (such as logging in with a certain username with an SSH client, or visiting a web page that uses CGI).

Graphical Interfaces for User Management
Microsoft Windows

The Control Panel may have a Users applet. On at least some systems, it may be possible to use the networking control panel applet to open the control panel applet for users, using “ control Ncpa.cpl users ” (as documented by Microsoft KB Q192806.

MMC may also provide an interface. (This same sort of interface may also be seen within Computer Management.)

On a domain controller, in the (Control Panel's) Administrative Tools, check for Active Directory Users & Computers.