Link to home
Start Free TrialLog in
Avatar of ccfcfc
ccfcfcFlag for United Kingdom of Great Britain and Northern Ireland

asked on

NTFS security permission issues in Windows Server 2012

Hi,

Im not sure if some are aware of the potential issues administrators face with NTFS security permissions on the C drive of windows server 2012. However, it seems that even as a local administrator, or domain admin, you are not able to edit some locations within the C drive. Although, at the root of the C drive, I can that the local 'Administrators' group has been given full access, but when I go to a specific directory such as C:/windows/Microsoft.Net/, user accounts (either local administrator or a domain admin) are not able to write to this directory.

To get around this, I have to remove ownership of the folder from 'TrustedInstallers' to the local administrators, and filter that ownership change down to all child objects. Then I am able to make write to that directory.

The same goes for installed programs. Some accounts are not able to write to C:/program files/, causing some applications to stop working, as the accounts they're running as, don't have the relevant permissions to run.

Is there a policy (preferably at domain level) which will allow me to change these permissions to allow the relevant security groups to have the right access?

thanks in advance for any help.

Anton
Avatar of Joseph O'Loughlin
Joseph O'Loughlin
Flag of Ireland image

For the applications that need permissions to their c:\program files\ directories
Create a security group in the domain
When installing the app, towards the end of the process, modify permissions to the folder granting the permissions needed to the security group.
Add the user to the group
Most vendors document the permissions needed.

The behavior of Trusted Installer/permissions is as intended, to improve windows security, app isolation, and have developers update their applications accordingly.
Do not alter windows system folders security, we never knows what functionality it may break, its not recommended.

Ensure that your AV software is not blocking any thing

Also logon to server with account that is member of local administrators group on server and also run any applications with elevated privileges (run as administrator),
Then you should not face any issue

You can disable UAC if wanted to
We had a similar issue not to long ago and after installing all the windows updates we where able to acces file shares.

Search for Microsoft KB2822241, it could ge related.

DirkMare
That is not 2012 specific. With all previous versions it was the same, some directories or registry branches are kind of system reserved, because windows does not think an admin should have reason to change those.
Avatar of ccfcfc

ASKER

We tried the add to group option.. you still do not have any permissions to the folders. Hence the question about best practice to get aroudn this. Adding users to a security group does not allow you to add permissions . We took ownership of the folder then we could modify child objects. Even being  amember of Domin Admin still meant we were unable do anything. So we took ownership as Local Administrator.
SO what you are saying this is a new feature or the way it is or the Windows updates fixes this issue  ?

Appreciate your feedback and the 2012 experience is fairly new and hitting quite a few brick walls along the way
Yes in our environment with VM 2012 and r2 servers on vmware hosts we had to install the updates.

DirkMare
Avatar of ccfcfc

ASKER

Dirk Mare,

Thank you for your time.

All of the servers sitting on this platform, are all running the same base image.

I can see that this update you specified is already installed.

The last batch of updates were installed on these images on 8th March 2014.

Is there anything else that might be worth trying?

thanks
ccfcfc, the behavior is normal. As I wrote before, the system does not want anything to be changeable. What you can do:
Turn off UAC, in order to see what effect that has. There is another security layer that is called MIC (mandatory integrity control), that even overrides NTFS. MIC is not effective with UAC off or when running elevated.

Generally, being an admin on UAC enabled systems needs programs that are UAC aware. Explorer is UAC aware, it will notify you as an admin when your session token needs to be elevated. UAC has been around since 2006 (Vista/server 2008).
Please try disabling UAC as Mahesh suggested above. Also in your registry.

You can switch UAC off by amending the registry:

"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system"

Change the Value of DWORD "EnableLUA" from 1 to 0 reboot.

DirkMare
Avatar of ccfcfc

ASKER

DirkMare

Thank you again for your response.

I tried the suggested a few days ago following some research on some forums, and rebooted. I can see that the 'EnableLUA' is set to '0' already and was rebooted.

This didn't make access any better for us.

Anything else that might be worth trying?

Thanks

Anton
The same goes for installed programs. Some accounts are not able to write to C:/program files/, causing some applications to stop working, as the accounts they're running as, don't have the relevant permissions to run.
Is there a policy (preferably at domain level) which will allow me to change these permissions to allow the relevant security groups to have the right access?

What permissions are you trying to assign to the groups? Can you give us some screenshots of the current permissions?

Do you have FULL permissions for System? And Read for Everyone?

DirkMare
You are trying to stop windows from working as designed, and revert to the behavior of earlier versions.
You will need to go through application by application, and check the documentation / with support any changes you may need to make. I expect you to be advised to update some of the applications to newer versions.
Avatar of ccfcfc

ASKER

One example, is IIS. We were able to import a group of sites into IIS. Then we tried to browse to the page and received this error:

domain\username does not have write access to C:\Windows\MicrosoftdotNet\Framework

The user account which the app pool is running is included in the 'IIS_IUSRS' group, yet the issue still persists.

To get around this, I had to give the account read/write/modify access to the directory. I couldnt do this however logged on as a domain admin, as the TrustedInstaller (the owner) hadnt specified permissions for the domain admin (although the domain admin is running as a local administrator). To get around this, I made the above directory owners to the local administrators group, and then this allowed me to specify permissions for the folder and the child objects.

this seems to have resolved the issue.

going forward however, we will have many servers running IIS and do not want to spend hours changing permissions within windows explorer and wondered if there is a solution/way around this problem? Ideally, id like to enforce something using group policies across the domain.

Any help will be much appreciated.

Thanks
Hi Anton
From
http://technet.microsoft.com/en-us/library/cc756952(v=ws.10).aspx
you can see how to assign permissions by group policy,
but note the advice that modifying access control lists in this way can be a burden on the network.
From experience, it's best to set the permissions once, when the application is installed.  I'd advise against using group policy for this,
Joseph
Avatar of ccfcfc

ASKER

Joseph,

Thank you for you comment above. Can you explain the reasons why you believe using GPO could be worse off? It's just going forward I would have to explain to my management the reasons for this?

Effectively, we have a couple of options I am considering. I am considering testing on a new AMI, and building a new server and making the local administrators the own of the 'C:\' directory.

Second, is we live with this issue, each time the problems occur, we allo administrators to take ownership of the affected directory and then apply the relevant permissions. However, we are in the process of building a network which could contain hundreds of servers going forward, so the ideal solution would be to find a remote way of resolving problem?

Thank you for your time.

Kind regards

Anton
Between 8am and 9:15 in the morning their's a login storm, with synchronization of ost files etc.
Because Global Policy network traffic is UDP it is dropped in this situation.
The permissions will only be successfully applied once the network has light traffic and low low latency.
One of the original design objectives for using group policy rather than imposing direct changes to make the change is transitory, so that a contractor who's laptops on the domain is not locked down while away.
Think of group policy as overlays of registry settings.
If the cumulative size of the group policies is too large, you'll be forever troubleshooting the output of
gpupdate /force
You could write a script (per install) making the permissions changes using cacls or similar.
Avatar of ccfcfc

ASKER

Joseph, is this the only implication?

This GPO would be made on a production platform, meaning connectivity bandwidth should be fair consistent through out the day.... meaning no severe spikes should cause a problem as stated above.

Thanks
Can't say.
Too dependant on product mix and environment
Avatar of ccfcfc

ASKER

I've requested that this question be deleted for the following reason:

There doesn't seem to be a specific solution to this question, and don't see any reponses feasible for 500 points.
ASKER CERTIFIED SOLUTION
Avatar of Joseph O'Loughlin
Joseph O'Loughlin
Flag of Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial