Article ID: 950934 - View products that this article applies to.
This article describes a scenario in which Windows Explorer prompts you to click Continue to gain access to a file system folder for which you don’t have Read permissions. It also describes workarounds to avoid particular aspects of this behavior. This issue occurs in Windows Vista and later versions of Windows and in Windows Server 2008 and later versions of Windows Server. Note that Windows Explorer is called File Explorer in Windows 8 and later versions.
Assume that User Account Control (UAC) is enabled, and you use Windows Explorer to access a folder for which you don’t have Read permissions. Additionally, the folder is not marked by both the Hidden and System attributes. In this situation, Windows Explorer displays a dialog box that prompts you with the following:
Note In Windows Vista and Windows Server 2008, the second sentence does not include the word “permanently”; it just says “Click Continue to get access to this folder.”
You then have the option to click Continue or Cancel. (Continue is selected by default.) If you click Continue, UAC tries to obtain administrative rights on your behalf. Depending on the UAC security settings that control the behavior of the UAC elevation prompt, and on whether you are a member of the Administrators group, you may be prompted for consent or for credentials. Or, you may not be prompted at all. If UAC can obtain administrative rights, a background process will change the permissions on the folder, and on all its subfolders and files, to grant your user account access to them. In Windows Vista and Windows Server 2008, the background process grants your user account Read and Execute permissions. In later versions of Windows, this process grants your user account Full Control.
This behavior is by design. But because the typical pattern with UAC elevation is to run an instance of the elevated program with administrative rights, users may expect that by clicking Continue, this will generate an elevated instance of Windows Explorer and not make permanent changes to file system permissions. However, this expectation is not possible, as Windows Explorer’s design does not support the running of multiple process instances in different security contexts in an interactive user session.
If UAC is disabled, UAC elevation is not possible. All programs that are run by members of the Administrators group, including Windows Explorer, always have administrative rights. Therefore, administrators do not need to use elevation to access resources that require administrative rights. For example, if a folder grants access only to the Administrators group and the System account, an administrator can browse it directly without being prompted to alter the folder’s permissions. If the user does not have Read permissions, Windows Explorer displays the dialog box that was described earlier. However, if UAC is disabled, Windows cannot request administrative credentials on behalf of the user through a UAC elevation prompt. Therefore, Windows will not start a background process with administrative permissions in order to change file system permissions.
However, if the user clicks Continue and the folder’s current security descriptor grants the user permission to both read and change the object’s permissions, Windows will start the background process in the user’s current security context and modify the folder’s permissions to grant the user greater access, as described earlier. The user may have permission to read and change the object’s permissions from object ownership or from the object’s access control list (ACL).
Known issuesThis feature may cause unexpected behavior. For example, assume that you belong to the Administrators group and that you use Windows Explorer to access a folder that requires administrative access. After the permissions have been changed, any program that’s running through your user account can have full control of the folder, even if the program is not elevated and even after your account has been removed from the Administrators group. Such altered permissions may violate an organization’s security policies and may be flagged in a security audit. Additionally, if a program verifies file system permissions, it may refuse to run if the permissions have been changed.
UAC should remain enabled in all cases except under the constrained circumstances that are described in the following Microsoft Knowledge Base article:
Disabling User Account Control (UAC) on Windows Server
Workaround 1To avoid changing permissions in a folder that’s accessible only to administrators, consider using another program that can run elevated instead of using Windows Explorer. Examples include Command Prompt, PowerShell, and the Computer Management MMC snap-in for share management.
Workaround 2If you have an application-specific folder that’s locked down to prevent ordinary users from accessing it, you can also add permissions for a custom group and then add authorized users to that group. For example, consider a scenario in which an application-specific folder grants access only to the Administrators group and to the System account. In this situation, create a domain or a local AppManagers group, and then add authorized users to it. Then, use a utility such as icacls.exe, the security tab of the folder’s Properties dialog box, or the PowerShell Set-Acl cmdlet to grant the AppManagers group Full Control of the folder, in addition to the existing permissions.
Users who are members of AppManagers will now be able to use Windows Explorer to browse the folder without UAC having to change the folder’s permissions. Be aware that this alternative applies only to application-specific folders. You should never make any permission changes to folders that are part of the Windows operating system, such as C:\Windows\ServiceProfiles.
Article ID: 950934 - Last Review: January 15, 2014 - Revision: 5.0