In CompTIA A+ Core 2 (220-1202), Domain 1, Objective 1.11, you're expected to install, configure, and support cloud-based productivity tools. Two ideas show up in real tickets more than most: identity synchronization and licensing assignment. Cloud productivity tools (such as Microsoft 365 and Google Workspace) bundle email, chat, file storage, calendars, and office apps, but users only benefit when their account exists in the right place and has the right permissions.
Support work often turns into a simple question with a messy backstory: "Why can't this user sign in or use email?" The answer usually sits in one of two buckets. Either the user's identity didn't sync correctly (or doesn't match), or the user has no license (or the wrong one). This guide explains what identity sync is, how licensing works, and how to troubleshoot common access failures with quick, practical checks.
Identity synchronization, what it is and why support techs care
Identity synchronization means keeping user identity data consistent across systems. In many organizations, users start in an on-premises directory such as Active Directory (AD). The business may also keep employee records in an HR system. Cloud services, however, rely on a cloud directory, such as Microsoft Entra ID (formerly Azure AD), or Google Cloud Identity in Google environments. Sync connects these sources so that names, usernames, passwords (depending on the method), and group memberships stay aligned.
A helpful mental model is one person, one identity, many doors. The person is the employee. The identity is their account record. The doors are services like email, Teams, SharePoint, Google Drive, or Google Meet. When the identity matches across systems, users sign in once and move between tools with fewer prompts.
Organizations care about identity sync for clear reasons:
- Single sign-on (SSO) support, so users authenticate once and access multiple services.
- Fewer passwords, which reduces lockouts and password re-use.
- Faster onboarding, because creating one account can feed many services.
- Better control, because disabling an account in the right place can block access quickly.
For Microsoft 365 hybrid setups, a common approach uses Microsoft Entra Connect to synchronize on-prem AD objects to Entra ID. Authentication can work in several ways. Password hash synchronization copies a password hash to the cloud so the user can sign in to cloud services directly. Pass-through authentication keeps password validation on-prem, even though the user signs in to cloud apps. At the A+ level, you don't need design depth. What matters is the result: if identity sync fails, the user might exist on one side but not the other, or their sign-in name might not match the expected format.
Where identity sync shows up in real life
Most users never hear the term "identity synchronization," yet they feel it when something breaks. Hybrid Microsoft 365 is a common example. A user gets created in Active Directory, then Entra Connect syncs that user to Entra ID, and Microsoft 365 services attach to that cloud identity. Google Workspace environments can also sync from an on-prem directory or an HR source into Google Cloud Identity, depending on the organization's setup.
Once synced, users and groups become the access backbone for collaboration tools. Teams and SharePoint rely heavily on group membership. Exchange Online needs a cloud identity to attach a mailbox. Even basic scenarios, like joining a shared calendar, can depend on the correct primary email address and a consistent sign-in name.
Help desk requests tend to sound routine, but the fixes often touch sync:
- Reset a password and confirm the change works for cloud sign-in.
- Fix a sign-in failure when the username format changed (or the user types the old one).
- Confirm the cloud account exists and matches the on-prem account.
- Check group membership so the user can access Teams sites or shared drives.
Think of identity sync like a shipping label. If the label is wrong, the package might still exist, but it won't reach the right destination.
Common identity sync problems and quick checks
Identity sync failures often look like "bad password," yet the root cause may be naming, duplication, or timing. Start with checks that confirm the identity exists and matches across systems.
First, verify the user exists on-prem (if the business uses AD) and in the cloud directory. Next, compare the user principal name (UPN), often formatted like user@domain.com, to what the user is typing. A UPN mismatch is common after a domain change or after standardizing usernames.
Email attributes matter too. Confirm the primary email address matches the expected domain and spelling. Also watch for duplicate accounts. For example, a cloud-only account might exist from early testing, then a synced account appears later. Those duplicates can cause sign-in confusion, licensing mistakes, or mailbox attachment issues.
Timing causes false alarms. Sync is not always instant. A new user or a group change may take time to appear in the cloud. If a ticket comes in right after onboarding, waiting and re-checking later can be part of the correct process, not a stall tactic.
Fast triage rule: if sign-in fails, confirm account existence, UPN format, and sign-in status before you reset anything.
Also check whether the account is blocked from sign-in in the cloud. A user can have the correct password and still be denied access if the account is disabled, flagged, or restricted by policy (including multi-factor authentication requirements). When you see repeated lockouts, consider whether the user has an old password saved on a phone, a tablet, or an email client.
How licensing assignment works in Microsoft 365 and Google Workspace
A license is a paid permission that enables services for a user. In Microsoft 365, assigning a license can activate Exchange Online, Teams, SharePoint, and desktop apps, depending on the plan.