Fun can take many different forms of course, and this one is a little more geeky in nature but is also tied into my theme of recent security focused posts. Not long ago, I had a customer tell me they had been hacked as a student had revealed to them how they could connect to AzureAD and generate a list of student names and email addresses from the directory.
I reviewed the information provided and then checked out if I could replicate this in my test environment – sure enough I could. By opening a PowerShell window as administrator and running a basic command I could reveal information from AzureAD:

Now, it’s worth pointing out that the student still had to authenticate as themselves to run the above request and it’s showing information in a “read only” format. However, aside from the ObjectID revealed, the other information such as DisplayName or UserPrincipalName can actually be obtained through the “front end” user interface of Outlook. In the screenshot below I show this in Outlook Web App by looking through the Global Address List:

So, was the customer “hacked”? No, not really. If anything, this was a configuration issue that needed to be corrected to tighten their security posture. Few customers are going to want to allow a student using some PowerShell to export in bulk student information and so the ability to turn this off is always desirable. The good news, there is an easy way to do this.
How To: Blocking PowerShell Access For Education Tenants
There is some easy to follow documentation here that provides a number of different ways to block access via PowerShell to the M365 tenant and I encourage you to check it out. A likely specific scenario is to want to block PowerShell access to all users aside from a specified list of admins – direct link to how to do this is here.
A direct link to GitHub with all the exemplar PowerShell scripts is here and you can see there are a number of different scenarios catered for:

You can see there is a range of options there to block non-authorised users from accessing PowerShell, Graph and Intune PowerShell scripts – I encourage you to evaluate if taking this action to restrict access to these services makes sense in your context.
One last thing – I mentioned above that the student in question would have had to authenticate via PowerShell with their student credentials to get access to the AzureAD directory listing of students and groups. This, of course, is logged so you could check if this has already happened in your tenant.
Audit Attempts: Using Sign-in Logs in Azure Active Directory
You’d need to be either a Global Admin or AzureAD Admin to access these logs (direct link is here) and they look as follows:

There is a lot of information there, so if you wanted to filter just for PowerShell access you could:
Click “Add filters” and then choose “Application” followed by “Apply”:

Type “PowerShell” and you’ll notice a green tick shows to the right indicating there is a match – click apply:

In my tenant, I have two authentications matching showing user, date/time and more detail as required:

Clicking on one of the matching records shows additional relevant information:

As you can see, it’s very easy to determine if a user has connected to AzureAD using PowerShell and this might be the first thing you check before determining whether further restrictions are required using the PowerShell exemplar scripts above.
Happy Friday!
You certainly do not need global admin to see signin logs.
https://docs.microsoft.com/en-us/azure/active-directory/roles/delegate-by-task#monitoring—sign-ins