Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm currently working with two Windows 2008 servers, each running on completely separate domains with no possibility of setting up a trust relationship between them.

What I need to find a way of doing is having a service on "Domain Controller A" able to write onto a fileshare on "Domain B".

I am able to map a drive from Domain Controller A to "Domain B" (\\Folder) using an account from Domain B, (Domain_B\Account). However, I'm unable to run the service on Domain Controller A under this account as Domain_B\Account is unable to be authenticated by it.

Is there a way of doing this apart from setting permissions of "\\Folder" to allow read/write for the EVERYONE account, which I'm reluctant to do for the obvious security reasons?

share|improve this question
You'll need to reprogram the service to use impersonation, or just specific credentials, when dealing with the Domain B server. That way it can run as one user, but communicate with Domain B as another. – Ƭᴇcʜιᴇ007 Feb 11 '14 at 14:23
I am assuming by reprogram the service your talking at a coding level and not something that can be done by a sys admin? As for the comment about specific credentials, is would this also be the same or are you refering to a different method? Esentially I have no way of accessing/modifying the way the service works, only the account the service runs under via services.msc – Silthias Feb 11 '14 at 15:43
Yes, unfortunately I meant you'll have to reprogram the service. If you can't, then you're fighting against Windows' security to try and do it any other way, which is aiming to prevent this kind of untrusted, cross-domain communication. Even adding the "Everyone" group probably won't be enough, as the "Everyone" group only covers "Everyone" in the domain (or in trusted domains). One domain won't trust credentials for the other, unless you provide them manually when needed (by reprogramming) or introduce a domain trust, which you say you can't do. – Ƭᴇcʜιᴇ007 Feb 11 '14 at 15:49
But who knows, maybe someone has a usable solution. :) I'm just warning you that you may be out of luck (from my experience). – Ƭᴇcʜιᴇ007 Feb 11 '14 at 15:50
Damn, I thought that might be the case. I guess but was hoping against hope that there was a way. Thank You. – Silthias Feb 11 '14 at 15:55

One solution:

(Note this will not work on a domain controller as they do not differentiate between AD and Local logins on a domain controller)

  1. Create a local user on Computer A ie ComputerA\SharedServiceUser
  2. Create a local user on Computer B with exactly the same username and password ie ComputerB\SharedServiceUser
  3. Set permissions on the share on Computer B for the local user created on ComputerB
  4. Set the service on ComputerA to run as the local user on ComputerA

This works because windows password hashes don't salt. So when the service on ComputerA passes its identity across the network as .\SharedServiceUser with Hash as password it matches the local user identity on ComputerB .\SharedServiceUser

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.