Announcement

Collapse
No announcement yet.

AD doesn't like servers on secondary IP's

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • AD doesn't like servers on secondary IP's

    Hi,
    we are changing (correcting) IP address range in our AD domain. We currently have all Servers and PC's in the range 142.1.10.xxx,2552552550 (yes I know!!) so I'm moving everything to a new address range of 10.0.0.xxx 2552552480 (ie 10.0.0-7.xxx) (all internal of course)
    I have added say 10.0.0.7 as a secondary IP address on AD server(2003sp2) (so it still has 142.1.10.7 as the primary IP for the sake of all the other clients for now!) and my PC is 10.0.0.1(XPprosp3)..... I can ping 10.0.0.7 fine, and server can ping 10.0.0.1 fine.. but can't join the domain (a domain controller for the domain ABC could not be contacted) I have reverse entries in the AD's DNS for each range eg:10.0.0, 10.0.1, 10.0.2 and so on.
    What else needs to be done before AD will accept my PC to it's domain?
    IF I change my pc to 142.1.10.1, and DNS to 142.1.10.7, allows me to join no probs, DNS 142.1.10.7 and PC 142.1.10.1 as secondary IP - no go.
    seems that AD will only allow a PC to join if on the 142.1.10.xxx network and only if it's a primary address. intend dropping 142.1.10.xxx off all together once everyone is over..
    Don't want to change the AD server to 10.0.0.7 as the primary address just yet for fear of breaking usage? if I do this for testing overnight? can I change it back without AD issues following it?
    any perls of wisdom would help..
    thanks
    AJ

  • #2
    Re: AD doesn't like servers on secondary IP's

    Have you configured the new subnet in site and services and associated with the site already ?

    Comment


    • #3
      Re: AD doesn't like servers on secondary IP's

      Take a look at which ip address the DNS service is listening on. Also look at which ip address is registered in DNS for the DC. If the DNS server isn't listening on 10.0.0.7 and if there aren't any DNS SRV records for the DC for ip address 10.0.0.7 then I suspect that's what's causing the problem.

      Also, I'll post my response to another post here regarding ip addressing to give you my thoughts and opinion on this subject. Here it is:

      Using publicly routable addresses internally is neither right or wrong. In today's IT world it's currently considered "best practice" to use an ip addressing scheme that uses addresses from one of the three private ranges but before RFC1918 everyone used publicly routable addresses internally. Anyone that tells you that using private addresses internally because they're more secure is mistaken regarding the intended use of the private address ranges. The implementation of RFC1918 addresses was intended to stave off the depletion of the IPv4 address space and any incremental security benefit was an unintended side effect.

      The network I inherited 4 years ago also used publicly routable addresses and I've kept it that way. It's no more at risk than any other network. I don't allow inbound address or port space probes, I apply all applicable patches to my hosts, I monitor internet ingress and egress, I monitor my firewall, web server, ftp server, email server logs, etc. The task of readdressing my network (3 subnets) and dealing with the issues related to AD, DHCP, DNS, routing, management, NAT, etc., etc. hardly seems like an exercise I want to go through when I've got a perfectly functioning network right now. I'm not going to readdress my network just to conform to a standard that some feel is "best practice". If your current address space is sufficient for future growth and you're not experiencing any legitimate technical problems because of it my recommendation is this: if it's not broke don't fix it.

      Now that's not to say that if I was building a network from scratch that I wouldn't use RFC1918 addresses, because I would.

      Comment

      Working...
      X