What should the SRV record _ldap._tcp.dc._msdcs.domainname.com point to in Azure AD?

2

I administer Office 365 for our company widgetsRus.com, and I am trying to join my desktop computer to the domain and log in using my Office 365 email address. I bought the domain and the Office 365 subscription from GoDaddy, and the name servers are currently at he.net. I administer the DNS server for that domain, so I can add or change records. I am certainly willing to relocate the name servers or create a domain controller at Azure if necessary.

I can see our domain, users, and devices at portal.azure.com.

When I try to join the domain using Control Panel, I get an error message:

The following error occurred when DNS was queried for the service location (SRV) resource record used to locate an Active Directory Domain Controller (AD DC) for domain "netorgft3xxxxxxx.onmicrosoft.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.netorgft3xxxxxx.onmicrosoft.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:

208.67.222.222 208.67.220.220

I am able to join the computer to the Azure AD using Access from Work or School, however, I am unable log on using my email address after that.

I gather that I need to add some more records to the zone file, starting with the SRV record mentioned. How can I find out what that should be?

microsoft-office-365
dns-zone
azure-active-directory
asked on Server Fault Jun 9, 2018 by zkilnbqi • edited Jun 10, 2018 by zkilnbqi

1 Answer

1

This is a confusing topic for those first exposed to AzureAD.

AzureAD by itself will not replace a domain controller. You can not Join your domain with AzureAD unless you also enable Domain Services (additional paid service). I've probably oversimplified the differences below but hope it helps.

AzureAD does allow you to register or enroll a device in the service.

Workplace Join - this is for machines that are already configured and is device registration. It can improve the user experience as the authentication in Windows 10 is built to work directly with AzureAD. For MDM you to manually enroll a device.

AzureAD Join - Microsoft calls this Device enrollment. With Windows 10 - when you have the "out of the box" OOTB experience you get to choose to join AzureAD or a domain. When you choose the former, you tie your sign-in credentials to AzureAD and enroll into any Intune policies that may be in place. It's a great way to manage device (assuming you have Intue as well) for devices that are not on the network frequently. This is enrollment - b/c it's possible to enroll a device into MDM at the of device registration as well (it's all done together).

Back to Domain Services. You can enable Domain Services in an AzureAD directory - but it's another paid service. In addition, you have to create an Azure virtual network to bind it too and then you would need a VPN to connect it to the local network (assuming you want to join more than just Azure VM's). With this setup - you can indeed join machines, and manage them with GPO's. If you have traditional domain controllers - this service is not part of the domain replication, it's a separate service that works like a "domain". There are still plenty of things that are not ideal for domain services but the basics are there. For Azure deployments, the costs will be similar to deploying a small DC your self as a VM - but then again you won't have to manage the OS or domain replication, which is ideal if no Active Directory domain yet exist.

answered on Server Fault Jun 10, 2018 by Jesus Shelby

User contributions licensed under CC BY-SA 3.0