I've got a standalone Windows Server 2003 running SQL Server 2005 and a Windows Server 2003 Active Directory domain controller. Using maintenance plans/SQL Server Agent, I'm trying to write the database dumps from the standalone box to a share on the DC. I know the usual rules about accessing remote shares (e.g. must use a logon account which has proper rights, etc.). In fact, writing the dumps to another non-DC server in the same domain as the DC works fine.
I'm trying to set the SQL Server Agent account's logon credentials to "domain\username" (or username@addomainname). If I specify a username in the form of "domain\username, the error I get (regardless of password) is:
"The account name is invalid or does not exist, or the password is invalid for the account name specified".
If I specify a username in the form of "user@addomainname", the error I get (regardless of password) is:
"The specified domain either does not exist or could not be contacted."
I've turned on logon failure auditing on the DC and I see no failures in the log, which suggests to me that the machine isn't even trying to authenticate, but rather failing prior to that.
I know that users on non-member servers can authenticate to shares on a DC, because doing an interactive logon (e.g. "net use * \dcname\c$ /user:username@addomainname", or using the other form of the username) works fine.
The above example is about SQL Server but applies to any Windows service.
Why can't the service log on with the domain account, but an interactive logon (drive mapping) using that same account works?
Best Answer
With Rackspace's (hosting this particular configuration) support, I now understand the situation.
The "net use *..." drive mapping example and the service example is an apples to oranges comparison. With the drive mapping case it's just an authentication that's happening. In the service case, I'm actually attempting to run a local process under domain credentials, which by definition isn't possible since the server isn't in the domain. Not in domain = can't execute under domain credentials. The drive mapping works because I'm not attempting to execute a process as the domain account - I'm simply passing the credentials.
This restriction applies to any type of process, regardless of it's interactive or service-based.