Using non-domain local account to connect to a domain
We have domain.local in our datacenter. The DC is Server 2008. We have a Windows 2003 Server, Backup1.domain.local, that is used for network storage. We have created a domain account called "backupuser" for automation purposes. When we set a scheduled task to backup one of the servers in our domain, we set the task to run as domain\backupuser. When we set a scheduled task to backup a client's server, which is not in our domain, we create a local user on that server with the same name and password, and set the task to run as that local user. The scheduled tasks access the network storage server through UNC (i.e., \\backup1\d$\backup_direct
We recently added another network storage server, backup2. It is using Windows 2008 Server. This same system is working fine for any machine in our domain, but the local user strategy is now returning 0xc0000064 (user does not exist) during authentication. We cannot use a domain account to run the task since the local system is not aware of the domain and provides no local access for its accounts. How can we have a local user account still be able to access the network shares via UNC?
We recently added another network storage server, backup2. It is using Windows 2008 Server. This same system is working fine for any machine in our domain, but the local user strategy is now returning 0xc0000064 (user does not exist) during authentication. We cannot use a domain account to run the task since the local system is not aware of the domain and provides no local access for its accounts. How can we have a local user account still be able to access the network shares via UNC?
ASKER
We can't do that because of the security concerns involved with saving a password in a batch file. It does work, though. I tested with NET USE to figure out why I was getting access denied when I first discovered the issue.
In case it matters, the backup task is running a third-party app (snapshot) which accesses the network storage by UNC. The path/filenames it uses are passed on the command line.
In case it matters, the backup task is running a third-party app (snapshot) which accesses the network storage by UNC. The path/filenames it uses are passed on the command line.
I think it is better to have a domain for backup servers and joint those servers to it, and create trust relationship with production domain,
this way authonticated users by backup servers domains are trusted in the production domain
this way authonticated users by backup servers domains are trusted in the production domain
ASKER
>>> I think it is better to have a domain for backup servers
I will raise this possibility. That would resolve a couple of issues we are seeking to address, including this authentication problem.
I will raise this possibility. That would resolve a couple of issues we are seeking to address, including this authentication problem.
ASKER
Using a domain for the backup servers was rejected by management. In the end, we decided to go with individual local accounts on both the network storage server and the client servers not joined to the domain. This presents us with a few additional management issues, but it does get the job done. Servers that are joined to the domain can continue to use the domain account as usual.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
The one suggestion offered worked, but was not acceptable for the task at hand. It only served to verify the problem.
For example write a batch file that will run before the task, on backup2, without actually mapping a drive... just identifying to the domain... it works even if the machine is not attached/aware of the domain...
NET USE \\backup1 /USER:DOMAIN\username password
this will just introduce itself to the server and supply the correct domain credentials. so when you will try to go to a share on it later on it will grant you access.