Azure ADDS extension of my onpremises domain

[Sandro Alves]

Hi,

I have an onpremises domain (company.com.br) where all my users used to login.

however now with home office users I want them to authenticate to Azure ADDS using the same credentials as my ADDS onpremises.

I read in the documentation that there is a scenario with a hybrid name that is an extension of my domain using adconnect to synchronize users.

I did the whole procedure, I created the domain in Azure ADDS but when trying to join a computer from my case at (addscompany.com) he says he didn't find the domain controller for that domain.

I saw that there is an option to enable secure LDAP for Internet, do I need to enable this option? It requires a certificate.

What is wrong?

Besides, I was left with the following doubt?

If I am going to register the computer in the domain (addscompany.com) the user profile will be created for that domain. But when the user goes to the office and there he can log into (company.com). If so, does the user continue to log in to (addscompany.com)?

That is, the user will be able to choose which domain to log in to? Or not, will it be fixed in the domain you joined?

What was lacking in the explanation of the Microsoft documentation is the simulation of a scenario so that we can better understand how this process works in practice.

Thanks.

[#2]

The client has to have access to the Azure AD DS domain and Azure AD DS DNS servers to find the domain. You would likely need a VPN solution for the clients as it’s not recommended to expose AD DS, Windows or Azure, to the internet.

You can configure the on-premises Windows AD DS to sync user’s legacy NTLM password hash from Windows AD to Azure AD. The legacy password hash is different from the password hash sync used to sync passwords with AD Connect. This way, the passwords will be the same for the on-premises domain and the Azure AD DS domain.

Based on your description, I sounds like you are looking for behavior similar to a multi-domain forest or trust relationship between a Windows AD Domain and an Azure AD DS domain. Identities can replicate from Windows AD to Azure AD DS (not the other way), but they are two serrate domains. Also, Azure AD DS will not support trust relationships. So a computer added to one domain will not be trusted by the other. Other than sharing user names and passwords, they are two distinct domains.

From my experience, Azure AD DS is really meant for standing up a hosted, isolated AD DS environment to support a cloud service that requires AD DS. Extending it to remote users will have all the complexities of extending on-premises AD DS to remote users with the limitations of Azure AD DS (no trust relationships, only available in one site, can’t extend the schema)

If you are looking to manage remote desktops, Azure AD join and Intune may be a better option.

-Travis

[#3]

@Travis Roberts 

Hi,

I understand what you say, but I have a friend who said that in his company the machines were joined to the domain via the Internet.

I believe that to do this I need to enable secure LDAP for the internet.

He does not use GPO to protect computers, he uses Itune to enforce policies.

Thanks.

[#4]

Hi,

If you study the documentation for AAD DS service, you find out that this service is not designed for "anywhere / any device purpose". Moreover, it is not encouraged to domain join machines that are not running in Azure to this domain (e.g. endpoint devices, VMs running on-prem). The managed domain is a stand-alone domain. It isn't an extension of an on-premises domain.

You should think about AADS as a cloud "equivalent" to your WS ADDC service you are hosting on-prem. You don't expose it to the Internet (it is protected behind a perimeter network), and machines joined to this domain are in the same network (or connected via a VPN, if they are portable).

Keep in mind that you need much more than just LDAP port to be available outside your perimeter. Active Directory and protocols it uses was not designed as "internet-friendly". Even if you could enable 'secure LDAP' and choose to expose it to the Internet, it is not recommended for "all source IPs", but only some specific ranges and use Network Security Groups, difficult to achieve in your scenario).

Your scenario is about remote users (working from home). Their endpoints are currently joined to your on-prem AD, I presume. "Switching" to AAD DS is really not a good idea, among many things it would require you to join all the endpoint devices to AADDS domain (instead of your on-prem AD). In the documentation you will see, this option (joining W10 / client devices) is not even there.

Most of my customers use a different strategy instead:

• use AAD-join or Hybrid AD-join (on-prem AD + AAD)
• use Intune / Endpoint Manager for management (instead of GPOs and System Center)