The most expensive identity failures are often created by systems that each appear to be working. A human resources team changes an employee’s name, on-premises directory synchronization publishes a partially updated account, and a Conditional Access policy evaluates claims that no longer match the intended group. The user sees a login error; administrators may see several successful operations with a missing relationship between them.<\/p>\n
The MS-102<\/a> identity-and-access objectives address synchronization, authentication, and secure access across Microsoft 365. As of October 2026, Microsoft has scheduled the exam’s retirement for November 30, but the identity techniques remain essential to running hybrid environments. The strongest preparation therefore focuses on tracing where an identity comes from, which system controls it, and how access is evaluated at each step.<\/p>\n An organization may create users directly in Microsoft Entra ID or synchronize selected directory objects from on-premises Active Directory Domain Services. Those are different source-of-authority models. A synchronized user’s selected attributes may need to be changed in the original directory instead of through a cloud interface. Attempting to fix every issue in the Microsoft 365 admin center can lead to repeated corrections that disappear at the next synchronization cycle.<\/p>\n Microsoft Entra Connect Sync and Microsoft Entra Cloud Sync have different deployment models and supported scenarios. The right choice depends on forest complexity, agent availability, feature requirements, security boundaries, and operational ownership. A legacy directory may contain duplicate or malformed attributes that should be investigated with preparation tools such as IdFix before synchronization, not assumed to disappear after migration.<\/p>\n Identity health monitoring should address connector failures, delayed exports, attribute conflicts, and objects unexpectedly excluded by filtering. When one department cannot sign in after a merger, confirm whether its accounts were in the configured synchronization scope. An enabled user in a source directory is not enough evidence that a corresponding cloud identity is ready, correctly matched, and assigned the expected access.<\/p>\n Authentication establishes confidence in a claimant’s identity under a particular method. Authorization evaluates what the authenticated subject may do to a resource. The distinction becomes important when someone successfully completes multifactor authentication but remains unable to reach a SharePoint site. The problem might be group membership, a resource permission, a session restriction, or a policy requiring a compliant device.<\/p>\n Password hash synchronization, pass-through authentication, and federation place different dependencies in the sign-in flow. A cloud authentication arrangement may continue working during an on-premises outage under conditions where another design cannot. Candidates should understand these architectural consequences and not assume all hybrid implementations have the same failure path. Identity troubleshooting starts by identifying the actual authentication method and the systems it requires.<\/p>\n Strong authentication includes choices about authenticator methods, registration, recovery, and user experience. MFA can be undermined by weak recovery processes, socially engineered approvals, or unmanaged devices. Self-service password reset should be deployed with deliberate verification and writeback considerations where applicable. An enrollment campaign that neglects frontline staff or external collaborators can create a predictable flood of risky exceptions.<\/p>\n A Conditional Access policy combines assignments and conditions with access controls. Users, workloads, cloud applications, device signals, locations, and sign-in risk may affect the result according to the configured capabilities. A policy that appears simple on paper can behave unexpectedly when exclusions, multiple policies, legacy authentication, or group changes intersect. Evaluate the actual sign-in logs and policy details rather than inferring a result from the policy title.<\/p>\n A finance team might require phishing-resistant authentication for sensitive administration while permitting ordinary low-risk collaboration through a different supported method. That choice must take account of user capabilities, device enrollment, temporary access, and break-glass recovery. Policy should be tested in a report-only or otherwise controlled mode when available, with a representative population, before enforcement is expanded.<\/p>\nSeparate identity source from cloud access<\/h2>\n
Authentication and authorization are separate decisions<\/h2>\n
Conditional Access expresses policy as an evaluated context<\/h2>\n