Migrálás összevonásról Microsoft Entra tanúsítványalapú hitelesítésre (CBA)
Ez a cikk bemutatja, hogyan migrálhat a futó összevont kiszolgálókról, például a helyszíni Active Directory összevonási szolgáltatások (AD FS) (AD FS) felhőhitelesítésről felhőhitelesítésre a Microsoft Entra tanúsítványalapú hitelesítés (CBA) használatával.
Szakaszos bevezetés
A bérlői rendszergazdák próbatesztelés nélkül teljesen átvághatják az összevont tartományt a Microsoft Entra CBA-ra, ha engedélyezik a CBA hitelesítési módszert a Microsoft Entra ID-ban, és a teljes tartományt felügyelt hitelesítéssé alakítják. Ha azonban az ügyfél egy kis köteg felhasználó hitelesítését szeretné tesztelni a Microsoft Entra CBA-n, mielőtt a teljes tartományátvételt felügyelni szeretné, használhatja a szakaszos bevezetési funkciót.
A tanúsítványalapú hitelesítés (CBA) szakaszos bevezetése segít az ügyfeleknek áttérni a CBA összevont identitásszolgáltatón történő elvégzéséről a Microsoft Entra-azonosítóra azáltal, hogy szelektíven áthelyezik a felhasználók kis csoportját a CBA használatára a Microsoft Entra ID-ban (a továbbiakban nem átirányítják az összevont identitásszolgáltatóra), mielőtt a Microsoft Entra ID tartománykonfigurációját összevontról felügyeltre konvertálnák. A szakaszos bevezetés nem úgy lett kialakítva, hogy a tartomány hosszú ideig vagy nagy mennyiségű felhasználó számára összevont maradjon.
Ebből a rövid videóból megtudhatja, hogy migrál az ADFS-tanúsítványalapú hitelesítésről a Microsoft Entra CBA-ba
Feljegyzés
Ha a szakaszos bevezetés engedélyezve van egy felhasználó számára, a felhasználó felügyelt felhasználónak minősül, és minden hitelesítés a Microsoft Entra-azonosítón történik. Összevont bérlő esetén, ha a CBA engedélyezve van a szakaszos bevezetéskor, a jelszó-hitelesítés csak akkor működik, ha a PHS is engedélyezve van, különben a jelszóhitelesítés sikertelen lesz.
Szakaszos bevezetés engedélyezése tanúsítványalapú hitelesítéshez a bérlőn
Tipp.
A cikkben szereplő lépések a portáltól függően kissé eltérhetnek.
A szakaszos bevezetés konfigurálásához kövesse az alábbi lépéseket:
- Jelentkezzen be a Microsoft Entra Felügyeleti központba legalább felhasználói rendszergazdaként.
- Keresse meg és válassza ki a Microsoft Entra Connectet.
- A Microsoft Entra Connect lapon, a felhőalapú hitelesítés szakaszos bevezetése alatt kattintson a Szakaszos bevezetés engedélyezése felügyelt felhasználói bejelentkezéshez elemre.
- A Szakaszos bevezetés engedélyezése funkciólapon kattintson a Tanúsítványalapú hitelesítés beállításra
- Kattintson a Csoportok kezelése elemre, és vegye fel a felhőhitelesítés részét képező csoportokat. Az időtúllépés elkerülése érdekében győződjön meg arról, hogy a biztonsági csoportok kezdetben legfeljebb 200 tagot tartalmaznak.
További információ: Szakaszos bevezetés.
A CertificateUserIds attribútum frissítése a Microsoft Entra Connect használatával
Az AD FS rendszergazdái a Szinkronizálási szabályok szerkesztőjével szabályokat hozhatnak létre az AD FS attribútumainak a Microsoft Entra felhasználói objektumokkal való szinkronizálásához. További információ: A certificateUserIds szinkronizálási szabályai.
A Microsoft Entra Connecthez egy hibrid identitáskezelő nevű speciális szerepkörre van szükség, amely megadja a szükséges engedélyeket. Erre a szerepkörre van szüksége az új felhőattribútumba való íráshoz.
Feljegyzés
Ha egy felhasználó szinkronizált attribútumokat használ, például az onPremisesUserPrincipalName attribútumot a felhasználónév-kötés felhasználói objektumában, vegye figyelembe, hogy a Microsoft Entra Connect-kiszolgálóhoz rendszergazdai hozzáféréssel rendelkező felhasználók módosíthatják a szinkronizált attribútumleképezést, és módosíthatják a szinkronizált attribútum értékét. A felhasználónak nem kell felhőgazdának lennie. Az AD FS rendszergazdájának gondoskodnia kell arról, hogy a Microsoft Entra Connect-kiszolgáló rendszergazdai hozzáférése korlátozott legyen, a kiemelt fiókok pedig csak felhőalapú fiókok legyenek.
Gyakori kérdések az AD FS-ről a Microsoft Entra ID-ra való migrálással kapcsolatban
Rendelkezhetünk kiemelt fiókokkal összevont AD FS-kiszolgálóval?
Bár lehetséges, a Microsoft azt javasolja, hogy a kiemelt fiókok csak felhőalapú fiókok legyenek. Csak felhőalapú fiókok használata emelt szintű hozzáférési korlátokhoz a Microsoft Entra ID-ban egy sérült helyszíni környezetből. További információ: A Microsoft 365 védelme a helyszíni támadásokkal szemben.
Ha egy szervezet hibrid, amely az AD FS-t és az Azure CBA-t is futtatja, továbbra is sebezhetők az AD FS-kompromisszummal szemben?
A Microsoft azt javasolja, hogy a kiemelt fiókok csak felhőalapú fiókok legyenek. Ez a gyakorlat korlátozza a Microsoft Entra ID-beli kitettséget egy sérült helyszíni környezetből. Ehhez a célhoz alapvető fontosságú a csak felhőalapú kiemelt fiókok fenntartása.
Szinkronizált fiókok esetén:
- Ha felügyelt tartományban vannak (nem összevontak), az összevont identitásszolgáltató nem kockáztatja őket.
- Ha összevont tartományban vannak, de a fiókok egy részét a szakaszos bevezetés áthelyezi a Microsoft Entra CBA-ba, az összevont identitásszolgáltatóval kapcsolatos kockázatoknak vannak kitéve, amíg az összevont tartomány teljes mértékben át nem vált a felhőalapú hitelesítésre.
A szervezeteknek meg kell szüntetniük az összevont kiszolgálókat, például az AD FS-t, hogy megakadályozzák az AD FS-ből az Azure-ba való kimutatás lehetőségét?
Az összevonással a támadók megszemélyesíthetnek bárkit, például egy CIO-t, még akkor is, ha nem tudnak csak felhőbeli szerepkört beszerezni, például a globális rendszergazdai fiókot.
Ha egy tartomány összevonása a Microsoft Entra-azonosítóban történik, a rendszer magas szintű megbízhatóságot helyez el az összevont identitásszolgáltatóban. Az AD FS egy példa, de a fogalmak minden összevont identitásszolgáltatóra igaznak bizonyulnak. Számos szervezet kizárólag tanúsítványalapú hitelesítés megvalósításához helyez üzembe összevont identitásszolgáltatót, például az AD FS-t. A Microsoft Entra CBA ebben az esetben teljesen eltávolítja az AD FS-függőséget. A Microsoft Entra CBA használatával az ügyfelek áthelyezhetik alkalmazástulajdonukat a Microsoft Entra ID-ba, hogy modernizálják az IAM-infrastruktúrát, és nagyobb biztonsággal csökkentsék a költségeket.
Biztonsági szempontból nincs változás a hitelesítő adatokban, beleértve az X.509-tanúsítványt, a hitelesítésszolgáltatót, a PIV-t stb. A PKI-tulajdonosok továbbra is teljes mértékben ellenőrzik a tanúsítvány kiállítását, valamint a visszavonás életciklusát és szabályzatát. A visszavonási ellenőrzés és a hitelesítés az összevont azonosító helyett a Microsoft Entra-azonosítón történik. Ezek az ellenőrzések lehetővé teszik a jelszó nélküli, adathalászatnak ellenálló hitelesítést közvetlenül a Microsoft Entra-azonosítóhoz minden felhasználó számára.
Hogyan működik a hitelesítés az összevont AD FS-vel és a Microsoft Entra felhőhitelesítéssel a Windows használatával?
A Microsoft Entra CBA megköveteli, hogy a felhasználó vagy az alkalmazás adja meg a bejelentkező felhasználó Microsoft Entra UPN-ét.
A böngésző példájában a felhasználó leggyakrabban a Microsoft Entra UPN-ben gépel. A Microsoft Entra UPN tartomány- és felhasználófelderítéshez használható. Az ezt követően használt tanúsítványnak meg kell egyeznie a felhasználóval a szabályzatban konfigurált felhasználónév-kötések egyikével.
Windows-bejelentkezés esetén az egyezés attól függ, hogy az eszköz hibrid vagy a Microsoft Entra csatlakozik-e. Ha azonban a felhasználónévre vonatkozó tipp van megadva, a Windows a Microsoft Entra UPN-ként küldi el a tippet. Az ezt követően használt tanúsítványnak meg kell egyeznie a felhasználóval a szabályzatban konfigurált felhasználónév-kötések egyikével.
Következő lépések
- A Microsoft Entra CBA áttekintése
- Technikai mélyrepülés a Microsoft Entra CBA-hoz
- 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
- Gyakori kérdések
Visszajelzés
https://aka.ms/ContentUserFeedback.
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ:Visszajelzés küldése és megtekintése a következőhöz: