1

I have a Windows Active Directory network in a LAN of addresses 192.168.10.0/24. I have another site that has addresses of 192.168.11.0/24, where all AD servers are in the 192.168.10.0/24 site (I know, bad!). Both gateways use Fortigate firewalls and are linked through a Fortinet IPsec tunnel so machines on both sides can access each other.

Accidentally a machine was configured with a static IP of 192.168.10.36 and was sent to the other side, where no IT department staff is available onsite. Now we cannot access the machine due to the wrong addressing, and the following solutions aren't working:

  • Login as a local administrator, because it is disabled.
  • Login as an AD administrator, because the machine cannot access the AD server.
  • Change the routing table, because if we changed the address of the other side's firewall to 192.168.10.X, we will be knocked out.

What other options do we have? I am looking for:

  • A way to change the IP address. There's a cached domain user that is able to login, but it is no admin. Or,
  • A way to restore connectivity so we can login and change the IP address, or
  • Any other solution that restores access to the machine.

EDIT: Just to clarify: for some reasons, shipping something to the other site is not possible right now...

Improve this question
11
  • No amount of jiggering is going to fix this without breaking the connection between the two sites. You're going to have to have the machine shipped back to your site in order to fix it, there's no way around that. If nothing else, make sure to change your process to include logging onto each machine as the Domain Administrator in order to cache those credentials on each machine before they're shipped out.
    – joeqwerty
    Jun 14, 2015 at 14:54
  • I agree.. just wanted to exhaust all options until I can ship the damn thing back...
    – amyassin
    Jun 14, 2015 at 14:56
  • 2
    Don't disable local admin account for reasons such as this. If this was done for security reasons consider microsoft.com/en-us/download/details.aspx?id=46899
    – user2320464
    Jun 14, 2015 at 21:22
  • 1
    In a similar question the solution was to access the machine using an IPv6 link-local address. I don't know if that method works with Windows, the other question doesn't mention which OS was being used on the misconfigured machine.
    – kasperd
    Jun 14, 2015 at 21:52
  • 1
    TCP/IP Configuration Parameters - technet.microsoft.com/en-us/library/cc739819(v=ws.10).aspx
    – user2320464
    Jun 16, 2015 at 7:32

4 Answers 4

Reset to default
3

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):

  1. RDP to TEMPAD and install the AD role on TEMPAD
  2. On TEMPAD set a static route to host(!) 192.168.10.36 via 192.168.11.200
  3. 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.
  4. Add secondary IPs 192.168.10.1/24 and 192.168.10.2/24 on TEMPDNS and enable IP forwarding.
  5. Ask a person at the 192.168.11.* site to turn on the problem computer
  6. 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.

Improve this answer
1

Hmmm ... list ordered from least user interaction to most user interaction:

  1. Segment the system onto their own VLAN, route that VLAN back to the known good LAN segment (make sure there are no overlaps in IP space!). Login, fix the mistakes, reset the switchport to the local VLAN, try to access again.
  2. Prepare a boot CD that grants remote desktop access and ntpasswd, mail it to the remote office and have a user boot it up and use a good ip address for the location. (might run into issues here, you'll have to walk the user through configuration steps)
  3. Get another similar hard drive and laptop, reimage, correct your mistakes, Fedex, have the users swap the drives. (User will need to be able to swap drives and boot the computer).
Improve this answer
4
  • Unfortunately, sending objects is off the table right now..
    – amyassin
    Jun 14, 2015 at 10:40
  • Yep try to manipulate the VLAN on the client switchport, and then the routing table (tricky! be careful). If I think of anything else I will update the question.
    – Joseph Kern
    Jun 14, 2015 at 10:51
  • the problem is that .10 is our other site, If I routed traffic anywhere other than the tunnel, it will not reach the tunnel and we'll be cut!
    – amyassin
    Jun 14, 2015 at 11:57
  • Have you considered creating a routing rule that only includes the 10.36 address? Like a /30? This is pretty workable in general, I am not sure about the specifics of your routing rules though. Other than that, I would really recommend shipping something (even though you say you can't).
    – Joseph Kern
    Jun 15, 2015 at 5:00
0

Could you ship them a multihomed box configured as the default router or domain controller for 192.168.10 and as a regular machine on 192.168.11? Maybe then you could connect to the .11 side and proxy through to .10. (Not at all an AD expert- just thinking of the general case.). The .10 and the new box could be connected with a crossover if necessary.

Improve this answer
3
  • unfortunately, shipping right now is off the table :(
    – amyassin
    Jun 14, 2015 at 10:38
  • Can you remote in to one of the. 11s and set it to temporarily route traffic?
    – cxw
    Jun 14, 2015 at 11:27
  • how to route it? If I changed the IP to .10 I cannot see the other site...
    – amyassin
    Jun 14, 2015 at 11:54
0

Did you try safe mode and the following command: "net user administrator /active:yes". I once disabled the local admin account and only had non-admin local accounts on the pc. I did that cmd and got it enabled. Also you can always hire an IT services company to send out a local tech to help you guys out.

Improve this answer

You must log in to answer this question.

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