I shall assume your problem box has these settings:
- IP = 192.168.10.36, default gateway = 192.168.10.1, DNS = 192.168.10.2 (otherwise adjust the numbers accordingly below).
Now proceed as follows, using two boxes TEMPAD (with ip 192.168.11.100, say) and TEMPDNS (with 192.168.11.200, say):
- RDP to TEMPAD and install the AD role on TEMPAD
- On TEMPAD set a static route to host(!) 192.168.10.36 via 192.168.11.200
- From within your RDP session on TEMPAD, start an RDP session to TEMPAD and install DNS on TEMPDNS. It should serve your AD zone; I'm not sure if it should rather serve a crippled AD zone with all references to the 192.168.10.* AD servers removed, see hints below.
- Add secondary IPs 192.168.10.1/24 and 192.168.10.2/24 on TEMPDNS and enable IP forwarding.
- Ask a person at the 192.168.11.* site to turn on the problem computer
- When the boot has completed, start an RDP session to 192.168.10.36 from within your RDP session to TEMPAD. You can now login as whoever you want.
Note: The fourth step disrupts connectivity from TEMPDNS to your 192.168.10.* LAN, but your remote session is stillworking because it is actually originating from TEMPAD in the 192.168.11.* LAN
In step 6 the following magic happens (I hope): The machine asks its configured DNS server 192.168.10.2 (i.e., TEMPDNS) for the address of an AD server. It gets as a reply your original AD servers in 192.168.10.* and 192.168.11.200 (i.e., TEMPAD). Connection attempts to the 192.168.10.* AD servers fail, so ultimately 192.168.11.200 is tried (as I said, it may be better to avoid the attempts to connect 192.168.10.* by crippling the DNS on TEMPDNS). The connection to 192.168.11.200 succeeds: We have a working forward route 192.168.10.36 -> 192.168.10.1=TEMPDNS -> TEMPAD and backward rout TEMPAD -> 192.168.10.200=TEMPAD -> 192.168.10.36.
Once all repairs have completed, donÄt forget to undo all the crap above.
There must be a local administration account, otherwise joining the domain wouldn't have been possible. – Daniel B – 2015-06-14T12:29:46.153
@DanielB OP says the local admin account is disabled, presumably after the computer was joined to the domain. – a CVn – 2015-06-14T12:31:09.483
1yes, it was disabled afterwards... – amyassin – 2015-06-14T12:32:51.003
Ah, missed that. If an account exists, the usual hacking tools can easily enable it and reset its password. – Daniel B – 2015-06-14T12:33:17.010
Is it still disabled even in Safe Mode? – user1686 – 2015-06-14T13:41:21.697
2To attack this from the other side, can't you set up some form of gateway to temporarily make the IP configuration of your target machine valid? – Matthew Steeples – 2015-06-14T16:01:48.170
that would mess up routing for other machines, since the address of the messed up machine is in the range of the remote machines I am accessing it from.. If I changed the gateway, I am locked out... – amyassin – 2015-06-14T16:22:36.580
1Try plugging in a USB network adapter (this requires action by a local user, but it shouldn't require IT staff), by default it will have DHCP enabled, you should then have enough network connectivity to login with domain credentials. – Ben Voigt – 2015-06-14T17:21:57.183
The domain is in a local network and cannot be accessed from outer internet... We have a vpn but requires installation of a client, meaning back again to admin rights... – amyassin – 2015-06-14T18:43:00.547