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...

amyassin
  • 337
  • 2
  • 7
  • 22
  • 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 '15 at 14:54
  • I agree.. just wanted to exhaust all options until I can ship the damn thing back... – amyassin Jun 14 '15 at 14:56
  • 2
    Don't disable local admin account for reasons such as this. If this was done for security reasons consider https://www.microsoft.com/en-us/download/details.aspx?id=46899 – user2320464 Jun 14 '15 at 21:22
  • 1
    In a [similar question](http://serverfault.com/q/682756) 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 '15 at 21:52
  • Uhm, for the simplest solution - send them a PowerShell script that changes IP configuration? Even if they are not into IT, I believe they can be instructed to doubleclick a file... Also, depends on your security settings as it may require elevated priviledges – AlexPawlak Jun 15 '15 at 06:52
  • @Koliat they user that can login has no elevated privileges unfortunately... – amyassin Jun 15 '15 at 07:27
  • The machine was deployed by an admin account I assume - if the machine is offline, there is a chance they might use cached credentials for this account. If the users are not much into IT you could try to encrypt logon / password with SecureString with set key, and delegate the script to run as your admin user – AlexPawlak Jun 15 '15 at 08:45
  • the admin user is -strangely enough- not cached.. interrogated the admin and got his password and previous passwords, but all returned a password error.. – amyassin Jun 15 '15 at 08:50
  • network config resides in the registry. boot to msft dart and modify the registry keys – user2320464 Jun 16 '15 at 01:16
  • @user2320464 what keys? any clue?? – amyassin Jun 16 '15 at 07:27
  • 1
    TCP/IP Configuration Parameters - https://technet.microsoft.com/en-us/library/cc739819(v=ws.10).aspx – user2320464 Jun 16 '15 at 07:32

4 Answers4

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.

Hagen von Eitzen
  • 816
  • 3
  • 15
  • 41
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).
Joseph Kern
  • 9,809
  • 3
  • 31
  • 55
  • Unfortunately, sending objects is off the table right now.. – amyassin Jun 14 '15 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 '15 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 '15 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 '15 at 05: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.

cxw
  • 176
  • 1
  • 2
  • 9
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.

Jon
  • 339
  • 2
  • 10