User Profile
liamherbert1105
Copper Contributor
Joined 6 months ago
User Widgets
Recent Discussions
Composite Authentication via on premise connectors
Edit: this doesn't seem to now work for outbound mail. But for inbound, comp auth is still passing. Prefacing this with, this is all in my testing across multiple Exchange Online environments. I have also raised a Microsoft support ticket for it. Consider a mail-flow scenario where an email enters EOP, is then redirected to a 3rd party service. The email is then sent back to EOP via an on-premise connector. This allows for both inbound and outbound email to be redirected. A partner type inbound connector does not allow external relay. Then we have authentication. On the first hop to EOP, assume SPF/DKIM/DMARC/ARC/CompAuth passes. On the re-delivery to EOP after the 3rd party has interacted with the email, it is likely SPF/DKIM will fail and therefore DMARC will. ARC should pass. However, it is known that composite authentication is not calculated against emails received via an on-premise type connector. Microsoft changed their on-premise type inbound connectors on approx 24th June 2024, to make several properties "partner connector" only. This includes RequireTLS and RestrictDomainsToCertificate. Assuming our connector is using a unique accepted domain per tenant (which is required per MS documentation), and this value is set in the TlsSenderCertificateName parameter. After the changes on the 24th, I set the RestrictDomainsToCertificate value to $false, so that I could continue to edit the connector in future. This is because MS made it impossible to edit a connector with that value set - they have since reverted this restriction. However, I found that the value set for my TlsSenderCertificateName had changed slightly. Instead of xyz.domain.com, it has a special character prepended to it. This was unicode character "LEFT-TO-RIGHT MARK" https://unicode-explorer.com/c/200E. So it looked like (character)xyz.domain.com, note that it's not a visible character. Following this, all my inbound emails, being delivered after the 3rd party service, had composite authentication calculated. With no other changes, it was compauth=none. If I added the TLSSenderCertificateName, simply xyz.domain.com, to the Trusted ARC Sealers configuration, then it would show compauth=pass reason=130. The special character isn't visible in the GUI, but if you run Get-InboundConnector you can see the character taking up the space. If I override it in PowerShell and set it to the certificate without the character, composite authentication is disabled again. But now, I can manually set the character and it enables it. I can validate that this works for outbound relayed mail also, which would fail if the connector was configured incorrectly. Try it out: Set-InboundConnector -identity "yourConnector" -TlsSenderCertificateName "yourCertName" Make sure you prepend the "yourCertName" with the "LEFT-TO-RIGHT MARK" charcater from here https://unicode-explorer.com/c/200E(you can copy it to clipboard from there).241Views2likes0CommentsCreate/Edit On-Premise type inbound connector in UI after cmdlet update
Following the updates on 24th July to the New/Set-InboundConnector cmdlets, you can no longer create Inbound connectors of type on-premise in the UI. You get the error: Microsoft.Exchange.Management.Tasks.ConnectorNotApplicablePropertyException|The properties 'RestrictDomainsToCertificate' are not applicable to connector of type 'OnPremises' with the current combination. Connector creation or modification aborted. Essentially, the RestrictDomainsToCertificate and RestrictDomainsToIPAddresses parameters were updated to only be allowed for partner connectors. This is understandable, since these elements aren't considered for emails delivered via on-premise connectors anyway. However, if you try and create an on-premise connector in the Exchange Online UI, particularly for certificated based auth, the RestrictDomainsToCertificate is set to $true by default in the UI, even though the PowerShell param default is $false. If so, you can still make the connector, you just need to do so via PowerShell, and either omit the -RestrictDomainsToCertificate parameter or explicitly set it as $false. If you need to edit an existing connector that was created with this set to true, you need to set it to false first before editing, and again, only via PowerShell. Set-InboundConnector -Identity "connectorID/name" -RestrictDomainsToCertificate:$false527Views0likes6Comments
Groups
Recent Blog Articles
Re: Enhanced Filtering for Connectors - Improving Deliverability and Minimizing False Positives
Hi The_Exchange_Team, how does this change detect a legitimate DKIM body hash failure where the trusted third party modified the email. Assuming a scenario with third party gateway that does not sup...0likes0Comments