I was working with some threat hunters from BlueVoyant who called out an oddity in our O365 SignInLogs. We had successful sign-ins from dozens of accounts where the AlternateSignInName field (Sign-in identifier field in the Azure AD sign-in log) contained a single account and that account was deleted months ago. Why would dozens of accounts have the same AlternateSignInName and how can that happen with an account that no longer exists? Do we have an incident? Yikes.
So what is this AlternateSignInName? How does it get populated? Is the account actually used for authentication? In short, what the heck is happening here?
Diving into Google results returned very little about how AlternateSignInName works. Microsoft has a reference for SignInLogs (https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/signinlogs) but it clarifies little. "The identification that the user provided to sign in. It may be the userPrincipalName but it's also populated when a user signs in using other identifiers." I also noticed it's usually blank in our logs. So how and why does AlternateSignInName get populated? I was hoping someone might have posted a question about it on Reddit or StackOverflow but no dice.
Here's a sample from Azure AD showing a login for my neutered username and a non-existent account for the Sign-in identifier (AlternateSignInName when it goes to Sentinel/Splunk).
Eventually we figured it out, at least for my organization. When you use Azure AD (Entra?) for authentication and have apps that use single sign-on, when you hit the initial login page it just asks for an e-mail address. That e-mail address is only being used to determine where to redirect your authentication request to. Then you go to your organization's sign in page and login. So it actually doesn't matter what account you type in as long as the domain is correct. It's this initial e-mail address that's getting stored in AlternateSignInName in the logs. Note that it hasn't been used for authentication.
Then it redirects to my company's Azure AD and you type in your real username and password.
Now you've authenticated with your real username and password. But in the logs your initially entered e-mail address is forever immortalized (as long as the retention period) in the AlternateSignInName in the SignInLogs. The e-mail address can be real/fake/disabled/deleted because it's not actually used for authentication, just the redirect to the correct authentication endpoint.
But one more mystery. Why did dozens of our users have the same AlternateSignInName?
In the cases I investigated, all the users signing in worked in the same department. We had a case where a shared computer was being used but an account had already been cached in the browser. So on the initial login page instead of an empty field to type in a new e-mail address users were seeing the page to the right. If you click the cached e-mail address, it takes you to the Azure AD login page. If you click "Use another account" then you have to type in your e-mail address, then get redirected to the Azure AD login page and type in your username/password. It's one less step to just click the cached entry and go straight to the Azure AD login page and that's what our efficient (lazy?) users were doing. In our case, the cached user had left the company months ago but the cached user still remained in the browser of the shared computer.
Thankfully, this was not an incident!
