Is it possible to pass the UNC username and password within a UNC path?
Similar to how FTP and SMB support this:
smb://user:pass@destination.com/share
ftp://user:pass@destination.com/share
I am trying to get a (non domain PC) service access to a DFS path.
Is there another way around this? I could bind the PC to the domain and run the service as a domain user but what if I was using Linux?
On Windows, you cannot put credentials in UNC paths. You must provide them using net use, runas /netonly, or when asked by Windows.
You can also store the password as a "domain credential" using cmdkey /add:, or using the CredWrite() function in C, both of which are equivalent to checking the "Remember password" box in Windows.
On Linux, it depends on the program.
GNOME's Gvfs accepts the user@host syntax, but appears to completely ignore the password. (However, you can store it in GNOME Keyring beforehand.)
smbclient uses the same UNC syntax as Windows; however, it has an --authentication-file option from which credentials could be read.
Both programs above are using libsmbclient, and can use Kerberos authentication instead of passwords: run kinit user@YOUR.DOMAIN and use smbclient -k //host/share. This is more secure than password authentication.
Note that putting passwords into URIs is deprecated, and you should not rely on it being supported anywhere.
You can map a "drive" to the UNC path using net use. Future accesses should share the existing connection
Net Use \\yourUNC\path /user:uname password
Note: you do not need to specify a drive letter
I think the user name and password has to be passed to the server for authentication first before any file access can be done, so the code handling the SMB connection has to be able to parse and extra the user name and password from the URL. You'll have to check if that code supports this format or not.
If it doesn't, you can mount that SMB share through SAMBA and direct your program to use that "local" path. You can put the mount into fstab and use a SAMBA password file to supply the user credentials. Remember to set the correct permissions to the password file so normal users can't read it.
Note that it is bad practice to store passwords in clear text in configuration files, so even if your program can handle password in URL, you should consider the mounted share method.
You can add the credentials in Control Panel/Users/Windows Credential Manager so that the credentials are cached. You would add the device name (server.domain.local) with the domain username/password, then you should be able to access the share without providing the credentials again.
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.
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.