Azure AD Integration practice questions

It stores plaintext passwords in the Microsoft Entra ID cloud repository.

Why it fails: PHS does not transmit or store passwords in plaintext. It uses an iterative hashing algorithm to process the on-premises password, creating a hash that is then synchronized to Microsoft Entra ID. This ensures that cleartext credentials are never exposed during the transit or storage process in the cloud.

It requires the on-premises domain controller to be directly accessible from the internet.

Why it fails: Microsoft Entra Connect handles the synchronization process via outbound-only connections to Azure. The on-premises domain controllers do not need to be exposed to the internet. The sync service initiates the connection over HTTPS, maintaining the security boundary of the internal network against direct external inbound attacks.

It forces all cloud users to reset their passwords every 90 days.

Why it fails: Password hash synchronization does not dictate or enforce password rotation policies. Password policies are governed by the source of authority, which remains the on-premises Active Directory. Microsoft Entra ID will honor the password policy settings defined within the local domain controllers during the synchronization process.

Grant the Microsoft Entra Connect service account Global Administrator permissions.

Why it fails: Assigning Global Administrator rights is a violation of the principle of least privilege. The service account only requires specific directory permissions to perform synchronization tasks. Over-privileged service accounts provide attackers with a massive target for compromise, potentially leading to full tenant takeover if the account is hijacked.

Disable all logging to prevent attackers from viewing synchronization activity.

Why it fails: Disabling logs severely hinders incident response and forensic investigations. Security teams need visibility into the synchronization service to detect anomalous behavior, such as unexpected mass object updates or unauthorized modifications to the sync rules that could indicate an identity-based attack is currently in progress.

Use a standard domain user account to run the Microsoft Entra Connect local database.

Why it fails: Running the sync database with a standard user account will lead to service failure due to insufficient access. The service requires specific permissions to interact with the local SQL instance and the Active Directory environment. Using improper accounts results in unstable sync performance and security configuration errors.

The policy is currently in report-only mode and is not enforcing security.

Why it fails: The status field explicitly states 'Enabled'. Therefore, the policy is actively enforcing the defined controls on the targeted users. If the policy were in report-only mode, the status would indicate so, and it would not be actively mitigating the threats to the tenant's authentication infrastructure.

Applying the policy to 'All Users' is a configuration error that blocks all authentication.

Why it fails: Applying a policy to 'All Users' is a common and supported configuration for organizational security. It does not automatically block authentication unless the grant control is set to 'Block access'. Here, the policy is simply defining the scope, and the actual risk relates to the account exclusion.

The policy requires a specific location constraint that is missing from the JSON.

Why it fails: While location constraints are a best practice, the absence of one in this specific JSON snippet does not constitute the primary security risk. The critical flaw is the unconstrained exclusion of a high-privilege account, which is a known attack vector in Microsoft Entra ID administrative security hardening.

It automatically assigns the Domain Admins the Global Administrator role.

Why it fails: While synchronized, groups are not automatically mapped to the Global Administrator role. However, if the environment is misconfigured or if roles are mapped via third-party tools, this synchronization can lead to unintentional privilege escalation, making it a critical area for strict management of sync rules.

It is required for the Microsoft Entra Connect synchronization service to function correctly.

Why it fails: The synchronization engine does not require Domain Admin groups to be synchronized. The service account itself needs specific permissions, but this is different from syncing the group objects themselves. Synchronizing administrative groups is an optional configuration that usually poses a security risk rather than a functional requirement.

It allows cloud users to reset the passwords of on-premises Domain Admins.

Why it fails: Synchronizing groups does not grant cloud-to-on-premises password reset capabilities. The flow of identity is typically one-way, from on-premises to the cloud. Granting cloud-based users the ability to reset sensitive on-premises administrative passwords would be a severe security flaw that is not enabled by default synchronization.

The user is using an incorrect password.

Why it fails: While the error code indicates an invalid password, the presence of the Conditional Access trigger suggests that the authentication attempt was blocked by policy before the password could even be validated. The policy enforcement is the primary reason the access attempt was unsuccessful in the eyes of security.

The account has been locked due to excessive failed attempts.

Why it fails: A locked account error typically produces a specific sign-in code related to account status, not a legacy authentication policy block. The error message specifically references the 'Block_Legacy_Auth' policy, which is the defining factor in this authentication failure, regardless of the account's current lockout status.

The Microsoft Entra Connect synchronization server is offline.

Why it fails: An offline sync server would prevent identity updates but would not trigger a specific legacy authentication policy block. The error is clearly related to the authentication method being used by the client application, not the health or connectivity status of the backend identity synchronization infrastructure.

A user logging in from their usual home office IP address during business hours.

Why it fails: Authentication from a known location during normal work hours is expected, baseline behavior. Monitoring systems are designed to identify anomalies, and flagging expected activity as a potential security incident would lead to high volumes of false positives, effectively masking actual threats in the environment.

A user performing a standard, scheduled task using a service account.

Why it fails: Scheduled service account tasks are normal operational activity. These accounts should be baseline-monitored, and their behavior should be consistent. Flagging normal, scheduled behavior as suspicious would create noise and interfere with the organization's ability to focus on truly anomalous or malicious behavior within the identity environment.

A successful login from a new device that was previously registered in the domain.

Why it fails: A user logging in from a known, domain-registered device is standard and secure behavior. The environment should facilitate this activity. This is not an indicator of an identity-based attack and should be treated as legitimate user activity as long as the device is properly managed and compliant.

Create a standard cloud-only Global Administrator account directly in the Azure portal using stolen credentials

Why it fails: Creating a cloud-only Global Administrator account is easily monitored by continuous threat monitoring solutions and generates immediate audit logs in the Microsoft Entra portal. Security teams routinely audit privileged role assignments, making this an extremely short-lived and noisy persistence vector during an assessment.

Modify the on-premises user account password and force an immediate Microsoft Entra Connect synchronization cycle

Why it fails: Forcing a synchronization cycle after modifying a normal user password will merely update the hash in Microsoft Entra ID if password hash synchronization is enabled. It does not establish persistent administrative access unless the targeted user already holds high privileges in the cloud environment.

Inject a malicious application or service principal with high-privileged API permissions directly into the Microsoft Entra ID tenant

Why it fails: Injecting a malicious service principal provides robust API-level persistence independent of directory synchronization. However, it relies on cloud-side API access rather than leveraging the hybrid synchronization trust relationship specifically requested in the scenario involving DCSync privileges.

Refresh tokens lack cryptographic signatures and are immediately rejected by the token endpoint upon any modification

Why it fails: Refresh tokens are cryptographically signed JSON Web Tokens issued by the authorization server. While they cannot be modified without invalidating the signature, simply replaying an unmodified token does not fail due to signature absence, but rather due to conditional access and token binding validations.

Refresh tokens expire strictly after exactly fifteen minutes regardless of activity or sliding window configurations

Why it fails: Access tokens typically have a short lifetime of approximately one hour, whereas refresh tokens possess much longer lifespans, often lasting up to ninety days or until revoked, making them prime targets for persistence during penetration tests and adversary simulations.

Azure CLI securely encrypts refresh tokens using the local user's plaintext password, making offline decryption mandatory before replay

Why it fails: Azure CLI caches tokens in cleartext or using basic operating system credential stores such as DPAPI on Windows. Offline password decryption is not required to extract and attempt replay of these cached token files from the local filesystem.

Assign the Global Administrator role to a managed identity and then use that identity to perform actions.

Why it fails: Managed identities cannot be assigned Entra ID directory roles. They are service principals without directory role assignments. Application Administrator cannot assign roles to managed identities, and even if attempted, it would fail. This path is technically invalid for privilege escalation.

Use the Microsoft Entra Connect synchronization account to create a new user with Global Administrator privileges.

Why it fails: The Microsoft Entra Connect synchronization account is not typically accessible to an Application Administrator. Even if it were, the synchronization account has directory synchronization permissions, not the ability to assign directory roles. Creating a user with Global Administrator privileges would require role assignment permissions, which the sync account lacks.

Add a new credential to an existing application and use it to authenticate as a service principal with high privileges.

Why it fails: While Application Administrator can manage application credentials, adding a credential to an existing app does not directly grant Global Administrator privileges. The service principal's permissions are limited to those already granted to the application. Unless the application has highly privileged API permissions (e.g., Directory.ReadWrite.All) and the service principal is used to modify roles, this does not guarantee escalation.

Add new devices to the Microsoft Entra ID tenant.

Why it fails: Adding devices to the tenant requires permissions such as 'Device Registration' or specific roles like Cloud Device Administrator. The 'Microsoft Entra ID Joined Device Local Administrator' role does not include the ability to add new devices; it only grants local administrative rights on existing Microsoft Entra ID joined devices.

Reset passwords for other users in the organization.

Why it fails: The 'Microsoft Entra ID Joined Device Local Administrator' role does not grant permissions to reset passwords for other users. Password reset permissions are typically held by Helpdesk Administrator, Password Administrator, or User Administrator roles. This role is scoped to device management, not user account management.

Modify conditional access policies.

Why it fails: Conditional Access policies are managed by roles such as Conditional Access Administrator or Global Administrator. The 'Microsoft Entra ID Joined Device Local Administrator' role is limited to device-level administration and does not include permissions to modify tenant-wide policies, so this action is not possible.

Add a new credential to an existing application.

Why it fails: Adding a credential to an existing application requires sufficient privileges to modify that application. If you have those privileges, it can provide persistence, but the scenario does not guarantee you have such rights. Moreover, it may not be as stealthy as creating a new application. It is not the most reliable method here.

Use the refresh token to request a new access token.

Why it fails: Using the refresh token to request a new access token provides temporary access but does not guarantee persistence after a password change. Refresh tokens are invalidated when the user's password is changed, so this method will fail once the password is reset. It does not establish long-term persistence.

Create a new user account with Global Administrator role.

Why it fails: Creating a new user account with Global Administrator role requires privileges to create users and assign roles. If you have those privileges, it can provide persistence, but it is easily detectable and may be removed. It is not the most covert method and requires more permissions than the scenario implies.

Use Mimikatz with the command `sekurlsa::pth /user:user /domain:domain /ntlm:hash` to inject credentials.

Why it fails: Mimikatz sekurlsa::pth performs pass-the-hash to spawn a new process with the injected hash, but it does not directly request a Kerberos service ticket for a specific computer account. While it can be used for lateral movement, it is not the correct method to obtain the service ticket needed for Seamless SSO abuse, which requires a targeted request.

Use Impacket's GetUserSPNs.py to request a service ticket for the AZUREADSSOACC account.

Why it fails: GetUserSPNs.py is designed to find and request Kerberos service tickets for accounts with Service Principal Names (SPNs) set, typically for Kerberoasting. The AZUREADSSOACC account does not have an SPN, so this tool would not find it. Therefore, it cannot obtain the required service ticket for Seamless SSO abuse.

Use Rubeus with the command `Rubeus.exe tgtdeleg` to request a delegation ticket.

Why it fails: Rubeus tgtdeleg obtains a Ticket Granting Ticket (TGT) for the current user using delegation, not a service ticket for the Microsoft Entra Connect computer account. The Seamless SSO abuse requires a service ticket for the AZUREADSSOACC computer account, which this command does not provide. It is used for different attack paths such as Kerberoasting or delegation abuse.

The cloud userPrincipalName will be set to the user's on-premises userPrincipalName with the unverified domain.

Why it fails: Microsoft Entra ID does not allow userPrincipalNames with unverified domains. If the on-premises UPN uses an unverified domain, the cloud UPN cannot be set to that value. Therefore, this option is incorrect because it would result in an invalid configuration.

The cloud userPrincipalName will be set to a random string followed by the default domain.

Why it fails: Microsoft Entra Connect does not generate random UPNs. Instead, it uses the primary SMTP address or a placeholder. A random string is not used because it would be unpredictable and not aligned with user identity. This option misrepresents the actual behavior.

The synchronization will fail, and the user will not be created in Microsoft Entra ID.

Why it fails: Synchronization does not fail outright; instead, Microsoft Entra Connect handles the unverified domain by assigning a different UPN based on the primary SMTP address. The user object is still created in Microsoft Entra ID, but with a modified UPN. Therefore, this option is incorrect.

Golden Ticket attack using the KRBTGT hash.

Why it fails: A Golden Ticket attack requires the KRBTGT account hash to forge Kerberos TGTs, which grants access to on-premises resources, not directly to Entra ID. The scenario involves a user's password hash, not the KRBTGT hash, and the goal is to authenticate to Entra ID, not on-premises. Thus, this attack is not applicable.

Pass-the-Ticket attack using the user's Kerberos TGT.

Why it fails: Pass-the-Ticket involves using a stolen Kerberos ticket to authenticate, but it is specific to on-premises Active Directory environments and does not directly work against Entra ID, which uses different authentication protocols. The hash obtained is an NTLM hash, not a Kerberos ticket, so this attack is not applicable.

Kerberoasting attack to request a service ticket for the user.

Why it fails: Kerberoasting targets service accounts with Service Principal Names (SPNs) to obtain crackable service tickets. The user in question is a regular user without an SPN, and the hash obtained is a password hash, not a service ticket. Kerberoasting does not apply to this scenario and cannot be used to authenticate to Entra ID.

Exploit the user's ability to reset the password of a Global Administrator account through the Microsoft Entra Connect synchronization service.

Why it fails: The 'Microsoft Entra ID Joined Device Local Administrator' role does not grant password reset permissions for other users. Password resets for privileged accounts typically require higher roles like 'User Administrator' or 'Helpdesk Administrator', and even then, Global Administrators cannot reset each other's passwords without additional permissions. This method is not viable.

Abuse the user's membership in the 'Microsoft Entra ID Joined Device Local Administrator' role to add a new device to Entra ID and then use that device to request a Primary Refresh Token (PRT) for a Global Administrator.

Why it fails: The 'Microsoft Entra ID Joined Device Local Administrator' role allows managing local administrators on Microsoft Entra ID joined devices, but it does not grant the ability to add new devices to Entra ID or request PRTs for other users. Adding devices requires different permissions, such as the 'Cloud Device Administrator' role. Therefore, this method is not feasible for privilege escalation to Global Administrator.

Use the compromised user's credentials to authenticate to Microsoft Entra ID Graph API and modify the role assignment of the user to Global Administrator.

Why it fails: Modifying role assignments in Entra ID requires administrative permissions, such as the 'Privileged Role Administrator' or 'Global Administrator' role. A user with only the 'Microsoft Entra ID Joined Device Local Administrator' role does not have the necessary privileges to call the Graph API and change role assignments. Thus, this method would fail due to insufficient permissions.

Enumerate the authentication methods registered for the privileged user and attempt to answer their security questions by guessing common answers.

Why it fails: While SSPR may use security questions, Microsoft Entra ID no longer supports security questions as a standalone method for SSPR; it requires at least two methods, and security questions are not available for administrator accounts. Additionally, guessing security questions is unreliable and not a direct technical attack. This method is unlikely to succeed against a privileged user.

Use the compromised user's access to read the privileged user's registered authentication methods via Microsoft Graph, then attempt to reset the password by satisfying those methods.

Why it fails: A standard user cannot read another user's registered authentication methods unless they have been granted permissions such as 'UserAuthenticationMethod.Read.All'. By default, users can only read their own methods. Without these permissions, this method is not possible. Even with read access, satisfying the methods would require possessing the authentication factors, which the attacker does not have.

Leverage the compromised user's session to access the Microsoft Entra ID SSPR portal and attempt to reset the privileged user's password by answering their security questions.

Why it fails: The SSPR portal requires the user to authenticate as themselves to reset their own password. A standard user cannot reset another user's password via SSPR unless they are an administrator with password reset permissions. Security questions are not used for administrator accounts, and even for standard users, they would need to know the answers. This method is not feasible.

Use the compromised user's credentials to access the AD FS server and modify the claim rules to include a claim that grants administrative access in Microsoft Entra ID.

Why it fails: Modifying claim rules on the AD FS server requires administrative access to the server, which the compromised user account likely does not have. Even if the user had access, claim rules affect the claims issued in tokens, but they do not directly grant administrative access in Microsoft Entra ID unless the cloud is configured to trust those claims for role assignments. This is not a straightforward method.

Perform a pass-the-hash attack using the compromised user's NTLM hash to authenticate to the AD FS server, then request a SAML token for a privileged user.

Why it fails: Pass-the-hash can be used to authenticate to the AD FS server if the compromised user has administrative rights on it, but that does not allow requesting a SAML token for a different user. The AD FS server issues tokens based on the authenticated user's identity. To forge tokens for another user, the attacker would need the token-signing certificate, not just access to the server.

Modify the on-premises user's 'msDS-KeyCredentialLink' attribute to add a rogue key credential, then authenticate to Microsoft Entra ID using the corresponding private key.

Why it fails: The 'msDS-KeyCredentialLink' attribute is used for Windows Hello for Business and is not related to AD FS federated authentication. Modifying this attribute requires write permissions that a standard compromised user may not have. Even if modified, it would not allow forging SAML tokens for cloud authentication because Microsoft Entra ID in a federated setup relies on AD FS for authentication, not on key credentials.

The certificate is public knowledge and can be used to decrypt all cloud traffic.

Why it fails: The public portion of the token-signing certificate is used by the relying party to verify the digital signature of the incoming token, not to encrypt traffic. Decryption of TLS traffic requires the server's private key, which is distinct from the identity token signing keys.

AD FS requires the certificate to be stored in an unsecured plaintext file on the web server.

Why it fails: AD FS stores the token-signing private key within the Windows Certificate Store, specifically protected by the service account's permissions. It does not exist as a plaintext file accessible to web users, requiring elevated privileges or hardware security module (HSM) access to extract or manipulate.

The relying party cannot verify the identity if the certificate expires.

Why it fails: An expired certificate is a stability and operational availability issue rather than a primary security vulnerability. If the certificate expires, authentication will fail globally, leading to a denial-of-service condition for users, but it does not inherently provide an attacker with unauthorized access or privilege escalation.

The attacker can directly modify the Microsoft Entra ID tenant settings.

Why it fails: Compromising the SSO computer account does not grant administrative rights to the Microsoft Entra ID tenant. It specifically facilitates the generation of Kerberos tickets for authentication purposes. While dangerous for identity impersonation, it does not provide the direct privilege escalation required to change tenant-wide configuration settings.

The attacker can permanently disable synchronization between on-premises and cloud.

Why it fails: The SSO account is used for authentication, not synchronization. Disabling or tampering with the SSO account will break the single sign-on experience for users, but it does not disable the Microsoft Entra Connect synchronization engine, which runs under a separate, highly privileged service account.

All password hash synchronization processes will immediately cease.

Why it fails: Password hash synchronization is independent of the Seamless SSO feature. The sync process relies on the Microsoft Entra Connect synchronization service and its associated permissions. Compromising the SSO object does not interact with the PHS pipeline, meaning credential synchronization will continue functioning as intended.

Guest users are automatically granted Global Administrator privileges.

Why it fails: Guest users do not receive administrative privileges by default. They are assigned the 'Guest' role, which has restricted permissions. The risk arises from the default ability to enumerate directory objects, not from excessive administrative permissions being granted automatically upon the creation of the guest user.

Guest accounts can only be created by the Global Administrator.

Why it fails: Microsoft Entra ID allows for delegated invitation of guest users. By default, many users within the organization may have the ability to invite external guests. If this is not restricted, it leads to an unmanaged expansion of the identity footprint, creating visibility and security governance challenges for administrators.

Guest users are exempt from Conditional Access policies.

Why it fails: Conditional Access policies can and should be applied to guest users. Administrators have the option to include or exclude guest users from these policies. Failing to include them in security policies is a configuration choice, not a fundamental property of the guest user account type.