OneDrive not starting up

Leave a reply

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?

Leave a reply

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

Leave a reply

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!

Everything you wanted to know about Security and Audit Logging in Office 365

Leave a reply

There are four primary audit log locations in Office 365. Depending on license level, these logs have varying lengths of retention.

  1. Office 365 “Unified Access Log”
    1. Enabled by ‘opt in’ (The first time you visit the log page, it asks if you want to enable it.)
    2. Goes back 90 days
    3. Accessible here: https://compliance.microsoft.com/auditlogsearch?viewid=Test%20Tab
    4. Documentation: Search the audit log in the Microsoft 365 compliance center – Microsoft 365 Compliance | Microsoft Docs
    5. There are four options for extending the logs beyond 90 days
    6. Option 1: purchase M365 E5 (or other license) “Advanced Audit” which can extend this log to 1 year
    7. Option 2: purchase ‘10-Year Audit Log Retention Add On’ (this add-on first became available for purchase in March 2021). Note: This policy is *not* retroactive.
    8. Option 3: Extend this into Sentinel to get correlation and default query templates
    9. Option 4: Use a 3rd party SIEM to query the Office 365 Management API.
      TIP: When you purchase the “Advanced Audit” license, it will reduce the throttling that occurs when querying the API (so for example you will see data in Splunk much faster!).
    10. Option 5: PowerShell
  2. Azure AD Audit Log
    1. Enabled by Default
    2. Goes back 30 days with an Azure AD P1 license (or 7 days with an Azure AD Free)
    3. Accessible here: Azure Audit Log
    4. Documentation: Audit logs in Azure Active Directory | Microsoft Docs
    5. Latency. Audit logs have a latency ranging from 15 minutes to an hour
    6. Activities. A complete list of each activity audited is available (here)
    7. Limits. The export limit from the web interface is 5,000 records. You can get around this by exporting the logs through one of the options below, which can also be used to extend retention.
    8. Option 1: Extend this log into Azure Log Analytics (aka Azure Monitor) to go beyond 30 days (learn how here)
    9. Option 2: Extend this log into Sentinel to get correlation and default query templates (learn how here)
    10. Option 3: PowerShell or Graph API.
  3. Azure AD Sign-in log
    1. Enabled by Default
    2. Goes back 30 days with an Azure AD P1 license (or 7 days with an Azure AD Free)
    3. Accessible here: Azure Sign-in Log
    4. Documentation: Sign-in logs in Azure Active Directory | Microsoft Docs
    5. Latency. Sign-in activity logs can take from 15 minutes to up to 2 hours for some records. According to the documentation, 95% of all logs will show up in 2 minutes.
    6. Limits. The export limit from the web interface is 5,000 records. You can get around this by exporting the logs through one of the options below, which can also be used to extend retention.
    7. Option 1: Extend this log into Azure Log Analytics (aka Azure Monitor) to go beyond 30 days (learn how here)
      NOTE: Unlike the Azure Audit Log, the Azure AD Sign-in logs require an Azure AD P1 or higher license to export into Log Analytics.
    8. Option 2: Extend this log into Sentinel to get correlation and default query templates (learn how here)
    9. Option 3: PowerShell or Graph API.
  4. Microsoft Cloud App Security
    1. Goes back 6 months
    2. Not enabled by default, requires configuration. You must go to “Connected Apps” then click the three dots to make it include the additional log sources as shown here:
      clip_image002
    3. Requires an M365 E5 license or O365 E5 license (or available via Stand Alone)
    4. Accessible here: https://portal.cloudappsecurity.com/#/audits/
    5. Option 1: Extend this log into Sentinel to go beyond 6 months

Reporting

There are a few really useful built-in reports that analyze the logs and produce findings.

  • Risky sign-ins – A risky sign-in is an indicator for a sign-in attempt that might have been performed by someone who is not the legitimate owner of a user account.

    Latency can range from as little as 5 minutes, to a maximum of 2 hours.

  • Users flagged for risk – A risky user is an indicator for a user account that might have been compromised
    Latency can range from as little as 5 minutes, to a maximum of 2 hours.
  • Risk Detections. Azure AD uses adaptive machine learning algorithms and heuristics to detect suspicious actions that are related to your user accounts. Each detected suspicious action is stored in a record called a risk detection.
    Here are the latencies associated with when the risk detections will appear:
    image

Advanced Audit License

As noted above, the new Advanced Audit License extends the retention of the UAL audit log to 1 year and speeds up 3rd party API throttling. A 3rd useful capability is the additional fields that get audited when this license is applied to mailboxes. The ability to log the ‘MailItemsAccessed’ (some may know this as MessageBind, that is what it was called in on-premises Exchange). Additional entries including exactly which items were sent from the compromised account are also logged.

The Send event is also a mailbox auditing action and is triggered when a user performs one of the following actions:

  • Sends an email message
  • Replies to an email message
  • Forwards an email message

Investigators can use the Send event to identify email sent from a compromised account. The audit record for a Send event contains information about the message, such as when the message was sent, the InternetMessage ID, the subject line, and if the message contained attachments. This auditing information can help investigators identify information about email messages sent from a compromised account or sent by an attacker. Additionally, investigators can use a Microsoft 365 eDiscovery tool to search for the message (by using the subject line or message ID) to identify the recipients the message was sent to and the actual contents of the sent message. You can also run the Search-UnifiedAuditLog -Operations Send or Search-MailboxAuditLog -Operations Send commands in Exchange Online PowerShell.

The MailItemsAccessed mailbox auditing action covers all mail protocols: POP, IMAP, MAPI, EWS, Exchange ActiveSync, and REST.

This is useful in a forensic investigation because it logs which emails were accessed. Imagine the relief of a Legal team when a hacker only accessed 10 items instead of a million items, and none of those 10 items contained PII or PHI data.

Note: When a protocol such as POP, IMAP, or MAPI over HTTPS (aka Outlook Anywhere) syncs a folder, then a single audit event is logged that the folder contents were synced rather than an entry for each item in the folder. (Reference).

Note: If an attacker generates more than 1,000 audit records in 24 hours in a mailbox, then this audit log is paused for 24 hours =( So a crafty hacker could overwhelm the log in order to hide activities (the pause occurs for 24 hours). (Reference)

SearchQueryInitiatedExchange

The SearchQueryInitiatedExchange event is triggered when a person uses Outlook to search for items in a mailbox. Events are triggered when searches are performed in the following Outlook environments:

  • Outlook (desktop client)
  • Outlook on the web (OWA)
  • Outlook for iOS
  • Outlook for Android
  • Mail app for Windows 10
  • Investigators can use the SearchQueryInitiatedExchange event to determine if an attacker who may have compromised an account looked for or tried to access sensitive information in the mailbox. The audit record for a SearchQueryInitiatedExchange event contains information such as the actual text of the search query. The audit record also indicates the Outlook environment the search was performed in. By looking at the search queries that an attacker may have performed, an investigator can better understand the intent of the email data that was searched for.

Similar to searching for mailbox items, the SearchQueryInitiatedSharePoint event is triggered when a person searches for items in SharePoint. Events are triggered when searches are performed in the following types of SharePoint sites:

  • Home sites
  • Communication sites
  • Hub sites
  • Sites associated with Microsoft Teams

Investigators can use the SearchQueryInitiatedSharePoint event to determine if an attacker tried to find (and possibly accessed) sensitive information in SharePoint. The audit record for a SearchQueryInitiatedSharePoint event contains also contains the actual text of the search query. The audit record also indicates the type of SharePoint site that was searched. By looking at the search queries that an attacker may have performed, an investigator can better understand the intent and scope of the file data being searched for.You can also run the Search-UnifiedAuditLog -Operations SearchQueryInitiatedSharePoint in Exchange Online PowerShell. You must enable SearchQueryInitiatedSharePoint to be logged so you can search for this event in the audit log. For instructions, see Set up Advanced Audit.

In additional to the events listed above, there are also unique audit events that are only audited when the Advanced Audit license is owned:

Alerting

You can configure Alert Policies to notify you when certain things happen. This can be done in M365, Azure Monitor, MCAS, or Sentinel.

Audit Log Bypass

This article describes how it is possible for a user with administrative rights to bypass Mailbox audit logging, so be sure to document the configuration, and any changes to this configuration during a forensic investigation.

Manage mailbox auditing – Microsoft 365 Compliance | Microsoft Docs

PowerShell Modules

There are a variety of PowerShell modules available, designed to automate gathering the logs or searching them for use in forensic investigations. If you find any more, send me a DM on Twitter at @ITGuySocal

1. Hawk

2. DFIR-O365RC

3. Azure AD Toolkit (This is what Microsoft’s DART team uses)

4. CrowdStrike Reporting Tool for Azure (CRT)

5. Sparrow (this is what the US Government’s CISA’s Cloud Forensics team wrote back in December 2020 to identify activity in a tenant associated with the TTPs used by the hackers who compromised SolarWinds).

6. 365BlueTeamKit by Chaim Black

7. Office 365 Extractor by Joey Rentenaar and Korstiaan Stam from PwC Netherlands Incident Response team

8. Mandiant Azure AD Investigator This is similar to Sparrow in that it was built to  detecting artifacts that may be indicators of Nobelium/UNC2452/Sunburst or other threat actors that use those same techniques. 

Learning SAML in Azure AD

Leave a reply

In my opinion, the best way to learn a technology such as SAML is building a hands-on lab environment. In this blog we’ll explore how to create a SAML Application in Azure AD, using the “Azure AD SAML Toolkit” app.

There are two types of SAML Applications:

– Service Provider Initiated (aka “SP Initiated”). This means that the end-user will navigate to the web application first and then be directed back to the IDP to authenticate, and then the end-user will go back to the application to present the authentication token.

– Identity Provider Initiated (aka “IDP Initiated”). This means that the end-user will navigate to the IDP, in this case Azure is the IDP, so the list of applications will be found at “myapps.microsoft.com.”

Experts may read the simplistic explanations above and notice there are exceptions to these definitions, but to keep things simple we are going with those definitions.

The “Azure AD SAML Toolkit” was written to support SP Initiated SSO.

Getting Started

If you already have a test environment or if you are brave enough to test in your production environment, then skip step 1 and proceed to step 2.

Step 1) Sign up for a Office 365 trial tenant (here)

Step 2) Sign into the Azure Portal (this is the IDP) here: https://portal.azure.com

Step 3) In the search box type in “Azure Active Directory”

image

Step 4) Click Add > Enterprise Application

SNAGHTMLbf612fd

Step 5) Type “Azure AD SAML Toolkit” and then click on the application

image

Step 6) Click Create

image

Step 7) Click Single sign-on in the left navigation then click SAML on the right

image

Step 8) In Step One of “Basic SAML Configuration”  Click Edit

image

Step 9) In the Sign on URL enter: https://samltoolkit.azurewebsites.net/

image

PRO TIP: If you leave this field blank, you are configuring an app for “IDP Initiated” SSO instead of “SP Initiated SSO.” This will help you in the future when troubleshooting why an IDP Initiated app is not working, clear this field and it may start working.

Step 10) In the Reply URL (otherwise known as the Assertion Consumer Service URL) enter:  https://samltoolkit.azurewebsites.net/SAML/Consume

image

Leave the Entity ID with the pre-populated value, it should be:
https://samltoolkit.azurewebsites.net

Step 11)  Click Save
image

Step 12) On step three click Download next to “Certificate (Raw)”

The Certificate download link

Step 13) On Step four “Set up Azure AD SAML Toolkit” copy the values shown into Notepad or your favorite text editor. You’ll need these in a future step

Copy configuration URLs

Step 14) On the left navigation select “Users and Groups” and then add the user you are signed in with (this user will be used in a future step)

image

Step 15) Browse to the Azure AD SAML Toolkit website here: https://samltoolkit.azurewebsites.net

Step 16) Click Register

Azure AD SAML Toolkit Register

Step 17) Enter the email address associated with the user account that you added to the SAML Account in step 14 above

Step 18) Click SAML Configuration on the top navigation

Azure AD SAML Toolkit SAML Configuration

Step 19) Click Create

image

Step 20) Paste the values that you copied from step 13 above, and upload the certificate from step 12 above

image

Step 21) Copy Sign-on URL, Identifier and ACS URL values on SAML Toolkit SSO configuration page and paste into respected textboxes in the Basic SAML Configuration section in the Azure portal

image

Step 22) Test it out! Sign into Myapps.Microsoft.com and find the Azure AD SAML Toolkit. Click on it and then you should see a button to Log in. Click on this button to initiated an SP-Initiated sign-in.

image

If it works, you’ll be brought back to the same configuration page you used to create the app. This is just a simple app to show how SSO works with Azure AD.

References

Troubleshooting Windows 365 Business “Setup failed, please reset your Cloud PC”

Leave a reply

My first attempt at Windows 365 Business failed with error message “Setup failed, please reset your Cloud PC.” I thought it would be as simple as assigning a license to a user.

Turns out there are a few additional configuration prerequisites that must take place.

The key is to understand that during the provisioning process, a new user account named CloudBPRT or “Windows 365 BPRT Permanent User” is created in Azure AD. This account is used to join the machine to Azure AD.

1. If you have a conditional access policy that requires MFA then you need to exclude the CloudBPRT user from the policy.
A great troubleshooting tip is to use the WhatIf tool and add the CloudBPRT user to see which CA policies are applying to the user and then exclude the user from these policies
image

2. In Device Settings you must disable the requirement to require MFA when doing Azure AD Join, and If you limit which users or groups can join Azure AD, you must add the CloudBPRT user (as shown below)

image

3. The CloudBPRT user must be assigned an Intune license if you are doing Intune Auto Enrollment

4. If you Configure MDM AutoEnrollment, you must make sure the CloudBPRT user is a member of the scope, or that it is set to ALL as shown below
image

5. Then, reset the Cloud PC
image

6. In my experience, after Cloud PC was reset, I also had to select Restart before I was able to logon, otherwise I got a blank screen when trying to connect to Cloud PC.

image

Reference: Windows 365 for Business Troubleshooting Documentation

Other tips:

  1. The device will automatically enroll into Intune as an Autopilot device, but there is no need to configure an Autopilot Enrollment Status Page, nor can you target an ESP to Cloud PC’s per Microsoft Documentation (here)
  2. The device may fail compliance checks since bitlocker is not supported on Cloud PC’s, so it will be necessary to create an Intune Filter for “Cloud PC” and exclude that from policies that require Bitlocker while requiring that filter for other settings so that you can pass conditional access policy checks. For instructions on how to create an Intune filter click (here)
  3. It can take several hours for Microsoft Defender for Endpoint to perform the initial sync of the risk level to Intune Compliance, so if your Intune Compliance Policy has the setting “Require the device to be at or under the machine risk score” then be prepared to adjust your “mark device as non compliant’ to have some grace period such as a day otherwise your new employee will be locked out after their first sign-in.
    “Once the connection is established, the services are expected to sync with each other at least once every 24 hours.” (reference here)

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”

Securing Windows Virtual Desktop (2 of 2)

This is part 2, to learn how to setup a lab for WVD see part 1.

The first rule of securing WVD is to block all internet ports to the WVD infrastructure. You should not open TCP 3389 because Windows Virtual Desktop doesn’t require any open ports for users to access the host pool’s VMs. WVD uses Reverse Connect, which reduce the risk involved with having remote desktops brute forced from the internet.

The second rule of securing WVD is to enable MFA. Otherwise, if an attacker knows the email address, brute force is possible (or easier if the attacker obtains the password from a data breach since most users recycle their passwords). The location of the WVD environment is not a secret since most organizations will publish a deterministic TXT record that is always in the format of _msradc.(domain.com), like _msradc.contoso.com.

So security for WVD is similar to how we secure other M365 applications such as Exchange Online, SharePoint Online, Teams, OneDrive for Business, etc.

Identity Best Practices for WVD

1. Implement MFA for WVD.

Prerequisites:

a. Azure AD Premium P1 license is applied to the user accessing WVD

b. The user has previously enrolled into Azure AD MFA. (http://myprofile.microsoft.com)

c. Create a conditional access policy that targets the WVD application
Windows Virtual Desktop (App ID 9cdead84-a844-4324-93f2-b2e6bb768d07)

(If you are using the older WVD Classic (early adopters of WVD) then there is a different application you will select, learn more here.

2. Setting Expectations for the user’s MFA experience. For devices that authenticate with MFA at least once, they receive a token that allows the user to avoid additional (and arguably unnecessary) MFA prompts since they have already proven they are not a hacker. Some organizations still require MFA prompts for every single authentication attempt. The closest to that requirement is to set the CA Session refresh timeout to 1 hour (that is the minimum), which will require multifactor authentication if a connection is launched an hour after the last one. To configure this go to the Conditional Access policy created in step 1 and then select Session, select Sign-in frequency, set the value to the time you want between prompts. 

3. Use IP Fencing (sparingly). For example, if the outside vendor that needs to access your WVD environment always connects from a specific static IP address, you could create the conditional access policy to block access to WVD from any IP address other than the permitted IP address ranges. This scales reasonably well even for large organizations since you can have 2,000 IP ranges per named location (and a max of 195 total named locations).  This works mostly for businesses because most people’s home ISP will rotate the IP address periodically.

Disable Redirections

To prevent data from being copied outside of the WVD VM you can disable some of the redirections such as Clipboard and local drive access.

You can do this in the GUI or in PowerShell.

clip_image002

To learn how to connect with PowerShell, click here.

For example:

· redirectclipboard:i:0 disables clipboard redirection.

· usbdevicestoredirect:s: disables USB device redirection.

· devicestoredirect:s: disables redirection of plug and play devices.

· drivestoredirect:s: disables local drive redirection.

· redirectprinters:i:0 disables printer redirection.

To learn more about customizing RDP properties for a host pool using PowerShell or the Azure portal, check out RDP properties. For the full list of supported RDP properties, see Supported RDP file settings.

Block Screen Capture

The WVD client for Windows 10 has a unique feature that can prevent the host machine from taking screen shots of the applications running inside the WVD. This is done by adding a registry key to the WVD host computer in azure that is hosting the virtual machines. Since only the Windows client supports this, you could create a conditional access policy that prevents other operating systems from connecting to WVD (block mac, mobile and browser clients).
reg add “HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services” /v fEnableScreenCaptureProtection /t REG_DWORD /d 1
Learn more here.

RemoteApps vs Full Desktop

Publish RemoteApps rather than the full desktop. If you publish applications instead of the desktop then you don’t need to worry as much about data exfiltration. If you must publish a full desktop then you may want to look into Endpoint DLP for Windows 10 (requires M365 E5 license, Microsoft 365 E5 compliance, or Microsoft 365 E5 information protection and governance). This is likely to work on the WVD Dedicated but may not the WVD multi-session pooled configuration (I’ll have to test that).

Securing Azure AD Domain Services

In many WVD environments, they will be connecting to Azure AD Domain Services. Therefore, securing Azure AD Domain Services is important too.

By default, Azure Active Directory Domain Services (Azure AD DS) enables the use of ciphers such as NTLM v1 and TLS v1. These ciphers may be required for some legacy applications, but are considered weak and can be disabled if you don’t need them. If you have on-premises hybrid connectivity using Azure AD Connect, you can also disable the synchronization of NTLM password hashes.

To learn how to disable NTLM v1 and TLS v1 ciphers and disable NTLM password hash synchronization see Secure Azure AD Domain Services | Microsoft Docs

Azure Defender

For more tips we recommend the Microsoft Documentation ‘Security Best Practices for WVD’ here. For example, enable AppLocker and hide the Windows Explorer and local and remote drive mappings. Set a screen saver timeout, and disconnect idle sessions. Enable antivirus, EDR, and 3rd party vulnerability scanning and patch management. A lot of this is bundled by onboarding the hosts into Azure Defender (formerly known as Azure Security Center Standard). Pricing starts at $14.60 per server per month, see more pricing details here.

Stay Informed

To keep up to date with the latest announcements and improvements to Windows Virtual Desktop, check the release notes here once a month. I’m eagerly looking forward to support for Azure AD Join, so that WVD VM’s don’t have to join traditional domain controllers or AAD Domain Services.

[Update 5/26/2021] – Support for ADFS is now in PUBLIC PREVIEW: Announcing public preview of SSO using AD FS – Microsoft Tech Community