Exchange2019CU12认证模式设置

此回复已自动翻译，因此可能存在语法错误或表达不自然的情况。

您好 @LiBO

感谢您在 Microsoft Q&A 上发布问题。
根据我的研究，在 Exchange Server 2019 中，EHLO（或您描述的 HELO）在端口 25 和 587 上返回的 SMTP 功能取决于相关接收连接器的配置，尤其是它们的身份验证机制（由 AuthMechanism 属性控制）和 TLS 设置。

即使两个服务器“配置相同”，仍可能出现差异，原因可能包括：

手动修改接收连接器（例如有人为了安全添加或删除身份验证方法）。

TLS 证书绑定差异（例如某台服务器未设置 TlsCertificateName）。

连接时选择的连接器不同（基于远程 IP 范围、本地绑定或权限组，如 AnonymousUsers 与 ExchangeUsers）。

传输服务重启未在更改后统一应用。

CU12 安装残留或补丁应用不一致。

要重新配置服务器上的端口，可以尝试按照以下步骤操作：

在端口 25 上设置 AUTH LOGIN 并处理 EHLO（HELO）响应

默认情况下，Exchange 2019 在端口 25 的连接器的 AuthMechanism 中包含 BasicAuth 和 BasicAuthRequireTLS，但 AUTH LOGIN（BasicAuth）通常只会在 STARTTLS 之后被公布，以确保安全（避免明文密码）。如果在初始 EHLO 中立即公布，则表示 BasicAuth 在未强制要求 TLS 的情况下启用，这是不安全且不推荐的，因为它会使凭据暴露于窃听风险。安全配置中通常会先显示 NTLM（来自 Integrated）。

要在端口 25 的初始 EHLO 中强制显示 250-AUTH LOGIN（即启用 BasicAuth 且不强制 TLS）：

运行以下 PowerShell 命令（将 <ServerName> 替换为你的实际服务器名称）：

Set-ReceiveConnector -Identity "<ServerName>\Default Frontend <ServerName>" -AuthMechanism Tls,BasicAuth,Integrated,ExchangeServer

这会添加 BasicAuth（用于 AUTH LOGIN），同时移除 BasicAuthRequireTLS（该参数用于强制 BasicAuth 必须通过 TLS）。

默认的 AuthMechanism 包含：Tls、BasicAuth、BasicAuthRequireTLS、ExchangeServer、Integrated, 请根据需要进行调整，但避免明文暴露 BasicAuth。

重新启动 Microsoft Exchange Transport 服务：

Restart-Service MSExchangeTransport

从远程主机使用 Telnet 进行测试： telnet <ServerFQDN> 25 EHLO test.com

在响应中查找 250-AUTH LOGIN。

注意：在端口 25 上启用纯 BasicAuth 存在安全风险。建议保留 BasicAuthRequireTLS，并指导客户端先使用 STARTTLS。

在端口 587 的 EHLO 响应中设置 STARTTLS

端口 587 用于客户端提交，如果 AuthMechanism 中包含 Tls 且已绑定有效证书，默认会公布 250-STARTTLS。

如果未公布，可能是因为：

连接器缺少 Tls, 启用了 ExternalAuthoritative（常见于配置错误的中继，这会禁用 STARTTLS), 或缺少证书。

确保端口 587 上显示 250-STARTTLS：

确认或设置 AuthMechanism 以包含 Tls（将 <ServerName> 替换为实际服务器名称）：

Set-ReceiveConnector -Identity "<ServerName>\Client Frontend <ServerName>" -AuthMechanism Tls,BasicAuth,BasicAuthRequireTLS,Integrated

这是默认设置, 确保未启用 ExternalAuthoritative（如果存在，请移除，因为它会为受信任的中继禁用 STARTTLS）。

绑定有效的 TLS 证书（必须与服务器的 FQDN 匹配，并启用 SMTP）：

首先，获取你的证书指纹（Thumbprint):

Get-ExchangeCertificate | Format-List Thumbprint, Services, Subject

然后进行设置（将 <Thumbprint> 替换为实际证书指纹）：

$TLSCert = Get-ExchangeCertificate -Thumbprint <Thumbprint>
$$ TLSCertName = "<I> $$($$ TLSCert.Issuer)<S> $$($TLSCert.Subject)"
Set-ReceiveConnector -Identity "<ServerName>\Client Frontend <ServerName>" -TlsCertificateName $TLSCertName

然后重复之前的步骤：重新启动传输服务，并使用 Telnet 进行测试，查看响应中是否包含 250-STARTTLS。

如果问题仍然存在，请在连接器上启用协议日志（Set-ReceiveConnector -ProtocolLoggingLevel Verbose），并在以下路径查看日志以获取线索：

C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\ProtocolLog\SmtpReceive

如果连接器已被自定义，请使用 Microsoft 文档中的脚本重新创建默认配置，或通过导出/导入配置在服务器之间进行比较。对于生产环境，请先在实验室中测试更改。

希望这些信息对你有所帮助。

请理解，我们的初步回复可能无法立即解决问题。但只要您提供更多详细信息，我们将能够与您一起找到解决方案。

如果答案对您有帮助，请点击「接受答案」并按赞。如果您对此答案还有其他疑问，请点击「评论」。   

注意： 如果您希望收到此討論串的相關電子郵件通知，請依照我們的文件步驟啟用電子郵件通知。