I ran into the same problem, and I found this link : Windows server 2012 UAC Folder problem
I have the problem on a server that is in production, so I didn't test it yet.
I'm running into a weird NTFS/group permissions issue that I just can't wrap my head around at all. I'm really hoping someone can help me make sense of this. I have created a Server 2012 Active Directory domain and have created a second domain administrator account by creating a new user and adding that new user to the exact same groups as the default "Administrator" account. Seems simple, right?
I've also created a default file share to be shared by all staff, as a test. The file share is in C:\Shares\SharedFolder, for simplicity sake. I've disabled inheritance on the "SharedFolder" and crafted my own permissions [keep in mind in Server 2000 and Server 2003 I have always done this and had absolutely no issues]. For share permissions, DOMAIN\Administrators = full control, and DOMAIN\Staff = full control. Both of these are groups. For Security, I have DOMAIN\Administrators = full control, and DOMAIN\Staff = modify. Again, both of these are groups. Then SYSTEM also has full control in Security.
Great. Looks good. The identical setup on the previous Server 2003 network works flawlessly and always has. Now, because one of the 2003 servers is being carried over to the new network and virtualized, I've already used Disk2Vhd and converted it to a virtual machine, removed it from the previous domain, and added it to this domain as a test member server within Hyper-V on the domain controller. So, I then log out of the domain controller after making the group and security changes for the share. I have a login script that adds the share as a drive letter.
Now, I log in to the domain controller [via RDP, same way I did the configuration with DOMAIN\Administrator] as the new test admin account, in the identical groups as the default Administrator account, and I notice I can't access the share. I see it in Computer, but I can't open it because I don't have permissions. Now, since the actual share folder resides on THAT machine that I'm RDP'd into, I open C:\Shares, and when I double click on SharedFolder, I got the "You don't currently have permission to access this folder. Click Continue to permanently get access to this folder." message, and then the Continue with UAC shield button. What's worse, is if I open a second RDP session and login as Administrator, and create just a new folder in the root of C, and then switch back to my test admin RDP session, I can't delete the folder without first right clicking on it, editing permissions, adding the test user that I'm logged in with, giving myself full control, applying, and THEN I can delete the folder.
Just for fun, I logged in to the test VM I had carried over, running Server 2003, which is now on this network as a member server. I was able to log into that machine locally via Hyper-V manager, using the test domain admin account, and permissions worked perfectly. I could access the share with absolutely no issues and create and delete files/folders inside of it.
Can someone please explain to me why this doesn't work in Server 2012, despite the test user having identical group permissions to the default Administrator account for the domain? I thought the idea was to be able to use groups whenever possible, but this share doesn't work unless I specifically define the individual user account of the new domain admin user.
Last edited by link470; 22nd July 2013 at 06:03 AM.
Glad I'm not the only one! I think you're right, from the reading I've been doing too it appears to be a feature with UAC, albeit one that makes very little sense on anything besides the Windows system directories.
So far, this is the best solution I can find, but I also haven't implemented it yet. The good news is it only deals with GPO changes and not editing the registry directly. Check out the marked solution on this page: All-users-required-for-folder-access. The main one that caught my attention was "User Account Control: Run all administrators in Admin Approval Mode: Enabled".
Last edited by link470; 27th July 2013 at 03:14 AM.
Ya I haven't tried using Explorer++, but I'm convinced it's a feature of UAC and by design. Although I'm still slightly confused at why that would be the case for a simple folder access. I can understand the need for UAC/permission add-ons for editing a core system file, and I can understand maybe launching a system application at an Administrator level, but just opening a directory that Administrators and Domain Administrators all have access to already according to the ACL's just doesn't make sense in my mind.
Its much worse then you think. Try running a server with applocker where a member of the default user group can't run a program, but admin can. Make the program one such as winlogon if you want (needed to logon). You won't be able to logon due to the standard user token not being able to access the program.
However the default admin has no issues in the same area for some reason.
I disabled Useless Account Cr*p as a result.
Took me a while to debug the login issue as well.
There are currently 4 users browsing this thread. (0 members and 4 guests)