471,316 Members | 1,026 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,316 software developers and data experts.

Secruity on remote folders

Hello all,

I've spent a lot of my time on this issue, and I thought it best to
share my solution with the community. A special thanks to Willy
Denoyette for his help. Ive opened about two threads to try and get
this solved and neither of them contain a full solution; but this one

So the scenario is, I need to change the file permissions on a remote
folder using WMI. I was attempting to do this using a UNC path, which
is not the right way to go about it, because when you access file
security from a UNC path with WMI you get the share permissions as
opposed to the physical file permissions (at least this appears to be
how it works -- perhaps Willy, you could confirm?).

This said (as pointed out by Willy), we need to access the security
from a local path, which is possible once you're connected to a remote
machine via a WMI scope/path etc. So, step by step, this is how it's
done -- for those who are having trouble, this is definitely the best
way to do it, and it works.

I have tested the following procedure on a Windows 2003 server, which
is not part of a domain. This has also been tried using ADSI with
little success.

1. Create e a new scope which points to the remote machine.
2. Create a new Win32_LogicalFileSecuritySetting path based on the
3. Create a new management object based on the above path (file
4. Invoke the GetSecurityDescriptor and gather the out parameters.
5. Retrieve the "Descriptor" property from the out params.
6. From the new "Descriptor" object, retrieve the "Dacl" property.
7. Create a new Win32_Trustee ManagementObject from ManagementClass.
8. Make sure you're using the scope which points to the remote machine.
9. Set the "Name" property to the name of the user account on the
remote machine.
10. Create a new Win32_ACE object from ManagementClass.
11. Set the "Trustee" property to the Win32_Trustee object in step 7.
12. Set the "AccessMask" property of the Win32_ACE object*.
13. If you want to inherit the parent's Dacl, set the "AceFlags"
property to 0x10.
14. Generally speaking you want to have an "Allow" ace, so set the
"AceType" to 0.
15. Convert the current Dacl to an array list (or similar) and add your
ACE to the list.
16. Set the descriptor's "Dacl" property to the Dacl array list
(converted back to an array).
17. From the file security object (step 3) get the parameters for
18. For the parameters, set the "Descriptor" property to our security
descriptor (step 5).
19. For file security (step 3) invoke the SetSecurityDescriptor passing
the parameters.

Seems like a very complex solution, but for a remote machine, it's the
only way. Again, thanks to Willy for his guidance. Please see below for
the notes on the access mask described in step 12.

Happy coding!

Nick Bolton
Rensoft Web Services

* I used the following variables to set the bits.

int FILE_READ_DATA = 0x0;
int FILE_WRITE_DATA = 0x1;
int DELETE = 0x10000;

If you need to allow a user to modify, I used this but I'm not entirely
sure it's perfect because the Windows security properties still show it
as "special" permissions.

newAce.Properties["AccessMask"].Value = FILE_READ_DATA |

Jan 22 '06 #1
3 2796
Also, this thread may interest you if you're experiencing problems.


Jan 22 '06 #2
Another point to note; in step 12, instead of using bitwise flags (as
described in the foot note) you can simple cast enumerations of the
FileSystemRights in to integer. For example...

newAce.Properties["AccessMask"].Value = (int)FileSystemRights.Modify;

Jan 22 '06 #3
With regards to points 4 though 6, if you want to inherit the Dacl
instead of overriding with a new list, start off with a new empty Dacl.
This way you will only add the new ACE which is a more elegant solution.

Jan 22 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by =?Utf-8?B?UHJhZGVlcCBFYXJsYQ==?= | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.