Troubleshooting Lab: Create users and groups
Diagnostic Scenarios
Scenario 1 — Root Cause
An IT administrator reports that they attempted to create a new member user in Microsoft Entra ID through the Azure portal. The process completed without error messages and the user appears in the directory's user list. However, when trying to sign in with the created credentials, the user receives the following message:
AADSTS50126: Invalid username or password, or Invalid on-premise username or password.
The administrator confirms that:
- The password was set as
Temp@2024!during creation - The option "User must change password on next sign-in" was checked
- The tenant uses a verified custom domain
contoso.com - The created user's UPN was
joao.silva@contoso.com - The tenant has Microsoft Entra Connect configured, synchronizing users from an on-premises AD
- The user's department was filled as
ITin the profile
The administrator verifies that no user with the same UPN exists in the on-premises AD.
What is the root cause of the authentication failure?
A. The password Temp@2024! does not meet the Microsoft Entra ID minimum complexity policy.
B. The user was created as a cloud member, but Microsoft Entra Connect overwrote or blocked the object due to identity conflict with the synchronization scope.
C. The domain contoso.com is not verified in the tenant, preventing authentication with that UPN suffix.
D. The "change password on next sign-in" option conflicts with the Microsoft Entra Connect authentication flow, which blocks sign-ins with temporary passwords.
Scenario 2 — Action Decision
The identity team identified that a security group called GRP-Auditoria was incorrectly configured with membership type Assigned when it should be Dynamic, as the rule based on the attribute jobTitle -eq "Auditor" needs to be applied automatically. The group already has 15 manually added members and is associated with 3 active Microsoft Entra Conditional Access policies in production.
The cause is confirmed. The team needs to act now, during business hours, without an approved maintenance window.
What is the correct action to take at this moment?
A. Change the existing group's membership type from Assigned to Dynamic directly through the Azure portal, keeping the current members.
B. Create a new group with Dynamic membership type and the correct rule, update the 3 Conditional Access policies to reference the new group, and remove the old group only after validation.
C. Create a new group with Dynamic membership type, wait for automatic member propagation, and immediately delete the old group to avoid duplication.
D. Add the dynamic rule as metadata to the existing group via Microsoft Graph API, without needing to recreate the group.
Scenario 3 — Root Cause
An administrator configured a dynamic group in Microsoft Entra ID with the following membership rule:
(user.department -eq "Vendas") and (user.accountEnabled -eq true)
The group was created 48 hours ago. When checking the members, the administrator observes that only 12 of the expected 40 users from the Sales department are in the group. The administrator verifies the following facts:
- All 40 users have the
departmentfield filled asVendasin the Microsoft Entra ID portal - All 40 users have
accountEnabled = truein the portal - The tenant has Microsoft Entra ID P1 license assigned only to the 12 users that appear in the group
- The other 28 users have only Microsoft 365 Business Basic license
- The rule was successfully validated by the portal validation tool before being saved
- The group was created by a Global Administrator
What is the root cause of the problem?
A. The membership rule contains a syntax error that only affects users without Entra ID P1 license, processing them partially.
B. Dynamic groups require each potential member to have a Microsoft Entra ID P1 or higher license; users without this license are not evaluated by the rule.
C. The 48-hour period has not been sufficient for complete processing; dynamic groups with more than 30 expected members can take up to 72 hours on first evaluation.
D. The accountEnabled attribute is not supported as filtering criteria in dynamic membership rules and is being silently ignored, causing incorrect evaluation.
Scenario 4 — Diagnostic Sequence
An administrator receives the following report: a user member of the dynamic group GRP-RH-Dinamico lost access to an application integrated with Microsoft Entra ID. Access was granted exclusively through membership in this group.
The available investigation steps are:
- Verify if the Microsoft Entra ID P1 license is still assigned to the tenant
- Confirm if the user still appears as a member of the
GRP-RH-Dinamicogroup in the portal - Check the current value of the attribute used in the dynamic rule in the user's profile
- Review the user profile change history in Microsoft Entra ID audit logs
- Confirm if the application still has the
GRP-RH-Dinamicogroup as an active access assignment
What is the correct investigation sequence?
A. 1 → 2 → 3 → 5 → 4
B. 2 → 3 → 4 → 5 → 1
C. 5 → 2 → 3 → 4 → 1
D. 2 → 5 → 3 → 4 → 1
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The central clue in the statement is the combination of two facts: the tenant has Microsoft Entra Connect active synchronizing objects from on-premises AD, and the user was created directly in the cloud with a UPN that belongs to the synchronized domain contoso.com. When Entra Connect is configured to synchronize a domain, objects created directly in the cloud with UPNs from that domain can conflict with the synchronization scope. Entra Connect may treat this object as an identity conflict, convert the user to an inconsistent state, or block authentication by not recognizing the credential as locally managed.
The information about the IT department is irrelevant and was intentionally included to simulate data noise present in real scenarios.
Alternative A is incorrect: Temp@2024! meets the standard Entra ID complexity criteria (uppercase, lowercase, number, symbol, 8+ characters).
Alternative C is the most dangerous distractor: if the domain wasn't verified, the user wouldn't have been created with that UPN without error. The successful creation confirms the domain is verified.
Acting based on alternative C would lead the administrator to waste time resetting passwords or recreating the user without resolving the actual conflict with Entra Connect.
Answer Key — Scenario 2
Answer: B
The context imposes two critical restrictions: the group is linked to active Conditional Access policies in production and there's no maintenance window. Alternative B is the only one that respects both restrictions, as it keeps the original group functional while the new group is prepared and validated, only removing the reference in the policies after confirmation.
Alternative A represents a serious conceptual mistake: Microsoft Entra ID does not allow changing the membership type of an existing group. This operation is simply not available, regardless of the method used.
Alternative C is technically possible as a sequence, but deleting the old group immediately before validating the new group in production represents a real risk of access interruption for users covered by the Conditional Access policies.
Alternative D is false: the Microsoft Graph API also doesn't expose an endpoint that allows converting the membership type of an existing group. The restriction is platform-based, not interface-based.
Answer Key — Scenario 3
Answer: B
The root cause is in the license distribution described in the statement: exactly the 12 users with Microsoft Entra ID P1 license are in the group, and the remaining 28 don't have this license. Dynamic groups in Microsoft Entra ID are a feature that requires P1 or higher license per evaluated user. Users without this license are not eligible for dynamic membership, regardless of their profile attributes.
The information that the rule was successfully validated by the portal tool is irrelevant for this diagnosis and was intentionally included. The rule's syntactic validation doesn't check license coverage for candidate users.
Alternative C is the most superficially plausible distractor, but the statement informs that 48 hours have already passed and the group is stable with 12 members, without growth. A latency problem would manifest as gradual growth, not as a fixed plateau that exactly matches the number of licensed users.
Alternative D is wrong: accountEnabled is a supported and documented attribute in dynamic membership rules in Entra ID.
Answer Key — Scenario 4
Answer: D
The correct sequence is: 2 → 5 → 3 → 4 → 1.
The diagnostic reasoning should follow the logic from symptom to cause, from most specific to most broad:
- Step 2: confirming if the user is still a group member is the first verifiable and most direct to the reported symptom.
- Step 5: confirming if the group is still assigned to the application eliminates the hypothesis that the problem is in the application configuration, not the user.
- Step 3: checking the current attribute value in the user's profile answers why they left the group, if that's the case.
- Step 4: audit logs confirm when and by whom the attribute was changed, completing the diagnosis.
- Step 1: verifying the tenant's P1 license is a broad infrastructure check, relevant only if previous steps don't identify the cause.
Alternative B (2 → 3 → 4 → 5 → 1) is plausible, but checks the attribute and history before confirming if the group still has application access, which may lead the administrator to fix the user's attribute without noticing the group was disassociated from the application, solving only half the problem.
Troubleshooting Tree: Create users and groups
Legend:
| Color | Meaning |
|---|---|
| Dark blue | Initial symptom (root node) |
| Blue | Diagnostic question |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Intermediate validation or verification |
To use this tree when facing a real problem, start at the root node and answer each diagnostic question based on what is observable in the portal or Microsoft Entra ID logs. Each answer eliminates a branch and leads to the next verification level. When reaching a cause node (red), the corresponding action (green) indicates the recommended correction. Never jump directly to the action without following the question path, as identical symptoms may have different causes depending on licensing context, group type, and synchronization configuration.