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


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.

A Microsoft Entra tanúsítványalapú hitelesítés működésének lépéseit bemutató ábra.

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.

    Képernyőkép a MyApps bejelentkezési portáljáról.

  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.

    Képernyőkép a Tanúsítvány vagy intelligens kártya használata lehetőségről.

    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.

    Képernyőkép a bejelentkezésről, ha a FIDO2 is engedélyezve van.

  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í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 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 tippeket.

  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.

    Képernyőkép a tanúsítványválasztóról.

  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 kiállítói tippek ismertetése (előzetes verzió)

A kiállítói tippek egy megbízható hitelesítésszolgáltatói jelzést küldenek vissza a TLS-kézfogás részeként. A megbízható hitelesítésszolgáltatói lista a bérlő által az Entra megbízhatósági tárolóban feltöltött hitelesítésszolgáltatókra (CA-kra) van beállítva. A böngészőügyfél vagy a natív alkalmazásügyfél a kiszolgáló által visszaküldött tanácsokkal szűri 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.

Kiállítói tippek engedélyezése

Az engedélyezéshez kattintson a Kiállítói tippek jelölőnégyzetre. A hitelesítési házirend rendszergazdáinak az Nyugtázás gombra kell kattintanak, miután meggyőződnek arról, hogy a TLS-ellenőrzéssel rendelkező proxy megfelelően frissült, és mentve van.

Feljegyzés

Ha a szervezet tűzfalakkal vagy proxykkal rendelkezik TLS-ellenőrzéssel, vegye figyelembe, hogy letiltotta a tanúsítványvégpont TLS-vizsgálatát, amely képes bármely névnek [*.]certauth.login.microsoftonline.commegfeleltetni a használt proxy alapján.

Képernyőkép a kiállítói tippek engedélyezéséről.

Feljegyzés

A hitelesítésszolgáltató URL-címe formátuma t{tenantId}.certauth.login.microsoftonline.com a kiállítói tippek engedélyezése után lesz.

Képernyőkép a tanúsítványválasztóról a kiállítói tippek engedélyezése után.

A hitelesítésszolgáltató megbízhatósági tárának frissítési propagálása

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 állapotból, akár 10 perc is eltolhatja a kiállítói tippeket az ügyfélhez. A felhasználók nem hitelesíthetik magukat az új hitelesítésszolgáltatók által kibocsátott tanúsítványokkal, amíg a tippek 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 az alábbi hibaüzenetet fogják látni, ha a hitelesítésszolgáltató megbízhatósági tárolójának frissítései propagálás alatt állnak.

Képernyőkép egy hibaüzenetről, amelyből a felhasználók láthatják, hogy a frissítések folyamatban vannak-e.

Tanúsítványalapú hitelesítés MFA-képessége

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 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. Ideiglenes hozzáférési bérlet kiállítása.
  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. 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 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.

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

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 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ő)

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 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á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.

    Képernyőkép a többtényezős hitelesítési beállítások konfigurálásáról.

  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.

    Képernyőkép az értesítések mobilalkalmazáson keresztüli eltávolításáról.

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.

    Képernyőkép a felhasználónév megadásáról.

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

    Képernyőkép a tanúsítványokkal való bejelentkezésről.

    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.

    Képernyőkép a tanúsítványokkal való bejelentkezés alternatív módjáról.

  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.

    Képernyőkép a tanúsítvány kiválasztásáról.

  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.

    A második tényezőkérés képernyőképe.

  5. Értesítést fog kapni a telefonján. Válassza a Bejelentkezés jóváhagyása?lehetőséget. Képernyőkép a jóváhagyási kérelemről.

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

    Képernyőkép a számegyezésről.

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

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

A CBA olyan második tényezőként használható, mint a Jelszó (első tényező) és a CBA (második tényező) az MFA lekéréséhez.

Feljegyzés

Az iOS-en a tanúsítványalapú hitelesítéssel rendelkező felhasználók egy "dupla kérést" fognak látni, ahol a tanúsítványalapú hitelesítés kétszeri használatára kell kattintaniuk. Az iOS-en a Microsoft Authenticator alkalmazással rendelkező felhasználók óránkénti bejelentkezési kérést kapnak a CBA hitelesítéséhez, ha a CBA-t hitelesítési erősségi szabályzat kényszeríti, vagy ha a CBA-t használják második tényezőként vagy lépésenkénti hitelesítésként.

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 rendszergazdái 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 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 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 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 a Microsoft Entra hitelesítési házirend rendszergazdája A 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

A munkahelyi csatlakozással, a Microsoft Entra-azonosítóval és a hibrid Microsoft Entra-eszközillesztéssel történő eszközregisztrációra nincs 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 megoldás érdekében a hitelesítési házirend rendszergazdáinak a következőt kell tenni:

  • 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
SÍEL X509:<SKI>aB1cD2eF3gH4iJ5kL6-mN7oP8qR= certificateUserIds nagy affinitás
SHA1PublicKey X509:<SHA1-PUKEY>aB1cD2eF3gH4iJ5kL6-mN7oP8qR certificateUserIds nagy affinitás
IssuerAndSerialNumber (előzetes verzió) 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
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 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ő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 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 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 hitelesítési házirend rendszergazdája egy tanúsítványt több Microsoft 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 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-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 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 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>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ó 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 (azaz ebben a példában Kiállító+SerialNumber), akkor 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ú (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 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ő 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ő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ü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 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 hitelesítési házirend rendszergazdái egyedi értékeket képezhetnek le minden olyan felhasználói fiókhoz, amely a tanúsítványt fogja használni, a Microsoft Entra-azonosítóban lévő összes érték feltöltésének általános gyakorlata megnehezítené 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 a felhasználókat egyetlen Microsoft Entra-bérlőbe hozzájárulnak. 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ó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 (például detailee, rendszergazda, fejlesztő stb.). Válasszon ki egy kulcsattribútumot az AD-ben, amely közli a szinkronizálással, hogy melyik felhasználói fióktípust értékeli 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>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Erdő 1 – Fiók2 (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ő metaverzumhoz 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 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 populációjának a Microsoft Entra-azonosítóban való 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 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 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 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á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.

      Képernyőkép a visszavont felhasználói tanúsítványról 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 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á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 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 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 felhasználói tanúsítvány képernyőképe.

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, bizonyos esetekben szükség van bizonyos értékekre, és mivel a bejelentkezési naplók nem támogatják a dinamikus változókat, a bejelentkezési naplókból hiányoznak 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.

Képernyőkép a hitelesítési házirend konfigurációjáról, amelyen egytényezős hitelesítés szükséges.

  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.

    Képernyőkép a bejelentkezési naplók egytényezős hitelesítési bejegyzéséről.

    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.

    Képernyőkép a bejelentkezési naplók tevékenységadatairól.

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

    Képernyőkép a többtényezős további részletekről a bejelentkezési naplókban.

    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.

    Képernyőkép a bejelentkezési naplók jogkivonat-bejegyzésének frissítéséről.

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.

Képernyőkép a hitelesítési szabályzat konfigurációjáról, amelyen a többtényezős hitelesítés szükséges.

  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.

    Képernyőkép a bejelentkezési naplók több bejegyzéséről.

    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.

    Képernyőkép a bejelentkezési naplók második tényezős bejelentkezési adatairól.

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

    Képernyőkép a bejelentkezési naplók megszakadt kísérleteinek részleteiről.

    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:

Képernyőkép egy tanúsítványérvényesítési hibáról.

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 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.

Képernyőkép a hiba részleteirő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.

Képernyőkép egy új bejelentkezési kísérletről.

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