Azure AD & Entra ID: User Management

Entra ID vs. On-Premises Active Directory

Microsoft Entra ID (the product formerly branded Azure AD) is not "AD in the cloud." It's a fundamentally different system that happens to share some vocabulary. On-prem AD Domain Services is a hierarchical directory built on LDAP and Kerberos, organized into domains, forests, and organizational units, with domain controllers replicating a shared database and Group Policy enforcing configuration on domain-joined machines. Entra ID is a flat, multi-tenant identity store accessed over REST APIs (Microsoft Graph), authenticating principals with OAuth 2.0, OpenID Connect, and SAML rather than Kerberos or NTLM.

Practical consequences of that difference matter for how you plan a deployment. Entra ID has no organizational units and no Group Policy — device and app configuration is instead handled through Intune (Microsoft Endpoint Manager) via Conditional Access and compliance policies, not GPOs. There's no concept of a domain controller you can RDP into; every operation happens through the Entra admin center, Microsoft Graph, or Microsoft Graph PowerShell. Trust relationships that used to be inter-forest trusts become B2B guest invitations or cross-tenant access settings instead.

Entra ID also doesn't replace on-prem AD for workloads that require Kerberos or NTLM authentication — legacy file shares, some LOB apps, and traditional domain join still need AD DS (or Entra Domain Services, a separate managed-domain product) sitting alongside it. Most organizations run hybrid: on-prem AD DS as the authoritative source for employee identities, synced into Entra ID so those same users get single sign-on to Microsoft 365, Conditional Access enforcement, and SaaS app access. Understanding this distinction up front prevents a common mistake: treating Entra ID as a place to recreate an OU structure or push registry-based GPO settings — that's not what it's built for.

User and Group Provisioning: Cloud-Only vs. Synced

Every object in Entra ID falls into one of two provisioning models. Cloud-only objects are created directly in Entra ID — through the admin center, Microsoft Graph, or Microsoft Graph PowerShell — and Entra ID is authoritative for them. Synced objects originate in on-prem AD DS and are mirrored into Entra ID by Microsoft Entra Connect (or Entra Cloud Sync); on-prem AD remains authoritative, and most attribute edits must happen there, not in the cloud portal.

You can tell which model an object uses by checking its OnPremisesSyncEnabled property, or in the admin center by looking at the "Source" column, which shows Windows Server AD for synced objects and Azure Active Directory for cloud-only ones. Mixing models deliberately is normal — for example, service accounts, external contractors, and break-glass admin accounts are often created cloud-only even in an otherwise fully synced tenant, since they have no reason to exist on-prem.

Creating a cloud-only user with the Microsoft Graph PowerShell SDK (the supported successor to the retired AzureAD/MSOnline modules) looks like this:

Connect-MgGraph -Scopes "User.ReadWrite.All"

$PasswordProfile = @{
    Password = "TempP@ssw0rd1234!"
    ForceChangePasswordNextSignIn = $true
}

New-MgUser -DisplayName "Jordan Alvarez" `
    -UserPrincipalName "jordan.alvarez@contoso.com" `
    -MailNickname "jordan.alvarez" `
    -AccountEnabled `
    -PasswordProfile $PasswordProfile

Groups follow a similar cloud-only/synced split, but Entra ID also supports group types that have no on-prem equivalent. Security groups and Microsoft 365 groups can be created with assigned membership (you manually add/remove members, same as on-prem) or dynamic membership, where Entra ID evaluates a rule against user or device attributes and updates membership automatically:

New-MgGroup -DisplayName "Dynamic - Sales Department" `
    -MailEnabled:$false -MailNickname "dyn-sales" `
    -SecurityEnabled `
    -GroupTypes @("DynamicMembership") `
    -MembershipRule '(user.department -eq "Sales")' `
    -MembershipRuleProcessingState "On"

Dynamic groups are the backbone of most modern Entra ID designs because they eliminate manual membership maintenance for licensing, Conditional Access targeting, and app assignment — a user whose department attribute changes in HR-driven sync automatically moves between groups without an admin touching anything.

Group-Based Licensing

Group-based licensing assigns Microsoft 365, EMS, or other Entra-billed SKUs (like Entra ID P1/P2) to a security group rather than to individual users. Entra ID evaluates group membership continuously: add a user to the group and it acquires the license; remove them and it releases the license automatically. This replaces the old pattern of an admin manually running license assignment for every new hire.

The workflow is: assign the license to the group in the Entra admin center (Identity > Groups > select group > Licenses), which internally sets a license assignment on the group object referencing one or more SKUs from your tenant's subscriptions. You can inspect available SKUs and current assignments with:

Get-MgSubscribedSku | Select-Object SkuPartNumber, ConsumedUnits, PrepaidUnits
Get-MgUserLicenseDetail -UserId "jordan.alvarez@contoso.com"

Combine group-based licensing with dynamic group membership and you get a fully automated pipeline: a new hire's HR record syncs into AD, flows to Entra ID via Entra Connect, lands them in a dynamic group based on department or job title, and that group both assigns their Microsoft 365 E3 license and grants access to the SaaS apps and Conditional Access policies scoped to that group — with zero manual steps after the HR record is created.

Watch for license conflicts: some service plans within a SKU are mutually exclusive with plans from another SKU (for example, two different Exchange Online plans can't both be active for one user). When this happens, Entra ID assigns what it can and reports the rest as a licensing error on the group's "Assignment status" blade — it does not fail silently, but it also doesn't retry on its own, so this needs monitoring, especially in tenants with several overlapping SKUs.

Conditional Access Policies

Conditional Access is Entra ID's policy engine for enforcing access controls at sign-in time, based on signals rather than network location. Each policy is an if-then statement: assignments (who — users/groups, cloud apps, conditions like device platform, location, or sign-in risk) determine when the policy applies, and access controls (grant or block, plus session controls) determine what happens. This is the direct replacement for the old on-prem model of "trusted if you're on the corporate network" — Entra ID instead asks "who is this, on what device, from where, at what risk level" for every sign-in.

Common baseline policies most tenants implement early:

• Require MFA for administrators — target built-in role groups (Global Administrator, User Administrator, etc.) or a group containing privileged accounts, requiring multifactor authentication with no exceptions, since admin accounts are the highest-value target for compromise.
• Require MFA for all users — broader baseline coverage, often with a break-glass emergency access account explicitly excluded from the policy so a Conditional Access misconfiguration can't lock out every administrator simultaneously.
• Block legacy authentication — legacy protocols (POP, IMAP, older Exchange ActiveClients) don't support modern auth or MFA prompts and are a common brute-force target; blocking them closes off a large attack surface with minimal user impact.
• Require compliant or hybrid-joined device for sensitive apps — restricts access to finance or HR systems to devices that are Intune-compliant or hybrid Entra-joined, rather than any browser anywhere.
• Sign-in risk / user risk policies — these require Entra ID Protection (P2) and automatically require MFA or block sign-in when Microsoft's risk detection flags atypical travel, leaked credentials, or anomalous sign-in patterns.

Policies can be created via the admin center (Protection > Conditional Access) or through Microsoft Graph using the Microsoft.Graph.Identity.SignIns module. New policies should always be created in Report-only mode first — this evaluates the policy against real sign-ins and logs what would have happened without actually enforcing it, which is the safest way to validate scope before flipping it to On and potentially locking out a segment of users.

Entra Connect and Hybrid Identity

Microsoft Entra Connect (the successor to Azure AD Connect, sync engine now also available as the lighter-weight Entra Cloud Sync for simpler topologies) is the bridge that keeps on-prem AD DS and Entra ID consistent. It runs on a server joined to the on-prem domain, reads objects within its configured sync scope, and writes them to Entra ID on a default 30-minute cycle. The authentication method you choose during setup determines how synced users actually prove their identity at sign-in, and it's one of the most consequential decisions in a hybrid deployment.

Password Hash Sync (PHS) synchronizes a hash of each user's password hash (not the password itself) to Entra ID, which can then authenticate sign-ins independently, even if on-prem AD or the network link is down. It's the simplest option to deploy and maintain, requires no additional on-prem servers beyond Entra Connect itself, and is Microsoft's recommended default for most organizations. Pairing it with Seamless SSO gives domain-joined users silent sign-on without a password prompt at all, matching the on-prem experience users are used to.

Pass-Through Authentication (PTA) validates passwords directly against on-prem AD in real time via a lightweight connector agent, rather than syncing any password data to the cloud. It's the choice when policy or compliance requires that password validation never leave the corporate network — but it introduces a hard dependency: if all PTA agents and the on-prem AD are unreachable, cloud sign-in fails entirely, so it requires redundant agents on multiple servers to avoid becoming a single point of failure.

Federation (typically via AD FS) delegates authentication entirely to an on-prem federation server, with Entra ID redirecting sign-in requests there and trusting the resulting token. This is the most complex option — it means standing up and maintaining highly-available AD FS and Web Application Proxy servers — and is generally only justified by requirements PHS/PTA can't meet: third-party MFA providers that must sit in the auth path, smart-card authentication, or specific sign-in customization AD FS supports that Entra ID native features don't (rare today, since Entra ID's native capabilities have closed most of that gap).

For the large majority of new deployments, Microsoft's own guidance and most field experience point to PHS with Seamless SSO and Entra ID Protection layered on top: it's the lowest-maintenance option, survives on-prem outages, and gets you leaked-credential detection that PTA and federation can't provide natively since the password hash comparison happens in the cloud. Reserve PTA and federation for the specific compliance or legacy-integration cases that actually require them, rather than defaulting to the more complex option out of habit from on-prem-only environments.