The credentials storage answer by Matt is the most elegant for a modern Windows PC. Although not stated the credentials storage used should be for the service account. That is both to ensure availability to the service and so that any other users you do not want accessing that share cannot (e.g. more of a remember to clean up credentials mistaken added under wrong account).
But if its legacy Windows or Linux you might need to go slightly wider.
A non-domain PC should not really care about DFS to which it does not subscribe or directly participate. It just needs to see a share path (i.e. server/sharename). Sharenames remove all the host file server path considerations.
Honestly there are more secure ways to logon to shares than UNC URI.
UNC and URI are themselves a clear text communication protocol.
If that is acceptable security...why not just have an open share without any user or password?
The simplest immediate solution would be giving the service credentials direct access to logon to the share (e.g. matching user/password). Long term that not so obvious match might make remembering to update permissions whenever things changed difficult. And its also an area where MS might change how security passes credentials yet again and break things.
Long term the best simple thing is probably to permanently map a local drive letter to the network share. Protect the mapped drive with permissions only for service (and appropriate admins etc) plus sharename might be hidden with leading &.
But DFS gives a clue to a more elegant solution. Linux requires network shares to be mounted first ...usually as a directory in the root file system in manner very much like DFS. The Linux mount command allows specifying a credentials file for username and password thus making them easier to update and more secure than command line script or fstab (i.e. file system table). I am pretty sure Windows command shells and DFS can do the same thing (been a while). It would just be a different DFS system private to the target PC to incorporate mounted network shares using stored credentials passed by SMB and logon services rather than hard coded in script and sent as clear text UNC.
Also consider if that nondomain PC will remain a non-domain PC long term.
Kerberos logon servers in *NIX Realms can be linked to Windows AD Domains. Probably what you want to do for any serious long term project involving more than a few people. On the other hand its probably overkill for most home network situations. Though if you are using DFS for any good reason other than hobbyist self-challenge its probably best.
Do you have a reference in regard to "putting passwords into URIs is deprecated"? – Alexis Wilke – 2013-03-11T04:23:06.343
2
@AlexisWilke RFC 1738 § 3.3 started by not allowing them in HTTP, RFC 2396 § 3.2.2 had a more general "not recommended", and RFC 3986 § 3.2.1 says "Use of the format "user:password" in the userinfo field is deprecated".
– user1686 – 2013-03-11T11:05:11.807