3.1 Create, Configure & Manage Users
Key Takeaways
- Cloud-only users are created and managed entirely in Microsoft Entra ID; synchronized users are authoritative in on-premises Active Directory (or another connected source) and must be changed at the source for most attributes.
- Usage location must be set before license assignment because Microsoft 365 and Entra license services enforce regional service availability and compliance rules against that property.
- Deleted users enter a soft-deleted state for up to 30 days and can be restored with object ID, group memberships, and many license assignments intact; permanent deletion after that window requires recreating the identity.
- Disabling (blocking sign-in) is preferred over delete for temporary leave, investigation, or offboarding staging; it keeps the object, licenses, and audit trail while preventing authentication.
- SC-300 expects you to distinguish member, guest, cloud-only, synced, and break-glass identities and to choose the right lifecycle action for each type.
Why user lifecycle is core to SC-300
Domain 1 of the Microsoft Identity and Access Administrator Associate exam (SC-300) expects you to create, configure, and manage identities. Users are the primary human identity object in Microsoft Entra ID (formerly Azure Active Directory). Almost every later control—Conditional Access, multifactor authentication (MFA), Privileged Identity Management (PIM), access reviews, and license-based features—depends on a correctly provisioned user object with the right properties, memberships, and state.
This section focuses on internal (member) user lifecycle in the tenant. Guest and external collaboration deep-dives appear in a later chapter; here you need only enough guest awareness to avoid misclassifying identity types on the exam.
Cloud-only versus synchronized users
Two creation models dominate real tenants and exam scenarios:
| Aspect | Cloud-only user | Synchronized (hybrid) user |
|---|---|---|
| Source of authority | Microsoft Entra ID | On-premises Active Directory Domain Services (AD DS) or another connected directory, via Microsoft Entra Connect Sync or Cloud Sync |
| Where you create it | Entra admin center, Microsoft Graph, Microsoft Graph PowerShell, or bulk CSV | On-premises AD (or HR-driven identity pipeline that writes to AD) |
| Attribute writes | Most attributes editable in Entra | Most directory attributes are read-only in Entra; change them at the source |
| Password | Cloud password (or passwordless methods) | Depends on hybrid auth: password hash sync (PHS), pass-through authentication (PTA), or federation |
| Deletion | Soft-delete in Entra | Delete or disable in the source; sync reflects the change (subject to soft-match/recycle behavior) |
Exam rule of thumb: if a scenario says “the user was created in Active Directory and synced,” do not choose “edit the department attribute in the Entra admin center” as the fix. Choose update on-premises AD (or the authoritative HR/source system) and allow the next sync cycle to flow the change.
Cloud-only users are common for pure cloud tenants, break-glass accounts, some contractor models (when not using B2B guests), and service-style human accounts that never lived in AD. Synchronized users are the norm for enterprises that retain on-premises AD as the identity source of truth.
How you tell them apart in the portal
In the Microsoft Entra admin center, open a user and check Identity / source indicators. Synchronized users typically show a source such as Windows Server AD (wording can vary slightly by UI version) and many profile fields appear dimmed or non-editable. Cloud-only users show Microsoft Entra ID (or similar cloud source) and allow broader in-cloud edits.
Creating a user (cloud-only path)
When you create a cloud-only user in the Entra admin center (or via Graph), you commonly set:
- User principal name (UPN) — the sign-in name (for example,
alex@contoso.com). The UPN domain must be a verified domain (or the default*.onmicrosoft.comdomain). - Display name, first name, last name, and job title/department as needed for directory completeness and dynamic group rules later.
- Password options — auto-generate or specify; force change at first sign-in is a common security control for admin-created accounts.
- Groups and roles — optional at create time; many orgs assign groups after creation for cleaner automation.
- Usage location — critical before licensing (covered below).
Microsoft Graph PowerShell (New-MgUser) and bulk CSV create paths produce the same object model. The exam cares more about properties and lifecycle rules than clicking every wizard page.
Key user properties for SC-300
Memorize properties that affect authentication, licensing, collaboration, and governance:
| Property / setting | Why it matters |
|---|---|
| User principal name (UPN) | Primary sign-in identifier for most cloud apps |
| Object ID | Immutable unique identifier used by Graph, CA troubleshooting, and restore operations |
| User type | Member vs Guest drives collaboration defaults and many license/group behaviors |
| Account enabled / Block sign-in | Controls whether the user can authenticate |
| Usage location | Required for license assignment; drives service availability |
| Manager | Used by access reviews, entitlement workflows, and org charts |
| Department, job title, employee ID, company | Common dynamic group rule attributes |
| Authentication methods | MFA methods, Temporary Access Pass, passwordless — detailed in later chapters |
| Directory roles | Privileged roles (Global Admin, User Administrator, etc.) — prefer PIM later |
| Identities / source | Distinguishes cloud-only vs federated/synced identities |
Block sign-in (disable the account) is the operational control for “this person must not authenticate right now” without destroying the object. Deletion is a stronger, recovery-oriented lifecycle event.
Usage location (do not skip this)
Usage location is a two-letter country/region code on the user object (for example, US, GB, DE). Microsoft 365 and many Entra ID P1/P2 feature licenses require it before you can successfully assign a license. Without usage location, license assignment fails or services do not provision correctly.
Operational implications:
- Set usage location before assigning Microsoft 365 E3/E5, Entra ID P1/P2, EMS, or related SKUs.
- Usage location also influences which services are available in that country (compliance and export control constraints).
- For bulk onboarding, include usage location in your CSV or automation template; missing it is a classic day-one provisioning failure.
If group-based licensing is used (next section’s sibling topic in this chapter), users still need a valid usage location for the license to apply successfully when the group assignment is processed.
Soft-delete, restore, and permanent deletion
When you delete a user in Microsoft Entra ID:
- The user enters a soft-deleted (recycle bin) state.
- Soft-deleted users remain recoverable for up to 30 days (the default retention window for deleted users).
- During that window an admin with sufficient privileges can restore the user.
- After the window, the user is permanently deleted and must be recreated as a new object if needed (new object ID; prior app assignments and some relationships are not magically reconstituted the same way a restore would).
What restore typically preserves: object ID continuity for the restored user, many group memberships, role assignments, and license state depending on how deletion interacted with those systems. Restore is far preferable to “create a new account with the same UPN” when the business needs continuity of identity for apps and audit.
Exam scenarios:
- User deleted by mistake yesterday → restore from deleted users, not recreate.
- User left the company six months ago and object is gone → recreate (and re-establish access packages/groups as designed).
- Need to stop access immediately but keep mailbox/data processes running per IT policy → often block sign-in first, then follow offboarding runbooks (licenses, Exchange, OneDrive) rather than impulsive delete.
Disable versus delete
| Goal | Prefer |
|---|---|
| Temporary leave, investigation, suspected compromise | Block sign-in |
| Staged offboarding while retaining audit and group history short-term | Block sign-in, then scheduled deprovision |
| Identity no longer needed and retention policy allows | Delete (soft-delete) after access removal checklist |
| Need object and app assignments back after accidental removal | Restore soft-deleted user |
Blocking sign-in keeps licenses and group memberships unless you also remove them. That can be intentional (preserve data processing) or wasteful (paying for licenses on disabled accounts). SC-300 expects you to reason about security first, then license hygiene and governance automation.
Bulk create concepts
Large onboarding waves use bulk operations rather than one-by-one UI clicks:
- Bulk create users in the Entra admin center via a CSV template (UPN, display name, initial password pattern, department, usage location, and so on).
- Microsoft Graph and Microsoft Graph PowerShell for scripted creation with validation, retry, and logging.
- HR-driven provisioning (for example, cloud HR apps with app provisioning) for continuous joiner automation—more advanced identity governance territory, but know that bulk CSV is the classic admin-center path.
Bulk success depends on verified domains, unique UPNs, password policy compliance, and complete required properties. Partial failures are common when usage location or domain suffixes are wrong for a subset of rows.
Identity types relevant to SC-300
Keep these identity categories clear; exam items often hinge on picking the right category’s management path:
| Identity type | Notes for SC-300 |
|---|---|
| Member (cloud-only) | Full internal user created in Entra; fully cloud-managed |
| Member (synced) | Internal employee identity authoritative on-premises |
| Guest (B2B) | External collaborator; invited or self-service redemption; different default permissions |
| Break-glass / emergency access | Cloud-only, highly privileged, excluded from many CA policies; strict monitoring |
| Workload identities | Apps, service principals, managed identities—not users; covered in workload chapters |
| Device identities | Join/register state on devices—covered later in this chapter |
Do not confuse a guest user with a cloud-only member contractor account. Guests use invitation/redemption flows and external collaboration settings; members do not.
Practical exam traps
- Choosing cloud UI edits for synced attributes.
- Assigning licenses without usage location.
- Deleting when block sign-in was the proportionate control.
- Recreating instead of restoring within the soft-delete window.
- Treating guest and member identically for default access and governance.
When you can state, for any scenario, where authority lives, which property must change, and whether to block, delete, or restore, you have the SC-300 user-management foundation needed before groups, licenses, and devices.
A user’s Department attribute must be updated. The user was created in on-premises Active Directory and synchronized with Microsoft Entra Connect. Where should an identity administrator make the change?
An administrator attempts to assign a Microsoft 365 license to a newly created cloud user and the assignment fails until a specific user property is set. Which property is required for successful license assignment?
A User Administrator accidentally deleted a cloud-only user two days ago. The business needs the same identity restored with continuity of object ID and prior memberships where possible. What should they do?
Security suspects a member account is compromised but the investigation may take several days. Which action best stops authentication immediately while preserving the user object for investigation and recovery?