Entra 智能體身分的待解問題及整套技術環境的執行方法

The first four parts covered the design, the Entra mechanics, the directory match and the surprises from the real tenant. This
final part is honest about what is still open, shows how to run the stack, and ends with the takeaways that would have saved us
the most time.

What is verified

Before the open items, here is what the real tenant has confirmed. The status is recorded in docs/design/real-entra.md, and the
claims below are the ones the end-to-end checks assert.

• O2 and O3, in the home tenant. A signed-in user's refresh token led to a T1 token with fmi_path, then an OBO exchange gave a Graph token with the right audience and scope. azp was the agent identity and oid was the user, and Graph accepted the token.
• O1, the B2B guest case. A home-tenant user signed in as a guest in a second tenant. That tenant's own blueprint and agent identity produced the token. The consent step needed the 65001 handling described in Part 4.
• The directory match. The Samba entry for the user agreed with the Entra token on every required field, and the drift tests caught each deliberate change.

What is still open

Two items are not settled, and we do not want the series to imply otherwise.

O6: MFA trust across tenants

The question is whether a guest's MFA done in the home tenant is trusted by the second tenant, or whether the guest is challenged
again. The answer decides how often a user is prompted when an agent works across tenants.

We have not verified it. The second tenant had no Conditional Access policy, so there was no MFA requirement to trust or
ignore. Testing O6 needs a Conditional Access policy in the second tenant that requires MFA, and a sign-in from a guest. Until then
the answer is unknown, and the design treats the guest's MFA as the tenant's own decision.

Preview status of Agent ID

Agent ID is partly in preview. Microsoft's pages describe the blueprint and agent identity objects in more than one way, and in
places they disagree about which endpoint or header is required. We pinned the behaviour we saw in the real tenant rather than the
wording of any one page. When Microsoft changes the surface, the provisioning script is the first thing to revisit, and its
requests are written out explicitly so a diff shows what changed.

Running the stack locally

The stack runs in Docker Compose. Everything runs on your machine, with the mock Entra, unless you choose the real tenant.

cd compose
make up            # PingFederate, Vault, OpenFGA, the TLS proxy, the broker, the mock Entra and the sample API
make ad-up         # adds the Samba domain controller (profile ad)
make ad-sync TARGET=mock   # seeds the mock directory from the Samba users
make test          # smoke, end-to-end, and the directory checks

make test includes e2e/ad.mjs, which signs in through PingFederate, reads the kept claims, compares them with Samba and runs
the drift scenarios. A green run means the whole chain works against the mock.

Two small notes from running it repeatedly:

• Run make up before make ad-up. The directory's certificate comes from the same local CA, and the TLS init must have run.
• Do not run docker compose down -v casually. It deletes the volumes, including the Vault and OpenFGA data. We did this once by accident and had to rebuild those services.

Running it against a real tenant

The real tenant path is documented in docs/design/real-entra.md. Read it first, because it creates objects in your Entra tenant.
The order matters:

cd compose
make real-plan     # read-only: shows what Terraform would create
make real-apply    # creates the apps, the blueprint, the agent identities
make real-login    # signs in as a user, through the broker
make real-verify   # runs the T1 and OBO chain for each agent and calls Graph
make real-cae      # the revocation measurement described in Part 4
make ad-sync TARGET=real SYNC_ARGS=--dry-run   # preview the cloud users
make ad-sync TARGET=real                       # create or update them
make ad-verify     # compare each synced user with its directory entry

Two cautions from our own runs. First, make sure the az login points at the tenant you intend. We had an isolated Azure CLI
profile in one shell and the default profile in another, and they were signed in to different tenants. az account show before
any real step prevents surprises. Second, the teardown is separate: make real-destroy removes the agent objects, but it does not
remove the emulated cloud users or the extension properties on the RP app. Those need their own cleanup, which we have not written
yet.

Troubleshooting by symptom

Takeaways

These are the lessons we would give to anyone starting the same work.

• Put the token exchange behind one endpoint. An agent should ask for a resource by its URI and never construct an Entra scope. The resource map is the policy, and it lives in one file.
• Keep refresh tokens in a vault and hand out only handles. The agent's copy of a credential is the one most likely to leak.
• Prefer proxy mode. Every call through the broker is an audit point. Token mode is a deliberate exception for a resource that really needs it.
• Use objectGUID as the link. It survives renames, and every other field can be checked against it.
• Test against the real service early. The mock hid the propagation delays, the identifier formats, the resolver order and the consent flow. Each one cost us a debugging session that a single real run would have exposed sooner.
• State the limits. Revocation does not end a token already issued, MFA across tenants is unverified, and the emulated directory is not Entra Connect. Each limit is in the design, and saying it plainly is cheaper than discovering it in production.

The code, the design notes and the runbook are in the repository. Pull requests are welcome, especially for the open O6 item: a
second tenant with a Conditional Access policy that requires MFA would settle it.