This post will detail how to create an Azure Logic App which will take input from an end user (in the form of a SharePoint list entry) and automatically provision a new shared mailbox as well as set up delegation for selected users.

Prerequisites:

• Azure Az PowerShell module
• MgGraph PowerShell module
• Working knowledge of M365/SharePoint Online/Exchange Online/Azure

SharePoint Setup

1. Create a SharePoint site
2. Create a SharePoint list within your SharePoint site
3. Create columns as needed for the data to be input by the requesting users

Here is an example of the list I created:

Azure Automation Account Setup

Create an Automation Account in the Azure portal or via PowerShell.

Next, navigate to Shared Resources>Modules in the Automation Account blade, and click "Browse gallery" - search for ExchangeOnlineManagement and import the module:

Now we need to grant the Exchange Online API permission for the managed identity (reference). Using a managed identity allows the Automation Account to authenticate to Exchange Online without specifying any credentials - pretty cool:

• Connect to MgGraph module: Connect-MgGraph -Scopes AppRoleAssignment.ReadWrite.All,Application.Read.All
• Connect to Azure Az module: Connect-AzAccount
• Fetch GUID for the Automation Account managed identity: $MI_ID = (Get-AzADServicePrincipal -DisplayName "svc-exchange").Id
• Assign app role to service principal:

$AppRoleID = "dc50a0fb-09a3-484d-be87-e023b12c6440"
$ResourceID = (Get-MgServicePrincipal -Filter "AppId eq '00000002-0000-0ff1-ce00-000000000000'").Id

New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $MI_ID -PrincipalId $MI_ID -AppRoleId $AppRoleID -ResourceId $ResourceID

Navigate to Azure AD Roles and Administrators>Exchange Administrator>Add assignments, and select the service principal for the Automation Account:

Creating the Runbooks

Within the Automation Account, go to Process Automation>Runbooks in the navigation blade. We will be creating two runbooks - one to provision the shared mailbox, and another to set the appropriate delegation.

Create the first runbook, adjusting the name as you see fit:

Here is a simple script for the runbook to provision the shared mailbox:

param (
    $EmailAddress,
    $DisplayName
    )

Connect-ExchangeOnline -ManagedIdentity -Organization YOUR_ORG_NAME.onmicrosoft.com

New-Mailbox -Shared -Name $DisplayName -DisplayName $DisplayName -PrimarySmtpAddress $EmailAddress

Be sure to both Save and Publish the runbook. Then create the second runbook to set the delegation on the new shared mailbox. Here is a script for that:

param (
    $Users,
    $SharedMailbox
    )

Connect-ExchangeOnline -ManagedIdentity -Organization YOUR_ORG_NAME.onmicrosoft.com
    
foreach ($user in $Users) {
	Add-MailboxPermission -Identity $SharedMailbox -User $user -AccessRights FullAccess
    Add-RecipientPermission -Identity $SharedMailbox -Trustee $user -AccessRights SendAs -Confirm:$false
}

Again, be sure to Save and Publish the runbook.

Logic App Setup

1. Create a new Logic App
2. In the Logic App blade>Settings>Identity, turn system assigned managed identity on and click Save
3. Add the Logic App managed identity as a Contributor to the resource group the Automation Account resides in. Again, this makes it so that the Logic App can authenticate to the Automation Account to invoke the runbooks without specifying any credentials in the connection:

Building the Logic App Flow

Begin building the Logic App by using a blank template. The trigger for the Logic App will be SharePoint>When an item is created. Select the SharePoint list you created earlier:

We will need to initialize a couple of variables - a string and an array. The string will be used within email notifications to display the users who will be granted permissions to the shared mailbox. The array will be used in our script for the runbook to set the mailbox permissions.

The next three steps should look like this - Initialize variable>Initialize variable>For each:

Add the next step - Office 365 Outlook>Send approval email. Fill the parameters as you see fit:

Add the next step - Condition. Build a condition for "SelectedOption is equal to Approved":

In the True branch, Add an action>Azure Automation>Create job. This is going to use our runbook to create the shared mailbox. Name the connection and select "Logic Apps Managed Identity" for the Authentication Type:

Select the Azure Subscription, Resource Group, Automation Account, and Runbook Name (you will need to use the Add new parameter drop-down menu for the runbook name). Use dynamic content from the SharePoint list for the runbook parameters:

Add an action>Azure Automation>Create job again. This is going to run the runbook which will grant Full Access and Send As permissions to the requested users. Supply the necessary parameters:

At this point the core functionality is there. I decided to add a few more email notifications - one to notify the requesting user if the request was rejected, and notifications to the administrator and the requestor when the workflow is complete.

Here is the complete workflow I created:

The Finished Product

First, the end user submits an entry to the SharePoint list:

This triggers the flow, and then an approval email is sent to the administrator:

After approval is granted, the runbook jobs are launched. The shared mailbox is provisioned, and the listed users are granted Full Access and Send As permission:

A completion email is sent to the administrator and the requesting user:

Now the workflow is complete.

Logic Apps are a great way to easily automate routine administrative tasks or helpdesk requests. Using the same general workflow described in this post, you can automate many different tasks. I hope this post helps and provokes further ideas for improvement in your environment.

If someone isn't able to triage and respond to an alert in a reasonable amount of time, the outcome can be less than desirable.

Say you are part of a small team and don't have a set of eyes on alerts 24/7 and something happens overnight when the team is sleeping. Your monitoring system may be working as intended and fire off an alert email in the middle of the night when certain conditions are met, but what good is it if it doesn't get anyone's attention?

If you can't afford around-the-clock detection and response, you need to prepare yourself some other way for those truly time-sensitive events which will inevitably arise at the most inconvenient of times.

I came up with this simple solution using an email as a trigger, which will generate a phone call informing the appropriate personnel to get to a PC and take action.

This post assumes some basic knowledge of REST APIs and requires a Power Automate premium license.

Plivo

Plivo is a Voice and Messaging API which I found easy to use and has good developer documentation. Their prices are reasonable and when I signed up for a trial account they provided a generous $25.00 credit.

Setup

Sign up for an account on Plivo's website. You will need to use a work email address (common personal email domains such as gmail.com are not allowed).

Sign in to your account, and make note of your Auth ID and Auth Token as shown on your dashboard:

Purchase a number by selecting the Phone Numbers icon in the left navbar, and then click Buy Number. You can search for your desired prefix and country code on the following page. This will be the number that calls originate from:

Next, you will want to create a "PHLO." A PHLO is a workflow within Plivo that can be triggered via an API call or other events. Using the left navbar, select the PHLO icon and then click Create New PHLO:

A window will pop up with several options to use as a template, simply select Build my own to start with a blank canvas:

From the components on the left, drag "Play Audio" into your PHLO designer (1). Then, drag a connector from "Incoming Call" within your "Start" component (2) to your new "Play Audio" component (3):

Select your Play Audio component within the designer to configure it. Give it a name, select either speech-to-text or upload an audio file, and specify any advanced settings:

Rename your PHLO in the top left corner and then save it. Click Copy PHLO URL in the top right corner and save this, you will need it in the next section.

Power Automate Flow

Navigate to flow.microsoft.com and then click Create>Automated cloud flow:

Give the flow a name, and for the trigger select When a new email arrives (V3). Create the flow:

Click Show advanced options within the When a new emails arrives (V3) step. Enter the appropriate values to filter on the alert email you want to notify on:

Click the New Step button and add the HTTP action:

Set the method for the HTTP request to POST.
Set the URI to https://api.plivo.com/v1/Account/YOUR_AUTH_ID_HERE/Call/.
Add Content-Type as a key with application/json as its value in the headers.
Use the following as the JSON body:

{
  "from": "PURCHASED_NUMBER_HERE",
  "to": "NUMBER_TO_CALL_HERE",
  "answer_url": "PHLO_URL_HERE",
  "answer_method": "POST",
  "time_limit": "60"
}

Set Authentication to Basic.
Set Username to your Auth ID.
Set Password to your Auth Token.

The action should look similar to this (my use case requires an additional line in the Body):

This will use send a POST request to the Plivo Call endpoint which will generate a phone call. The options in the Body will determine what number the phone call originates from and which number is dialed.

After the phone call is answered, a callback is made to the URL specified in the answer_url (your PHLO URL) which will invoke your PHLO. This will either speak the text you specified or play the audio file you uploaded earlier.

Be sure to save the flow.

Next time you receive an email matching the criteria you set, you will receive a phone call automatically. I would recommend setting a unique ringtone and excluding the number from your Do Not Disturb settings on your cell phone to ensure you hear the call.

There are many situations this can be easily adapted to, hopefully you can derive value from a use case of your own.

Cloudflare makes it incredibly easy to restrict deprecated TLS versions for all of your services, provided that your traffic is being proxied through them. While enforcing secure versions of TLS is easy, you should still do your due diligence before restricting TLS 1.0 and 1.1 if you are still allowing that traffic today.

There is a widget that will show your entire domain's observed traffic broken out by TLS version over a rolling 24 hour period, but in order to drill deeper to determine what source/destinations are involved, you will need to use either the Logpush or Logpull API.

If you are not familiar, see my other post, Using the Cloudflare Logpull API with PowerShell, for a quick primer. Following the steps in that post will ensure that you retrieve your API key, Zone ID, and enable log retention, which will all be required to proceed here.

In this example we will be using the Logpull API to fetch events which include the ClientSSLProtocol field to display which version of TLS was used for the connection. This script will fetch the previous hour's worth of logs via the /logs/received endpoint for your zone and save as a .ndjson file locally:

#Specify filepath to export logs
$exportPath = "C:\some\file\path.ndjson"

#Cloudflare API Key
$apiKey = "YOUR_API_KEY_HERE"
#Cloudflare Zone
$zone = "YOUR_ZONE_ID_HERE"
#Cloudflare Profile Email Address
$email = "YOUR_EMAIL_ADDRESS_HERE"

#Get time from 1 hour ago in ISO 8601 format; e.g. 2022-03-23T02:30:19Z
$timeStart = (Get-Date -AsUTC).AddHours(-1).ToString("yyyy-MM-ddTHH:mm:ss") + "Z"
#Get time from 1 minute ago in ISO 8601 format; e.g. 2022-03-23T03:29:19Z
$timeEnd = (Get-Date -AsUTC).AddMinutes(-1).ToString("yyyy-MM-ddTHH:mm:ss") + "Z"

#Specify fields to return
$fields = "ClientIP,ClientRequestHost,ClientSSLProtocol,ClientRequestMethod,ClientRequestURI,EdgeEndTimestamp,EdgeResponseBytes,EdgeResponseStatus,EdgeStartTimestamp,RayID"
#URL endpoint with parameters
$url = "https://api.cloudflare.com/client/v4/zones/$zone/logs/received?start=$timeStart&end=$timeEnd&fields=$fields"

#Required authentication headers
$headers = @{
    "X-Auth-Key"   = $apiKey
    "X-Auth-Email" = $email
    "Content-Type" = "application/json"
}

#Send request, store response
$response = Invoke-RestMethod -Method Get -Uri $url -Headers $headers

#Create .ndjson file at $exportPath if it doesn't already exist, add contents of response to file
if (!(Test-Path -Path $exportPath)) {
    New-Item -Path $exportPath
    Add-Content -Path $exportPath -Value $response
} else {
    Add-Content -Path $exportPath -Value $response
}

Now that we have a file with newline-delimited JSON, we can convert this to a CSV, for example, to manually inspect the logs and filter for a specific versions of observed TLS traffic:

#Specify filepath to .ndjson file
$inputPath = "C:\some\file\path.ndjson"

#Specify filepath to export CSV
$exportPath = "C:\some\file\path.csv"

#Get content of file, convert from JSON to PowerShell objects, export as CSV
Get-Content -Path $inputPath | ConvertFrom-Json | Export-Csv -Path $exportPath

The example outlined above can be a quick way to identify a sample of traffic and look for specific hosts and URIs with external connections over a particular TLS version. You could easily run the first script as a scheduled task or cron job to get traffic over a longer period of time, depending on your needs.

This method will not scale well with large datasets - for that, it would be recommended to use the Logpush API to send Cloudflare logs to a system capable of indexing large amounts of data.

Cloudflare has a great Analytics dashboard that provides good insight into your proxied web traffic. While the interface is intuitive and great for some high-level information, the dashboard may not always have the information you need.

The advanced logs you are looking for can be retrieved using either Logpush or Logpull. In this post we will cover the basics and retrieve some logs using the Logpull API with PowerShell.

Gather Requirements

In order to make requests, you will need an API key and a zone ID.

Log in to Cloudflare and go to My Profile:

Go to API Tokens and then view your Global API Key. Save this for later:

Navigate to your Account and then choose your website you want to view logs for. Retrieve the Zone ID and save this for later:

Enable Log Retention

HTTP request logs are not retained by default, so you will need to enable log retention before you can use the Logpull API.

You can check the status of log retention for your zone by running this in PowerShell (replacing variables with the values you retrieved earlier):

#Cloudflare API Key
$apiKey = "YOUR_API_KEY_HERE"
#Cloudflare Zone
$zoneId = "YOUR_ZONE_ID_HERE"
#Cloudflare Profile Email Address
$email = "YOUR_EMAIL_ADDRESS_HERE"
#Request Endpoint
$url = "https://api.cloudflare.com/client/v4/zones/$zoneId/logs/control/retention/flag"

#Required authentication headers
$headers = @{
    "X-Auth-Key"   = $apiKey
    "X-Auth-Email" = $email
    "Content-Type" = "application/json"
}

#Send request, store response
$response = Invoke-RestMethod -Method Get -Uri $url -Headers $headers

#Print response
$response

If the flag in the response is set to false, you need to enable log retention. Run the following to enable log retention:

#Cloudflare API Key
$apiKey = "YOUR_API_KEY_HERE"
#Cloudflare Zone
$zoneId = "YOUR_ZONE_ID_HERE"
#Cloudflare Profile Email Address
$email = "YOUR_EMAIL_ADDRESS_HERE"
#Request Endpoint
$url = "https://api.cloudflare.com/client/v4/zones/$zoneId/logs/control/retention/flag"

#Required authentication headers
$headers = @{
    "X-Auth-Key"   = $apiKey
    "X-Auth-Email" = $email
    "Content-Type" = "application/json"
}

#Data payload
$body = @{
    "flag" = $true
} | ConvertTo-Json

#Send request, store response
$response = Invoke-RestMethod -Method Post -Uri $url -Headers $headers -Body $body

#Print response
$response

Making a Request

With log retention enabled, you are ready to start making requests. You will want to review the available log fields to customize your request to conform to your use case.

Here is an example of a request made to the /logs/received endpoint which will fetch the previous hour's worth of logs for your zone and save them to a .ndjson file locally:

#Specify filepath to export logs
$exportPath = "C:\some\file\path.ndjson"

#Cloudflare API Key
$apiKey = "YOUR_API_KEY_HERE"
#Cloudflare Zone
$zoneId = "YOUR_ZONE_ID_HERE"
#Cloudflare Profile Email Address
$email = "YOUR_EMAIL_ADDRESS_HERE"

#Get time from 1 hour ago in ISO 8601 format; e.g. 2022-03-23T02:30:19Z
$timeStart = (Get-Date -AsUTC).AddHours(-1).ToString("yyyy-MM-ddTHH:mm:ss") + "Z"
#Get time from 1 minute ago in ISO 8601 format; e.g. 2022-03-23T03:29:19Z
$timeEnd = (Get-Date -AsUTC).AddMinutes(-1).ToString("yyyy-MM-ddTHH:mm:ss") + "Z"

#Specify fields to return
$fields = "ClientIP,ClientRequestHost,ClientRequestMethod,ClientRequestURI,EdgeEndTimestamp,EdgeResponseBytes,EdgeResponseStatus,EdgeStartTimestamp,RayID"
#Request endpoint with parameters
$url = "https://api.cloudflare.com/client/v4/zones/$zoneId/logs/received?start=$timeStart&end=$timeEnd&fields=$fields"

#Required authentication headers
$headers = @{
    "X-Auth-Key"   = $apiKey
    "X-Auth-Email" = $email
    "Content-Type" = "application/json"
}

#Send request, store response
$response = Invoke-RestMethod -Method Get -Uri $url -Headers $headers

#Create .ndjson file at $exportPath if it doesn't already exist, add contents of response to file
if (!(Test-Path -Path $exportPath)) {
    New-Item -Path $exportPath
    Add-Content -Path $exportPath -Value $response
} else {
    Add-Content -Path $exportPath -Value $response
}

View the Cloudflare developer documentation for more information about requesting logs with the Logpull API, which includes all of the available log fields that are supported to customize your requests.

The scenario here is that you have an M365 tenant which has multiple Active Directory forests synced to it, and you need to move a user's identity from its current forest into a different forest.

This isn't a very common occurence, but one that can come as part of a merger or acquisition situation where an employee transfers to a different business unit which has a disconnected forest and is being synced to the same tenant.

This post assumes that you have the MSOnline PowerShell Module installed and that you can connect to it and that you are using a topology similar to this with Azure AD Connect and Azure AD Connect Cloud Sync:

Convert from Directory-Synced to Cloud User Object

First, we need to convert the user object into a Cloud identity so that it is not being directory-synced from Active Directory.

Here, we have user 'John Doe' who is a directory-synced user:

• Move the user object such that it is out of scope from Azure AD Connect. Generally, this would be accomplished by moving the object to a non-syncing OU:

• Force Azure AD Connect to sync by logging into your Azure AD Connect server and entering the following in an elevated PowerShell terminal:
  Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Delta
  
  The user object will now be in a soft-deleted state in M365:

• Run a second sync cycle: Start-ADSyncSyncCycle -PolicyType Delta. There is not a clear technical explanation I have come across as to why this is necessary, but just save yourself the headache and run it a second time. I spent many hours going down a troubleshooting rabbit hole on a Sev A case with Microsoft and they recommended this themselves.
• Restore the user account: Restore-MsolUser -UserPrincipalName john.doe@contoso.com

• Reset the user object's Immutable ID: Set-MsolUser -UserPrincipalName john.doe@contoso.com -ImmutableId "$null"

The user's identity will now be managed exclusively by Azure AD and is no longer directory-synced:

Perform Matching Process to Link to Active Directory

Now that the user identity is Cloud-managed, we can link it to the other Active Directory forest so that it becomes managed there. To do this, there are two options - either the soft matching or the hard matching process.

A soft match occurs when both the Primary SMTP Address and UserPrincipalName of the Cloud-managed object are the same as an on-premises object. A hard match occurs when the Immutable ID of a Cloud-managed object is equal to the Base64-encoded objectGuid of an on-premises object. This process is covered in more detail here.

When the match occurs, the attributes in Azure AD (as well as the account's password, if password hash sync is enabled) will be overwritten by whatever is in Active Directory for the user account. Ensure the desired information is in Active Directory for this user before matching.

For the purposes of this post we will be doing a soft match.

• Ensure that there is a user account in the other AD forest that has the same UserPrincipalName and proxyAddresses (just the primary SMTP) attributes as the Cloud-managed account.
• Add the on-premises user account to the scope of what Azure AD Connect Cloud Sync is configured to sync (OU or Security Group). During the next sync cycle, the match will occur and the previously Cloud-managed account will become on-premises managed.

After completing a tenant migration project, some Lists used within various Teams embedded as channel tabs were missing certain fields when trying to add a new item or edit an existing item.

All fields were showing, but when trying to create a new list item there were random fields missing even though the old data was present and those columns were displayed.

The issue is most likely related to the Content Type these columns have assigned. To resolve this issue, first navigate to the 'List Settings' in SharePoint:

Next, go to 'Advanced Settings':

Navigate to Content Types>Allow management of content types? and select 'Yes'. Click 'OK' at the bottom of the page.

Review your columns. For any fields that are missing, you should notice that they have a different Content Type than the others.

Click the Content Type which is assigned to all of your working columns/fields:

Click 'Add from existing site or list columns':

Now, select the column(s) that were missing and then click 'Add' followed by 'OK':

At this point, you should be able to create a new List item and all columns/fields will properly display as input options.

You may need to adjust the column order if it is not displaying in the order you would like. Simply change this under 'Column order' and adjust accordingly.

Now you can go back to List settings>Advanced settings and change 'Allow management of content types?' back to 'No' and then click 'OK':

CarbonBlackPS is a PowerShell module for Carbon Black that I threw together over the course of a couple weekends in early 2021. This was one of the first modules I wrote and something that has saved me and my team a lot of time.

The project is available for download on Github and PowerShell Gallery and works with either Windows PowerShell or PowerShell Core.

Carbon Black Setup

To interact with the Carbon Black API, you need to authenticate your requests with several parameters which are defined in the API docs.

• Log in to your Carbon Black Cloud console. Make note of the web address as you will need it for later. This is your environment:

• Navigate to Settings>API Access

• Navigate to 'Access Levels' and click 'Add Access Level'

• Enter a Name and Description along with the necessary permissions to interact with the various endpoints you plan to make use of. This can be adjusted later if needed.

• Navigate to 'API Keys' and make note of your Org Key and click 'Add API Key'

• Enter a Name and Description and then select 'Custom' for the 'Access Level type' and select the name of the Access Level you created in the previous step for 'Custom Access Level'.

• Click 'Save' and your API ID and API Secret Key will be displayed. Make note of these as you will need them shortly.

PowerShell Module Setup

To install the module, simply open PowerShell and then enter the following command: Install-Module -Name CarbonBlackPS

After installing, import the module by running the following command: Import-Module CarbonBlackPS

Next, run Set-CbConfig to create your config.json file with the values you obtained from the previous section. Here is an example: Set-CbConfig -Environment "https://defense-prod05.conferdeploy.net" -ApiSecret "YOUR_API_SECRET" -ApiID "YOUR_API_ID" -OrgKey "YOUR_ORG_KEY"

This will create a config.json file in the root of your module's directory with your Environment, API Secret Key, API ID, and Org Key. After you run Set-CbConfig with the proper parameters you fetched earlier, you are ready to use this module.

Command Help and Examples

To get a list of commands, run Get-Command -Module CarbonBlackPS.

To get help about any particular function, run Get-Help <commandname> -Detailed.

To return examples of a particular command, run Get-Help <commandname> -Examples.