AZ-120 · Question #353
Drag and Drop Question Your on-premises network contains an Active Directory Domain Services (AD DS) domain that syncs with a Microsoft Entra tenant by using Microsoft Entra Connect. You plan to…
The correct answer is An Enterprise Application (EA) in Microsoft Entra ID; Kerberos. Explanation: SAP NetWeaver + SAP Cloud Identity Services Authentication The Scenario You have AD DS synced to Microsoft Entra via Entra Connect. You need to authenticate users to two targets: SAP NetWeaver (on-premises) SAP Cloud Identity Services (cloud) The correct solution…
Question
Exhibit
Answer Area
Drag items
Correct arrangement
- An Enterprise Application (EA) in Microsoft Entra ID
- Kerberos
Explanation
Explanation: SAP NetWeaver + SAP Cloud Identity Services Authentication
The Scenario
You have AD DS synced to Microsoft Entra via Entra Connect. You need to authenticate users to two targets:
- SAP NetWeaver (on-premises)
- SAP Cloud Identity Services (cloud)
The correct solution maps one component to each target:
Placement 1: Enterprise Application (EA) in Microsoft Entra ID → SAP Cloud Identity Services
Why: SAP Cloud Identity Services federates with external identity providers via SAML or OIDC. Registering it as an Enterprise Application in Entra ID makes Entra the Identity Provider (IdP) for SAP Cloud Identity Services. This gives you:
- AD DS credentials: Since Entra Connect syncs AD DS users to Entra, users authenticate with their domain credentials.
- MFA enforcement: Conditional Access policies on the EA enforce MFA centrally - no per-app MFA configuration needed.
- Minimal admin effort: One EA registration covers all SAP Cloud Identity Services-connected apps.
Placement 2: Kerberos → SAP NetWeaver (on-premises)
Why: SAP NetWeaver supports Kerberos-based SSO via SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism). Since NetWeaver is on-premises and AD DS is the domain authority, Kerberos is the native protocol - users get SSO using their Windows session ticket without re-entering credentials.
Why the Other Items Are Wrong
| Item | Why it's excluded |
|---|---|
| Microsoft Entra Application Proxy | Used to publish on-premises apps externally - it's a network access component, not an authentication protocol. Kerberos handles the auth; Application Proxy is an optional layer for remote access, not required here. |
| LDAP | LDAP binds can query AD DS but do not natively support MFA. Using LDAP for authentication increases admin overhead and fails the MFA requirement. |
Common Misconceptions
- "Application Proxy should handle NetWeaver" - Application Proxy works alongside Kerberos (via Kerberos Constrained Delegation) for remote access scenarios, but the authentication mechanism itself is still Kerberos. The question asks what to include, and Kerberos is the direct answer.
- "LDAP is just as good as Kerberos for AD auth" - LDAP is a directory protocol; Kerberos is the proper AD authentication protocol. They are not interchangeable in this context.
- "MFA needs a separate tool" - MFA is built into the EA + Conditional Access flow in Entra, so no additional component is required.
Topics
Community Discussion
No community discussion yet for this question.