0
votes

I have setup domain services in Azure using the domain name "cloud.mydomain.com". Microsoft documentation specifically says to avoid creating DNS names with the ".local" suffix due to routing issue so I didn't do that.

When setting up an on-premise domain sync using AD Sync tool, the on-premise active directory UPN suffix "mydomain.local" does not match the "cloud.mydomain.com" custom domain name in Azure.

When this happens, documentation indicates that the UPN suffix of the users of this domain will be changed to the default .onmicrosoft.com suffix. Is it critical that they match in order to get integrated security to azure resources such as SQL servers using their on-premise domain account?

If they do have to match, then I'd have to create a custom domain name called "mydomain.local". Since that only exists in the on-premise domain, how would that ever be verified?

1

1 Answers

0
votes

Is it critical that they match in order to get integrated security to azure resources such as SQL servers using their on-premise domain account?

Of course, the Azure AD is very critical for the security. And the default .onmicrosoft.com suffix is due to you create the domain is under Microsoft in the Azure portal.

Since that only exists in the on-premise domain, how would that ever be verified?

You cannot directly use your local domain to verify with Azure AD, due to your local domain .local is a private domain. You need to register a domain in public, and then you could verify it with Azure AD. After verified success, you should add this domain into your local DNS, then when you syncing, the .local could be matched with Azure AD.