No announcement yet.

AD doesn't like servers on secondary IP's

  • Filter
  • Time
  • Show
Clear All
new posts

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

    we are changing (correcting) IP address range in our AD domain. We currently have all Servers and PC's in the range,2552552550 (yes I know!!) so I'm moving everything to a new address range of 2552552480 (ie (all internal of course)
    I have added say as a secondary IP address on AD server(2003sp2) (so it still has as the primary IP for the sake of all the other clients for now!) and my PC is I can ping fine, and server can ping 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, and DNS to, allows me to join no probs, DNS and PC as secondary IP - no go.
    seems that AD will only allow a PC to join if on the network and only if it's a primary address. intend dropping off all together once everyone is over..
    Don't want to change the AD server to 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..

  • #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 ?


    • #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 and if there aren't any DNS SRV records for the DC for ip address 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.