Test authentication against Azure AD Server

? So just to clarify, you setup servers within Azure (as VM's) and then promoted them to be DC's ? That's what it sounds like your saying.

you just need to be careful with your terminology - as Azure AD (or AAD as its commonly abbreviated to) is a completely different product/technology to full/traditional domain controllers (no matter where they running)

Thanks Hayes for the quick response.
Yes we have set up new Azure AD servers but they are running as a tertiary AD/DNS server.  Not promoted yet until we migrate all users.  Wanted a way to test it with it as tertiary AD/DNS server if that is possible.  Thanks!

ok, so - there is no such thing a secondary or tertiary domain controller...  all DC's are equal (and yes, technical people will state correctly that there are 5 FSMO roles which are unique in the forest/domain - but these are for specific purposes - and not relevant here). Which DC is used by users (or services etc) is determined by AD sites and services configuration. In order to be DC's - they must have been promoted to be DC's - that's how servers become DC's.

There is such a thing as secondary and tertiary DNS - as the order you specify them in DCHP or manually is the order they are utilised in - so the terminology is correct for that.

sorry to be pedantic - but these distinctions are important.

There's 2 things to test here
1) Authentication occuring on your new DC's
2) Network connectivity from on prem to your new DC's

Additionally, you will want to check if anything else is using your existing DC's with hard-coded names or IP's - for LDAP lookups or the like.

There's a couple of ways you can go about this:
1) Ensure you have an AD site correctly configured for your Azure IP range
2) Look for event ID 4624 in the security logs of the new DC's - this will show you logons that are occurring against that DC
3) Logon to a server or workstation you have within azure - if the AD site is configured correctly, you would expect that logon to utilise one of your azure-based DC's. This can be verified by checking for the event log entries on the DC's or by looking at the logonServer variable on the workstation/server you logged on from (or both)
4) Outside of hours, shutdown your on-prem DC's (temporarily) and update DNS on a test workstation - This assumes you are not a 24x7 operation. If you are not, this can act as a very quick test to verify and give confidence that the environment will work once the on-prem DC's are shutdown for good
5) if you think you may have LDAP and other services performing lookups to your existing DC's - this can be identified by turing up logging as specified here - https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/configure-ad-and-lds-event-logging

Thanks for the quick reponse again Hayes.

Yes clients are using DHCP and we will change the DNS order to point to Azure DNS first for the pilot site.  Unfortunately, they have 5 sites and are 24x7 and was trying to avoid shutting the on-prem to avoid any issues on-prem and also unfortunately, Azure is a new environment and the only Virtual Machines now on Azure is the two new Azure AD/DNS servers so there is not a new VM to test authentication. Even then, I still don't think that would be a valid test for on-prem users to authenticate against the Azure new AD servers.  All connectivity is there via site to site VPCs and we tested all replication already and that is working fine.

If there is no other way to test, we may have to shutdown the on-prem after hours (which we plan to test anyway withe first site - which has less amount of users).

thanks!

Awesome, will try the options you mentioned Hayes. thanks a lot!