Entra ID: Finding your inactive users

This article will highlight the extended evaluations that I perform against users and guests in order to clean up stale accounts in Entra ID.

This article mainly contains my thought process and some tips for cleaning up Entra ID. However in the future I want to create something fully automated that can help all Entra ID admins clear out stale accounts. This article is just a first step in that direction.

Inactive users pose a major threat to companies. Both member users and guest users often lie around with just passwords, awaiting a first login to initiate MFA registration. And when the first user login is malicious, the attacker can just claim the MFA registration for themselves and bobs-your-uncle, they are in.

There are great compensating controls like “Securing registration locations” in Conditional Access, “Temporary Access Pass” and manually populating phone numbers as an MFA method prior to login. But for the customers we have worked with, these controls are rarely implemented…

Target Audience

The target audience for this article are companies that dont really have a single master system for employee information. Maybe Entra ID is your master system, or maybe you have 5 different HR systems that are not friends and none of them are accurate.

If everything is hard, and you really just want to do some housekeeping, this is the process and variables that we have used for clearing out some stale user accounts.

Note: For now, this is a manual process. I will update this post with links to my automated solution once it is up and running.

High level process for Inactive User evaluation

1. Last Interactive and Non-Interactive Sign-ins
2. Exclusions; Recently created users and Fracture accounts
3. Check users for automatic Mail Forwarding in Exchange Online
4. Disable Users that are SharedMailbox
5. Find inactivity for users with only Failed Sign-ins

1. Last Interactive and Non-Interactive Sign-ins

These fields are populated by, you guessed it, last interactive sign-ins and last non-interactive sign-ins and are visible per user.

Microsoft started populating these fields around 2018/2019 or so if i am not mistaken? So anything before then is going to be blank.

In essence, an interactive sign-in is a sign-in where the user actually presents, for example, a password and does an action to enter the account. On the other hand, a non-interactive sign-in is where the application does a passive check-in to stay signed in to Entra ID.

If the fields are blank, this often means that the user has never logged into the account.

We can utilize PowerShell scripts using MgGraph to programatically get and sort this data into an Excel sheet or CSV file and programatically “Disable” or “Delete” these users.

AdminDroid has provided a fantastic script for free on their blog that helps to get and list/delete/deactivate these inactive users based on this information. See their blog for guidance on how to run it! And always read scripts before running them on your machine.

2. Exclusions: Recently created users and Fracture accounts

There are many functions in the AdminDroid script to clean out stale users, however it seems to not evaluate some key variables such as “Created Date” for accounts that were created in the last two weeks or “fracture” accounts that are for emergency access, that rarely log in in order to stay “active”.

In order to exclude these you would need to prepare a list of account “UserPrincipalName”s to exclude from this evaluation and build in some exclude functionality if using the script above.

3. Check users for automatic Mail Forwarding in Exchange Online

When users set up automatic mail forwarding, alarms should go off in general. However, we have seen some implementations of this at our customers, so I chose to include this as a factor.

To list Mail Forwarding rules you can either go to Exchange Admin Center -> Reports -> Mail Flow -> “Auto forwarded messages report”

Or do it programatically (see this blog from Ali Tajran).

Evaluate the forwarding rules for the users and remove the rules if possible. Mail auto forwarding is not a good idea in general. If the account gets disabled, auto forwarding will stop. But if some rules have to stay – the account will need to stay active and licensed.

Add the account to an exclude list to not auto-disable it in the future, and if relevant change the user accounts password to a long string (64 characters+) so that it can stay secure while active and “not in use”.

4. Disable Users that are SharedMailbox

When you create a “SharedMailbox” in Exchange Online this also creates an Account with a random generated secret password and is Enabled in Entra ID. The Shared Mailbox itself will still work if the Entra ID account is disabled.

So why is it Enabled by default when created?

……. I dont know. No one knows. Just Disable it. It’s good for the MFA stats.

You can list all users by mailbox types in the Exchange Admin Center.

5. Find inactivity for users with only Failed Sign-ins (Experimental)

This one is a bit clunky and still under development…

When an external user is invited to your organisation to collaborate in Microsoft Teams we have experienced that the Teams connection can end up stuck in a failed login loop, constantly spamming our Entra ID with Failed logins against the Teams application as a non-interactive sign-in.

This will keep renewing the “Non-interactive” sign-in field even though the sign-ins are failed or interrupted, creating a false notion that the account might be active.

I started creating a script that would get all the non-interactive sign-ins from these users and check if they only fail against the Teams app so that I could clean them out. However, by default Entra ID only carries 30 days of these logs so for now it has been of little use to me as 30 days is a short timespan to judge inactivity for some customers.

Even though this is only a tiny bit useful, i’ll add the script I created to get some of this data. It does take a while to run since it has to get quite a lot of login events due to limitations the API query opportunities.

View the script on my Github here!

Or maybe I am just bad at APIs. You decide!

Conclusion

Clearing out old users in Entra ID is essential now that brute-force attacks are at an all time high. We are even struggling with the MFA App being bypassed by AiTM attacks, so getting the basics right is an absolute necessity. User Lifecycle is a critical element of secure identities and secure identities should not be a licensed feature. I rarely see anyone managing to keep stale users in check manually.

Many organisations struggle with user lifecycle for different reasons, and the built in functionality for user cleanup in Entra ID has been licensed out of our hands. Luckily PowerShell and APIs are free!

Future work

In the future I hope to contribute to making user lifecycle, especially for stale accounts in Entra ID as painless as possible for the every day IT administrator through automation.

I want to create a recurring task using modern authentication, modern APIs and a DevOps Pipeline to deliver the following functionality:

1. Exclusion list for chosen accounts
2. Automatic disabling/deletion of stale accounts
   • Based on all/most of the variables discussed above
   • Variables for
     • “Created After”
     • “Days inactive before disable”
     • “Days inactive before delete”
3. Reporting of disabled accounts
   • Rollback opportunity
4. Multi-tenant possibilities from a single DevOps instance
5. Terraform deployable for simple implementation

The work on this project har already started, but it might take a while before it is actually realised and published for all to use.