A user object in Microsoft Entra ID carries far more than a name and password. Properties such as job title, department, manager, office location, employee ID and usage location are used by dynamic group rules, by the global address list and by licensing. You edit them on the user's Properties page in the portal, in bulk with Microsoft Graph PowerShell (Update-MgUser -UserId ana@contoso.com -Department "Finance"), or, for synchronized users, in on-premises Active Directory Domain Services (AD DS), because the on-premises directory is the source of authority. Groups have properties too: name, description, owners (who can manage membership without being administrators), membership type, and whether the group can be assigned Microsoft Entra roles, a setting you can only choose when you create the group.
Licenses for products such as Microsoft 365 or Microsoft Entra ID P1 and P2 are assigned to users. Before a license can be assigned, the user must have a usage location set, a two-letter country property, because some services are not available in every country; assignment fails without it. You can assign a license directly on the user's Licenses page, but at scale direct assignment becomes hard to track and easy to forget when people leave.
Group-based licensing solves that. You assign the license to a group, and every member receives it, with the option to turn off individual service plans inside the product, for example disabling one app for a department. When a user joins the group they get the license; when they leave, it is removed. Combine this with a dynamic group and licensing follows HR data automatically. Group-based licensing needs Entra ID P1 or a product that includes it. If assignment fails, for example because there are not enough licenses, a usage location is missing or two service plans conflict, the group's Licenses page shows those users in an error state so you can fix them and reprocess. A user can hold the same license both directly and through a group; removing the direct assignment then leaves the inherited one in place.
External collaboration uses Microsoft Entra B2B (business-to-business). You invite a partner by email address (Users > New user > Invite external user, or New-MgInvitation), and a guest user object is created in your tenant with a user type of Guest. The partner signs in with their own identity from their home organization, a Microsoft account, or an email one-time passcode, so you never store or reset their password. After they redeem the invitation you can put guests in groups and give them RBAC roles like any other user. External collaboration settings control who can invite guests (for example only admins and users in the Guest Inviter role), how much of your directory guests can see, and which partner domains are allowed or blocked. Cross-tenant access settings add finer control over inbound and outbound collaboration with specific organizations.
Self-service password reset (SSPR) lets users reset a forgotten password without calling the help desk. Under Microsoft Entra ID > Password reset you enable it for None, Selected (one group) or All users, choose which authentication methods are allowed (such as the Microsoft Authenticator app, mobile phone, email or security questions), and set how many methods are required to reset: one or two. Users must register methods before they can use SSPR, and you can require registration at sign-in with a periodic reconfirmation. For users synchronized from on-premises, password writeback through Microsoft Entra Connect or Cloud Sync is needed so the new password is written back to AD DS; without it, the reset either fails or leaves the on-premises password unchanged. Administrator accounts always use a stricter built-in policy that requires two methods and never allows security questions, regardless of your settings.
Consider a worked example. An engineering firm creates a dynamic user group for user.department -eq "Engineering" and assigns the Microsoft 365 license to it, turning off one service plan the team does not use. A new engineer is created with department Engineering but no usage location, and the group shows her in an error state. You set usage location to Canada, reprocess the group, and the license arrives. A contractor from a partner firm is invited as a B2B guest, redeems the invitation with his own company account, and is added to a project security group that has Contributor on one resource group. SSPR is enabled for the Engineering group with two required methods, and password writeback is turned on because the engineers sync from on-premises.
Common mistakes: assuming spare licenses guarantee assignment when the usage location is empty; thinking guests have passwords in your tenant; picking 'Selected' for SSPR and expecting to add several groups (it takes one group, so nest groups or use All); forgetting that writeback is needed for synchronized users; and believing the role-assignable group setting can be turned on later.
Exam wording: 'license assignment fails but licenses are available' points to usage location. 'Assign licenses automatically when users join a department' points to group-based licensing with a dynamic group. 'External partner, their own credentials' points to B2B guest invitation. 'Users reset their own password, change must reach on-premises' points to SSPR plus password writeback. 'Minimize help desk calls' is almost always SSPR.
Key terms
- Usage location
- The country property on a user that must be set before a license can be assigned.
- Group-based licensing
- Assigning a license to a group so that all members inherit it and lose it when they leave the group.
- Service plan
- An individual component of a license product that can be turned off during assignment.
- B2B guest user
- An external identity invited into your tenant with user type Guest who signs in with credentials from their own organization or account.
- External collaboration settings
- Tenant settings that control who can invite guests, what guests can see and which domains are allowed.
- Self-service password reset (SSPR)
- A feature that lets registered users reset their own password using verified authentication methods.
- Password writeback
- A sync feature that writes passwords reset in the cloud back to on-premises Active Directory.
An engineering firm adds a dynamic group for all users in the Engineering department and assigns the Microsoft 365 license to it. A new engineer's license fails until the administrator sets her usage location to Canada and reprocesses the group. A contractor from a partner firm is invited as a B2B guest, added to a project group and signs in with his own company account, while engineers reset forgotten passwords through SSPR with writeback to on-premises AD DS.
Check yourself
A license assignment to a new user fails with an error. The tenant has spare licenses. What is the most likely cause?
The user's usage location is not set; it is required before a license can be assigned.
How does a B2B guest authenticate to your tenant?
With their own identity from their home organization, a Microsoft account or a one-time passcode; your tenant does not store their password.
You enable SSPR for synchronized users, but reset passwords do not work on-premises. What is missing?
Password writeback through Microsoft Entra Connect or Cloud Sync, which writes the new password back to Active Directory.
You want every user in the Sales department to receive a license automatically. What do you configure?
Group-based licensing on a dynamic user group whose rule matches the Sales department, which requires Entra ID P1.