Considerazioni per la disattivazione e la sostituzione di TLS 1.0 in ADFS

IMPORTANTE: il presente articolo è stato tradotto tramite un software di traduzione automatica di Microsoft ed eventualmente revisionato dalla community Microsoft tramite la tecnologia CTF (Community Translation Framework) o da un traduttore professionista. Microsoft offre articoli tradotti manualmente e altri tradotti automaticamente e rivisti dalla community con l’obiettivo di consentire all'utente di accedere a tutti gli articoli della Knowledge Base nella propria lingua. Tuttavia, un articolo tradotto automaticamente, anche se rivisto dalla community, non sempre è perfetto. Potrebbe contenere errori di vocabolario, di sintassi o di grammatica. Microsoft declina ogni responsabilità per imprecisioni, errori o danni causati da una traduzione sbagliata o dal relativo utilizzo da parte dei clienti. Microsoft aggiorna frequentemente il software e gli strumenti di traduzione automatica per continuare a migliorare la qualità della traduzione.

Clicca qui per visualizzare la versione originale in inglese dell’articolo: 3194197
Sommario
Molti clienti stanno prendendo in considerazione la possibilità di disattivare il protocollo di RC4 in Active Directory Federation Services (ADFS) e TLS 1.0 e sostituirlo con TLS 1.1 o versione successiva. In questo articolo vengono illustrati i problemi che possono verificarsi se si disattiva TLS 1.0 e è fornite indicazioni per completare il processo.
Sintomi
Dopo avere disattivato TLS 1.0 server ADFS o AD FS proxy (WAP), i server potrebbero verificarsi alcuni dei seguenti sintomi:

  • La connettività tra un proxy di AD FS e un server ADFS non riesce. Ciò potrebbe causare una delle seguenti condizioni:

    • La configurazione del proxy ha esito negativo della procedura guidata oppure utilizzando Windows PowerShell.
    • ID di eventi 422 è connesso il proxy di AD FS: "Impossibile recuperare la configurazione del proxy servizio federativo".
    • Proxy non è in grado di inoltrare il traffico ai server ADFS e viene generato il seguente messaggio di errore:
      Errore HTTP 503: il servizio è disponibile.
  • ADFS non è in grado di aggiornare i metadati di federazione dell'attendibilità componente o trust tra Provider di attestazioni configurati.
  • Viene visualizzato un messaggio di errore HTTP 503:
    Il servizio è disponibile. HTTP 503 accesso a Office 365 servizi per i domini federati."
  • Viene visualizzato un messaggio di errore RDP:
    Perdita di connettività RDP ai server.
Cause
Questo problema si verifica se i clienti Disattiva precedenti protocolli utilizzando le chiavi del Registro di sistema SChannel. Per un esempio di questa procedura, vedere il testo correlato al "Ulteriori informazioni" sezione.
Risoluzione
Importante Seguire attentamente i passaggi in questa sezione. L'errata modifica del Registro di sistema può causare problemi gravi. Prima di modificarlo, eseguire il backup del Registro di sistema per il ripristino nel caso in cui si verifichino problemi.

ADFS è sviluppato utilizzando.NET Framework. Per le applicazioni .NET supportare la crittografia avanzata (ovvero, TLS 1.1 e versioni successive), è necessario installare gli aggiornamenti descritti nell'advisory sulla sicurezza seguenti:
Importante I clienti che eseguono applicazioni.NET Framework 3.5 su 10 di Windows o applicazioni di 4.5/4.5.1/4.5.2 di.NET Framework nei sistemi in cui il 4.6 di.NET Framework installato è necessario seguire i passaggi forniti in questo advisory per disattivare manualmente RC4 in TLS. Per ulteriori informazioni, vedere la sezione "Interventi consigliati" di questo advisory.

Note

  • I sistemi che eseguono il 4.6 di.NET Framework solo protetti per impostazione predefinita e non devono essere aggiornate.
  • I passaggi aggiuntivi da advisory sulla sicurezza richiedono la creazione di chiave di registro SchUseStrongCrypto , come descritto nell'articolo consultivo.

    Esempi di sottochiavi per questa nuova chiave del Registro di sistema:
    [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

  • Per applicare la modifica, è necessario riavviare i seguenti servizi e applicazioni:

    • Servizio ADFS (adfssrv)
    • Servizio registrazione dispositivi (drs)
    • Qualsiasi altra applicazione .NET che potrebbe essere in esecuzione sul server
    • Il pool di applicazioni Internet Information Services (IIS) per ADFS (valido solo per ADFS 2.0 e 2.1 di ADFS)
Informazioni
Importante Seguire attentamente i passaggi in questa sezione. L'errata modifica del Registro di sistema può causare problemi gravi. Prima di modificarlo, eseguire il backup del Registro di sistema per il ripristino nel caso in cui si verifichino problemi.

La disattivazione dei protocolli precedenti nel Registro di sistema

Un esempio di disattivazione precedenti protocolli utilizzando le chiavi del Registro di sistema SChannel, è possibile configurare i valori nelle sottochiavi del Registro di sistema elencati di seguito. Questi disabilitare SSL 3.0, TLS 1.0 e protocolli RC4. Perché questa situazione si applica a SChannel, influisce su tutte le connessioni SSL/TLS da e verso il server.

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 È necessario riavviare il computer dopo la modifica di questi valori.

Per verificare che un server connesso a Internet è disabilitato correttamente protocolli precedenti, è possibile utilizzare qualsiasi verifier SSL Test online, quali laboratori SSL Qualys. Per ulteriori informazioni, vedere il seguente sito Web Qualys:

Soluzione alternativa

In alternativa all'utilizzo della chiave del Registro di sistema SchUseStrongCrypto , è possibile utilizzare la chiave del Registro di sistema SystemDefaultTlsVersions quando si utilizza il.NET Framework 3.5.1.

SystemDefaultTlsVersions è disponibile dopo l'installazione aggiornamento 3154518.

Dopo aver impostate le chiavi del Registro di sistema, il servizio ADFS rispetta il lavoro e le impostazioni predefinite di SChannel.

Effetti collaterali noti

Le applicazioni client Impossibile connettersi al server ADFS o proxy per l'autenticazione di ADFS

Quando si disabilita TLS 1.0 e versioni precedenti sul proxy e server ADFS, devono supportare le applicazioni client che siano tentando di connettersi a esso TLS 1.1 o versioni successive.

Ciò avviene, ad esempio, di Android 4.1.1 mobile quando si utilizza l'applicazione di portale di società Intune per registrare il dispositivo. L'applicazione Intune Impossibile visualizzare la pagina di accesso ADFS.

È previsto in questa versione Android perché TLS 1.1 è disattivata per impostazione predefinita.

È possibile ottenere ulteriori informazioni su questi problemi mediante la raccolta di tracce di rete sul server ADFS o proxy mentre si riproduce un errore di connessione. In questo scenario, è possibile utilizzare con il fornitore del sistema operativo client o il fornitore dell'applicazione per verificare che le versioni più recenti di TLS sono supportate. ADFS non può aggiornare i metadati di federazione.

Scenario 1


  • ADFS non recupera automaticamente il FederationMetadata dall'attendibilità componente o trust tra Provider di attestazioni.
  • Quando si tenta di aggiornare manualmente il file XML, viene visualizzato il seguente messaggio di errore:
    Si è verificato un errore durante il tentativo di leggere i metadati di federazione.




  • In alternativa, viene visualizzato il seguente messaggio di errore quando si utilizza Windows PowerShell:
    La connessione sottostante chiusa. Si è verificato un errore imprevisto durante un'operazione di ricezione.


Analizzando attentamente l'eccezione sottostante, è possibile vedere le seguenti informazioni:

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}


Quando si analizzano le tracce di rete, non vediamo qualsiasi ClientHello. Inoltre, il client (ADF) sta chiudendo la connessione (TCP FIN) quando si prevede di inviare il 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

Il motivo è che sono state create le chiavi del Registro di sistema SChannel. Questi rimuovere il supporto per SSL 3.0 o TLS 1.0 come client.

Tuttavia, non è stata creata la chiave SchUseStrongCrypto . Pertanto dopo abbiamo stabilito la sessione TCP/IP, il ClientHello deve essere inviata dalla presenza di queste condizioni:

  • .NET utilizzando la crittografia debole (solo TLS 1.0 e versioni precedenti)
  • SChannel è configurato per utilizzare solo TLS 1.1 o versioni successive
Risoluzione: Applicare SchUseStrongCrypto e riavviare il computer.

HTTP 503 nell'accesso ai servizi di Office 365

Scenario 2

  • Solo TLS 1.1 e versioni successive sono supportate in serviceOffice di ADFS.
  • Si dispone di un dominio federato O365.
  • Il client accede alcuni servizi di O365 che utilizzano proxiedauthentication: applicazione Client inviato le credenziali utilizzando HTTP Basic e il servizio O365 utilizza tali credenziali in una nuova connessione per ADFS per autenticare l'utente.
  • L'invia servizio cloud un TLS 1.0 per ADFS e ADFS chiude la connessione.
  • Il client riceve una risposta HTTP 503.
Ad esempio, questo avviene quando si accede di individuazione automatica. In questo scenario, i client di Outlook sono interessati. Questa operazione può essere facilmente riprodotto aprendo un browser web e passare a https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.

xmlRequest inviato:

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)
Risposta ricevuta dal servizio in linea di Exchange:

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

Analisi delle tracce di rete del server WAP, possiamo vedere più connessioni provenienti dal nostro cloud, come indicato di seguito. Queste connessioni WAP termina (TCP RST), subito dopo aver ricevuto il 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

Abbiamo inoltre verificare che Hello Client utilizza 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)
In questo scenario, è probabile che il proxy ADFS non accetta la connessione. Questo problema è stato segnalato al team di Exchange Online ed è oggetto dell'inchiesta.

Soluzioni alternative:

  • Utilizzare l'autenticazione moderno.

    Nota Questo non è stato testato. Concettualmente, tuttavia, la connessione ad ADFS è direttamente dall'applicazione client. Pertanto, dovrebbe funzionare se supporta TLS 1.1.
  • Riattivare TLS 1.0 Server nel proxy WAP/ADFS.
Riferimenti
Pagamento carta industria (PCI) protezione Standard (DSS) livello 1 del servizio Provider di dati

AGGIUNGE: Protezione: passaggio da TLS 1.0 a TLS 1.1 e TLS 1.2

Disattivazione di TLS 1.0 e versioni precedenti nel Proxy di applicazione Web

Declinazione di responsabilità di informazioni di terze parti

I prodotti di terze parti descritti in questo articolo sono forniti da società indipendenti da Microsoft. Microsoft esclude ogni garanzia, implicita o esplicita relativa alle prestazioni o all'affidabilità di tali prodotti.


Declinazione di responsabilità di informazioni di terze parti

Microsoft fornisce informazioni di contatto di terze parti per facilitare l'individuazione del supporto tecnico. Tali informazioni potrebbero cambiare senza preavviso. Microsoft non garantisce l'accuratezza delle informazioni per contattare altri produttori.

Avviso: questo articolo è stato tradotto automaticamente

Proprietà

ID articolo: 3194197 - Ultima revisione: 10/17/2016 22:09:00 - Revisione: 1.0

  • kbmt KB3194197 KbMtit
Feedback