entra1-10  Exercise 2: Personalising the Runbook
=========================================================

Source: Course chapters 1, 2, 5 and 8. This answer is an example for the
fictional "Acme Support Desk"; your real answers will differ.

ANSWERS TO THE FOUR OPEN QUESTIONS (Acme Support Desk)
  1. Integration types: OpenID Connect sign-in (user login) and SAML SSO for
     larger clients. Both use the same multitenant application.
  2. Arrangement: A (our multitenant app registered in our tenant); each
     client has an enterprise application (service principal) in their
     tenant. SAML clients also have a client-side signing certificate (C).
  3. Access to a client's tenant: none by default; the client's administrator
     shares their screen. Occasionally a Reports Reader role for a day.
  4. "Validate the connection": inside our product's admin page (it checks the
     redirect URI, tests a token request and for SAML checks the certificate),
     not in Microsoft's portal.

EDITED RUNBOOK STEPS

  Step 2 IDENTIFY
    Original: Tenant card: client, tenant ID, app (client) ID, arrangement,
              pattern.
    Edited:   Tenant card for the client: client name, tenant ID, our (single)
              application (client) ID, pattern (OIDC or SAML), who their
              Entra administrator is, whether they have P1/P2 (log retention),
              whether SAML notification addresses are set and verified.
              Arrangement is always A for OIDC and C for SAML, so record only
              the pattern.

  Step 5 INSPECT
    Original: Right tenant? Enterprise app: Enabled? Assignment required?...
    Edited:   WE CAN inspect our own side: our registration in our tenant
              (client ID, redirect URIs, secrets, permissions requested) and our
              product's stored credential/certificate and logs.
              WE MUST ASK the client's administrator (screen share) to open:
              Enterprise apps > Acme Support Desk > Properties (Enabled?
              Assignment required?), Users and groups, Permissions (granted?),
              and for SAML the SAML Certificates page (expiry, active/inactive).
              And Sign-in logs filtered by our application ID.

  Step 7 FIX
    Original: Credential: create new, install, prove, remove old...
    Edited:   OIDC: credentials are OURS (arrangement A). Rotate in our tenant:
              new secret/certificate, install in our deployment, prove with a
              sign-in, then remove the old one. The client does nothing.
              SAML: the client's administrator creates the new signing
              certificate (Inactive), we upload it, they Make certificate
              active, a test user signs in. Consent, assignment, and policies:
              the client's administrator or security team changes them.

WHY THIS WORKS AS AN ANSWER
---
Answering the four questions turns a generic playbook into one that says who
does each step in your real arrangement.