Pertimbangan untuk menonaktifkan dan mengganti TLS 1.0 di ADFS

PENTING: Artikel ini diterjemahkan oleh perangkat lunak penerjemahan mesin Microsoft, dan mungkin telah diedit oleh Masyarakat Microsoft melalui teknologi CTF dan bukan oleh seorang penerjemah profesional. Microsoft menawarkan baik artikel yang diterjemahkan oleh manusia maupun artikel hasil editan terjemahan oleh mesin/komunitas, sehingga Anda dapat mengakses semua artikel di Sentra Pengetahuan yang kami miliki dalam berbagai bahasa. Namun artikel hasil editan mesin atau bahkan komunitas tidak selalu sempurna. Artikel ini dapat mengandung kesalahan dalam hal kosa kata, sintaksis atau tatabahasa, sangat mirip dengan penutur asing yang membuat kekeliruan ketika berbicara dalam bahasa Anda. Microsoft tidak bertanggung jawab atas ketidakakuratan, kesalahan atau kerugian apa pun akibat dari kekeliruan dalam penerjemahan isi atau penggunaannya oleh pelanggan kami. Microsoft juga akan senantiasa memperbarui perangkat lunak penerjemahan mesin dan alat untuk menyempurnakan Editan Hasil Penerjemahan Mesin.

Klik disini untuk melihat versi Inggris dari artikel ini: 3194197
Ringkasan
Banyak pelanggan mempertimbangkan opsi untuk menonaktifkan TLS 1.0 dan RC4 protokol di Active Directory Federation Services (AD FS), dan ganti dengan TLS 1.1 atau versi yang lebih baru. Artikel ini membahas masalah yang dapat terjadi jika Anda menonaktifkan TLS 1.0, dan memberikan panduan untuk membantu Anda menyelesaikan proses.
Gejala
Setelah Anda menonaktifkan TLS 1.0 di AD FS atau AD FS server proksi (WAP), server tersebut mungkin mengalami beberapa gejala berikut ini:

  • Konektivitas antara AD FS server proksi AD FS dan gagal. Hal ini dapat menyebabkan salah satu dari kondisi berikut ini:

    • Konfigurasi proksi gagal wizard atau dengan menggunakan Windows PowerShell.
    • ID Kejadian 422 masuk proxy AD FS: "Tidak dapat mengambil konfigurasi proksi dari layanan Federasi."
    • Proxy tidak dapat diteruskan lalu lintas AD FS server, dan pesan galat berikut yang dihasilkan:
      Galat HTTP 503-Layanan tidak tersedia.
  • ADFS tidak dapat memperbarui metadata Federasi mengandalkan pihak kepercayaan atau klaim penyedia kepercayaan yang dikonfigurasi.
  • Anda menerima pesan galat HTTP 503:
    Layanan tidak tersedia. HTTP 503 mengakses ke Office 365 layanan untuk domain federasi."
  • Anda menerima pesan galat RDP:
    Konektivitas RDP hilang ke server.
Penyebab
Masalah ini terjadi jika pelanggan menonaktifkan protokol lama dengan menggunakan bukti kunci registri SChannel. Untuk contoh praktik ini, lihat teks terkait "Informasi lebih lanjut"bagian.
Pemecahan masalah
Penting Ikuti langkah-langkah di bagian ini dengan seksama. Masalah serius dapat terjadi apabila Anda salah mengubah registri. Sebelum Anda mengubahnya, membuat cadangan registri untuk pemulihan Jika masalah terjadi.

ADFS dikembangkan dengan menggunakan .NET Framework. Untuk aplikasi .NET untuk mendukung kriptografi yang kuat (yaitu, TLS 1.1 dan di atas), Anda harus menginstal pemutakhiran yang dijelaskan di penasihat keamanan berikut ini:
Penting Pelanggan yang menjalankan aplikasi .NET Framework 3.5 Windows 10 atau aplikasi 4.5/4.5.1/4.5.2 .NET Framework pada sistem yang memiliki .NET Framework 4.6 diinstal harus mengikuti langkah-langkah yang disediakan dalam penasihat ini secara manual Nonaktifkan RC4 di TLS. Untuk informasi selengkapnya, lihat bagian "Menyarankan tindakan" penasihat.

Catatan

  • Sistem yang menggunakan .NET Framework 4.6 hanya dilindungi secara asali dan tidak harus diperbarui.
  • Langkah-langkah tambahan dari penasihat keamanan mengharuskan Anda membuat bukti kunci registri SchUseStrongCrypto , seperti yang dijelaskan dalam artikel penasihat.

    Contoh subkunci untuk bukti kunci registri baru:
    [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

  • Untuk menerapkan perubahan, Anda harus memulai ulang layanan dan aplikasi berikut ini:

    • ADFS Layanan (adfssrv)
    • Alat registrasi Layanan (drs)
    • Aplikasi .NET lainnya yang mungkin dijalankan di server
    • Pool aplikasi layanan informasi Internet (IIS) untuk ADFS (hanya berlaku untuk ADFS 2.0 dan ADFS 2.1)
Informasi lebih lanjut
Penting Ikuti langkah-langkah dalam bagian ini dengan seksama. Masalah serius dapat terjadi jika Anda salah mengubah registri. Sebelum Anda mengubahnya, membuat cadangan registri untuk pemulihan apabila terjadi masalah.

Menonaktifkan protokol yang lama di registri

Contoh menonaktifkan protokol lama dengan menggunakan bukti kunci registri SChannel akan mengkonfigurasi nilai di subkunci registri di bawah ini. Ini menonaktifkan SSL 3.0, TLS 1.0, dan protokol RC4. Karena situasi ini berlaku untuk SChannel, hal itu mempengaruhi semua sambungan SSL/TLS ke dan dari 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

Catatan Anda harus me-restart komputer setelah Anda mengubah nilai-nilai ini.

Untuk memverifikasi bahwa server yang tersambung ke Internet telah berhasil dinonaktifkan protokol yang lama, Anda dapat menggunakan apa pun verifier SSL uji online seperti Qualys SSL Labs. Untuk informasi selengkapnya, lihat situs web Qualys berikut:

Solusi alternatif

Sebagai alternatif untuk menggunakan bukti kunci registri SchUseStrongCrypto , Anda dapat menggunakan bukti kunci registri SystemDefaultTlsVersions ketika Anda menggunakan .NET Framework 3.5.1.

SystemDefaultTlsVersions tersedia setelah Anda menginstal Pemutakhiran 3154518.

Setelah bukti kunci registri ditetapkan, Layanan ADFS kehormatan SChannel default dan bekerja.

Efek samping yang diketahui

Aplikasi klien tidak dapat menyambung ke ADFS server atau proxy ADFS untuk otentikasi

Ketika Anda menonaktifkan TLS 1.0 dan versi yang lebih lawas di ADFS server dan proxy, aplikasi klien yang mencoba untuk menyambung ke harus mendukung TLS 1.1 atau versi yang lebih baru.

Ini benar, misalnya, Android mobile 4.1.1 ketika Anda menggunakan aplikasi Portal perusahaan Intune untuk mendaftar peranti penangkap tersebut. Intune aplikasi tidak dapat menampilkan halaman masuk ADFS.

Hal ini diharapkan versi Android ini karena TLS 1.1 dinonaktifkan secara asali.

Anda bisa mendapatkan rincian selengkapnya tentang potensi masalah ini dengan pengumpulan jejak jaringan ADFS server atau proxy saat Anda mereproduksi kegagalan koneksi. Dalam skenario ini, Anda dapat bekerja dengan klien OS vendor atau vendor aplikasi untuk memverifikasi bahwa TLS versi yang lebih baru yang didukung. ADFS tidak dapat memperbarui metadata Federasi.

Skenario 1


  • ADFS secara otomatis tidak dapat mengambil Federationmetadata.xml dari mengandalkan kepercayaan pihak atau penyedia klaim kepercayaan.
  • Ketika Anda mencoba untuk memperbarui berkas XML secara manual, Anda menerima pesan galat berikut:
    Terjadi kesalahan selama upaya untuk membaca metadata Federasi.




  • Atau, Anda menerima pesan galat ketika Anda menggunakan Windows PowerShell:
    Sambungan utama ditutup. Galat tak terduga terjadi pada terima.


Dengan menganalisis pengecualian dasar secara lebih dekat, kami dapat melihat informasi berikut ini:

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}


Ketika kita menganalisis jejak jaringan, kami tidak melihat ClientHello apa pun. Juga, klien sendiri (ADFS) menutup sambungan (TCP FIN) ketika kita berharap kirim 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

Alasan untuk ini adalah bahwa bukti kunci registri SChannel dibuat. Ini menghapus dukungan untuk SSL 3.0, atau TLS 1.0 sebagai klien.

Namun, bukti kunci SchUseStrongCrypto tidak dibuat. Jadi setelah kami membuat sesi TCP/IP, ClientHello akan dikirim oleh memiliki kondisi berikut ini:

  • .NET menggunakan kriptografi lemah (hanya TLS 1.0 dan versi yang lebih lawas)
  • SChannel dikonfigurasi untuk hanya menggunakan TLS 1.1 atau versi yang lebih baru
Resolusi: Menerapkan SchUseStrongCrypto dan reboot.

HTTP 503 akses ke layanan Office 365

Skenario 2

  • Hanya TLS 1.1 dan versi yang lebih baru yang didukung di ADFS serviceOffice.
  • Anda memiliki domain gabungan O365.
  • Klien mengakses beberapa layanan O365 yang menggunakan proxiedauthentication: aplikasi klien mengirimkan kredensial yang menggunakan HTTP Basic, dan layanan O365 menggunakan kredensial tersebut dalam sambungan baru ke ADFS mengotentikasi pengguna.
  • Pengiriman layanan cloud TLS 1.0 ADFS, dan ADFS menutup sambungan.
  • Klien menerima respons HTTP 503.
Sebagai contoh, ini benar ketika Anda mengakses Autodiscover. Dalam skenario ini, klien Outlook yang terpengaruh. Hal ini dapat dengan mudah direproduksi dengan membuka web browser dan membuka https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.

xmlRequest dikirim:

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)
Tanggapan yang diterima dari layanan 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

Menganalisis jejak jaringan di WAP server, kita dapat melihat beberapa sambungan berasal dari cloud kami, sebagai berikut. WAP berakhir (TCP SOAL) sambungan tersebut segera setelah menerima klien Halo.

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

Kami juga melihat bahwa klien Halo menggunakan 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)
Dalam skenario ini, diharapkan bahwa ADFS proksi menolak sambungan. Masalah ini telah dilaporkan ke Exchange Online tim dan sedang diselidiki.

Pemecahan masalah:

  • Menggunakan otentikasi Modern.

    Catatan Ini belum diuji. Namun, secara konsep, sambungan ke ADFS adalah langsung dari aplikasi klien. Oleh karena itu, harus bekerja jika mendukung TLS 1.1.
  • Mengaktifkan ulang TLS 1.0 Server di WAP ADFS proxy.
Referensi
Pembayaran Kartu Bisnis industri (PCI) Data keamanan standar (DSS) tingkat 1 penyedia layanan

MENAMBAHKAN: Keamanan: transisi dari TLS 1.0 TLS 1.1 dan TLS 1.2

Menonaktifkan TLS 1.0 dan versi yang lebih lawas di proksi aplikasi web

Sanggahan informasi pihak ketiga

Produk pihak ketiga yang dibahas di artikel ini dibuat oleh perusahaan yang independen terhadap Microsoft. Microsoft tidak menyediakan jaminan, baik tersirat maupun tersurat, mengenai kinerja atau keandalan produk ini.


Sanggahan informasi pihak ketiga

Microsoft menyediakan informasi kontak pihak ketiga untuk membantu Anda menemukan dukungan teknis. informasi kontak ini dapat berubah tanpa pemberitahuan. Microsoft tidak menjamin keakuratan informasi kontak dari pihak ketiga ini.

Peringatan: Artikel ini telah diterjemahkan secara otomatis

Properti

ID Artikel: 3194197 - Tinjauan Terakhir: 10/17/2016 22:08:00 - Revisi: 1.0

  • kbmt KB3194197 KbMtid
Tanggapan