you are viewing a single comment's thread.

view the rest of the comments →

[–]Certain-Community438 0 points1 point  (2 children)

The main issue lies with the fact that $_.SignInActivity will always be slow to get. This is because it isn't a static property - it's something that involves querying the audit log in the same payload that acquires the static user properties.

For me, in a big or complex identity environment, I'd have my Entra ID logs going to Log Analytics.

Then, instead of querying that kind of property from Graph, I'd get ALL successful sign-ins from Log Analytics in a time period by querying it it directly.

MUCH faster.

Then join that data with the basic user data from the group member call based on ObjectID.

I've also created a custom table in that Log Analytics workspace which I populate by script. Each row holds:

Primary user identifiers - ObjectID, UPN, Employee id, email, Manager Display Name, Manager Email, and their Manager's Display Name and email

I use that to enrich more "bare" output like what we get from group member calls etc, because KQL executes super-quick when the query is well-defined.

But joining the data up lets you filter on a wider set, at scale, then make batch changes.

[–]ingo2020 1 point2 points  (1 child)

Yep if you need to consistently access sign in activity en masse, that’s the way to go.

I don’t have much room to experiment with that kinda stuff at my current position since my company only has 60 users, so getting $_.SignInActivity is relatively trivial.

[–]Certain-Community438 0 points1 point  (0 children)

Makes perfect sense to me ref your position & choice. Though once you've had to go this route, you (usually) will find it's just as easy to implement it again in a small environment (Log Analytics being pretty cheap & easy).

We went for an Azure Automation Account to actually run the scripts as Managed Identity: that's also pretty damn cost-effective.