Phishing emails are fake messages, designed to look legitimate.
They cost businesses around the world billions of dollars each year. And they get opened by about 30% of people. These emails will generally impersonate a person or company that you trust or deal with, and attempt to trick you using one of three things:
They’ll use a fake person – someone pretending to be someone you know, so that you share information or transfer money into an attacker’s bank account.
They’ll set up a fake site – So that you enter your private information, like passwords or credit card details, or provide a rogue app with permission to access your data.
They’ll create fake attachments – attackers will disguise malware in fake invoices and shipping notification to remotely access your computer or encrypt your files.
How can I prevent phishing emails with Microsoft 365?
To give our teams the best chance of avoiding phishing emails, not only do we need to make people aware of the methods above, we need to configure the features in Microsoft 365 that address them. Starting with Office 365 Advanced Threat Protection
Start with Office 365 Advanced Threat Protection
This is your companies primary defence against phishing emails. While all Office 365 plans come with a built-in anti-phish policy, it’s not even close to what’s offered in Office 365 Advanced Threat Protection, also known as Office 365 ATP.
Once you’ve purchased Office 365 ATP, you should jump into the Security and Compliance centre and check out your anti-phishing policy.
Its default controls are pretty good for detecting phishing emails that impersonate your users, your domains and external contacts. It develops an understanding of how your users and their contacts interact, the addresses and sending infrastructure they use, and identifies anything out of the ordinary. If it detects an impersonation attempt, the message is either quarantined or delivered with a warning.
You can enhance your protection by adding users in roles like CEO or CFO to the targeted user protection feature. You can also add external domains, that you frequently interact with, to the targeted domains feature.
Use a mail transport rule to warn on external impersonation
You can configure a mail rule that applies a warning to messages where an external sender uses a display name that matches someone internally in your company. We have an example rule on our website that has been pretty popular amongst smaller organisations.
So that helps address fake senders, how about fake attachments and fake websites? Office 365 ATP addresses these with the Safe Attachments and Safe Links policies.
Detect malicious attachments with Safe Attachments policy
The safe attachments policy can protect your users from malware sent by phishing emails, like the COVID-19 phishing campaign that used Excel files to install a malicious remote access tool. The Safe Attachments feature analyses your attachments in a separate environment, running a bunch of checks for malware then blocking the email or removing the unsafe attachment.
Detect malicious websites with a Safe Links Policy
The Safe links policy scans your URLs in emails for links to malicious sites. If a malicious website is detected, Safe Links blocks users from visiting it.
Remove phishing emails from mailboxes after delivery
These tools work by analysing messages for known malware, bad links or untrusted senders and stopping them arriving. But what happens if a bad email gets through, and the system doesn’t realise until later?
You should configure Zero Hour Auto Purge. Zero Hour Auto purge removes bad messages from your mailboxes retroactively and sends them junk, quarantine or deleted items.
Set up Office 365 ATP and Exchange Online Protection with recommended best practices
I’ve just discussed four different security policies in a few minutes. If you’ve spent any time looking at ATP or Exchange Online Protection policies, you’ll probably notice there’s a lot of policies, and most of them are already set up. Should you change anything or leave them as they are?
It would help if you changed them, and Microsoft has two levels of recommended best practices that they say will prevent most unwanted messages from reaching your team.
These two levels are called Strict and Standard. In our experience, Strict is very strict, but it’s a good starting point that you can enable first, and adjust later.
Test users by simulating a phishing campaign
Once your policies are set up, you should test your users. If you purchase Office 365 ATP Plan 2, you can run attack simulations against your team. Attack Simulations can help you identify and find vulnerable users before a real attack impacts them.
Protect your accounts if your team gives up their credentials
But what happens when messages get through? What happens when users get duped and provide their login details to attackers?
Protect your accounts. If a user enters their credentials into a fake website, we need to make sure an attacker can’t use these credentials alone to log in. All Office and Microsoft 365 plans allow you to configure multi-factor authentication; this will ensure that attackers can’t log in without having access to an additional form of verification such as a phone or authentication token.
If you have a plan that includes Azure Identity Protection, you should set up a sign-in risk policy to monitor for unusual logins. These policies use machine learning to detect suspicious activity and can temporarily block sign-ins and accounts if something’s amiss.
Monitor for unusual applications with access to your users’ data.
Now that accounts are getting more secure by default, attackers are requesting access to user data via apps. And it’s worse if they manage to trick an admin user because then attackers can have longstanding access to an entire organisation that persists even when passwords are changed.
It can be challenging to detect if a user clicks a phishing link and provides a rogue app with access to their mailbox, OneDrive or SharePoint data. So you use Microsoft Cloud App Security to get alerted to unusual oAuth applications with access to your teams’ information.
Be extra vigilant if your data has been exposed in the past
Take extra care if you, or companies you regularly interact with, have been breached before. If attackers have had access to your company data and know who usually communicates with who, and for what purposes, they will try to exploit that information by setting up fake emails to hold their fake conversations with their fake invoices to get your real money.
Need help with phishing in Office 365 or Microsoft 365?
If you need assistance setting-up these policies in your organisation or need a hand cleaning up after a successful phishing attack in Microsoft 365, we’d be happy to help. Reach out to us via chat, or using the form below.
//gcits.com.au/wp-content/uploads/GCITSlogowordpress.png00Elliot Munro//gcits.com.au/wp-content/uploads/GCITSlogowordpress.pngElliot Munro2020-05-27 17:33:392020-07-09 09:37:42How do I stop phishing emails?
Office 365 Advanced Threat protection and Office 365 threat intelligence logs can now be integrated into your SIEM solution.
Threats discovered by these services can be made available on the audit.general workload of the Office 365 Management APIs.
What are the Office 365 Management APIs?
The Office 365 Management APIs are essentially the API version of the Office 365 Unified Audit Log
To get your Office 365 ATP info into your SIEM, you’ll need to have the Unified Audit Log enabled for your tenant. Unfortunately, it’s not enabled by default.
How to enable the Office 365 Unified Audit Log
The Office 365 Unified Audit Log is an important and useful tool which can help you secure your Microsoft Cloud environment. If you’re a Microsoft Partner, we have a longer article on enabling this for your customers’ tenants here, but to enable it for a single tenant, you have two options.
Enable the Office 365 Unified Audit Log via the Security and Compliance Center
You can log into the Security and Compliance Center at protection.office.com as a global or security administrator.
You’ll find the setting under Search and Investigation, Audit Log Search.
If the audit log isn’t enabled, click Start recording user and admin activities
Enable the Office 365 Unified Audit Log via Powershell
Connect your SIEM to the Office 365 Management APIs
Once the audit log is enabled, threats discovered by Office 365 ATP and Threat Intelligence will be available on the audit.general endpoint of the Office 365 Management API. For more information on setting this up, see the official Microsoft documentation here.
//gcits.com.au/wp-content/uploads/GCITSlogowordpress.png00Elliot Munro//gcits.com.au/wp-content/uploads/GCITSlogowordpress.pngElliot Munro2018-10-30 12:48:312019-02-21 13:23:31Office 365 ATP can now be integrated into your SIEM
Some companies will block access to Outlook on the web entirely because they don’t want users to be able to download their company data externally. This new feature strikes a middle ground, so users can still access Outlook on the web, but admins can use conditional access to restrict downloads from Outlook on the web on personal or unmanaged devices.
What is Conditional Access?
Conditional access lets you define different security measures which take effect depending on how users are trying to access your company data. For example a risky sign in according to Azure Active Directory might prompt for MFA, while a sign in from inside your company network on a trusted device won’t. An unmanaged or non-compliant device might not be able to access certain apps, while compliant devices can.
How to set up Conditional Access for Outlook on the web
Add the policy via Azure Active Directory Conditional Access
In this example, we are setting up a conditional access policy for non-compliant devices which prevents users from being able to download attachments via the browser.
Valid values for the -ConditionalAccessPolicy parameter are:
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.
Wait a few hours for the policy to apply. Once it takes effect, the previously selected users on non-compliant devices will not be able to download attachments via Outlook on the web.
What is the user experience?
The ReadOnly policy will ensure that users on non-compliant devices can’t download email attachments through Outlook on the web to their local device. They can only access them via the file viewers in the browser.
If you use the ReadOnlyPlusAttachmentsBlocked value, users will not be able to access attachments via the browser at all.
What license do I need for Conditional Access for Outlook on the web?
Conditional Access requires a subscription with Azure AD P1 or P2.
//gcits.com.au/wp-content/uploads/GCITSlogowordpress.png00Elliot Munro//gcits.com.au/wp-content/uploads/GCITSlogowordpress.pngElliot Munro2018-10-21 21:03:392019-02-21 13:23:33Outlook on the web – Conditional Access
A compromised administrator account or an admin becoming a disgruntled ex-employee is a source of serious risk to a business. This is because traditionally admins can do whatever they want, whenever they want. To address this issue, Microsoft have developed Privileged Access Management.
What is Privileged Access Management?
Privileged Access Management works on the principle of zero standing access. That means that admins don’t have the ability to perform potentially damaging actions all of the time.
When they need to perform a task that may expose sensitive data or has potential to cause a lot of damage, they will be given just enough access to complete the task. And even then, only for a specific time and only following an audited approval process.
You can define which tasks require a privileged access request via the admin portal.
When admins want to perform one of these tasks, they can raise their requests for access via the portal or via Powershell.
A sample Powershell request to perform tasks requiring privileged access approval looks like this:
New-ElevatedAccessRequest -Task 'Exchange\New-JournalRule' -Reason 'Setting Journal per request.' -DurationHours 4
Requests can be automatically or manually approved, and requestors are notified of the approval outcome via email. All privileged access requests and approval process information is recorded for internal reviews and auditors.
Privileged Access Management License requirements
Privileged access management requires Microsoft 365 E5, Office 365 E5 or the standalone Advanced Compliance SKU.
The popular Encrypt-Only policy for Office 365 Message Encryption can now be enabled automatically as part of a DLP (Data Loss Prevention) policy.
What is the Office 365 Encrypt-Only policy?
The Encrypt-only policy is useful because it encrypts the message and prevents it from being intercepted or scanned by other mail systems. To read the messages, recipients need to sign in via a Microsoft, Google, Yahoo or Office 365 account. If they don’t have any of those accounts, they can request a one time password to access and read the email.
It’s called Encrypt-only because other encryption options in Office 365 also enforce policies that prevent a message from being forwarded or printed. The Encrypt-Only policy just encrypts the message and prevents it from being accessed by anyone who shouldn’t.
Enabling Encrypt-Only via a DLP policy
If you are using Office 365 Message Encryption already, you can set up a DLP policy that will enable Encrypt-Only on email messages that match a certain DLP trigger. These policies are configurable in the Security and Compliance Center at https://protection.office.com.
Here is a policy that is set to trigger on emails containing Australian Financial Information:
The action for this policy is to apply the Encrypt-only message encryption policy:
This feature is available now for organisations with Microsoft 365 E3 and E5, Office 365 E3 and E5 or as part of the standalone Azure Information Protection SKUs.
For security and compliance in Office 365, the Unified Audit Log is probably the most important tool of all. It tracks every user and account action across all of the Office 365 services. You can run reports on deletions, shares, downloads, edits, reads etc, for all users and all products. You can also set up custom alerting to receive notifications whenever specific activities occur.
For all of it’s usefulness, the most amazing thing about it is that it’s not turned on by default.
It can be extremely frustrating when you come across a query or problem that could easily be resolved if we had access to the logs, only to find out they were never enabled in the first place. Here’s how to get it set up in your own organisation, or if you’re a Microsoft Partner, how to script it for all of your customers using Delegated Administration and PowerShell.
How to enable the Unified Audit Log for a single Office 365 tenant
If you’re only managing your own tenant, it’s quite simple to turn it on. You can do this in two ways.
How to enable the Unified Audit Log via the Security and Compliance Center for a single Office 365 tenant
Since the PowerShell command for enabling the Unified Audit Log is just one line, I assumed we’d be able to add it as a script block and run it across all of our Office 365 customers at once.
When I tried setting this up, it initially appeared to be working, though I soon received the following error:
The remote server returned an error: (401) Unauthorized.
It looks like Microsoft don’t allow you to run this particular script using Delegated Administration, though I’m not too sure why. You also can’t enable it via https://protection.office.com using your delegated admin credentials, it just seems to revert you back to the settings for your own Office 365 tenant.
In order to enable the Unified Audit Log, we’ll need to activate it using an admin within the customer’s Office 365 tenant. The remainder of this blog post contains the instructions on how to script this process.
Disclaimer
Use the following scripts at your own risk. They are designed to temporarily create Global Admins with a standard password (chosen by you) on each of your customer’s environments. If all goes well, every admin that was created should be deleted automatically. If some tenants fail to enable the Unified Audit Log correctly, the new admin for those tenants will remain (I’ve included a script to remove these ones too). Also, see step 3 for a link to a script that reports on every Unlicensed Office 365 Company Admin in your Office 365 tenant. Use it to verify that none of these temporary admins remain.
This process has three parts
PowerShell Script One: Checking Unified Audit Log Status and creating admin users
PowerShell Script Two: Enabling Unified Audit Log on all Office 365 tenants and removing successful admins
PowerShell Script Three (And Optional Script): Removing unsuccessful admins and checking tenants for all unlicensed admins.
Things you should know beforehand
For the most part, these scripts work. Using these three scripts, I’ve enabled the Unified Audit Log on 227 of our 260 delegated Office 365 customers. However, there are a few error messages that can pop up, and a few reasons that will prevent it working for some Office 365 tenants at all.
Here are a few things to keep in mind:
It doesn’t work with LITEPACK and LITEPACK_P2 subscriptions
In our case these are Telstra customers running the older Office 365 Small Business and Office 365 Small Business Premium subscriptions. You can run our Office 365 Delegated Tenant license report to identify these customers.
It does not work on customers that don’t have any subscriptions, or only has expired subscriptions.
It won’t work for Office 365 tenants that don’t have any Office 365 subscriptions, or if their Office 365 subscriptions have expired. The script will fail for these organisations with the error: The tenant organization isn’t in an Active State. Complete the administrative tasks that are active for this organization, and then try again.
It does not work on customers that only have Dynamics CRM licenses
This script doesn’t seem to run on customers that only have Dynamics CRM Online. It hasn’t been tested with customers that only have Dynamics 365.
You should wait before running the second PowerShell Script
It can take a while for the temporary admin user to receive the appropriate permissions in your customers Office 365 organisation. If you run the second script too soon, the temporary admin may not be able to pull down all the Exchange Online cmdlets to perform the required tasks.
PowerShell Script One: Checking Unified Audit Log Status and creating admin users
This script uses your own delegated admin credentials. It creates a list of all of your Office 365 Customers and reports on their subscriptions. If they have at least one subscription (active or not) it attempts to run an Exchange Online cmdlet to check whether the Unified Audit Log is enabled. If it’s enabled, it does nothing and moves onto the next customer. If it’s disabled, it creates a new user, assigns it to the Company Administrator role and adds a row to a CSV with the tenant ID, customer name and user principal name.
To use the script, copy and paste it into a PowerShell document. You can use Visual Studio Code, PowerShell ISE, or Notepad etc.
Modify the placeholder variables at the top of the script and run it in PowerShell.
<# This script will connect to all delegated Office 365 tenants and check whether the Unified Audit Log is enabled. If it's not, it will create an Exchange admin user with a standard password. Once it's processed, you'll need to wait a few hours (preferably a day), then run the second script. The second script connects to your customers' Office 365 tenants via the new admin users and enables the Unified Audit Log ingestion. If successful, the second script will also remove the admin users created in this script. #>
#-------------------------------------------------------------
# Here are some things you can modify:
# This is your partner admin user name that has delegated administration permission
$UserName = "[email protected]"
# IMPORTANT: This is the default password for the temporary admin users. Don't leave this as Password123, create a strong password between 8 and 16 characters containing Lowercase letters, Uppercase letters, Numbers and Symbols.
$NewAdminPassword = "Password123"
# IMPORTANT: This is the default User Principal Name prefix for the temporary admin users. Don't leave this as gcitsauditadmin, create something UNIQUE that DOESNT EXIST in any of your tenants already. If it exists, it'll be turned into an admin and then deleted.
$NewAdminUserPrefix = "gcitsauditadmin"
# This is the path for the exported CSVs. You can change this, though you'll need to make sure the path exists. This location is also referenced in the second script, so I recommend keeping it the same.
$CreatedAdminsCsv = "C:\temp\CreatedAdmins.csv"
$UALCustomersCsv = "C:\temp\UALCustomerStatus.csv"
# Here's the end of the things you can modify.
#-------------------------------------------------------------
# This script block gets the Audit Log config settings
$ScriptBlock = {Get-AdminAuditLogConfig}
$Cred = get-credential -Credential $UserName
# Connect to Azure Active Directory via Powershell
Connect-MsolService -Credential $cred
$Customers = Get-MsolPartnerContract -All
$CompanyInfo = Get-MsolCompanyInformation
Write-Host "Found $($Customers.Count) customers for $($CompanyInfo.DisplayName)"
Write-Host " "
Write-Host "----------------------------------------------------------"
Write-Host " "
foreach ($Customer in $Customers) {
Write-Host $Customer.Name.ToUpper()
Write-Host " "
# Get license report
Write-Host "Getting license report:"
$CustomerLicenses = Get-MsolAccountSku -TenantId $Customer.TenantId
foreach($CustomerLicense in $CustomerLicenses) {
Write-Host "$($Customer.Name) is reporting $($CustomerLicense.SkuPartNumber) with $($CustomerLicense.ActiveUnits) Active Units. They've assigned $($CustomerLicense.ConsumedUnits) of them."
}
if($CustomerLicenses.Count -gt 0){
Write-Host " "
# Get the initial domain for the customer.
$InitialDomain = Get-MsolDomain -TenantId $Customer.TenantId | Where {$_.IsInitial -eq $true}
# Construct the Exchange Online URL with the DelegatedOrg parameter.
$DelegatedOrgURL = "https://ps.outlook.com/powershell-liveid?DelegatedOrg=" + $InitialDomain.Name
Write-Host "Getting UAL setting for $($InitialDomain.Name)"
# Invoke-Command establishes a Windows PowerShell session based on the URL,
# runs the command, and closes the Windows PowerShell session.
$AuditLogConfig = Invoke-Command -ConnectionUri $DelegatedOrgURL -Credential $Cred -Authentication Basic -ConfigurationName Microsoft.Exchange -AllowRedirection -ScriptBlock $ScriptBlock -HideComputerName
Write-Host " "
Write-Host "Audit Log Ingestion Enabled:"
Write-Host $AuditLogConfig.UnifiedAuditLogIngestionEnabled
# Check whether the Unified Audit Log is already enabled and log status in a CSV.
if ($AuditLogConfig.UnifiedAuditLogIngestionEnabled) {
$UALCustomerExport = @{
TenantId = $Customer.TenantId
CompanyName = $Customer.Name
DefaultDomainName = $Customer.DefaultDomainName
UnifiedAuditLogIngestionEnabled = $AuditLogConfig.UnifiedAuditLogIngestionEnabled
UnifiedAuditLogFirstOptInDate = $AuditLogConfig.UnifiedAuditLogFirstOptInDate
DistinguishedName = $AuditLogConfig.DistinguishedName
}
$UALCustomersexport = @()
$UALCustomersExport += New-Object psobject -Property $UALCustomerExport
$UALCustomersExport | Select-Object TenantId,CompanyName,DefaultDomainName,UnifiedAuditLogIngestionEnabled,UnifiedAuditLogFirstOptInDate,DistinguishedName | Export-Csv -notypeinformation -Path $UALCustomersCSV -Append
}
# If the Unified Audit Log isn't enabled, log the status and create the admin user.
if (!$AuditLogConfig.UnifiedAuditLogIngestionEnabled) {
$UALDisabledCustomers += $Customer
$UALCustomersExport [email protected]()
$UALCustomerExport = @{
TenantId = $Customer.TenantId
CompanyName = $Customer.Name
DefaultDomainName = $Customer.DefaultDomainName
UnifiedAuditLogIngestionEnabled = $AuditLogConfig.UnifiedAuditLogIngestionEnabled
UnifiedAuditLogFirstOptInDate = $AuditLogConfig.UnifiedAuditLogFirstOptInDate
DistinguishedName = $AuditLogConfig.DistinguishedName
}
$UALCustomersExport += New-Object psobject -Property $UALCustomerExport
$UALCustomersExport | Select-Object TenantId,CompanyName,DefaultDomainName,UnifiedAuditLogIngestionEnabled,UnifiedAuditLogFirstOptInDate,DistinguishedName | Export-Csv -notypeinformation -Path $UALCustomersCSV -Append
# Build the User Principal Name for the new admin user
$NewAdminUPN = -join($NewAdminUserPrefix,"@",$($InitialDomain.Name))
Write-Host " "
Write-Host "Audit Log isn't enabled for $($Customer.Name). Creating a user with UPN: $NewAdminUPN, assigning user to Company Administrators role."
Write-Host "Adding $($Customer.Name) to CSV to enable UAL in second script."
$secpasswd = ConvertTo-SecureString $NewAdminPassword -AsPlainText -Force
$NewAdminCreds = New-Object System.Management.Automation.PSCredential ($NewAdminUPN, $secpasswd)
New-MsolUser -TenantId $Customer.TenantId -DisplayName "Audit Admin" -UserPrincipalName $NewAdminUPN -Password $NewAdminPassword -ForceChangePassword $false
Add-MsolRoleMember -TenantId $Customer.TenantId -RoleName "Company Administrator" -RoleMemberEmailAddress $NewAdminUPN
$AdminProperties = @{
TenantId = $Customer.TenantId
CompanyName = $Customer.Name
DefaultDomainName = $Customer.DefaultDomainName
UserPrincipalName = $NewAdminUPN
Action = "ADDED"
}
$CreatedAdmins = @()
$CreatedAdmins += New-Object psobject -Property $AdminProperties
$CreatedAdmins | Select-Object TenantId,CompanyName,DefaultDomainName,UserPrincipalName,Action | Export-Csv -notypeinformation -Path $CreatedAdminsCsv -Append
Write-Host " "
}
}
Write-Host " "
Write-Host "----------------------------------------------------------"
Write-Host " "
}
Write-Host "Admin Creation Completed for tenants without Unified Audit Logging, please wait 12 hours before running the second script."
Write-Host " "
See the Unified Audit Log status for your customers
One of the outputs of this script is the UALCustomerStatus.csv file. You can make a copy of this, and rerun the process at the end to compare the results.
Browse the list of created admins
The script will also create a CSV containing the details for each admin created. This CSV will be imported by the second PowerShell Script and will be used to enable the Unified Audit Log on each tenant.
PowerShell Script Two: Enabling Unified Audit Log on all Office 365 tenants and removing successful admins
This script should be run at least a few hours after the first script to ensure that the admin permissions have had time to correctly apply. If you don’t wait long enough, your admin user may not have access to the required Exchange Online cmdlets.
You’ll need to update the password in this script to reflect the password you chose for your temporary admins in the first script.
To use the script, copy and paste it into a PowerShell document. You can use Visual Studio Code, PowerShell ISE, or Notepad etc.
Modify the placeholder variables at the top of the script and run it in PowerShell.
<# This script will use the admin users created by the first script to enable the Unified Audit Log in each tenant. If enabling the Unified Audit Log is successful, it'll remove the created admin. If it's not successful, it'll keep the admin in place and add it to another CSV. You can retry these tenants by modifying the $Customers value to import the RemainingAdminsCsv in the next run. #>
#-------------------------------------------------------------
# Here are some things you can modify:
# This is your partner admin user name that has delegated administration permission
$UserName = "traini[email protected]"
# IMPORTANT: This is the default password for the temporary admin users. Use the same password that you specified in the first script.
$NewAdminPassword = "Password123"
# This is the CSV containing the details of the created admins generated by the first script. If you changed the path in the first script, you'll need to change it here.
$Customers = import-csv "C:\temp\CreatedAdmins.csv"
# This CSV will contain a list of all admins removed by this script.
$RemovedAdminsCsv = "C:\temp\RemovedAdmins.csv"
# This CSV will contain a list of all unsuccessful admins left unchanged by this script. Use it to retry this script without having to start again.
$RemainingAdminsCsv = "C:\temp\RemainingAdmins.csv"
#-------------------------------------------------------------
$Cred = get-credential -Credential $UserName
foreach ($Customer in $Customers) {
Write-Host $Customer.CompanyName.ToUpper()
Write-Host " "
$NewAdminUPN = $Customer.UserPrincipalName
$secpasswd = ConvertTo-SecureString $NewAdminPassword -AsPlainText -Force
$NewAdminCreds = New-Object System.Management.Automation.PSCredential ($NewAdminUPN, $secpasswd)
Write-Host " "
Write-Output "Getting the Exchange Online cmdlets as $NewAdminUPN"
$Session = New-PSSession -ConnectionUri https://outlook.office365.com/powershell-liveid/ `
-ConfigurationName Microsoft.Exchange -Credential $NewAdminCreds `
-Authentication Basic -AllowRedirection
Import-PSSession $Session -AllowClobber
# Enable the customization of the Exchange Organisation
Enable-OrganizationCustomization
# Enable the Unified Audit Log
Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true
# Find out whether it worked
$AuditLogConfigResult = Get-AdminAuditLogConfig
Remove-PSSession $Session
# If it worked, remove the Admin and add the removed admin details to a CSV
if($AuditLogConfigResult.UnifiedAuditLogIngestionEnabled){
# Remove the temporary admin
Write-Host "Removing the temporary Admin"
Remove-MsolUser -TenantId $Customer.TenantId -UserPrincipalName $NewAdminUPN -Force
$AdminProperties = @{
TenantId = $Customer.TenantId
CompanyName = $Customer.CompanyName
DefaultDomainName = $Customer.DefaultDomainName
UserPrincipalName = $NewAdminUPN
Action = "REMOVED"
}
$RemovedAdmins = @()
$RemovedAdmins += New-Object psobject -Property $AdminProperties
$RemovedAdmins | Select-Object TenantId,CompanyName,DefaultDomainName,UserPrincipalName,Action | Export-Csv -notypeinformation -Path $RemovedAdminsCsv -Append
}
# If it didn't work, keep the Admin and add the admin details to another CSV. You can use the RemainingAdmins CSV if you'd like to try again.
if(!$AuditLogConfigResult.UnifiedAuditLogIngestionEnabled){
Write-Host "Enabling Audit Log Failed, keeping the temporary Admin"
$AdminProperties = @{
TenantId = $Customer.TenantId
CompanyName = $Customer.CompanyName
DefaultDomainName = $Customer.DefaultDomainName
UserPrincipalName = $NewAdminUPN
Action = "UNCHANGED"
}
$RemainingAdmins = @()
$RemainingAdmins += New-Object psobject -Property $AdminProperties
$RemainingAdmins | Select-Object TenantId,CompanyName,DefaultDomainName,UserPrincipalName,Action | Export-Csv -notypeinformation -Path $RemainingAdminsCsv -Append
}
Write-Host " "
Write-Host "----------------------------------------------------------"
Write-Host " "
}
View the successful Office 365 admins that were removed
If the Unified Audit Log was enabled successfully, the newly created Office 365 admin will be automatically removed. You can see the results of this in the RemovedAdmins CSV.
See the remaining Office 365 admins that couldn’t enable the Unified Audit Log
If the Unified Audit Log couldn’t be enabled, the Office 365 admin will remain unchanged. If you like, you can use the RemainingAdmins CSV in place of the CreatedAdmins CSV and rerun the second script. In our case, some tenants that couldn’t be enabled on the first try, were able to be enabled on the second and third tries.
Any tenants that weren’t able to have their Unified Audit Log enabled via PowerShell will still have the Office 365 admin active. This script will import these admins from the RemainingAdminsCsv and remove them.
Once removed, it will add them to the RemovedAdmins CSV. You can compare this to the CreatedAdmins CSV from the first script to make sure they’re all gone.
<# This script will use the admin users created by the first script to enable the Unified Audit Log in each tenant. If enabling the Unified Audit Log is successful, it'll remove the created admin. If it's not successful, it'll keep the admin in place and add it to another CSV. You can retry these tenants by modifying the $Customers value to import the RemainingAdminsCsv in the next run. #>
#-------------------------------------------------------------
# Here are some things you can modify:
# This is your partner admin user name that has delegated administration permission
$UserName = "[email protected]"
# This CSV contains a list of all remaining unsuccessful admins left unchanged by the second script.
$RemainingAdmins = import-csv "C:\temp\RemainingAdmins.csv"
# This CSV will contain a list of all admins removed by this script.
$RemovedAdminsCsv = "C:\temp\RemovedAdmins.csv"
#-------------------------------------------------------------
$Cred = get-credential -Credential $UserName
Connect-MsolService -Credential $cred
ForEach ($Admin in $RemainingAdmins) {
$tenantID = $Admin.Tenantid
$upn = $Admin.UserPrincipalName
Write-Output "Deleting user: $upn"
Remove-MsolUser -UserPrincipalName $upn -TenantId $tenantID -Force
$AdminProperties = @{
TenantId = $tenantID
CompanyName = $Admin.CompanyName
DefaultDomainName = $Admin.DefaultDomainName
UserPrincipalName = $upn
Action = "REMOVED"
}
$RemovedAdmins = @()
$RemovedAdmins += New-Object psobject -Property $AdminProperties
$RemovedAdmins | Select-Object TenantId,CompanyName,DefaultDomainName,UserPrincipalName,Action | Export-Csv -notypeinformation -Path $RemovedAdminsCsv -Append
}
Want to see all the current Office 365 global administrators in your customers tenants?
To confirm that all of the created admins from these scripts have been removed, or just to see which global administrators have access to your customer tenants, you can run the scripts here. If required, there’s a second script that will block the credentials of the admins that you leave in the exported CSV.
//gcits.com.au/wp-content/uploads/GCITSlogowordpress.png00Elliot Munro//gcits.com.au/wp-content/uploads/GCITSlogowordpress.pngElliot Munro2017-03-21 23:00:352019-02-21 13:23:41Enabling the Unified Audit Log on all delegated Office 365 tenants via PowerShell
I ran a small migration on Friday last week that took a lot longer than planned due to a few unexpected issues. The customer was migrating from Telstra’s Office 365 service (AKA syndicated account) to a Microsoft Office 365 account licensed via the CSP model.
This is a pretty standard migration that we run often, though this time I ran into a number of issues.
Since it was a small migration (4 users), and it needed to be moved over in a short amount of time, I opted to do a standard PST migration on an Azure VM. The plan was as follows:
Disconnect the domain from the existing tenant
Add it to the new tenant by moving it to new name servers and verifying the DNS
Create the required users on the new tenant
Set up the Exchange accounts for the old users via their .onmicrosoft.com addresses and export the mail via PSTs
Set up the Exchange accounts for the new users and import the mail
Here’s a few important details regarding the source tenant:
Office 365 licensed via Telstra on a syndicated account
Domain DNS hosted on Microsoft’s name servers
Here are some important details regarding the destination tenant:
Office 365 licensed via CSP model
Domain DNS hosted on external name servers
Problem #1: Cannot create a user with the same UPN as before
My first issue occurred when I started to set up the users on the new tenant. Three out of four worked correctly, though the fourth mailbox (unfortunately the most important one) would not create correctly on the new tenant.
I was given the error OrgIdMailboxRecentlyCreatedException and the message:
Hang on, we’re not quite ready
It looks like your account [email protected] was created 1 hour ago. It can take up to 24 hours to set up a mailbox.
I did some testing and discovered that the error message only appears when I set the User Principal Name to match what it was on the old tenant ([email protected]). If I set it up to use a variation of the old name ([email protected]), it worked instantly.
I suspected this was to do with some internal updating issue with how Office 365 maps usernames to mailboxes, and decided to give it a bit of time.
In the meantime, the customer needed to be able to send and receive as their previous email address. So I logged onto Exchange via Powershell and ran the following cmdlets:
Once this was confirmed working, I set it up on the user’s Outlook profile and kicked off the migration.
I left this running overnight, and in the morning faced a new problem.
Problem #2: Cannot send to BigPond addresses due to SPF issue
The next issue was related to recipients using Telstra BigPond addresses. Emails sent to external domains worked fine, though emails sent to BigPond account would fail instantly. They’d return a message stating that the message was rejected by the recipient email server.
The SPF Headers in the returned email state that there is no SPF records configured for the domain:
I double checked the SPF records on the new name servers and they were configured correctly. I also sent test emails to my own external addresses, and the SPF headers were fine too.
I’m not 100% sure what the cause of the issue here is, though I suspect it is due to the fact that Microsoft used to manage the DNS for this domain via their internal Office 365 name servers. If the change is taking a while to propagate throughout the system, it may still looking at their internal name servers for records relating to this domain.
Solution: Switch Name Servers back to Microsoft
To resolve this issue, I transferred management of the DNS records back to Microsoft’s Office 365 name servers, and within about half an hour, all of the issues were resolved.
I was able to rename the user to the correct email ([email protected]) and users no longer had issues mailing BigPond accounts.
Since I was trying everything to resolve this issue, I’m not sure what the ultimate fix was. Though it seems that switching the name servers back to Microsoft on the new tenant did the most good.
I suspect that this was a DNS propagation problem within Office 365, and may have been resolved in time anyway. If you’re currently experiencing it, moving the DNS to Microsoft’s Office 365 name servers may speed up the resolution.
//gcits.com.au/wp-content/uploads/GCITSlogowordpress.png00Elliot Munro//gcits.com.au/wp-content/uploads/GCITSlogowordpress.pngElliot Munro2016-10-16 17:05:202016-10-16 18:05:56Resolving issues when migrating from Telstra syndicated Office 365 to Office 365 via CSP
Apple has (very slightly) changed the way we add Office 365 email accounts to iOS 10. We’ve taken the opportunity to update our most popular How to video. We’re also giving a big plug for Outlook for iOS. Microsoft have done a great job with this app, and we think it’s a must have for Office 365 users. See how you can get your email under control in our 3 minute video:
//gcits.com.au/wp-content/uploads/GCITSlogowordpress.png00Elliot Munro//gcits.com.au/wp-content/uploads/GCITSlogowordpress.pngElliot Munro2016-09-23 09:45:102019-02-21 13:23:42How to set up Office 365 email on iPhone – Video updated for iOS 10
Skykick automates the migration of email from other platforms onto Office 365, though occasionally it needs a bit of help.
This is especially true when moving from Google Apps or Google for Work to Office 365. These mailboxes can bloat in size due to how both systems manage email folders.
Office 365 (Microsoft Exchange) stores email in folders, while Google gives email labels. The difference is, in Exchange an email can be in only one folder, while in Google an email can have multiple labels. When migrating from Google for Work to Office 365, SkyKick will create Exchange folders for every Google label, and migrate emails that are assigned multiple labels into multiple folders.
This results in a bunch of duplication on the destination system.
When you’re using Skykick to migrate large mailboxes from Google for Work, you may occasionally receive a message advising that the mailbox may exceed the storage limits on Office 365. While this message appears, synchronisation will be paused.
In order to resume the migration for this mailbox you’ll need to do the following:
Confirm you’re using the right retention policy
Enable archiving on the mailbox.
Ensure the archive is running.
Mark the alert as completed.
What are Exchange Retention Policies?
In Exchange, each mailbox is assigned a Retention Policy that contain the retention settings for mail within the mailbox. Retention policies are made up of Retention Policy Tags.
Retention Policy Tags outline how long Exchange is going to keep a user’s mail before performing a specific action on it. For Retention Policy Tags, this action can be PermanentlyDelete, DeleteAndAllowRecovery or MoveToArchive.
When archiving is enabled on a mailbox, the default policy is to archive anything older than two years. This may be enough to get the migration running again, but just in case it’s not, you can create a new Retention Policy Tag with a shorter archive time limit, apply it to a new Retention Policy, then apply the policy to the user you want to archive mail for.
Alternatively, you can edit the default policy (known as Default MRM Policy) or its tags, though this will affect all users that have archiving enabled.
You can create a new Retention Policy and Retention Policy Tags via PowerShell or via the Exchange Control Panel. In Exchange Control Panel, these actions are performed under Compliance Management. In this tutorial we’ll be working in PowerShell.
Setting up a Retention Policy in PowerShell
This new Retention Policy will move any mail older than 1 year into a users archive. It will have one tag.
Connect to Exchange Online via PowerShell as an Exchange Online Administrator
Run the following PowerShell cmdlet
New-RetentionPolicyTag "1 year move to archive" -Type All -RetentionEnabled $true -AgeLimitForRetention 365 -RetentionAction MoveToArchive
Create the new Retention Policy and link the tags
New-RetentionPolicy "One Tag Policy" -RetentionPolicyTagLinks "1 year move to archive"
Assign a retention policy to a user
Set-Mailbox -Identity UserAliasOrEmail -RetentionPolicy "One Tag Policy"
Confirm the Retention Policy was applied correctly by running:
Get-Mailbox -Identity UserAliasOrEmail | ft Name,RetentionPolicy
Enable Archiving on a mailbox.
Once you’ve assigned the policy, you can enable archiving on the user’s mailbox. This can be done in the Exchange Control Panel under Recipients, Mailboxes on the right menu.
In Powershell, you can run the following cmdlet while connected to Exchange Online.
The default cmdlet return is to display the Name, ItemCount, StorageLimitStatus and LastLogonTime of the mailbox. To see more info, append ‘| fl *‘ (minus the quotations) to the cmdlet.
Your archive will probably be empty right now. To start the archive, run the following cmdlet.
Start-ManagedFolderAssistant UserAliasOrEmail
Now, if you run the Get-MailboxStatistics cmdlet a few times more, you’ll see the ItemCount increasing. Providing of course, that there’s email older than a year in the mailbox.
You can also append ‘| fl *‘ to the end of the cmdlet to get the available statistics for the user’s mailbox too. Try it a few times and watch it reduce as items are archived.
//gcits.com.au/wp-content/uploads/GCITSlogowordpress.png00Elliot Munro//gcits.com.au/wp-content/uploads/GCITSlogowordpress.pngElliot Munro2016-08-25 20:36:252016-08-25 21:48:41Working with archive policies in Office 365 and SkyKick
A common requirement for our customers is to forward emails to SharePoint Online lists. This email data usually comes from website forms or enquiry pages, though there’s no out-of-the-box way to extract the form data from an email, and upload it to separate columns in SharePoint list.
Previously I was using Cloud2050 Email Sync, though it relied on software installed on a PC to work, and only worked while that PC was operational and Outlook was open.
Here’s a solution that operates completely in the cloud using Outlook Rules, MailParser.io and Microsoft Azure Logic Apps.
The solution looks like this:
Office 365 forwards email from your website’s form to your mailparser.io address via an Outlook Rule or Exchange Transport Rule.
MailParser.io receives the email, extracts the form data and sends it to an Azure logic app using a Generic HTTP Webhook.
Your Azure Logic App receives the form data, connects to SharePoint Online and adds the form data into the appropriate SharePoint list columns.
Prerequisites:
Sign up for MailParser.io – a free 30 day trial is available
Sign up for Microsoft Azure – use your Office 365 account, a free 30 day trial is available
A SharePoint List set up with the fields required for your form
Setting up MailParser
Once you’ve signed up for mailparser.io, sign in and click Create New Inbox
Give it a name and add some notes:
You’ll be given an email address to forward your form emails to. Keep track of this address, as you’ll need it to receive the emails you send from Outlook or Exchange mail rules. Forward a couple of sample form emails to the address to get started.
Once your emails are received, you can set up your Parsing Rules:
Usually, the mailparser will be able to automatically identify the field names and values from your forwarded email. If it doesn’t, click Try Something Else to give it some help, otherwise click OK, start with this.
Now, we start setting up our Generic Webhook. Click Webhook Integrations in on the left menu, then click Add New Integration.
Click Generic Webhook.
Give it a descriptive name and type in a sample URL (I used http://google.com) into the Target URL field. We need to use a sample first so that we can copy the webhook’s JSON payload. We then use this JSON payload to help generate the actual TargetURL from Azure Logic Apps in the next steps.
Next, click Save and test.
Then Send test data. We expect this to fail, though it will give us the JSON payload.
Copy the text from Body Payload into Notepad or Visual Studio Code.
Set up the Azure Logic App
Log onto Azure at portal.azure.com. If you don’t already have a subscription, you can sign up using your Office 365 account.
Click New, search for Logic App, and click Logic App
Click Create
Complete the fields, placing the Azure Logic App in the region of your choice. You can name the Resource group whatever you like, or use an existing one. Click Create.
Click Edit to start editing your logic app.
Search for Request and click the Request Trigger
Now you can use your copied JSON Body Payload from MailParser.io as a reference for your Request Body JSON Schema.You’ll need to define the data type for each Key-Value Pair in your JSON payload. This allows you to use the separate fields in your Azure Logic App, and add the field data into the appropriate SharePoint columns.The syntax of the Request Body JSON Schema is as follows:
You can use Visual Studio Code, Notepad++ or Notepad to edit this schema so that it describes your JSON Payload.
Replace the properties values with the name of the keys in your JSON payload. Not all fields need to be added to the required array, only the ones that you need to create a valid SharePoint list entry.
In my case, this JSON body becomes the following JSON Schema.
Paste the Schema into the Request Body Schema and click Save.
You will then receive the URL that you can use in Mailparser.io to send your requests:
Next click + New step.
Type SharePoint and click SharePoint – Create item.
You may need to add a Connection to SharePoint Online. If you’re prompted, add a connection using an Office 365 account that has permission to write to the required SharePoint list. If you don’t have a SharePoint list available to accept the data, you’ll need to set one up now before proceeding.
Next enter your site URL. The List Name drop down will be populated with the available lists. You should also see that the Outputs from the Request step are available to use.
The list columns that can accept strings, as well as a few other column types will be available for you to modify. Click in each relevant column and select the relevant output.
Once you’re finished, go back to the Request Step in your Logic App and copy the URL from the Request step
Return to MailParser.io, go back to Webhook integrations, and click Edit.
Paste the URL from your Logic App Request step into the Target URL.
Click Save and test.
Click Send test data.
You should receive a response code of 202 to confirm it was sent successfully.
You can now check Azure Logic Apps to confirm that it ran correctly.
You should also see the new entry in your SharePoint Online list.
Setting up the Outlook Rule
Once you’ve confirmed it’s working, you can set up your mail rules in Outlook or via Exchange to automatically forward emails to your mailparser.io email address.
Right click on an email sent via your web form. Click Rules, then Create rule.
Choose a condition that matches all emails sent via your form, eg. Subject. Then click Advanced Options…
Click Next.
Tick forward it to people or public group, then click people or public group.
Enter the email address from Mailparser.io, click OK, then click Next twice.
Turn on the rule, and choose whether you want to run it on mail already in the same folder.
And that’s it. From now on, any mail sent by your website’s form will be automatically forwarded into mailparser.io, broken up into the relevant fields, and added to SharePoint Online. You can also use Azure Logic Apps to automate a bunch of other business processes. Check out the documentation here.
We may request cookies to be set on your device. We use cookies to let us know when you visit our websites, how you interact with us, to enrich your user experience, and to customize your relationship with our website.
Click on the different category headings to find out more. You can also change some of your preferences. Note that blocking some types of cookies may impact your experience on our websites and the services we are able to offer.
Essential Website Cookies
These cookies are strictly necessary to provide you with services available through our website and to use some of its features.
Because these cookies are strictly necessary to deliver the website, refuseing them will have impact how our site functions. You always can block or delete cookies by changing your browser settings and force blocking all cookies on this website. But this will always prompt you to accept/refuse cookies when revisiting our site.
We fully respect if you want to refuse cookies but to avoid asking you again and again kindly allow us to store a cookie for that. You are free to opt out any time or opt in for other cookies to get a better experience. If you refuse cookies we will remove all set cookies in our domain.
We provide you with a list of stored cookies on your computer in our domain so you can check what we stored. Due to security reasons we are not able to show or modify cookies from other domains. You can check these in your browser security settings.
Google Analytics Cookies
These cookies collect information that is used either in aggregate form to help us understand how our website is being used or how effective our marketing campaigns are, or to help us customize our website and application for you in order to enhance your experience.
If you do not want that we track your visit to our site you can disable tracking in your browser here:
Other external services
We also use different external services like Google Webfonts, Google Maps, and external Video providers. Since these providers may collect personal data like your IP address we allow you to block them here. Please be aware that this might heavily reduce the functionality and appearance of our site. Changes will take effect once you reload the page.
Google Webfont Settings:
Google Map Settings:
Google reCaptcha Settings:
Vimeo and Youtube video embeds:
Other cookies
The following cookies are also needed - You can choose if you want to allow them:
Requests can be automatically or manually approved, and requestors are notified of the approval outcome via email. All privileged access requests and approval process information is recorded for internal reviews and auditors.
A common requirement for our customers is to forward emails to SharePoint Online lists. This email data usually comes from website forms or enquiry pages, though there’s no out-of-the-box way to extract the form data from an email, and upload it to separate columns in SharePoint list.
