entra1-4  Exercise 3: Three Reports, Three Causes
=================================================

(a) "Fabrikam's nightly sync failed at 00:01 on 28 September and has failed every
    night since."
    Likely cause: An expired CREDENTIAL (a client secret or certificate used for
                  API access), since nobody is signed in and the failure began
                  at a specific moment and continues. In the exercise 2 register,
                  the Fabrikam directory sync secret expired on 28 September.
    Who acts:     Whoever holds the registration. In the client's tenant
                  (Chapter 2, arrangement B) that is their Entra administrator;
                  in yours (arrangement A), your team. Then your system's
                  configuration must be updated.
    Check first:  Certificates & secrets on the registration for the expiry date;
                  the sign-in logs (service principal sign-ins, Chapter 7) for the
                  failure at the first request; the error at the token request
                  (invalid_client is the documented category for invalid
                  client credentials).

(b) "On Monday Contoso's administrator renewed the SAML certificate. Since Monday
    afternoon nobody at Contoso can sign in."
    Likely cause: A CHANGED or MISMATCHED certificate, not an expiry. The new
                  certificate was probably made active in Entra but not given to
                  our system, so signature checks fail for everyone. (The reverse,
                  a new certificate in our system but not yet active in Entra, has
                  the same effect.)
    Who acts:     Both sides together. The client's administrator confirms which
                  certificate is Active (and its thumbprint); your team installs
                  the matching certificate. If you can read the federation
                  metadata, the current certificate is in it.
    Check first:  The status and thumbprint of each SAML certificate in the
                  client's portal, compared with the thumbprint your system
                  holds. Microsoft warns that if the application isn't updated
                  after a certificate is renewed, authentication may fail.
    Quick fix:    If the old certificate hasn't expired yet, the administrator may
                  be able to make it active again while the new one is installed
                  (confirm the exact steps with Chapter 8).

(c) "Our integration reads Dana's calendar. It stopped on Tuesday, the day IT
    reset Dana's password. Nobody else is affected."
    Likely cause: A REVOKED REFRESH TOKEN for Dana. The integration acts for her,
                  and Microsoft documents that an administrator password reset in
                  the Microsoft Entra admin center or the Microsoft 365 admin
                  center revokes refresh tokens issued to confidential clients.
                  (A reset in the Azure portal, a password change by Dana herself,
                  or self-service reset leave a confidential client's token alive,
                  per Microsoft's table, so ask how the reset was done.)
    Who acts:     Dana, who needs to authorise the integration again by signing in
                  to it. No secret or certificate needs renewing.
    Check first:  Whether only Dana is affected (yes), when and how her password
                  was reset, and the sign-in log entry showing the integration's
                  request being refused.

WHAT THE THREE HAVE IN COMMON
-----------------------------
Each started at an identifiable moment: an expiry date, an action on Monday, an
action on Tuesday. "When exactly did it start, and what happened just before?" is
the most valuable question you can ask.

WHY THIS WORKS AS AN ANSWER
---------------------------
It separates three different mechanisms (expiry, mismatch, revocation) that all
look like "stopped working", and attaches a different owner and a different first
check to each. The mismatch case is the one most often mistaken for an expiry.