Requirements

In order to query license information for your tenant, you will need the following API Scopes permitted.

• Microsoft.Graph or Microsoft.Graph.Beta PowerShell modules
• Directory.Read.All or Organization.Read.All

Get Microsoft 365 License Usage Count Using PowerShell

Before we get into the PowerShell script, I wanted to point out that the Microsoft API’s don’t show the friendly display names for these licenses. Instead, they use a SkuPartNumber to give you an idea of what the licenses is regarding. The problem here is that you also won’t find the SkuPartNumber anywhere in the portal so it’s kind of a pain to make sure the license you’re targeting in the API is in fact the license in the Azure portal.
 

Luckily, there is a Microsoft Doc that has this information but it’s not always up to date. The link to that doc is https://learn.microsoft.com/en-us/entra/identity/users/licensing-service-plan-reference. There’s about 400+ Sku’s that are shown so it’s also nice that they have provided a csv file that we can use PowerShell to be able to pull these names into our Script.

$LicenseFile = 'C:\temp\m365license.csv'
$CutoffDate = (Get-Date).AddDays(-7)

if (Test-Path $LicenseFile) {
    $LastWriteTime = Get-ChildItem -Path $LicenseFile | select -ExpandProperty LastWriteTime

    if ($CutoffDate -gt $LastWriteTime) {
        #csv file is older than a week old.  Let us get a newer version
        Invoke-WebRequest -Uri 'https://download.microsoft.com/download/e/3/e/e3e9faf2-f28b-490a-9ada-c6089a1fc5b0/Product%20names%20and%20service%20plan%20identifiers%20for%20licensing.csv' -OutFile C:\temp\m365license.csv
    }
} else {
    #csv file was not found so let us download it now
    Invoke-WebRequest -Uri 'https://download.microsoft.com/download/e/3/e/e3e9faf2-f28b-490a-9ada-c6089a1fc5b0/Product%20names%20and%20service%20plan%20identifiers%20for%20licensing.csv' -OutFile C:\temp\m365license.csv
}

$csvList = Import-Csv C:\temp\m365license.csv
$LicenseHash = @{}

$csvList | ForEach-Object {
    if (-not $LicenseHash[$_.Guid]) {
        $LicenseHash.Add($_.GUID, $_.Product_Display_Name)
    }
}

$LicenseList = Get-MgSubscribedSku

#Uncomment if you only want to display licenses that are maxed out
foreach ($License in $LicenseList) {
    if ($License.PrepaidUnits.Enabled -ge 1) {
        #if ($License.ConsumedUnits -ge $License.PrepaidUnits.Enabled) {
            [PSCustomObject]@{
                LicenseName   = $LicenseHash[$License.SkuId]
                SkuPartNumber = $License.SkuPartNumber
                SkuId         = $License.SkuId
                Remaining     = $License.PrepaidUnits.Enabled - $License.ConsumedUnits
                Enabled       = $License.PrepaidUnits.Enabled
                Used          = $License.ConsumedUnits
            }
        #}
    }
}

As you can see from above, the Identity Governance P2 Step Up license has not been updated in the downloadable csv file so the license name shows up blank.

Conclusion

Hopefully this article was able to help you get Microsoft 365 License usage count using PowerShell and Graph API. Sometimes we’re too busy to manually keep an eye on it so having this script along with an email alert would be helpful for preventing your licenses being maxed out.

The post Get Microsoft 365 License Usage Count Using PowerShell appeared first on the Sysadmin Channel.

Requirements

Before we go into the details on how to set this up, we first need to ensure that we have everything in place so everything works as expected. Here’s what is needed.

• Azure AD P1 or P2 license for conditional access
• Security Administrator, Conditional Access Administrator or Global Administrator
• SharePoint Administrator or Global Administrator
• Exchange Administrator or Global Administrator
• Microsoft.Online.SharePoint.PowerShell PowerShell Module
• ExchangeOnlineManagement PowerShell Module

To touch a bit on these requirements, we need to ensure we have an Azure AD P1 or P2 license so we can have access to use conditional access policies. This is going to be the foundation of what we’re going to use to either limit or block unmanaged devices from accessing anything in the cloud. Also as of today, Security Administrator, Conditional Access Administrator or Global Administrator are the only roles that are able to modify CA policies. So we will need at least one of those.
 

Exchange Administrator and SharePoint Administrators are needed to be able to set the respective platform policies to limited access. A bit more on that later.

What Classifies as an Unmanaged Device

An unmanaged device is typically a device that is not issued by your organization. It is often synonymous with BYOD (Bring Your Own Device) and can be anything from a personal computer or phone to a machine that you use to access emails while at grandma’s house. The point here is that it doesn’t have any policies and it is not properly governed by the IT department.
 

Limit Browser Access on Unmanaged Devices for M365 Apps

If you don’t want to put a full stop on users accessing M365 resources, you do have the ability to limit what they can do while signed in from an unmanaged device. Simply put, we can enforce policies so users can still sign in using the web only methods, however, they will be blocked from downloading anything to the local machine.
 

For most, this is a great happy medium because it still keeps your data secure to a certain extent and users can access their documents if they don’t have their company issued device around.
 

This is in fact a two-step process so we’ll target SharePoint/OneDrive and Exchange Online now. Then we will finish it off with the CA Policies.

Limited Browser Access for SharePoint Online

If you want to take this in incremental steps you definitely can. Being able to set limited access on specific sites is supported so it’s definitely recommended you take that approach first. In my opinion it will be a good test to set limited access on a few SharePoint sites as well as a few OneDrive sites.
 

Let’s connect to SharePoint Online using the Microsoft.Online.SharePoint.PowerShell PowerShell Module.

Import-Module Microsoft.Online.SharePoint.PowerShell -WarningAction SilentlyContinue
$adminURL = 'https://<tenantname>-admin.sharepoint.com'
Connect-SPOService -Url $adminURL -WarningAction SilentlyContinue

Apply on a Per-Site Basis

Next, let’s take a look at the conditional access property within the Get-SPOSite cmdlet. This is what we’ll use to be able to limit access on specific SharePoint (or OneDrive) sites before we deploy this on the tenant level. By default, this should be set to allow full access. Meaning anyone can access this SharePoint site from anywhere and there wouldn’t be any restrictions in place.

With that out of the way, let’s change the access to allow limited, web only access for this site as well as a OneDrive site. To accomplish this we’re going to use the Set-SPOSite cmdlet along with the -ConditionalAccessPolicy Parameter.
 

This parameter supports the following inputs:

• AllowFullAccess: Allows full access from desktop apps, mobile apps, and the web
• AllowLimitedAccess: Allows limited, web-only access
• BlockAccess: Blocks Access
• AuthenticationContext: Assign an Azure AD authentication context. Must add the AuthenticationContextName

$SiteURL = 'https://thesysadminchannel.sharepoint.com/sites/someproject'
$OneDriveURL = 'https://thesysadminchannel-my.sharepoint.com/personal/buzz_thesysadminchannel_com'

Set-SPOSite -Identity $SiteURL -ConditionalAccessPolicy AllowLimitedAccess
Set-SPOSite -Identity $OneDriveURL -ConditionalAccessPolicy AllowLimitedAccess

$SiteURL, $OneDriveURL | ForEach-Object {Get-SPOSite -Identity $_ | select Title, ConditionalAccessPolicy}

Title          ConditionalAccessPolicy
-----          -----------------------
SomeProject         AllowLimitedAccess
Buzz Lightyear      AllowLimitedAccess

Before you start checking the sites you set the limited access on, note that nothing is limited until we configure the CA policies. It is strongly recommended that you do thorough testing before enabling this at the tenant level. Once you’ve done that and you’re ready to set it as the default, you can do that with another cmdlet. That cmdlet is Set-SPOTenant
 

Apply at the Tenant Level

Now that you’re ready to enable this as the default on the tenant level, there is one thing we need to decide on. That one thing is whether we want to enforce these restrictions on adhoc recipients. What exactly does that mean you say?
 

When the feature is enabled, all external users are going to be in scope of the restrictions and users who are accessing SharePoint Online files with a pass code are going to be blocked.
 

Set-SPOTenant -ConditionalAccessPolicy AllowLimitedAccess -ApplyAppEnforcedRestrictionsToAdHocRecipients: $false

When completed, we can also check the SharePoint Admin center to see the same thing.

 

Finally, since doing this will automatically create a conditional access policy on our behalf, I would recommend disabling that and crafting one by hand so we can fine tune it to our liking.

Limited Browser Access for Exchange Online

Much like the SharePoint Online scenario, we can also limit browser access for users who are trying to access their email when on an unmanaged device. This setting is done using the OwaMailboxPolicy and is configurable for specific mailboxes or at the tenant level. Before we take a look at each one, we need to connect to Exchange Online via PowerShell.

Connect-ExchangeOnline -UserPrincipalName user@domain.com -ShowBanner: $false

Apply on a Per-Mailbox Basis

Again, it’s always a great idea to test on a few people to ensure you’re able to get the results you want. There’s nothing worse than enabling a policy and having to revert back because of incidents that could have very well been avoided if it was properly tested.
 

To set the limited access on a few mailboxes we’re going to need to create a new OwaMailboxPolicy and then set the same conditional access parameter to readonly.
 
In case you’re interested, here is what the supported inputs are for that parameter:

• Off: No conditional access policy is applied to Outlook on the web. This is the default value
• ReadOnly: Users can’t download attachments to their local computer, and can’t enable Offline Mode on non-compliant computers. They can still view attachments in the browser
• ReadOnlyPlusAttachmentsBlocked: All restrictions from ReadOnly apply, but users can’t view attachments in the browser

$OwaPolicy = New-OwaMailboxPolicy -Name LimitAccess
Set-OwaMailboxPolicy -Identity LimitAccess -ConditionalAccessPolicy ReadOnly
Get-OwaMailboxPolicy | select Name, IsDefault, ConditionalAccessPolicy

Name                     IsDefault ConditionalAccessPolicy
----                     --------- -----------------------
OwaMailboxPolicy-Default      True Off
LimitAccess                  False ReadOnly

With the OwaMailboxPolicy now created, let’s apply that policy to a few users so we can do our testing. To apply we will use the Set-CASMailbox cmdlet.

Set-CASMailbox darth -OwaMailboxPolicy LimitAccess
Get-CASMailbox darth | select DisplayName, OwaMailboxPolicy

DisplayName OwaMailboxPolicy
----------- ----------------
Darth Vader LimitAccess

Apply at the Tenant Level

After we’ve tested for a bit, we can now apply this as the default setting at the tenant level. To accomplish this, we will use the Set-OwaMailboxPolicy and and modify the “OwaMailboxPolicy-Default” to use the readonly conditional access policy.
 

Set-OwaMailboxPolicy -Identity OwaMailboxPolicy-Default -ConditionalAccessPolicy ReadOnly
Get-OwaMailboxPolicy | select Name, IsDefault, ConditionalAccessPolicy

Name                     IsDefault ConditionalAccessPolicy
----                     --------- -----------------------
OwaMailboxPolicy-Default      True ReadOnly
LimitAccess                  False ReadOnly

Block Unmanaged Devices Using Conditional Access

If you’re wondering why nothing has changed after setting the SharePoint or Exchange settings, it’s because your conditional access policies are the tools that are going to be enforcing these restrictions. The platform settings are the underlying scoping policies, however the conditional access policies are the overlying restriction setting. Since we ended up setting both platform restrictions at the tenant level, the users we add (and ONLY those users) in the conditional access policy should have this setting enforced. Hopefully that clears up any confusion.
 

Similar to the default SharePoint policies that were automatically created, there are 2 policies we need to create so we can block unmanaged devices as well as restrict browser access if they’re not on an IT issued device. We can use those as rough templates to get us started.
 

Within Azure AD:

• Navigate to Security → Conditional Access → Policies → New Policy
• Direct Link: Conditional Access Blade
• Name: CA015: Block Unmanaged Devices for All Users
• Under Users:
• Include: All Users (or smaller groups for testing)
• Exclude: Break glass account, MFA exclude group and all Guest users



• Under Target Resources:
• Include: All Cloud Apps (or M365 Apps for testing)
• Exclude: None



• Under Conditions: No Changes needed (or exclude iOS and Android Devices for testing)
• Under Grant:
• Require device to be marked as compliant: Checked
• Require Hybrid Microsoft Entra joined device: Checked
• Require one of the selected controls: Is selected



• Under Sessions: No Changes needed

Restrict Browser Access on Unmanaged Devices Using Conditional Access

Earlier we setup the policies on Exchange Online and SharePoint to be able to limit browser access while using an unmanaged device. The policy on that platform is set, however, as mentioned earlier, we need to be able to enforce this using conditional access policies. Let’s do that now.
 

Within Azure AD:

• Navigate to Security → Conditional Access → Policies → New Policy
• Direct Link: Conditional Access Blade
• Name: CA016: Restrict Browser Access to Unmanaged Devices for All Users
• Under Users:
• Include: All Users (or smaller groups for testing)
• Exclude: Break glass account, MFA exclude group and all Guest users



• Under Target Resources:
• Include: Office 365
• Exclude: None



• Under Conditions:
• Client Apps → Browser: Checked



• Under Grant: No changes needed
• Under Sessions:
• Use app enforced restrictions: Checked

Incognito Mode and Browser Extensions

One important item to call out is that your users can continue to have issues even though their device is compliant or Hybrid Azure AD Joined. This is because certain browsers don’t have the functionality built-in to send the device payload so the CA policy can properly evaluate it.
 

• Edge: Functionality is built-in so testing with Edge is always recommended
• Chrome: Windows 10 accounts extension is required for Chrome v111+
• FireFox: FireFox Windows SSO is required
• Incognito Mode: extensions should be abled for incognito mode as well

If you’re STILL having issues after ensure your device is in the proper state and you have the proper extensions installed, one thing that I’ve learned is clear the cache and cookies and that resolves most of the issues.
 

Conclusion

Hopefully this article on how to limit or restrict browser access to Microsoft 365 apps as well as block unmanaged devices using conditional access was insightful. This should help add a bit more strength to your overall security posture so that’s always a good thing.
 

This policy is very powerful so you need to make sure you do some thorough testing before enabling the policy globally. Another policy I would highly recommend is to Enable Authentication Strengths Using Conditional Access so you can set higher profile apps to use phishing resistant MFA.

The post Block Unmanaged Devices Using Conditional Access appeared first on the Sysadmin Channel.

Requirements

In order to have successful results, you will need the following.

• Exchange Administrator Permissions -or Global Administrator Permissions
• Audit Logs Enabled. Specifically Mailbox Audit logs
• Exchange Online Management PowerShell Module

Get Recipient Permissions to See Who Has Access

Before we dive deep into the logs, I always like to narrow down my search by simply seeing who has access to send as that specific account. If there are only 1-2 users who have access, this narrows things down pretty well. If there are a dozen or more, then things might get a little tricky and we’ll need to go into logs.
 

Let’s check to see who has permissions and see if we get lucky. To find this, we’re going to use the Get-RecipientPermission cmdlet from the ExchageOnlineManagement module.

Get-RecipientPermission testmailbox -AccessRights SendAs | Where-Object {$_.Trustee -ne 'NT AUTHORITY\SELF'}

Identity     Trustee                     AccessControlType AccessRights Inherited
--------     -------                     ----------------- ------------ ---------
Test Mailbox paul@thesysadminchannel.com Allow             {SendAs}     False

In some scenarios it very well may be possible that the account itself sent the email, but for the sake of this article we’re going to assume someone sent an email with the sendas permissions. Therefore we added the where clause to not include SELF.

Find Account That Sent Emails From Shared Mailbox

In the example above, we can see that only one account has access to send as the shared mailbox so it’s pretty much a no brainer in this scenario. However, as I mentioned before, some shared mailboxes (or regular mailboxes for that matter) can have multiple people with this access right.
 

In order to find the exact user, let’s look to the logs and see what they say. Logs never lie!

$SendAs = Search-MailboxAuditLog -Identity testmailbox -Operations SendAs -ShowDetails
$Sendas | select LogonUserDisplayName, ClientProcessName, ItemSubject, OperationResult, LastAccessed


LogonUserDisplayName : Paul Contreras
ClientProcessName    :
ItemSubject          : The Force
OperationResult      : Succeeded
LastAccessed         : 9/14/2023 8:37:38 PM

Conclusion

In this case the recipient permissions pretty much gave it away as I was the only one with permissions. However, being able to search in the mailbox audit logs will show us EXACTLY which was the account that sent this email. Hopefully this was informative for you and you’re able to find out who sent emails from shared mailbox.

The post Find Account That Sent Emails From Shared Mailbox using PowerShell appeared first on the Sysadmin Channel.

Requirements

In order to set this up without failure, there are a few things needed to get you on your way to using Exchange Online certificate based authentication. Let’s cover what’s needed right now.
 

• A certificate, either self signed or one issued by PKI
• Azure Application Administrator or Global Administrator
• Privilege Role Administrator or Global Administrator
• Exchange Online Management PowerShell module

Above are the requirements to allow you to connect to Exchange Online using certificates. I manage Exchange Online using PowerShell so I added that as well. If you’re looking for instructions on how to get that installed, check out this article to install the Exchange Online Management module for PowerShell.

Create a Self-Signed Certificate

First things first, I thought it would be best to start off by creating the self-signed certificate to get the ball rolling. If possible, I would recommend using a certificate issued by a public key infrastructure (PKI). The reason for that is because we know we can trust it, it is inherently more secure, and we can also revoke the cert should the situation call for it. The problem is not every environment has a PKI setup (my lab included).
 

As mentioned, we don’t have a PKI in our environment so we’ll make due with a self signed certificate. Luckily, Azure does support self signed certs so let’s get that created within PowerShell.
With PowerShell open, enter in the following:
 

#splatting for human readability
$CertParam = @{
    'KeyAlgorithm'      = 'RSA'
    'KeyLength'         = 2048
    'KeyExportPolicy'   = 'NonExportable'
    'DnsName'           = 'server.thesysadminchannel.com'
    'FriendlyName'      = 'Exchange Online Automation App'
    'CertStoreLocation' = 'Cert:\CurrentUser\My\'
    'NotAfter'          = (Get-Date).AddYears(1)
}
 
#Creating self signed cert with parameters from above.
$Cert = New-SelfSignedCertificate @CertParam

The above parameters do not allow you to export the certificate to another machine. I should also note that this is saving the certificate under the user context. If you want to store the certificate under the local machine context, you will need to run PowerShell as an administrator anytime you to connect. Allowing it under the local machine certificate store means other administrators on the machine would also be able to connect. So just be aware.
 

Now that we have the cert created, let’s export it so we can upload it to Azure when we create our application.

#Since we captured the output to the $Cert variable in our previous step.
#We will use that to specify the cert parameter. 
#The .cer file will exported to the user's desktop.
 
Export-Certificate -Cert $Cert -FilePath $Home\Desktop\ExchangeOnlineAutomation.cer

Create an Azure App Registration and Service Principal

To get started, we need to make sure we have the proper rights to get the application created. This is where you will need an Azure AD Application administrator (or Global administrator).
 

Within Azure AD:

• Navigate to App registrations → New registration

• Name your application accordingly. I’ve named mine Exchange Online Automation
• Select Accounts in this organizational directory only (Single tenant)
• Leave the Redirect URI empty
• Click Register to create the app

With your app now created:

• Navigate to Certificates & secrets
• Click the certificates tab
• Click Upload certificate
• Click the folder icon and browse to your desktop to select the exported cert
• Click Add

Next we need to add the Exchange.ManageAsApp API permissions within the app so the application object can access the resource. To do this we need to add it through the manifest because we won’t be able to find it via the typical API permissions blade.
 

Within the app, navigate to the manifest blade and replace the requiredResourceAccess block with this code. Be sure to click save when it’s added.

"requiredResourceAccess": [
   {
      "resourceAppId": "00000002-0000-0ff1-ce00-000000000000",
      "resourceAccess": [
         {
            "id": "dc50a0fb-09a3-484d-be87-e023b12c6440",
            "type": "Role"
         }
      ]
   }
],

Once that is saved, we can verify it was added correctly by going back to API permissions. We will now see that Exchange.ManageAsApp is the only entry there.

 

However, we will notice that the app requires admin consent in order for it to be effective. Go ahead and consent to it now. Once complete, it should look like the image below.

Add Exchange Administrator Role

With our app now created and configured properly, we’ll need to grant the Exchange Administrator role to that app.
 

Within Azure AD:

• Navigate to Roles and administrators
• Search for Exchange and click on Exchange administrator

• You should be taken to the active assignments for the Exchange admin role
• Click on Add assignments

• Click no members selected link
• Search for the app name (Our is Exchange Online Automation)
• Click on the app to add it to the selection
• Click select
• Complete the prompts to add the role

We should now see our Service Principal listed as an active assignment.

Connect to Exchange Online using the Azure Application

Finally, we’re in a spot where we can put all of the pieces together and connect to Exchange Online using our Azure AD application (Service Principal). Again, since I use PowerShell to manage EXO, we’re going to connect using the Exchange Online Management module. Be sure to use the latest version.
 

Before we connect, let’s get the AppId. We’ll also need to know the tenant’s default onmicrosoft name. To get the AppId, go back to the overview page of the Application we created earlier.

 

$AppId = '9e46ef5x-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
$Certificate = Get-ChildItem Cert:\CurrentUser\My\A94FFE108DCxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
$TenantName = 'thesysadminchannel.onmicrosoft.com'

Connect-ExchangeOnline -AppId $AppId -Certificate $Certificate -Organization $TenantName -ShowBanner: $false

As you can see, we were able to successfully connect to Exchange Online and run the Get-Mailbox command against my account. As a side note, I’ve also chosen to not display the banner by using the ShowBanner: $false parameter in the command.

Conclusion

Hopefully this article on how to use Exchange Online certificate based authentication was insightful and you were able to implement it in your own organization. This is used pretty much daily to automate tasks in Exchange and it’s great that we don’t have to worry about usernames and passwords.
 

If you want more information on creating Azure apps and using Graph API, check out my in-depth article on how to Connect To Microsoft Graph API Using PowerShell.

The post Exchange Online Certificate Based Authentication appeared first on the Sysadmin Channel.

Requirements

If this is something we are considering than let’s take a look at the options we have available to us. As mentioned, the best (and most practical) way to handle this task is to do so via a transport rule. Furthermore, let’s list the requirements here.

• Exchange Administrator Role
• Exchange Online with a valid mail license

Block Users From Sending to External Recipients in Office 365

Regarding use cases, I’m sure someone somewhere can justify a good reason why we would want to block mail to an external domain like Gmail, yahoo or anyone outside of your domain. Perhaps they want to prevent someone from leaking information, whatever the reason may be, we’ll show you how to get this done.
 

First we’ll want to open a browser of your choice.

• Navigate to Exchange Admin Center
• Expand Mail Flow -> Rules
• Direct Link: https://admin.exchange.microsoft.com/#/transportrules

• Next Click on the “+” to create a new rule
• Select Create a new rule

• Name the rule Block Sending to External Domains
• Scroll down a bit and click on the more options link
• Under apply this rule if dropdown, select the recipient.. -> is external/internal -> select outside the organization
• Click Add Condition
• Under the next and statement, select the sender.. -> is a member of this group -> select a mail-enabled security group
• We have the option to choose individual users but it’s always best to use groups for easier administration
• Under do the following -> select block this message -> select delete the message without notifying anyone
• Apply exceptions as needeed

Testing The Exchange Transport Rule

Now that we have the rule in place, we should be able to test that it’s actually working. To do that, we’ll send an email to both an external domain and to someone in our tenant.
 

In this instance, we can run a simple message trace to see the status and the event type.

Conclusion

Hopefully this article was informative and we were able to show you how to block users from sending to external recipients. We showed you how to create an Exchange Transport Rule as well as confirming that the actual email was being blocked at the Exchange level.
 

If you’re looking to implement something like this, just be sure that you have the right parameters in place. If this is not configured correctly, you can imagine the mayhem you’d cause by blocking all outbound emails.
 

Finally, if you’re looking for more articles on Exchange, be sure to check out how to block legacy authentication in Office 365

The post Block Users From Sending to External Recipients in Office 365 appeared first on the Sysadmin Channel.

Requirements

As far as requirements go, you’ll need proper permissions to be able to disable this. This means that a Global Administrator is best suited to do this since it will be impacting the entire tenant.
 

What Is Microsoft Viva

Microsoft describes Viva as an employee experience platform that brings together communications, knowledge, learning, resources, and insights in the flow of work. While that may be true, in my personal experience I’ve only ever received briefing and insight emails that tend to clutter my inbox without any real benefit.
 

Here’s an example of one I received not too long ago.

 

How To Turn Off Microsoft Viva Briefing and Digest Emails

Moving on, in order to disable Microsoft Viva briefing email, let’s head on to the Microsoft 365 Admin Center since that is where the work is going to take place.
 

In Microsoft Admin Center:

• Click Settings -> Org Settings -> Services
• Select Briefing email from Microsoft

• Next, uncheck Let people in your organization receive Briefing email
• Click Save

Next up, we’ll want to disable those digest emails that you receive on a regular basis as well.

Within the same Microsoft Admin portal:

• Click Settings -> Org Settings -> Services
• Select Microsoft Viva Insights
• Uncheck Digest email and insights Outlook add-in

Conclusion

Today we’ve walked through how to stop Microsoft Viva from sending you those briefing emails and we hope it was informative. With Microsoft Viva disabled, you shouldn’t get those emails that are most unwanted for you and your organization.
 

If you liked this article, be sure to check out Enable Plus Addressing in Office 365 Exchange Online. Finally, if you like to see more video content, don’t forget to check out our YouTube Channel with awesome Sysadmin video content.

The post How To Turn Off Microsoft Viva Briefing and Digest Emails appeared first on the Sysadmin Channel.

Requirements

As of today, there aren’t any major requirements other than having an Office 365 tenant and a mailbox in Exchange Online to be able to use this feature.
 

Plus Addresses – What is it and why should I use it

Before we get into the details of how to enable plus addressing in Office 365 Exchange Online, let’s take a minute to explain what it is and why it would be beneficial for you to use it.
 

For starters, plus addressing is a standard approach for mailboxes to provide dynamic, disposable recipient email addresses. Furthermore, it should be explicitly mentioned that this is intended for recipient addresses, not sending addresses.
 

As we’re well aware, the basic format for an SMTP email address is username@domain.com. However, when using plus addressing, the basic format would be username+additionalcharacterstomakethisunique@domain.com. When using plus addresses, you as sender can specify a any set of characters after the “+” and when enabled, Exchange will see that and route the mail to the mailbox that it corresponds to. This is assuming the underlying mailbox is active and functioning properly.
 

We’ve gone over the what, so now let’s go over the why. Why would enabling this in your tenant be beneficial to you or your users?
 

Essentially, this would be useful to many organizations because it allows you to use “burner” addresses that route to your mailbox in the backend. I’ve used it on a couple of occasions myself, mainly when testing something using a different address. However, this can also be useful for users who would like sign up for subscription services and have the ability to identify those quickly.
 

Enable Plus Addressing in the Office 365 Portal

We’ve identified what plus addresses are and how they can might be of service to you and your org. Now let’s take a look how to enable plus addressing in the Office 365 Portal.
 

Within the Exchange Admin Center:

• Navigate to Settings -> Mail Flow
• Direct Link: https://admin.exchange.microsoft.com/#/settings
• Ensure Turn off plus addressing for your organization is unchecked

Enable Plus Addressing using PowerShell

An alternative to the Exchange Admin portal is being able to enable plus addressing using Powershell. For starters, we’ll need to install Exchange Online Powershell Module and connect to it using the Connect-ExchangeOnline cmdlet.
 

Once connected, we can run a one-liner to enable this feature for your tenant.

PS C:\> Connect-ExchangeOnline -ShowBanner: $false
PS C:\>
PS C:\> Set-OrganizationConfig -DisablePlusAddressingInRecipients $false
PS C:\>

Conclusion

Hopefully this article to show you how to enable plus addressing for Office 365 and Exchange Online was helpful. Plus addressing is helpful for users who want to create dynamic, disposable recipient addresses.
 

If this was helpful, be sure to check out our other Exchange Online posts.

The post Enable Plus Addressing in Office 365 Exchange Online appeared first on the Sysadmin Channel.

Feel free navigate to any portion of the article using the table of contents below.

Requirements

As mentioned, this is definitely something that should be enabled for just about every organization out there, but there are a few things you should know if you want to implement this for your org. Let’s list them out here and what you’ll need.

• A Global Administrator. This is needed to modify SSPR settings
• Azure AD P1 or P2 license (for Hybrid environments only)

Enable Self-Service Password Reset for Cloud Only Environments

If you’re a cloud only environment, meaning you don’t have any users syncing from on-premises Active Directory, it is pretty simple to enable self-service password reset. Let’s cover the steps now.

In Azure Active Directory:

• Navigate to Password Reset
• Direct Link: https://portal.azure.com/#blade/Microsoft_AAD_IAM/PasswordResetMenuBlade/Properties
• Under Self-Service password reset enabled, select your choice of All or a specified group
• As a pilot, I’ve selected a group but it is generally recommended to enable it for all users

Enable Self-Service Password Reset for Hybrid Environments

In order to enable self-service password reset for hybrid environments, you’ll need to complete the steps above because that is the baseline configuration needed in order to make this work.
 

Furthermore, if you’re syncing onprem Active Directory users to Azure AD there is still more to do in the AAD Connect wizard. Let’s cover those steps now.

Set up Password Write Back in Azure AD Connect

Logon to your Azure AD Connect Server and launch the Azure AD Connect wizard.

Configure SSPR Authentication Methods

Once we’ve enabled SSPR for the environment we stop now but I thought it would be a good idea to take a few more minutes to look over some of the sub settings that are in the password reset blade.
 

In order for a user to reset their password, they’ll need to provide some form of identity verification. This is essential from a security standpoint, and prevents joe user (or a potential hacker) to gain access to your account. In any event, let’s take a look at the authentication methods that are required in order to reset a user’s password.

By default, email and phone are enabled because 2 methods are required but I also like to add mobile app code because it uses MFA as a verification method. This helps reduce the attack surface for anyone changing their password.

Require Registration for Self-Service Password Reset

In the previous years of SSPR, you were required to register for self-service password reset AND register for MFA. This was kind of a pain point because users had to register for 2 items. Thankfully, the team at Microsoft integrated these and today we can use combined registration mode for SSPR and MFA. This is great because as the name suggests, you will only need to register 1 time and that will be active for both items.
 

Furthermore, let’s head into the registration blade:

Confirm On-premises Integration

If you’re wondering if password writeback is enabled and don’t have access to view the configuration in the Azure AD Connect wizard? That’s not a problem because we can easily check this in the password reset blade.
 

Conclusion

Hopefully this article was able to provide in-depth detail on how to enable self-service password (SSPR) in Azure Active Directory. As mentioned, this is something that should be enabled for your organization help eliminate administrative overhead. Your users will happy, and you’ll be happy because you won’t be getting calls to reset a password.

The post How To Enable Self-Service Password Reset (SSPR) In Azure AD appeared first on the Sysadmin Channel.

Requirements

In order to move forward with enabling multi-factor authentication for guest users there are a couple of requirements that are needed. Let’s list them out here so we have a clear understanding of what they are.

• Azure AD Premium license (P1 or P2)
• A valid external email account that you can add as B2B guest user

In my lab tenant, I have EMS-E5 licenses which is P2 so I’m good to use conditional access policies to get this all setup.

End User Experience and What to Expect

To give you some context on how I’m testing this in my lab tenant, I’ve granted the external user who is named “Guest User” access to a SharePoint site that I’ve created for this purpose.
 

The SPO site, Project Gladiator, has an “ExternalUser” folder that I’ve setup to mimic a real-world scenario. This folder is where people from other orgs will update their notes to use for collaboration.

At this point, I’ve sent an invitation to the guest user and they have accepted the invite. Next, I copied the link to that folder and sent over to the external user so they can access the resources that are setup at their convenience.
 

For now, we’ll take a moment to check in on the user experience before and after the policy is enabled.

What to Expect if the User has MFA Enabled

Let’s take a moment to clear the air first. If a user has MFA enabled on their own home tenant, this doesn’t mean that they’ll be prompted to confirm their identity with an MFA prompt on your resource tenant. There are now ways to trust the MFA claims from the home tenant using Cross Tenant Access Policies (xtap) but that’s a little outside the scope of the this article.
 

It will actually take some effort to enable MFA on a resource tenant if you’re not enforcing it so chances are they won’t do unless you make them.
 

However, if a user has enrolled in MFA in the resource tenant, then they’ll continue to be prompted for MFA as they previously have.

What to Expect if MFA is not enabled for the User

Since there aren’t any policies that are enforcing MFA for external (guest, B2B etc..) users, this user is able to get in with just a username and password. If someone potentially compromised the remote credentials, they now have access to your tenant. This is obviously a no-no and is the reason why enabling MFA is so vital to security.
 

We haven’t touched on how to enable the policy yet, however, what can we expect when we enable MFA for external users Office 365 / Azure AD?
 

Once you enable the policy, the user would be shown the typical prompt for when a user tries to enroll in MFA in the home tenant.

How To Enable MFA for External Users Office 365

Now that we know what it looks like, next up is to use a conditional access policy template in Azure AD to set it up. As mentioned, this would require you have a premium license so hopefully you have that setup in you tenant so you can follow along. Let’s review the steps needed to enable this policy.

In Azure AD:

• Navigate to Security -> Conditional access -> Policies
• Direct Link: https://portal.azure.com/#blade/Microsoft_AAD_IAM/ConditionalAccessBlade/Policies
• Click New Policy -> Create new policies from templates

• Under Customize your build: select Identities and click Next
• select Require multi-factor authentication for guest access and click Next

• Review the policy and confirm it is in Report-only
• Click Create Policy

Now let’s go back into the policy and under Assignments -> Exclude: Enter the breakglass account and an MFA exclusions group in your own tenant. Hopefully this won’t be needed, but if someone decides to modify the policy and applies it to people in your org, you’ll at least have some specific exclusions in place.
 

Finally, enable the policy and click save. External users will now need to enable MFA to access resources in your home tenant.

Conclusion

Hopefully this article showed you how to enable MFA for external users Office 365 and was easy to follow along. If you haven’t done so already, be sure to enable MFA for your regular users to ensure you’re covered across the board.

The post How To Enable MFA for External Users Office 365 appeared first on the Sysadmin Channel.

Per Microsoft, several of the older components that Azure AD Connect uses have been scheduled for deprecation. To mitigate the issue, they bundled as many of these newer components into a single release so you only have to update once.

So What Are the Major Changes in Azure AD Connect 2.0

If you recall, the previous version of AAD Connect shipped with SQL Server 2012. Seeing as how SQL 2012 will be out of extended support in 2022, they’ve decided to bundle SQL Server 2019 when you install it.

 
Another major note to take in account is the new version of AAD Connect will now have Microsoft Authentication Library (MSAL), where as the previous version had Active Directory Authentication Library (ADAL) installed. MSAL uses Microsoft Graph Endpoints on the backend to make sync processes much faster.

 
Next up is Server 2012 and Server 2012 R2 are no longer supported for AD Connect and with that is a requirement to have PowerShell 5.0 installed on the machine. The good thing is that Server 2016 and Server 2019 have Powershell 5.0 installed by default.

 
Furthermore, if you have tried to install AAD Connect v2.0 and you’re not on Server 2019 you might have noticed that you’re immediately prompted with a warning of an incorrect TLS version. If you’re doing your homework before installing the new version, just know that TLS 1.0 and TLS 1.1 are protocols that are being deprecated by Microsoft because they are now deemed unsafe. This release of Azure AD Connect will only support TLS 1.2. If your server does not support TLS 1.2 you will need to enable this before you can deploy Azure AD Connect v2.0.

Enable TLS 1.2 For Azure AD Connect v2.0

Straight out of their documentation, Microsoft has already posted the Powershell script to enable TLS 1.2. Here is the exact replica so you don’t have to go to another place. Make sure you Powershell as an Administrator because you will change the state of the machine.

New-Item 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319' -name 'SystemDefaultTlsVersions' -value '1' -PropertyType 'DWord' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319' -name 'SchUseStrongCrypto' -value '1' -PropertyType 'DWord' -Force | Out-Null
New-Item 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -name 'SystemDefaultTlsVersions' -value '1' -PropertyType 'DWord' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -name 'SchUseStrongCrypto' -value '1' -PropertyType 'DWord' -Force | Out-Null
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -name 'Enabled' -value '1' -PropertyType 'DWord' -Force | Out-Null	
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -name 'DisabledByDefault' -value 0 -PropertyType 'DWord' -Force | Out-Null
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -name 'Enabled' -value '1' -PropertyType 'DWord' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -name 'DisabledByDefault' -value 0 -PropertyType 'DWord' -Force | Out-Null
Write-Host 'TLS 1.2 has been enabled.'

Once that is ran, go ahead and reboot the server to make sure you install AAD Connect on a fresh system.

Upgrade To Azure AD Connect 2.0 Step by Step

First things first, you’ll need to download the latest version on Microsoft’s website here.

• After the initial MSI is ran and the setup is completed, you’ll be prompted with the welcome screen

• Select Upgrade when you reach this prompt

• Azure Active Directory Connect will now upgrade the Sync Engine

• Once the Sync Engine is upgraded, you will be prompted to enter in credentials

• AAD Connect no longer needs a Global Administrator to upgrade, you can now use a Hybrid Identity Administrator
• Following the least privilege model, we’ll enter in a Hybrid Identity Administrator account that also needs to be activated with PIM
• To continue the installation, enter a Global Administrator -or Hybrid Identity Administrator account (we’ll activate our hybrid identity role)

• Once Azure has confirmed the credentials, select Upgrade to start the sync process.

• The setup will now run several update processes

• If everything was successful, you should see Configuration Complete

• Last but not least, open the Synchronization Service Manager -> Help -> About
• You should be able to confirm the version is now above. 2.0

• You should also be able to confirm you’re using AD Connect v2 EndPoint API

PS C:\> Import-Module 'C:\Program Files\Microsoft Azure AD Sync\Extensions\AADConnector.psm1'
PS C:\>
PS C:\> Get-Command *ApiVersion* -Module AADConnector

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Function        Get-ADSyncAADConnectorExportApiVersion             0.0        AADConnector
Function        Get-ADSyncAADConnectorImportApiVersion             0.0        AADConnector
Function        Set-ADSyncAADConnectorExportApiVersion             0.0        AADConnector
Function        Set-ADSyncAADConnectorImportApiVersion             0.0        AADConnector


PS C:\> Get-ADSyncAADConnectorExportApiVersion
2
PS C:\> Get-ADSyncAADConnectorImportApiVersion
2
PS C:\>

Conclusion

Well hopefully this article was able to help you upgrade to Azure AD Connect 2.0. It’s actually not that bad of an install and it’s not too involved so hopefully you won’t run into any issues if/when you decide to upgrade it in your environment.

One thing I forgot to mention is that if you have specific rules on your AD Connect Server, those will need to confirmed so it doesn’t cause any impact.

The post How To Upgrade To Azure AD Connect 2.0 appeared first on the Sysadmin Channel.