User Profile
liamherbert1105
Copper Contributor
Joined Jul 15, 2024
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).401Views2likes0CommentsRe: Create/Edit On-Premise type inbound connector in UI after cmdlet update
Yeah I can now set to $true for those parameters too. PowerShell spec sheet remains the same, probably jumped ahead without the front end update and are waiting for that. Or the server response that provides the error can't service it today due to the current network outage...413Views0likes0CommentsRe: Create/Edit On-Premise type inbound connector in UI after cmdlet update
Yeah it seems they've only edited the articles available via the community/github. The others must be waiting for internal MS edits? In my environments, you are able to create inbound connectors restricted to IP and certificate, but it seems that the respective RestrictDomainsToCertificate and RestrictDomainsToIPAddresses parameters are set to true always in the UI. You can still set SenderIPAddresses and TlsSenderCertificateName in the UI. It does seem that now if you're delivering via an on premise type connector, you must send via TLS, since you can't set it to false as that'll error out "partner connectors only". This might cause issues for organizations delivering from on premise SMTP servers, who want to relay via 365 without TLS, a common scenario. Wouldn't surprise me if they remove on-premise type connectors from the UI, since they're specialist scenario connectors, such as for in-line services (think Exclaimer or metadact). In fact, as a result of this update, composite authentication is now calculated from emails delivered via on-premise connectors. Which is big new for vendors in that space.443Views0likes2CommentsRe: Properties are not applicable to connector of type 'OnPremises' with the current combination.
I've had confirmation from Microsoft that those connector properties are no longer, and have never been, applicable to on-premise type connectors. So although the UI can't be used now, you only need to set affected properties to $false in PowerShell and then you may continue to edit them as required (only in PowerShell).381Views0likes0CommentsRe: Create/Edit On-Premise type inbound connector in UI after cmdlet update
I've had confirmation from Microsoft that those connector properties are no longer, and have never been, applicable to on-premise type connectors. So although the UI is useless now, you only need to set affected properties to $false and then you may continue to edit them as required.500Views0likes4CommentsCreate/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:$false682Views0likes6Comments
Recent Blog Articles
No content to show