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.

Az alábbiakban a következő lépéseket kell elvégezni:

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 engedélyezhetem a Microsoft Entra CBA-t?

   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 a telefonos bejelentkezést vagy a 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álasztotta, a rendszer átirányítja az ügyfelet a tanúsítványvégpontra, amely a nyilvános Microsoft 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ím esetén is működik a kiadó 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 nem engedélyezett a hozzáférés, a tanúsítványalapú hitelesítés meghiúsul, ha engedélyezi a kiállítói útmutatásokat.

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.

   

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. Az elsődleges frissítési jogkivonat visszaküldésével a Microsoft Entra ID befejezi a bejelentkezési folyamatot, jelezve a sikeres bejelentkezést.

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

A kibocsátói tippek ismertetése (előzetes)

A kiállítói utalások a TLS-kézfogás részeként megbízható hitelesítésszolgáltatói jelzést küldenek vissza. A megbízható hitelesítésszolgáltatói listát a bérlő által az Entra hitelesítéstarolóban feltöltött hitelesítésszolgáltatók (CA-k) határozzák meg. A böngészőügyfél vagy a natív alkalmazásügyfél a kiszolgáló által küldött tippek segítségével szűrheti a tanúsítványválasztóban látható tanúsítványokat. Az ügyfél csak azokat a hitelesítési tanúsítványokat jeleníti meg, amelyeket a hitelesítésszolgáltatók állítottak ki a megbízhatósági tárolóban.

Kibocsátói javaslatok engedélyezése

Ha engedélyezni szeretné, jelölje be a Kiállítói tippek jelölőnégyzetet. A hitelesítési házirend-alkalmazóknak a Tudomásul veszem lehetőséget kell választaniuk, miután meggyőződnek arról, hogy a TLS-ellenőrzéssel rendelkező proxy megfelelően frissült, és mentse el.

Feljegyzés

Ha a szervezet tűzfalakkal vagy proxykkal rendelkezik, amelyek TLS-forgalom ellenőrzését végzik, tudomásul veszi, hogy letiltotta a certauth végpont TLS-vizsgálatát, amely képes bármilyen név egyeztetésére a [*.]certauth.login.microsoftonline.com alatt, és amelyet a használt proxy alapján testre szabtak.

Feljegyzés

A hitelesítésszolgáltató URL-címe formátuma t{tenantId}.certauth.login.microsoftonline.com lesz, miután a kiállítói utasításokat engedélyezik.

A CA megbízhatósági tároló frissítéseinek terjedése

Miután engedélyezte a kiállítói tippeket, és hozzáadott, frissített vagy törölt hitelesítésszolgáltatókat a megbízhatósági állapotban, akár 10 perc is eltelhet, amíg a kiállítói tippek eljutnak az ügyfélhez. A felhasználók nem hitelesíthetik magukat az új tanúsítványhitelesítő hatóságok által kibocsátott tanúsítványokkal, amíg az információk propagálása meg nem történik.

A hitelesítési házirend rendszergazdáinak egy tanúsítvánnyal kell bejelentkezniük, miután engedélyezik a kiállítói tippeket a propagálás elindításához. A felhasználók a következő hibaüzenetet látják, ha a hitelesítésszolgáltató megbízhatósági tárolójának frissítései propagálása folyamatban van.

MFA egytényezős tanúsítványalapú hitelesítéssel

A Microsoft Entra CBA a hitelesítés első és második tényezőjeként is támogatott. A támogatott kombinációk némelyike a következő:

1. CBA (első tényező) és hozzáférési kulcsok (második tényező)
2. CBA (első tényező) és jelszó nélküli telefonos bejelentkezés (második tényező)
3. CBA (első tényező) és FIDO2 biztonsági kulcsok (második tényező)
4. Jelszó (első tényező) + CBA (második tényező) (előzetes verzió)

Feljegyzés

Az iOS második tényezőjeként a CBA ismert problémákkal rendelkezik, és blokkolva van az iOS-en. Dolgozunk a problémák megoldásán, és támogatni kell az iOS-en.

A Microsoft Entra CBA-val való bejelentkezéshez a felhasználóknak módot kell adni az MFA beszerzésére és a jelszó nélküli bejelentkezés vagy a FIDO2 regisztrálására.

Fontos

A felhasználó akkor tekinthető MFA-kompatibilisnek, ha szerepel 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.

Az MFA-képesség egytényezős tanúsítványokkal való beszerzésének lehetőségei

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. Az egytényezős tanúsítvánnyal rendelkező felhasználónak egy másik tényezőre van szüksége az MFA elvégzéséhez, ezért nem engedélyezzük más módszerek regisztrálását az MFA kielégítése nélkül. Ha a felhasználó nem rendelkezik más regisztrált MFA hitelesítési módszerrel, és bekerül a CBA hitelesítési módszer hatókörébe, a felhasználó nem tudja igazolni, hogy regisztráljon más hitelesítési módszereket, és lekérje az MFA-t.

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

1. Jelszó és SF-tanúsítvány (VAGY) használata
2. A hitelesítési házirend rendszergazdája ideiglenes hozzáférési engedélyt adhat ki.
3. A hitelesítési házirend rendszergazdája hozzáad egy telefonszámot, és engedélyezi a hang-/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. A hitelesítési házirend rendszergazdája ideiglenes hozzáférési engedélyt adhat ki.
2. A hitelesítési házirend rendszergazdája hozzáad egy telefonszámot, és engedélyezi a hang-/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. A hitelesítési házirend rendszergazdája ideiglenes hozzáférési engedélyt adhat ki.
2. A felhasználónak regisztrálnia kell egy másik MFA-módszert (amikor a felhasználó MF tanúsítványt használhat egy eszközön) (VAGY)
3. A hitelesítési házirend rendszergazdája hozzáad egy telefonszámot, és engedélyezi a hang-/szöveges üzenetek hitelesítését a felhasználói fiók számára.

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 házirend-rendszergazdaké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átjelszó 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 az Entra ID>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 között törölje a mobilalkalmazáson keresztüli értesítést, é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 a telefonos bejelentkezést vagy a 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 hitelesítési házirendért felelős rendszergazdák módosíthatják az alapértelmezett értéket egytényezősről többtényezősre, vagy egyéni szabályzatkonfigurációkat állíthatnak be a kiállítói témakör, a szabályzat OID, illetve a kiállítói és házirend OID mezők használatával a tanúsítványban.

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

A hitelesítési házirend rendszergazdái megállapíthatják, 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 rendszergazdájának 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 kibocsátó + szabályzat OID használatával, vagy kizárólag a Házirend OID-t, illetve kizárólag a kibocsá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 kibocsátó és a politika OID-szabályai elsőbbséget élveznek a politika 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 a kiállító és a szabályzat OID szabályait értékeli ki. Ha van egy egyéni szabálya a CA1 kiállítóval és az 1.2.3.4.5 szabályzat OID-vel MFA esetén, akkor csak az A tanúsítvány kap MFA-t, amely megfelel mind a kiállítói értéknek, mind a szabályzat OID-nak.
3. Ezután a rendszer kiértékeli a szabályzatazonosítókat használó egyéni szabályokat. Ha van egy A tanúsítványa, amely az OID 1.2.3.4.5 szabályzat szerint van érvényesítve, és egy B származtatott hitelesítő adat, amely az OID 1.2.3.4.5.6 szabályzatot követi, és az egyéni szabály Házirend OID-ként van definiálva, amelynek értéke 1.2.3.4.5 MFA-val, akkor csak az A tanúsítvány felel meg az MFA követelményeinek, míg a B hitelesítő adat csak egytényezős hitelesítést teljesít. 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 az egyéni szabályokat, amelyek a kiállító hitelesítésszolgáltató (CA) alapján vannak definiálva.
6. Ha egy tanúsítványnál mind a házirendi OID, mind pedig a kibocsátó szabályai megegyeznek, a rendszer mindig először a házirendi OID-t ellenőrzi, és ha nem található házirendszabály, akkor a kibocsátói kötéseket ellenőrzi. A Politika OID magasabb erős hitelesítési kötési prioritással rendelkezik, mint a kibocsá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 során a Microsoft Entra hitelesítési házirend rendszergazdája a Kiállító és a Házirend OID együttes használatával konfigurálja a CBA hitelesítési házirend-szabályt; ez 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

A munkahelyi csatlakozással, a Microsoft Entra-azonosítóval és a hibrid Microsoft Entra-eszközcsatlakozással kapcsolatos eszközregisztrációs forgatókönyveket nem érinti. A CBA-hitelesítési szabályok, amelyek kiállítót vagy házirend-OID-t használnak, nincsenek befolyásolva. A hitelesítési házirend rendszergazdáinak a enyhítés érdekében a következőt kell tenni:

• Szerkessze a jelenleg a Kiállító és a Házirend OID beállításait használó tanúsítványalapú hitelesítési házirend-szabályokat, távolítsa el a Kiállító vagy az OID követelményt, majd mentse a módosításokat. VAGY
• Távolítsa el a jelenleg a Kiállító és a házirend OID alkalmazásával használt hitelesítési házirendi szabályt, és hozzon létre szabályokat, amelyek csak a kiállítót vagy a házirend OID-t használják.

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ánytérképezési mező	Példák a certificateUserIds értékeire	Felhasználói objektumattribútumok	Típus
Fő név	X509:<PN>bob@woodgrove.com	felhasználói főnév onPremisesFelhasználóiFőnév tanúsítványFelhasználóAzonosítók	alacsony affinitás
RFC822Name	X509:<RFC822>user@woodgrove.com	felhasználói főnév onPremisesFelhasználóiFőnév tanúsítványFelhasználóAzonosítók	alacsony affinitás
Kibocsátó és Tárgy	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	tanúsítványFelhasználóAzonosítók	alacsony affinitás
Tárgy	X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	tanúsítványFelhasználóAzonosítók	alacsony affinitás
SÍEL	X509:<SKI>aB1cD2eF3gH4iJ5kL6-mN7oP8qR=	tanúsítványFelhasználóAzonosítók	magas affinitású
SHA1PublicKey	X509:<SHA1-PUKEY>aB1cD2eF3gH4iJ5kL6-mN7oP8qR Az SHA1PublicKey érték (a teljes tanúsítványtartalom SHA1 kivonata a nyilvános kulccsal együtt) a tanúsítvány Ujjlenyomat tulajdonságában található.	tanúsítványFelhasználóAzonosítók	magas affinitású
Kibocsátó és sorozatszám	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT 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	tanúsítványFelhasználóAzonosítók	magas affinitású

Fontos

A CertificateBasedAuthentication PowerShell-modullal megkeresheti a végfelhasználói tanúsítványból származó felhasználó megfelelő CertificateUserIds-értékeit.

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

Ezzel a funkcióval a hitelesítési házirend rendszergazdája konfigurálhatja, hogy a felhasználó hitelesítése alacsony affinitású vagy nagy affinitású felhasználónév-kötés-megfelelteté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ő szintű alapértelmezett értéket is, ha egyéni szabályokat hoz létre a Kibocsátó és a házirend OID, a házirend OID vagy a Kibocsá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 legelőrehelyezettebb prioritású (legalacsonyabb szám) kapcsolódást.

1. Keresse meg a felhasználói objektumot a felhasználónév vagy a Felhasználói UPN (User Principal Name) használatával.
2. Kérje le a hitelesítési házirend rendszergazdája által beállított összes felhasználónév-kötés listáját a CBA hitelesítési módszer "priority" attribútum által rendezett konfigurációjában. 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 szerepel a bemutatott tanúsítványban, a Microsoft Entra ID az ebben szereplő értéket a felhasználói objektum attribútumértékével egyezteti.
   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 házirendben, amely lehetővé teszi, hogy a hitelesítési házirend rendszergazdája egy tanúsítványt több Microsoft Entra felhasználói fiók-kiosztáshoz kezeljen.

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 rendszergazdája 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 rendszergazdájának 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 rendszergazdájának meg kell győződnie arról, hogy nem rendelkezik egynél több alacsony affinitású kötéssel.

Tegyük fel például, hogy a PrincipalName-hez tartozik két felhasználónév-kötés, ahol az egyik az UPN-re és a másik a SubjectKeyIdentifierre (SKI) a certificateUserIds-ra van leképezve. Ha azt szeretné, hogy egy tanúsítvány csak egyetlen fiókhoz legyen használva, a hitelesítési házirend rendszergazdájának 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-megfeleltetést ugyanazon fiók certificateUserId attribútumában.

Több tanúsítvány támogatása egy Microsoft 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 tanúsítványa lehet, vagy egy másodlagos intelligenskártyát vagy x509-tanúsítványt kezelni képes eszköz, mint például egy Yubikey.

Csak felhőbeli fiókok Csak felhőalapú fiókok esetén több tanúsítványt (legfeljebb 5) képezhet le 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>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV

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ó bármelyik tanúsítványt megjelenítheti 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 (azaz a példában a Kiállító+SerialNumber értéket), akkor a felhasználó sikeresen bejelentkezik.

Hibrid szinkronizált fiókok Szinkronizált fiókok esetén több tanúsítványt is hozzárendelhet az AD altSecurityIdentities mezőjének kitöltésével, amely tartalmazza az egyes tanúsítványokat azonosító értékeket. Ha a szervezet nagy affinitású (vagyis erős hitelesítési) kötéseket használ, például Kiállító + SerialNumber, ez a következőképpen nézhet ki:

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV

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 a Microsoft Entra ID certificateUserIds mezőjével.

Több Microsoft 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 szolgálati fiókokhoz is használható. A hagyományos AD-ben az altSecurityIdentities mező a tanúsítványértékek kitö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ásképp van, és nincs útmutatás. 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 ugyanazt a tanúsítványértéket feltölteni.

Fontos

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

Csak felhőbeli fiókok Csak felhőalapú fiókok esetén több felhasználónév-kötést kell létrehoznia, és egyedi értékeket kell megfeleltetnie a tanúsítványt használó felhasználói fiókoknak. Minden fiók hitelesítése másik felhasználónév-kötéssel történik. Ez egyetlen címtár/bérlő határain belülre vonatkozik (azaz a hitelesítési házirend rendszergazdái leképezhetik 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 a Kiállító + SerialNumber és a SKI kötéseket, ez a következőképpen 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>aB1cD2eF3gH4iJ5kL6-mN7oP8qR
X509:<SKI>cD2eF3gH4iJ5kL6mN7-oP8qR9sT

Most, ha bármelyik felhasználó ugyanazt a tanúsítványt mutatja be a 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 használatával, a másik pedig SKI-kapcsolattal 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 legfeljebb 3 lehet. 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ő. Bár a hitelesítési házirend rendszergazdái egyedi értékeket rendelhetnek a tanúsítványt használó összes felhasználói fiókhoz, a Microsoft Entra-azonosítóban lévő összes érték feltöltésének általános gyakorlata megnehezíti ezt. Ehelyett a Microsoft Entra Connectnek szűrnie kell a fiókonkénti kívánt értékeket a Microsoft Entra-azonosítóban található fiókba feltöltött egyedi értékekre. Az egyediségi szabály egyetlen címtár/bérlő határain belül érvényes (azaz a hitelesítési házirend rendszergazdái leképezhetik a tanúsítványt egy másik címtárban/bérlőben való használatra, mindaddig, amíg az értékek fiókonként is egyediek maradnak). Emellett a szervezet több AD-erdővel is rendelkezhet, amelyek felhasználókat tartalmaznak, és egyetlen Microsoft Entra-bérlőhöz tartoznak. Ebben az esetben a Microsoft Entra Connect minden ilyen AD-erdőre alkalmazza a szűrőt azzal a céllal, hogy csak a kívánt egyedi értéket töltse fel a felhőfiókba.

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 (például detailee, rendszergazda, fejlesztő stb.). Válasszon ki egy kulcsattribútumot az AD-ben, amely a szinkronizálás számára megmutatja, hogy a felhasználó milyen típusú felhasználói fiókot értékel ki (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>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Erdő 1 – Fiók 2 (bob-admin@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Erdő 2 – ADAccount1 (bob-tdy@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

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

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

1. A Microsoft Entra Connect konfigurálása az alternativeSecurityIds mező metaverzumba való hozzáadására
2. Minden AD-erdő esetében konfiguráljon egy új egyéni bejövő szabályt magas prioritással, 100 alatti alacsony számmal. 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 használja.
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 a rendszer először ellenőrzi az altSecurityIdentities és az msDS-cloudExtensionAttribute1is kulcsattribútumot annak ellenőrzéséhez, hogy ki vannak-e töltve. Ha nem, ellenőrzik, hogy az altSecurityIdentities fel 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 ki 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 a Microsoft 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 a Microsoft 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 adatok betöltésének befejezéséhez a Microsoft Entra ID-ben.

Győződjön meg arról, hogy a CBA minden bérlőben konfigurálva van úgy, hogy a felhasználónév-megkötés a tanúsítványból leképezett mezőtípusok certificateUserIds mezőjére mutasson. 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.

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

A tanúsítvány-visszavonási folyamat lehetővé teszi, hogy a hitelesítési házirend rendszergazdái visszavonjanak egy korábban kiadott tanúsítványt a jövőbeli hitelesítéshez való használatból. A tanúsítvány visszavonása nem érvényteleníti a felhasználó már kiadott hozzáférési tokenjeit. Kövesse a lépéseket a jogkivonatok manuális visszavonásához a Visszavonás konfigurálása részben.

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 hitelesítési házirend rendszergazdái konfigurálhatják 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 Microsoft 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 nyilvános Microsoft Entra-azonosító és 150 MB az Azure US Government-felhőkben).

Fontos

Ha egy hitelesítési házirend rendszergazdája kihagyja a CRL konfigurációját, a Microsoft Entra ID 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 a művelet javítja 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 bármilyen további használathoz. A CRL-dokumentumban tiszteli 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).
3. A felhasználói tanúsítványalapú hitelesítés meghiúsul, ha:

   • A CRL be van állítva a megbízható kiállítóhoz, és a Microsoft Entra ID nem tudja letölteni a CRL-t korlátozások miatt, amelyek a rendelkezésre állás, a méret vagy a késés szempontjából fennállnak.

   • 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. Legfeljebb 10 végső ügyféltanúsítvány hitelesítésszolgáltató vehető figyelembe 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 ha a hitelesítésszolgáltató biztonsága sérül, a hitelesítési házirend rendszergazdáinak el kell távolítaniuk 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ás és közzététel ciklusai miatt erősen javasolt, hogy tanúsítvány-visszavonás esetén az érintett felhasználó minden munkamenetét is visszavonja a Microsoft Entra ID-ben.

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ó StsRefreshTokensValidFrom mezőjét a Windows PowerShell használatával. Frissítenie kell a StsRefreshTokensValidFrom mezőt minden olyan felhasználóhoz, akihez vissza szeretné vonni a hozzáférést.

Annak biztosításához, hogy a visszavonás továbbra is megmaradjon, a visszavont tanúsítványok érvényes dátumát a StsRefreshTokensValidFrom által beállított érték utáni dátumra kell állítania, és gondoskodnia kell arról, hogy a kérdéses tanúsítvány szerepeljen a CRL-ben.

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 StsRefreshTokensValidFrom mező beállításával.

# Authenticate to Microsoft Graph
Connect-MgGraph -Scopes "User.Read.All"

# Get the user
$user = Get-MgUser -UserPrincipalName "test@yourdomain.com"

# Get the StsRefreshTokensValidFrom property
$user.StsRefreshTokensValidFrom

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 az Set-MsolUser parancs által jelzett dátumra).

A CRL-ellenőrzés ismertetése

A CRL azoknak a digitális tanúsítványoknak a rekordja, amelyeket egy hitelesítésszolgáltató visszavont az érvényességi időszak lejárta előtt. Ha a hitelesítésszolgáltatókat feltöltik a Microsoft Entra megbízhatósági tárolóba, nincs szükség CRL-re, vagy pontosabban a crlDistributionPoint attribútumra. A hitelesítésszolgáltató CRL-végpont nélkül is feltölthető, és a tanúsítványalapú hitelesítés nem fog meghiúsulni, ha a kibocsátó hitelesítésszolgáltató nem rendelkezik CRL-lel.

A biztonság megerősítése és a helytelen konfigurációk elkerülése érdekében a hitelesítési házirend rendszergazdája megkövetelheti, hogy a CBA-hitelesítés meghiúsuljon, ha nincs konfigurálva CRL egy végfelhasználói tanúsítványt kiállító hitelesítésszolgáltatóhoz.

CRL-ellenőrzés engedélyezése

A CRL-érvényesítés engedélyezéséhez válassza a CRL-ellenőrzés megkövetelése (ajánlott) lehetőséget.

Miután engedélyezve van, a CBA bármilyen hibája azért következik be, mert a végfelhasználói tanúsítvány egy olyan hitelesítésszolgáltató által került kiadásra, amelynél nincs konfigurálva a CRL.

A hitelesítési házirend rendszergazdája mentesítheti a hitelesítésszolgáltatót, ha a CRL-jének kijavítandó problémái vannak. Válassza a Kivétel hozzáadása lehetőséget, és válassza ki a mentesítendő hitelesítésszolgáltatókat.

A mentesített listában szereplő hitelesítésszolgáltatóknak nem kell konfigurálniuk a CRL-t, és az általuk kibocsátott végfelhasználói tanúsítványok nem vallanak kudarcot a hitelesítés során.

Válassza ki a tanúsítványkiadókat, és válassza a Hozzáadás lehetőséget. A Keresés szövegmezővel szűrheti a hitelesítésszolgáltatói listákat adott hitelesítésszolgáltatók kiválasztásához.

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 hitelesítési házirend rendszergazdája a hitelesítés-kötési szabályzat 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 követelményként egy adott tanúsítványt kelljen használni a kibocsátó és a szabályzat OID-jai alapján, amikor a felhasználók bizonyos érzékeny erőforrásokhoz való hozzáférés céljából CBA-t végeznek. 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 egyik, ahol a tanúsítvány megfelel az egytényezős hitelesítésnek, és a másik, ahol a tanúsítvány megfelel a többtényezős hitelesítésnek (MFA).

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 a SAN főnév nevét leképezi a UserPrincipalName névre.

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 tárgykulcs-azonosító ({expectedSKI}) nem egyezik a CRL hatósági kulccsal ({crlAK}). 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, kérjük, másolja a naplórészleteket a hibajelentés oldal 'További részletek' hivatkozásából. 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 Megszakított azt jelenti, hogy a Microsoft Entra ID ellenőrizte, 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 tárgy neve 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	többtényezős hitelesítés
   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.

Feljegyzés

Az Edge böngésző azonban hozzáadott egy új funkciót a tanúsítványkijelölés alaphelyzetbe állításához a böngésző újraindítása nélkül.

A További részletek lehetőséget választva lekérheti a hitelesítési házirend rendszergazdájának küldhető naplózási információkat, akik pedig további információkat kaphatnak 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.

A tanúsítványválasztás alaphelyzetbe állítása az edge böngészőben

Ha a CBA sikertelen 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 újbóli kipróbálásához, amikor a böngészők gyorsítótárazza a tanúsítványt. Az Edge böngésző azonban hozzáadott egy új fejlesztést, amely visszaállítja a tanúsítványválasztást a böngészőben.

• Ha a CBA meghiúsul, a rendszer elküldi a felhasználót a hibaoldalra

• Válassza a cím URL-címétől balra található zárolás ikont, és válassza a Tanúsítványválasztás lehetőséget.

• Válassza a Tanúsítvány beállításainak visszaállítása lehetőséget

• Válassza a Beállítások visszaállítása lehetőséget a párbeszédpanelen

• Kattintson az Egyéb módok lehetőségre a hibaoldalon való bejelentkezéshez

• Válassza a Tanúsítvány vagy intelligens kártya használata a választóban lehetőséget, és folytassa a CBA-hitelesítést.

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.

Az MRU hitelesítési módszer felhasználói szinten van beállítva, így ha egy felhasználó sikeresen bejelentkezik egy másik eszközre egy másik hitelesítési módszerrel, az MRU visszaállítja a felhasználót a jelenleg bejelentkezett metódusra.

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

Egy külső identitású B2B vendégfelhasználó használhatja a CBA-t az otthoni bérlői környezetben, és amennyiben az erőforrás-bérlő bérlőközi beállításai úgy vannak beállítva, hogy megbízzanak az otthoni bérlő MFA-jában, a felhasználó CBA-hitelesítése az otthoni bérlőnél elismerésre kerül. 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. Az erőforrásbérlő CBA-ja még nincs támogatva.

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
• GYIK
• A Microsoft Entra CBA hibaelhárítása