Microsoft Entra tanúsítványalapú hitelesítés – részletes műszaki útmutató

Ez a cikk bemutatja a Microsoft Entra tanúsítványalapú hitelesítés (CBA) működését, és megismerkedik a Microsoft Entra CBA-konfigurációkkal kapcsolatos technikai részletekkel.

Hogyan működik a Microsoft Entra tanúsítványalapú hitelesítése?

Az alábbi kép bemutatja, hogy mi történik, ha egy felhasználó egy olyan bérlőben próbál bejelentkezni egy alkalmazásba, ahol engedélyezve van a Microsoft Entra CBA.

Most végigvezetjük az egyes lépéseket:

1. A felhasználó megpróbál hozzáférni egy alkalmazáshoz, például a MyApps portálhoz.

2. Ha a felhasználó még nincs bejelentkezve, a rendszer átirányítja a felhasználót a Microsoft Entra ID felhasználói bejelentkezési lapjára a következő címen https://login.microsoftonline.com/: .

3. A felhasználó beírja a felhasználónevét a Microsoft Entra bejelentkezési oldalára, majd a Tovább lehetőséget választja. A Microsoft Entra ID a bérlő nevével végzi az otthoni tartományfelderítést, a felhasználónév pedig a felhasználó keresésére szolgál a bérlőben.

   

4. A Microsoft Entra ID ellenőrzi, hogy engedélyezve van-e a CBA a bérlő számára. Ha a CBA engedélyezve van, a felhasználó egy tanúsítvány vagy intelligens kártya használatára mutató hivatkozást lát a jelszóoldalon. Ha a felhasználó nem látja a bejelentkezési hivatkozást, győződjön meg arról, hogy a CBA engedélyezve van a bérlőn. További információ: Hogyan a Microsoft Entra CBA engedélyezése?.

   Feljegyzés

   Ha a CBA engedélyezve van a bérlőn, a jelszóoldalon minden felhasználó láthatja a tanúsítvány vagy intelligens kártya használatára mutató hivatkozást. Azonban csak a CBA hatókörébe tartozó felhasználók végezhetnek sikeres hitelesítést a Microsoft Entra-azonosítót identitásszolgáltatóként (IdP) használó alkalmazáson.

   

   Ha engedélyezte az egyéb hitelesítési módszereket, például Telefon bejelentkezési vagy biztonsági kulcsokat, a felhasználók eltérő bejelentkezési képernyőt láthatnak.

   

5. Miután a felhasználó a tanúsítványalapú hitelesítést választja, a rendszer átirányítja az ügyfelet a tanúsítványvégpontra, amely a nyilvános Entra-azonosítóhoz tartozik https://certauth.login.microsoftonline.com . Az Azure Government esetében a tanúsítványvégpont az https://certauth.login.microsoftonline.us.

   A végpont kölcsönös TLS-hitelesítést végez, és a TLS-kézfogás részeként kéri az ügyféltanúsítványt. A kérelem bejegyzése megjelenik a bejelentkezési naplóban.

   Feljegyzés

   A hálózati rendszergazdának engedélyeznie kell a felhasználói bejelentkezési laphoz és a tanúsítványvégponthoz *.certauth.login.microsoftonline.com való hozzáférést az ügyfél felhőkörnyezetéhez. Tiltsa le a TLS-ellenőrzést a tanúsítványvégponton, hogy az ügyféltanúsítvány-kérés sikeres legyen a TLS-kézfogás részeként.

   Győződjön meg arról, hogy a TLS-vizsgálat letiltása az új URL-címhez is működik a kiállítói tippekkel. Ne kódolja az URL-címet a tenantId azonosítóval, mert előfordulhat, hogy a B2B-felhasználóknál megváltozik. Használjon egy reguláris kifejezést, amely lehetővé teszi, hogy a régi és az új URL-cím is működjön a TLS-vizsgálat letiltásához. Például a proxytól függően használja *.certauth.login.microsoftonline.com vagy *certauth.login.microsoftonline.com. Az Azure Governmentben használja *.certauth.login.microsoftonline.us vagy *certauth.login.microsoftonline.us.

   Ha nincs engedélyezve a hozzáférés, a tanúsítványalapú hitelesítés meghiúsul, ha engedélyezi a hamarosan megjelenő megbízható hitelesítésszolgáltatói tippek funkciót.

6. A Microsoft Entra ID ügyféltanúsítványt kér. A felhasználó kiválasztja az ügyféltanúsítványt, és az Ok gombot választja.

   Feljegyzés

   A megbízható hitelesítésszolgáltatói tippek nem támogatottak, ezért a tanúsítványok listája nem terjedhet ki további hatókörre. Ezt a funkciót a jövőben szeretnénk hozzáadni.

   

7. A Microsoft Entra ID ellenőrzi a visszavont tanúsítványok listáját, hogy meggyőződjön arról, hogy a tanúsítvány nincs visszavonva és érvényes. A Microsoft Entra ID a bérlőn konfigurált felhasználónév-kötéssel azonosítja a felhasználót a tanúsítványmező értékének a felhasználói attribútum értékére való leképezéséhez.

8. Ha egy egyedi felhasználó olyan feltételes hozzáférési szabályzattal rendelkezik, amely többtényezős hitelesítést igényel, és a tanúsítványhitelesítési kötési szabály megfelel az MFA-nak, akkor a Microsoft Entra ID azonnal aláírja a felhasználót. Ha MFA szükséges, de a tanúsítvány csak egyetlen tényezőnek felel meg, akkor a jelszó nélküli bejelentkezés vagy a FIDO2 második tényezőként érhető el, ha már regisztrálva vannak.

9. A Microsoft Entra ID befejezi a bejelentkezési folyamatot egy elsődleges frissítési jogkivonat visszaküldésével, amely jelzi a sikeres bejelentkezést.

10. Ha a felhasználó bejelentkezése sikeres, a felhasználó hozzáférhet az alkalmazáshoz.

A tanúsítványalapú hitelesítés MFA-kompatibilis

A Microsoft Entra CBA képes többtényezős hitelesítésre (MFA). A Microsoft Entra CBA lehet egytényezős (SF) vagy többtényezős (MF) a bérlő konfigurációjától függően. A CBA engedélyezése lehetővé teszi a felhasználó számára az MFA elvégzését. Előfordulhat, hogy a felhasználónak több konfigurációra van szüksége az MFA befejezéséhez, és más hitelesítési módszerek regisztrálásához, ha a felhasználó a CBA hatókörébe tartozik.

Ha a CBA-kompatibilis felhasználó csak egytényezős (SF) tanúsítvánnyal rendelkezik, és az MFA-t kell elvégeznie:

1. Használjon jelszót és SF-tanúsítványt.
2. Ideiglenes hozzáférési bérlet kiállítása.
3. A hitelesítési szabályzat Rendszergazda istrator hozzáad egy telefonszámot, és engedélyezi a hang- és szöveges üzenetek hitelesítését a felhasználói fiók számára.

Ha a CBA-kompatibilis felhasználó még nem állított ki tanúsítványt, és ki kell fejeznie az MFA-t:

1. Ideiglenes hozzáférési bérlet kiállítása.
2. A hitelesítési szabályzat Rendszergazda istrator hozzáad egy telefonszámot, és engedélyezi a hang- és szöveges üzenetek hitelesítését a felhasználói fiók számára.

Ha a CBA-kompatibilis felhasználó nem tud MF-tanúsítványt használni, például intelligenskártya-támogatás nélküli mobileszközön, és be kell fejeznie az MFA-t:

1. Ideiglenes hozzáférési bérlet kiállítása.
2. A felhasználónak regisztrálnia kell egy másik MFA-módszert (amikor a felhasználó használhatja az MF tanúsítványt).
3. Jelszó és MF-tanúsítvány használata (ha a felhasználó használhatja az MF tanúsítványt).
4. A hitelesítési szabályzat Rendszergazda istrator hozzáad egy telefonszámot, és engedélyezi a hang- és szöveges üzenetek hitelesítését a felhasználói fiók számára.

MFA egytényezős tanúsítványalapú hitelesítéssel (előzetes verzió)

A Microsoft Entra CBA második tényezőként használható az MFA-követelmények egytényezős tanúsítványokkal való teljesítéséhez. A támogatott kombinációk némelyike a következő:

1. CBA (első tényező) és jelszó nélküli telefonos bejelentkezés (jelszó nélküli bejelentkezés második tényezőként)
2. CBA (első tényező) és FIDO2 biztonsági kulcsok (második tényező)
3. Jelszó (első tényező) és CBA (második tényező)

A Microsoft Entra CBA-val való bejelentkezéshez a felhasználóknak más módon kell beszerezni az MFA-t, és regisztrálniuk kell a jelszó nélküli bejelentkezést vagy a FIDO2-t.

Fontos

A felhasználó akkor tekinthető MFA-kompatibilisnek, ha azok szerepelnek a CBA-metódus beállításai között. Ez azt jelenti, hogy a felhasználó a hitelesítés részeként nem használhatja fel a hitelesítést más elérhető módszerek regisztrálásához. Győződjön meg arról, hogy az érvényes tanúsítvánnyal nem rendelkező felhasználók nem szerepelnek a CBA-metódus beállításai között. A hitelesítés működésével kapcsolatos további információkért tekintse meg a Microsoft Entra többtényezős hitelesítést.

A jelszó nélküli telefonos bejelentkezés (PSI) beállításának lépései a CBA-val

A jelszó nélküli bejelentkezés működéséhez a felhasználóknak le kell tiltaniuk az örökölt értesítéseket a mobilalkalmazásukon keresztül.

1. Jelentkezzen be a Microsoft Entra felügyeleti központba legalább hitelesítési szabályzatként Rendszergazda istratorként.

2. Kövesse a jelszó nélküli telefonos bejelentkezési hitelesítés engedélyezésének lépéseit.

   Fontos

   Az előző konfigurációban győződjön meg arról, hogy a Jelszó nélküli beállítást választotta. A PSI-hez hozzáadott csoportok hitelesítési módját jelszó nélkülire kell módosítania. Ha az Any lehetőséget választja, a CBA és a PSI nem működik.

3. Válassza a Védelmi>többtényezős hitelesítés>további felhőalapú többtényezős hitelesítési beállításait.

   

4. Az Ellenőrzési beállítások területen törölje az értesítés jelölését a mobilalkalmazáson keresztül, és válassza a Mentés lehetőséget.

   

MFA-hitelesítési folyamat egytényezős tanúsítványokkal és jelszó nélküli bejelentkezéssel

Tekintsünk meg egy példát egy olyan felhasználóra, aki egytényezős tanúsítvánnyal rendelkezik, és jelszó nélküli bejelentkezésre van konfigurálva.

1. Adja meg a felhasználónevet (UPN), és válassza a Tovább gombot.

   

2. Válassza a Bejelentkezés tanúsítvánnyal lehetőséget.

   

   Ha engedélyezte az egyéb hitelesítési módszereket, például Telefon bejelentkezési vagy FIDO2 biztonsági kulcsokat, a felhasználók eltérő bejelentkezési képernyőt láthatnak.

   

3. Válassza ki a megfelelő felhasználói tanúsítványt az ügyféltanúsítvány-választóban, és válassza az OK gombot.

   

4. Mivel a tanúsítvány egytényezős hitelesítésre van konfigurálva, a felhasználónak egy második tényezőre van szüksége az MFA-követelmények teljesítéséhez. A felhasználó az elérhető második tényezőket látja, amelyek ebben az esetben jelszó nélküli bejelentkezések. Válassza a Microsoft Authenticator alkalmazás kérésének jóváhagyása lehetőséget.

   

5. Értesítést fog kapni a telefonján. Válassza a Bejelentkezés jóváhagyása?lehetőséget.

6. Adja meg a böngésző vagy az alkalmazás képernyőjén látható számot a Microsoft Authenticatorban.

   

7. Válassza az Igen lehetőséget, és a felhasználó hitelesítheti és bejelentkezhet.

A hitelesítési kötési szabályzat ismertetése

A hitelesítési kötési szabályzat segít meghatározni a hitelesítés erősségét egytényezős vagy többtényezősként. A rendszergazda módosíthatja az alapértelmezett értéket egytényezősről többtényezősre, vagy egyéni szabályzatkonfigurációkat állíthat be a tanúsítvány kiállítói tulajdonosának vagy szabályzatazonosítójának, illetve a Kiállító és házirend OID mezőinek használatával.

Tanúsítvány erősségei

A rendszergazda meghatározhatja, hogy a tanúsítványok egytényezősek vagy többtényezősek-e. További információ: A NIST hitelesítési megbízhatósági szintjeit a Microsoft Entra hitelesítési módszereire leképező dokumentáció, amely az NIST 800-63B SP 800-63B, a Digital Identity Guidelines: Authentication and Lifecycle Mgmt szolgáltatásra épül.

Többtényezős tanúsítványhitelesítés

Ha egy felhasználó többtényezős tanúsítvánnyal rendelkezik, többtényezős hitelesítést csak tanúsítványokkal végezhet. A hitelesítési házirend Rendszergazda istratornak azonban gondoskodnia kell arról, hogy a tanúsítványok PIN-kóddal vagy biometrikus azonosítóval legyenek védve, hogy többtényezősnek minősüljenek.

Hogyan oldja fel a Microsoft Entra ID több hitelesítési szabályzatkötési szabályt?

Mivel több egyéni hitelesítési kötési házirend-szabály hozható létre különböző tanúsítványmezőkkel, például a kiállító + szabályzat OID használatával, vagy csak a Házirend OID vagy csak a kiállító használatával. Az alábbiakban a hitelesítési védelmi szint meghatározásának lépéseit követjük, ha az egyéni szabályok átfedésben vannak. Ezek a következők:

1. A kiállító és a szabályzat OID-szabályai elsőbbséget élveznek a házirend OID-szabályaival szemben. A házirend OID-szabályai elsőbbséget élveznek a tanúsítványkibocsátó szabályokkal szemben.
2. A rendszer először kiértékeli a kiállító + szabályzat OID-szabályait. Ha egyéni szabállyal rendelkezik a ca1 kiállítóval és az OID 1.2.3.4.5 szabályzattal MFA-val, akkor csak az A tanúsítvány felel meg a kiállítói értéknek és a szabályzat OID-nak is.
3. Ezután a rendszer kiértékeli a szabályzatazonosítókat használó egyéni szabályokat. Ha rendelkezik egy OID 1.2.3.4.5 szabályzattal rendelkező A tanúsítvánnyal és az ezen a tanúsítványon alapuló származtatott B hitelesítő adatokkal, az OID 1.2.3.4.5.6 szabályzattal rendelkezik, és az egyéni szabály az 1.2.3.4.5-ös MFA értékkel rendelkező Házirend OID-ként van definiálva, csak az A tanúsítvány felel meg az MFA-nak, a hitelesítő adatok B pedig csak egytényezős hitelesítést tesznek eleget. Ha a felhasználó származtatott hitelesítő adatokat használt a bejelentkezés során, és MFA használatára lett konfigurálva, a rendszer egy második tényezőt kér a sikeres hitelesítéshez.
4. Ha ütközés van több házirend-azonosító között (például ha egy tanúsítvány két házirend-azonosítóval rendelkezik, ahol az egyik egytényezős hitelesítéshez, a másik pedig az MFA-hoz kötődik), akkor kezelje a tanúsítványt egytényezős hitelesítésként.
5. Ezután a rendszer kiértékeli a kiállító hitelesítésszolgáltatóját használó egyéni szabályokat.
6. Ha egy tanúsítványnak a házirend OID és a Kiállító szabályai is egyeznek, a rendszer mindig a házirend-objektumazonosítót ellenőrzi először, és ha nem található szabályzatszabály, akkor a rendszer ellenőrzi a kiállító kötéseit. A házirend-OID magasabb erős hitelesítési kötési prioritással rendelkezik, mint a kiállító.
7. Ha egy hitelesítésszolgáltató kapcsolódik az MFA-hoz, a hitelesítésszolgáltató által kibocsátott összes felhasználói tanúsítvány MFA-nak minősül. Ugyanez a logika vonatkozik az egytényezős hitelesítésre is.
8. Ha egy házirend-OID az MFA-hoz kötődik, az összes olyan felhasználói tanúsítvány, amely ezt a házirend-OID-ot az OID-k egyikeként tartalmazza (egy felhasználói tanúsítvány több szabályzatazonosítóval is rendelkezhet) MFA-nak minősül.
9. Egy tanúsítványkibocsátó csak egy érvényes erős hitelesítési kötéssel rendelkezhet (vagyis a tanúsítvány nem tud egytényezős és MFA-hoz is kapcsolódni).

Fontos

Van egy ismert probléma, amely miatt az Entra-bérlő rendszergazdája egy CBA hitelesítési házirendszabályt konfigurál a Kiállító és a Szabályzat OID használatával, hatással van néhány eszközregisztrációs forgatókönyvre, például:

• Vállalati Windows Hello-regisztráció
• Fido2 biztonsági kulcs regisztrációja
• Windows jelszó nélküli Telefon bejelentkezés

Az eszközregisztráció a Munkahelyi csatlakozás, az Entra ID és a hibrid Entra ID eszközillesztés forgatókönyvekre nem lesz hatással. A CBA hitelesítési házirendjének a kibocsátó vagy a házirend OID azonosítóját használó szabályai nem lesznek hatással. A mérséklés érdekében a rendszergazdáknak a következőkkel kell rendelkeznie:

• Szerkessze a tanúsítványalapú hitelesítési házirendszabályokat jelenleg a Kiállító és a Házirend OID beállításaival, és távolítsa el a Kiállító vagy az OID követelményt, és mentse őket. VAGY
• Távolítsa el a hitelesítési házirend szabályát jelenleg a Kiállító és a Házirend OID használatával, és hozzon létre szabályokat csak a kiállító vagy a szabályzat OID használatával

Dolgozunk a probléma megoldásán.

A felhasználónév-kötési szabályzat ismertetése

A felhasználónév-kötési szabályzat segít ellenőrizni a felhasználó tanúsítványát. Alapértelmezés szerint a tanúsítvány tulajdonosi másodlagos neve (SAN) egyszerű neve a felhasználói objektum UserPrincipalName attribútumára van leképezve a felhasználó meghatározásához.

Nagyobb biztonság elérése tanúsítványkötésekkel

A tanúsítványkötések esetében hét támogatott módszer létezik. A leképezési típusok általában nagy affinitásnak minősülnek, ha olyan azonosítókon alapulnak, amelyeket nem lehet újra felhasználni, például a tárgykulcs-azonosítókat vagy az SHA1 nyilvános kulcsot. Ezek az azonosítók nagyobb biztosítékot nyújtanak arra, hogy csak egyetlen tanúsítvány használható a megfelelő felhasználó hitelesítéséhez.

A felhasználónevek és e-mail-címek alapján történő leképezési típusok alacsony affinitásnak minősülnek. A Microsoft Entra ID három olyan leképezést valósít meg, amelyeket az újrahasználható azonosítók alapján alacsony affinitásúnak tekintenek. A többit nagy affinitású kötésnek tekintik. További információ: certificateUserIds.

Tanúsítványleképezési mező	Példák a certificateUserIds értékeire	Felhasználói objektumattribútumok	Típus
Egyszerű név	X509:<PN>bob@woodgrove.com	userPrincipalName onPremisesUserPrincipalName certificateUserIds	alacsony affinitás
RFC822Name	X509:<RFC822>user@woodgrove.com	userPrincipalName onPremisesUserPrincipalName certificateUserIds	alacsony affinitás
IssuerAndSubject (előzetes verzió)	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	certificateUserIds	alacsony affinitás
Tárgy (előzetes verzió)	X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	certificateUserIds	alacsony affinitás
SKI	X509:<SKI>123456789abcdef	certificateUserIds	nagy affinitás
SHA1PublicKey	X509:<SHA1-PUKEY>123456789abcdef	certificateUserIds	nagy affinitás
IssuerAndSerialNumber (előzetes verzió)	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48 A sorozatszám helyes értékének lekéréséhez futtassa ezt a parancsot, és tárolja a CertificateUserIdsben látható értéket: Szintaxis: Certutil –dump –v [~certificate path~] >> [~dumpFile path~] Példa: certutil -dump -v firstusercert.cer >> firstCertDump.txt	certificateUserIds	nagy affinitás

Affinitási kötés definiálása bérlői szinten, felülbírálás egyéni szabályokkal (előzetes verzió)

Ezzel a szolgáltatással a hitelesítési házirend Rendszergazda istrator konfigurálhatja, hogy a felhasználó hitelesítése alacsony affinitású vagy nagy affinitású felhasználónév-kötés-leképezéssel végezhető-e el. Beállíthat kötelező affinitási kötést a bérlőhöz, amely minden felhasználóra érvényes. Felülbírálhatja a bérlőre vonatkozó alapértelmezett értéket is, ha egyéni szabályokat hoz létre a Kiállító és házirend OID, a Házirend OID vagy a Kiállító alapján.

Hogyan oldja fel a Microsoft Entra ID több felhasználónév-szabályzat kötési szabályát?

Használja a legmagasabb prioritású (legalacsonyabb szám) kötést.

1. Keresse meg a felhasználói objektumot a felhasználónév vagy a felhasználónév használatával.
2. Kérje le a bérlői rendszergazda által beállított összes felhasználónév-kötés listáját a CBA hitelesítési módszer konfigurációjában, amelyet a "priority" attribútum rendez. A prioritás fogalma ma nem érhető el a Portal UX-ben. A Graph az egyes kötések prioritási attribútumát adja vissza, és azokat a kiértékelési folyamat során használják.
3. Ha a bérlő nagy affinitású kötéssel rendelkezik, vagy ha a tanúsítvány értéke megfelel a nagy affinitást igénylő egyéni szabálynak, távolítsa el az összes alacsony affinitású kötést a listából.
4. Értékelje ki a listában szereplő összes kötést, amíg sikeres hitelesítés nem történik.
5. Ha a konfigurált kötés X.509 tanúsítványmezője a bemutatott tanúsítványon van, a Microsoft Entra ID a tanúsítványmezőben szereplő értéket a felhasználói objektum attribútumértékével egyezik meg.
   1. Ha talál egyezést, a felhasználói hitelesítés sikeres.
   2. Ha nem talál egyezést, lépjen a következő prioritási kötésre.
6. Ha az X.509 tanúsítványmező nem szerepel a bemutatott tanúsítványon, lépjen a következő prioritási kötésre.
7. Ellenőrizze az összes konfigurált felhasználónév-kötést, amíg az egyik egyezést nem eredményez, és a felhasználói hitelesítés sikeres lesz.
8. Ha egyik konfigurált felhasználónév-kötésen sem található egyezés, a felhasználói hitelesítés meghiúsul.

A Microsoft Entra konfigurációjának védelme több felhasználónév-kötéssel

A Microsoft Entra felhasználói objektum attribútumai (userPrincipalName, onPremiseUserPrincipalName, certificateUserIds) mindegyike, amely a Tanúsítványok Microsoft Entra felhasználói fiókokhoz való kötéséhez érhető el, egyedi korlátozással rendelkezik, hogy a tanúsítvány csak egyetlen Microsoft Entra-felhasználói fiókkal egyezzen. A Microsoft Entra CBA azonban több kötési módszert is támogat a felhasználónév-kötési szabályzatban, amely lehetővé teszi, hogy a rendszergazda egy tanúsítványt több Entra-felhasználói fiók konfigurációjához is elférjen.

Fontos

Ha több kötést konfigurál, a Microsoft Entra CBA-hitelesítés csak olyan biztonságos, mint a legalacsonyabb affinitási kötés, mivel a CBA ellenőrzi az egyes kötéseket a felhasználó hitelesítéséhez. Ha meg szeretné akadályozni, hogy egyetlen tanúsítvány több Microsoft Entra-fiókkal egyezzen, a hitelesítési házirend Rendszergazda istrator a következőt teheti:

• Konfiguráljon egyetlen kötési módszert a felhasználónév-kötési szabályzatban.
• Ha egy bérlő több kötési metódussal rendelkezik, és nem szeretné engedélyezni, hogy egy tanúsítvány több fiókhoz legyen megfeleltetve, a hitelesítési házirend Rendszergazda istratornak biztosítania kell, hogy a szabályzattérképen konfigurált összes engedélyezett metódus ugyanarra a Microsoft Entra-fiókra legyen konfigurálva. Minden felhasználói fióknak az összes kötésnek megfelelő értékekkel kell rendelkeznie.
• Ha egy bérlő több kötési módszert is konfigurált, a hitelesítési házirend Rendszergazda istratornak meg kell győződnie arról, hogy nem rendelkezik több alacsony affinitású kötéssel.

Tegyük fel például, hogy a PrincipalName-en két felhasználónév-kötés van leképezve az UPN-re és a SubjectKeyIdentifierre (SKI) a certificateUserIdsre. Ha azt szeretné, hogy a tanúsítvány csak egyetlen fiókhoz legyen használva, a hitelesítési házirend Rendszergazda istratornak meg kell győződnie arról, hogy a fiók rendelkezik a tanúsítványban található UPN-vel, és implementálja a SKI-leképezést ugyanazon fiók certificateUserId attribútumában.

Több tanúsítvány támogatása egy Entra felhasználói fiókkal (M:1)

Vannak olyan esetek, amikor egy szervezet több tanúsítványt ad ki egyetlen identitáshoz. Ez leggyakrabban egy mobileszköz származtatott hitelesítő adata lehet, vagy lehet egy másodlagos intelligenskártya- vagy x509 hitelesítőadat-tulajdonosi képességű eszköz, például a Yubikey esetében is.

Csak felhőalapú fiókok Csak felhőalapú fiókokhoz több tanúsítványt (legfeljebb 5) képezhet le a használatra a certificateUserIds mező (Engedélyezési adatok a felhasználói portálon) feltöltésével az egyes tanúsítványokat azonosító egyedi értékekkel. Ha a szervezet nagy affinitású kötéseket használ, például Kiállító + SerialNumber, a CertificateUserIds értékei a következőnek tűnhetnek:

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>c11154138u089b48767212a86cd0ef76

Ebben a példában az első érték az X509Certificate1 értéket, a második pedig az X509Certificate2 értéket jelöli. A felhasználó megjelenítheti bármelyik tanúsítványt a bejelentkezéskor, és ha a CBA felhasználónév-kötése a certificateUserIds mezőre mutat, hogy megkeresse az adott kötéstípust (pl. Kiállító+SerialNumber ebben a példában), a felhasználó sikeresen bejelentkezik.

Hibrid szinkronizált fiókok Szinkronizált fiókokhoz több használható tanúsítványt is leképezhet az AD AltSecurityIdentities mezőjének az egyes tanúsítványokat azonosító értékek feltöltésével. Ha a szervezet nagy affinitású (azaz erős hitelesítési) kötéseket használ, például Kiállító + SerialNumber, az alábbihoz hasonlóan nézhet ki:

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>c11154138u089b48767212a86cd0ef76

Ebben a példában az első érték az X509Certificate1 értéket, a második pedig az X509Certificate2 értéket jelöli. Ezeket az értékeket ezután szinkronizálni kell az Azure AD CertificateUserIds mezőjével.

Több Entra-felhasználói fiókkal rendelkező tanúsítvány támogatása (1:M)

Vannak olyan esetek, amikor a szervezetnek ugyanazt a tanúsítványt kell használnia a felhasználónak több identitásban való hitelesítéshez. Ez leggyakrabban rendszergazdai fiókok esetében fordul elő. Fejlesztői fiókokhoz vagy ideiglenes vámfiókokhoz is használható. A hagyományos AD-ben az altSecurityIdentities mező a tanúsítványértékek feltöltésére szolgál, a bejelentkezés során pedig egy tippet használ, amellyel az AD-t a kívánt fiókhoz irányíthatja a bejelentkezés ellenőrzéséhez. A Microsoft Entra CBA-val ez más, és nincs tipp. Ehelyett a Home Realm Discovery azonosítja a kívánt fiókot a tanúsítványértékek ellenőrzéséhez. A másik fontos különbség az, hogy a Microsoft Entra CBA a certificateUserIds mezőben kényszeríti ki az egyediséget. Ez azt jelenti, hogy két fiók nem tudja feltölteni ugyanazt a tanúsítványértéket.

Fontos

Nem túl biztonságos konfiguráció, ha ugyanazt a hitelesítő adatot használja a különböző Entra-azonosító fiókokban való hitelesítéshez, és ajánlott, hogy ne engedélyezzen egy tanúsítványt több Entra-felhasználói fiókhoz.

Csak felhőalapú fiókok A csak felhőalapú fiókokhoz több felhasználónév-kötést kell létrehoznia, és egyedi értékeket kell hozzárendelnie minden olyan felhasználói fiókhoz, amely a tanúsítványt fogja használni. A rendszer minden fiókot egy másik felhasználónév-kötéssel hitelesít. Ez egyetlen címtár/bérlő határain belül érvényes (azaz a bérlői rendszergazda leképezheti a tanúsítványt egy másik címtárban/bérlőben való használatra, feltéve, hogy az értékek fiókonként is egyediek maradnak).

Töltse ki a certificateUserIds mezőt (engedélyezési adatok a felhasználói portálon) a kívánt tanúsítványt azonosító egyedi értékkel. Ha a szervezet nagy affinitású kötéseket (azaz erős hitelesítést) használ, például Kiállító + SerialNumber és SKI kötéseket használ, az alábbihoz hasonlóan nézhet ki:

Felhasználónév-kötések:

• Kiállító + sorozatszám –> CertificateUserIds
• SKI –> CertificateUserIds

Felhasználói fiók CertificateUserIds értékei:
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523

Most, ha bármelyik felhasználó ugyanazt a tanúsítványt mutatja be bejelentkezéskor, a felhasználó sikeresen bejelentkezik, mert a fiókja megegyezik a tanúsítvány egyedi értékével. Az egyik fiók hitelesítése az Issuer+SerialNumber, a másik a SKI-kötés használatával történik.

Feljegyzés

Az ilyen módon használható fiókok számát a bérlőn konfigurált felhasználónév-kötések száma korlátozza. Ha a szervezet csak nagy affinitású kötéseket használ, a támogatott fiókok száma 3-ra lesz korlátozva. Ha a szervezet alacsony affinitási kötéseket is használ, ez a szám 7 fiókra nő (1 PrincipalName, 1 RFC822Name, 1 SubjectKeyIdentifier, 1 SHA1PublicKey, 1 Kiállító+Tárgy, 1 Kiállító+Sorozatszám, 1 Tárgy).

Hibrid szinkronizált fiókok Szinkronizált fiókok esetén a megközelítés eltérő lesz. Bár a bérlői rendszergazda egyedi értékeket képezhet le minden olyan felhasználói fiókhoz, amely a tanúsítványt fogja használni, az Entra-azonosítóban lévő összes érték feltöltésének általános gyakorlata megnehezítené ezt. Ehelyett az Azure AD Csatlakozás a fiókonkénti kívánt értékeket az Entra-azonosítóban lévő fiókba feltöltött egyedi értékekre kell szűrnie. Az egyediségi szabály egyetlen címtár/bérlő határain belül érvényes (azaz a bérlői rendszergazda leképezheti a tanúsítványt egy másik címtárban/bérlőben való használatra, feltéve, hogy az értékek fiókonként is egyediek maradnak). Emellett a szervezet több AD-erdővel is rendelkezhet, amelyek egyetlen Entra-azonosító-bérlőben járulnak hozzá a felhasználókhoz. Ebben az esetben az Azure AD Csatlakozás minden ilyen AD-erdőre alkalmazza a szűrőt ugyanazzal a céllal, hogy csak a kívánt egyedi értéket töltse fel a felhőfiókra.

Töltse ki az altSecurityIdentities mezőt az AD-ben a kívánt tanúsítványt azonosító értékekkel, és adja meg a kívánt tanúsítványértéket az adott felhasználói fióktípushoz (pl. detailee, admin, developer stb.). Válasszon egy kulcsattribútumot az AD-ben, amely közli a szinkronizálással, hogy melyik felhasználói fióktípust értékeli ki a felhasználó (például msDS-cloudExtensionAttribute1). Töltse ki ezt az attribútumot a kívánt felhasználói típusértékkel, például a detailee, a rendszergazda vagy a fejlesztő. Ha ez a felhasználó elsődleges fiókja, az érték üres/null érték marad.

A fiókok a következőképpen nézhetnek ki:

Erdő 1 – Fiók1 (bob@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

Erdő 1 – Fiók2 (bob-admin@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

Erdő 2 – ADAccount1 (bob-tdy@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

Ezeket az értékeket ezután szinkronizálni kell az Entra ID certificateUserIds mezőjével.

A certificateUserIds-sel való szinkronizálás lépései

1. Az Azure AD connect konfigurálása az alternativeSecurityIds mező metaverse-hez való hozzáadásához
2. Minden AD-erdő esetében konfiguráljon egy új egyéni bejövő szabályt magas előnénnyel (alacsony szám 100 alatt). Adjon hozzá egy kifejezésátalakítást az altSecurityIdentities mezővel forrásként. A célkifejezés a kiválasztott és kitöltött kulcsattribútumot, valamint a megadott felhasználói típusokhoz való leképezést fogja használni.
3. Példa:

IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer"))>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    Where($item,[altSecurityIdentities],(BitAnd(InStr($item, "X509:<I>"),InStrRev($item, "<SR>"))>0)), NULL) 
)

A fenti példában az altSecurityIdentities és az msDS-cloudExtensionAttribute1is kulcsattribute1is először ellenőrzi, hogy vannak-e feltöltve. Ha nem, akkor az altSecurityIdentities jelölőnégyzet bejelölve ellenőrzi, hogy ki van-e töltve. Ha üres, akkor NULL értékre állítjuk. Ellenkező esetben a fiók az alapértelmezett esetbe tartozik, és ebben a példában csak a Kiállító+SerialNumber leképezésre szűrünk. Ha a kulcsattribútum fel van töltve, akkor a rendszer ellenőrzi, hogy az értéke megegyezik-e az egyik definiált felhasználói típusunkkal. Ebben a példában, ha ez az érték detailee, akkor az altSecurityIdentities sha1PublicKey értékére szűrünk. Ha az érték fejlesztő, akkor az altSecurityIdentities subjectKeyIssuer értékére szűrünk. Egy adott típusú tanúsítványérték több is lehet. Például több PrincipalName vagy több SKI vagy SHA1-PUKEY érték. A szűrő lekéri az összes értéket, és szinkronizálja az Entra-azonosítót – nem csak az elsőt, amit talál.

1. Egy második példa, amely bemutatja, hogyan küldhet le üres értéket, ha a vezérlőattribútum üres.

IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer")>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    AuthoritativeNull, NULL) 
) 

Ha az altSecurityIdentities értéke nem egyezik a vezérlőattribútum egyik keresési értékével sem, akkor a rendszer egy Mérvadónull értéket ad át. Ez biztosítja, hogy az alternativeSecurityId azonosítót tartalmazó korábbi vagy későbbi szabályok figyelmen kívül legyenek hagyva, és az eredmény üres legyen az Entra-azonosítóban.

1. Konfiguráljon egy új, alacsony elsőbbséget élvező egyéni kimenő szabályt (magas szám 160 felett – a lista alján).
2. Adjon hozzá egy közvetlen átalakítást az alternativeSecurityIds mezővel forrásként, célként pedig a certificateUserIds mezőt.
3. Futtasson egy szinkronizálási ciklust az Entra-azonosítóban lévő adatok sokaságának befejezéséhez.

Győződjön meg arról, hogy a CBA minden bérlőben konfigurálva van a tanúsítványból leképezett mezőtípusok certificateUserIds mezőjére mutató felhasználónév-kötésekkel. Most bármelyik felhasználó megjelenítheti a tanúsítványt bejelentkezéskor, és miután a tanúsítvány egyedi értékét a certificateUserIds mezőn érvényesítette, a felhasználó sikeresen bejelentkezett lesz.

A tanúsítvány-visszavonási folyamat ismertetése

A tanúsítvány-visszavonási folyamat lehetővé teszi, hogy a rendszergazda visszavonjon egy korábban kiadott tanúsítványt a későbbi hitelesítéshez való használatból. A tanúsítvány visszavonása nem vonja vissza a felhasználó már kiadott jogkivonatait. Kövesse a lépéseket a jogkivonatok manuális visszavonásához a visszavonás konfigurálásakor.

A Microsoft Entra ID letölti és gyorsítótárazza az ügyfelek tanúsítvány-visszavonási listáját (CRL) a hitelesítésszolgáltatótól, hogy ellenőrizze, visszavonták-e a tanúsítványokat a felhasználó hitelesítése során.

A rendszergazda konfigurálhatja a CRL terjesztési pontot a Microsoft Entra-bérlő megbízható kiállítóinak beállítási folyamata során. Minden megbízható kiállítónak rendelkeznie kell egy CRL-sel, amely internetes URL-cím használatával hivatkozható.

Fontos

Az interaktív bejelentkezésre és gyorsítótárra való sikeres letöltéshez szükséges CRL maximális mérete 20 MB a nyilvános Entra-azonosítóban és 45 MB az Azure US Government-felhőkben, és a CRL letöltéséhez szükséges idő nem haladhatja meg a 10 másodpercet. Ha a Microsoft Entra-azonosító nem tudja letölteni a CRL-t, a tanúsítványalapú hitelesítések a megfelelő hitelesítésszolgáltató által kibocsátott tanúsítványokkal meghiúsulnak. Ajánlott eljárás a CRL-fájlok méretkorláton belüli megtartásához, a tanúsítvány élettartamának ésszerű korlátokon belüli megtartásához és a lejárt tanúsítványok törléséhez. További információ: Van-e korlát a CRL-méretre vonatkozóan?

Ha egy felhasználó egy tanúsítvánnyal végez interaktív bejelentkezést, és a CRL túllépi a felhő interaktív korlátját, a kezdeti bejelentkezés a következő hibával meghiúsul:

"A(z) {uri} fájlból letöltött visszavont tanúsítványok listája (CRL) túllépte a Microsoft Entra-azonosítóban lévő CRL-ek maximális megengedett méretét ({size} bájt). Próbálkozzon újra néhány perc múlva. Ha a probléma továbbra is fennáll, forduljon a bérlő rendszergazdáihoz."

A hiba után a Microsoft Entra ID megpróbálja letölteni a crl-t a szolgáltatásoldali korlátoknak megfelelően (45 MB a nyilvános Entra-azonosítóban és 150 MB az Azure US Government-felhőkben).

Fontos

Ha a rendszergazda kihagyja a CRL konfigurációját, a Microsoft Entra-azonosító nem végez CRL-ellenőrzéseket a felhasználó tanúsítványalapú hitelesítése során. Ez hasznos lehet a kezdeti hibaelhárításhoz, de éles használat esetén nem érdemes figyelembe venni.

Egyelőre teljesítmény- és megbízhatósági okokból nem támogatjuk az Online Tanúsítványállapot Protokollt (OCSP). Ahelyett, hogy az OCSP ügyfélböngészője minden kapcsolatnál letölti a CRL-t, a Microsoft Entra ID az első bejelentkezéskor egyszer letölti és gyorsítótárazza azt, ezáltal javítva a CRL-ellenőrzés teljesítményét és megbízhatóságát. A gyorsítótárat is indexeljük, így a keresés minden alkalommal sokkal gyorsabb. Az ügyfeleknek közzé kell tenni a visszavont tanúsítványok crls-eit.

Az alábbi lépések a CRL-ellenőrzés tipikus folyamatai:

1. A Microsoft Entra ID az első bejelentkezéskor megkísérli letölteni a CRL-t, ha bármely felhasználó rendelkezik a megfelelő megbízható kiállító vagy hitelesítésszolgáltató tanúsítványával.
2. A Microsoft Entra ID gyorsítótárazza és újra felhasználja a CRL-t minden további használathoz. A következő frissítési dátumot, és ha rendelkezésre áll, a következő CRL-közzétételi dátumot (amelyet a Windows Server hitelesítésszolgáltatók használnak) a CRL-dokumentumban.
3. A felhasználói tanúsítványalapú hitelesítés meghiúsul, ha:

   • A crL-t a megbízható kiállítóhoz konfigurálták, és a Microsoft Entra-azonosító nem tudja letölteni a CRL-t a rendelkezésre állási, méret- vagy késési korlátozások miatt.

   • A felhasználó tanúsítványa visszavontként szerepel a CRL-ben.

     

   • A Microsoft Entra ID megpróbál letölteni egy új CRL-t a terjesztési pontról, ha a gyorsítótárazott CRL-dokumentum lejárt.

Feljegyzés

A Microsoft Entra-azonosító ellenőrzi a kiállító hitelesítésszolgáltató és a PKI megbízhatósági láncában lévő egyéb hitelesítésszolgáltatók crl-ját a legfelső szintű hitelesítésszolgáltatóig. A levél ügyféltanúsítványából legfeljebb 10 hitelesítésszolgáltatói korlát áll rendelkezésére a PKI-lánc CRL-hitelesítéséhez. A korlátozás annak biztosítása, hogy egy rossz szereplő ne állítsa le a szolgáltatást egy olyan PKI-lánc feltöltésével, amely nagy számú hitelesítésszolgáltatóval rendelkezik nagyobb CRL-mérettel. Ha a bérlő PKI-lánca több mint 5 hitelesítésszolgáltatóval rendelkezik, és hitelesítésszolgáltatói kompromisszum esetén a rendszergazdának el kell távolítania a feltört megbízható kiállítót a Microsoft Entra-bérlő konfigurációjából.

Fontos

A CRL-gyorsítótárazási és közzétételi ciklusok jellegéből adódóan erősen ajánlott a tanúsítvány visszavonása esetén, hogy az érintett felhasználó összes munkamenetét is visszavonja a Microsoft Entra-azonosítóban.

Egyelőre nincs mód arra, hogy manuálisan kényszerítse vagy próbálkozzon újra a CRL letöltésével.

Visszavonás konfigurálása

Az ügyféltanúsítvány visszavonásához a Microsoft Entra ID lekéri a tanúsítvány-visszavonási listát (CRL) a hitelesítésszolgáltató adatainak részeként feltöltött URL-címekről, és gyorsítótárazza azt. A CRL utolsó közzétételi időbélyege (Effective Date tulajdonság) annak ellenőrzésére szolgál, hogy a CRL továbbra is érvényes-e. A CRL-ra rendszeres időközönként hivatkozunk a lista részét képező tanúsítványokhoz való hozzáférés visszavonásához.

Ha azonnali visszavonásra van szükség (például ha egy felhasználó elveszíti az eszközt), a felhasználó engedélyezési jogkivonata érvényteleníthető. Az engedélyezési jogkivonat érvénytelenítéséhez állítsa be az adott felhasználó StsRefreshTokenValidFrom mezőjét a Windows PowerShell használatával. Frissítenie kell a StsRefreshTokenValidFrom mezőt minden olyan felhasználóhoz, akihez vissza szeretné vonni a hozzáférést.

Annak érdekében, hogy a visszavonás továbbra is megmaradjon, a visszavont tanúsítványok érvényes dátumát a StsRefreshTokenValidFrom által beállított érték utáni dátumra kell állítania , és győződjön meg arról, hogy a szóban forgó tanúsítvány szerepel a CRL-ben.

Feljegyzés

Az Azure AD- és MSOnline PowerShell-modulok 2024. március 30-ától elavultak. További információkért olvassa el az elavulás frissítését. Ezen dátum után ezeknek a moduloknak a támogatása a Microsoft Graph PowerShell SDK-ra való migrálásra és a biztonsági javításokra korlátozódik. Az elavult modulok 2025. március 30-ától működnek tovább.

Javasoljuk, hogy migráljon a Microsoft Graph PowerShellbe a Microsoft Entra ID (korábbi nevén Azure AD) használatához. Gyakori migrálási kérdésekért tekintse meg a migrálással kapcsolatos gyakori kérdéseket. Megjegyzés: Az MSOnline 1.0.x verziói 2024. június 30. után fennakadást tapasztalhatnak.

Az alábbi lépések az engedélyezési jogkivonat frissítésének és érvénytelenítésének folyamatát ismertetik a StsRefreshTokenValidFrom mező beállításával.

1. Csatlakozás a PowerShellhez:

   Connect-MgGraph
   

2. A felhasználó aktuális StsRefreshTokensValidFrom értékének lekérése:

           $user = Get-MsolUser -UserPrincipalName test@yourdomain.com`
           $user.StsRefreshTokensValidFrom
   

3. Konfiguráljon egy új StsRefreshTokensValidFrom értéket a felhasználó számára, amely megegyezik az aktuális időbélyegzővel:

           Set-MsolUser -UserPrincipalName test@yourdomain.com -StsRefreshTokensValidFrom ("03/05/2021")
   

A megadott dátumnak a jövőben kell lennie. Ha a dátum nem a jövőben van megadva, a StsRefreshTokensValidFrom tulajdonság nincs beállítva. Ha a dátum a jövőben van, a StsRefreshTokensValidFrom az aktuális időpontra van állítva (nem a Set-MsolUser parancs által jelzett dátumra).

A CBA működése feltételes hozzáférési hitelesítési erősségű szabályzattal

Az ügyfelek létrehozhatnak egy feltételes hozzáférési hitelesítési erősségű szabályzatot, amely meghatározza, hogy a CBA-t egy erőforrás eléréséhez kell-e használni.

Az adathalászatnak ellenálló MFA-hitelesítés beépített erősségét használhatja. Ez a szabályzat csak az adathalászatnak ellenálló hitelesítési módszereket engedélyezi, például a CBA-t, a FIDO2 biztonsági kulcsokat és a Vállalati Windows Hello.

Egyéni hitelesítési erősséget is létrehozhat, amely lehetővé teszi, hogy csak a CBA férhessen hozzá a bizalmas erőforrásokhoz. Engedélyezheti a CBA-t egytényezős, többtényezős vagy mindkettőként. További információ: Feltételes hozzáférés hitelesítésének erőssége.

CBA-hitelesítés erőssége speciális beállításokkal

A CBA hitelesítési módszerek házirendjében a rendszergazda a hitelesítés kötési szabályzatának használatával meghatározhatja a tanúsítvány erősségét a CBA-metóduson. Most már konfigurálhatja a speciális beállításokat , amikor egyéni hitelesítési erősséget hoz létre, hogy egy adott tanúsítványt kell használni a kiállító és a szabályzat azonosítói alapján, amikor a felhasználók CBA-t végeznek bizonyos bizalmas erőforrások eléréséhez. Ez a funkció pontosabb konfigurációt biztosít az erőforrásokhoz hozzáférő tanúsítványok és felhasználók meghatározásához. További információ: Speciális beállítások a feltételes hozzáférés hitelesítésének erősségéhez.

A bejelentkezési naplók ismertetése

A bejelentkezési naplók információt nyújtanak a bejelentkezésekről, valamint arról, hogy a felhasználók hogyan használják az erőforrásokat. A bejelentkezési naplókról további információt a Microsoft Entra ID bejelentkezési naplóiban talál.

Tekintsünk át két forgatókönyvet, az egyikben a tanúsítvány egytényezős hitelesítést, a másikat pedig az MFA-nak megfelelő tanúsítványt.

A tesztforgatókönyvek esetében válasszon egy feltételes hozzáférési szabályzattal rendelkező felhasználót, amely MFA-t igényel. Konfigurálja a felhasználói kötési szabályzatot úgy, hogy leképezi a san principal name to UserPrincipalName nevet.

A felhasználói tanúsítványt az alábbi képernyőképhez hasonlóan kell konfigurálni:

A bejelentkezési naplók dinamikus változóival kapcsolatos bejelentkezési problémák elhárítása

Bár a bejelentkezési naplók minden információt megadnak a felhasználó bejelentkezési problémáinak hibakereséséhez, vannak olyan időszakok, amikor bizonyos értékekre van szükség, és mivel a bejelentkezési naplók nem támogatják a dinamikus változókat, a bejelentkezési naplókban hiányoznak az információk. Például: A bejelentkezési naplóban a hiba oka a következőhöz hasonlót mutat: "A visszavont tanúsítványok listája (CRL) sikertelen aláírás-ellenőrzés. A várt tulajdonoskulcs-azonosító ({expectedSKI} nem egyezik a CRL-szolgáltató {crlAK} kulcsának azonosítóval). Kérje meg a bérlői rendszergazdát, hogy ellenőrizze a CRL-konfigurációt." ahol a(z) {expectedSKI} és a {crlAKI} nem megfelelő értékekkel van feltöltve.

Ha a CBA-val való bejelentkezés sikertelen, másolja a napló adatait a hibalap További részletek hivatkozására. Részletesebb információkért tekintse meg a CBA hibaoldalának megértését

Egytényezős hitelesítés tesztelése

Az első tesztforgatókönyvben konfigurálja azt a hitelesítési házirendet, amelyben a kiállító tárgyszabálya megfelel az egytényezős hitelesítésnek.

1. Jelentkezzen be a Microsoft Entra felügyeleti központba tesztfelhasználóként a CBA használatával. A hitelesítési szabályzatot az adja meg, ahol a kiállító tárgyszabálya megfelel az egytényezős hitelesítésnek.

2. Keresse meg és válassza ki a bejelentkezési naplókat.

   Tekintsük át közelebbről a bejelentkezési naplókban található bejegyzéseket.

   Az első bejegyzés az X.509-tanúsítványt kéri le a felhasználótól. Az állapot megszakadása azt jelenti, hogy a Microsoft Entra-azonosító ellenőrzi, hogy a CBA engedélyezve van-e a bérlőben, és a rendszer tanúsítványt kér a hitelesítéshez.

   

   A tevékenység részletei azt mutatják, hogy ez csak egy része a várt bejelentkezési folyamatnak, amelyben a felhasználó kiválaszt egy tanúsítványt.

   

   A további részletek a tanúsítvány adatait jelenítik meg.

   

   Ezek a további bejegyzések azt mutatják, hogy a hitelesítés befejeződött, a rendszer visszaküld egy elsődleges frissítési jogkivonatot a böngészőnek, és a felhasználó hozzáférést kap az erőforráshoz.

   

Többtényezős hitelesítés tesztelése

A következő tesztforgatókönyvben konfigurálja azt a hitelesítési házirendet, amelyben a policyOID-szabály megfelel a többtényezős hitelesítésnek.

1. Jelentkezzen be a Microsoft Entra felügyeleti központba a CBA használatával. Mivel a szabályzat többtényezős hitelesítésre lett beállítva, a felhasználói bejelentkezés második tényező nélkül sikeres.

2. Keresse meg és válassza ki a bejelentkezéseket.

   A bejelentkezési naplókban több bejegyzés is megjelenik, köztük egy megszakított állapotú bejegyzés.

   

   A tevékenység részletei azt mutatják, hogy ez csak egy része a várt bejelentkezési folyamatnak, amelyben a felhasználó kiválaszt egy tanúsítványt.

   

   A Megszakított állapotú bejegyzés további diagnosztikai információkat tartalmaz a További részletek lapon.

   

   Az alábbi táblázat az egyes mezők leírását tartalmazza.

   Mező	Leírás
   Felhasználótanúsítvány tulajdonosának neve	A tanúsítvány tulajdonosnév mezőjére hivatkozik.
   Felhasználói tanúsítvány kötése	Tanúsítvány: Egyszerű név; Felhasználói attribútum: userPrincipalName; Rang: 1 Ez azt mutatja, hogy melyik SAN PrincipalName tanúsítványmező lett a userPrincipalName felhasználói attribútumhoz rendelve, és az 1. prioritás volt.
   Felhasználói tanúsítvány hitelesítési szintje	multiFactorAuthentication
   Felhasználótanúsítvány-hitelesítési szint típusa	PolicyId Ez azt mutatja, hogy a házirend OID-ját használták a hitelesítés erősségének meghatározására.
   Felhasználói tanúsítvány hitelesítési szintjének azonosítója	1.2.3.4 Ez a tanúsítvány azonosítóházirendjének OID értékét jeleníti meg.

A tanúsítványalapú hitelesítési hibalap ismertetése

A tanúsítványalapú hitelesítés meghiúsulhat olyan okok miatt, mint például a tanúsítvány érvénytelensége, vagy a felhasználó rossz tanúsítványt vagy lejárt tanúsítványt választott, vagy a visszavont tanúsítványok listája (CRL) hibája miatt. Ha a tanúsítvány érvényesítése sikertelen, a felhasználó a következő hibaüzenetet látja:

Ha a CBA meghiúsul egy böngészőben, még akkor is, ha a hiba a tanúsítványválasztó megszakítása miatt van, be kell zárnia a böngésző munkamenetét, és meg kell nyitnia egy új munkamenetet a CBA ismételt kipróbálásához. Új munkamenetre van szükség, mert a böngészők gyorsítótárazják a tanúsítványt. A CBA újrapróbálkozásakor a böngésző elküldi a gyorsítótárazott tanúsítványt a TLS-kihívás során, ami bejelentkezési hibát és érvényesítési hibát okoz.

A További részletek lehetőséget választva olyan naplózási információkat kaphat, amelyeket elküldhet egy rendszergazdának, aki pedig további információkat kaphat a bejelentkezési naplókból.

A bejelentkezés egyéb módjai lehetőséget választva más, a felhasználó számára elérhető módszereket is kipróbálhat.

Feljegyzés

Ha újra megkísérli a CBA-t egy böngészőben, az továbbra is meghiúsul a böngésző gyorsítótárazási hibája miatt. A felhasználóknak meg kell nyitniuk egy új böngésző munkamenetet, és újra be kell jelentkezni.

Tanúsítványalapú hitelesítés a MostRecentlyUsed (MRU) metódusokban

Miután egy felhasználó sikeresen hitelesítést végzett a CBA használatával, a felhasználó MostRecentlyUsed (MRU) hitelesítési módszere CBA-ra van állítva. Következő alkalommal, amikor a felhasználó beírja az UPN-et, és a Tovább lehetőséget választja, a rendszer közvetlenül a CBA-metódusra viszi a felhasználót, és nem kell a Tanúsítvány vagy intelligens kártya használata lehetőséget választania.

Az MRU-metódus alaphelyzetbe állításához a felhasználónak le kell mondania a tanúsítványválasztót, ki kell választania a bejelentkezés egyéb módjait, és ki kell választania egy másik, a felhasználó számára elérhető módszert, és sikeresen hitelesítenie kell magát.

Külső identitás támogatása

Egy külső identitás nem tud többtényezős hitelesítést végezni az erőforrás-bérlőn a Microsoft Entra CBA-val. Ehelyett állítsa be az MFA-t a felhasználónak a CBA használatával az otthoni bérlőben, és állítson be bérlők közötti beállításokat az erőforrás-bérlő számára, hogy megbízzanak az otthoni bérlő MFA-jában.

A többtényezős megbízhatósági hitelesítés Microsoft Entra-bérlőktől való engedélyezéséről további információt a B2B-együttműködés bérlők közötti hozzáférésének konfigurálása című témakörben talál.

Következő lépések

• A Microsoft Entra CBA áttekintése
• A Microsoft Entra CBA konfigurálása
• Microsoft Entra CBA iOS-eszközökön
• Microsoft Entra CBA Android-eszközökön
• Windows intelligenskártya-bejelentkezés a Microsoft Entra CBA használatával
• Tanúsítványfelhasználói azonosítók
• Összevont felhasználók migrálása
• Gyakori kérdések
• A Microsoft Entra CBA hibaelhárítása