Considérations sur la désactivation et le remplacement de TLS 1.0 dans ADFS

IMPORTANT : Cet article est issu d'une traduction automatique réalisée par un logiciel Microsoft et non par un traducteur professionnel. Cette traduction automatique a pu aussi être révisée par la communauté Microsoft grâce à la technologie Community Translation Framework (CTF). Pour en savoir plus sur cette technologie, veuillez consulter la page http://support.microsoft.com/gp/machine-translation-corrections/fr. Microsoft vous propose en effet des articles traduits par des professionnels, des articles issus de traductions automatiques et des articles issus de traductions automatiques révisées par la communauté Microsoft, de manière à ce que vous ayez accès à tous les articles de notre Base de connaissances dans votre langue. Il est important de noter que les articles issus de la traduction automatique, y compris ceux révisés par la communauté Microsoft, peuvent contenir des erreurs de vocabulaire, de syntaxe ou de grammaire. Microsoft ne pourra être tenu responsable des imprécisions, erreurs, ainsi que de tout dommage résultant d’une traduction incorrecte du contenu ou de son utilisation par les clients.

La version anglaise de cet article est la suivante: 3194197
Résumé
De nombreux clients envisagent la possibilité de désactiver TLS 1.0 et RC4 protocole Active Directory Federation Services (ADFS) et le remplacer par TLS 1.1 ou une version ultérieure. Cet article décrit les problèmes qui peuvent se produire si vous désactivez TLS 1.0 et fournit des conseils pour vous aider à terminer le processus.
Symptômes
Après avoir désactivé le TLS 1.0 sur AD FS AD FS proxy (WAP), serveurs, ces serveurs peuvent rencontrer certains des problèmes suivants :

  • Échec de la connectivité entre un proxy d’ADFS et un serveur ADFS. Cela peut entraîner une des conditions suivantes :

    • La configuration du proxy échoue dans l’Assistant ou à l’aide de Windows PowerShell.
    • ID d’événements 422 est enregistré sur les serveurs proxy de Federation Services : « Impossible de récupérer la configuration du proxy du Service de fédération ».
    • Serveurs proxy ne peut pas transférer le trafic vers les serveurs ADFS, et le message d’erreur suivant est généré :
      Erreur HTTP 503 : le service n’est pas disponible.
  • ADFS ne peut pas mettre à jour les métadonnées de fédération des approbations des parties de confiance ou approbations de fournisseur de revendications qui sont configurés.
  • Vous recevez un message d’erreur HTTP 503 :
    Le service n’est pas disponible. HTTP 503 d’accès à Office 365 services des domaines fédérés ».
  • Vous recevez un message d’erreur RDP :
    Connectivité RDP perdue sur les serveurs.
Cause
Ce problème se produit si les utilisateurs de désactiver anciens protocoles à l’aide de clés de Registre SChannel. Pour obtenir un exemple de cette application pratique, consultez le texte associé dans la "Plus d'informations.
Résolution
Important Suivez les étapes décrites dans cette section avec soin. Des problèmes graves peuvent survenir si vous modifiez le Registre de façon incorrecte. Avant de le modifier, sauvegarder le Registre pour la restauration en cas de problème.

ADFS est développé à l’aide de.NET Framework. Pour les applications .NET prendre en charge de la cryptographie (c'est-à-dire, TLS 1.1 et les versions ultérieures), vous devez d’abord installer les mises à jour qui sont décrites dans l’avis de sécurité suivant :
Important Les clients qui exécutent des applications.NET Framework 3.5 sur Windows 10 ou des applications de 4.5/4.5.1/4.5.2 de.NET Framework sur les systèmes qui ont la 4.6 du.NET Framework installé doivent suivre les étapes décrites dans cet avis pour désactiver manuellement le RC4 dans TLS. Pour plus d’informations, consultez la section « Actions suggérées » de cet avis.

Remarques

  • Les systèmes qui exécutent le 4.6 du.NET Framework sont protégés par défaut uniquement et ne doivent pas être mis à jour.
  • Les étapes supplémentaires à partir de l’avis de sécurité requièrent la création de la clé de Registre SchUseStrongCrypto , comme décrit dans l’article consultatif.

    Exemples de sous-clés pour cette nouvelle clé de Registre :
    [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

  • Pour appliquer la modification, vous devez redémarrer les services et applications suivants :

    • Service ADFS (adfssrv)
    • Service d’inscription de périphérique (drs)
    • Toutes les applications .NET qui peuvent être en cours d’exécution sur le serveur
    • Le pool d’applications Internet Information Services (IIS) pour ADFS (s’applique uniquement à ADFS 2.0 et 2.1 d’ADFS)
Plus d'informations
Important Suivez les étapes décrites dans cette section avec soin. Des problèmes graves peuvent survenir si vous modifiez le Registre de façon incorrecte. Avant de le modifier, sauvegarder le Registre pour la restauration en cas de problème.

Désactivation des anciens protocoles dans le Registre

Pour configurer les valeurs dans les sous-clés de Registre dans la liste suivante est un exemple de désactivation des anciens protocoles à l’aide de clés de Registre SChannel. Ces désactiver SSL 3.0, TLS 1.0 et les protocoles de RC4. Étant donné que cette situation s’applique à SChannel, elle affecte toutes les connexions SSL/TLS pour et à partir du serveur.

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 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

Remarque Vous devez redémarrer l’ordinateur après avoir modifié ces valeurs.

Pour vérifier qu’un serveur est connecté à Internet a désactivé avec succès anciens protocoles, vous pouvez utiliser n’importe quel vérificateur Test SSL en ligne, tels que des laboratoires Qualys SSL. Pour plus d’informations, consultez le site Web Qualys suivant :

Autre solution

Comme alternative à l’utilisation de la clé de Registre SchUseStrongCrypto , vous pouvez utiliser la clé de Registre SystemDefaultTlsVersions lorsque vous utilisez le.NET Framework 3.5.1.

SystemDefaultTlsVersions est disponible après l’installation mise à jour 3154518.

Une fois les clés de Registre sont définies, le service ADFS respecte les travaux et les valeurs par défaut de SChannel.

Effets secondaires connus

Applications clientes ne peut pas se connecter au serveur ADFS ou au proxy ADFS pour l’authentification

Lorsque vous désactivez TLS 1.0 et les versions antérieures de serveurs ADFS et les serveurs proxy, les applications clientes que vous essayez de vous connecter à elle doivent prendre en charge TLS 1.1 ou une version ultérieure.

Cela est vrai, par exemple, Android 4.1.1 mobile lorsque vous utilisez l’application portail de société Intune pour s’inscrire à ce périphérique. L’application Intune ne peut pas afficher la page de connexion ADFS.

Ceci est dû dans cette version Android TLS 1.1 est désactivé par défaut.

Vous pouvez obtenir plus d’informations sur ces problèmes potentiels en collectant les traces du réseau sur le serveur ADFS ou serveurs proxy lorsque vous reproduisez l’échec de connexion. Dans ce scénario, vous pouvez travailler avec le fournisseur du système d’exploitation client ou le fournisseur de l’application pour vérifier que les versions plus récentes de TLS sont prises en charge. ADFS ne peut pas mettre à jour des métadonnées de fédération.

Scénario 1


  • ADFS ne peut pas récupérer automatiquement de la Federationmetadata.xml depuis les approbations des parties de confiance ou approbations de fournisseur de revendications.
  • Lorsque vous essayez de mettre à jour le fichier XML manuellement, le message d’erreur suivant s’affiche :
    Une erreur s’est produite lors d’une tentative de lecture des métadonnées de fédération.




  • Ou bien, le message d’erreur suivant s’affiche lors de l’utilisation de Windows PowerShell :
    La connexion sous-jacente a été fermée. Une erreur inattendue s’est produite lors de la réception.


En analysant l’exception sous-jacente de plus près, nous pouvons voir les informations suivantes :

PS C:\> Update-AdfsRelyingPartyTrust -TargetName "Microsoft Office 365 Identity Platform"Update-AdfsRelyingPartyTrust : The underlying connection was closed: An unexpected error occurred on a receive.At line:1 char:1+ Update-AdfsRelyingPartyTrust -TargetName "Microsoft Office 365 Identity Platform ...+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~    + CategoryInfo          : NotSpecified: (Microsoft.Ident...lyingPartyTrust:RelyingPartyTrust) [Update-AdfsRelyingP   artyTrust], WebException    + FullyQualifiedErrorId : The underlying connection was closed: An unexpected error occurred on a receive.,Microso   ft.IdentityServer.Management.Commands.UpdateRelyingPartyTrustCommand PS C:\> $error[0] | fl * -fwriteErrorStream      : TruePSMessageDetails      :Exception             : System.Net.WebException: The underlying connection was closed: An unexpected error occurred on                        a receive. ---> System.ComponentModel.Win32Exception: The client and server cannot                        communicate, because they do not possess a common algorithm                           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)                           --- End of inner exception stack trace ---                           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.RelyingPartyTrustCategoryInfo          : NotSpecified: (Microsoft.Ident...lyingPartyTrust:RelyingPartyTrust)                        [Update-AdfsRelyingPartyTrust], WebExceptionFullyQualifiedErrorId : The underlying connection was closed: An unexpected error occurred on a                        receive.,Microsoft.IdentityServer.Management.Commands.UpdateRelyingPartyTrustCommandErrorDetails          : The underlying connection was closed: An unexpected error occurred on a receive.InvocationInfo        : System.Management.Automation.InvocationInfoScriptStackTrace      : at <ScriptBlock>, <No file>: line 1PipelineIterationInfo : {0, 1}


Lorsque nous analysons les traces réseau, nous ne voyons pas tout ClientHello. En outre, le client lui-même (ADFS) ferme la connexion (TCP FIN) lorsque nous attendre à envoyer le ClientHello :

3794   16:22:31 31/05/2016 4.0967400    (4588)      adfs1  nexus.microsoftonline-p.com.nsatc.net  TCP    8192   TCP: [Bad CheckSum]Flags=CE....S., SrcPort=56156, DstPort=HTTPS(443) 4013   16:22:32 31/05/2016 4.1983176    (0)   nexus.microsoftonline-p.com.nsatc.net   adfs1  TCP    2097152      TCP:Flags=...A..S., SrcPort=HTTPS(443), DstPort=56156 4021   16:22:32 31/05/2016 4.1983388    (0)   adfs1  nexus.microsoftonline-p.com.nsatc.net     TCP    131328 TCP: [Bad CheckSum]Flags=...A...., SrcPort=56156, DstPort=HTTPS(443)4029   16:22:32 31/05/2016 4.1992083    (4588)      adfs1  nexus.microsoftonline-p.com.nsatc.net  TCP    131328 TCP: [Bad CheckSum]Flags=...A...F, SrcPort=56156, DstPort=HTTPS(443)4057   16:22:32 31/05/2016 4.2999711    (0)   nexus.microsoftonline-p.com.nsatc.net   adfs1  TCP    0      TCP:Flags=...A.R.., SrcPort=HTTPS(443), DstPort=56156

La raison en est que les clés de Registre SChannel ont été créés. Ces supprimer la prise en charge de SSL 3.0 ou TLS 1.0 en tant que client.

Toutefois, la clé SchUseStrongCrypto n’a pas été créée. Ainsi, une fois que nous avons établi la session TCP/IP, le ClientHello doit être envoyée grâce à ces conditions :

  • .NET à l’aide d’une cryptographie faible (uniquement TLS 1.0 et versions antérieures)
  • SChannel est configuré pour utiliser uniquement TLS 1.1 ou une version ultérieure
Résolution : Appliquer SchUseStrongCrypto et redémarrez l’ordinateur.

HTTP 503 dans l’accès aux services Office 365

Scénario 2

  • TLS 1.1 et les versions ultérieures sont pris en charge dans le serviceOffice d’ADFS.
  • Vous avez un domaine fédéré O365.
  • Le client accède à certains service O365 utilisant proxiedauthentication : application cliente envoyé l’information d’identification à l’aide de base HTTP, et le service O365 utilise ces informations d’identification dans une nouvelle connexion à ADFS pour l’authentification de l’utilisateur.
  • L’envoie de service cloud un TLS 1.0 pour ADFS et ADFS ferme la connexion.
  • Le client reçoit une réponse HTTP 503.
Par exemple, cela est vrai lorsque vous accédez à la découverte automatique. Dans ce scénario, les clients Outlook sont affectés. Ceci peut être facilement reproduit en ouvrant un navigateur web et allez à https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.

xmlRequest envoyé:

GET https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml HTTP/1.1Host: autodiscover-s.outlook.comUser-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflate, brConnection: keep-aliveAuthorization: Basic (REMOVED FOR PRIVACY)
Réponse reçue du service Exchange Online :

HTTP/1.1 503 Service UnavailableCache-Control: privateRetry-After: 30Server: Microsoft-IIS/8.0request-id: 33c23dc6-2359-44a5-a819-03f3f8e85aaeX-CalculatedBETarget: db4pr04mb394.eurprd04.prod.outlook.comX-AutoDiscovery-Error: LiveIdBasicAuth:FederatedStsUnreachable:<X-forwarded-for:179.159.146.135><FederatedSTSFailure>System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send.;X-DiagInfo: DB4PR04MB394X-BEServer: DB4PR04MB394X-AspNet-Version: 4.0.30319Set-Cookie: X-BackEndCookie2=; expires=Tue, 27-May-1986 11:30:37 GMT; path=/Autodiscover; secure; HttpOnlySet-Cookie: X-BackEndCookie=; expires=Tue, 27-May-1986 11:30:37 GMT; path=/Autodiscover; secure; HttpOnlyX-Powered-By: ASP.NETX-FEServer: AM3PR05CA0056Date: Fri, 27 May 2016 11:30:38 GMTContent-Length: 0

Analyse des traces réseau dans le serveur WAP, nous pouvons voir plusieurs connexions provenant de notre nuage, comme suit. WAP termine (TCP RST) ces connexions dès qu’il reçoit du Client Hello.

3282   13:30:37 27/05/2016 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 ( Negotiating scale factor 0x8 ) = 81923285   13:30:37 27/05/2016 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 ( Negotiated scale factor 0x8 ) = 81923286   13:30:37 27/05/2016 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=5173293   13:30:37 27/05/2016 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   13:30:37 27/05/2016 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 (scale factor 0x0) = 0

Nous constatons également que Hello Client utilise TLS 1.0 :
 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 = 132.245.225.68, Dest = 10.10.1.5, 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: Transport Layer Security (TLS) Payload Data- TLS: TLS Rec Layer-1 HandShake: Client Hello.  - TlsRecordLayer: TLS Rec Layer-1 HandShake:     ContentType: HandShake:   - Version: TLS 1.0      Major: 3 (0x3)      Minor: 1 (0x1)     Length: 111 (0x6F)   - SSLHandshake: SSL HandShake ClientHello(0x01)      HandShakeType: ClientHello(0x01)      Length: 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: Server Name(0x0000)        ExtensionType: Server Name(0x0000)        ExtensionLength: 19 (0x13)        NameListLength: 17 (0x11)        NameType: Host Name (0)        NameLength: 14 (0xE)        ServerName: sts.contoso.net     + ClientHelloExtension: Elliptic Curves(0x000A)     + ClientHelloExtension: EC Point Formats(0x000B)    + ClientHelloExtension: SessionTicket TLS(0x0023)     + ClientHelloExtension: Unknown Extension Type     + ClientHelloExtension: Renegotiation Info(0xFF01)
Dans ce scénario, il est prévu que les proxy ADFS rejette la connexion. Ce problème a été signalé à l’équipe Exchange Online et est soumis à l’enquête.

Solutions de contournement :

  • Utiliser l’authentification moderne.

    Remarque Cela n’a pas été testée. Toutefois, du point de vue conceptuel, la connexion à ADFS est directement à partir de l’application cliente. Par conséquent, il doit fonctionner si elle prend en charge TLS 1.1.
  • Réactiver la fonctionnalité TLS 1.0 serveur de proxy WAP/ADFS.
Références
Fournisseur de Service niveau 1 données sécurité Standard (DSS) paiement carte industrie (PCI)

AJOUTE : La sécurité : transition de TLS 1.0 pour TLS 1.1 et TLS 1.2

La désactivation de TLS 1.0 et les versions antérieures dans le Proxy de l’Application Web

Avis de non-responsabilité

Les produits tiers dont traite cet article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute forme de garantie, expresse ou implicite, concernant les performances ou la fiabilité de ces produits.


Avis de non-responsabilité

Microsoft fournit des informations pour contacter des sociétés tierces afin de vous aider à obtenir une aide technique. Ces coordonnées peuvent changer sans préavis. Microsoft ne garantit pas l'exactitude des informations de contact de ces tiers.

Avertissement : Cet article a été traduit automatiquement.

Propriétés

ID d'article : 3194197 - Dernière mise à jour : 10/17/2016 22:06:00 - Révision : 1.0

  • kbmt KB3194197 KbMtfr
Commentaires