通过

在 AD FS 中禁用和替换 TLS 1.0 的注意事项

本文提供有关在 Active Directory 联合身份验证服务 （AD FS） 中禁用和替换 TLS 1.0 的指南和注意事项。

原始 KB 数： 3194197

总结

许多客户正在考虑在 AD FS 中禁用 TLS 1.0 和 RC4 协议的选项，并将其替换为 TLS 1.1 或更高版本。 本文讨论禁用 TLS 1.0 时可能出现的问题，并提供指导来帮助完成该过程。

在 AD FS 或 AD FS 代理 （WAP） 服务器上禁用 TLS 1.0 后，这些服务器可能会遇到以下一些症状：

  • AD FS 代理与 AD FS 服务器之间的连接失败。 这可能会导致以下任一情况：

    • 代理配置在向导中或使用 Windows PowerShell 失败。

    • 事件 ID 422 记录在 AD FS 代理上：

      无法从联合身份验证服务检索代理配置。

    • 代理无法将流量转发到 AD FS 服务器，并生成以下错误消息：

      错误 HTTP 503 - 服务不可用。

  • AD FS 无法更新已配置的信赖方信任或声明提供程序信任的联合元数据。

  • 收到 HTTP 503 错误消息：

    服务不可用。 HTTP 503 访问联合域的 Office 365 服务。

  • 收到 RDP 错误消息：

    RDP 连接到服务器时丢失。

原因

如果客户使用 SChannel 注册表项禁用旧协议，则会出现此问题。 有关这种做法的示例，请参阅注册表部分中的“禁用旧协议”。

解决方法

重要

请认真遵循本部分所述的步骤。 如果注册表修改不正确，可能会发生严重问题。 在修改注册表之前，请备份注册表，以便在出现问题时可以还原。

ADFS 是使用 Microsoft .NET Framework 开发的。 对于支持强加密（即 TLS 1.1 及更高版本）的 .NET 应用程序，必须先安装以下安全公告中所述的更新： Microsoft安全公告2960358。

重要

在安装了 .NET Framework 4.6 的系统上运行 .NET Framework 3.5 应用程序或 .NET Framework 4.5/4.5.1/4.5.2 应用程序的客户必须按照此公告中提供的步骤手动禁用 TLS 中的 RC4。 有关详细信息，请参阅 公告的“建议的操作 ”部分。

注意

  • 运行 .NET Framework 4.6 的系统默认仅受到保护，无需更新。

  • 安全公告中的其他步骤要求创建 SchUseStrongCrypto 注册表项，如咨询文章中所述。

    此新注册表项的子项示例：

    • [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727] SchUseStrongCrypto=dword：00000001
    • [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319] SchUseStrongCrypto=dword：00000001
    • [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319] SchUseStrongCrypto=dword：00000001
    • [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727] SchUseStrongCrypto=dword：00000001

  • 若要应用更改，必须重启以下服务和应用程序：

    • ADFS 服务 （adfssrv）
    • 设备注册服务 （drs）
    • 可能正在服务器中运行的任何其他 .NET 应用程序
    • ADFS 的 Internet 信息服务 （IIS） 应用程序池（仅适用于 ADFS 2.0 和 ADFS 2.1）

重要

请认真遵循本部分所述的步骤。 如果注册表修改不正确，可能会发生严重问题。 在修改注册表之前，请备份注册表，以便在出现问题时可以还原。

禁用注册表中的旧协议

使用 SChannel 注册表项禁用旧协议的一个示例是在以下列表中的注册表子项中配置值。 它们禁用 SSL 3.0、TLS 1.0 和 RC4 协议。 由于这种情况适用于 SChannel，因此会影响与服务器之间的所有 SSL/TLS 连接。

reg add “HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0” /f
reg add “HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client” /f
reg add “HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server” /f
reg add “HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client” /v Enabled /t REG_DWORD /d d 0000000
reg add “HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server” /v Enabled /t REG_DWORD /d 0000000
reg add “HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0” /f
reg add “HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client” /f
reg add “HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server” /f
reg add “HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client” /v Enabled /t REG_DWORD /d 00000000
reg add “HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server” /v Enabled /t REG_DWORD /d 00000000
reg add “HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128” /f
reg add “HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128” /v Enabled /t REG_DWORD /d 00000000
reg add “HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128” /f
reg add “HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128” /v Enabled /t REG_DWORD /d 00000000
reg add “HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128” /f
reg add “HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128” /v Enabled /t REG_DWORD /d 00000000

注意

更改这些值后，必须重新启动计算机。

若要验证连接到 Internet 的服务器是否已成功禁用旧协议，可以使用任何联机 SSL 测试验证程序，例如 Qualys SSL 实验室。 有关详细信息，请参阅 SSL 服务器测试。

替代解决方案

作为使用 SchUseStrongCrypto 注册表项的替代方法，在使用 .NET Framework 3.5.1 时，可以使用 SystemDefaultTlsVersions 注册表项。

安装更新3154518后，可以使用 SystemDefaultTlsVersions。

设置注册表项后，ADFS 服务会遵循 SChannel 默认值和工作。

已知副作用

以下是了解副作用。

客户端应用程序无法连接到 ADFS 服务器或 ADFS 代理进行身份验证

在 ADFS 服务器和代理上禁用 TLS 1.0 及更早版本时，尝试连接到它的客户端应用程序必须支持 TLS 1.1 或更高版本。

例如，使用 Intune 公司门户 应用程序注册该设备时，Android mobile 4.1.1 也是如此。 Intune 应用程序无法显示 ADFS 登录页。

这是在此 Android 版本中的预期，因为默认情况下禁用 TLS 1.1。

在重现连接失败时，可以通过在 ADFS 服务器或代理上收集网络跟踪来获取有关这些潜在问题的更多详细信息。 在此方案中，可以与客户端 OS 供应商或应用程序供应商合作，验证是否支持较新的 TLS 版本。 ADFS 无法更新联合元数据。

方案 1

  • ADFS 无法从信赖方信任或声明提供程序信任自动检索Federationmetadata.xml。

  • 尝试手动更新 XML 文件时，会收到以下错误消息：

    尝试读取联合元数据期间出错。

  • 或者，使用 Windows PowerShell 时会收到以下错误消息：

    基础连接已关闭。 接收时发生意外错误。

通过更密切地分析基础异常，我们可以看到以下信息：

PS C：>Update-AdfsRelyingPartyTrust -TargetName “Microsoft 办公室 365 标识平台”
Update-AdfsRelyingPartyTrust：基础连接已关闭：接收时发生意外错误。
位置：line:1 char:1
+ Update-AdfsRelyingPartyTrust -TargetName “Microsoft 办公室 365 Identity Platform ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo： NotSpecified： （Microsoft.Ident...lyingPartyTrust：RelyingPartyTrust） [Update-AdfsRelyingP artyTrust]， WebException
+ FullyQualifiedErrorId：基础连接已关闭：receive.，Microso ft 发生意外错误。IdentityServer.Management.Commands.UpdateRelyingPartyTrustCommand

PS C：> $error[0] | fl * -f
writeErrorStream ： True
PSMessageDetails ：
异常：System.Net.WebException：基础连接已关闭：接收时发生意外错误。 >--- System.ComponentModel.Win32Exception：客户端和服务器无法通信，因为它们不具有通用算法
at System.Net.SSPIWrapper.AcquireCredentialsHandle（SSPIInterface SecModule， 字符串包， CredentialUse 意向， SecureCredential scc）
at System.Net.Security.SecureChannel.AcquireCredentialsHandle（CredentialUse credUsage， SecureCredential& secureCredential）
at System.Net.Security.SecureChannel.AcquireClientCredentials（Byte[]& thumbPrint）
at System.Net.Security.SecureChannel.GenerateToken（Byte[] input， Int32 offset， Int32 count， Byte[]& output）
at System.Net.Security.SecureChannel.NextMessage（Byte[] incoming， Int32 offset， Int32 count）
at System.Net.Security.SslState.StartSendBlob（Byte[] incoming， Int32 count， AsyncProtocolRequest asyncRequest）
at System.Net.Security.SslState.ForceAuthentication（Boolean receiveFirst， Byte[] buffer， AsyncProtocolRequest asyncRequest）
at System.Net.Security.SslState.ProcessAuthentication（LazyAsyncResult lazyResult）
at System.Threading.ExecutionContext.RunInternal（ExecutionContext executionContext， ContextCallback callback， Object state， Boolean preserveSyncCtx）
at System.Threading.ExecutionContext.Run（ExecutionContext executionContext， ContextCallback 回调， 对象状态， 布尔保留SyncCtx）
at System.Threading.ExecutionContext.Run（ExecutionContext executionContext， ContextCallback 回调， 对象状态）
at System.Net.TlsStream.ProcessAuthentication（LazyAsyncResult 结果）
at System.Net.TlsStream.Write（Byte[] buffer， Int32 offset， Int32 size）
at System.Net.ConnectStream.WriteHeaders（布尔异步）
- 内部异常堆栈跟踪结束 -
at System.Net.HttpWebRequest.GetResponse（）
at Microsoft.IdentityServer.Management.Resources.Managers.RelyingPartyTrustManager.ApplyMeta dataFromUrl（RelyingPartyTrust party、Uri metadataUrl、String& warnings）
at Microsoft.IdentityServer.Management.Commands.UpdateRelyingPartyTrustCommand.OperateOnRely ingPartyTrust（RelyingPartyTrust party）
at Microsoft.IdentityServer.Management.Commands.RemoveRelyingPartyTrustCommand.ProcessRecord（）
TargetObject：Microsoft.IdentityServer.Management.Resources.RelyingPartyTrust
CategoryInfo ： NotSpecified： （Microsoft.Ident...lyingPartyTrust：RelyingPartyTrust）
[Update-AdfsRelyingPartyTrust]， WebException
FullyQualifiedErrorId：基础连接已关闭：receive.，Microsoft.IdentityServer.Management.Commands.UpdateRelyingPartyTrustCommand 上出现意外错误
ErrorDetails：基础连接已关闭：接收时发生意外错误。 InvocationInfo ：System.Management.Automation.InvocationInfo
ScriptStackTrace ： at <ScriptBlock>， <No file>： line 1
PipelineIterationInfo ： {0， 1}

分析网络跟踪时，看不到任何 ClientHello。 此外，当客户端本身（ADFS）预期将发送 ClientHello 时关闭连接（TCP FIN）：

3794 <DateTime> 4.0967400 （4588） adfs1 nexus.microsoftonline-p.com.nsatc.net TCP 8192 TCP： [Bad CheckSum]Flags=CE....S.， SrcPort=56156， DstPort=HTTPS（443）
4013 <DateTime> 4.1983176 （0） nexus.microsoftonline-p.com.nsatc.net adfs1 TCP 2097152 TCP：Flags=...一个。。S.， SrcPort=HTTPS（443）， DstPort=56156
4021 <DateTime> 4.1983388 （0） adfs1 nexus.microsoftonline-p.com.nsatc.net TCP 131328 TCP： [Bad CheckSum]Flags=...A....， SrcPort=56156， DstPort=HTTPS（443）
4029 <DateTime> 4.1992083 （4588） adfs1 nexus.microsoftonline-p.com.nsatc.net TCP 131328 TCP： [Bad CheckSum]Flags=...一个。。。F， SrcPort=56156， DstPort=HTTPS（443）
4057 <DateTime> 4.2999711 （0） nexus.microsoftonline-p.com.nsatc.net adfs1 TCP 0 TCP：Flags=...A.R..， SrcPort=HTTPS（443）， DstPort=56156

原因是已创建 SChannel 注册表项。 这些删除对 SSL 3.0 或 TLS 1.0 作为客户端的支持。

但是， 没有创建 SchUseStrongCrypto 密钥。 因此，建立 TCP/IP 会话后，应通过满足以下条件发送 ClientHello：

  • 使用弱加密 （仅 TLS 1.0 和更早版本）
  • 配置为仅使用 TLS 1.1 或更高版本的 SChannel

解决方法：应用 SchUseStrongCrypto 并重新启动。

访问 Office 365 服务的 HTTP 503

方案 2

  • ADFS serviceOffice 仅支持 TLS 1.1 及更高版本。
  • 你有一个 O365 联合域。
  • 客户端正在访问一些使用 proxiedauthentication 的 O365 服务：客户端应用程序使用 HTTP Basic 发送了凭据，而 O365 服务在与 ADFS 的新连接中使用这些凭据对用户进行身份验证。
  • 云服务将 TLS 1.0 发送到 ADFS，ADFS 将关闭连接。
  • 客户端接收响应 HTTP 503。

例如，访问自动发现时，这是事实。 在此方案中，Outlook 客户端受到影响。 可以通过打开 Web 浏览器并转到 https://autodiscover-s.outlook.com/Autodiscover/Autodiscover来轻松重现此问题。

xmlRequest 送：

GET https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml HTTP/1.1
主机：autodiscover-s.outlook.com
用户代理：Mozilla/5.0 （Windows NT 10.0;WOW64;rv：46.0） Gecko/20100101 Firefox/46.0
接受：text/html，application/xhtml+xml，application/xml;q=0.9，;/q=0.8
Accept-Language：en-US，en;q=0.5
Accept-Encoding：gzip、deflate、br
连接：保持活动
授权：基本（已删除隐私）

从 Exchange Online 服务收到的响应：

HTTP/1.1 503 服务不可用
Cache-Control: private
重试后：30
服务器：Microsoft-IIS/8.0
request-id： 33c23dc6-2359-44a5-a819-03f3f8e85aae
X-CalculatedBETarget：db4pr04mb394.eurprd04.prod.outlook.com
X-AutoDiscovery-Error： LiveIdBasicAuth：FederatedStsUnreachable：<X-forwarded-for：<IP Address>><FederatedSTSFailure>System.Net.WebException：基础连接已关闭：发送时发生意外错误。
X-DiagInfo：DB4PR04MB394
X-BEServer：DB4PR04MB394
X-AspNet-Version：4.0.30319
Set-Cookie：X-BackEndCookie2=;expires=<DateTime>; path=/Autodiscover; secure;HttpOnly
Set-Cookie：X-BackEndCookie=;expires=<DateTime>; path=/Autodiscover; secure;HttpOnly
X-Powered-By：ASP.NET
X-FEServer：AM3PR05CA0056
日期： <DateTime>
内容长度：0

分析 WAP 服务器中的网络跟踪，可以看到来自云的多个连接，如下所示。 WAP 在收到 Client Hello 后不久终止这些连接（ TCP RST）。

3282 <DateTime> 10.8024332 （0） 132.245.225.68 62047 （0xF25F） 10.10.1.5 443 （0x1BB） TCP 52 （0x34） 32 8192 TCP：Flags=CE....S.， SrcPort=62047， DstPort=HTTPS（443）， PayloadLen=0， Seq=1681718623， Ack=0， Win=8192 （协商比例系数 0x8） = 8192
3285 <DateTime> 10.8025263 （0） 10.10.1.5 443 （0x1BB） 132.245.225.68 62047 （0xF25F） TCP 52 （0x34） 32 8192 TCP： [Bad CheckSum]Flags=.E.A..S.， SrcPort=HTTPS（443）， DstPort=62047， PayloadLen=0， Seq=3949992650， Ack=1681718624， Win=8192 （协商比例系数 0x8） = 8192
3286 <DateTime> 10.8239153 （0） 132.245.225.68 62047 （0xF25F） 10.10.1.5 443 （0x1BB） TCP 40 （0x28） 20 517 TCP：Flags=...A....， SrcPort=62047， DstPort=HTTPS（443）， PayloadLen=0， Seq=1681718624， Ack=3949992651， Win=517
3293 <DateTime> 10.8244384 （0） 132.245.225.68 62047 （0xF25F） 10 .10.1.5 443 （0x1BB） TLS 156 （0x9C） 136 517 TLS：TLS Rec Layer-1 HandShake： Client Hello.
3300 <DateTime> 10.8246757 （4） 10.10.1.5 443 （0x1BB） 132.245.225.68 62047 （0xF25F） TCP 40 （0x28） 20 0 TCP： [Bad CheckSum]Flags=...A.R..、SrcPort=HTTPS（443）、DstPort=62047、PayloadLen=0、Seq=3949992651、Ack=1681718740、Win=0（比例系数0x0） = 0

我们还看到 Client Hello 正在使用 TLS 1.0：

帧：数字 = 3293，捕获的帧长度 = 271，MediaType = NetEvent
+ NetEvent：
+ MicrosoftWindowsNDISPacketCapture：数据包片段（170（0xAA） 字节）
+ 以太网：Etype = Internet IP （IPv4），DestinationAddress：[00-0D-3A-24-43-98]，SourceAddress：[12-34-56-78-9A-BC]
+ Ipv4：Src = <IP 地址，Dest = <IP 地址>>，下一协议 = TCP，数据包 ID = 31775，IP 总长度 = 156
+ Tcp：Flags=...AP...、SrcPort=62047、DstPort=HTTPS（443）、PayloadLen=116、Seq=1681718624 - 1681718740、Ack=3949992651、Win=517
TLSSSLData：传输层安全性（TLS）有效负载数据
- TLS：TLS Rec Layer-1 HandShake：Client Hello。
- TlsRecordLayer：TLS Rec Layer-1 HandShake：
ContentType：HandShake：
- 版本：TLS 1.0
专业： 3 （0x3）
次要： 1 （0x1）
长度：111（0x6F）
- SSLHandshake：SSL HandShake ClientHello（0x01）
HandShakeType： ClientHello（0x01）
长度：107 （0x6B）
- ClientHello：TLS 1.0
+ 版本：TLS 1.0
+ RandomBytes：
SessionIDLength： 0 （0x0）
CipherSuitesLength：14
+ TLSCipherSuites：TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA { 0xC0,0x14 }
+ TLSCipherSuites： TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA { 0xC0,0x13 }
+ TLSCipherSuites：TLS_RSA_WITH_AES_256_CBC_SHA { 0x00， 0x35 }
+ TLSCipherSuites：TLS_RSA_WITH_AES_128_CBC_SHA { 0x00， 0x2F }
+ TLSCipherSuites：TLS_RSA_WITH_3DES_EDE_CBC_SHA { 0x00,0x0A }
+ TLSCipherSuites： TLS_RSA_WITH_RC4_128_SHA { 0x00,0x05 }
+ TLSCipherSuites：TLS_RSA_WITH_RC4_128_MD5 { 0x00,0x04 }
CompressionMethodsLength：1（0x1）
CompressionMethods：0 （0x0）
ExtensionsLength： 52 （0x34）
- ClientHelloExtension：服务器名称（0x0000）
ExtensionType：服务器名称（0x0000）
ExtensionLength： 19 （0x13）
NameListLength： 17 （0x11）
NameType：主机名 （0）
NameLength： 14 （0xE）
ServerName：sts.contoso.net
+ ClientHelloExtension：椭圆曲线（0x000A）
+ ClientHelloExtension：EC 点格式（0x000B）
+ ClientHelloExtension：SessionTicket TLS（0x0023）
+ ClientHelloExtension：未知扩展类型
+ ClientHelloExtension：重新协商信息（0xFF01）

在此方案中，ADFS 代理应拒绝连接。 此问题已报告给 Exchange Online 团队，目前正在调查中。

解决方法：

  • 使用新式身份验证。

    注意

    尚未进行测试。 但是，从概念上讲，与 ADFS 的连接直接从客户端应用程序进行。 因此，如果支持 TLS 1.1，则它应该正常工作。

  • 在 WAP/ADFS 代理中重新启用 TLS 1.0 服务器。

参考

第三方信息免责声明

本文中提到的第三方产品由 Microsoft 以外的其他公司提供。 Microsoft 不对这些产品的性能或可靠性提供任何明示或暗示性担保。