Az AD FS támogatásának konfigurálása felhasználói tanúsítványhitelesítéshez

2025-04-08
A következőre érvényes:: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

Ez a cikk bemutatja, hogyan engedélyezheti a felhasználói tanúsítványok hitelesítését az Active Directory összevonási szolgáltatásokban (AD FS). Hibaelhárítási információkat is nyújt az ilyen típusú hitelesítéssel kapcsolatos gyakori problémákhoz.

A felhasználói tanúsítvány hitelesítésének két fő felhasználási esete van:

A felhasználók intelligens kártyákkal jelentkeznek be az AD FS-rendszerükbe.
A felhasználók mobileszközökre kiépített tanúsítványokat használnak.

Előfeltételek

Határozza meg az AD FS felhasználói tanúsítványhitelesítés engedélyezésének módját, amelyet engedélyezni szeretne az AD FS tanúsítványhitelesítéséhez alternatív gazdagépnév-kötés támogatásával.
Győződjön meg arról, hogy a felhasználói tanúsítvány megbízhatósági láncát minden AD FS- és webalkalmazás-proxykiszolgáló (WAP) telepíti és megbízhatónak minősíti, beleértve a köztes hitelesítésszolgáltatókat is. Ezt általában csoportházirend-objektumon (GPO) keresztül teheti meg az AD FS- és WAP-kiszolgálókon.
Győződjön meg arról, hogy a felhasználói tanúsítványok megbízhatósági láncának főtanúsítványa az Active Directory NTAuth-tárolójában található.
Ha alternatív tanúsítványhitelesítési módban használja az AD FS-t, győződjön meg arról, hogy az AD FS- és WAP-kiszolgálók rendelkeznek ssl-tanúsítványokkal, amelyek tartalmazzák a "certauth" előtaggal ellátott AD FS-állomásnevet. Ilyen például a certauth.fs.contoso.com. Győződjön meg arról is, hogy az erre a gazdagépnévre irányuló forgalom engedélyezve van a tűzfalon keresztül.
Ha az extranetről használ tanúsítványhitelesítést, győződjön meg arról, hogy a tanúsítványokban megadott listából legalább egy szolgáltatói információ-hozzáférés (AIA) és legalább egy CRL-terjesztési pont (CDP) vagy online tanúsítványállapot-protokoll (OCSP) helye elérhető az internetről.
Ha AD FS-t konfigurál a Microsoft Entra-tanúsítványhitelesítéshez, győződjön meg arról, hogy konfigurálta a Microsoft Entra-beállításokat, valamint a tanúsítványkibocsátóhoz és a sorozatszámhoz szükséges AD FS-jogcímszabályokat.
Ha Microsoft Entra tanúsítványhitelesítést használ Exchange ActiveSync ügyfelekhez, az ügyféltanúsítványnak tartalmaznia kell a felhasználó elérhető e-mail címét az Exchange Online-ban vagy a Fő név értékben, vagy a RFC822 Név értékében a Tárgy alternatív neve mezőben. A Microsoft Entra ID leképozza az RFC822 értéket a címtár proxycímattribútumára.

Jegyzet

Az AD FS nem támogatja az intelligens kártyával vagy tanúsítványalapú hitelesítéssel rendelkező felhasználónév-tippeket.

Felhasználói tanúsítvány hitelesítésének engedélyezése

A felhasználói tanúsítvány hitelesítésének engedélyezése intranetes vagy extranetes hitelesítési módszerként az AD FS felügyeleti konzol vagy a PowerShell-parancsmag Set-AdfsGlobalAuthenticationPolicyhasználatával.

Választható szempontok a következők:

Ha az EKU jogcímtípuson kívül tanúsítványmezőkön és bővítményeken alapuló jogcímeket is szeretne használni, https://schemas.microsoft.com/2012/12/certificatecontext/extension/ekukonfiguráljon további jogcímátvételi szabályokat az Active Directory jogcímszolgáltató megbízhatóságára. A cikk későbbi részében megtekintheti az elérhető tanúsítványra vonatkozó igények teljes listáját.
Ha a tanúsítvány típusa alapján kell korlátoznia a hozzáférést, a tanúsítvány további tulajdonságait az alkalmazás AD FS-kiállítási engedélyezési szabályaiban használhatja. Gyakori forgatókönyv, hogy csak a mobileszköz-felügyeleti (MDM-) szolgáltató által kiépített tanúsítványokat engedélyezi, vagy csak intelligenskártya-tanúsítványokat engedélyez.

Fontos

Azok az ügyfelek, akik eszközkód-folyamatot használnak hitelesítésre, és a Microsoft Entra-azonosítótól (például AD FS) eltérő identitásszolgáltatóval hajtják végre az eszközhitelesítést, nem kényszeríthetik az eszközalapú hozzáférést a Microsoft Entra-erőforrásokhoz. Például nem engedélyezhetik csak a felügyelt eszközöket egy külső MDM-szolgáltatás használatával.

A vállalati erőforrásokhoz való hozzáférés védelméhez és az adatszivárgás megelőzéséhez konfigurálja a Microsoft Entra eszközalapú feltételes hozzáférést. Használja például a Az eszköz megfelelőségének megjelölésének megkövetelése a Microsoft Entra feltételes hozzáférés-vezérlés biztosításához.

Konfigurálja az engedélyezett hitelesítésszolgáltatókat az ügyféltanúsítványok számára a Schannel SSP technikai áttekintésének "Megbízható kiállítók kezelése ügyfélhitelesítéshez" című témakörében található útmutató segítségével.
Fontolja meg a bejelentkezési lapok módosítását a felhasználók igényeinek megfelelően, amikor tanúsítványhitelesítést végeznek. Gyakori eset, hogy a "Jelentkezzen be az X509 tanúsítványával" üzenetet valami felhasználóbarátabbra változtatják.

Zökkenőmentes tanúsítványhitelesítés konfigurálása a Chrome böngészőhöz Windows asztali számítógépeken

Ha egy gép több felhasználói tanúsítvánnyal (például Wi-Fi tanúsítvánnyal) rendelkezik, amelyek megfelelnek az ügyfél-hitelesítés céljának, a Windows asztali Chrome böngészője kérni fogja a felhasználókat a megfelelő tanúsítvány kiválasztására. Ez a kérés zavaró lehet a felhasználók számára. A felhasználói élmény optimalizálásához beállíthat egy szabályzatot a Chrome-hoz, amely automatikusan kiválasztja a megfelelő tanúsítványt.

Automatikusan konfigurálhatja ezt a szabályzatot GPO-val (a beállításkulcsok beállításához) vagy manuálisan is beállíthatja egy beállításjegyzék-módosítással. Ehhez az AD FS-hez való hitelesítéshez használt felhasználói tanúsítványoknak különböző kiállítók által kell kibocsátva lenniük a többi használati esettől.

A tanúsítványhitelesítés Chrome-hoz való konfigurálásáról további információt Chrome Enterprise szabályzatlistájában.

Tanúsítványhitelesítés hibaelhárítása

Az alábbi információk segítségével elháríthatja az AD FS tanúsítványhitelesítéshez való konfigurálásakor felmerülő gyakori problémákat a felhasználók számára.

Ellenőrizze, hogy a tanúsítvány megbízható kiállítói megfelelően vannak-e konfigurálva az összes AD FS- és WAP-kiszolgálón

Ha a tanúsítvány megbízható kiállítói nincsenek megfelelően konfigurálva, a gyakori tünet egy HTTP 204 hiba: "Nincs tartalom a https://certauth.adfs.contoso.com."-tól;"

Az AD FS az alapul szolgáló Windows operációs rendszert használja a felhasználói tanúsítvány birtoklásának igazolására, és a tanúsítvány megbízhatósági láncának hitelesítésével biztosítja, hogy az megfeleljen egy megbízható kiállítónak. A megbízható kiállítóval való egyeztetéshez gondoskodnia kell arról, hogy az összes legfelső szintű és köztes hatóság megbízható kiállítóként legyen konfigurálva a helyi tárolóban a számítógép-hitelesítésszolgáltatók számára.

Ennek automatikus ellenőrzéséhez használja az AD FS Diagnostics Analyzer eszközt. Az eszköz lekérdezi az összes kiszolgálót, és biztosítja a megfelelő tanúsítványok megfelelő kiépítését.

Töltse le és futtassa az eszközt.
Töltse fel az eredményeket, és tekintse át az esetleges hibákat.

Ellenőrizze, hogy engedélyezve van-e a tanúsítványhitelesítés az AD FS hitelesítési szabályzatában

Az AD FS alapértelmezés szerint a 49443-as porton hajtja végre a felhasználói tanúsítvány hitelesítését ugyanazzal a gazdagépnévvel, mint az AD FS (például adfs.contoso.com). Az AD FS-t úgy is konfigurálhatja, hogy a 443-as portot (az alapértelmezett HTTPS-portot) használja a másodlagos SSL-kötés használatával. Az ebben a konfigurációban használt URL-cím azonban certauth.<adfs-farm-name> (például: certauth.contoso.com). További információért lásd: AD FS támogatása az alternatív gazdagépnév-kötéshez a tanúsítványhitelesítés során.

Jegyzet

A Windows Server 2016 AD FS-ben mostantól két mód támogatott. Az első mód a adfs.contoso.com gazdagépet használja a 443-as és a 49443-as portokkal. A második mód a adfs.contoso.com és certauth.adfs.contoso.com gazdagépeket használja a 443-as porttal. A certauth.\<adfs-service-name> másodlagos tulajdonosnévként való támogatásához SSL-tanúsítványra van szükség. Ezt a farm létrehozásakor vagy később is megteheti a PowerShell-lel.

A hálózati csatlakozási problémák leggyakoribb esete, hogy a tűzfal helytelenül lett konfigurálva, és letiltja a forgalmat a felhasználói tanúsítványok hitelesítéséhez. A probléma felmerülésekor általában üres képernyő vagy 500 kiszolgálóhiba jelenik meg. A hiba kijavítása:

Jegyezze fel az AD FS-ben konfigurált állomásnevet és portot.
Győződjön meg arról, hogy az AD FS és a WAP előtti tűzfal úgy van konfigurálva, hogy engedélyezze az AD FS-farm számára a hostname:port kombinációt. A hálózati mérnöknek végre kell hajtania ezt a lépést.

CRL-kapcsolat ellenőrzése

A tanúsítvány-visszavonási listák (CRL-ek) olyan végpontok, amelyek a felhasználói tanúsítványba vannak kódolva a futásidejű visszavonási ellenőrzések végrehajtásához. Ha például ellopnak egy tanúsítványt tartalmazó eszközt, a rendszergazda felveheti a tanúsítványt a visszavont tanúsítványok listájára. A tanúsítványt korábban elfogadó végpontok mostantól nem fogják végrehajtani a hitelesítést.

Minden AD FS- és WAP-kiszolgálónak el kell érnie a CRL-végpontot annak ellenőrzéséhez, hogy a neki bemutatott tanúsítvány továbbra is érvényes-e, és nem lett-e visszavonva. A CRL érvényesítése HTTPS, HTTP, LDAP vagy OCSP protokollon keresztül történhet. Ha az AD FS- és WAP-kiszolgálók nem érik el a végpontot, a hitelesítés sikertelen lesz. A hibaelhárításhoz kövesse az alábbi lépéseket:

Kérje meg a nyilvános kulcsú infrastruktúra (PKI) mérnökét, hogy megállapíthassa, mely CRL-végpontok használatával vonhatja vissza a felhasználói tanúsítványokat a PKI-rendszerből.
Minden AD FS- és WAP-kiszolgálón győződjön meg arról, hogy a CRL-végpontok a használt protokollon keresztül érhetők el (általában HTTPS vagy HTTP).
A speciális ellenőrzéshez engedélyezze a(z) CAPI2 eseménynaplózást az egyes AD FS, valamint WAP-kiszolgálókon.
Ellenőrizze a CAPI2 működési naplóiban a 41-s eseményazonosítót (visszavonás ellenőrzése).
Ellenőrizze az <Result value="80092013">The revocation function was unable to check revocation because the revocation server was offline.</Result>-t.

Borravaló

Egyetlen AD FS- vagy WAP-kiszolgálót is megcélozhat a könnyebb hibaelhárítás érdekében, ha konfigurálja a DNS-feloldást (a Windows gazdagépfájl segítségével), hogy egy adott kiszolgálóra mutasson. Ez a technika lehetővé teszi a nyomkövetés engedélyezését egy kiszolgáló megcélzásával.

SNI-problémák ellenőrzése

Az AD FS használatához ügyféleszközökre (vagy böngészőkre) és terheléselosztókra van szükség a kiszolgálónév-jelzés (SNI) támogatásához. Egyes ügyféleszközök (például az Android régebbi verziói) nem támogatják az SNI-t. Emellett előfordulhat, hogy a terheléselosztók nem támogatják az SNI-t, vagy nem konfigurálhatók SNI-hez. Ezekben az esetekben valószínűleg felhasználói minősítési hibákat fog kapni.

A probléma megoldásához a hálózati mérnökkel együttműködve győződjön meg arról, hogy az AD FS és a WAP terheléselosztója támogatja az SNI-t. Ha az SNI nem támogatott, használja az alábbi kerülő megoldást az AD FS-ben:

Nyisson meg egy emelt szintű parancssori ablakot az elsődleges AD FS-kiszolgálón.
Adja meg a Netsh http show sslcert.
Másolja ki az összevonási szolgáltatás alkalmazás GUID azonosítóját és tanúsítványkivonatát.
Adja meg a netsh http add sslcert ipport=0.0.0.0:{your_certauth_port} certhash={your_certhash} appid={your_applicationGUID}.

Ellenőrizze, hogy az ügyféleszköz megfelelően lett-e kiépítve a tanúsítvánnyal

Előfordulhat, hogy egyes eszközök megfelelően működnek, más eszközök azonban nem. A legtöbb esetben ez azt jelenti, hogy a felhasználói tanúsítvány egyes ügyféleszközökön nem lett megfelelően kiépítve. Kövesse az alábbi lépéseket:

Ha a probléma egy Android-eszközre vonatkozik, a leggyakoribb ok az, hogy a tanúsítványlánc nem megbízható teljes mértékben az eszközön. Tekintse meg az MDM-gyártót, és győződjön meg arról, hogy a tanúsítvány megfelelően lett kiépítve, és a teljes lánc teljes mértékben megbízható az Android-eszközön.

Ha a probléma egy Windows-eszközre vonatkozik, ellenőrizze, hogy a tanúsítvány megfelelően van-e kiépítve a bejelentkezett felhasználó Windows-tanúsítványtárolójának ellenőrzésével (nem rendszer vagy számítógép).
Exportálja az ügyfélfelhasználói tanúsítványt egy .cer fájlba, és futtassa a parancsot certutil -f -urlfetch -verify certificatefilename.cer.

Ellenőrizze, hogy a TLS-verzió kompatibilis-e az AD FS/WAP-kiszolgálók és az ügyféleszköz között

Ritkán az ügyféleszközt úgy frissítik, hogy csak a TLS egy magasabb verzióját támogatják (például 1.3). Vagy előfordulhat, hogy fordított probléma merül fel, amikor az AD FS- és WAP-kiszolgálókat úgy frissítették, hogy csak egy magasabb TLS-verziót használjanak, amelyet az ügyféleszköz nem támogat.

Online SSL-eszközökkel ellenőrizheti az AD FS- és WAP-kiszolgálókat, és ellenőrizheti, hogy kompatibilisek-e az eszközzel. A TLS-verziók szabályozásáról további információt Az AD FS-SSL-/TLS-protokollok és titkosítási csomagok kezelése című témakörben talál.

Ellenőrizze, hogy a Microsoft Entra PromptLoginBehavior megfelelően van-e konfigurálva az összevont tartomány beállításaiban

Számos Office 365-alkalmazás küld prompt=login a Microsoft Entra-azonosítónak. A Microsoft Entra ID alapértelmezés szerint egy új jelszó-bejelentkezéssé alakítja át az AD FS-be. Ennek eredményeképpen még ha konfigurálta is a tanúsítványhitelesítést az AD FS-ben, a felhasználók csak egy jelszóval történő bejelentkezést láthatnak. A probléma megoldása:

Az összevont tartománybeállításokat a Get-MgDomainFederationConfiguration parancsmaggal szerezheti be.
Győződjön meg arról, hogy a PromptLoginBehavior paraméter Disabled vagy NativeSupportértékre van állítva.

További információért lásd: AD FS prompt=login paraméter támogatása.

További hibaelhárítás

Ritka esetben, ha a CRL-listák nagyon hosszúak, időtúllépés következhet be a letöltési kísérlet során. Ebben az esetben frissítenie kell és a Windowsbeállításjegyzékének Http.sys beállításaiban leírtak szerint.

Referencia: A felhasználói tanúsítvány jogcímtípusainak és példaértékeinek teljes listája

Jogcím típusa	Példaérték
`http://schemas.microsoft.com/2012/12/certificatecontext/field/x509version`	`3`
`http://schemas.microsoft.com/2012/12/certificatecontext/field/signaturealgorithm`	`sha256RSA`
`http://schemas.microsoft.com/2012/12/certificatecontext/field/issuer`	`CN=entca, DC=domain, DC=contoso, DC=com`
`http://schemas.microsoft.com/2012/12/certificatecontext/field/issuername`	`CN=entca, DC=domain, DC=contoso, DC=com`
`http://schemas.microsoft.com/2012/12/certificatecontext/field/notbefore`	`12/05/2016 20:50:18`
`http://schemas.microsoft.com/2012/12/certificatecontext/field/notafter`	`12/05/2017 20:50:1`8
`http://schemas.microsoft.com/2012/12/certificatecontext/field/subject`	`E=user@contoso.com, CN=user, CN=Users, DC=domain, DC=contoso, DC=com`
`http://schemas.microsoft.com/2012/12/certificatecontext/field/subjectname`	`E=user@contoso.com, CN=user, CN=Users, DC=domain, DC=contoso, DC=com`
`http://schemas.microsoft.com/2012/12/certificatecontext/field/rawdata`	`{Base64 encoded digital certificate data}`
`http://schemas.microsoft.com/2012/12/certificatecontext/extension/keyusage`	`DigitalSignature`
`http://schemas.microsoft.com/2012/12/certificatecontext/extension/keyusage`	`KeyEncipherment`
`http://schemas.microsoft.com/2012/12/certificatecontext/extension/subjectkeyidentifier`	`9D11941EC06FACCCCB1B116B56AA97F3987D620A`
`http://schemas.microsoft.com/2012/12/certificatecontext/extension/authoritykeyidentifier`	`KeyID=d6 13 e3 6b bc e5 d8 15 52 0a fd 36 6a d5 0b 51 f3 0b 25 7f`
`http://schemas.microsoft.com/2012/12/certificatecontext/extension/certificatetemplatename`	`User`
`http://schemas.microsoft.com/2012/12/certificatecontext/extension/san`	`Other Name:Principal Name=user@contoso.com, RFC822 Name=user@contoso.com`
`http://schemas.microsoft.com/2012/12/certificatecontext/extension/eku`	`1.3.6.1.4.1.311.10.3.4`

Megosztás a következőn keresztül: