none
Service Accounts and Network Shares RRS feed

  • Question

  • I have a service running which has the sole purpose of transferring files from a local directory to a network share in a domain environment.

    The problem is that the Local System account is unable to authenticate with the network share. I tried granting the computer account rights to the share but authentication still fails. In this scenario, I cannot create a user account on the domain that the service can log on as due to company policy.

    So, is there any way to get any of the built-in accounts to gain access to this share? Whatever account I use, it can only have modify rights to the share.

    Friday, December 2, 2011 9:37 PM

All replies

  • Hi,In domain environments you can assign priviliges to the computer account, that should work. You can use psexec to launch processes (like cmd.exe) under the system account, that might be helpfull in troubleshooting such an issue.

    However, because "system" has no user session, it will not be able access mapped network drives. Instead configure the service to contact UNC paths using FQDN's \\server.domain\share\folder\file.ext

     

     


    MCP/MCSA/MCTS/MCITP
    • Edited by SenneVL Friday, December 2, 2011 10:57 PM
    Friday, December 2, 2011 10:56 PM
  • SenneVL,

    Thank you for your reply but it seems the information you provided will not resolve my problem.

    You first mentioned that assigning privileges to the computer account should work but in my case it hasn't. Example, ComputerA contains the local directory and the service that is trying to copy the contents of that local directory to a network share. I granted modify rights under ComputerA$ on the network share but still, authentication fails.

    In regards to your mention of mapped network drives I will point out that this service is indeed configured to point to a UNC path. The network share is NOT mapped to ComputerA.

    Friday, December 2, 2011 11:16 PM
  • Hi,

    please check the privileges on both the share as on ntfs to include the computeraccount.

    On the remote computer, use pseexec, linked in my previous post, to open cmd.exe as the system account. From that command prompt you can verify whether the system account can access the share using the net use command. Please post back with the error you encounter, if any.

    Also check whether the service is indeed configured to start as local system or network service account, not the local service account. The network service account should be prefered over the others, security wise.  (but in fact using a well configured and managed service account will be far more secure!)


    MCP/MCSA/MCTS/MCITP
    • Edited by SenneVL Saturday, December 3, 2011 12:47 AM
    Saturday, December 3, 2011 12:43 AM
  • The permissions for the share are set to allow access to anyone and everyone. The permissions on the NTFS side are set to allow Modify rights to ComputerA$.

     

    I used the folowing command on ComputerA to test the Local System account...

    "psexec -i -s net use z: \\ComputerB\Share"

    I receive the following message immediately after executing the above command...

    "The password is invalid for \\ComputerB\Share.

    Enter the user name for 'ComputerB':"

     

    I can confirm that the service is indeed configured to start as local system and not Local Service.

    Friday, December 9, 2011 1:25 AM
  • Alternatively,

    We COULD use a user account on the domain for the purpose of network authentication but the problem is handling password changes if that is ever a need. Ideally, the Local System account is wanted for the sake of avoiding password change issues.

    But if there is a simple and effective method of handling that other than manually logging on and changing the password set in the service properties that could be considered.

    We still need to answer the question though..is the Local System account capable of authenticating to network shares over a domain or is it not? And if it is, how do I make it work?

    Monday, December 12, 2011 10:19 PM
  • Are we out of ideas here? :(
    Tuesday, December 13, 2011 8:46 PM
  • Sorry, as far as I know this should just work, however I did not find time yet to test this properly.

    A service account is in fact the best practice, an manging it's password the challenge indeed.Consider automating the password change for serviceaccounts. This might enable you to work around the password policy limitations like password expiry


    MCP/MCSA/MCTS/MCITP
    Tuesday, December 13, 2011 9:52 PM
  • You have probably tried this, but here is a thought...

    Assuming ComputerA and ComputerB are members of the same Active Directory domain, then try not granting ComputerA any share permissions or NTFS permissions directly, but do it through inheritance via group membership:

    -As a domain admin, create a Global Security Group in AD

    -Grant that group all necessary share permissions to the remote share on ComputerB

    -Grant that group all necessary NTFS permissions to the underlying folder (and subfolders and files) of that remote share on ComputerB

    -Add the computer object in AD (computer account) which represents ComputerA to that group you just created above

    -On ComputerB, open Windows Explorer and browse to \\ComputerB (effectively browsing via SMB/CIFS to itself), then look at the security of the "Share" share and calculate the effective permissions (share + NTFS combined) for the "DOMAIN\ComputerA" account

    Just a thought... because if I remember correctly, in a domain environment all services which run under the LocalSystem account on a particular system actually run as the computer account of that host system.

    Let us know...

     

    TamGiao "Tom" Nguyen

    Tuesday, December 13, 2011 10:21 PM
  • Just a brief update. All attempts to find a working solution to this have failed. This strategy was ultimately abandoned because of this.

    Wednesday, December 19, 2012 7:53 PM
  • I know that you have abandoned this however what you are asking for is nothing complicated and must be done daily by many system admins.

    If you still require help with this then could you supply me with the following and I have a number of methods which will allow you to complete this bit of work.

    The Local Directory (Computer 1) What OS is that running I guess from the forum windows XP but just wanted to check.

    (Computer 2)  what OS is this running?

    Is (Computer 1) able to UNC from the run box onto the share? It should prompt for a username & Password if you get this far enter domain\username and password of an account on your DOMAIN. Does this give you access? I know that this is not an account that the computer will use to access the share but I want to check the share is setup correctly and that a DOMAIN account can gain access.


    8B17

    Wednesday, December 19, 2012 8:15 PM