Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We have multiple servers scattered over different hosting providers. For learning, experimenting and, ultimately, production purposes, I set one of them as a Domain Controller.

That went well, most of our services are now authenticating via AD, which helps us a lot.

What I want to do now is to simplify the authentication for the multiple servers, by making each of them look at the Domain Controller. This way, our Devs can log into (Remote Desktop) the multiple servers with the same credentials from AD.

I know I have to configure each server to look at the Domain Controller.

But when I try to add the Domain Controller to the Computer, it cannot find it, although the Domain Controller address is a valid, reachable internet sub-domain (as in "ad.ourcompany.com").

enter image description here

This is the detailed error message:

Note: This information is intended for a network administrator. If you are not your network's administrator, notify the administrator that you received this information, which has been recorded in the file C:\Windows\debug\dcdiag.txt.

The following error occurred when DNS was queried for the service location (SRV) resource record used to locate an Active Directory Domain Controller for domain ad.ourcompany.com:

The error was: "DNS name does not exist." (error code 0x0000232B RCODE_NAME_ERROR)

The query was for the SRV record for _ldap._tcp.dc._msdcs.ad.ourcompany.com

Common causes of this error include the following:

  • The DNS SRV records required to locate a AD DC for the domain are not registered in DNS. These records are registered with a DNS server automatically when a AD DC is added to a domain. They are updated by the AD DC at set intervals. This computer is configured to use DNS servers with the following IP addresses:

    109.188.207.9

    109.188.207.10

  • One or more of the following zones do not include delegation to its child zone:

    ad.ourcompany.com

    ourcompany.com com

    . (the root zone)

For information about correcting this problem, click Help.

What am I missing?

I'm an experienced Dev, but a newbie Sysdamin experimenting with new stuff.

Disclaimer

All IP addresses and domains/subdomains were changed to preserve security. If by any chance you still can see private information, please let me know so that I can change it.

share|improve this question

3 Answers 3

The clue is in the error message, the servers that you plan to join to the domain need to use the DNS servers that hold your AD DNS zone as their DNS servers. It looks like they're using some public DNS servers, which I'm guessing are not the DNS servers holding your AD DNS zone.

share|improve this answer
    
Exactly. But, let's add, the most common way to do this is to point the DNS settings for member servers at the DNS services running on the Domain Controller(s). –  Mark Aug 29 '12 at 18:09
    
In most scenarios (and probably this one) the DC is also the DNS server, but it's not a given and shouldn't be assumed. –  joeqwerty Aug 29 '12 at 18:12
    
I already tried that. It just appends the newly added DNS IP address to the error message. And, yes, the DC is also the DNS. It was a out-of-the-box-and-no-further-fiddling installation. Could there be something wrong with the DNS setup? –  Adrian Aug 29 '12 at 18:15
1  
Is there a firewall between the client server and the DC/DNS server? If so, that's the next thing to check. You'll need to have the appropriate ports open between the two in order for a domain join to work. The relevant ports should be: Kerberos (port 88 TCP/UDP), LDAP (port 389 TCP/UDP), SMB (port 445 TCP/UDP), and DNS (port 53 TCP/UDP). I can't think of any other ports but someone else will chime in if I've missed any. –  joeqwerty Aug 29 '12 at 18:37

joeqwerty is spot on.

For the pc to join the domain, it looks up SRV records. If the clients are at the same site as the DC, change DNS on the clients to point to your DC, otherwise follow the details below.

I'm guessing the ad in ad.ourcompany.com is the hostname for your DC? If so, you should try and join the domain without putting the ad. part - specify the domain only.

It sounds like you only have the A record set up for your server. The client pc first looks for _ldap._tcp.dc._msdcs.ourcompany.com which should then point to ad.ourcompany.com. (or yourdc.ad.ourcompany.com)

If you create this SRV record accessible on the public internet, then this should eliminate this error. Also check DNS on your DC for the other relevant SRV records which your AD setup requires.

However for security reasons, my preference would be to set up a local DNS server at the site(s) your client PC's are based at which hold the relevant SRV records so these are not available to all and sundry.

share|improve this answer
    
I tried your first suggestion, did not work, same error message. –  Adrian Aug 29 '12 at 18:18
    
Check your DC is pointing to itself for primary DNS, then open a command prompt and type nslookup then enter, then set q=srv then enter, then type _ldap._tcp.dc_msdcs.ourcompany.com (or _ldap._tcp.dc_msdcs.ad.ourcompany.com as appropriate) and then enter. It should return your DC. –  Robin Gill Aug 29 '12 at 18:21
    
"Check your DC is pointing to itself for primary DNS". Excuse my inexperience, but how can I do this? –  Adrian Aug 29 '12 at 18:30
    
Assuming you are running server 08, on your DC, click Start, Control Panel, Network and Sharing Centre, Local Area Connection (assuming you have one NIC), then properties, Internet Protocol 4 (TCP/IPv4), properties, then check the primary DNS server ip address is that of itself. –  Robin Gill Aug 29 '12 at 18:33
    
Yes, it does point to itself. But the nslookup query does not return as expected –  Adrian Aug 29 '12 at 19:25

For the love of God, don't have Domain Controllers that are accessible over the internet. That's begging for a catastrophe. You need to set up site-to-site VPNs between your sites, and make sure your subnet/subdomain on which AD is located is NOT accessible other the internet through anything but a VPN.

In IPv4, that means your Domain Controllers, (and your whole internal network as well) should have a privately routed address such as 10.x.x.x 192.168.x.x or 172.16-31.x.x, and not start with a publicly routed octet like 109.

DO NOT just go punching holes in your firewalls to make this work, please.

share|improve this answer
    
Dare I ask what kind of catastrophe? Security issues? –  Adrian Aug 30 '12 at 14:47
    
@Adrian That would be opening up your Active Directory to be [potentially] accessible to the whole world... so yeah, security. Anything from information leakage to someone compromising AD and deciding to delete everything for shits and giggles. –  HopelessN00b Aug 30 '12 at 15:16

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.