Running a Windows service under a domain account from a non-member server

Question

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?

Solution

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.

Comments

[Peter Schuetze]

Did you try the full qualified name for the domain (addomainname.something.com)? It will proably don't make a difference, but it is wort a try. The other hint I have is, run your SQL server or SQL server agent under a user account instead of the local system account. This sometimes makes a difference.

[Matthew]

Hi Peter I did. I should have clarified that by user@addomainname I meant user@fullyQualifiedADdomainname.

[Matthew]

Hi Catherine yes. From my question: "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."

[Catherine MacInnes]

I couldn't tell from your questions whether that was users in general or specifically users on this server.

[Spence]

+1 - A Windows machine can't create security tokens for security principals that aren't either (a) local, or (b) in a domain trusted by the machine's local security authority (LSA). When you "join" a domain you're creating a trust relationship between the member machine's LSA and the domain (by way of a shared secret). W/o this relationship the member machine's LSA can't create security tokens referencing remote accounts. The "drive mapping" trick works for accessing remote files because the token is being created on the remote machine-- you're just providing a password to the remote machine.

[Matthew]

@Evan - excellently stated!