Home / server / Questions / 310069
Accepted
surfasb
Asked: 2011-09-11 10:15:15 +0800 CST

strange case of Domain admin != local Admin

  • 772

I've ran into a strange issue. Our domain admin accounts, for some odd reason, aren't seeing certain files. It was mainly on three workstations that were off the network for a while for hardware repairs and were rejoined.

The three workstations are running 7 SP1. The respective Domain controllers that were used as logon servers are running 2008r2 x2, a 2008sp1, and 2003sp2. The domain is a 2003 level.

When they were first rejoined to the domain, there were authentication issues. So they were rejoined under three new computer accounts with new names.

Now it seems Domain and Enterprise Admins are having an issue where if they create a symlink(requires local admin privileged) or move a file into an (local) admin privileged folder, the newly created file is cannot be seen from File explorer.

But if we open a command prompt, the file shows up on the directory listing. . .

I've been looking into the problem all day, digging through the event logs on the three workstations and the respective logon servers they connect to each time.

I've tried auditing the accounts as the logon for failures, but I'm not 100% sure I'm covering all the bases. I thought it was an open and shut case as the accounts were being logged in before the network adapter was fully initialized, thus GPO errors would show up. But after logging off and logging in again, no dice. A full reboot does the trick though.

group-policy authentication windows-server-2008-r2

2 Answers

  1. I've seen this, or at least very similar issues with files not appearing after creation, but appearing in the command shell. It seems that Windows 7 gui shell may not update a folder under these circumstances, or a combination of them, if you have a share mapped to a drive and it's currently unavailable:

    • The folder in wich you create files is accesible over the network as a share
    • The folder is accessed over the network and is configured to sync so you can access it offline

    You could draw the conclusion that its using a queue system to update and that an inaccesible network share is blocking all other updates until it resolves.

    • 1
  2. Best Answer

    So I found the problem later that day. While I unjoin and then rejoined the workstations under brand new computer accounts, I failed to take into account that the profiles being logged in weren't authenticating correctly. They never showed up as failures because the workstations were authenticating them under the cached logins.

    After wiping the cache, they authenticated correctly.

    • 0