Memecahkan single sign-on (SSO) masalah dengan Active Directory Federation Services (AD FS)

Lanjutkan dengan pemecahan masalah untuk memeriksa kemungkinan masalah dengan pihak mengandalkan.

Lanjutkan dengan pemeriksaan tambahan pada pihak mengandalkan.

Lanjutkan pemecahan masalah untuk memeriksa sertifikat SSL.

Lanjutkan pemecahan masalah untuk memeriksa hubungan kepercayaan proxy antara proksi aplikasi Web dan AD FS.

Pengikatan mungkin konflik dengan AD FS sertifikat ikatan pada port 443.

Masalah apa yang mengalami pengguna dengan SSO?

Masalah ini dapat terjadi pada AD FS masuk halaman atau aplikasi.

Jika masalah ini terjadi di AD FS masuk halaman, Anda menerima "Galat terjadi", "HTTP 503 Layanan tidak tersedia" atau beberapa pesan galat lainnya. URL halaman galat menunjukkan nama Layanan AD FS seperti fs.contoso.com.

Jika masalah ini terjadi di sebelah aplikasi, URL halaman galat menampilkan alamat IP atau nama situs layanan target.

Di mana Anda mengalami masalah ini?

Apakah masalah ini mempengaruhi semua pengguna?

Pengguna dapat mengakses pihak mengandalkan?

Apakah masalah ini terjadi dalam skenario Azure AD?

Pengguna dapat mengakses pihak mengandalkan?

Jika token penandatanganan sertifikat diperbarui baru dengan AD FS, periksa jika sertifikat baru yang diambil oleh Federasi mitra. Dalam kasus AD FS menggunakan token dekripsi sertifikat yang juga telah diperbarui baru-baru ini, lakukan pemeriksaan sama juga. Untuk memeriksa jika saat ini AD FS token penandatanganan sertifikat di AD FS cocok dengan salah satu di Federasi mitra, ikuti langkah-langkah berikut:

  1. Dapatkan token sekarang penandatanganan sertifikat di AD FS dengan menjalankan perintah berikut ini:
    Get-ADFSCertificate -CertificateType token-signing

  2. Dalam daftar sertifikat kembali, temukan satu dengan IsPrimary = TRUE, dan buat catatan cap jempol.

  3. Dapatkan cap jempol token sekarang penandatanganan sertifikat di Federasi mitra. Pemilik aplikasi harus memberikan ini.

  4. Bandingkan cap jempol dua sertifikat .

Lakukan pemeriksaan sama jika menggunakan AD FS token baru dekripsi sertifikat, kecuali bahwa perintah untuk mendapatkan token dekripsi sertifikat di AD FS adalah sebagai berikut:
Get-ADFSCertificate -CertificateType token-decrypting

Jika token penandatanganan sertifikat atau token decrypting sertifikat ditandatangani sendiri, AutoCertificateRollover diaktifkan secara default pada sertifikat ini dan AD FS mengelola pembaruan otomatis sertifikat ketika mereka mendekati kedaluwarsa.

Untuk menentukan apakah Anda menggunakan sertifikat yang ditandatangani sendiri, ikuti langkah-langkah berikut:

  1. Jalankan perintah berikut ini:
    Get-ADFSCerticate -CertificateType "token-signing"
    Get-ADFSCertificate

  2. Periksa atribut sertifikat.
    Jika subjek dan penerbit atribut kedua dimulai dengan "CN = ADFS Signing...", sertifikat diri ditandatangani dan dikelola oleh AutoCertRollover.

Untuk mengkonfirmasi jika sertifikat memperbarui secara otomatis, ikuti langkah-langkah berikut:

  1. Jalankan perintah berikut ini:
    Get-ADFSProperties | FL AutoCertificateRollover
    Get-ADFSProperties

  2. Periksa atribut AutoCertificateRollover.

    • Jika AutoCertificateRollover = TRUE, AD FS secara otomatis menghasilkan sertifikat baru (30 hari sebelum berakhirnya secara default) dan menetapkan mereka sebagai sertifikat utama (25 hari sebelum berakhirnya).

    • Jika AutoCertificateRollover = FALSE, Anda harus secara manual mengganti sertifikat tersebut.

Apakah sesuai cap jempol?

Untuk memeriksa apakah ada ketidakcocokan, ikuti langkah-langkah berikut:

  1. Menentukan algoritma yang digunakan oleh pihak mengandalkan dengan menjalankan perintah berikut ini: Get-ADFSRelyingPartyTrust -Name RPName | FL SignatureAlgorithm

    Nilai kemungkinan SHA1 atau Sha256 .

  2. Periksa dengan pemilik aplikasi untuk algoritma yang digunakan di sebelah aplikasi.

  3. Periksa jika algoritma dua cocok.

Tidak ada ketidakcocokan?

Tidak pengguna mendapatkan prompt NTLM tak terduga atau wantian otentikasi berbasis formulir?

Pengguna tidak mendapatkan prompt tak terduga untuk otentikasi multi faktor? Atau tidak pengguna berulang kali mendapatkan prompt?

Apakah masalah ini terjadi dalam skenario Azure AD?

Apakah permintaan otentikasi yang dikirim ke Azure AD termasuk prompt = login parameter?

Parameter permintaan seperti WAUTH dan RequestedAuthNContext dalam permintaan otentikasi dapat memiliki metode otentikasi yang ditentukan. Adalah parameter permintaan penegakan wantian otentikasi tak terduga?

Gunakan metode berikut untuk pemecahan masalah.

Periksa status pengguna di Windows PowerShell atau UI. Jika pengguna dinonaktifkan, mengaktifkan pengguna.

Periksa status pengguna dengan Windows PowerShell

  1. Masuk ke salah satu kontroler domain.

  2. Buka Windows PowerShell.

  3. Periksa status pengguna dengan menjalankan perintah berikut ini:
    Get-ADUser -Identity <samaccountname of the user> | Select Enabled
    Get-ADUser

Periksa status pengguna di UI

  1. Masuk ke salah satu kontroler domain.

  2. Buka konsol manajemen pengguna direktori aktif dan komputer .

  3. Klik simpul pengguna , klik kanan pengguna di panel sebelah kanan, dan kemudian klik properti.

  4. Klik tab akun .

  5. Di bawah opsi akun, verifikasi jika akun dinonaktifkan dicentang.
    The "Account is disabled" option under Account options

  6. Jika opsi dicentang, Hapus centang.

Masalah diselesaikan?

Jika properti setiap pengguna yang diperbarui di direktori aktif, hasilnya perubahan metadata objek pengguna. Periksa objek metadata pengguna untuk melihat properti yang telah diperbarui baru-baru ini. Jika perubahan yang ditemukan, pastikan bahwa mereka yang diambil oleh layanan yang terkait. Untuk memeriksa apakah ada perubahan properti pengguna, ikuti langkah-langkah berikut ini:

  1. Masuk ke kontroler domain.

  2. Buka Windows PowerShell.

  3. Dapatkan metadata objek pengguna dengan menjalankan perintah berikut ini:
    repadmin /showobjmeta <destination DC> "user DN"

    Contoh perintah ini:
    repadmin /showobjmeta localhost "CN=test user,CN=Users,DC=fabidentity,DC=com"

  4. Metadata, periksa kolom waktu/tanggal untuk setiap atribut untuk petunjuk untuk perubahan. Dalam contoh berikut, atribut userPrincipleName mengambil tanggal terbaru dari atribut lain yang mewakili perubahan ke pengguna objek metadata.
    repadmin show user metadata

Masalah diselesaikan?

Di lingkungan AD FS hutan multi, kepercayaan dua arah hutan diperlukan antara hutan mana AD FS disebarkan dan hutan lain yang menggunakan AD FS penyebaran untuk otentikasi. Untuk memverifikasi apakah kepercayaan antara hutan bekerja seperti yang diharapkan, ikuti langkah-langkah berikut:

  1. Masuk ke kontroler domain di hutan mana AD FS disebarkan.

  2. Konsol manajemen terbuka yang aktif domain dan Trust direktori .

  3. Di konsol manajemen, klik kanan domain yang berisi kepercayaan yang Anda inginkan untuk memverifikasi, dan kemudian klik properti.

  4. Klik tab kepercayaan .

  5. Di bawah domain dipercaya oleh domain ini (keluar Trust) atau domain yang Anda percayai domain ini (masuk Trust), klik kepercayaan akan diverifikasi, dan kemudian klik properti.

  6. Klik validasi.
    Di kotak dialog Layanan Domain direktori aktif , pilih salah satu opsi.

    • Jika Anda memilih tidak, kami sarankan Anda Ulangi prosedur yang sama untuk reciprocal domain.

    • Jika Anda memilih ya, menyediakan kredensial pengguna administratif untuk reciprocal domain. Perlu melakukan prosedur yang sama untuk reciprocal domain.

Active Directory Domain Services

  • Masalah diselesaikan?

Aplikasi Dump Token ini berguna ketika debugging masalah dengan layanan Federasi Anda serta memvalidasi kustom mengklaim aturan. Bukanlah solusi resmi tetapi debugging independen baik solusi yang disarankan untuk tujuan pemecahan masalah.

Sebelum menggunakan aplikasi Dump Token, Anda perlu:

  1. Dapatkan informasi pihak mengandalkan untuk aplikasi yang akan diakses. Jika autentikasi OAuth diterapkan, Dapatkan informasi klien OAuth serta.

  2. Mengatur Dump Token aplikasi.

Dapatkan mengandalkan pihak dan informasi klien OAuth

Jika Anda menggunakan pihak mengandalkan konvensional, ikuti langkah-langkah berikut:

  1. Server AD FS, buka Windows PowerShell dengan opsi Jalankan sebagai administrator .

  2. Tambahkan AD FS 2.0 komponen Windows PowerShell dengan menjalankan perintah berikut ini:
    Add-PSSnapin Microsoft.Adfs.PowerShell

  3. Dapatkan informasi pihak mengandalkan dengan menjalankan perintah berikut ini:
    $rp = Get-AdfsRelyingPartyTrust RPName

  4. Dapatkan informasi klien OAuth dengan menjalankan perintah berikut ini:
    $client = Get-AdfsClient ClientName

Jika Anda menggunakan fitur grup aplikasi di Windows Server 2016, ikuti langkah-langkah berikut:

  1. Server AD FS, buka Windows PowerShell dengan opsi Jalankan sebagai administrator .

  2. Dapatkan informasi pihak mengandalkan dengan menjalankan perintah berikut ini:
    $rp = Get-AdfsWebApiApplication ResourceID

  3. Jika klien OAuth umum, klien mendapatkan informasi dengan menjalankan perintah berikut ini:
    $client = Get-AdfsNativeClientApplication ClientName

    Jika klien OAuth rahasia, klien mendapatkan informasi dengan menjalankan perintah berikut ini:
    $client = Get-AdfsServerApplication ClientName

Mengatur aplikasi Dump Token

Untuk menyiapkan aplikasi Dump Token, jalankan perintah berikut di jendela Windows PowerShell:

$authzRules = "=>issue(Type = `"http://schemas.microsoft.com/authorization/claims/permit`", Value = `"true`");"
$issuanceRules = "x:[]=>issue(claim=x);"
$redirectUrl = "https://dumptoken.azurewebsites.net/default.aspx"
$samlEndpoint = New-AdfsSamlEndpoint -Binding POST -Protocol SAMLAssertionConsumer -Uri $redirectUrl
Add-ADFSRelyingPartyTrust -Name "urn:dumptoken" -Identifier "urn:dumptoken" -IssuanceAuthorizationRules $authzRules -IssuanceTransformRules $issuanceRules -WSFedEndpoint $redirectUrl -SamlEndpoint $samlEndpoint

Sekarang Lanjutkan dengan metode pemecahan masalah berikut ini. Di akhir setiap metode, lihat jika masalah teratasi. Jika tidak, gunakan metode lain.

Dalam metode ini, Anda memulai dengan mendapatkan rincian kebijakan, dan kemudian menggunakan aplikasi Dump Token untuk mendiagnosis kebijakan untuk melihat jika pengguna yang terpengaruh.

Dapatkan rincian kebijakan

$rp. IssuanceAuthorizationRules menunjukkan aturan otorisasi pihak mengandalkan.

Di Windows Server 2016 dan versi yang lebih baru, Anda dapat menggunakan $rp. AccessControlPolicyName untuk mengkonfigurasi kebijakan otentikasi dan otorisasi. Jika $rp. AccessControlPolicyName memiliki nilai, akses kontrol kebijakan di tempat yang mengatur kebijakan otorisasi. Dalam hal ini , $rp. IssuanceAuthorizationRules kosong. Gunakan $rp. ResultantPolicy untuk mengetahui rincian tentang kebijakan kontrol akses.

Jika $rp. ResultantPolicy tidak memiliki rincian tentang kebijakan ini, lihatlah ke aturan klaim sebenarnya. Untuk mendapatkan klaim aturan, ikuti langkah-langkah berikut:

  1. Tetapkan kebijakan kontrol akses ke $null dengan menjalankan perintah berikut ini:
    Set-AdfsRelyingPartyTrust -TargetRelyingParty $rp -AccessControlPolicyName $null

  2. Dapatkan informasi pihak mengandalkan dengan menjalankan perintah berikut ini:
    $rp = Get-AdfsRelyingPartyTrust RPName

  3. Check $rp.IssuanceAuthorizationRulesdan$rp. AdditionalAuthenticationRules.

Menggunakan apl Dump Token untuk mendiagnosis kebijakan otorisasi

  1. Tetapkan kebijakan otentikasi Dump Token sama pihak mengandalkan gagal.

  2. Minta pengguna membuka salah satu tautan berikut ini tergantung pada kebijakan otentikasi yang Anda tetapkan.

    • WS-Fed:https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken

    • SAML P:https://FerderationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken

    • Otentikasi multi faktor Force:https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn

  3. Log halaman Sign-In.

Apa yang Anda dapatkan adalah serangkaian klaim pengguna. Melihat apakah ada apa pun pada kebijakan otorisasi yang secara eksplisit menolak atau memungkinkan pengguna berdasarkan klaim.

Masalah diselesaikan?

  1. Mengkonfigurasi aturan klaim dalam aplikasi Dump Token sama aturan klaim pihak mengandalkan gagal.

  2. Mengkonfigurasi kebijakan otentikasi Dump Token sama pihak mengandalkan gagal.

  3. Minta pengguna membuka salah satu tautan berikut ini tergantung pada kebijakan otentikasi yang Anda tetapkan.

    • WS-Fed:https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken

    • SAML P:https://FerderationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken

    • Otentikasi multi faktor Force:https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn

  4. Log halaman Sign-In.

Ini adalah serangkaian klaim pihak mengandalkan akan mendapatkan untuk pengguna. Jika klaim segala hilang atau tidak terduga, lihatlah kebijakan penerbitan untuk mengetahui alasan.

Apabila semua klaim ada, periksa dengan pemilik aplikasi untuk melihat klaim yang tidak ada atau tidak terduga.

Masalah diselesaikan?

Jika aturan otorisasi memeriksa klaim perangkat, verifikasi jika salah satu dari klaim perangkat tidak ada dalam daftar klaim Anda dapatkan dari aplikasi Dump Token. Klaim hilang dapat memblokir perangkat otentikasi. Untuk mendapatkan klaim dari aplikasi Dump Token, ikuti langkah-langkah di bagian penggunaan aplikasi Dump Token untuk mendiagnosis kebijakan otorisasi dalam metode memeriksa kebijakan otorisasi jika pengguna terpengaruh .

Berikut ini adalah klaim perangkat. Aturan otorisasi dapat menggunakan beberapa dari mereka.

  • http://schemas.microsoft.com/2012/01/devicecontext/claims/registrationid

  • http://schemas.microsoft.com/2012/01/devicecontext/claims/displayname

  • http://schemas.microsoft.com/2012/01/devicecontext/claims/identifier

  • http://schemas.microsoft.com/2012/01/devicecontext/claims/ostype

  • http://schemas.microsoft.com/2012/01/devicecontext/claims/osversion

  • http://schemas.microsoft.com/2012/01/devicecontext/claims/ismanaged

  • http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser

  • http://schemas.microsoft.com/2014/02/devicecontext/claims/isknown

  • http://schemas.microsoft.com/2014/02/deviceusagetime

  • http://schemas.microsoft.com/2014/09/devicecontext/claims/iscompliant

  • http://schemas.microsoft.com/2014/09/devicecontext/claims/trusttype

Jika terdapat klaim hilang, ikuti langkah-langkah di mengkonfigurasi lokal bersyarat akses menggunakan terdaftar perangkat untuk memastikan lingkungan penataan untuk otentikasi perangkat.

Apabila ada semua klaim, lihat jika nilai klaim dari aplikasi Dump Token cocok dengan nilai yang diperlukan dalam kebijakan otorisasi.

Masalah diselesaikan?

Gunakan metode berikut untuk pemecahan masalah. Di akhir setiap metode, lihat jika masalah teratasi. Jika tidak, gunakan metode lain.

Jika pengguna mencoba untuk masuk ke Azure AD, mereka akan diarahkan ke AD FS untuk otentikasi domain gabungan. Salah satu kemungkinan alasan login gagal adalah bahwa pengguna tidak belum disinkronkan ke Azure AD. Anda mungkin melihat loop dari Azure AD untuk AD FS setelah otentikasi pertama usaha AD FS. Untuk menentukan apakah pengguna telah disinkronkan ke Azure AD, ikuti langkah-langkah berikut:

  1. Download dan menginstal modul Azure AD PowerShell untuk Windows PowerShell.

  2. Buka Windows PowerShell dengan opsi "Jalankan sebagai administrator".

  3. Memulai koneksi ke Azure AD dengan menjalankan perintah berikut ini:
    Connect-MsolService

  4. Memberikan kredensial global administrator untuk sambungan.

  5. Dapatkan daftar pengguna di Azure AD dengan menjalankan perintah berikut ini:
    Get-MsolUser

  6. Verifikasi Apakah pengguna dalam daftar.

Jika pengguna bukan dalam daftar, menyinkronkan pengguna ke Azure AD.

Masalah diselesaikan?

Azure AD memerlukan immutableID dan UPN pengguna mengotentikasi pengguna.

Catatan immutableID juga disebut sourceAnchor dalam alat berikut:

  • Azure AD Sync

  • Sync azure Active Directory (DirSync)

Administrator dapat menggunakan Azure AD menyambung otomatis manajemen AD FS kepercayaan dengan Azure AD. Jika Anda tidak mengelola kepercayaan melalui Azure AD menyambung, kami sarankan Anda melakukan sehingga dengan men-download Azure AD menyambung. Otomatis memungkinkan azure AD menyambung klaim aturan manajemen didasarkan pada pengaturan sinkronisasi.

Untuk memeriksa apakah klaim aturan immutableID dan UPN AD FS pertandingan apa Azure AD menggunakan, ikuti langkah-langkah berikut:

  1. Dapatkan sourceAnchor dan UPN di Azure AD menyambung.

    1. Buka Azure AD menyambung.

    2. Klik tampilan konfigurasi saat ini.
      Azure AD Connect -View current configuration

    3. Pada halaman Periksa solusi Anda , Catat nilai JANGKAR sumber dan Nama pengguna utama.
      Azure AD Connect -Review your solution

  2. Verify nilai-nilai immutableID (sourceAnchor) dan UPN di terkait klaim aturan dikonfigurasi di server AD FS.

    1. Konsol manajemen server AD FS, buka AD FS .

    2. Klik mengandalkan pihak kepercayaan.

    3. Klik kanan kepercayaan pihak mengandalkan dengan Azure AD, dan kemudian klik Edit klaim penerbitan kebijakan .

    4. Buka aturan klaim untuk tetap ID dan UPN.

    5. Verifikasi jika variabel dipertanyakan nilai immutableID dan UPN yang sama seperti yang muncul di Azure AD menyambung.
      Issue UPN and ImmutableID

    6. Jika ada perbedaan, gunakan salah satu metode di bawah ini:

      • Jika AD FS dikelola oleh Azure AD menyambung, reset kepercayaan pihak mengandalkan menggunakan Azure AD menyambung.

      • Jika AD FS tidak dikelola oleh Azure AD menyambung, benar klaim dengan atribut yang tepat.
         

Masalah diselesaikan?

Informasi yang akan digunakan dalam langkah-langkah pemecahan masalah berikutnya.

 

Jika Anda menggunakan pihak mengandalkan konvensional, ikuti langkah-langkah berikut:

  1. Server AD FS utama, buka Windows PowerShell dengan opsi Jalankan sebagai administrator .

  2. Tambahkan AD FS 2.0 komponen Windows PowerShell dengan menjalankan perintah berikut ini:
    Add-PSSnapin Microsoft.Adfs.PowerShell

  3. Dapatkan informasi pihak mengandalkan dengan menjalankan perintah berikut ini:
    $rp = Get-AdfsRelyingPartyTrust RPName

  4. Dapatkan informasi klien OAuth dengan menjalankan perintah berikut ini:
    $client = Get-AdfsClient ClientName

Jika Anda menggunakan fitur grup aplikasi di Windows Server 2016, ikuti langkah-langkah berikut:

  1. Server AD FS utama, buka Windows PowerShell dengan opsi Jalankan sebagai administrator .

  2. Dapatkan informasi pihak mengandalkan dengan menjalankan perintah berikut ini:
    $rp = Get-AdfsWebApiApplication ResourceID

  3. Jika klien OAuth umum, Dapatkan informasi klien dengan menjalankan perintah berikut ini:
    $client = Get-AdfsNativeClientApplication ClientName

    Jika klien rahasia, Dapatkan informasi klien dengan menjalankan perintah berikut ini:
    $client = Get-AdfsServerApplication ClientName

Sekarang lanjutkan dengan metode pemecahan masalah berikut ini.

Mengandalkan pengidentifikasi pihak, ID klien dan pengalihan URI harus disediakan oleh pemilik aplikasi dan klien. Namun, mungkin masih ada ketidaksesuaian pemilik yang menyediakan dan apa yang dikonfigurasi di AD FS. Sebagai contoh, ketidakcocokan dapat disebabkan oleh kesalahan ketik. Periksa jika pengaturan yang disediakan oleh pemilik cocok yang dikonfigurasi di AD FS. Langkah-langkah di Halaman sebelumnya Anda mendapatkan pengaturan yang dikonfigurasi di AD FS melalui PowerShell.

Pengaturan yang disediakan oleh pemilik

Pengaturan yang dikonfigurasi di AD FS

Mengandalkan pihak ID

$rp.Identifier

Mengandalkan pihak pengalihan URI

Awalan atau wildcard pertandingan

  • $rp. WSFedEndpoint pihak mengandalkan WS-Fed

  • $rp. SamlEndpoints pihak mengandalkan SAML

ID klien

$client.ClientId

Klien pengalihan URI

Pertandingan awalan $client. RedirectUri

Jika item di dalam tabel cocok, Selain itu Periksa jika pengaturan ini sesuai antara apa yang mereka muncul dalam permintaan otentikasi yang dikirim ke AD FS dan apa yang dikonfigurasi di AD FS. Cobalah mereproduksi masalah di mana Anda merekam jejak Fiddler pada permintaan otentikasi yang dikirim oleh aplikasi AD FS. Periksa parameter permintaan untuk melakukan pemeriksaan berikut ini tergantung pada jenis permintaan.

Permintaan OAuth

Permintaan OAuth terlihat seperti berikut ini:

https://sts.contoso.com/adfs/oauth2/authorize?response_type=code&client_id=ClientID&redirect_uri=https://www.TestApp.com&resource=https://www.TestApp.com

Periksa apakah parameter permintaan cocok dengan pengaturan yang dikonfigurasi di AD FS.

Parameter permintaan

Pengaturan yang dikonfigurasi di AD FS

client_id

$client.ClientId

redirect_uri

Pertandingan awalan @client_RedirectUri

Parameter "sumber daya" harus mewakili pihak mengandalkan valid di AD FS. Dapatkan informasi pihak mengandalkan dengan menjalankan salah satu dari perintah berikut ini.

  • Jika Anda menggunakan pihak mengandalkan konvensional, jalankan perintah berikut ini:
    Get-AdfsRelyingPartyTrust -Identifier "ValueOfTheResourceParameter"

  • Jika Anda menggunakan fitur grup aplikasi di Windows Server 2016, jalankan perintah berikut ini:
    Get-AdfsWebApiApplication "ValueOfTheResourceParameter"

WS-Fed permintaan

Permintaan WS-Fed terlihat seperti berikut ini:

https://fs.contoso.com/adfs/ls/?wa=wsignin1.0&wtrealm=https://claimsweb.contoso.com&wctx=rm=0&id=passive&ru=/&wct=2014-10-21T22:15:42Z

Periksa apakah parameter permintaan cocok dengan pengaturan yang dikonfigurasi di AD FS:

Parameter permintaan

Pengaturan yang dikonfigurasi di AD FS

wtrealm

$rp.Identifier

wreply

Awalan cocok atau wildcard cocok $rp. WSFedEndpoint

Permintaan SAML

Permintaan SAML terlihat seperti berikut ini:

https://sts.contoso.com/adfs/ls/?SAMLRequest=EncodedValue&RelayState=cookie:29002348&SigAlg=http://www.w3.org/2000/09/Fxmldsig#rsa-sha1&Signature=Signature

Dekode nilai SAMLRequest parameter dengan menggunakan opsi "Dari DeflatedSAML" di Wisaya teks Fiddler. Nilai decoded terlihat seperti berikut ini:

<samlp:AuthnRequest ID="ID" Version="2.0" IssueInstant="2017-04-28T01:02:22.664Z" Destination="https://TestClaimProvider-Samlp-Only/adfs/ls" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" ForceAuthn="true" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://fs.contoso.com/adfs/services/trust</Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true" /></samlp:AuthnRequest>

Lakukan pemeriksaan berikut dalam nilai decoded:

  • Memeriksa jika host nama nilai tujuan cocok dengan nama host AD FS.

  • Memeriksa jika nilai penerbit cocok dengan$rp.Identifier.

Catatan tambahan untuk SAML

  • $rp. SamlEndpoints: Menampilkan semua jenis SAML akhir. Respons dari AD FS dikirim ke URL terkait yang dikonfigurasi di akhir. Titik akhir SAML dapat menggunakan pengalihan, posting atau artifak pengikatan untuk transmisi pesan. URL ini dapat dikonfigurasi di AD FS.

  • $rp. SignedSamlRequestsRequired: Jika nilainya diatur, permintaan SAML dikirimkan dari mengandalkan pihak harus ditandatangani. Parameter "SigAlg" dan "Tanda tangan" harus ada dalam permintaan.

  • $rp. RequestSigningCertificate: Ini adalah penandatanganan sertifikat yang digunakan untuk membuat tanda tangan pada permintaan SAML. Pastikan bahwa sertifikat yang sah dan meminta pemilik aplikasi untuk mencocokkan sertifikat.

Masalah diselesaikan?

Jika$rp.EncryptClaimsmengembalikan "Diaktifkan", mengandalkan pihak enkripsi diaktifkan. AD FS menggunakan enkripsi sertifikat untuk mengenkripsi klaim. Lakukan pemeriksaan berikut ini:

  • $rp. EncryptionCertificate: Gunakan perintah ini untuk mendapatkan sertifikat dan periksa apakah berlaku.

  • $rp. EncryptionCertificateRevocationCheck: Gunakan perintah ini untuk memeriksa jika sertifikat yang memenuhi pembatalan periksa persyaratan.

Masalah diselesaikan?

Jika ada sertifikat mismatches, pastikan bahwa mitra menggunakan sertifikat baru. Sertifikat yang disertakan dalam metadata Federasi yang diterbitkan oleh server AD FS.

Catatan Mitra merujuk ke semua sumber daya organisasi atau akun organisasi mitra Anda, diwakili di AD FS mengandalkan kepercayaan pihak dan Trust penyedia klaim.

Mitra dapat mengakses metadata Federasi

Jika mitra dapat mengakses metadata Federasi, meminta mitra untuk menggunakan sertifikat baru.

Mitra tidak dapat mengakses metadata Federasi

Dalam hal ini, Anda harus secara manual mengirim mitra kunci publik sertifikat baru. Untuk melakukannya, ikuti langkah-langkah berikut:

  1. Mengekspor kunci publik sebagai file .cert, atau .p7b file untuk menyertakan rantai sertifikat keseluruhan.

  2. Kirim kunci publik untuk mitra.

  3. Meminta mitra untuk menggunakan sertifikat baru.

Masalah diselesaikan?

  1. Buka konsol manajemen AD FS.

  2. Klik kanan kepercayaan pihak mengandalkan, dan kemudian klik properti.

  3. Pada Advanced tab, pilih algoritma sesuai aplikasi yang diperlukan.
    Relying party trust-Hash algorithm

Masalah diselesaikan ?

  1. Di server AD FS, dump penerbitan transformasi aturan dengan menjalankan perintah berikut ini:
    (Get-AdfsRelyingPartyTrust -Name RPName).IssuanceTransformRules

  2. Temukan aturan yang masalah klaim NameIdentifier. Jika aturan tersebut tidak ada, lewati langkah ini.
    Berikut adalah contoh dari aturan:

    c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

    Pemberitahuan format NameIdentifier sintaks berikut ini:
    Properties["Property-type-URI"] = "ValueURI"

    Format mungkin tercantum di bawah ini. Format pertama adalah default.

    • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecifie.

    • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

    • urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

    • urn:oasis:names:tc:SAML:2.0:nameid-format:transient

  3. Meminta pemilik aplikasi format NameIdentifier yang diperlukan oleh aplikasi.

  4. Verifikasi jika dua NameIdentifier format cocok.

  5. Jika format tidak cocok, konfigurasikan klaim NameIdentifier menggunakan format yang memerlukan aplikasi. Untuk melakukannya, ikuti langkah-langkah berikut:

    1. Buka konsol manajemen AD FS.

    2. Klik Mengandalkan pihak kepercayaan, pilih mitra Federasi sesuai, dan kemudian klik Edit klaim penerbitan kebijakan di panel tindakan .

    3. Menambahkan aturan baru jika tidak ada aturan untuk masalah klaim NameIdentifier, atau memperbarui aturan yang ada. Pilih Nama IDmasuk klaim jenis, dan kemudian Tentukan format yang memerlukan aplikasi.
      Configure claim rule

Masalah diselesaikan?

Catatan: Anda juga dapat menggunakan Fiddler untuk memecahkan masalah. Ide yang sama.

Aplikasi Dump Token ini berguna ketika debugging masalah dengan layanan Federasi Anda serta memvalidasi kustom mengklaim aturan. Bukanlah solusi resmi tetapi debugging independen baik solusi yang disarankan untuk tujuan pemecahan masalah. Untuk menggunakan aplikasi Dump Token, ikuti langkah-langkah berikut:

  1. Mengatur aplikasi Dump Token dengan menjalankan perintah berikut ini:
    $authzRules = "=>issue(Type = `"http://schemas.microsoft.com/authorization/claims/permit`", Value = `"true`");"https://dumptoken.azurewebsites.net/default.aspx"
    $samlEndpoint = New-AdfsSamlEndpoint -Binding POST -Protocol SAMLAssertionConsumer -Uri $redirectUrl
    Add-ADFSRelyingPartyTrust -Name "urn:dumptoken" -Identifier "urn:dumptoken" -IssuanceAuthorizationRules $authzRules -IssuanceTransformRules $issuanceRules -WSFedEndpoint $redirectUrl -SamlEndpoint $samlEndpoint

  2. Replikasi gagal mengandalkan pihak konfigurasi salinan aturan penerbitan dari pihak mengandalkan untuk DumpToken. Untuk melakukannya, jalankan perintah berikut ini:
    Set-ADFSRelyingPartyTrust -TargetName "urn:dumptoken" -IssuanceTransformRules (Get-ADFSRelyingPartyTrust -Name <”your_SrcRP_Name”>).IssuanceTransformRules

  3. Minta pengguna membuka salah satu tautan berikut ini tergantung pada kebijakan otentikasi yang Anda tetapkan.

    • WS-Fed:https://<Ferderation Instance>/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken

    • SAML:https://<Ferderation Instance>/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken

    • Otentikasi multi faktor Force:https://<Ferderation Instance>/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn

  4. Dapatkan klaim setelah pengguna login di halaman otentikasi.

  5. Output di Dump Token, luaskan bagian XML mentah Token, dan kemudian baca pernyataan atribut dengan memeriksa string berikut ini untuk melihat apakah mereka cocok dengan yang dikonfigurasi di kebijakan penerbitan klaim :

    • SAML:NameIdentifier: ini menunjukkan NameIdentifier format.

    • SAML:AttributeStatement: ini menunjukkan setiap klaim Ketik nilai pasangan Token.

    • SAML:AuthenticationStatement: ini menunjukkan metode otentikasi dan otentikasi instan.

Masalah diselesaikan?

Gunakan Halaman IdpInititatedSignOn untuk memverifikasi jika Layanan AD FS dan menjalankan dan fungsionalitas otentikasi bekerja dengan benar. Untuk membuka halaman IdpInitiatedSignOn, ikuti langkah-langkah berikut:

  1. Mengaktifkan halaman IdpInitiatedSignOn dengan menjalankan perintah berikut ini di server AD FS:
    Set-AdfsProperties -EnableIdPInitiatedSignonPage $true

  2. Dari komputer yang ada di dalam jaringan Anda, kunjungi halaman berikut ini:
    https://FederationInstance/adfs/ls/idpinitiatedsignon.aspx

  3. Masukkan benar kredensial pengguna sah pada halaman masuk.

Apakah masuk berhasil?

Untuk memecahkan masalah, periksa komponen berikut dan layanan.

Mengakses AD FS harus menunjuk langsung ke salah satu dari server AD FS atau penyeimbang beban depan server AD FS. Lakukan pemeriksaan berikut ini:

  • Ping nama Layanan Federasi (misalnya fs.contoso.com). Konfirmasi jika alamat IP yang Anda Dapatkan menyelesaikan salah satu server AD FS atau penyeimbang beban server AD FS.

  • Memeriksa apakah ada A record untuk layanan Federasi di DNS server. A record harus menunjuk ke salah satu server AD FS atau penyeimbang beban server AD FS.

Masalah diselesaikan?

  • Memeriksa jika firewall memblokir lalu lintas antara:

    • Server AD FS dan penyeimbang beban.

    • WAP (proksi aplikasi Web) server dan beban pengimbang jika WAP digunakan.

  • Jika penyelidikan diaktifkan pada penyeimbang beban, periksa berikut ini:

    • Jika Anda menjalankan Windows Server 2012 R2, untuk memastikan bahwa Agustus 2014 Batal pemutakhiran diinstal.

    • Periksa apakah port 80 diaktifkan di firewall pada WAP server dan server AD FS.

    • Pastikan bahwa penyelidikan diatur untuk port 80 dan titik akhir/adfs/penyelidikan.

Masalah diselesaikan?

  1. Server AD FS, buka manajer Server.

  2. Di Server Manager, klik alat > Layanan.

  3. Periksa apakah StatusActive Directory Federation Servicesberjalan.

Masalah diselesaikan?

AD FS menyediakan berbagai akhir untuk fungsi yang berbeda dan skenario. Tidak semua akhir diaktifkan secara default. Untuk memeriksa status akhir, mengikuti langkah-langkah berikut:

  1. Server AD FS, Buka konsol manajemen AD FS.

  2. Memperluas Layanan > akhir.

  3. Temukan akhir dan verifikasi jika status diaktifkan di kolom diaktifkan .
    ADFS Endpoints status

Masalah diselesaikan?

Kami sarankan Anda menggunakan Azure AD menyambung yang mempermudah manajemen sertifikat SSL.

Azure AD menyambung diinstal di lingkungan Anda?

Jika Azure AD menyambung diinstal, pastikan bahwa Anda gunakan untuk mengelola dan memperbarui sertifikat SSL.

Masalah diselesaikan?

Sertifikat SSL harus memenuhi persyaratan berikut ini:

  • Sertifikat ini dari otoritas sertifikasi akar terpercaya.
    AD FS memerlukan sertifikat SSL adalah dari otoritas sertifikasi akar terpercaya. Jika AD FS diakses dari non-domain bergabung dengan komputer, kami sarankan agar Anda menggunakan sertifikat SSL dari otoritas sertifikasi akar terpercaya pihak ketiga seperti DigiCert, VeriSign, dll. Jika sertifikat SSL bukan dari otoritas sertifikasi akar terpercaya, SSL komunikasi dapat merusak.

  • Nama subjek sertifikat sah.
    Nama subjek harus cocok dengan nama Layanan Federasi, bukan nama server AD FS atau nama lain. Untuk mendapatkan nama Layanan Federasi, jalankan perintah berikut ini di server AD FS utama:
    Get-AdfsProperties | select hostname

  • Sertifikat tidak ditarik.
    Periksa pembatalan sertifikat. Jika sertifikat dicabut, sambungan SSL tidak dapat dipercaya dan akan diblokir oleh klien.

Sertifikat SSL tidak memenuhi persyaratan ini?

Untuk memecahkan masalah Anda, Dapatkan syarat sertifikat SSL komunikasi.

Masalah diselesaikan setelah Anda menggunakan sertifikat SSL syarat?

Periksa konfigurasi berikut sertifikat SSL.

Sertifikat SSL harus diinstal ke toko pribadi untuk komputer lokal di setiap Federasi server di daerah Anda. Untuk menginstal sertifikat, klik dua kali. PFX berkas sertifikat dan ikuti Wisaya.

Untuk memverifikasi jika sertifikat yang diinstal ke tempat yang benar, ikuti langkah-langkah berikut:

  1. Daftar sertifikat yang ada di penyimpanan pribadi untuk komputer lokal dengan menjalankan perintah berikut ini:
    dir Cert:\LocalMachine\My

  2. Periksa apakah sertifikat dalam daftar.

Masalah diselesaikan?

Dapatkan cap jempol sertifikat yang digunakan untuk komunikasi SSL dan verifikasi jika cap jempol cocok dengan cap jempol sertifikat yang diharapkan.

Untuk mendapatkan cap jempol sertifikat yang digunakan, jalankan perintah berikut di Windows PowerShell:

Get-AdfsSslCertificate

Jika sertifikat salah digunakan, tetapkan sertifikat yang benar dengan menjalankan perintah berikut ini:

Set-AdfsSslCertificate –Thumbprint CorrectThumprint

Masalah diselesaikan?

Sertifikat SSL harus disetel sebagai layanan komunikasi sertifikat di daerah AD FS Anda. Ini tidak terjadi secara otomatis. Untuk memeriksa apakah sertifikat benar diatur, ikuti langkah-langkah berikut:

  1. Di AD FS Management Console, luaskan Layanan > sertifikat.

  2. Verifikasi sertifikat yang tercantum di bawah layanan komunikasi apakah sertifikat yang diharapkan.

Jika sertifikat salah terdaftar, ditetapkan sertifikat yang benar, dan kemudian memberi AD FS Layanan izin Baca ke sertifikat. Untuk melakukannya, ikuti langkah-langkah berikut:

  1. Mengatur sertifikat yang benar:

    1. Klik kanan sertifikat, dan kemudian klik Set layanan komunikasi sertifikat.

    2. Pilih sertifikat yang benar.

  2. Verifikasi apakah layanan AD FS memiliki izin Baca ke sertifikat:

    1. Menambahkan sertifikat snap-in untuk akun lokal komputer untuk konsol manajemen Microsoft (MMC).

    2. Memperluas sertifikat (komputer lokal) > pribadi > sertifikat.

    3. Klik kanan sertifikat SSL, klik Semua tugas > Mengatur kunci privat.

    4. Verifikasi jika adfssrv tercantum di bawah nama grup dan pengguna dengan izin Baca .

  3. Jika adfssrv tidak terdaftar, memberi izin Baca ke sertifikat Layanan AD FS:

    1. Klik Tambah, klik Lokasi, klik server, dan kemudian klik OK.

    2. Di bawah Masukkan nama objek untuk memilih, masukkan nt service\adfssrv, klik Periksa nama, dan kemudian klik OK.
      Jika Anda menggunakan AD FS dengan alat registrasi Layanan (DRS), masukkan nt service\drs .

    3. Memberikan izin Baca , dan kemudian klik OK.

Masalah diselesaikan?

DRS dikonfigurasi di AD FS?

Jika Anda telah mengonfigurasi AD FS dengan DRS, pastikan bahwa sertifikat SSL ini juga dikonfigurasi dengan benar untuk RDS. Sebagai contoh, jika ada dua UPN sufiks contoso.com dan fabrikam.com, sertifikat harus enterpriseregistration.contoso.com dan enterpriseregistration.fabrikma.com sebagai nama alternatif subjek (SANs).

Untuk memeriksa apakah sertifikat SSL memiliki SANs benar, ikuti langkah-langkah berikut:

  1. Daftar semua akhiran UPN yang digunakan dalam organisasi dengan menjalankan perintah berikut ini:
    Get-AdfsDeviceRegistratrionUpnSuffix

  2. Verifikasi apakah sertifikat SSL memiliki wajib SANs dikonfigurasi.

Sertifikat SSL memiliki nama DRS benar sebagai SANs?

Untuk memecahkan masalah ini, Dapatkan sertifikat SSL baru yang memiliki SANs benar untuk DRS, dan kemudian menggunakan sebagai sertifikat SSL untuk AD FS.

Masalah diselesaikan?

Periksa apakah sertifikat SSL benar diatur pada semua server WAP

  1. Pastikan bahwa sertifikat SSL telah diinstal di penyimpanan pribadi untuk komputer lokal di server WAP masing-masing.

  2. Dapatkan sertifikat SSL yang digunakan oleh WAP dengan menjalankan perintah berikut ini:
    Get-WebApplicationProxySslCertificate

  3. Jika sertifikat SSL salah, tetapkan sertifikat SSL benar dengan menjalankan perintah berikut ini:
    Set-WebApplicationProxySslCertificate -Thumbprint Thumbprint

Periksa pengikatan sertifikat dan memperbaruinya jika diperlukan

Untuk mendukung non-SNI kasus, administrator dapat menetapkan pengikatan mundur. Selain federationservicename:443 standar mengikat, Cari mundur pengikatan pada id aplikasi berikut ini:

  • {5d89a20c-beab-4389-9447-324788eb944a}
    Ini adalah ID aplikasi untuk AD FS.

  • {f955c070-e044-456c-ac00-e9e4275b3f04}
    Ini adalah ID aplikasi untuk aplikasi Web Proxy.

Sebagai contoh, jika sertifikat SSL yang ditetapkan untuk mengikat mundur seperti 0.0.0.0:443, pastikan bahwa pengikatan diperbarui sesuai saat sertifikat SSL akan diperbarui.

Masalah diselesaikan?

  1. Server AD FS, buka manajer Server.

  2. Di Server Manager, klik alat > Layanan.

  3. Periksa apakah StatusActive Directory Federation Servicesberjalan.

Masalah diselesaikan?

Gunakan Halaman IdpInititatedSignOn cepat memverifikasi jika Layanan AD FS cadangan dan dijalankan dan fungsionalitas otentikasi bekerja dengan benar. Untuk membuka halaman IdpInitiatedSignOn, ikuti langkah-langkah berikut:

  1. Mengaktifkan halaman IdpInitiatedSignOn dengan menjalankan perintah berikut ini di server AD FS:
    Set-AdfsProperties -EnableIdPInitiatedSignonPage $true

  2. Dari komputer yang berada di luar jaringan Anda, kunjungi halaman berikut ini:
    https://FederationInstance/adfs/ls/idpinitiatedsignon.aspx

  3. Masukkan benar kredensial pengguna sah pada halaman masuk.

Apakah masuk berhasil?

Untuk memecahkan masalah, periksa komponen berikut dan layanan.

Mengakses AD FS harus menunjuk langsung ke salah satu server WAP (proksi aplikasi Web) atau penyeimbang beban depan WAP server. Lakukan pemeriksaan berikut ini:

  • Ping nama Layanan Federasi (misalnya fs.contoso.com). Konfirmasi Apakah alamat IP Ping ditetapkan ke satu server WAP atau penyeimbang beban server WAP.

  • Memeriksa apakah ada A record untuk layanan Federasi di DNS server. A record harus menunjuk ke salah satu server WAP atau penyeimbang beban server WAP.

Jika WAP tidak diterapkan dalam skenario untuk akses eksternal, periksa jikaccessing AD FS titik langsung ke salah satu server AD FS atau penyeimbang beban depan server AD FS:

  • Ping nama Layanan Federasi (misalnya fs.contoso.com). Konfirmasi jika alamat IP yang Anda Dapatkan menyelesaikan salah satu server AD FS atau penyeimbang beban server AD FS.

  • Periksa apakah ada A record untuk layanan Federasi di DNS server. A record harus menunjuk ke salah satu server AD FS atau penyeimbang beban server AD FS.

Masalah diselesaikan?

  • Memeriksa jika firewall memblokir lalu lintas antara:

    • Server AD FS dan penyeimbang beban.

    • WAP (proksi aplikasi Web) server dan beban pengimbang jika WAP digunakan.

  • Jika penyelidikan diaktifkan pada penyeimbang beban, periksa berikut ini:

    • Jika Anda menjalankan Windows Server 2012 R2, untuk memastikan bahwa Agustus 2014 Batal pemutakhiran diinstal.

    • Periksa apakah port 80 diaktifkan di firewall pada WAP server dan server AD FS.

    • Memastikan penyelidikan yang ditetapkan untuk port 80 dan /adfs/probe akhir.

Masalah diselesaikan?

  1. Periksa apakah lalu lintas masuk melalui TCP port 443 diaktifkan pada:

    • tia firewall antara server proksi aplikasi Web dan Kampung server Federasi.

    • firewall antara klien dan server proksi aplikasi Web.

  2. Periksa apakah lalu lintas masuk melalui TCP port 49443 diaktifkan firewall antara klien dan server proksi aplikasi Web jika kondisi berikut benar:

    • Otentikasi klien TLS menggunakan sertifikat X.509 diaktifkan.

    • Anda menggunakan AD FS di Windows Server 2012 R2.

      Catatan Konfigurasi yang tidak diperlukan firewall antara server proksi aplikasi Web dan server Federasi.

Masalah diselesaikan?

 

Masalah diselesaikan?

AD FS menyediakan berbagai akhir untuk fungsi yang berbeda dan skenario. Tidak semua akhir diaktifkan secara default. Untuk memeriksa apakah akhir diaktifkan pada proxy, mengikuti langkah-langkah berikut:

  1. Server AD FS, Buka konsol manajemen AD FS.

  2. Memperluas Layanan > akhir.

  3. Temukan endpoint dan verifikasi Apakah status diaktifkan pada kolom Proksi diaktifkan .
    ADFS endpoints proxy status

 

Masalah diselesaikan?

Catatan Informasi pada Halaman ini berlaku untuk AD FS 2012 R2 dan yang lebih baru.

Jika proksi aplikasi Web (WAP) disebarkan, hubungan kepercayaan proxy harus dibuat antara WAP server dan server AD FS. Periksa jika hubungan kepercayaan proxy dibuat atau mulai gagal pada beberapa titik waktu.

Informasi latar belakang

Hubungan kepercayaan proksi yang berbasis sertifikat klien. Ketika Anda menjalankan Wisaya pasca penginstalan proksi aplikasi Web, Wisaya menghasilkan sertifikat klien yang ditandatangani sendiri menggunakan kredensial yang Anda tentukan di Wisaya. Wisaya memasukkan sertifikat ke pangkalan data konfigurasi AD FS kemudian menambahkannya ke penyimpanan sertifikat AdfsTrustedDevices di server AD FS.

Untuk setiap SSL komunikasi, http.sys menggunakan urutan prioritas untuk pengikatan sertifikat SSL sertifikat yang sesuai:

Prioritas

Nama

Parameter

Deskripsi

1

IP

IP:port

Tepat IP dan Port cocok

2

SNI

Hostname:port

Nama host tepat sesuai (sambungan harus menetapkan SNI)

3

CCS

Port

Memanggil penyimpanan sertifikat tengah

4

IPv6 wildcard

Port

IPv6 wildcard cocok (sambungan harus IPv6)

5

IP wildcard

Port

IP wildcard cocok (sambungan dapat IPv4 atau IPv6)

AD FS 2012 R2 dan kemudian tergantung pada layanan informasi Internet (IIS) dan dijalankan sebagai layanan ke http.sys. Sertifikat SSL hostname:port pengikatan digunakan dengan AD FS. Selama sertifikat otentikasi klien, AD FS mengirimkan daftar kepercayaan sertifikat (CTL) berdasarkan sertifikat di penyimpanan AdfsTrustedDevices. Jika menggunakan ikatan sertifikat SSL untuk server AD FS IP:port atau penyimpanan CTL bukan AdfsTrustedDevices, hubungan kepercayaan proxy mungkin tidak dapat dibuat.

Dapatkan pengikatan sertifikat SSL untuk AD FS

Di server AD FS, jalankan perintah berikut di Windows PowerShell:
netsh http show sslcert

Dalam daftar binding kembali, Cari dengan ID aplikasi 5d89a20c-beab-4389-9447-324788eb944a. Berikut adalah contoh dari pengikatan sehat. Perhatikan bagian tebal.

Hostname:port : adfs.contoso.com:443
Certificate Hash : 3638de9b03a488341dfe32fc3ae5c480ee687793
Application ID : {5d89a20c-beab-4389-9447-324788eb944a}
Certificate Store Name : MY
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : AdfsTrustedDevices
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled

Pemecahan masalah

Untuk secara otomatis mendeteksi masalah dengan hubungan kepercayaan proxy, jalankan skrip berikut ini. Berdasarkan masalah yang terdeteksi, mengambil tindakan yang sesuai di akhir halaman.

param

(

  [switch]$syncproxytrustcerts

)

function checkhttpsyscertbindings()

{

Write-Host; Write-Host("1 – Checking http.sys certificate bindings for potential issues")

$httpsslcertoutput = netsh http show sslcert

$adfsservicefqdn = (Get-AdfsProperties).HostName

$i = 1

$certbindingissuedetected = $false

While($i -lt $httpsslcertoutput.count)

{

        $ipport = $false

        $hostnameport = $false

        if ( ( $httpsslcertoutput[$i] -match "IP:port" ) ) { $ipport = $true }

        elseif ( ( $httpsslcertoutput[$i] -match "Hostname:port" ) ) { $hostnameport = $true }

        # Check for IP specific certificate bindings

        if ( ( $ipport -eq $true ) )

        {

            $httpsslcertoutput[$i]

            $ipbindingparsed = $httpsslcertoutput[$i].split(":")

            if ( ( $ipbindingparsed[2].trim() -ne "0.0.0.0" ) -and ( $ipbindingparsed[3].trim() -eq "443") )

            {

                $warning = "There is an IP specific binding on IP " + $ipbindingparsed[2].trim() + " which may conflict with the AD FS port 443 cert binding." | Write-Warning

                $certbindingissuedetected = $true

            }

            $i = $i + 14

            continue

        }

        # check that CTL Store is set for ADFS service binding

        elseif ( $hostnameport -eq $true )

        {

            $httpsslcertoutput[$i]

            $ipbindingparsed = $httpsslcertoutput[$i].split(":")

            If ( ( $ipbindingparsed[2].trim() -eq $adfsservicefqdn ) -and ( $ipbindingparsed[3].trim() -eq "443") -and ( $httpsslcertoutput[$i+10].split(":")[1].trim() -ne "AdfsTrustedDevices" ) )

            {

                Write-Warning "ADFS Service binding does not have CTL Store Name set to AdfsTrustedDevices"

                $certbindingissuedetected = $true

            }

        $i = $i + 14

        continue

        }

    $i++

}

If ( $certbindingissuedetected -eq $false ) { Write-Host "Check Passed: No certificate binding issues detected" }

}

function checkadfstrusteddevicesstore()

{

# check for CA issued (non-self signed) certs in the AdfsTrustedDevices cert store

Write-Host; Write-Host "2 – Checking AdfsTrustedDevices cert store for non-self signed certificates"

$certlist = Get-Childitem cert:\LocalMachine\AdfsTrustedDevices -recurse | Where-Object {$_.Issuer -ne $_.Subject}

If ( $certlist.count -gt 0 )

{

    Write-Warning "The following non-self signed certificates are present in the AdfsTrustedDevices store and should be removed"

    $certlist | Format-List Subject

}

Else { Write-Host "Check Passed: No non-self signed certs present in AdfsTrustedDevices cert store" }

}

function checkproxytrustcerts

{

    Param ([bool]$repair=$false)

    Write-Host; Write-Host("3 – Checking AdfsTrustedDevices cert store is in sync with ADFS Proxy Trust config")

    $doc = new-object Xml

    $doc.Load("$env:windir\ADFS\Microsoft.IdentityServer.Servicehost.exe.config")

    $connString = $doc.configuration.'microsoft.identityServer.service'.policystore.connectionString

    $command = "Select ServiceSettingsData from [IdentityServerPolicy].[ServiceSettings]"

    $cli = new-object System.Data.SqlClient.SqlConnection

    $cli.ConnectionString = $connString

    $cmd = new-object System.Data.SqlClient.SqlCommand

    $cmd.CommandText = $command

    $cmd.Connection = $cli

    $cli.Open()

    $configString = $cmd.ExecuteScalar()

    $configXml = new-object XML

    $configXml.LoadXml($configString)

    $rawCerts = $configXml.ServiceSettingsData.SecurityTokenService.ProxyTrustConfiguration._subjectNameIndex.KeyValueOfstringArrayOfX509Certificate29zVOn6VQ.Value.X509Certificate2

    #$ctl = dir cert:\LocalMachine\ADFSTrustedDevices

    $store = new-object System.Security.Cryptography.X509Certificates.X509Store("ADFSTrustedDevices","LocalMachine")

    $store.open("MaxAllowed")

    $atLeastOneMismatch = $false

    $badCerts = @()

    foreach($rawCert in $rawCerts)

    {   

        $rawCertBytes = [System.Convert]::FromBase64String($rawCert.RawData.'#text')

        $cert=New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(,$rawCertBytes)

        $now = Get-Date

        if ( ($cert.NotBefore -lt $now) -and ($cert.NotAfter -gt $now))

        {

            $certThumbprint = $cert.Thumbprint

         $certSubject = $cert.Subject

         $ctlMatch = dir cert:\localmachine\ADFSTrustedDevices\$certThumbprint -ErrorAction SilentlyContinue

         if ($ctlMatch -eq $null)

         {

       $atLeastOneMismatch = $true

          Write-Warning "This cert is NOT in the CTL: $certThumbprint – $certSubject"

       if ($repair -eq $true)

       {

        write-Warning "Attempting to repair"

        $store.Add($cert)

        Write-Warning "Repair successful"

       }

                else

                {

                    Write-Warning ("Please install KB.2964735 or re-run script with -syncproxytrustcerts switch to add missing Proxy Trust certs to AdfsTrustedDevices cert store")

                }

         }

        }

    }

    $store.Close()

    if ($atLeastOneMismatch -eq $false)

    {

     Write-Host("Check Passed: No mismatched certs found. CTL is in sync with DB content")

    }

}

checkhttpsyscertbindings

checkadfstrusteddevicesstore

checkproxytrustcerts($syncproxytrustcerts)

Write-Host; Write-Host("All checks completed.")

Apa yang dimaksud dengan masalah yang terdeteksi?

Pengikatan IP:port lebih diutamakan tertinggi. Jika pengikatan IP:port AD FS SSL sertifikat pengikatan, http.sys selalu menggunakan sertifikat untuk mengikat SSL komunikasi. Untuk mengatasi masalah ini, gunakan metode berikut.

Metode 1: Menghapus pengikatan IP:port

Berhati-hatilah bahwa pengikatan IP:port mungkin muncul kembali setelah Anda menghapus. Sebagai contoh, aplikasi dikonfigurasi dengan ikatan IP:port ini akan secara otomatis membuat ulang di awal layanan berikutnya.

Metode 2: Menggunakan alamat IP lain untuk komunikasi AD FS SSL

Apabila pengikatan IP:port diperlukan, menyelesaikan ADFS Layanan FQDN ke alamat IP yang tidak digunakan dalam pengikatan apa pun. Dengan demikian, http.sys akan menggunakan pengikatan Hostname:port SSL komunikasi.

Metode 3: AdfsTrustedDevices ditetapkan sebagai penyimpanan CTL untuk mengikat IP:port

Ini adalah pilihan terakhir jika Anda tidak dapat menggunakan metode di atas. Tapi lebih baik untuk memahami kondisi berikut ini sebelum Anda mengubah default CTL menyimpan AdfsTrustedDevices:

  • Mengapa IP:port pengikatan ada.

  • Jika pengikatan mengandalkan default CTL toko untuk otentikasi sertifikat klien.

Masalah diselesaikan?

Jika Azure AD menyambung diinstal, gunakan AAD menyambung untuk menetapkan nama toko CTL ke AdfsTrustedDevices untuk pengikatan sertifikat SSL pada semua server AD FS. Jika Azure AD menyambung tidak diinstal, kembali AD FS sertifikat pengikatan dengan menjalankan perintah berikut pada semua server AD FS.
Set-AdfsSslCertificate -Thumbprint Thumbprint

Masalah diselesaikan?

Jika CA diterbitkan Sertifikat di penyimpanan sertifikat yang mana hanya ditandatangani sendiri sertifikat biasanya akan ada, CTL dibuat dari toko hanya berisi CA diterbitkan Sertifikat. Penyimpanan sertifikat AdfsTrustedDevices adalah penyimpanan yang seharusnya memiliki hanya ditandatangani sendiri sertifikat. Sertifikat ini adalah:

  • Access organisasi MS: Ditandatangani sendiri sertifikat yang digunakan untuk mengeluarkan workplace bergabung dengan sertifikat.

  • Kepercayaan ADFS Proxy: Sertifikat untuk setiap server proksi aplikasi Web.

AdfsTrustedDevices certificates

Oleh karena itu, Hapus semua sertifikat CA dikeluarkan dari penyimpanan sertifikat AdfsTrustedDevices.

Masalah diselesaikan?

Ketika hubungan kepercayaan proksi yang dibuat dengan server AD FS, sertifikat klien ditulis ke pangkalan data konfigurasi AD FS dan ditambahkan ke penyimpanan sertifikat AdfsTrustedDevices di server AD FS. Untuk penyebaran farm AD FS, sertifikat klien diharapkan untuk disinkronkan ke server AD FS lainnya. Apabila sinkronisasi tidak terjadi karena beberapa alasan, hubungan kepercayaan proxy hanya akan bekerja terhadap server AD FS kepercayaan dibuat dengan, tetapi tidak terhadap server AD FS lainnya.

Untuk mengatasi masalah ini, gunakan salah satu metode berikut.

Metode 1

Instal pemutakhiran yang didokumentasikan di KB 2964735 di semua server AD FS. Setelah pembaruan diinstal, sinkronisasi sertifikat klien yang diharapkan terjadi secara otomatis.

Metode 2

Menjalankan skrip dengan switch syncproxytrustcerts – secara manual Sync sertifikat klien dari AD FS konfigurasi database penyimpanan sertifikat AdfsTrustedDevices. Skrip harus dijalankan di semua server AD FS farm.

Perhatikan bahwa ini adalah tidak solusi permanen karena sertifikat klien akan diperbarui secara teratur.

Masalah diselesaikan?

Periksa apakah ada ketidakcocokan waktu atau zona waktu. Jika waktu yang cocok dengan tetapi tidak zona waktu, hubungan kepercayaan proxy juga akan gagal dapat dibuat.

Masalah diselesaikan?

Jika penghentian SSL terjadi pada perangkat jaringan antara AD FS server dan WAP server, komunikasi antara AD FS dan WAP akan merusak karena komunikasi didasarkan pada sertifikat klien.

Nonaktifkan SSL penghentian pada perangkat jaringan antara server AD FS dan WAP.

Masalah diselesaikan?

Periksa pengaturan otentikasi Terpadu Windows di browser klien, AD FS pengaturan dan parameter permintaan otentikasi.

Periksa browser klien pengguna

Periksa setelan berikut pada pilihan Internet:

  • Pada Advanced tab, pastikan bahwa pengaturan Mengaktifkan otentikasi Terpadu Windows telah diaktifkan.

  • Berikut keamanan > intranet lokal > situs > lanjutan, pastikan bahwa AD FS URL di daftar situs web.

  • Berikut Keamanan > intranet lokal > tingkat kustom, pastikan bahwa setelan otomatis masuk hanya di zona Intranet dipilih.

Jika Anda menggunakan Firefox, Chrome atau Safari, pastikan bahwa pengaturan setara di peramban ini diaktifkan.

Periksa pengaturan AD FS

Periksa pengaturan WindowsIntegratedFallback

  1. Buka Windows PowerShell dengan Jalankan sebagai administrator opsi.

  2. Dapatkan kebijakan global otentikasi dengan menjalankan perintah berikut ini:
    Get-ADFSGlobalAuthenticationPolicy

  3. Periksa nilai dari atribut WindowsIntegratedFallbackEnbaled.

Jika nilai yang benar, otentikasi berbasis borang yang diharapkan. Ini berarti bahwa permintaan otentikasi berasal dari browser yang tidak mendukung otentikasi Terpadu Windows. Lihat bagian berikutnya tentang cara mendapatkan peramban yang didukung.

Jika nilai adalah False, otentikasi Terpadu Windows harus diharapkan.

Periksa pengaturan WIASupportedUsersAgents

  1. Dapatkan daftar agen pengguna yang didukung dengan menjalankan perintah berikut ini:
    Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents

  2. Periksa daftar untai agen pengguna yang mengembalikan perintah.

Verifikasi Apakah untai agen pengguna browser Anda dalam daftar. Jika tidak, tambahkan untai agen pengguna dengan mengikuti langkah-langkah berikut:

  1. Buka http://useragentstring.com/ yang mendeteksi dan menampilkan untai agen pengguna browser.

  2. Dapatkan daftar agen pengguna yang didukung dengan menjalankan perintah berikut ini:
    $wiaStrings = Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents

  3. Tambahkan untai agen pengguna browser dengan menjalankan perintah berikut ini:
    $wiaStrings = $wiaStrings+"NewUAString"
    Contoh:$wiaStrings = $wiaStrings+" =~Windows\s*NT.*Edge"+"Mozilla/5.0"

  4. Perbarui pengaturan WIASupportedUserAgents dengan menjalankan perintah berikut ini:
    Set-ADFSProperties -WIASupportedUserAgents $wiaStrings

Periksa parameter permintaan otentikasi

Periksa jika permintaan otentikasi menentukan otentikasi berbasis formulir sebagai metode otentikasi

  1. Jika permintaan otentikasi permintaan WS-Federation, periksa apakah permintaan mencakup wauth = urn: oasis: Nama: tc: SAML:1.0:am:password.

  2. Jika permintaan otentikasi permintaan SAML, periksa jika permintaan termasuk samlp:AuthnContextClassRef elemen dengan nilai urn: oasis: Nama: tc: SAML:2.0:ac:classes:Password.

Untuk informasi selengkapnya, lihat Ikhtisar otentikasi handler AD FS masuk halaman.

Periksa apakah aplikasi Layanan Online Microsoft Office 365

Jika aplikasi yang ingin mengakses bukan Layanan Online Microsoft, Anda mengalami diharapkan dan dikendalikan oleh permintaan otentikasi masuk . Bekerja dengan pemilik aplikasi untuk mengubah perilaku.

Apabila aplikasi Layanan Online Microsoft, apa yang Anda alami dapat dikendalikan oleh PromptLoginBehavior pengaturan dari objek bidang terpercaya. Pengaturan ini mengontrol Apakah Azure AD penyewa mengirim prompt = login ke AD FS. Untuk menetapkan PromptLoginBehavior pengaturanikuti langkah:

  1. Buka Windows PowerShell dengan opsi "Jalankan sebagai administrator".

  2. Dapatkan domain federasi pengaturan yang ada dengan menjalankan perintah berikut ini:
    Get-MSOLDomainFederationSettings -DomainName DomainName | FL *

  3. Tetapkan pengaturan PromptLoginBehavior dengan menjalankan perintah berikut ini:
    Set-MSOLDomainFederationSettings -DomainName DomainName -PromptLoginBehavior <TranslateToFreshPasswordAuth|NativeSupport|Disabled> -SupportsMFA <$TRUE|$FALSE> -PreferredAuthenticationProtocol <WsFed|SAMLP>

    Nilai untuk PromptLoginBehavior parameter adalah:

    1. TranslateToFreshPasswordAuth: Azure AD mengirimkan wauth dan wfresh ke AD FS bukannya wantian = login. Hal ini menyebabkan permintaan otentikasi untuk menggunakan otentikasi berbasis formulir.

    2. NativeSupport: parameter login prompt = dikirim sebagai adalah AD FS.

    3. Nonaktifkan: apa yang dikirim ke AD FS.

Untuk mempelajari selengkapnya tentang perintah Set-MSOLDomainFederationSettings, lihat Active Directory Federation Services prompt = login parameter dukungan.

Masalah diselesaikan?

Otentikasi multi faktor dapat diaktifkan pada server AD FS, pihak mengandalkan, atau ditetapkan dalam parameter permintaan otentikasi. Periksa konfigurasi untuk melihat jika mereka telah ditetapkan dengan benar. Jika otentikasi multi faktor diharapkan tetapi Anda're berulang kali diminta untuk itu, periksa aturan penerbitan pihak mengandalkan untuk melihat jika multi faktor otentikasi klaim disampaikan melalui aplikasi.

Untuk informasi selengkapnya tentang otentikasi multi faktor di AD FS, lihat artikel berikut ini:

Periksa konfigurasi server AD FS dan mengandalkan pihak

Untuk memeriksa konfigurasi di server AD FS, validasi aturan global otentikasi tambahan. Untuk memeriksa konfigurasi pada pihak mengandalkan, validasi aturan otentikasi tambahan untuk kepercayaan pihak mengandalkan.

  1. Untuk memeriksa konfigurasi di server AD FS, jalankan perintah berikut di jendela Windows PowerShell.
    Get-ADFSAdditionalAuthenticationRule

    Untuk memeriksa konfigurasi pada pihak mengandalkan, jalankan perintah berikut ini:
    Get-ADFSRelyingPartyTrust -TargetName RelyingParty | Select -ExpandProperty AdditionalAuthenticationRules

    Catatan Jika perintah kembali tidak ada, aturan tambahan otentikasi tidak dikonfigurasi. Melewati bagian ini.

  2. Mengamati aturan klaim set dikonfigurasi.

Verifikasi jika otentikasi multi faktor diaktifkan di seperangkat aturan klaim

Seperangkat aturan klaim terdiri dari bagian berikut ini:

  • Pernyataan kondisi:C:[Type=…,Value=…]

  • Masalah pernyataan:=> issue (Type=…,Value=…)

Jika masalah pernyataan berisi klaim berikut, otentikasi multi faktor ditetapkan.
Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn"

Berikut adalah contoh yang memerlukan otentikasi multi faktor yang akan digunakan untuk non-workplace bergabung dengan perangkat dan akses extranet masing-masing:

  • c:[Type == "http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser", Value == "false"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn")

  • c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn")

Periksa aturan penerbitan pihak mengandalkan

Jika pengguna berulang kali menerima wantian otentikasi multi faktor setelah mereka melakukan otentikasi pertama, dimungkinkan pihak menjawab tidak melewati melalui klaim otentikasi multi faktor untuk aplikasi. Untuk memeriksa apakah otentikasi klaim melewati, ikuti langkah-langkah berikut:

  1. Jalankan perintah berikut di Windows PowerShell:
    Get-ADFSRelyingPartyTrust -TargetName ClaimApp

  2. Mengamati aturan yang ditetapkan ditetapkan dalam atribut IssuanceAuthorizationRules atau IssuanceAuthorizationRulesFile.

Seperangkat aturan harus menyertakan aturan penerbitan berikut ini untuk melewati multi faktor otentikasi klaim:
C:[Type==http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod, Value==” http://schemas.microsoft.com/claims/multipleauthn”]=>issue(claim = c)

Periksa parameter permintaan otentikasi

Periksa jika permintaan otentikasi menentukan otentikasi multi faktor sebagai metode otentikasi

  • Jika permintaan otentikasi permintaan WS-Federation, periksa apakah permintaan mencakup wauth = http://schemas.microsoft.com/claims/multipleauthn.

  • Jika permintaan otentikasi permintaan SAML, periksa jika permintaan termasuk samlp:AuthnContextClassRef elemen dengan nilai http://schemas.microsoft.com/claims/multipleauthn.

Untuk informasi selengkapnya, lihat Ikhtisar otentikasi handler AD FS masuk halaman.

Periksa apakah aplikasi Layanan Online Microsoft Office 365

Jika aplikasi yang ingin Anda mengakses Layanan Online Microsoft Office 365, periksa SupportsMFA domain federasi pengaturan.

  1. Dapatkan SupportsMFA domain federasi pengaturan yang saat ini dengan menjalankan perintah berikut ini:
    Get-MSOLDomainFederationSettings -DomainName DomainName | FL *

  2. Jika pengaturan SupportsMFA FALSE, tetapkan nilainya ke benar dengan menjalankan perintah berikut ini:
    Set-MSOLDomainFederationSettings -DomainName DomainName -SupportsMFA $TRUE

Masalah diselesaikan?

Menonaktifkan kemampuan login prompt = dengan menjalankan perintah berikut ini:
Set-MsolDomainFederationSettings –DomainName DomainName -PromptLoginBehavior Disabled

Setelah Anda menjalankan perintah ini, aplikasi Office 365 tidak termasuk prompt = login parameter di setiap permintaan otentikasi.

Masalah diselesaikan?

Mengubah parameter permintaan untuk menggunakan metode otentikasi yang diharapkan.

Masalah diselesaikan?

Jika SSO dinonaktifkan, mengaktifkannya.

Masalah diselesaikan?

Selamat! SSO masalah telah dipecahkan.

Kami Mohon maaf yang bermasalah. Kami akan menghargai jika Anda mengisi survei dengan rincian masalah Anda.

Apa yang dilakukan panduan ini?

Menyelesaikan masuk tunggal (SSO) masalah dengan Active Directory Federation Services (AD FS).

Ditujukan kepada siapa?

Administrator yang membantu mendiagnosa masalah SSO bagi pengguna.

Bagaimana cara kerja?

Kami akan mulai dengan meminta masalah yang dialami pengguna Anda. Kemudian kami akan membawa Anda melewati langkah spesifik untuk situasi Anda pemecahan masalah.

Perkiraan waktu penyelesaian:

30-45 menit.

Perlu bantuan lainnya?

Kembangkan keterampilan Anda
Jelajahi pelatihan
Dapatkan fitur baru terlebih dahulu
Gabung Microsoft Insider

Apakah informasi ini bermanfaat?

Terima kasih atas umpan balik Anda!

Terima kasih atas umpan balik Anda! Sepertinya menghubungkan Anda ke salah satu agen dukungan Office kami akan sangat membantu.

×