AzureAD is just a directory. The Auth flow can occur in a few different ways (Microsoft supplied versions).
- AzureAD native cloud accounts and password. Authentication and
authorization all happen in AzureAD.
- AzureAD with AzureAD connect to sync accounts and/or password
hashes. This syncs domain accounts. AzureAD Connect is a custom
version of Microsoft Identity Manager configured to work directly
with domain accounts. Authentication and authorization still happen
- AzureAD with AzureAD Connect and Passthrough Authentication. This
is where thing switch up - Authentication happesn at the domain
controller. AzureAD trusts the domain controller and then authorizes
access to resources
- AzureAD with ADFS (or 3rd party SAML IdP) - works like above, authentication is moved to AD via ADFS as the proxy.
Authentication is also configured on a domain basis in AzureAD. That is the individual domains are configured for a certain auth scheme and not individual user accounts.
For a Dev setup if you have a small domain you could sync that and keep accounts together.
Without a domain controller you can use cloud accounts and simple scripts to recreate accounts and passwords. for instance run a PowerShell script that creates the local account representation in AzureAD, and also takes in the password and sets it for the local account and the cloud account. They are still separate and not linked entities, but gets you a similar result. Now if the domain you want to use is already configured for non-cloud authentication (Passthrough, federated), you can not create a cloud only account with that domain.
To do any of this on the account level, you need rights inside of AzureAD directory. The contributor rights allows you to deploy assets in subscription, but does not infer any rights at the directory level. And remember some changes affect an entire verified domain, so it can impact all users whose login ID's are tied to those domains.