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\”

$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


Exchange 2016 CU7 hybrid bug

After deploying a fresh install of Exchange 2016 CU7 to setup a Hybrid deployment to Office 365 I could not federate to Office 365 using the HCW.

HCW is trying to use the cmdlet “Set-FederatedOrganizationIdentifier” but the command “Set-FederatedOrganizationIdentifier” is broken in CU7.

Opening a ticket with MS support they too try the command in their lab environment and confirmed that with the install of CU7 this command does not work.

At this moment, the official Microsoft answer is the following:

For a hybrid scenario, deploy another Exchange 2016 server with CU6 to run the HCW or wait for Exchange 2016 CU8 release.

Exchange 2016 CU7 Mail Flow bug

Hace un par de días hemos desplegado en un entorno de coexistencia con Exchange 2010 un Exchange 2016 con el CU7.
Nada más desplegarlo hemos empezado a tener problemas de flujo de correo con el nuevo servidor Exchange 2016 que  hemos desplegado.
No aceptaba ninguna conexión smtp.
El proceso de  instalación, no dió ningún problema pero el servicio de transporte (Mailbox Transport Delivery) entraba en un loop y se reiniciaba constantemente generando los siguientes errors en el registro de eventos:

Despues de realizar varias pruebas, revisar los eventos de sistema y analizar logs, hemos encontrado un artículo que habla de un bug en la CU7 y nos da la solución:
El problema parece ser que el proceso de instalación no añade los permisos al grupo NETWORK SERVICE en la siguiente clave de registro:

Añadiendo el permiso Full Control al grupo NETWORK SERVICE en la clave de registro de nivel superior ha permitido solucionar los problemas de reinicio del servicio de transporte y restablecer el flujo de correo entre los servidores de Exchange 2010 y Exchange 2016 desplegados en el entorno de laboratorio.

Nota: El usuario Creator Owner debe tener también permisos “Full Control” en la misma clave de registro.

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:

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:

  • 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 -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:

How to move the MFA Service Provider from one Azure subscription to another

Be in mind the following procedure in case you may need to do it.
A couple of days ago a customer decided to create a new Azure subscription and move the MFA service provider from one Azure subscription to the new one.
After hearing this request, the first thing that came to my mind was scary.
But after a few minutes of calm this is what I did.

1- I create a new MFA Provider in a new Azure subscription

2- In each one of MFA server, I delete all files in the following path C:\Program Files\Multi-Factor Authentication Server\Data” except database named Phonefactor.pfdata

3- Note when you delete those files you will lose the MFA provider and subscription association, thus Activation credentials will be required next time you open MFA Manager Console.

4- Generate new Activation credentials from the new subscription. 


5- Activate the license using the new Activation credentials.

6- Activation process will recreate the previous deleted files and will associate the MFA servers with the new Azure Subscription

7- Once the service has been activated you can delete the old MFA provider.

Note that users who are enrolled for phone call or text authentication will not be impacted by this change, but the mobile app push notifications may will stop working for some users that are using the app. If this happened users will need to reactivate the mobile app after the change to start using it again.

Under my scenario, using SMS (one-way) and OATH token , the experience was great and no re-enroll process was required.

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 -NewUserPrincipalName

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 -User -AccessRights FullAccess -InheritanceType All -AutoMapping $false

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

Display all Values in a multi-valued property from PowerShell

Sometimes there are some multi-value properties that can not be displayed from powershell, what can be a bit frustrating.
In the image below there´s an example of it:

Fortunately, there´s a simple way to deal with this situation, and I am sure you will never forget this tip as soon as you know it.
By default the $FormatEnumerationLimit preference variable has a value of 4, and it determines how many items are displayed when a property contains more than a single item.

Keep in mind you can change this variable to get all properties be displayed. It is simple and easy.
You can set this variable to 20, 50 whatever you need, or my favorite: (-1) (it means show me all with no limit)
voilà !!!
Simple and quick.