entra1-5 Exercise 2: Inspect Fabrikam's Screenshot (today: 2026-10-01) ======================================================================= THE FIVE-MINUTE INSPECTION, APPLIED ----------------------------------- 1. Right tenant? The tenant ID is 11111111-... which matches Fabrikam's tenant in the earlier exercises. OK. 2. Both objects? Both pages exist and the Application ID in the enterprise app (22222222-...) matches the Client ID in your system. OK. 3. Properties: "Enabled for users to sign in?" is Yes (so tokens can be issued). "Assignment required?" is Yes: see problem 3 below. 4. Credentials: The "prod 2025" secret expired on 2026-09-28. See problem 1. 5. Config vs system: Redirect URI mismatch (trailing slash). See problem 2. PROBLEMS, RANKED ---------------- 1. The secret your system uses has expired. "prod 2025" expired on 28 September, and your system's "Client secret in use" is "prod 2025". Every Fabrikam user would be refused at the token step (Chapter 3, step 4), after a successful Microsoft sign-in, with the invalid client credentials error. This fits "nobody at Fabrikam can sign in". 2. The redirect URI doesn't match exactly. Entra has https://app.acme.example/auth/callback/ (with a trailing slash) while your system sends https://app.acme.example/auth/callback (without). Microsoft says the redirect URI in the request must exactly match a registered one. If this is really the case it would stop EVERY sign-in at step 1, before the secret is even used. Since the integration presumably worked before, ask what changed: someone may have edited the registration recently. This could be a second, independent cause, or the cause itself. HOW TO TELL 1 FROM 2: with 1, users get all the way through the Microsoft sign-in and fail when they come back to your site. With 2, Microsoft shows an error page BEFORE or INSTEAD of the sign-in. The sign-in logs and the exact error message settle it (Chapter 7). 3. Assignment required = Yes, but only "Support Staff" is assigned. The affected users are in "Sales", who aren't assigned, so they'd be refused at the sign-in step even if everything else were fixed. This explains "some users", not "everyone", but it will surface as soon as problems 1 and 2 are fixed. (Global Administrators would still get in, which can make the problem look inconsistent.) 4. Ownership gap. Notes say it was set up by someone who has left the company. Check the Owners page. If nobody owns the application, nobody was likely to notice an expiring secret or maintain assignments. This isn't the immediate cause but it's why it happened. 5. A "test" secret is on a production application. It expires on 2027-02-01. It could be a stopgap in an emergency, but a test credential in production is worth asking about, and it will expire too. WHAT NOT TO DO -------------- Don't change the redirect URI, assignments or secrets during the inspection. First get the exact error and the sign-in log entry. Then plan the fix: a new secret created, your system updated, then tested (Chapter 8), assignments agreed with the client. WHY THIS WORKS AS AN ANSWER --------------------------- It finds several independent problems in one small screenshot, ranks them by whether they explain "everyone", and shows how to tell the two top causes apart with evidence before changing anything. The ownership problem explains why it was missed.