Field notes: Make the actual source client IP visible for a load-balanced SMTP service

Reading Time: 5 minutes

A typical headache for Microsoft Exchange Server administrators is to setup load-balancing with port 25. They face the issue that, typically in these setups, they no longer see the source client IPs of the actual clients; All traffic is translated and is presented to the SMTP service with the load balancer IP as source. This makes working with receive connectors quite difficult. Many organizations have opted to use multiple virtual IPs and/or different port numbers for the SMTP service…

I think there is a better solution. I think the Direct Server Return option on load balancers provides a better solution; This option forces the load balancer to present the original client IP to the back-end server, in our case: the SMTP service of Microsoft Exchange Server. The back-end server sends response packets directly to the client instead of the load balancer (no Server Network Address Translation (NAT)).

This works fine if you have a single subnet or no firewall(s) between the client, the load balancer and the back-end server. However, if a firewall plays a role in the communications flow, then the firewall will drop the connections because of asymmetric traffic flows; The firewall notices that the TCP information does not match with what it knows.

The (not so) secret sauce

The basic trick is to have the Windows Server respond with the Virtual IP of the load balancer. This way, the TCP packet looks like it’s coming from the load balancer, but actually it’s coming from the back-end server. Most firewalls are happy and allow the traffic.

Note: The communication flow must go back and forth through the same devices. Otherwise, you still experience asymmetric traffic flow and traffic will be blocked.

Another hurdle you may encounter is the need to disable ARP responses to the actual Virtual IP addresses used by the systems. When firewalls come into play, you need to look at the communications path of the traffic. Firewalls can manipulate traffic or do additional translation, that may interfere with what you want to achieve.

How to make the actual source IP address visible to a load-balanced SMTP service

Below, I'll share the steps I follow to setup my solution.

Create a lookback adapter on Windows Server

First, we need to create a lookback adapter on the Windows Server that hosts the SMTP service. Perform the following steps with an account that has administrator privileges:

Click Start, then type cmd in the search box.
When cmd.exe appears, right-click it and choose Run as administrator.
The Administrator: Command Prompt window opens.
On the command prompt, type hdwwiz.exe and press Enter.
Click Next >.
Select Install the hardware that I manually select from a list (Advanced):
Click Next >:
Select Network adapters, then click Next >:
Select Microsoft as the manufacturer. Then, select Microsoft KM-TEST Loopback Adapter:
Click Next >.
Select Next > to confirm the installation:
Click Finish to complete the installation.

Configure the Loopback adapter on Windows Server

Now, we need to configure the network adapters on the Windows Server that hosts the SMTP service. Perform the following steps with an account that has administrator privileges:

Click Start > Control Panel > Network and Sharing Center.
Follow the Change adapter settings link in the left navigation pane.
Select the newly created connection and rename it to Loopback.
Right-click the Loopback connection and choose Properties from the menu.
Confirm that Microsoft Loopback Adapter or Microsoft Loopback Adapter # is displayed in the Connect Using: field. If it is not, return to step 2 and retry the Properties for another adapter.
Deselect every item in the list below This connection uses the following items:, except Internet Protocol (TCP/IP):
Select Internet Protocol (TCP/IP), and click Properties to open the Internet Protocol Version 4 (TCP/IPv4) Properties window.
Select the Use the following IP address option.
Fill in the IP address and Subnet mask fields of the Virtual Service that you configured on your load balancer:
Click the Advanced… button to open the Advanced TCP/IP Settings window.
On the IP Settings tab of the Advanced TCP/IP Settings window, deselect Automatic Metric and provide the value 254:
Switch to the WINS tab.
Select the Disable NetBIOS over TCP/IP option:
Click OK to close the Advanced TCP/IP Settings window.
Click OK to close the Internet Protocol Version 4 (TCP/IPv4) Properties window.
Click OK to close the connection properties.
Switch back to the Administrator: Command Prompt window.
On the command prompt, issue the following command with the LAN interface in scope (the interface that the load balancer points to):
netsh interface ipv4 set interface "LAN" weakhostreceive=enabled
On the command prompt, issue the following commands, too. This time, with the Loopback adapter as the target: (Repeat if you have multiple loopback interfaces)
netsh interface ipv4 set interface "loopback" weakhostsend=enabled
netsh interface ipv4 set interface "loopback" weakhostreceive=enabled
Close the Administrator: Command Prompt window.

The configuration on the Windows Server is now complete.

Configure the load balancer and firewalls

When you have the above configuration in place on the Windows Server that hosts the SMTP service, you can enable the Direct Server Return option in your load balancer.

Concluding

I personally try to implement the above solution in every project, that require me to build a new Microsoft Exchange Server environment with high-availability and load balancing. I've got the Direct Server Return option working with Citrix Netscaler and KEMP Loadmaster implementations.

Reclaim control of your SMTP configuration and regain insight to the source client IP for SMTP traffic and build secure receive connectors again, with the information above.

Test before going into production.

Field Notes: DKIM and missing selector records

Reading Time: 3 minutes

During a project with one of my customers, I was tasked to look at a non-delivery report (NDR) for a mail message. The bounce error was pretty confusing, but after reviewing the headers, we noticed that the DKIM check had failed. This was a bit of a surprise, because the message was sent from Microsoft Exchange Online. The root cause was that the selector mentioned in de header wasn’t resolving. Apparently, Microsoft did not provide the answer to validate the record.

The situation

The organization uses Microsoft Exchange Online and has setup DKIM signing with the accepted domains listed in the tenant. This particular organization owns 70+ domains. For every accepted domain, they have created the required CNAME records. During the validation, roughly 20 domains had a failed active selector entry.

I raised a case with Microsoft Office 365 Support, which confirmed that is was a bug and resolved the issue for my customer. They also informed the product team of this error.

How to setup DKIM

By default Exchange Online signs outgoing message with a DKIM signature. More information can be found here. The validation information recorded in the header points to one of the following records:

selector1-[tenantname]-onmicrosoft-com._domainkey.[tenantname].onmicrosoft.com
selector2-[tenantname]-onmicrosoft-com._domainkey.[tenantname].onmicrosoft.com

To enable DKIM you will also need to setup the following CNAME records in the domain:

selector1._domainkey
selector2._domainkey

Using Windows PowerShell, you can get the full value to use for these DNS records. You can retrieve the information through the Exchange Online PowerShell module. The recommended administrative permission is Security Admin.

Follow these steps:

Connect to Exchange Online using the Exchange Online Powershell module.
Sign in with your cloud administrator credentials.

Give the following command for all existing domains:

Get-DkimSigningConfig | FL Identity,Selector1CNAME,Selector2CNAME

Give the following command for one specific domain:

Get-DkimSigningConfig –identity [domainname]| Format-List Identity,Selector1CNAME,Selector2CNAME

Register the new CNAME records with the Selector[1/2]Cname as value.
After succesfully creating the DNS records, you can activate the DKIM signing configuration. This can be done via the following command:
```
Set-DkimSigningConfig –identity [domainname] –Enabled:$true
```

Note: If the domain is missing, you can create the DkimSigningConfig entry through this powershell command:

New-DkimSigningConfig -KeySize 2048 –DomainName [domainname] –Enabled:$false

Only one selector returns data

With the initial creation of your DKIM configuration, Microsoft populates both selectors in their DNS. After a while, though, only the active selector will be resolvable and the other selector is not. This is by Microsoft's design. The record should be visible again when the key rotates.

How to validate the existing records

The challenge for my customer was to validate the records for all 70+ domains. We can do this manually, but where it the fun in that!? We decided to do it through PowerShell.

The below Windows PowerShell script requires an active session to Exchange Online through PowerShell. The recommended administrative permissions is Security Admin.

We ran the following script:

$domains = Get-DkimSigningConfig |Where-Object {$_.Enabled -like "True"}
$Datenow = Get-date
$FailedLookupslog = "C:\Temp\FailedDKIMrecords.log"
$CheckDNS = @()
$failed = @()

ForEach($domain in $domains){

    $activeSelector1 = $domain.SelectorBeforeRotateOnDate
    $activeSelector2 = $domain.SelectorAfterRotateOnDate

    If($($domain.RotateOnDate.ToUniversalTime()) -gt $($datenow.ToUniversalTime()) ){
         $tempattribute = "$($activeSelector1)Cname"
         $CheckDNS += $domain."$tempattribute"
     }
     else{
         $tempattribute = "$($activeSelector2)Cname"
         $CheckDNS += $domain."$tempattribute"
     }
}

foreach($entry in $CheckDNS){
     $works = Resolve-DnsName -Name $entry -Type txt -erroraction 'silentlycontinue'

     If($works){}
     else{
         Write-host "$entry is not working" -ForegroundColor yellow
         $Failed += $entry
     }

     $works = ""
}

"Domain: , selector:" | Out-File -FilePath $FailedLookupslog

Foreach($fail in $failed){

    if($fail -like "selector1*"){
         $temp = $domains | where{$_.selector1Cname -like $fail}
     }
     else{
     $temp = $domains | where{$_.selector2Cname -like $fail}
    }
     "$($temp.Domain) , $fail" | Out-File -FilePath $FailedLookupslog -Append
}

The failed active selector entries were listed in the logfile.

Concluding

Organizations that enable the DKIM feature rely on Microsoft to maintain the information and keep it up-to-date. As a consumer of this feature you need to trust, but verify that it’s still works as designed.

By using the script in the blog, you can automate, verify and let it report to your ticketing system for review and follow-up actions.

Field Notes: Meeting the requirements for Interoperability between Microsoft Teams and Microsoft Exchange Server

Reading Time: 3 minutes

In this blog post, I want to walk you through my experiences with setting up and enable the interoperability between Microsoft Teams and on-premises Microsoft Exchange Server environments.

Since the beginning of this year, Microsoft Teams adoption has seen a tremendous uptick in usage. Organizations needed to adopt Microsoft Teams as their Unified Communications (UC) platform, but the other cloud migrations went on the back burner or were not even in scope anymore for this year. All is fine, until somebody asks: "I don’t see my calendar in Microsoft Teams… Can you fix this?"

Sure we can. In this blog post, I'll walk you through the process of enabling the interoperability between the Microsoft Teams service and the on-premises Microsoft Exchange Server environment.

Requirements

Let's start with listing the Microsoft requirements and what they actually mean in real life:

Known requirements

We start with the known requirements as listed here. Summarized these are:

The employee identities need to be synchronized to Azure AD;
The organization needs to have the Exchange Hybrid option in Azure AD Connect;
OAuth authentication between your on-premises Exchange and Exchange Online organizations needs to be configured;
Microsoft Teams scheduling of meetings by delegates require an additional partner application;
The employees need to have to be licensed: the Microsoft Teams license to be specific;
The on-premises Microsoft Exchange Server environment needs to run Microsoft Exchange Server 2016 CU3 or a newer version of Microsoft Exchange Server.
Good to know: The Microsoft hybrid Agent (Modern Exchange Hybrid) cannot be used for the Microsoft Teams calendar integration. It is listed here in the constraints of the Microsoft Hybrid Agent.

My approach

When a customer asks “I want to have my calendar visible is Microsoft Teams, is this possible for us and what do we need to do?”, then this is my approach:

To see if it’s even possible to realize the interoperability, we need to validate the current on-premises Microsoft Exchange Server environment in terms of the version: It needs to run at least Microsoft Exchange Server 2016 with CU3. The importance of this question is in the availability of the new AutodiscoverV2 and the new REST-based application programming interface (API) in the Exchange Web Services (EWS) capabilities. But that is not all: In order to benefit from these new capabilities, the mailbox needs to be homed on a Exchange Server 2016 CU3 or higher mailbox server. If this is all true, then I validate if Autodiscover service and Exchange Web Services of Exchange Server 2016 is accessible from the internet. If not, the organizations must be willing to allow this.

Initial checks

This results in the following checks:

Autodiscover and Exchange Web Services (EWS) need to be accessible from the internet and pointing to a Microsoft Exchange Server that runs at least Microsoft Exchange Server 2016 CU3;
The mailboxes for the employees in scope need to be homed on a Microsoft Exchange Server hat runs at least Microsoft Exchange Server 2016 CU3;
The employees must have Microsoft Teams licenses assigned;
Good to Know: Microsoft Teams will not use the configured hybrid configuration within Exchange Online, but trusts the native Autodiscover functionality. Via autodiscover.domain.tld it is pointed to the on-premises environment or via SRV records it needs to point to the on-premises environment.
Good to Know: Autodiscover (http) redirect will not work for the Microsoft Teams integration. This might impact the current public certificates that an organization might currently use.

If any of requirements are not met or not possible to achieve, then the integration is a NO GO.

Further implementation information

When the initial requirements are all met, we can ask the following questions:

Are there any Microsoft Exchange Server left in the organization that run Microsoft Exchange Server 2010?
If a Microsoft Exchange Server 2010 is present in the environment, then the Exchange Hybrid configuration wizard will not create the OAuth configuration with Azure AD during the setup and we need to do it manually.
Is a Exchange Hybrid configuration desired and on the roadmap for the organization?
Exchange Hybrid is a requirement from Microsoft for the interoperability between Microsoft Exchange Server and Microsoft Teams. If we cannot use the Exchange Hybrid configuration wizard (which is the preferred option), we need to configure the Oauth configuration manually.
Is it required that delegates need to be able to make appointments on behalf of the delegator?
If so, we need to perform steps 2 and 3 of the instructions listed here. The steps will provision the trust for the Skype for Business online integration.
Can we configured the Exchange Hybrid Writeback permission on the AD Connector account in Active Directory for Azure AD Connect?
Within Azure AD Connect we need to enable the synchronization option for the Exchange Hybrid feature. This requires that the configured service account has the correct writeback permissions for Exchange attributes. The list of required attributes to which we need write permissions is listed here.

Concluding

Compared to what is documented in the Microsoft docs and the real world, some parts are missing in the explanation or the requirements list of Microsoft. In this blog post I want to give you my past experience and help you with the little details to enable organizations to implement the calendar integration.

Field notes: What is the current default SMTP certificate for your Exchange Server environment?

Reading Time: 3 minutes

The last couple of weeks I have been working with several Microsoft Exchange Server environments. I encountered lots of expired certificates. Organizations wanted help with that.

One of the questions that kept coming back was:

Do I press Yes to change the default certificate, when I enabled the certificate for SMTP?

The official answer is to press No. The recommend practice is to leave it like it is. However, it begs another question:

How can I see the current default SMTP certificate?

I'll answer this latter question in this blog post.

What is the default SMTP certificate used for?

When you install Microsoft Exchange Server on a Windows Server installation, it creates a self-signed certificate with a validity period of 5 years. This certificate is assigned as the initial default SMTP certificate. This certificate is used for the mutual TLS connections between the Microsoft Exchange Servers within an Exchange Organization. This certificate is also presented to external mail systems when mutual TLS is required.

Normally, Microsoft Exchange Server admins:

Configure a dedicated certificate for this connector, or;
Configure the fully-qualified domain name (FQDN) on the connector to match the certificate.

How do I find the current default SMTP certificate?

One would assume that you would be able to see the current certificate with native tooling provided by Microsoft.

Let's test this assumption: Open the Microsoft Exchange Management shell. Connect to the Microsoft Exchange Server environment. Execute the Get-ExchangeServer Windows PowerShell cmdlet. Examine the output. See, the information is not there.

But we're close…

Where can I find it then?

The Get-ExchangeServer Windows PowerShell cmdlet retrieves the information that is configured in the configuration container of Active Directory. In this configuration container, the Exchange Server environment configuration is stored for the entire Active Directory forest.

Specifically, Get-ExchangeServer retrieves all Active Directory objects from the follow location:

CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Exchange Organization Name,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=tld

Note:
The Exchange Organization Name portion of the above location is the name used with the initial installation of a Microsoft Exchange Server in the Active Directory environment.

Each object that is retrieved contains multiple attributes. One of these attributes is msExchServerInternalTLSCert. This attribute contains the actual certificate used by the environment. If you look it up trough ADSI Edit (adsiedit.msc), then you'll find a string of number (hex, octal, decimal) values.

Not very human readable… And definitely not useful to determine the actual certificate.

PowerShell to the rescue!

We now know the Active Directory object and attribute to look for. Let's bring it all together and solve the riddle using Windows PowerShell.

Getting ready

In order to run this script you need to have:

Active Directory PowerShell module on the machine
The account used, must have at least the View-Only Configuration Management role assigned to it in the Exchange Server environment
This script can be run from the PowerShell ISE console
Before running, a target Exchange Server must be specified

Running PowerShell

Run the following PowerShell script:

#Specify a name of one of the Exchange Servers

$TargetExchangeServer = "Your Exchange Server"

$ExistingSessions = Get-PSSession

if($ExistingSessions.ConfigurationName -notcontains "Microsoft.Exchange"){

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "http://$TargetExchangeServer/PowerShell/" -Authentication Kerberos

Import-PSSession $Session

}

else{

Write-Host "Use existing session" -ForegroundColor Green

}

#Get all Exchange Servers in the environment

$ExchangeServers = (Get-ExchangeServer |Where-Object {$_.ServerRole -like "mailbox"} )| Select-Object Name,DistinguishedName

$Results = @()

#Process Information

ForEach($Server in $ExchangeServers){

$TransportCert = (Get-ADObject -Identity $Server.DistinguishedName -Properties *).msExchServerInternalTLSCert

$Cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2

$CertBlob = [System.Convert]::ToBase64String($TransportCert)

$Cert.Import([Convert]::FromBase64String($CertBlob))

$server | Add-Member -MemberType NoteProperty -Name DefaultTLSCertSubject -Value $Cert.Subject

$server | Add-Member -MemberType NoteProperty -Name DefaultTLSCertFriendlyName -Value $Cert.FriendlyName

$server | Add-Member -MemberType NoteProperty -Name DefaultTLSCertThumbprint -Value $Cert.Thumbprint

$server | Add-Member -MemberType NoteProperty -Name DefaultTLSCertExpireDate -Value $Cert.NotAfter

$Results += $Server

}

#Show result
$Results | Out-GridView

Interpreting the result

The script outputs a Windows PowerShell Grid View window. An example of the result is shown here:

Concluding

I hope this article gives you more insight where the information of the default SMTP certificate is stored and how to retrieve it. This information can be valuable, when you try to gain insights into the certificates used by the Microsoft Exchange Servers.

Security Officer: Please block the iOS native mail app (for) now!

Reading Time: 5 minutesLast week an announcement was made: The native mail app in Apple's iOS has zero-day vulnerabilities, deemed critical. No patch is available at this time.

More information about the vulnerability can be found here.

For you as IT admin this means that you probably have work to do. The main questions you may be facing from management or your security officer are:

How many people use the native mail app in our organization?
Can you block access to people using the native mail app?

I'll answer these two questions in this blog post, for the on-premises environment and for Office 365.

How many people use the native iOS mail app?

To gain insights into the current usage of the native mail app, we need to use Windows PowerShell.

Note:
Although the official support for Exchange Server 2010 ends October 2020, I 'm also adding the commands for Exchange Server 2010 to this blogpost. Organizations are (unfortunately) still using it.

To execute the commands you will need to be connected through the Exchange Management Shell. This applies to all versions of Exchange. The minimum permissions needed are Recipient Administrator.

Query Microsoft Exchange Server 2010

For Micrososft Exchange Server 2010, we need the Get-ActiveSyncDevice and Get-ActiveSyncDeviceStatistics Windows PowerShell cmdlets.

Use the below lines of Windows PowerShell to query Microsoft Exchange Server 2010 for usage of the native iOS mail app:

$AlliOSDevices = Get-ActiveSyncDevice -Filter {(DeviceOs -like "iOS*") -and (ClientType -eq "EAS")}

$QueryResults = $AlliOSDevices | %{Get-ActiveSyncDeviceStatistics -Identity $_.Identity} | Sort-Object -Descending -Property LastSuccessSync

$QueryResults | Export-Csv C:\temp\iOSDevicesResult.csv -Delimiter ","

$QueryResults | Out-GridView

Note: the warning shown in the example, is caused by the fact that for Microsoft Exchange Server 2013 and higher a different command is recommended. See Query Microsoft Exchange Server 2013 or Later for more information.

The results are now available on the C:\temp folder on the server. Load the results in Microsoft Excel and the last successful synchronization is shown on top.

Query Microsoft Exchange Server 2013, or later, and Microsoft Exchange Online

For Microsoft Exchange Server 2013, newer versions of Microsoft Exchange Server and for Microsoft Exchange Online (part of Microsoft Office 365 and Microsoft 365), we need the Get-MobileDevice and Get-MobileDeviceStatistics Windows PowerShell Cmdlets.

Use the below lines of Windows PowerShell to query Microsoft Exchange Server 2013, and later, for usage of the native iOS mail app:

$AlliOSDevices = Get-MobileDevice -Filter {(DeviceOs -like "iOS*") -and (ClientType -eq "EAS")}

$QueryResults = $AlliOSDevices | %{Get-MobileDeviceStatistics -Identity $_.Identity} | Sort-Object -Descending -Property LastSuccessSync

$QueryResults | Export-Csv C:\temp\iOSDevicesResult.csv -Delimiter ","

$QueryResults | Out-GridView

The results are now available on the C:\temp folder on the server. Load the results in Microsoft Excel and the last successful synchronization is shown on top.

How to block the iOS native mail app

Using the previous scripts, we known who is using the native iOS mail app. The service desk and/or security officer can use direct communications to these employees. Their message should be that use of the native mail app is (about to be) disabled. The employees should configure the Microsoft Outlook app for iOS to regain access to e-mail on their mobile devices.

Block Access

To create the block rules for iPad and iOS, we are using Windows PowerShell with an active management connection to the Microsoft Exchange Server Environment. We recommend to be be logged in as Organization Administrator of the Exchange Server environment.

In Exchange Online you'll need to have the Exchange Administrator role. The Windows PowerShell cmdlet that we are going to use is New-ActiveSyncDeviceAccessRule.

To block access for iPad and iPhones, please use the following lines of Windows PowerShell:

New-ActiveSyncDeviceAccessRule -Characteristic DeviceType -QueryString "iPhone" -AccessLevel Block

New-ActiveSyncDeviceAccessRule -Characteristic DeviceType -QueryString "iPad" -AccessLevel Block

Remove block rule

To rollback or remove the rules, you can use the following lines of Windows PowerShell from the Exchange Management connection. The Windows PowerShell cmdlet we are going to use is: Remove-ActiveSyncDeviceAccessRule.

Remove-ActiveSyncDeviceAccessRule "iPhone (DeviceType)" -confirm:$false

Remove-ActiveSyncDeviceAccessRule "iPad (DeviceType)" -confirm:$false

Is it working?

After applying the policy, it is a recommended practice to review mobile devices. In the past, a device may be manually allowed and will continue to function after activating the block rules.

To gain insight in the block status and the excluded devices, we are going to use the same Windows PowerShell cmdlets as before. This time, we're adding an additional where filter: We are going to filter out the ‘DeviceAccessStateReason’ with the global value. These devices will be automatically blocked. Below, I'll show the example for Microsoft Exchange Server 2010 and for Microsoft Exchange Server 2013 and later.

Is it working on Microsoft Exchange Server 2010?

Use the following lines of Windows PowerShell to figure out if the block rule is working on Microsoft Exchange Server 2010:

$AlliOSDevices = Get-Activesyncdevice -Filter {(DeviceOs -like "iOS*") -and (ClientType -eq "EAS")}

$QueryResults = $AlliOSDevices | %{Get-ActivesyncDeviceStatistics -Identity $_.Identity} | where {$_.DeviceAccessStateReason -ne "Global" }| Sort-Object -Descending -Property LastSuccessSync

$QueryResults | Export-Csv C:\temp\iOSDevicesBlockedAllowed.csv -Delimiter ","

$QueryResults | Out-GridView

Is it working on Microsoft Exchange Server 2013, or later, and Microsoft Exchange Online?

Use the following lines of Windows PowerShell to figure out if the block rule is working on Microsoft Exchange Server 2013, newer versions of Microsoft Exchange Server and for Microsoft Exchange Online (part of Microsoft Office 365 and Microsoft 365), :

$AlliOSDevices = Get-MobileDevice -Filter {(DeviceOs -like "iOS*") -and (ClientType -eq "EAS")}

$QueryResults = $AlliOSDevices | %{Get-MobileDeviceStatistics -Identity $_.Identity} |where {$_.DeviceAccessStateReason -ne "Global" }| Sort-Object -Descending -Property LastSuccessSync

$QueryResults | Export-Csv C:\temp\iOSDevicesBlockedAllowed.csv -Delimiter ","

$QueryResults | Out-GridView

Concluding

Don't panic when you get difficult questions from management and\or the security officer. The answer is Yes, thanks to Windows PowerShell.

We can see who is using the native app and we can block access. With a few lines of Windows PowerShell we gain insight and take control.

I hope that the above information is helpful to you in regaining security, until the zero day in the iOS native mail app is fixed.

Field Notes: How has your Azure AD Connect been configured?

Reading Time: 7 minutesAs a consultant, I see a lot of different environments. Often, I need to know the answer to one of the most important questions:

What did you select during the setup of Azure AD Connect?

The answers vary:

A colleague did the setup and has left the company, department…

A external supplier did the setup for a pilot or part of a project…

Of course, these answers are supported by a lack of documentation.

Why is this important to know?

During the setup of Azure AD Connect, the Microsoft Azure Active Directory Connect wizard shows several options. These options are only shown during the initial setup. Some of these options are not displayed when you perform the View Configuration task after initial configuration. Some options cannot be altered after the initial configuration; They can only be achieved with a new installation of Azure AD Connect, except for one option.

Initial setup options

Let's look at these options as they are presented chronologically as you perform a Custom settings installation of Azure AD Connect:

Uniquely identifying your users
(cannot be altered after initial config)

When you install your first Azure AD Connect instance and configure the connection to Azure Active Directory, the following setup options are presented on the Uniquely identifying your users page of the Microsoft Azure Active Directory Connect wizard:

The top half of the Uniquely identifying your users page shows the option to configure how Azure AD Connect should behave, when the organization has deployed a user account forest and resource forest Active Directory topology. However, a more common scenario is when an organization merges with another organization and is consolidating resources; Instead of two Exchange Server environments or Skype for Business Server environments, all is provisioned from one forest.

Custom installation - sourceAnchor configuration

The bottom half of the Uniquely identifying your users page allows the option to choose the source anchor.

The Microsoft documentation on these options can be found here.

Azure AD sign-in configuration
(cannot be altered after initial config)

The second option is the selection of the source for the Azure Active Directory UserPrincipalName on the Azure AD sign-in configuration page of the Microsoft Azure Active Directory Connect wizard.

During the installation wizard, the administrator can choose which on-premises attribute should be used to populate the Azure Active Directory UserPrincipalName attribute.

The Microsoft documentation on this option can be found here.

Filter users and devices
(can be altered after initial config)

The last option I want to discuss is intended for pilot use only. The option on the Filter users and devices page enables administrators to scope what objects are synchronized, based on a group membership instead of a selection of Organizational Units (OUs) and containers:

The Microsoft documentation on this option can be found here.

What is configured in Azure AD Connect

Of course, we want to answer the initial question.

Native tooling

There are two ways to get the configuration from the Azure AD Connect server using native tooling:

Azure AD Connect's Graphical User Interfaces (GUIs)
Windows PowerShell

The GUI provides almost all the information you need. However, if you have configured the “pilot” group filtering, you see it’s enabled, but you cannot see the actual configured group. If you also want to see the group. Then you will need to go to the second option.

The second option is to use Windows PowerShell to get all the configured options for your Azure AD Connect configuration.

Third-party tooling

A third option is to use a third party tool called Azure AD Connect Configuration Documenter.

Using the Graphical User Interface

The steps below describe how to use the graphical user interface (GUI) to get information on the configured options:

Sign in interactively to the Azure AD Connect server using an account that is a member of local Administrators and the SyncAdmins groups.
Open the “Azure AD Connect ” link to the Microsoft Azure Active Directory Connect wizard, found on the desktop or start menu.
Click Configure on the Welcome to Azure AD Connect page:
Select the View current configuration task on the Additional tasks page and click Next.
All the configuration options are shown on the Review Your Solution page:

So let's review our configured solution:

The first part provides information on the Azure AD tenant, the Active Directory environments it is connected to and the Azure AD Connect service account per Active Directory environment:

The second part provides the actual configuration of the Azure AD Connect instance:

The top two rows of this information shows the configured options that are mentioned before:

In the table below I map the configuration item to the setup option.

Configuration Item	Setup Option
SOURCE ANCHOR
USER PRINCIPAL NAME
SYNC CRITERIA
FILTER OBJECTS TO SYNCHRONIZE BY GROUP

As mentioned before, the GUI shows that we configured a group to scope synchronization, but it will not show the actual configured group:

The Windows PowerShell steps below provides the method to get the actual group name

Using Windows PowerShell

The steps below describe how to use Windows PowerShell to get information on the configured options:

Sign in interactively to the Azure AD Connect server using an account that is a member of local Administrators and the SyncAdmins groups.
Open Windows PowerShell as administrator.
Issue the following line of Windows PowerShell: Get-ADSyncGlobalSettingsParameter | Select-Object * | Sort-Object -Property Name | Out-GridView
It will now show the configured options of Azure AD Connect:

In the Out-GridView windows there are multiple entries. In the table below a overview of the configuration items and setup option is shown:

Configuration item	Setup Option
Microsoft.OptionalFeature.GroupFiltering
Microsoft.SynchronizationOption.AnchorAttribute
Microsoft.SynchronizationOption.JoinCriteria
Microsoft.SynchronizationOption.UPNAttribute

To get the actual configured group that is configured on the Filter users and devices page, follow these steps:

Issue the following line of Windows PowerShell in the elevated Windows PowerShell window:( (Get-ADSyncConnector).GlobalParameters | Where-Object {$_.Name -eq "Connector.GroupFilteringGroupDn"} ).Value
It will now show the configured group:

Using the Azure AD Connect Configuration Documenter

The Azure AD Connect Configuration Documenter is a free tool to document the configuration of Azure AD Connect. It is available on GitHub.

I use this tool every time when an update is needed of a Azure AD Connect instance. I use it to get a snapshot of the configuration before an update and after the update. Also, I use it to compare the configuration between Azure AD Connect instances, when an organization has one or more Azure AD Connect Staging Mode instances running or has instances running in their development, test, acceptance and production environments.

To use the tool, follow the provided instructions located in the readme file on GitHub.

The tool creates a report. In the report, there is a Global Settings section and this looks similar to the output when you'd use Windows PowerShell:

At time of writing this blog. The Azure AD Connect Configuration Documenter doesn’t show the configured group on the Filter users and devices page, if the option to filter based on a group has been activated.

Concluding

For me, as a consultant, it's important to provide as much documentation as possible to the customer about what I did or what is configured.

When I configure Azure AD Connect, I use the Problem Step Recorder (PSR) a lot, which is available by default on Windows installations and installations of Windows Server with the Desktop Experience. PSR takes a full screenshot when you click your mouse and when you type and leave the entry field. The PSR file of my activities is the raw draft for the actual as-built documentation that I always deliver to my customers.

I hope every consultant and systems administrator uses the same method, but it's not always the case. If not, I use the described methods to retrieve the actual Azure AD Connect configuration.

I hope to have given you the tools to retrieve the configuration yourselves, and find out what is actually configured, too.

Field notes: Azure AD Identity protection end-user perspective

Reading Time: 5 minutes

In my previous blog post Field Notes: Azure AD Identity Protection we looked at the administrator perspective on Identity Protection. The focus was how to protect your corporate accounts.
In this blog the focus is the end-user (employee and IT staff) experiences.

The experiences I want to share are:

Suspicious Activity
User with a high-risk classification
Behavior observed with Azure AD Password-less sign-in.

Employee experience

Suspicious Activity

When an employee uses a browser or modern authentication, this dialog will appear, when the conditions of a risky sign-in have been detected:

Risky sign-ins are medium-risk events. Example triggers for events are:

Signing-in from two separate locations in the world with an impossible travel time. However, this can also be detected, when a corporate VPN is used and it forces all internet traffic through the tunnel. Another false positive might be detected when using remote systems in datacenters located in another location. Please note that 'location' in Identity Protection-speak is usually in the scale of a small country or US state.
For example: 10:10 am sign-in from Amsterdam and on 10:15am a sign-in from Redmond, WA in the USA.
Using a VPN connection, proxy or browser to anonymize your real IP location. NordVPN and the Tor browser are great examples and we use them to demo Identity Protection detections effectively.
Connecting from a public IP address with a bad reputation, due to infected machines at that location. For example, connections from internet cafes and public hotspots.

Employee with a high-risk classification

When an employee meets the threshold of medium events or the situation score calculation algorithm generates a high score, the user will be blocked from access, by default.

The user feedback I received, is that the authenticator app gives an error message, and tells the end-user to contact the systems administrator. Microsoft Office Outlook will not connect on your machine.

The only way to know what is going on is to use a browser to sign into the Office 365 environment, for example.

Depending on your tenant's Identity Protection configuration, an employee can validate and reset the password to his or her account or be blocked until an administrator forces a password reset for the affected user account.

Note: Microsoft has added the ability to do a self-service password reset via the Authenticator app. This paves the way for resolving high-risk events from within the Microsoft Authenticator app, if the policy allows end-user reset in a high risk situation.

Azure AD Password-less sign-in

If you have configured Password-less sign-in with Azure AD, the user experience is different, when it comes to risky sign-in sessions. The end-user will not be shown a prompt that the sign-in session is calculated to be risky. A mere alert will be generated in Azure AD Identity Protection and depending on the configuration, sent to the IT staff for notification. The event itself will be automatically closed, because multi-factor authentication is performed.

IT Staff experience

Out-of-the box alert

In all three cases above, Azure AD Identity Protection will generate an alert e-mail that a risky event has occurred. This alert is sent to the configured mail recipients. The message itself does not contain the actual account information or threat level. In order to consume this information, you need to sign-in the Azure AD Identity Protection portal.

The message the IT staff receive is shown below:

Graph API

If the security teams wants faster insights, they should leverage the Graph API and create an automation option to retrieve the Azure AD Identity Protection data. This option is documented here. An example output is shown below, using the PowerShell code provided in the Microsoft documentation:

Using the Graph APU enables the IT/security staff to retrieve detailed information on security events, directly from the tenant. This enables automation and faster insights into what is going on. An automation example is a query is formatted to a readable event for the organization's SIEM solution or Log Analytics.

Processing a risk event

Azure AD Identity Protection has three levels of administrator access.

Role	Able to do	not able to do
Global Administrator	Full access to Azure AD Identity Protection, Onboard Azure AD Identity Protection
Security Administrator	Full access to Azure AD Identity Protection	Onboard Azure AD Identity Protection, reset passwords for a user
Security Reader	Read-only access to Azure AD Identity Protection	Onboard Identity Protection, remediate users, configure policies, reset passwords

The minimum level IT staff personnel need to process the security events and give back control to the end users, is to be assigned the Security Administrator role to gain access to Azure AD Identity Protection. Additionally, they need the User Administrator or Password Administrator role to reset passwords for affected users for them to regain access to the company resources.

In a event of a blocked user, the IT admin has two choices after reviewing the security events first for the affected user.

When the events are legitimate, they can force a reset of the user password and provide the end-user with the new temporary password.
When event are false positives, they can mark them as such in the web portal, so Azure AD machine learning can learn from it and lower the security score of the end-user in the process.

A better approach

The information that Microsoft supplies in case of a high risk event is minimal for an end-user. He or she is not properly informed on what is going on and what steps to take.

From a service desk/IT staff perspective, the information alert mail doesn’t contain direct information. It is not directly useful to prioritize the event. To gather the actual information, the IT admin needs to login and lookup the event. This takes time. Depending on the workload, it may not always be visible straight away.

The combination of the above two experiences is that when an employee contacts the service desk, time is lost with troubleshooting, because the error is not properly shown from the end-user interface, unless when using a browser.

A solution here, would be an automation script that runs in the background and registers an incident in the ticket system and an event for SIEM, based on the employee information and give it a high priority. In addition to that, a separate e-mail can be sent to the security staff with more detail. Also a brief e-mail can be sent to the service desk to be informed that a user is blocked.

This way, service desk personnel can be properly informed and can even pro-actively contact the effected employees and guide them through the process.

Concluding

Don't waste valuable time troubleshooting risky sign-ins and high-risk events that block employee sign-ins. Get the pro-active edge.

Field notes: Azure AD Identity Protection

Reading Time: 7 minutes

I'm managing several Azure AD tenants with a wide variety of licenses and settings. I've had a focus on Azure AD Identity Protection for the last weeks, so I'm sharing my field notes with you.

What is Azure AD Identity Protection?

Let's start with a little introduction.

Microsoft has a lot of experience with identities in the cloud. These identities are used for public cloud features like onedrive.com and outlook.com, but also for the organizational cloud identities within Azure Active Directory.

With the presence of one or more Azure AD Premium 2 license(s) in the tenant, an organization can benefit from additional security options and automated actions to secure their organizational identities within that tenant. The global administrator account that is going to be used to activate the feature, should be enabled with a Azure AD Premium P2 license.

Azure AD Identity Protection Features

With the activation of Azure AD Identity protection, organizations benefit from the following features:

Detection

Evaluates every sign-in sessions to existing sign-in behavior of the employee
Evaluates the User Risk on the overall behavior and detection points
Provides custom recommendations to improve overall security posture by highlighting vulnerabilities
Integrates with Password protection within Azure AD
Microsoft obtains from several recourses passwords that are known on the Internet. With this information, Password Protection checks the existing password if the are known on the internet. If so, the user risk becomes high risk within Azure AD Identity protection. Depending on your policies, actions need to be taken before a employee can start working again.

Investigation

Provides investigation capabilities
Provides an overview of all risk events and/or user accounts.
Alerts the security team(s) of events
Offers workflow capabilities so admins can
– Initiate immediate password reset
– Report false positive events

Risk-based (Conditional Access) policies

Provides the capability to request additional user conformation, in sense of a multi-factor authentication or even block access, if a sign-in session is been found risky
Provides the capability to request a password reset or even block access, if the user account has been marked to be at risk
Integrates with Conditional Access as conditions
Enforces MFA registration

Differences in Azure AD Identity Protection functionality between licenses

All the editions of Azure AD provide information on Risk Events and Risky Users. Depending on the edition, more features, information and controls become available.

Azure Active Directory Free merely offers a list of users flagged for risk and a overview of risk events.
Azure Active Directory Premium (P1) offers more access to the underlying risk events that have been detected for each report.
Azure Active Directory Premium P2 offers the most detailed information about all underlying risk events and it also enables organizations to configure security policies that automatically respond to configured risk levels. To enable these policies and response mechanisms, admins need to configure Azure AD Identity Protection.

Note: Azure AD Premium 2 is part of the EMS E5 and Microsoft 365 E5 bundles, but can also be bought separately.

Screenshots of a Azure AD Free edition risk event and Risky user panel:

Screenshots of a Azure AD Identity Protection risk event and Risky User details panel:

Azure AD Identity Protection Configuration Options (P2-only)

This section shows the configuration options that are available for Azure AD Identity protection:

MFA registration

The first configuration item I want to explain is the ability to manage the MFA registration for the user accounts in use within the organization. This ensures that user accounts that are used to sign in to the Azure AD environment need to have the Azure MFA settings in place in order to continue:

The settings are stored in the strongauthenticationdetails attribute. These attributes can be reported upon.

User risk

The second configuration item controls what to do if Azure AD Identity Protection calculates that the user risk reaches the Medium or High thresholds. This risk is of the user object itself.

In the example below, the configuration is shown for the situation in which the user risk is High; the affected person need to change the password for his or her account, before he or she can continue working with it.

Note: When the identities are synchronized for an on-premises environment, it is my advice to enable the self service password reset (SSPR) feature for the Azure AD tenant.

Sign-in risk

The third configuration item governs the action based on the risk level of an actual sign-in session of a user account.

In the example below, the configuration shows that when a sign-in session is calculated to be Medium and above, an additional multi-factor authentication needs to be performed to validate the sign-in attempt:

Azure AD Identity Protection Alerts (P2-only)

When policies are in place, an administrator also should configure the notification e-mails to the intended department, when a risk level of a user account is calculated to be Medium or higher for example:

Here's an example of a notification e-mail and a weekly digest:

User experience

Let's look at the result of the configured policies from an end-user perspective, but also with the admin perspective following through.

Risky sign-in

In this example, my test user logs in via a Tor browser and provides his username and password. After clicking Next the sign-in is processed by Azure AD, Conditional Access and Azure AD Identity Protection. Due to a Tor browser being used, the session is marked suspicious and Azure AD asks me to perform an additional MFA challenge, to verify the sign-in attempt:

After a successful MFA challenge, my test user can continue to use the Office 365 portal:

Azure AD Identity protection will report this session to the configured recipients in the alert page. And also the event is visible in the report, but marked Closed (resolved) due to the MFA challenge resolution in the policy:

User Risk sign-in

When a user account hits a risk level of High, the policy states that he or she should change the password for the account before he or she can continue. I recreated the High user risk level by using the Tor browser again to sign-in several times, starting the MFA challenge, but not completing it on all occasions.

In Azure AD Identity Protection the user account is now listed with a High risk level and the password needs to be changed. The configured alert recipients receive another e-mail with the notification that a user is at risk.

And if the person now tries to login in to the web portal under normal circumstances the following happens:

The person who signs in needs to perform an MFA challenge:
The person needs to update the password for his or her account:
After a successful change, the person now has access to his or her Office 365 portal:

Concluding

Microsoft provides organizations the ability to see if cloud identities are at risk independent of licenses. As an admin, use this to your advantage and take this into account for the health/assessment processes of your environment; include this in your security reports. Additionally, if your tenant is equipped with Azure AD Premium P1 or Premium P2 licenses, ensure you use password protection.

When your Azure AD tenant is using Azure AD Premium P2 licenses, expand your identity defenses with Azure AD Identity Protection. Make use of Microsoft's knowledge and resources to minimize security breaches.

Enable Valimail Single Sign-On with Azure Active Directory

Reading Time: 6 minutes

In my previous blogpost, I described how to enroll Valimail Monitor for Office 365. The initial setup is based on credentials, stored at Valimail. This results in another set of credentials that needs to be remembered, needs to be stored in a password vault, another set that may be leaked…

Additional admins and/or auditors also need to create an additional password for Valimail in order to gain access, adding to the problem.

There must be a better way…

Supported SSO Providers

Valimail has the capability to enable Single sign-on based on SAML2 matching the primary email address of a enabled user:

As you can see in the below screenshot, they currently support Okta and OneLogin. These SSO Providers have already created an application in their solution.

I felt it's random that Azure AD is not listed as an SSO Provider… Microsoft provides Valimail's services for free to Office 365 tenants; organizations that have Azure AD, too.

I wondered if I could make SSO work in my tenant, using SAML2 authentication. I can say: It works in my tenant! Below are the steps to make it work in your Azure AD tenant, too.

How to make Valimail SSO work with Azure Active Directory

Azure Active Directory doesn’t have Valimail as a listed enterprise application in the application gallery.

However, Microsoft provides the ability to Add your own app (for non-gallery applications), based on SAML-authentication:

Create an Enterprise App for Valimail in Azure Active Directory

In order to make it work. Write down the company name listed by the account information, on the account settings page on the Valimail webpage. I performed the following steps for Azure Active Directory in the Azure Portal to configure an enterprise application and enable it for SAML2-authentication:

Open a supported browser and navigate to the Azure Portal.
Sign in with an account that has the Global administrator, Application administrator or Cloud application administrator role assigned to it.
Perform multi-factor authentication and/or privileged identity management, if prompted.
Navigate to Azure Active Directory in the left navigation pane.
In Azure AD's second navigation pane, click on the Enterprise applications node.
Click on + New Application.
Click on the Non-gallery application tile.
Provide the application name. I choose to name the application Valimail, but your organization's naming convention may dictate something different.
Click on Add.
In the new panel that appears, click on Properties.
Set the option: User Assignment required? to No.

Note:
If you decide to limit the number of users that may use the application, leave this option to Yes and assign the users via the Users and groups option.
Click on Save.
Click on Single sign-on.
Click on the SAML tile.
Click on the pencil to the right of the Basic SAML Configuration text to start editing the SAML configuration:
Configure your Basic SAML Configuration as shown below:
1. Reconstruct the account information name for example Contoso B.V. to contoso-b-v and use this in the sign-on URL
2. Identifier (Entity ID): https://app.valimail.com
3. Reply URL (Assertion Consumer Service URL): https://app.valimail.com/sso/consume
4. Sign on URL: https://app.valimail.com/sso/accounts/contoso-b-v/sessions/new/
5. Relay State: https://app.valimail.com/users/sign_in
Click on the Save button and close the panel.
Click on No, I’ll test later.
Don’t change anything in User Attributes & Claims. You don't need to, anyway.
Download the Federation Metadata XML and save it to a file on your device.

The configuration of the enterprise application in Azure Active Directory is now complete.

Enable Single Sign-On in Valimail

Now that Azure Active Directory is configured and the federation metadata is stored on the device, it is time to configure Valimail:

Open a supported web browser and navigate to https://app.valimail.com/home.
Provide the email address of a account that has the owner role in Valimail:
Provide the password for the email address in Valimail:
Perform 2-factor authentication, if it’s configured.
In the Valimail Portal, click on your name and click on Account settings.
Click on the Setup button next to Single Sign-on:
Scroll down to IDP Metadata File field and click on the Browse… button:
Select and upload the Federation Metadata XML downloaded from Azure Active Directory from your device.
Click on Enable Single Sign-on.
You're now automatically signed out.
To sign back in, provide the email address of an account that has the owner role in Valimail.
Click on Sign in with SSO:
You’re redirected to Azure Active Directory.
Depending on your authentication method and configuration, you're automatically signed in to Azure Active Directory and redirected back to the Valimail Portal:
Your Valimail application is now configured with Single Sign-on (SSO) using Azure Active Directory.

Conclusion

I feel in every organization the use of a single source of authentication for business applications should be promoted. For SAML, OAuth and OpenID Connect-based authentication, Azure Active Directory is a perfect candidate to be acting as Identity Provider (IdP) for SaaS applications. This reduces the management overhead, especially when a delegated admin leaves the company and the non-Azure Active Directory accounts are improperly registered or are not part of the normal offboarding procedure.

The main benefit of creating a enterprise application within Azure Active Directory is you can apply your organization's Conditional Access policies. This way, a company can control the access and conditions for employees and even admins to gain access to the application. For instance, if an owner of the Valimail application tries to log on, Conditional Access will trigger multi-factor authentication, if it’s not performed already.

So take 5 minutes of your time and register and activate Single Sign-on for Valimail with Azure Active Directory.

Valimail Monitor for Office 365: Your Free DMARC Reporting Tool

Reading Time: 3 minutesOn their security blog on the 3rd of June 2019, Microsoft announced that Valimail Monitor for Office 365 is available. This option enables organizations using Exchange Online from Office 365 for their company mail to leverage DMARC.

The Road to securing E-Mail

Cyberattacks are common these days. These attacks can be actively targeting your organization over the internet or through incoming emails.

Reputation of your name and mail on the internet are important these days. Reputation attacks via email are achieved by spoofing; sending e-mail messages on behalf of your domain. To counter this, you can:

Enable SPF (Sender Policy Framework) records, and;
Enable DKIM (DomainKeys Identified Mail)

This is a common practice. However, after you have enabled this, you don't get any feedback about the attacks or invalid sources. To gain this insight you will need to activate DMARC (Domain-based Message Authentication, Reporting and Conformance). After you’ve enabled DMARC, via a simple DNS TXT record, you will start receiving automated mail messages with an XML file as attachment on the e-mail address listed in the TXT record.

In short: if you want to gain the insight, who is using your domain on the internet, start using DMARC.

Valimail to the rescue!

With Microsoft’s announcement, you get access to Valimail; a free tool to gain these insights.

Stop processing the XML files by hand or scripting tools. We all love (free) automation, right?

Requirements

To gain access to this information, you already need to have setup the following:

- Existing SPF record containing all the authoritative mail sources
- Enable DKIM on your mail flow (activated by default in Office 365).
  For outgoing mail, a transport agent can be installed on the on-premises Exchange Server or activated as an option on your anti-spam solution.
- Activated a basic DMARC record in your DNS domain, for example:
  "v=DMARC1; p=none; rua=mailto:reports@example.com".
  This example shows you’re using DMARC1 and you monitor existing connections. Please report findings to reports@example.com.

How to set it up

Follow these steps to set it up:

First go to the following website: https://go.valimail.com/microsoft.html
Fill in the required information.
Now wait for response from the Office 365 team of Valimail.
Update your DNS record with the requested entry and test the record.
Wait for your initial invite to create a login account.
When the invite is sent, accept the invite and configure a password for your account.

Tip!
Don’t forget to enable 2-factor authentication on your account or configure Azure AD single sign-on as described in Enable Valimail Single Sign-On with Azure Active Directory.

Conclusion

I have discussed DMARC before with customers and it's a valuable option to gain insight who is sending e-mail messages on behalf of your DNS domain. The only problem was, how to translate the XML files.

Yes, other tools are available, but for most, you will need to pay a fee to use.

ValiMail is free for organizations using Office 365, so why not use it? Regain control over your mail domain, today.

The (not so) secret sauce

How to make the actual source IP address visible to a load-balanced SMTP service

Create a lookback adapter on Windows Server

Configure the Loopback adapter on Windows Server

Configure the load balancer and firewalls

Concluding

The situation

How to setup DKIM

Only one selector returns data

How to validate the existing records

Concluding

Requirements

Known requirements

My approach

Initial checks

Further implementation information

Concluding

What is the default SMTP certificate used for?

How do I find the current default SMTP certificate?

Where can I find it then?

PowerShell to the rescue!

Getting ready

Running PowerShell

Interpreting the result

Concluding

How many people use the native iOS mail app?

Query Microsoft Exchange Server 2010

Query Microsoft Exchange Server 2013, or later, and Microsoft Exchange Online

How to block the iOS native mail app

Block Access

Remove block rule

Is it working?

Is it working on Microsoft Exchange Server 2010?

Is it working on Microsoft Exchange Server 2013, or later, and Microsoft Exchange Online?

Concluding

Why is this important to know?

Initial setup options

Uniquely identifying your users (cannot be altered after initial config)

Azure AD sign-in configuration (cannot be altered after initial config)

Filter users and devices (can be altered after initial config)

What is configured in Azure AD Connect

Native tooling

Third-party tooling

Using the Graphical User Interface

Using Windows PowerShell

Using the Azure AD Connect Configuration Documenter

Concluding

Employee experience

Suspicious Activity

Employee with a high-risk classification

Azure AD Password-less sign-in

IT Staff experience

Out-of-the box alert

Graph API

Processing a risk event

A better approach

Concluding

What is Azure AD Identity Protection?

Azure AD Identity Protection Features

Detection

Investigation

Risk-based (Conditional Access) policies

Differences in Azure AD Identity Protection functionality between licenses

Azure AD Identity Protection Configuration Options (P2-only)

MFA registration

User risk

Sign-in risk

Azure AD Identity Protection Alerts (P2-only)

User experience

Risky sign-in

User Risk sign-in

Concluding

Supported SSO Providers

How to make Valimail SSO work with Azure Active Directory

Create an Enterprise App for Valimail in Azure Active Directory

Enable Single Sign-On in Valimail

Conclusion

The Road to securing E-Mail

Valimail to the rescue!

Requirements

Uniquely identifying your users
(cannot be altered after initial config)

Azure AD sign-in configuration
(cannot be altered after initial config)

Filter users and devices
(can be altered after initial config)