Consideraciones para deshabilitar y reemplazar TLS 1.0 en ADFS

IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.

Haga clic aquí para ver el artículo original (en inglés): 3194197
Resumen
Muchos clientes están considerando la opción Deshabilitar TLS 1.0 y protocolo RC4 en los servicios de federación de Active Directory (AD FS) y reemplazarlo con TLS 1.1 o una versión posterior. Este artículo describe los problemas que pueden ocurrir si deshabilita TLS 1.0 y proporciona instrucciones para ayudarle a completar el proceso.
Síntomas
Después de deshabilitar TLS 1.0 en servidores de proxy (WAP) AD FS o AD FS, esos servidores pueden experimentar algunos de los síntomas siguientes:

  • Se produce un error en la conectividad entre un servidor de proxy de AD FS y un servidor de AD FS. Esto puede causar cualquiera de las siguientes condiciones:

    • Se produce un error en la configuración de proxy en el asistente o mediante el uso de Windows PowerShell.
    • Id. de eventos 422 se registra en los servidores proxy de AD FS: "No se puede recuperar la configuración de proxy del servicio de federación".
    • Servidores proxy no puede reenviar el tráfico a los servidores de AD FS y se genera el siguiente mensaje de error:
      Error HTTP 503: el servicio no está disponible.
  • ADFS no puede actualizar los metadatos de federación del confiar confía en el fabricante o reclamaciones proveedor confía en que están configurados.
  • Recibirá un mensaje de error 503 de HTTP:
    El servicio no está disponible. HTTP 503 acceso a Office 365 servicios para dominios federados".
  • Recibirá un mensaje de error RDP:
    Se perdió la conectividad RDP a los servidores.
Causa
Este problema se produce si los clientes deshabilitar protocolos antiguos mediante claves del registro de SChannel. Para obtener un ejemplo de esta práctica, consulte el texto relacionado en el "Más información.
Solución
Importante: siga cuidadosamente los pasos de esta sección. Pueden producirse problemas graves si modifica incorrectamente el registro. Antes de modificarlo, copia de seguridad del registro para la restauración por si se produjeran problemas.

ADFS se desarrolla utilizando.NET Framework. Para las aplicaciones de .NET admitir criptografía segura (es decir, TLS 1.1 y anterior), primero debe instalar las actualizaciones que se describen en el documento informativo de seguridad siguiente:
Importante: Los clientes que ejecutan aplicaciones de.NET Framework 3.5 en Windows 10 o en aplicaciones de.NET Framework 4.5/4.5.1/4.5.2 en sistemas que tienen la 4.6 de.NET Framework instalada deben seguir los pasos que se proporcionan en este documento informativo para deshabilitar manualmente RC4 en TLS. Para obtener más información, consulte la sección "Acciones recomendadas" del documento informativo.

Notas:

  • Sistemas que ejecutan la 4.6 de.NET Framework sólo están protegidos de forma predeterminada y no tienen que actualizarse.
  • Los pasos adicionales desde el asesoramiento de seguridad requieren la creación de la clave del registro SchUseStrongCrypto , como se describe en el artículo consultivo.

    Ejemplos de subclaves de esta clave del registro nuevo:
    [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

  • Para aplicar el cambio, debe reiniciar los siguientes servicios y aplicaciones:

    • Servicio de ADFS (adfssrv)
    • Servicio de registro de dispositivo (drs)
    • Cualquier otra aplicación de .NET que podría estar ejecutándose en el servidor
    • El grupo de aplicaciones de servicios de Internet Information Server (IIS) para ADFS (sólo se aplica a ADFS 2.0 y 2.1 de ADFS)
Más información
Importante: siga cuidadosamente los pasos de esta sección. Pueden producirse problemas graves si modifica incorrectamente el registro. Antes de modificarlo, copia de seguridad del registro para la restauración por si se produjeran problemas.

Deshabilitación de protocolos antiguos en el registro

Un ejemplo de la deshabilitación de protocolos antiguos mediante el uso de las claves del registro de SChannel sería configurar los valores de las subclaves del registro en la lista siguiente. Deshabilitar el SSL 3.0, TLS 1.0 y protocolos de RC4. Dado que esta situación se aplica a SChannel, afecta a todas las conexiones de SSL/TLS para y desde el servidor.

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

Nota: Debe reiniciar el equipo después de cambiar estos valores.

Para comprobar que un servidor que esté conectado a Internet correctamente ha deshabilitado los protocolos antiguos, puede utilizar cualquier comprobador de prueba SSL en línea como Qualys SSL Labs. Para obtener más información, consulte el siguiente sitio Web de Qualys:

Solución alternativa

Como alternativa al uso de la clave del registro SchUseStrongCrypto , puede utilizar la clave del registro SystemDefaultTlsVersions cuando se utiliza el.NET Framework 3.5.1.

SystemDefaultTlsVersions está disponible después de instalar actualización 3154518.

Después de configurar las claves del registro, el servicio ADFS respeta el trabajo y los valores predeterminados de SChannel.

Efectos secundarios conocidos

Las aplicaciones cliente no pueden conectarse al servidor de ADFS o proxy ADFS para la autenticación

Al deshabilitar TLS 1.0 y versiones anteriores en servidores ADFS y los proxies, las aplicaciones de cliente que están intentando conectarse a él deben admitir TLS 1.1 o versiones posteriores.

Esto es cierto, por ejemplo, Android 4.1.1 móvil cuando se utiliza la aplicación de Portal de empresa Intune para inscribir a ese dispositivo. La aplicación Intune no puede mostrar la página de inicio de sesión de ADFS.

Se espera que en esta versión de Android porque TLS 1.1 está deshabilitada de forma predeterminada.

Puede obtener más detalles acerca de estos posibles problemas mediante la recopilación de seguimientos de red en el servidor de ADFS o servidores proxy mientras reproduce el error de conexión. En este escenario, puede trabajar con el proveedor del sistema operativo cliente o el proveedor de la aplicación para comprobar que las versiones más recientes de TLS son compatibles. ADFS no puede actualizar los metadatos de federación.

Escenario 1


  • ADFS no puede recuperar automáticamente la Federationmetadata.xml de la confiar confía en parte o confía en el proveedor de notificaciones.
  • Cuando intenta actualizar el archivo XML manualmente, recibirá el siguiente mensaje de error:
    Se produjo un error al intentar leer los metadatos de federación.




  • O bien, recibirá el siguiente mensaje de error al usar Windows PowerShell:
    Se cerró la conexión subyacente. Se ha producido un error inesperado de recepción.


Al analizar la excepción subyacente más de cerca, podemos ver la siguiente información:

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}


Cuando analizamos las trazas de red, no vemos cualquier ClientHello. Además, el propio (ADFS) cliente cierra la conexión (TCP FIN) cuando esperaríamos que le envíe el 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 razón de esto es que se han creado las claves del registro de SChannel. Estos eliminar la compatibilidad con SSL 3.0 o TLS 1.0 como cliente.

Sin embargo, no se creó la clave SchUseStrongCrypto . Así que después establecemos la sesión TCP/IP, debe enviarse el ClientHello al tener estas condiciones:

  • .NET usando un cifrado débil (sólo TLS 1.0 y versiones anteriores)
  • SChannel configurado para utilizar sólo TLS 1.1 o versiones posteriores
Resolución: Aplicar SchUseStrongCrypto y reiniciar el equipo.

503 de HTTP en el acceso a los servicios de Office 365

Escenario 2

  • Sólo TLS 1.1 y versiones posteriores son compatibles con la serviceOffice ADFS.
  • Tiene un dominio federado O365.
  • El cliente tiene acceso a algún servicio O365 que utiliza proxiedauthentication: aplicación cliente envía las credenciales mediante básica HTTP y el servicio O365 utiliza esas credenciales en una nueva conexión con ADFS para autenticar al usuario.
  • El envía de servicio de nube un TLS 1.0 a ADFS y ADFS, se cierra la conexión.
  • El cliente recibe una respuesta HTTP 503.
Por ejemplo, esto es cierto cuando tiene acceso a detección automática. En este escenario, se ven afectados los clientes de Outlook. Esto se puede reproducir fácilmente para abrir un explorador web y vaya a https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.

xmlRequest enviado:

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)
Respuesta recibida del servicio 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

Análisis de trazas de red en el servidor WAP, podemos ver varias conexiones procedentes de nuestra nube, como sigue. WAP termina (TCP RST) estas conexiones poco después de que recibe el cliente 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

También vemos que cliente Hello utiliza 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)
En este escenario, se espera que el proxy ADFS está rechazando la conexión. Este problema se ha informado que el equipo de Exchange Online y está investigando.

Soluciones:

  • Utilizar autenticación modernos.

    Nota: Esto no ha sido probado. Sin embargo, conceptualmente, es la conexión con ADFS directamente desde la aplicación cliente. Por lo tanto, debe funcionar si es compatible con TLS 1.1.
  • Volver a habilitar el servidor de TLS 1.0 de proxy WAP/ADFS.
Referencias
Nivel 1 servicio proveedor de pago tarjeta (PCI) de la industria datos seguridad estándar (DSS)

AGREGA: Seguridad: transición de TLS 1.0 a TLS 1.1 y 1.2 de TLS

Deshabilitar TLS 1.0 y versiones anteriores en el Proxy de aplicación Web

Aviso legal de información de terceros

Los productos de terceros que se indican este artículo están fabricados por compañías independientes de Microsoft. Microsoft no otorga ninguna garantía, implícita o de otro tipo, respecto al rendimiento o confiabilidad de estos productos.


Aviso legal de información de terceros

Microsoft proporciona información de contacto de terceros para ayudarle a encontrar soporte técnico. Esta información de contacto puede cambiar sin previo aviso. Microsoft no garantiza la exactitud de esta información de contacto de terceros.

Advertencia: este artículo se tradujo automáticamente

Propiedades

Id. de artículo: 3194197 - Última revisión: 10/17/2016 22:05:00 - Revisión: 1.0

  • kbmt KB3194197 KbMtes
Comentarios