Renew token signin certificate for Office 365 and Azure Active Directory when you have a non windows federate service

A few days ago I had to renew the token signin certificate in the Security Token Service (non windows) deployed on premises.

In this case the Security Token Service was running under F5 BIG-IP Access Policy Manager: Authentication and Single Sign-On

Once I did it, the question was,

Should i do anything else in Azure and O365 to maintain the trust federation?

If you have a Windows Federation Service, typical Known as ADFS, you don´t need to do any extra task.

By default, ADFS includes an auto-renewal process called AutoCertificateRollover.

If you have ADFS 2.0 or later, Office 365 and Azure AD automatically update your certificate before it expires when AutoCertificateRollover is set to True.

You can check this value running the cmdlet Get-ADFSProperties

But in this case the answer to this question is YES.

I don´t have a Windows Federation Service, so I had to do an extra task to update my signin certificate in order to maintain the Trust Federation.

At this point I am going to explain what I did.

First at all, I saved the new certificate as pf-signing.crt in my computer in the following path: c:\temp

I opened a new file in notepad and added the following lines:

Note: Be in mind to put your Office 365 domain name first.

$certFile = “C:\temp\pf-signing.cr”

$cert = [IO.File]::ReadAllText($certFile)

$cert = $cert.replace(“—–BEGIN CERTIFICATE—–“,””)

$cert = $cert.replace(“—–END CERTIFICATE—–“,””)

$cert = $cert.replace(“`r”,””)

$cert = $cert.replace(“`n”,””)

$domainName = “myO365domain”

$protocol = “SAMLP”

Set-MsolDomainFederationSettings -DomainName “$domainName” -SigningCertificate “$cert” -PreferredAuthenticationProtocol $protocol

Then I saved it as a PowerShell script file cert-update.ps1 in C:\temp folder.

Then I opened Azure Active Directory Module for Windows PowerShell to connect to my Office 365 tenant with admin credentials

This can be done by running connect-msolservice

And finally I runned the PowerShell script created above in the local path: c:\temp

.\cert-update.ps1

Advertisements

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:


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