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:
-
Go to the disk hosting the shared drives in Windows Explorer, e.g. Z:
-
Choose a folder that is shared, right-click and go to Properties, then click the Security tab.
-
Observe the permissions that are there.
-
Log Off of your RDP session, and connect again.
-
Repeat steps 2 – 3.
-
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!
Best Answer
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:
I (we?) await more info...