1

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?

5
  • 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. Feb 11, 2014 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, 2014 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. Feb 11, 2014 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). Feb 11, 2014 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, 2014 at 15:55

1 Answer 1

0

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .