In a hybrid enterprise environment, an organization uses Azure AD Seamless Single Sign-On (Seamless SSO). During a penetration test, an attacker compromises a domain-joined workstation and attempts to abuse Seamless SSO. What is the mechanism by which Seamless SSO authenticates users, and what is a known security consideration?
Seamless SSO creates the AZUREADSSOACC$ computer account in on-premises AD, whose Kerberos decryption key Microsoft Entra ID shares. Domain-joined users obtain a Kerberos service ticket for that account, which the browser presents for cloud authentication. Compromising the account's key enables forging tickets for any user, satisfying the hybrid SSO constraint.
Why this answer
Seamless SSO uses a computer account named AZUREADSSOACC$ in on-premises AD whose Kerberos decryption key is shared with Azure AD. When a user on a domain-joined machine accesses a Microsoft 365 resource, the browser is redirected to Azure AD, which returns a Kerberos challenge; the local machine requests a service ticket for AZUREADSSOACC$ from the on-prem DC, and the browser presents it to Azure AD, which decrypts it with the shared key to authenticate the user without re-entering credentials.
Exam trap
The trap is that candidates confuse Seamless SSO with Password Hash Synchronization or Pass-through Authentication, or assume it bypasses Conditional Access, when it actually uses Kerberos tickets via the AZUREADSSOACC$ account.
How to eliminate wrong answers
Option A is wrong because Seamless SSO never stores plaintext passwords in Azure Key Vault — it relies on Kerberos tickets, not password synchronization. Option B is wrong because Seamless SSO does not bypass Conditional Access; CA policies still evaluate sign-in risk, device compliance, and location. Option C is wrong because Seamless SSO does not export NTLMv1 hashes to Azure AD; that describes neither its mechanism nor a real behavior.