I have a Windows Server 2003 box acting as a file server. It hosts numerous shared folders with various permissions. The 2003 box is not the Domain Controller / Active Directory host; Active Directory is run on a server outside our control but we believe it is Server 2008 R2.

I have discovered that staying logged in to the Windows Server 2003 box over Remote Desktop Protocol (RDP) causes security permissions in Windows Explorer to become outdated, like the server is caching the permissions that were there previously.

Steps to Reproduce:

  1. Go to the disk hosting the shared drives in Windows Explorer, e.g. Z:

  2. Choose a folder that is shared, right-click and go to Properties, then click the Security tab.

  3. Observe the permissions that are there.

  4. Log Off of your RDP session, and connect again.

  5. Repeat steps 2 - 3.

  6. Note that the permissions do not match.

I am 100% certain that no other users or administrators are modifying the permissions. The permissions for the shared folders are ONLY modified by one Administrator logged into this box. Pressing "F5" (Refresh) in Windows Explorer does not refresh the permissions. This causes the administrator to believe that there are different permissions on the folders than the actual, effective permissions that the clients see.

The most perplexing thing is that clients (end-users) connecting to the shared folders can see the actual permissions. For example, if a user is actually denied access to a folder, the cached permission granting them access may be displayed on the server, but the client will be unable to access the folder. However, the change in permissions will not be displayed on the server until the administrator logs off, then logs back on.

Is there a way to either force the system to automatically update the permissions rather than caching them, or to manually do so? Is this a bug that is addressed by a service pack, or is this a "by-design" feature?

In the case that a user is "cached" and appears to be added to the list of custom permissions for a folder, the behavior is most strange: you can change the permissions for the user, e.g. from Full Control to denying all permissions and back, with no errors reported by the operating system. But making these changes and clicking Apply will have no visible effect to the client, and when you log back into the server after logging off, the user won't appear in the list of users with custom permissions at all!

  • What you describe is certainly not the normal behavior of Windows regarding permissions. You might want to take a look with my tool SetACL Studio to get a second opinion. – Helge Klein Aug 21 '12 at 19:14
  • Procuring paid software in my environment is 100,000 times more painful than logging off / logging in every single time I want to make a change to my system. Installing free (as in beer) software is ALMOST as bad. Unfortunately I won't be able to use your tool. I know it's not the normal behavior, so I'm trying to troubleshoot it. – allquixotic Aug 21 '12 at 19:18
  • 1
    I have never seen the behavior your describe. But you might get better results if you skip windows GUI, and use icacls, or the CLI version of SetACL. BTW, are you sure that you aren't mixing up the share permissions with the NTFS permissions? Please excuse me saying this if you already know it. But the permissions on shares is unrelated to the filesystem ACLs. – Zoredache Aug 21 '12 at 19:57

Mmmm. Assuming, like Zoredache points out, that you are talking about NTFS file system DAC lists, then the problem is almost certainly not to do with your domain controller.

When you set permisions on the file system, the server tags the file system object with the SID of the security principal that you are granting the permission to. If you are using a local user account / local group, then the SID will be one specific to the server. However, in a domain model, you may be referencing a domain global or domain local group, in which case, the SID of the domain-based security principal will be tagged on to the file system object.

As an aside, best practice still dictates that you should use local groups on the file system, with domain global/domain local groups in those local groups. This theoretically cuts down on server-to-DC/GC SID lookups.

Once the SID tag has been applied, it will still persist even if the DC/GC is offline or unreachable; you'll just be presented with an unresolved SID.

So, suggestions:

  1. Perform a CHKDSK of your disk to ensure that the NTFS master file table (MFT) is OK
  2. Use ICACLS.EXE (not CACLS.EXE or XCACLS.EXE) to check permissions - all three of these are Microsoft tools. Do your test again, i.e.: check perms, grab ICACLS output, set perms, grab output, logoff, logon, check perms and grab output. Post output here.
  3. If not already, consider using the local group model.

I (we?) await more info...

| improve this answer | |
  • Thanks for your response! Unfortunately we can't reproduce the behavior now, and I don't think we're confusing NTFS filesystem ACLs with share drive permissions. We check both Properties and the "Sharing and Security" tab of every folder and they're always in sync. icacls shows nothing revealing and the permissions are now updating appropriately when we add or remove someone from the ACL list. BTW, we do use local groups, but we have to use individual domain users due to extremely custom permissions in some situations. – allquixotic Aug 22 '12 at 1:28
  • BTW, we already performed a CHKDSK. No errors reported. ICACLS showed permissions the same as Windows Explorer, which is to say, everything is working. The problem is that we don't know how the original problem occurred and don't know if it'll come back. It caused a lot of headache because we were sitting there looking at the permissions for a user set to Full Control but they were still getting access denied. Then we logged off on the server, logged back on, and he wasn't in the ACL list at all! – allquixotic Aug 22 '12 at 13:38
  • Don't you just love problems like that! ICACLS has a neat /SAVE option - you could build a DACL list periodically and then compare it to the last one, to see if anything is getting fudged. – Simon Catlin Aug 22 '12 at 19:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.