Author Archives: Joe Stocker

Pre-registering MFA in M365

This article describes how to make the user onboarding experience into MFA as smooth as possible by pre-registering MFA methods.

Disclaimer: This article only applies to organizations that have decided to use Phone Number for verification. This is not recommended but in some organizations, they are unable to avoid this for a variety of reasons. If you want to learn why phone number verification is weak, check out the Microsoft Article: https://techcommunity.microsoft.com/t5/azure-active-directory-identity/it-s-time-to-hang-up-on-phone-transports-for-authentication/ba-p/1751752

The most ideal scenario would be to deploy Passwordless MFA, such as Windows Hello for Business, Authenticator App, FIDO2 Keys, or Certificate (Preview). You might issue a Temporary Access Pass to allow users to register passwordless methods without knowing the password to the account.

For more information on planning a passwordless deployment, click here: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-passwordless-deployment

Ever wonder what is required to pre-register a user for Phone or Email?

The “Authentication Methods” page displayed in Portal.Azure.com > Azure Active Directory > Users, allows you to pre-define the phone number that would be used for MFA.

image

If you use Always ON MFA, then you can set the user to Enforced. This can be automated with a GUI or PowerShell, or the preferred method would be to use a Conditional Access Policy (if you have Azure AD P1 or EMS E3 or M365 E3).

image

Their very first sign-in experience would be:

image

Otherwise, if you only populate the Mobile Phone field (such as in on-premises Active Directory, and then it synchronizes to Azure AD) then the user’s first sign-in experience will be to verify that the number shown is correct.

image

image

To populate the mobile phone using PowerShell, you can use PowerShell as described here: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-sspr-authenticationdata

But if you want to populate the Authentication Phone Number (so that the user can skip the registration page) then the PowerShell gets a little bit more involved.

Method 1 – Using PowerShell version 1 as described here: bulk Pre-registration for Azure MFA for more Seamless Single Sign on and smooth for MFA roll out – Microsoft Tech Community

Method 2 – Using MS Graph as described here: Pre-configure Authentication Methods for end users in Azure AD – Identity Man (identity-man.eu)

At this point I would strongly encourage you to enable number matching notifications and then enable the registration campaign.

Note: After September 30th 2022, the Combined Registration feature will be enabled in all tenants worldwide. This means that if you are using Self Service Password Reset, then the registration experience for users will be combined.
Therefore, instead of waiting until September, I would enable that feature now so that you can update your end-user facing documentation and user communications once rather than twice.
Learn more about Combined Registration here: Combined registration for SSPR and Azure AD Multi-Factor Authentication – Azure Active Directory | Microsoft Docs

Lapsus$ gains access to OKTA and Microsoft

Today (3/22/2022) both OKTA and Microsoft released statements about a threat actor named LAPSUS$ (Microsoft tracks as DEV-0537) who gained access to both organizations. In the last 90 days, this same threat actor has claimed victims including Impresa, NVIDIA, Samsung, Mercado Libre, Vodafone, and most recently Ubisoft.

In the case of Microsoft, the attack appears to be limited to portions of source code related to Microsoft’s Bing, Bing Maps, and Cortana.

“This week, the actor made public claims that they had gained access to Microsoft and exfiltrated portions of source code. No customer code or data was involved in the observed activities. Our investigation has found a single account had been compromised, granting limited access. Our cybersecurity response teams quickly engaged to remediate the compromised account and prevent further activity. Microsoft does not rely on the secrecy of code as a security measure and viewing source code does not lead to elevation of risk. The tactics DEV-0537 used in this intrusion reflect the tactics and techniques discussed in this blog. Our team was already investigating the compromised account based on threat intelligence when the actor publicly disclosed their intrusion. This public disclosure escalated our action allowing our team to intervene and interrupt the actor mid-operation, limiting broader impact.”

I recommend reading Microsoft’s write-up on this incident as it gives a detailed glimpse at the threat actor’s TTPs. For example, the threat actor is paying employees to gain access to victim networks.

However, in the case of OKTA, it appears the attack was more substantial based upon the 8 screen shots that LAPSUS$ made public (here).

The original official statement from OKTA seems to contradict what the hacking group is claiming.

“In January 2022, Okta detected an unsuccessful attempt to compromise the account of a customer support engineer working for a third-party provide”

https://sec.okta.com/articles/2022/03/official-okta-statement-lapsus-claims

The laptop of a support engineer appears to have been compromised. The attacker would have the ability to reset passwords and Multi Factor Authentication for users.

Then Zack Whittaker reported that OKTA reported 366 corporate customers were impacted.

https://techcrunch.com/2022/03/23/okta-breach-sykes-sitel/

Brian Krebs reported that the ringleader of LAPSUS may be a 17-year-old from the city of London, England, who goes by the handle WhiteDoxbin with a net work of $14 million (300 BTC).

https://krebsonsecurity.com/2022/03/a-closer-look-at-the-lapsus-data-extortion-group/

The BBC is quoting that seven people between the ages of 16 to 21 have been arrested.

OKTA Recommendations

1. If you are an OKTA customer, active Incident Response Plans, assume compromise happened between January 16 to 21

2. Collect and retain related logs. Okta System Logs are only available for a limited time (90 days) so you should download those immediately.

3. Hunt for evidence of suspicious password resets or changes to MFA on or around 1/16 to 1/21

4. Rotate Okta privileged passwords.

5. Look at the Okta Admin Console app in particular

legacyEventType eq “app.generic.provision.assign_user_to_app”

the “app.generic.provision” event type

and to identify any users granted access to other apps.

Another event worth checking on is “security.threat.configuration.update” to see any changes to Okta’s behavioral threat detection.

SIEM rules

https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/okta

https://github.com/elastic/detection-rules/tree/main/rules/integrations/okta

PowerPoint Rehearse with Coach

Today I discovered a PowerPoint feature called Rehearse with Coach.

Since I do lot of customer facing presentations, I thought I would give this a try and see what this feature is all about.

You can find it inside PowerPoint’s Slide Show Menu.

image

After clicking Record, then just talk to yourself a bit as if you were presenting to an audience. When you are done it will give you several tips for improvement, or in my case, validate that I am nailing it! j/k

image

– Pace is VERY important! 130 words per minute is just about right. Too fast, people can’t follow you. Too slow, then you’re boring!

– Fillers. This is something I struggle with a LOT. I often will use filler words like “ummmm” or “you know” without even thinking about it!

– Repetitive Language. I used to work with an employee who would say the phrase “business outcome” in every other sentence. It started to lose meaning because not everything has a business outcome!

– Inclusiveness. I sometimes catch myself saying “You Guys!”  This is a bad habit I am still trying to break and I look forward to improving in this area.image

– Pitch! Avoid being monotone! As you can see the longer I spoke, the more I drifted to the dreaded monotone!

– Originality.  Don’t just read the text on the slide, but instead use this as a guide for story telling!

Pretty cool stuff. I really appreciate how Microsoft continuously adds cool features like this into PowerPoint and other Office products.

Availability: Microsoft Apps for Enterprise Version 2012 (January 5 2021) https://docs.microsoft.com/en-us/officeupdates/current-channel#version-2012-january-05

More Information https://support.microsoft.com/en-us/office/rehearse-your-slide-show-with-presenter-coach-cd7fc941-5c3b-498c-a225-83ef3f64f07b

How to use Intune Device Enrollment Restrictions to block “Second Wave Phishing”

Microsoft recently published an article (here) describing a new phishing attack where attackers will attempt to bypass Azure AD Conditional Access Policies configured for ‘Require Compliant Device.”

image

When an attacker obtains the 1st factor credentials (username and password) they will be greeted by a warning message that informs them that they cannot sign-in due to a conditional access policy. But here is the irony,  the warning message informs the hacker exactly how to bypass the block, step by step! (To be fair, the warning message was designed to help users enroll their devices.. but still.. in this day and age, we don’t need to be giving novice hackers free advice on how to bypass our security controls!)

image

So after the attacker realizes that Conditional Access has been configured to require Intune Compliance, now all the hacker has to do is find a device to enroll into Intune. The attack consists of a hacker logging into a virtual machine they control somewhere, and then they Azure AD Join it to the target organization (with MDM Auto Enrollment), or Azure AD Register with Device Management (Intune) because they have obtained the username and password of the user. Perhaps the user had MFA enabled on their account, but the user has  accidentally authorized the attacker to logon via MFA Push Notification or Phone Call (this happens a lot actually, so you should switch users to Code Match, or wait for Microsoft to roll it out which is coming soon).

It’s worth noting that the way the article was originally written, it made it seem like the registration or Azure AD join itself would be a security concern, but it is not, because as soon as you reset the password of the user, then the primary refresh token is invalidated. Applications with Continuous Access Evaluation will be revoked within 15 minutes (at most) and legacy apps may take up to 60 minutes. You can also create an Azure AD Conditional Access Session policy to limit session lifetime too.

The other issue I had with the article is that it said the problem happens when MFA is not enabled for Device Registration or Azure AD Join. While this can help reduce the risk of it happening, it doesn’t prevent it. There is a better setting in my opinion that does a better job of preventing it which is blocking device registration of personal devices into Intune.

Endpoint.Microsoft.com > Devices > Enroll Devices > Enrollment Device Platform Restrictions

image

This is a setting that you can apply to All Devices, All Users, or you can scope to selected groups (devices or users). It will prevent the hacker from joining a device to Azure AD and then becoming auto-enrolled. The setting is called Enrollment Restrictions and you set it to block personally owned devices from enrolling into Intune (Ideally you would do this for all device types, not just Windows). This is what I recommend unless you have not yet configured Autopilot or other methods of enrolling devices into Intune. Otherwise, then you must follow the recommendation from the Microsoft article which is to require MFA for enrollment https://portal.azure.com/#blade/Microsoft_AAD_Devices/DevicesMenuBlade/DeviceSettings/menuId/

image

In my opinion, blocking personal device enrollment into Intune is by far the most secure way to go because it really cuts at the heart of what the attacker is trying to do which is to bypass the CA Policy that requires Intune Compliance. Remember: A rogue device that is AAD Registered or AAD Joined is not a threat to your organization, it’s better to think of it as an extension of the user’s identity that enables that user to achieve SSO. When there is no network transport to the internal network (no VPN) then it’s equally fragile to a password reset of the user’s credentials. Think of it this way: without Intune enrollment, these other device states cannot move laterally into the target network to perform the ‘second wave phishing campaign’ described in the Microsoft article. Or to be more verbose, since a Conditional Access Policy Grant Control cannot factor Registered Device or AAD Join device status, it can only filter based on Intune Compliance or Hybrid Domain Join.

The second option is to limit MDM auto enrollment is to scope specific groups rather than ALL users.

image

I don’t recommend this because it will have unintended side effects for things like Windows 365 or Autopilot.

What is Device Identity

One of the most confusing things about all of this is what is Device Identity in Azure AD?

Registered
Devices that are Azure AD registered are typically personally owned or mobile devices and are signed in with a personal Microsoft account or another local account.

Azure AD Joined
Devices that are Azure AD joined are usually owned by an organization and are signed in with an Azure AD account belonging to that organization. They exist only in the cloud. By default, nothing would prevent a user from being able to Join their personal machine in this manner (and that is why I believe Enrollment Restrictions to block “Personal Devices” are important to consider, as it would block people from Azure AD Joining their devices).

Hybrid Joined
Devices that are hybrid Azure AD joined are owned by an organization and are signed in with an on-premises Active Directory Domain user account belonging to that organization. This account is then in an OU that is synced to the Cloud, and Conditional Access Policies can then use this to device state as a Grant Control.

References:https://docs.microsoft.com/en-us/azure/active-directory/devices/overview#getting-devices-in-azure-ad 

See also https://o365blog.com/post/devices/

What prevents a rogue user from categorizing their personal device as corporate owned to bypass policy?

Or what if someone has no problem with their personal device being managed by their corporation? Maybe their organization pays them a stipend (this is becoming more and more common as a pseudo-BYOD or hybrid BYOD). In these scenarios, if you configured Device Enrollment Restriction then you will block an individual user from enrolling ANY device into Intune, since it will always default to personal. So then how would a user enroll a device? Short answer, by themselves they wouldn’t – they will need someone to pre-register it for them such as AutoPilot or an AD GPO to enroll Windows device as a corporate device. Other device types like iOS, Android, or macOS allow you to enter a serial number or IMEI but that option is not available for Windows.

Important Side Note: This forum post illustrates what happens when you configure enrollment restrictions to block Personally owned devices to Block but then neglect to manually change Autopilot devices to Corporate. They will get error 80180014 because they forgot to set the Autopilot devices to Corporate. https://techcommunity.microsoft.com/t5/microsoft-intune/error-80180014-due-to-device-restrictions-for-windows-autopilot/m-p/1155809

Seeing Device Enrollment Restriction in Action

If you attempt to enroll a device when Enrollment Restrictions are configured to block personal devices then there is no way I could find to circumvent this control, which is AMAZING because that is what we want to achieve to prevent a hacker from enrolling a device into Intune and bypassing Conditional Access Policies that limit authentication to only compliant devices.

image

Then in the Event Viewer Log Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin you will get Event ID 52

“MDM Enroll: Server Returned Fault/Code/Subcode/Value=(DeviceNotSupported) Fault/Reason/Text=(Device Identifier not preregistered).”

Require MFA for Device Registration

The Microsoft article states that enabling MFA for device registration would prevent this attack. The reason I don’t like this as the *only* control is because users can still accidentally approve a push notification, or they might have a man-in-the-middle phishing attack like EvilGinx. So keep this ON, but don’t rely on this as the *only* control.

image

If you want more granularity you can set the setting above to No and then configure it in Conditional Access Policy to force MFA when registering or joining

image

The Microsoft article also correctly points out that Intune enrollment can be restricted to an IP range via Conditional Access Policy. This would only work if remote users already have a VPN established with force-tunnel (whereas split-tunnel is much more common).

Summary

Relying on conditional access policies to requires compliant devices without also restricting enrollment into Intune through the various methods described in this article can lead to the attacker bypassing Conditional Access Policies that require Intune Compliance, leading to unauthorized access to SaaS apps or network resources. For example, in the worst case scenario, “Second Wave Phishing” would happen if Auto MDM Enrollment happens after an AAD Join or Device Reg (‘enroll only in device management”) setting, then a VPN configuration is automatically pushed down to the device, and then the AAD Joined machine is able to connect to other network resources. Ouch!

TIP

I should also point out that Microsoft recently created a Conditional Access Overview page that can help you spot other misconfigurations.

https://portal.azure.com/#blade/Microsoft_AAD_IAM/ConditionalAccessBlade/Overview

image

Get Help

Head over to the Microsoft Technical Communities to ask questions and get free peer support:

https://techcommunity.microsoft.com/t5/communities/ct-p/communities

I am always interested in feedback. If you feel I got it wrong or if you would do it differently please DM me on Twitter at @ITGuySocal

-Joe

OneDrive not starting up

Ok this was bizarre – we had a customer who had multiple machines where OneDrive for Business would not startup.

They swore that it was working fine. Never trust an end user.

The fix was to reverse a registry key which had disabled OneDrive, which in itself proves the users had no idea what they were talking about. Some administrator had rolled out a registry key to disable OneDrive, so there is no way it could have been working.

Always take what an end user tells you with a grain of salt. Like: a very very small grain.

Here was the fix to reverse the problem: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\OneDrive.DisableFileSyncNGSC set value to 0

Reboot

You are welcome =)

What happened to the Email Security Funnel Reports?

Don’t feel bad if you missed the September 20th 2021 blog post titled “Improving the reporting experience in Microsoft Defender for Office 365

To be clear, most of us only have time to read about user impacting things where features are being taken away as that typically draws our attention. So when we read a headline like this, we may put it on the backburner until we have time to get to it later.

Then comes the day when you start looking for your favorite report and you can’t find it! It’s missing!

image

Yes, Microsoft has retired SIX reports: the malware email detection report, the spam report, the safe attachment file types, and deposition report, the sent and received email report, and the URL trace report that previously lived in the exchange admin center.

But as bad as that sounds, it’s actually not that bad at all. Why? Microsoft has replaced the reports with new and better reports, you just need to know where to go look for it. Basically the Funnel Report has been replaced with a newer and more modern “Sankey” report.

https://security.microsoft.com/mailflowStatusReport?viewid=sankey

clip_image002

The report is interactive, so if you click on ‘impersonation’ it will expand like this:

clip_image002[5]

The other benefit of the new report over the old one is the filtering capability is significantly more robust.

“In order for SecOps to focus the scope of their assessment with a lot more granularity, we are providing security professionals the ability to filter data by organization domain, policy type and name, priority account user tag, recipient address and email directionality (inbound and outbound).”

The new report also has a cool new ‘trendline’ flyout report that appears on the right after clicking on ‘show trends’

clip_image004

clip_image006

Here is the documentation page describing all the new features and capabilities of the new report. What’s really helpful about the documentation is it describes that of the 6 reports that have been retired, it tells you the hyperlinks of how to find the information in the new reports!

https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/view-email-security-reports?view=o365-worldwide#mailflow-view-for-the-mailflow-status-report

Other benefits: PowerBI and reporting API integration, and data going back > 90 days. <- This is huge.

Summary

Yes, change is hard sometimes when you get used to going somewhere and then a blog article gets posted, you miss it, and now you cannot find your data. Normally, Microsoft adds banners inside the product letting you know that a dashboard is coming or you have 30 days to enjoy it before its gone, so I am not sure why that did not happen in this case, but I am sure we can all agree the new reports are better and we will all enjoy the 90 day + increased historical data that the reports will pull, increased filtering, better details and drill downs, etc.

Conditional Access Policy to Block Non-Compliant Devices

Recently came across a scenario where we needed to block access to everything in Azure Active Directory (AAD) for non-compliant devices. Setting up that Conditional Access (CA) Policy was not a problem. The problem was it worked too well, and it even blocked the ability to register new devices into Intune for them to get the appropriate compliance policies.

Here is the error we were receiving when trying to enroll devices:

clip_image002

Based upon this denial of access error we knew that the policy was too strict, and we needed to allow for enrollment of new devices to get compliant. We went back into our policy that was set to block all cloud apps and excluded Microsoft Intune Enrollment.

After saving the policy we then went into testing mode and then got this:

clip_image003

SAME ERROR!!!!!

We then investigated into the Microsoft documentation to try and find more information about Intune Enrollment and CA Policies. We stumbled upon this link that breaks down the steps required to configure a CA Policy for Intune enrollment with Multi-Factor Authentication (MFA)

https://docs.microsoft.com/en-us/mem/intune/enrollment/multi-factor-authentication

We do have MFA turned for our users in this environment, but this article only highlighted using the Microsoft Intune Enrollment app for MFA at enrollment. Our policy to block access was at least allowing for the MFA prompt to occur, but not enrollment. This example policy also is not blocking any other apps, just requiring MFA for the Windows Intune Enrollment app.

In the document we notice it mentioned another Intune app – called Microsoft Intune

clip_image005

Searching for Microsoft Intune will yield a plethora of information, but we needed the details on the cloud app. We then searched for the cloud app we found this link that identifies all the cloud apps available for CA Policies.

https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/concept-conditional-access-cloud-apps

Scrolling down it does list Microsoft Intune – but it has no link for more information on what it does! Microsoft Intune Enrollment is listed, and linked, but that link goes back to our MFA CA Policy link we from earlier!

Now that its all clear as mud, and we had to try something, we decided to also exclude Microsoft Intune as well as Microsoft Intune Enrollment. All cloud apps were still selected, and block access was still the condition.

clip_image007

Then select the two Intune Apps – Microsoft Intune Enrollment AND Microsoft Intune

clip_image009

We then tested again, and ENROLLMENT WAS SUCCESSFUL! By adding those two apps as exclusions the Policy blocks access to all non-compliant devices but still allows for new devices to enroll. This meets the need for this situation as we needed to block all non-compliant devices from accessing anything, but also giving them an opportunity to become compliant by registering with the tenant.

Let us know in the comments section if this helps or if you have another way of blocking access while allowing enrollment.

Thanks for reading!

Security Concerns with Windows 365–aka Cloud PC

Cloud PC (sold as the Windows 365 Product SKU) is the latest Virtual Desktop service hosted by Microsoft in Azure. This post (Part 1) documents some of the security concerns that Infosec Twitter has identified. Part 2 will explore ways to harden CloudPC/Windows 365.

Cloud PC (Announced 7/14/2021 and Generally Available 8/2/2021)

Azure Virtual Desktop (Announced 6/7/2021) 

Windows Virtual Desktop (9/30/2019)

Azure RemoteApp (Retired on 8/31/2017)

Rand Morimoto wrote a nice write-up on Cloud PC (here), and the differences between it and Azure Virtual Desktop (here). Indeed, many have written articles on it, but the reason for this blog post is to examine the security and respond to some of the harsh criticism on Twitter (the InfoSec community on Twitter is probably the best ‘accountability’ buffer to keep Microsoft in check).

Most of what I have written about securing AVD/WVD (Part 1) and (Part 2) applies equally to Cloud PC. But what I love most about the business edition of Cloud PC is it eliminated all the overhead associated with spinning up the AVD/WVD environment (see Part 1 above to appreciate that effort). The Enterprise Edition requires some additional work but not as much as AVD/WVD, as explained in this Mechanics video here. There are already troubleshooting articles on the Hybrid Azure AD requirements here.

When I created my first Cloud PC, the provisioning process failed. I found out that there were issues with provisioning as described in the forums here. Turns out there were multiple issues and so I have published a separate blog post ‘Troubleshooting Windows 365 business’ here].

As an end user, you access your Cloud PC from: https://windows365.microsoft.com/

Also, it’s worth noting that on August 15th 2021, Microsoft is making Cloud PC available for end users to purchase on their own credit cards. IT Departments can disable this with PowerShell.

Install-module MSCommerce

Connect-MSCommerce

W365 Enterprise – update-MSCommerceProductPolicy -PolicyId AllowSelfServicePurchase -ProductId CFQ7TTC0HHS9 -Enabled $false

W365 Business/w Hybrid Benefits – update-MSCommerceProductPolicy -PolicyId AllowSelfServicePurchase -ProductId CFQ7TTC0J203 -Enabled $false

W365 Business – update-MSCommerceProductPolicy -PolicyId AllowSelfServicePurchase -ProductId CFQ7TTC0HX99 -Enabled $false”

Learn More: Use AllowSelfServicePurchase for the MSCommerce PowerShell module | Microsoft Docs

So why has Twitter been so unforgiving?

1. InfoSec Twitter does not like the default configuration of Local Administrator rights being given to the Cloud PC user. They claim this is not “secure by default.” It’s hard to argue with them on this point.
(1) Benjamin Delpy on Twitter: “Windows 365 is expensive and without basic security Did #mimikatz dumped my Azure *cleartext* password here? Or my Primary Refresh Token? It’s funny how you don’t apply best practices you recommend to the customer to avoid securing by default &gt; https://t.co/Wzb5GAfWfd https://t.co/cMDq1a4l5e” / Twitter
It does appear Microsoft is exploring solving this according to this thread here:
Windows 365 Business Cloud PC Local Admin – Microsoft Tech Community

2. Mimikatz has been updated to dump Windows 365 credentials

(1) Benjamin Delpy on Twitter: “After a little bug report from @LawrenceAbrams, I just pushed a #mimikatz fix to dump even more #Windows365 credentials privilege::debug ts::logonpasswords &gt; https://t.co/HjfZej6tqD” / Twitter

and

(1) Benjamin Delpy on Twitter: “Would you like to try to dump your #Windows365 Azure passwords in the Web Interface too? A new #mimikatz release is here to test! (Remote Desktop client still work, of course!) &gt; https://t.co/Wzb5GAfWfd cc: @awakecoding @RyMangan https://t.co/hdRvVT9BtG” / Twitter

3. Lack of SecureBoot, UEFI, Credential Guard, etc
(1) Benjamin Delpy on Twitter: “Figure 1. VM with hardware enforced security, vTPM, SecureBoot, UEFI, Credential Guard, etc. Figure 2. #Windows365 without basic hardware security, no security feature, BIOS Guess the one running on an old ESXi in basement vs the new 365 revolution from Microsoft in #Azure ? https://t.co/PUGtqO0g3s” / Twitter

Disable Exchange Online Remote PowerShell for users as a scheduled task

This PowerShell script can run unattended as a scheduled task and will enumerate the global administrators, then remove remote PowerShell access for any user who is not a global administrator.

#See Prerequisites section below to create these two certificate connection scripts below

Invoke-Expression -Command C:\scripts\connect-certificate.ps1

Invoke-Expression -Command C:\scripts\connect-azureadcertificate.ps1

$GlobalAdmins = Get-AzureADDirectoryRoleMember -ObjectId $(Get-AzureADDirectoryRole -filter “displayname eq ‘Global Administrator'”).ObjectID

$AllUsers = get-user -resultsize unlimited

$UserswithPowerShell = $AllUsers | where {$_.RemotePowerShellEnabled -eq $true}

$UsersWhoAreNotGlobalAdmins = $UserswithPowerShell | where {$_.userprincipalname -notin $GlobalAdmins.userprincipalname}

$counter = ($UsersWhoAreNotGlobalAdmins).count
$current = 1

if ($UsersWhoAreNotGlobalAdmins) {
write-host “Users who currently have remote powershell access” ($UserswithPowerShell).count
foreach ($user in $UsersWhoAreNotGlobalAdmins) {
write-host “Removing PowerShell access from user ” $current ” of ” $counter “(” $user.userprincipalname “)”
set-user -identity $user.userprincipalname -RemotePowerShellEnabled $false

#Optional, the next statement can also apply a authentication policy to block basic auth

#Set-User -identity $user.userprincipalname -AuthenticationPolicy “Block Basic Auth”
$current = $current + 1

}
}
else
{
write-host “there are no non-global admin users with PowerShell access”
}

Download the script (here).

Prerequisites: Create two Azure AD Applications (1) Exchange and (2) Azure AD

TIP: When creating the Scheduled Task,  the account must have the Logon as a service right assigned. Then the ‘action’ to start a program points to c:\windows\system32\windowspowershell\v1.0\powershell.exe
then the arguments are: -File “c:\scripts\scriptname.ps1”