Windows Server 2016: Security-Bug in Profile Security Settings

[German]German blog reader Martin Feuerstein pointed out a bug in the security permissions of the default user in Windows Server 2016. I am reporting the details here, maybe somebody else can confirm it.


The original comment (in German) may be found here (thanks for that). I hope, the post catches the attention from other admins, who are able to confirm it (or decline it for their environment).

Environment: Windows Server 2016 and Terminal Server

The environment of Martin is a Windows Server 2016 installation with German language settings. On this server Windows Terminal Servers are used for users. Here are the build number.

Windows Server 2016 Build Number

The problem: A bug in the profiles security permissions

Martin writes that there is a bug in the security permissions of Windows Server 2016. During the setup of new terminal servers with Windows Server 2016, various users with new user profiles were shown files of other users (visible at the owner property of the respective file).

Security Settings default desktop
(Wrong Security Settings default desktop)

The root cause for this behavior: The security permissions in all subfolders of the default profile, i.e. Desktop, Documents, Music etc., are faulty (see screenshot above).



The previous screenshot shows that users can create, write and modify files. This has the following effects:

  • Users are given permission to create files and folders in default profile.
  • In addition, when opening the Properties dialog box, an error message appears stating that the sequence of security permissions is incorrect.
  • Various programs, including Microsoft Office and the Foxit Reader's PDF printer, offer the default user's desktop as a storage location when the file selection dialog box Save as is opened.

Wrong permission warning

Martin sums it up like this: Already converted users did not pay attention when saving, so the files were stored on the desktop of the default user. For the users who were subsequently converted, the default user profile was copied as a template, so that the files were copied from the default desktop to their desktop in the user profile.

Martin writes that the problem does also occur within an English language Windows Server 2016. According to Martin Windows Server 2019 and Windows 10 1909 doesn't have these extra permissions issues.

The consequences of this bug

As a consequences of this faulty permission, IT managers in the environment outlined above probable have a problem. Martin named the following scenarios.

  • a user could inadvertently make protected data accessible to other users with new profiles
  • a user could deliberately provide disturbing data to new users
  • a user (without admin rights!) could inject malicious stuff to newly created profiles for administrators (and domain admins!)

Especially the latter item is a security issue, as the user could, for example, place a shortcut to a malicious script in the Start menu's autostart folder.

There is a fix

Martin Feuerstein provided in his comment a fix allowing administrators to reset the permissions for the default profile folder. To do this, open an administrative command prompt and type the following command:

ICACLS c:\users\default\* /T /Q /C /RESET

The parameters listed in the above command are described in the blog post How to reset NTFS permissions with ICACLS from Is Solving. Thanks again to Martin Feuerstein for his description, analysis and fix. To you the question: Has anyone noticed this yet?

Note: Martin wrote, that the default profile is not customized. He could reproduce the incorrect permissions on other Windows Server 2016, even without remote desktop role, in a different environment.

Cookies helps to fund this blog: Cookie settings

This entry was posted in issue, Security and tagged , , , . Bookmark the permalink.

2 Responses to Windows Server 2016: Security-Bug in Profile Security Settings

  1. Mbr says:

    thanks for the good article. we have the same reproducible issue.

  2. Nacho says:

    Hello, thanks,
    I have the same problema, and same resolution

Leave a Reply

Your email address will not be published. Required fields are marked *