The login provider can emit event log entries which say who logged in and when, and reasons for login failure etc.
Those entries aren't plain text - they are protobufs decoded by a google-provided dll file. If event viewer is open, it won't load that dll, and it will fail to render any event log entries for logins until it is restarted.
A previous debugging hole I fell into once accidentally and barely managed to escape left me with the impression that every event has a "custom" decoder associated; there's no "built-in" event types from the Event Viewer's perspective. There are a handful of very common "custom decoders" that when they break it is an interesting world of madness. In the case of my debugging, one of the decoders installed by the .NET Framework (and used by almost all apps that use the main .NET Event Log libraries) broke and needed repair. It seems like there is a bunch of power in building custom decoders, but I never want to try debugging one again.
Feels like a gentle reminder about corp.com. If some configuration works out of the box in an insecure way, that's what everybody is going to be using.
To help ensure unauthorized access to the device, you need to configure a registry key to restrict device sign-ins to accounts in specific domains.