none
Changing NTFS permission for a shared folder RRS feed

  • Question

  • I have an application that changes the permissions of a share remotely. I have a working API for share permissions and I am changing the NTFS permissions using the following API.

     

    Code Snippet:

    string sharePath = @"\\servername\sharename";

    DirectorySecurity dirSec = Directory.GetAccessControl(sharePath);

    dirSec.AddAccessRule(new FileSystemAccessRule("CONTOSO\UserA", FileSystemRights.FullControl, AccessControlType.Allow));

    Directory.SetAccessControl(sharePath, dirSec);

     

    This works well till my share resides on a computer in same domain. But when my computer is in different domain it fails with,

    error 1326 "Logon failure: unknown user" while trying to access network share

     

    What can I do to make this working in different domain. I have the required credentials (admin on the box that the share resides) but not sure where to use them.

     

    Also, I am open to using any other API too.


    Regards, Radhika - Posting is provided "AS IS" with no warranties, and confers no rights.
    Saturday, January 28, 2012 7:14 PM

All replies

  • Hi Radhika

    check below link. it may be some help to you resolve  your problem

    http://stackoverflow.com/questions/5241718/taking-ownership-of-files-with-broken-permissions

     

    HTH

    Raju

    Sunday, January 29, 2012 6:12 PM
  • Thanks for the suggestion. I tried using the above solution but I think I have a different problem. My application is running under an account which is in a different domain as the share, hence it's not able to translate/verify the account information resulting in the above error. But if I have the correct credentials there has to be a way to make this call remotely.
    Regards, Radhika - Posting is provided "AS IS" with no warranties, and confers no rights.

    Monday, January 30, 2012 5:54 AM
  • Hi,

    you need to use one of  the overloads of the  WindowsIdentity.Impersonate() method: http://msdn.microsoft.com/en-us/library/system.security.principal.windowsidentity.impersonate(v=vs.100).aspx

    In this way your code run`s under a different ( the imperonated ) account.


    Hannes

    If you have got questions about this, just ask.

    In a perfect world,
    users would never enter data in the wrong form,
    files they choose to open would always exist
    and code would never have bugs.

    C# to VB.NET: http://www.developerfusion.com/tools/convert/csharp-to-vb/
    Monday, January 30, 2012 6:59 AM
  • Thanks for the suggestion. I already tried impersonation and it fails with,

    The security database on the server does not have a computer account for this workstation trust relationship.

    Is there a different way to impersonate in a different domain?

     


    Regards, Radhika - Posting is provided "AS IS" with no warranties, and confers no rights.
    Monday, January 30, 2012 7:07 AM
  • Can you show your code, that part which doesn`t work for impersonation ?
    Hannes

    If you have got questions about this, just ask.

    In a perfect world,
    users would never enter data in the wrong form,
    files they choose to open would always exist
    and code would never have bugs.

    C# to VB.NET: http://www.developerfusion.com/tools/convert/csharp-to-vb/
    Monday, January 30, 2012 7:38 AM
  • Consider adding the other domain controller in the DNS resolution list (EDIT: I'm refering to something like "netsh interface ip add dns" command, but you can just add the new nameserver using dialog provided by "Network Connections"), your "application" computer (I'll just call it "workstation") may not be able to find the logon server of another domain. (I think you'll need to resolve  something like "_msdcs.<domain_name.com>" or "<whatever>._tcp/_udp.<domain_name>.com" for it to work) I think this is the primary reason to fail, but I suspect you can still fail after that because the workstation does not have "shared secret" of remote domain to do SMB signing.

    Even if this is successful, put the workstation on for a few days, then study the event logs of workstation and the remote domain controller to see if there's non-desired effect.

    However, I think the proper way is to have "cross domain trust" be setup between the domains. Just that it's hard to persuade the system administrators to do so.




    Monday, January 30, 2012 8:10 AM
    Answerer
  • However, I think the proper way is to have "cross domain trust" be setup between the domains. Just that it's hard to persuade the system administrators to do so.

    Yes what you decribe is exactly my problem.

    The thing is that, I need my application to work for non-trusted domain scenarios i.e. it is okay that the share can reside on a machine in non-trusted domain.

    Having said that I do have admin credentials of the machine (doman account in untrusted domain) on which the share resides.


    Regards, Radhika - Posting is provided "AS IS" with no warranties, and confers no rights.
    Monday, January 30, 2012 6:12 PM
  • Maybe you should just ask the system admins to set it up for you? I think this IS their duty.

    Tell them to set the workstation to be able to access the fileserver with that account in Explorer, so you can continue your work. (Unless you're unfortunate as I was, being the only one who maintain those servers)

    Tuesday, January 31, 2012 1:08 AM
    Answerer