Überlegungen zum Deaktivieren und Ersetzen von TLS 1.0 in AD FS

Dieser Artikel enthält Anleitungen und Überlegungen zum Deaktivieren und Ersetzen von TLS 1.0 in Active Directory-Verbunddienste (AD FS) (AD FS).

Gilt für: Windows Server 2012 R2
Ursprüngliche KB-Nummer: 3194197

Zusammenfassung

Viele Kunden ziehen die Option in Betracht, das PROTOKOLL TLS 1.0 und RC4 in AD FS zu deaktivieren und durch TLS 1.1 oder eine höhere Version zu ersetzen. In diesem Artikel werden Probleme erläutert, die auftreten können, wenn Sie TLS 1.0 deaktivieren, und enthält Anleitungen, die Ihnen bei der Durchführung des Prozesses helfen.

Nachdem Sie TLS 1.0 auf AD FS- oder AD FS-Proxyservern (WAP) deaktiviert haben, treten auf diesen Servern möglicherweise einige der folgenden Symptome auf:

• Bei der Konnektivität zwischen einem AD FS-Proxy und einem AD FS-Server tritt ein Fehler auf. Dies kann zu einer der folgenden Bedingungen führen:

  • Die Proxykonfiguration schlägt entweder im Assistenten oder mithilfe von Windows PowerShell fehl.

  • Die Ereignis-ID 422 wird auf AD FS-Proxys protokolliert:

    Die Proxykonfiguration kann vom Verbunddienst nicht abgerufen werden.

  • Proxys können keinen Datenverkehr an AD FS-Server weiterleiten, und die folgende Fehlermeldung wird generiert:

    Fehler HTTP 503: Der Dienst ist nicht verfügbar.

• AD FS kann die Verbundmetadaten der konfigurierten Vertrauensstellungen der vertrauenden Seite oder der Anspruchsanbieter-Vertrauensstellungen nicht aktualisieren.

• Sie erhalten eine HTTP 503-Fehlermeldung:

  Der Dienst ist nicht verfügbar. HTTP 503, der auf Office 365-Dienste für Verbunddomänen zugreift.

• Sie erhalten eine RDP-Fehlermeldung:

  RDP-Konnektivität für die Server verloren gegangen.

Ursache

Dieses Problem tritt auf, wenn Kunden alte Protokolle mithilfe von SChannel-Registrierungsschlüsseln deaktivieren. Ein Beispiel für diese Vorgehensweise finden Sie im Abschnitt Deaktivieren alter Protokolle in der Registrierung .

Lösung

ADFS wird mithilfe von Microsoft .NET Framework entwickelt. Damit .NET-Anwendungen starke Kryptografie unterstützen (d. h. TLS 1.1 und höher), müssen Sie zuerst die Updates installieren, die in der folgenden Sicherheitsempfehlung beschrieben werden: Microsoft-Sicherheitsempfehlung 2960358.

Deaktivieren alter Protokolle in der Registrierung

Ein Beispiel für das Deaktivieren alter Protokolle mithilfe von SChannel-Registrierungsschlüsseln wäre das Konfigurieren der Werte in Registrierungsunterschlüsseln in der folgenden Liste. Diese deaktivieren die Protokolle SSL 3.0, TLS 1.0 und RC4. Da diese Situation für SChannel gilt, wirkt sich dies auf alle SSL/TLS-Verbindungen zum und vom Server aus aus.

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 000000000
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server" /v Enabled /t REG_DWORD /d 000000000
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 000000000
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v Enabled /t REG_DWORD /d 000000000
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 000000000
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 000000000
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 000000000

Um zu überprüfen, ob ein Server, der mit dem Internet verbunden ist, alte Protokolle erfolgreich deaktiviert hat, können Sie eine beliebige Online-SSL-Testüberprüfung wie Qualys SSL Labs verwenden. Weitere Informationen finden Sie unter SSL-Servertest.

Alternative Lösung

Alternativ zur Verwendung des Registrierungsschlüssels SchUseStrongCrypto können Sie den Registrierungsschlüssel SystemDefaultTlsVersions verwenden, wenn Sie den .NET Framework 3.5.1 verwenden.

SystemDefaultTlsVersions ist verfügbar, nachdem Sie update 3154518 installiert haben.

Nachdem die Registrierungsschlüssel festgelegt wurden, berücksichtigt der AD FS-Dienst die SChannel-Standardwerte und funktioniert.

Bekannte Nebenwirkungen

Hier sind bekannte Nebenwirkungen.

Clientanwendungen können keine Verbindung mit ADFS-Server oder AD FS-Proxy für die Authentifizierung herstellen

Wenn Sie TLS 1.0 und frühere Versionen auf AD FS-Servern und Proxys deaktivieren, müssen die Clientanwendungen, die eine Verbindung herstellen möchten, TLS 1.1 oder höhere Versionen unterstützen.

Dies gilt beispielsweise für Android Mobile 4.1.1, wenn Sie die Intune-Unternehmensportal-Anwendung verwenden, um dieses Gerät zu registrieren. Die Intune Anwendung kann die AD FS-Anmeldeseite nicht anzeigen.

Dies wird in dieser Android-Version erwartet, da TLS 1.1 standardmäßig deaktiviert ist.

Sie können weitere Details zu diesen potenziellen Problemen erhalten, indem Sie Netzwerkablaufverfolgungen auf dem AD FS-Server oder Proxys sammeln, während Sie den Verbindungsfehler reproduzieren. In diesem Szenario können Sie mit dem Anbieter des Clientbetriebssystems oder des Anwendungsanbieters zusammenarbeiten, um zu überprüfen, ob neuere TLS-Versionen unterstützt werden. ADFS kann keine Verbundmetadaten aktualisieren.

Szenario 1

• AD FS kann die Federationmetadata.xml nicht automatisch aus den Vertrauensstellungen der vertrauenden Seite oder den Anspruchsanbieter-Vertrauensstellungen abrufen.

• Wenn Sie versuchen, die XML-Datei manuell zu aktualisieren, wird die folgende Fehlermeldung angezeigt:

  Fehler beim Lesen der Verbundmetadaten.

• Alternativ erhalten Sie die folgende Fehlermeldung, wenn Sie Windows PowerShell verwenden:

  Die zugrunde liegende Verbindung wurde geschlossen. Unerwarteter Fehler bei einem Empfang.

Durch eine genauere Analyse der zugrunde liegenden Ausnahme können wir die folgenden Informationen sehen:

PS C:> Update-AdfsRelyingPartyTrust -TargetName "Microsoft Office 365 Identity Platform"
Update-AdfsRelyingPartyTrust : Die zugrunde liegende Verbindung wurde geschlossen: Bei einem Empfang ist ein unerwarteter Fehler aufgetreten.
Bei zeile:1 char:1
+ Update-AdfsRelyingPartyTrust -TargetName "Microsoft Office 365 Identity Platform ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : Nicht angegeben: (Microsoft.Ident... lyingPartyTrust:RelyingPartyTrust) [Update-AdfsRelyingP artyTrust], WebException
+ FullyQualifiedErrorId : Die zugrunde liegende Verbindung wurde geschlossen: Ein unerwarteter Fehler ist bei einem Receive.,Microso ft. IdentityServer.Management.Commands.UpdateRelyingPartyTrustCommand

PS C:> $error[0] | fl * -f
writeErrorStream: True
PSMessageDetails :
Ausnahme: System.Net.WebException: Die zugrunde liegende Verbindung wurde geschlossen: Bei einem Empfang ist ein unerwarteter Fehler aufgetreten. >--- System.ComponentModel.Win32Exception: Client und Server können nicht kommunizieren, da sie keinen gemeinsamen Algorithmus besitzen
at System.Net.SSPIWrapper.AcquireCredentialsHandle(SSPIInterface SecModule, String package, CredentialUse intent, SecureCredential scc)
unter System.Net.Security.SecureChannel.AcquireCredentialsHandle(CredentialUse credUsage, SecureCredential& secureCredential)
unter 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)
bei 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 callback, Object state, Boolean preserveSyncCtx)
bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback-Rückruf, Objektzustand)
at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)
at System.Net.ConnectStream.WriteHeaders(Boolean async)
--- Ende des --- für die ablaufverfolgung des inneren Ausnahmestapels
bei System.Net.HttpWebRequest.GetResponse()
at Microsoft.IdentityServer.Management.Resources.Managers.RelyingPartyTrustManager.ApplyMeta dataFromUrl(RelyingPartyTrust party, URI metadataUrl, String& warnings)
unter Microsoft.IdentityServer.Management.Commands.UpdateRelyingPartyTrustCommand.OperateOnRely ingPartyTrust(RelyingPartyTrust party)
unter Microsoft.IdentityServer.Management.Commands.RemoveRelyingPartyTrustCommand.ProcessRecord()
TargetObject : Microsoft.IdentityServer.Management.Resources.RelyingPartyTrust
CategoryInfo : NotSpecified: (Microsoft.Ident... lyingPartyTrust:RelyingPartyTrust)
[Update-AdfsRelyingPartyTrust], WebException
FullyQualifiedErrorId : Die zugrunde liegende Verbindung wurde geschlossen: Unerwarteter Fehler bei einem receive.,Microsoft.IdentityServer.Management.Commands.UpdateRelyingPartyTrustCommand
ErrorDetails: Die zugrunde liegende Verbindung wurde geschlossen: Bei einem Empfang ist ein unerwarteter Fehler aufgetreten. InvocationInfo : System.Management.Automation.InvocationInfo
ScriptStackTrace : bei <ScriptBlock>, <Keine Datei>: Zeile 1
PipelineIterationInfo : {0, 1}

Wenn wir die Netzwerkablaufverfolgungen analysieren, wird kein ClientHello angezeigt. Außerdem schließt der Client selbst (AD FS) die Verbindung (TCP FIN), wenn erwartet wird, dass er den ClientHello sendet:

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=... Eine.. 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=... Eine... 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

Der Grund dafür ist, dass die SChannel-Registrierungsschlüssel erstellt wurden. Dadurch wird die Unterstützung für SSL 3.0 oder TLS 1.0 als Client entfernt.

Der Schlüssel SchUseStrongCrypto wurde jedoch nicht erstellt. Nachdem wir also die TCP/IP-Sitzung festgelegt haben, sollte der ClientHello mit den folgenden Bedingungen gesendet werden:

• .NET mit schwacher Kryptografie (nur TLS 1.0 und frühere Versionen)
• SChannel konfiguriert, um nur TLS 1.1 oder höhere Versionen zu verwenden

Lösung: Wenden Sie SchUseStrongCrypto an, und starten Sie neu.

HTTP 503 beim Zugriff auf Office 365-Dienste

Szenario 2

• Nur TLS 1.1 und höhere Versionen werden im ADFS serviceOffice unterstützt.
• Sie verfügen über eine O365-Verbunddomäne.
• Der Client greift auf einen O365-Dienst zu, der proxyedauthentication verwendet: Die Clientanwendung hat die Anmeldeinformationen mithilfe von HTTP Basic gesendet, und der O365-Dienst verwendet diese Anmeldeinformationen in einer neuen Verbindung mit AD FS, um den Benutzer zu authentifizieren.
• Der Clouddienst sendet TLS 1.0 an AD FS, und AD FS schließt die Verbindung.
• Der Client empfängt die Antwort HTTP 503.

Dies trifft beispielsweise zu, wenn Sie auf die AutoErmittlung zugreifen. In diesem Szenario sind Outlook-Clients betroffen. Dies kann einfach reproduziert werden, indem Sie einen Webbrowser öffnen und zu https://autodiscover-s.outlook.com/Autodiscover/Autodiscoverwechseln.

xmlRequest gesandt:

GET https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml HTTP/1.1
Host: autodiscover-s.outlook.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Accept: 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
Verbindung: keep-alive
Autorisierung: Basic (REMOVED FOR PRIVACY)

Antwort, die von Exchange Online-Dienst empfangen wurde:

HTTP/1.1 503-Dienst nicht verfügbar
Cache-Control: privat
Retry-After: 30
Server: 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: The underlying connection was closed: An unexpected error occurred on a send.;
X-DiagInfo: DB4PR04MB394
X-BEServer: DB4PR04MB394
X-AspNet-Version: 4.0.30319
Set-Cookie: X-BackEndCookie2=; expires=<DateTime>; path=/AutoErmittlung; sicher; HttpOnly
Set-Cookie: X-BackEndCookie=; expires=<DateTime>; path=/AutoErmittlung; sicher; HttpOnly
X-Powered-By: ASP.NET
X-FEServer: AM3PR05CA0056
Date: <DateTime>
Inhaltslänge: 0

Wenn Sie Netzwerkablaufverfolgungen auf dem WAP-Server analysieren, können Sie sehen, dass mehrere Verbindungen aus unserer Cloud stammen, wie folgt. WAP beendet diese Verbindungen (TCP RST), kurz nachdem der Client Hello empfangen wurde.

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 ( Verhandlungsskalierungsfaktor 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=. U. a.. S., SrcPort=HTTPS(443), DstPort=62047, PayloadLen=0, Seq=3949992650, Ack=1681718624, Win=8192 (ausgehandelter Skalierungsfaktor 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 (Skalierungsfaktor 0x0) = 0

Wir sehen auch, dass "Client Hello" TLS 1.0 verwendet:

Frame: Number = 3293, Captured Frame Length = 271, MediaType = NetEvent
+ NetEvent:
+ MicrosoftWindowsNDISPacketCapture: Paketfragment (170 (0xAA) Bytes)
+ Ethernet: Etype = Internet-IP (IPv4),DestinationAddress:[00-0D-3A-24-43-98],SourceAddress:[12-34-56-78-9A-BC]
+ Ipv4: Src = <IP-Adresse>, Dest = <IP-Adresse>, Nächstes Protokoll = TCP, Paket-ID = 31775, Gesamt-IP-Länge = 156
+ TCP: Flags=... AP..., SrcPort=62047, DstPort=HTTPS(443), PayloadLen=116, Seq=1681718624 - 1681718740, Ack=3949992651, Win=517
TLSSSLData: Tls-Nutzlastdaten (Transport Layer Security)
- TLS: TLS Rec Layer-1 HandShake: Client Hello.
- TlsRecordLayer: TLS Rec Layer-1 HandShake:
ContentType: HandShake:
- Version: TLS 1.0
Hauptfach: 3 (0x3)
Nebenjährig: 1 (0x1)
Länge: 111 (0x6F)
- SSLHandshake: SSL HandShake ClientHello(0x01)
HandShakeType: ClientHello(0x01)
Länge: 107 (0x6B)
– ClientHello: TLS 1.0
+ Version: 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)
ErweiterungenLänge: 52 (0x34)
– ClientHelloExtension: Servername(0x0000)
ExtensionType: Servername(0x0000)
ExtensionLength: 19 (0x13)
NameListLength: 17 (0x11)
NameType: Hostname (0)
NameLength: 14 (0xE)
ServerName: sts.contoso.net
+ ClientHelloExtension: Elliptic Curves(0x000A)
+ ClientHelloExtension: EC-Punktformate(0x000B)
+ ClientHelloExtension: SessionTicket TLS(0x0023)
+ ClientHelloExtension: Unbekannter Erweiterungstyp
+ ClientHelloExtension: Neuverhandlungsinformationen(0xFF01)

In diesem Szenario wird erwartet, dass der AD FS-Proxy die Verbindung ablehnt. Dieses Problem wurde Exchange Online Team gemeldet und wird derzeit untersucht.

Problemumgehungen:

• Verwenden Sie die moderne Authentifizierung.

  Hinweis

  Dies wurde nicht getestet. Konzeptionell erfolgt die Verbindung mit AD FS jedoch direkt von der Clientanwendung. Daher sollte es funktionieren, wenn TLS 1.1 unterstützt wird.

• Aktivieren Sie den TLS 1.0-Server im WAP/ADFS-Proxy erneut.

References

• Payment Card Industry (PCI) Data Security Standard (DSS)

• Fehler beim Konfigurieren von WAP– "Die zugrunde liegende Verbindung wurde geschlossen" – Teil 2

Informationen zum Haftungsausschluss von Drittanbietern

Die in diesem Artikel genannten Drittanbieterprodukte stammen von Herstellern, die von Microsoft unabhängig sind. Microsoft gewährt keine implizite oder sonstige Garantie in Bezug auf die Leistung oder Zuverlässigkeit dieser Produkte.