How to create a custom DLP rule in Office365

Yesterday, I was helping to a customer in order to create a new custom DLP policy to protect Spanish Identity Card Number (DNI) across the email communications.
I could not find any help in internet, so that´s why I decided to post how I did it.

  • First I created a custom policy using an XML unicode file
  • I use the script “Create-XML-1.3.ps1″ downloaded from Technet here:

https://gallery.technet.microsoft.com/office/Custom-DLP-XML-Generation-43846c75

The script will create the entire file, top to bottom, but you can use the code listed below as a XML template

The Regular Expression match pattern used to catch DNI on email communications was: ([0-9]{8,8}[A-Za-z])

You can use the following tools if you are not familiar with regular expressions:

https://regexr.com/
https://regex101.com/

  • I keep the file “demo.xml” in the path “C:\temp” in my computer
  • Then I connect to “Office 365 Security & Compliance Center” from a PowerShell using the following instructions

$cred= get-credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.compliance.protection.outlook.com/powershell-liveid/ -Credential $cred -Authentication Basic -AllowRedirection
Import-PSSession $Session

  • Then I use the following cmdlet to import my custom xml file to Office 365:

New-DlpSensitiveInformationTypeRulePackage -FileData ([Byte[]]$(Get-Content -Path “C:\temp\demo.xml” -EncodingByte -ReadCount 0))


Aditionally you can use the following cmdlets to manage Data Loss Prevetions Rule Packages using PowerShell.

  • New-DlpSensitiveInformationRulePackage
  • Get-DlpSensitiveInformationRulePackage
  • Set-DlpSensitiveInformationRulePackage
  • Remove-DlpSensitiveInformationRulePackage

Note this cmdlets are only available in the Office 365 Security & Compliance Center.
XML File used to Match DNI:

Advertisements

Cmdlets to be in mind in O365

When you are managing mailboxes in Office 365 you need to keep in mind some cmdlets that can help you to manage some tasks. Here above you have some examples:

When “UserprincipalName” attribute has been changed onprem but changes are not being applied in Azure Active Directory this cmdlet will help you to force the change:
Set-MsolUserPrincipalName -UserPrincipalName example@mydomain.es -NewUserPrincipalName example@mynewdomain.es

When you need to remove deleted users:
GetMsolUser –ReturnDeletedUsers
GetMsolUser –ReturnDeletedUsers | Remove-MsolUser –RemoveFromRecycleBin -force


When you need to add permissions to a Shared Mailbox and disable Automapping:
Add-MailboxPermission -Identity example@mydomain.es -User example@mynewdomain.es -AccessRights FullAccess -InheritanceType All -AutoMapping $false

When you need to change language in a Shared Mailbox:
get-mailbox example@mydomain.es | fl *lan*
get-mailbox example@mydomain.es | Set-Mailbox -Languages es-ES
get-mailbox example@mydomain.es | Set-MailboxRegionalConfiguration -LocalizeDefaultFolderName


Task Scheduler has disappeared in AADCONNECT

The new version of the AADConnect has changed the way to configure the directory synchronization schedule and the manual start.
Don´t get crazy searching the task schedule from prior versions because in this new release has disappeared.
A new Powershell module has been set for this purpose.
Go to PowerShell and run Get-ADSyncScheduler.
It will show you something like this:

By default the synchronization period is 30 minutes and synchronization process is disabled (SyncCycleEnabled)
Run Set-ADSyncScheduler -MaintenanceEnabled $false -SyncCycleEnabled $true to enable the synchronization process cycle.
Run Set-ADSyncScheduler –CustomizedSyncCycleInterval if you want the scheduler to run at any other frequency than the default 30 minutes.
Run Start-ADSyncSyncCycle -PolicyType Initial to initiate a manual Initial synchronization.
Run Start-ADSyncSyncCycle -PolicyType Delta to initiate a manual Delta synchronization


I can´t add a new subdomain in Office365

I tryed today to add a new subdomain in Office 365 and I get the following error:
“i.in.com is a subdomain of a domain that was added by using the Microsoft Online Services
Module for Windows PowerShell so you´ll need to also use Windows PowerShell to add i.in.com
To Microsoft Online Services”

When I try to add i.in.com subdomain from Windows Powershell i get the following error.
“Unable to add this domain. It is a subdomain and its authentication type is different from
the authentication type of the root domain”
New-MsolDomain -Name i.in.com

New-MSOLFederatedDomain -DomainName i.in.com
“Failed to connect to Active Directory Federation Services 2.0 on the local machine.
Please try running Set-MsolADFSContext before running this command again”

Solution:
I ran the following cmdlet from my ADFS server on premises.
Connect-Msolservice

Set-MsolADFSContext –Computer (FQDN of my ADFS server)
Then I ran the following cmdlet
New-MSOLFederatedDomain -DomainName i.in.com