Ü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-Verbunddiensten (AD FS).

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

Zusammenfassung

Viele Kunden erwägen die Option, das TLS 1.0- und RC4-Protokoll 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 anleitungen zum Abschließen des Prozesses bereitgestellt.

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:

  • Die Verbindung zwischen einem AD FS-Proxy und einem AD FS-Server schlägt fehl. Dies kann eine der folgenden Bedingungen verursachen:

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

    • Ereignis-ID 422 wird bei AD FS-Proxys protokolliert:

      Proxykonfiguration kann nicht vom Verbunddienst 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 Vertrauensstellungen der vertrauenden Seite oder der konfigurierten Anspruchsanbietervertrauensstellungen nicht aktualisieren.

  • Sie erhalten eine HTTP 503-Fehlermeldung:

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

  • Es wird eine RDP-Fehlermeldung angezeigt:

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

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 "Alte Protokolle deaktivieren" im Registrierungsabschnitt.

Lösung

Wichtig

Führen Sie die in diesem Abschnitt beschriebenen Schritte sorgfältig aus. Durch eine fehlerhafte Bearbeitung der Registrierung können schwerwiegende Probleme verursacht werden. Sichern Sie die Registrierung, bevor Sie sie ändern, damit Sie sie bei Bedarf wiederherstellen können.

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 sind: Microsoft Security Advisory 2960358.

Wichtig

Kunden, die .NET Framework 3.5-Anwendungen auf Windows 10 oder .NET Framework 4.5/4.5.1/4.5.2-Anwendungen auf Systemen ausführen, auf denen die .NET Framework 4.6 installiert ist, müssen die in dieser Empfehlung aufgeführten Schritte ausführen, um RC4 in TLS manuell zu deaktivieren. Weitere Informationen finden Sie im Abschnitt "Vorgeschlagene Aktionen" der Empfehlung.

Hinweis

  • Systeme, auf denen die .NET Framework 4.6 ausgeführt wird, sind standardmäßig geschützt und müssen nicht aktualisiert werden.

  • Für die zusätzlichen Schritte aus der Sicherheitsempfehlung müssen Sie den Registrierungsschlüssel "SchUseStrongCrypto" erstellen, wie im Empfehlungsartikel beschrieben.

    Beispiele für Unterschlüssel für diesen neuen Registrierungsschlüssel:

    • [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
  • Um die Änderung anzuwenden, müssen Sie die folgenden Dienste und Anwendungen neu starten:

    • ADFS-Dienst (adfssrv)
    • Geräteregistrierungsdienst (Drs)
    • Alle anderen .NET-Anwendungen, die möglicherweise auf dem Server ausgeführt werden
    • Der Internetinformationsdienste (IIS)-Anwendungspool für ADFS (gilt nur für ADFS 2.0 und ADFS 2.1)

Wichtig

Führen Sie die in diesem Abschnitt beschriebenen Schritte sorgfältig aus. Durch eine fehlerhafte Bearbeitung der Registrierung können schwerwiegende Probleme verursacht werden. Sichern Sie die Registrierung, bevor Sie sie ändern, damit Sie sie bei Bedarf wiederherstellen können.

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

Hinweis

Sie müssen den Computer neu starten, nachdem Sie diese Werte geändert haben.

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-Testprüfung wie Qualys SSL Labs verwenden. Weitere Informationen finden Sie unter SSL Server Test.

Alternative Lösung

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

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

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

Bekannte Nebeneffekte

Hier sind Nebeneffekte bekannt.

Clientanwendungen können zur Authentifizierung keine Verbindung mit dem ADFS-Server oder dem ADFS-Proxy herstellen

Wenn Sie TLS 1.0 und frühere Versionen auf ADFS-Servern und Proxys deaktivieren, müssen die Clientanwendungen, die versuchen, eine Verbindung damit herzustellen, TLS 1.1 oder höher 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 ADFS-Anmeldeseite nicht anzeigen.

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

Weitere Informationen zu diesen potenziellen Problemen erhalten Sie, indem Sie Netzwerkablaufverfolgungen auf dem ADFS-Server oder Proxys sammeln, während Sie den Verbindungsfehler reproduzieren. In diesem Szenario können Sie mit dem Clientbetriebssystem- oder Anwendungsanbieter zusammenarbeiten, um zu überprüfen, ob neuere TLS-Versionen unterstützt werden. ADFS kann Verbundmetadaten nicht aktualisieren.

Szenario 1

  • ADFS kann die Federationmetadata.xml nicht automatisch aus den Vertrauensstellungen der vertrauenden Seite oder den Vertrauensstellungen des Anspruchsanbieters abrufen.

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

    Beim Versuch, die Verbundmetadaten zu lesen, ist ein Fehler aufgetreten.

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

    Die zugrunde liegende Verbindung wurde geschlossen. Bei einem Empfang ist ein unerwarteter Fehler aufgetreten.

Wenn Sie die zugrunde liegende Ausnahme genauer analysieren, 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 Zeichen:1
+Update-AdfsRelyingPartyTrust -TargetName "Microsoft Office 365 Identity Platform ...+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (Microsoft.Ident... auswendigerPartyTrust:RelyingPartyTrust) [Update-AdfsRelyingP artyTrust], WebException
+ FullyQualifiedErrorId: Die zugrunde liegende Verbindung wurde geschlossen: Bei einem Empfang ist ein unerwarteter Fehler aufgetreten.,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 allgemeinen Algorithmus besitzen
at System.Net.SSPIWrapper.AcquireCredentialsHandle(SSPIInterface SecModule, String package, CredentialUse intent, 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 callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
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 der ablaufverfolgung des internen Ausnahmestapels ---
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... trustpartyTrust:RelyingPartyTrust)
[Update-AdfsRelyingPartyTrust], WebException
FullyQualifiedErrorId: Die zugrunde liegende Verbindung wurde geschlossen: Bei einem Receive.,Microsoft.IdentityServer.Management.Commands.UpdateRelyingPartyTrustCommand ist ein unerwarteter Fehler aufgetreten.
ErrorDetails: Die zugrunde liegende Verbindung wurde geschlossen: Bei einem Empfang ist ein unerwarteter Fehler aufgetreten. InvocationInfo : System.Management.Automation.InvocationInfo
ScriptStackTrace : at <ScriptBlock> , <No file> : Zeile 1
PipelineIterationInfo : {0, 1}

Wenn wir die Netzwerkablaufverfolgungen analysieren, wird kein ClientHello angezeigt. Außerdem schließt der Client selbst (ADFS) die Verbindung (TCP FIN), wenn wir davon ausgehen würden, 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 SchUseStrongCrypto-Schlüssel wurde jedoch nicht erstellt. Nachdem wir die TCP/IP-Sitzung eingerichtet haben, sollte der ClientHello mit den folgenden Bedingungen gesendet werden:

  • .NET mit schwacher Kryptografie (nur TLS 1.0 und frühere Versionen)
  • SChannel ist so konfiguriert, dass nur TLS 1.1 oder höher verwendet wird

Auflösung: Anwenden von SchUseStrongCrypto und Neustart.

HTTP 503 in Zugriff auf Office 365-Dienste

Szenario 2

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

Dies gilt beispielsweise, wenn Sie auf die AutoErmittlung zugreifen. In diesem Szenario sind Outlook Clients betroffen. Dies kann ganz einfach reproduziert werden, indem ein Webbrowser geöffnet und zu https://autodiscover-s.outlook.com/Autodiscover/Autodiscover .

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
Akzeptieren: 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: Einfach (AUS DATENSCHUTZGRÜNDEN ENTFERNT)

Antwort, die von Exchange Online Dienst empfangen wurde:

HTTP/1.1 503-Dienst nicht verfügbar
Cachesteuerung: privat
Wiederholung nach: 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: Die zugrunde liegende Verbindung wurde geschlossen: Beim Senden ist ein unerwarteter Fehler aufgetreten. X-DiagInfo: DB4PR04MB394 X-BEServer: DB4PR04MB394 X-AspNet-Version: 4.0.30319 Set-Cookie: X-BackEndCookie2=; expires= <DateTime> ; path=/AutoErmittlung; secure; HttpOnly Set-Cookie: X-BackEndCookie=; expires= <DateTime> *; path=/AutoErmittlung; secure; HttpOnly
X-Powered-By: ASP.NET
X-FEServer: AM3PR05CA0056
Datum: <DateTime>
Inhaltslänge: 0

Bei der Analyse von Netzwerkablaufverfolgungen auf dem WAP-Server können wir wie folgt mehrere Verbindungen sehen, die aus unserer Cloud stammen. WAP beendet (TCP RST) diese Verbindungen, 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 ( Skalarfaktor 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: Packet Fragment (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 Address> , Dest = <IP Address> , Next Protocol = TCP, Packet ID = 31775, Total IP Length = 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
Hauptversion: 3 (0x3)
Nebenversion: 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)
ExtensionsLength: 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 ADFS-Proxy die Verbindung ablehnt. Dieses Problem wurde Exchange Online Team gemeldet und wird untersucht.

Problemumgehungen:

  • Verwenden Sie moderne Authentifizierung.

    Hinweis

    Dies wurde nicht getestet. Vom Konzept her erfolgt die Verbindung mit ADFS jedoch direkt von der Clientanwendung. Daher sollte es funktionieren, wenn tls 1.1 unterstützt wird.

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

Informationsquellen

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.