I'm writing to follow-up if the original poster had scucess with this? We are in the exact same situation and I'm hoping for some feedback.
we have zero on-prem AD. As you can imagine this creates a huge headache because we are basically individually managing endpoints, and users have to have local accounts on their desktops (or a bunch of desktops if they use more than one computer...shared accounts sometimes for shared computers) and then those usernames/passwords have to match the local accounts we use for permissions on the file share servers we run. It worked when we were small (before my time) and now it's unmanageable.
On top of that, we have Office365 which we've been leveraging for email/word/excel, etc., so that's another username/password to manage.
Azure AD is what sits on the back of Office365. When you create a user in Office365, their account is setup in Azure AD.
We also recently stood up Azure AD Domain Services, which is setup as part of the infrastructure of some Apps we have running in Azure that required AD.
Consequently, the VMs which those apps are running on are joined to the Azure AD Domain Services domain. The Azure AD Domain Services is 1-way synched with Azure AD.
This all basically just allows our users to use their Office365 credentials to connect/authenticate to the VMs and apps we have hosted in Azure. That part works nice.
So since we have Azure AD Domain Services running, and it's synched to our AzureAD/Office365 credentials, then my thought was why not simplify our on-prem life and make use of this?
We can connect our on-prem devices to Azure AD Domain Services by extending the Azure AD Domain Services over site-to-site VPN to Azure we have setup.
The big win is our users will then get down to a single username/password that will work across all domain devices as well as when they access office365 or the Azure hosted appswe have.
For new users we only need to create the username/password in Office365/AzureAD, which will then synch over to Azure AD Domain Services. (Existing users we had to force a password change to get that synch to fire) If our users need to move between shared PCs they can do that easily because it's a domain and your acocunt works on any domain PC. And we can use Azure AD Domain Services for other ldap type queries we may need on-prem for some legacy apps that we've always had to create separate accounts for..e.g. sslVPN).
I've already tested this and its working fine. The reason I wanted to add an on-prem DC to the mix was just in case our internet goes down we'd be dead in the water in terms of accessing anything on-prem that required AD (e.g if we built our on-prem fileserver around AD users and groups).