Share via

How to implement anti-bruteforce protection in front of Exchange server 2019 DAG?

Sergey 45 Reputation points
2026-05-02T17:36:15.3666667+00:00

We have the following infrastructure:

  • Microsoft Exchange Server 2019 in a DAG configuration
  • Exchange is located inside a corporate/internal network with no direct Internet access
  • Only gateway/NAT devices can forward ports into the internal network
  • We use IMAPS and SMTPS

We would like to build an intermediate proxy layer between the gateway and Exchange.

The desired topology is something like:

Internet -> Gateway/NAT -> HAProxy -> Exchange 2019 DAG

The main goal is not only to proxy ports 993/587/465, but also to detect failed authentication attempts and automatically ban offending IP addresses.

For example, we are interested in responses such as:

AUTH LOGIN failed because of LogonDenied

535 5.7.3 Authentication unsuccessful

The traffic flow looks like this:

Client -> Gateway -> HAProxy -> Exchange

Exchange -> HAProxy -> Client

At the response stage from Exchange, we would like to:

  • inspect AUTH FAIL / LogonDenied responses
  • obtain the real client IP address
  • dynamically build a blacklist
  • block IPs directly on the proxy layer (fail2ban/ipset/nftables/pfSense API, etc.)

Questions:

  1. Can HAProxy actually inspect IMAPS/SMTPS traffic deeply enough to detect AUTH failures returned by Exchange?
  2. Is SSL termination required on the proxy for this?
  3. Has anyone implemented a similar design specifically with Exchange 2019 + DAG?
  4. Would a better approach be:
    • parsing Exchange logs
    • sending failed IPs to fail2ban/pfSense
    • blocking them on the gateway/firewall instead?
  5. What is the best way to preserve the real client IP address all the way to Exchange?
  6. Does it make sense to consider alternatives such as:
    • Dovecot proxy
    • nginx stream
    • stunnel
    • rspamd
    • postfix relay instead of HAProxy?

The main issue is that with standard TCP passthrough mode, the proxy cannot see AUTH LOGIN failed responses, while Exchange can.

However, we would prefer the blacklist to be managed at the proxy layer rather than directly on the Exchange servers.

I would appreciate any real-world production examples or recommendations.

Exchange | Exchange Server | Other
Exchange | Exchange Server | Other

A robust email, calendaring, and collaboration platform developed by Microsoft, designed for enterprise-level communication and data management.Miscellaneous topics that do not fit into specific categories.

0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Hin-V 15,085 Reputation points Microsoft External Staff Moderator
    2026-05-02T19:20:48.3333333+00:00

    Hi @Sergey

    Good day, and thank you for reaching out. 

    I understand that your goal is to add a proxy layer in front of Exchange to handle authentication attempts, rather than relying solely on Exchange itself.  

    In this scenario, it is important to consider that IMAPS and SMTPS traffic is protected by TLS encryption. In a typical TCP passthrough configuration, a proxy such as HAProxy does not have visibility into the authentication responses returned by Exchange, as the traffic remains encrypted end-to-end. As a result, the proxy layer cannot reliably detect authentication failures or make blocking decisions based on those responses.

    While enabling SSL/TLS termination on the proxy could provide the required visibility, this approach introduces additional complexity and effectively changes the trust boundary of the solution. It can also increase operational overhead, and is not commonly adopted for Exchange IMAP/SMTP deployments.

    In contrast, Exchange has full visibility into authentication outcomes and provides comprehensive protocol logging. I recommend leveraging Exchange logs to identify failed authentication attempts and then automating IP blocking at the firewall or gateway layer. This approach achieves the same objective of blocking offending IP addresses while preserving end‑to‑end encryption and minimizing architectural complexity.

     Please note that this summary is based on my own findings and may not fully address your concerns. To help you reach your goal more effectively, I recommend engaging with [GitHub Community Forum] for a deeper technical dive or to connect with individuals who have relevant experience and expertise. Some approaches may behave differently or be restricted depending on your specific environment and configuration. These forums include many experienced developers and Microsoft specialists who can assist with troubleshooting and guidance.   

    Apologies for redirecting you to the relevant development support team. At this time, I do not have access to your specific tenant configuration, and my testing environment is limited. I also do not have visibility into third‑party products or access to developer‑level insights, so I’m unable to provide a definitive answer from that perspective. Accordingly, my guidance is based solely on available Microsoft documentation and products. That said, I will do my best to provide additional insight where possible. 

    I hope this helps. 

    If you have any additional concerns, feel free to comment below. I would be more than happy to assist. 

    Note: Please follow the steps in [our documentation] to enable e-mail notifications if you want to receive the related email notification for this thread. 

    Was this answer helpful?

  2. AI answer

    2026-05-02T17:36:38.3866667+00:00

    Exchange Server itself already implements basic anti-bruteforce behavior on IMAP authentication: it allows four failed AUTHENTICATE/LOGIN attempts before dropping the session, but it does not enforce cross-session limits.

    Because the provided information focuses on Exchange behavior and not on HAProxy or other third‑party proxies, only the following can be stated:

    1. Exchange IMAP anti-bruteforce behavior
      • For IMAP (port 993 in the described setup), Exchange Server 2019 follows the documented behavior for failed AUTHENTICATE/LOGIN attempts: after four failed attempts in a single session, the server drops the session.
      • There is no built-in cross-session lockout or IP-based blocking in Exchange itself; session limits are per connection only.
    2. Network/firewall considerations between Exchange servers
      • In a DAG and multi-server environment, any firewall between Exchange servers must allow essentially any-to-any communication between Exchange servers and between Exchange servers and domain controllers. Restricting ports between Exchange servers can cause connectivity and management issues.
      • A real-world case showed that enabling any-to-any ports between Exchange 2013 and 2019 servers resolved issues such as:
        • Warnings like “Exchange can't connect to the Information Store service…” when administering databases across servers.
        • ECP errors when editing databases or accessing settings on another server.
      • This implies that any proxy or firewall layer inserted between Exchange servers (or between Exchange and domain controllers) must not break or restrict required internal communication.
    3. Hybrid / modern-auth security guidance
      • For client access security, Microsoft guidance focuses on:
        • Blocking legacy authentication protocols (Autodiscover, MAPI, Offline Address Book, EWS, RPC) via Exchange authentication policies.
        • Using modern authentication and Conditional Access (including multifactor authentication) instead of relying on network-layer brute-force blocking.
      • Example configuration uses New-AuthenticationPolicy and Set-User / Set-OrganizationConfig to block legacy auth, and recommends MAPI over HTTP instead of RPC because RPC does not support modern authentication or Microsoft Entra multifactor authentication.
    4. Extended Protection and TLS configuration
      • When enabling Windows Extended Protection on Exchange, TLS configuration must be consistent across all Exchange servers:
        • SchUseStrongCrypto and SystemDefaultTlsVersions registry values must be explicitly set to 1 on all Exchange servers.
        • Misconfiguration can cause TLS mismatches and connectivity issues between servers or between clients and servers.
      • Any proxy or middlebox that performs TLS termination or inspection must be compatible with these TLS requirements and not introduce man-in-the-middle behavior that Extended Protection will block.
    5. DAG witness and Azure considerations
      • For DAGs that use an Azure-based witness, Microsoft requires a full site-to-site VPN and emphasizes correct network configuration and familiarity with DAG concepts.
      • This reinforces that DAG-related traffic is sensitive to network topology and filtering; inserting additional proxies must not interfere with DAG quorum or witness communication.

    Within the provided information, there is no documented or recommended pattern from Microsoft for:

    • Using HAProxy (or similar) to deep-inspect IMAPS/SMTPS traffic for AUTH LOGIN failed or 535 5.7.3 responses.
    • Implementing IP-based blacklisting at a proxy layer based on Exchange authentication failures.
    • Using Dovecot proxy, nginx stream, stunnel, rspamd, or postfix as a front-end anti-bruteforce layer specifically for Exchange 2019 DAG.

    The documented and supported security approach centers on:

    • Relying on Exchange’s own per-session limits for failed logins.
    • Blocking legacy authentication and enforcing modern authentication with Conditional Access and multifactor authentication.
    • Ensuring unrestricted and secure communication between Exchange servers and domain controllers, especially in DAG configurations.
    • Correctly configuring TLS and Extended Protection so that middleboxes do not break or weaken security.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.