A hitelesítés újdonságai

A Microsoft rendszeresen hozzáadja és módosítja a Microsoft Identitásplatform funkcióit és funkcióit a biztonság, a használhatóság és a szabványok megfelelőségének javítása érdekében.

Eltérő rendelkezés hiányában az itt ismertetett változások csak a változás megjelölt hatályba lépése után regisztrált alkalmazásokra vonatkoznak.

Az alábbiakról rendszeresen olvassa el ezt a cikket:

• Ismert problémák és javítások
• Protokollmódosítások
• Elavult funkció

Tipp.

Ha értesítést szeretne kapni a lap frissítéséről, adja hozzá ezt az URL-címet az RSS-hírcsatorna-olvasóhoz:
https://learn.microsoft.com/api/search/rss?search=%22Azure+Active+Directory+breaking+changes+reference%22&locale=en-us

2024. augusztus

Az összevont identitás hitelesítő adatai mostantól megkülönböztetik a kis- és nagybetűk egyezését

Hatálybalépés dátuma: 2024. szeptember

A protokoll érintett: Számítási feladatok identitásának összevonása

Módosítás

Korábban az összevont identitás hitelesítő adatainak (FIC) issuersubjectaudience és a megfelelőnek issuersubjectmegfelelő értékeknek, valamint a Microsoft Entra ID-nak külső identitásszolgáltató által küldött jogkivonatban található értékeknek való megfeleléskor a kis- és audience nagybetűk megkülönböztetése nem volt megfelelő. Az ügyfelek részletesebb szabályozása érdekében a kis- és nagybetűket megkülönböztető egyeztetésre váltunk.

Érvénytelen példa:

• Jogkivonat tárgya: repo:contoso/contoso-org:ref:refs/heads/main
• FIC tárgy: repo:Contoso/Contoso-Org:ref:refs/heads/main

Ez a két tárgyérték nem egyezik a kis- és nagybetűk megkülönböztetésével, ezért az ellenőrzés sikertelen. A rendszer ugyanezt a mechanizmust issuer alkalmazza és audience érvényesíti.

Ezt a módosítást kezdetben a rendszer alkalmazza az után létrehozott August 14th, 2024alkalmazásokra vagy felügyelt identitásokra. Az inaktív alkalmazásoknak vagy felügyelt identitásoknak, amelyeket az adott alkalmazás vagy felügyelt identitás által a megadott időszak August 1st, 2024 August 31st, 2024közötti nulla számítási feladat identitás-összevonási kérése határoz meg, a kis- és nagybetűk megkülönböztetésével való egyeztetést September 27th, 2024kell használniuk. Az aktív alkalmazások esetében a kis- és nagybetűk közötti érzéketlen egyeztetést később kell közölni.

A kis- és nagybetűk érzéketlensége miatti hibák jobb kiemelése érdekében átdolgozzuk a következőhöz tartozó AADSTS700213hibaüzenetet: . Ez most meg fog jelenni;

`AADSTS700213: No matching federated identity record found for presented assertion subject '{subject}'. Please note that matching is done using a case-sensitive comparison. Check your federated identity credential Subject, Audience, and Issuer against the presented assertion.` 

A helyőrző '{subject}' a külső identitásszolgáltatótól a Microsoft Entra-azonosítónak küldött jogkivonatban található tulajdonosi jogcím értékét adja meg. Ez a hibasablon a kis- és nagybetűket érzéketlenül körülvevő issuer és audience érvényesítő hibákhoz is használható. Ha ezt a hibát tapasztalja, keresse meg a , vagy a hiba listában szereplő összevont identitás hitelesítő adataitissuersubject, és győződjön meg arról, hogy a megfelelő értékek kis- és audience nagybetűk szempontjából egyenértékűek. Ha eltérés van, a FIC aktuális issuerértékét subjectvagy audience értékét a hibaüzenetben szereplő értékre subjectvagy audience értékre issuerkell cserélni.

Feljegyzés

Ha Azure-alkalmazás Szolgáltatás ügyfelei a GitHub Actionst használják, és belefutnak ebbe a hibába, ennek a megoldásához nyissa meg a munkafolyamat-fájlt /.github/workflows a GitHub-adattárban, és frissítse a környezeti name tulajdonságot."Production" "production" Ez az útmutató csak Azure-alkalmazás szolgáltatásforgatókönyvekre vonatkozik. Ha ezt a hibát egy másik forgatókönyvben tapasztalja, tekintse meg a fenti útmutatást.

2024. június

Az alkalmazásokat címtárban kell regisztrálni

Hatálybalépés dátuma: 2024. június

Érintett végpontok: 2.0-s és 1.0-s verzió

A protokoll érintett: Minden folyamat

Módosítás

Korábban, amikor a Microsoft Entra alkalmazásregisztrációi felülettel regisztráltak egy alkalmazást, ha a felhasználó személyes Microsoft-fiókjával (MSA) jelentkezett be, dönthetett úgy, hogy csak a személyes fiókjához társítja az alkalmazást. Ez azt jelenti, hogy az alkalmazás nem lesz társítva egyetlen könyvtárhoz sem (más néven "bérlőhöz" vagy "szervezethez"). 2024 júniusától azonban minden alkalmazást regisztrálni kell egy címtárban. Ez lehet egy meglévő címtár, vagy egy új, amelyet a személyes Microsoft-fiók felhasználója hoz létre a Microsoft Entra-alkalmazások és más Microsoft-erőforrások házhoz vételével. A felhasználók egyszerűen létrehozhatnak egy új, erre a célra használható címtárat a Microsoft 365 fejlesztői programhoz való csatlakozással vagy az Azure-ra való regisztrációval.

Az alkalmazások címtárban való regisztrálása ahelyett, hogy csak személyes fiókkal társítanák, számos előnnyel jár. Ezek közé tartoznak:

• A címtárban regisztrált alkalmazások több funkcióval rendelkeznek, például több tulajdonos hozzáadásának lehetősége az alkalmazáshoz, valamint az alkalmazás közzétevői ellenőrzése .
• Az alkalmazás ugyanazon a helyen található, mint a fejlesztő által használt többi Microsoft-erőforrás, például az Azure-erőforrások.
• Az alkalmazás továbbfejlesztett rugalmassági előnyöket kap.

Ez nem érinti a meglévő alkalmazásokat, beleértve azokat a meglévő alkalmazásokat sem, amelyek csak személyes fiókhoz vannak társítva. Csak az új alkalmazások regisztrálásának képessége lesz hatással.

Október 2023.

Frissített RemoteConnect UX-parancssor

Hatálybalépés dátuma: 2023. október

Érintett végpontok: 2.0-s és 1.0-s verzió

A protokoll érintett: RemoteConnect

A RemoteConnect egy eszközközi folyamat, amelyet a Microsoft Authentication Brokerhez és a Microsoft Intune-hoz kapcsolódó, elsődleges frissítési jogkivonatokat tartalmazó forgatókönyvekhez használnak. Az adathalászati támadások megelőzése érdekében a RemoteConnect-folyamat frissített UX-nyelvet kap, hogy a távoli eszköz (a folyamatot kezdeményező eszköz) a folyamat sikeres befejezésekor hozzáférhessen a szervezet által használt alkalmazásokhoz.

A megjelenő üzenet a következőképpen fog kinézni:

2023. június

Nem ellenőrzött tartománytulajdonossal kapcsolatos e-mail-jogcímek kihagyása

Hatálybalépés dátuma: 2023. június

Érintett végpontok: 2.0-s és 1.0-s verzió

Módosítás

A több-bérlős alkalmazások esetében a nem tartománytulajdonos által ellenőrzött e-mailek alapértelmezés szerint kimaradnak, amikor az opcionális email jogcímet egy jogkivonat hasznos adatában kérik.

Az e-mailek akkor tekinthetők tartománytulajdonosnak, ha:

1. A tartomány ahhoz a bérlőhöz tartozik, ahol a felhasználói fiók található, és a bérlő rendszergazdája elvégezte a tartomány ellenőrzését.
2. Az e-mail egy Microsoft-fiókból (MSA) származik.
3. Az e-mail egy Google-fiókból származik.
4. Az e-mailt az egyszeri pin-kód (OTP) folyamattal történő hitelesítéshez használták.

Azt is meg kell jegyezni, hogy a Facebook és az SAML/WS-Fed fiókok nem rendelkeznek ellenőrzött tartományokkal.

2023. május

A Power BI rendszergazdai szerepköre át lesz nevezve hálóadminisztrátorra.

Hatálybalépés dátuma: 2023. június

Érintett végpontok:

• RoleDefinitions listázása – Microsoft Graph 1.0-s verzió
• List directoryRoles – Microsoft Graph 1.0-s verzió

Módosítás

A Power BI-rendszergazdai szerepkör át lesz nevezve hálóadminisztrátorra.

2023. május 23-án a Microsoft bemutatta a Microsoft Fabricet, amely a Data Factory-alapú adatintegrációs élményt, a Synapse-alapú adatelemzést, az adattárházat, az adatelemzést és a valós idejű elemzési és üzleti intelligenciát (BI) biztosítja a Power BI-val – mindezt egy tóközpontú SaaS-megoldáson üzemeltetve. Ezeknek a szolgáltatásoknak a bérlői és kapacitásfelügyelete a Háló felügyeleti portálján (korábbi nevén a Power BI felügyeleti portálján) van központosítva.

2023 júniusától a Power BI-rendszergazdai szerepkör át lesz nevezve Hálóadminisztrátorra, hogy igazodjon a szerepkör változó hatóköréhez és felelősségéhez. Az összes alkalmazás, beleértve a Microsoft Entra ID-t, a Microsoft Graph API-kat, a Microsoft 365-öt és a GDAP-t, néhány hét alatt elkezdi tükrözni az új szerepkör nevét.

Emlékeztetőül, az alkalmazáskódnak és a szkripteknek nem szabad szerepkörnév vagy megjelenítendő név alapján döntéseket hozniuk.

2021. december

Az AD FS felhasználói további bejelentkezési kéréseket fognak látni, amelyek biztosítják, hogy a megfelelő felhasználó be legyen jelentkezve.

Hatálybalépés dátuma: 2021. december

Érintett végpontok: Integrált Windows-hitelesítés

A protokoll érintett: Integrált Windows-hitelesítés

Módosítás

Ma, amikor a rendszer elküldi a felhasználót az AD FS-nek a hitelesítéshez, a rendszer csendesen bejelentkezik minden olyan fiókba, amely már rendelkezik munkamenettel az AD FS-sel. A csendes bejelentkezés akkor is megtörténik, ha a felhasználó egy másik felhasználói fiókba akart bejelentkezni. A helytelen bejelentkezés gyakoriságának csökkentése érdekében decembertől a Microsoft Entra ID elküldi a paramétert az prompt=login AD FS-nek, ha a Windows webfiók-kezelője megadja a Microsoft Entra-azonosítót login_hint a bejelentkezés során, ami azt jelzi, hogy egy adott felhasználót szeretne bejelentkezni.

Ha a fenti követelmények teljesülnek (a WAM-et arra használják, hogy a felhasználót a Microsoft Entra-azonosítóra küldje a bejelentkezéshez, login_hint egy is szerepel benne, és a felhasználó tartományához tartozó AD FS-példány támogatja prompt=login) a felhasználó nem lesz csendesen bejelentkezve, hanem egy felhasználónevet kér az AD FS-be való bejelentkezés folytatásához. Ha be szeretnének jelentkezni a meglévő AD FS-munkamenetbe, a bejelentkezési kérés alatt megjelenő "Folytatás aktuális felhasználóként" lehetőséget választhatják. Ellenkező esetben folytathatják azt a felhasználónevet, amellyel be szeretnének jelentkezni.

Ezt a módosítást 2021 decemberében fogjuk végrehajtani több hét alatt. A következőhöz nem módosítja a bejelentkezési viselkedést:

• Közvetlenül az IWA-t használó alkalmazások
• OAuth-ot használó alkalmazások
• Az AD FS-példányhoz nem összevont tartományok

2021. október

Az 50105-ös hiba kijavítva, hogy az interaktív hitelesítés során ne térjen vissza interaction_required

Hatálybalépés dátuma: 2021. október

Érintett végpontok: 2.0-s és 1.0-s verzió

A protokoll érintett: A felhasználói hozzárendelést igénylő alkalmazások összes felhasználói folyamata

Módosítás

Az 50105-ös hiba (az aktuális megjelölés) akkor jelenik meg, ha egy hozzárendeletlen felhasználó megpróbál bejelentkezni egy olyan alkalmazásba, amelyet a rendszergazda felhasználói hozzárendelést igénylőként jelölt meg. Ez egy gyakori hozzáférés-vezérlési minta, és a felhasználóknak gyakran meg kell találniuk egy rendszergazdát, aki hozzárendelést kér a hozzáférés letiltásának feloldásához. A hiba olyan hibát okozott, amely végtelen hurkokat okozott a helyesen kezelt interaction_required , jól kódolt alkalmazásokban. interaction_required interaktív hitelesítés végrehajtására utasítja az alkalmazást, de a Microsoft Entra ID még ezt követően is hibaüzenetet interaction_required ad vissza.

A hibaforgatókönyv frissült, így a nem interaktív hitelesítés (ahol prompt=none az UX elrejtésére szolgál) során az alkalmazás arra lesz utasítva, hogy hibaválasz használatával végezzen interaktív hitelesítést interaction_required . Az ezt követő interaktív hitelesítés során a Microsoft Entra-azonosító mostantól a felhasználót fogja tárolni, és közvetlenül megjelenít egy hibaüzenetet, megakadályozva a hurok előfordulását.

Emlékeztetőül, az alkalmazáskódnak nem szabad olyan hibakódsztringeken alapuló döntéseket hoznia, mint a AADSTS50105. Ehelyett kövesse a hibakezelési útmutatót, és használja a válasz standard error mezőjében található és login_required hasonló interaction_required szabványos hitelesítési válaszokat. A többi válaszmezőt csak az emberek használják, akik elhárítják a problémáikat.

Áttekintheti az 50105-ös hiba jelenlegi szövegét, és további tudnivalókat a hibakeresési szolgáltatásról: https://login.microsoftonline.com/error?code=50105.

Az egybérlős alkalmazásokban az AppId Uri használatához alapértelmezett séma vagy ellenőrzött tartományok szükségesek

Hatálybalépés dátuma: 2021. október

Érintett végpontok: 2.0-s és 1.0-s verzió

A protokoll érintett: Minden folyamat

Módosítás

Egybérlős alkalmazások esetén az AppId URI hozzáadása vagy frissítése ellenőrzi, hogy a HTTPS-séma URI tartománya szerepel-e az ügyfélbérlő ellenőrzött tartománylistájában, vagy hogy az érték a Microsoft Entra ID által biztosított alapértelmezett sémát (api://{appId}) használja-e. Ez megakadályozhatja, hogy az alkalmazások AppId URI-t adjanak hozzá, ha a tartomány nem szerepel az ellenőrzött tartománylistában, vagy ha az érték nem használja az alapértelmezett sémát. Az ellenőrzött tartományokra vonatkozó további információkért tekintse meg az egyéni tartományok dokumentációját.

A módosítás nincs hatással az AppID URI-ban nem ellenőrzött tartományokat használó meglévő alkalmazásokra. Csak az új alkalmazásokat ellenőrzi, vagy ha egy meglévő alkalmazás frissít egy azonosító URI-t, vagy újat ad hozzá az identifierUri-gyűjteményhez. Az új korlátozások csak az alkalmazások identifierUris gyűjteményéhez 2021. október 15. után hozzáadott URI-kra vonatkoznak. A korlátozás 2021. október 15-i érvénybe lépésekor az AppId URI-k már az alkalmazás identifierUris gyűjteményében is működnek, még akkor is, ha új URI-kat ad hozzá a gyűjteményhez.

Ha egy kérés sikertelen az érvényesítési ellenőrzés során, a létrehozási/frissítési alkalmazás API a HostNameNotOnVerifiedDomain azonosítót 400 badrequest tartalmazó ügyfelet adja vissza.

Az alábbi API- és HTTP-sémaalapú alkalmazásazonosító URI-formátumok támogatottak. Cserélje le a helyőrző értékeket a táblázatot követő listában leírtak szerint.

Támogatott alkalmazásazonosító URI-formátumok	Példa alkalmazásazonosító URI-kra
<api:// appId>	api://00001111-aaaa-2222-bbbb-3333cccc4444
<api:// tenantId>/<appId>	api://aaaabbbb-0000-cccc-1111-dddd2222eeee/00001111-aaaa-2222-bbbb-3333cccc4444
<api:// tenantId>/<sztring>	api://aaaabbbb-0000-cccc-1111-dddd2222eeee/api
<api:// string>/<appId>	api://productapi/00001111-aaaa-2222-bbbb-3333cccc4444
<https:// tenantInitialDomain.onmicrosoft.com/>< string>	https://contoso.onmicrosoft.com/productsapi
<https:// verifiedCustomDomain>/<string>	https://contoso.com/productsapi
<https://.><verifiedCustomDomain>	https://product.contoso.com
<https://.><verifiedCustomDomain>/<string>	https://product.contoso.com/productsapi

• <appId> – Az alkalmazásobjektum alkalmazásazonosító (appId) tulajdonsága.
• <sztring> – A gazdagép vagy az API elérési út szegmensének sztringértéke.
• <tenantId> – Az Azure által létrehozott GUID, amely a bérlőt jelöli az Azure-ban.
• <tenantInitialDomain> - <tenantInitialDomain.onmicrosoft.com>, ahol< a tenantInitialDomain> a bérlő létrehozásakor megadott kezdeti tartománynév.
• <verifiedCustomDomain> – A Microsoft Entra-bérlőhöz konfigurált ellenőrzött egyéni tartomány .

Feljegyzés

Ha a api:// sémát használja, közvetlenül a "api://" után adhat hozzá sztringértéket. Például api:// string>.< Ez a sztringérték lehet GUID vagy tetszőleges sztring. Ha GUID-értéket ad hozzá, annak meg kell egyeznie az alkalmazásazonosítóval vagy a bérlőazonosítóval. Az alkalmazásazonosító URI-értékének egyedinek kell lennie a bérlő számára. Ha api://< tenantId azonosítót> ad hozzá az alkalmazásazonosító URI-jaként, senki más nem fogja tudni használni ezt az URI-t más alkalmazásokban. A javaslat az api://< appId> vagy a HTTP-séma használata.

Fontos

Az alkalmazásazonosító URI-értéke nem végződik perjeles "/" karakterrel.

Feljegyzés

Bár az aktuális bérlőn belüli alkalmazásregisztrációk azonosítóUri-jait biztonságosan eltávolíthatja, az identifierUris eltávolításával az ügyfelek más alkalmazásregisztrációk esetén meghiúsulhatnak.

2021. augusztus

A feltételes hozzáférés csak a kifejezetten kért hatókörök esetén aktiválódik

Hatálybalépés dátuma: 2021. augusztus, a fokozatos bevezetés áprilisban kezdődik.

Érintett végpontok: 2.0-s verzió

A protokoll érintett: Minden folyamat dinamikus hozzájárulással

A dinamikus hozzájárulást használó alkalmazások minden olyan engedélyt megkapnak, amelyhez hozzájárulásuk van, még akkor is, ha nem kérték őket név alapján a scope paraméterben. Egy olyan alkalmazás, amely csak user.read a jóváhagyást files.read kéri, kényszeríthető például a feltételes hozzáférési követelmény teljesítésére files.read.

A szükségtelen feltételes hozzáférési kérések számának csökkentése érdekében a Microsoft Entra-azonosító módosítja a hatókörök alkalmazásokhoz való biztosításának módját, így csak a kifejezetten kért hatókörök aktiválják a feltételes hozzáférést. A Microsoft Entra ID korábbi viselkedésére támaszkodó alkalmazások, amelyek az összes hatókört belevetik a jogkivonatba – függetlenül attól, hogy kérték-e vagy sem –, a hiányzó hatókörök miatt megszakadhatnak.

Az alkalmazások mostantól különböző engedélyekkel kapják meg a hozzáférési jogkivonatokat: a kért jogkivonatokat és azokat, amelyekhez hozzájárulásuk van, és nem igényelnek feltételes hozzáférési kéréseket. A jogkivonat hozzáférési hatóköre a jogkivonat-válasz paraméterében jelenik scope meg.

Ez a módosítás az összes alkalmazás esetében történik, kivéve azokat, amelyeknél ez a viselkedés megfigyelt függőségben van. A fejlesztők értesítést kapnak, ha mentesülnek a módosítás alól, mivel előfordulhat, hogy függőségben vannak a további feltételes hozzáférési kérésekkel.

Példák

Egy alkalmazás hozzájárult a user.read, files.readwriteés tasks.read. files.readwrite feltételes hozzáférési szabályzatokat alkalmaz rá, míg a másik kettő nem. Ha egy alkalmazás jogkivonat-kérelmet scope=user.readküld, és a jelenleg bejelentkezett felhasználó nem adott át feltételes hozzáférési szabályzatokat, az eredményül kapott jogkivonat az és tasks.read az user.read engedélyek lesznek. tasks.read azért van benne, mert az alkalmazás rendelkezik hozzá hozzájárulással, és nem követeli meg a feltételes hozzáférési szabályzat kikényszerítését.

Ha az alkalmazás ezután kéri scope=files.readwrite, a bérlő által igényelt feltételes hozzáférés aktiválódik, így az alkalmazás egy interaktív hitelesítési kérést jelenít meg, ahol a feltételes hozzáférési szabályzat teljesíthető. A visszaadott jogkivonat mindhárom hatókörrel rendelkezik.

Ha az alkalmazás ezután egy utolsó kérést küld a három hatókör bármelyikére (például), a Microsoft Entra-azonosító látni fogja, scope=tasks.readhogy a felhasználó már elvégezte a feltételes hozzáférési szabályzatokat files.readwrite, és ismét kibocsát egy jogkivonatot mind a három engedélyével.

2021. június

Az eszközkód-folyamat UX-jának mostantól tartalmaznia kell egy alkalmazásmegerősítő kérést

Hatálybalépés dátuma: 2021. június.

Érintett végpontok: 2.0-s és 1.0-s verzió

A protokoll érintett: Az eszköz kódfolyamata

Az adathalászati támadások megelőzése érdekében az eszköz kódfolyamata mostantól tartalmaz egy kérést, amely ellenőrzi, hogy a felhasználó bejelentkezik-e a várt alkalmazásba.

A megjelenő üzenet a következőképpen néz ki:

május 2020.

Hibajavítás: A Microsoft Entra ID már nem fogja kétszer URL-kódolni az állapotparamétert

Hatálybalépés dátuma: 2021. május

Érintett végpontok: 1.0-s és 2.0-s verzió

A protokoll érintett: A végpontot meglátogató /authorize összes folyamat (implicit folyamat és engedélyezési kódfolyamat)

Hiba történt a Microsoft Entra engedélyezési válaszában. A hitelesítés során a /authorize válasz tartalmazza a state kérés paraméterét, amely megőrzi az alkalmazás állapotát, és segít megelőzni a CSRF-támadásokat. A Microsoft Entra ID helytelenül url-kódolja a paramétert, state mielőtt beszúrta volna a válaszba, ahol ismét kódolva lett. Ez azt eredményezné, hogy az alkalmazások helytelenül utasítják el a Microsoft Entra ID válaszát.

A Microsoft Entra ID nem fogja többé duplán kódolni ezt a paramétert, így az alkalmazások megfelelően elemezni fogják az eredményt. Ez a módosítás minden alkalmazás esetében meg fog változni.

Módosulnak az Azure Government-végpontok

Hatálybalépés dátuma: 2020. május 5. (Befejezés: 2020. június)

Érintett végpontok: Minden

A protokoll érintett: Minden folyamat

2018. június 1-jén a Hivatalos Microsoft Entra Authority for Azure Government a következőre https://login-us.microsoftonline.com https://login.microsoftonline.usváltozott: . Ez a módosítás a Microsoft 365 GCC High és a DoD szolgáltatásra is vonatkozott, amelyet az Azure Government Microsoft Entra ID is kínál. Ha egy usa-beli kormányzati bérlőn belül rendelkezik alkalmazással, frissítenie kell az alkalmazást, hogy bejelentkeztethesse a felhasználókat a .us végponton.

2020. május 5-én a Microsoft Entra ID megkezdi a végpontmódosítás kikényszerítését, megakadályozva, hogy a kormányzati felhasználók az USA kormányzati bérlőiben üzemeltetett alkalmazásokba jelentkezzenek be a nyilvános végpont ()microsoftonline.com használatával. Az érintett alkalmazások hibaüzenetet AADSTS900439 - USGClientNotSupportedOnPublicEndpointfognak látni. Ez a hiba azt jelzi, hogy az alkalmazás usa-beli kormányzati felhasználót próbál bejelentkezni a nyilvános felhővégpontra. Ha az alkalmazás nyilvános felhőbeli bérlőben van, és az USA kormányzati felhasználóinak támogatására szolgál, frissítenie kell az alkalmazást, hogy kifejezetten támogassa őket. Ehhez új alkalmazásregisztrációt kell létrehozni az USA kormányzati felhőjében.

Ennek a változásnak a végrehajtása fokozatos bevezetéssel történik, attól függően, hogy milyen gyakran jelentkeznek be az USA kormányzati felhőbeli felhasználói az alkalmazásba – az USA kormányzati felhasználóinak ritkán bejelentkező alkalmazások először a kényszerítéseket fogják látni, az USA kormányzati felhasználói által gyakran használt alkalmazások pedig utolsóként érvénybe lépnek. 2020 júniusában az összes alkalmazásra kiterjedő kényszerítés várható.

További részletekért tekintse meg az Azure Government migrálással kapcsolatos blogbejegyzését.

2020. március

A felhasználói jelszavak 256 karakter hosszúságúak lesznek.

Hatálybalépés dátuma: 2020. március 13.

Érintett végpontok: Minden

A protokoll érintett: Minden felhasználói folyamat.

A 256 karakternél hosszabb jelszóval rendelkező felhasználókat, akik közvetlenül a Microsoft Entra-azonosítóba jelentkeznek be (nem összevont identitásszolgáltató, például az AD FS) a bejelentkezés előtt meg kell változtatniuk a jelszavukat. A rendszergazdák kéréseket kaphatnak a felhasználó jelszavának alaphelyzetbe állításához.

A bejelentkezési naplókban a hiba az AADSTS 50052: InvalidPasswordExceedsMaxLength-hez hasonló lesz.

Üzenet: The password entered exceeds the maximum length of 256. Please reach out to your admin to reset the password.

Kármentesítés:

A felhasználó nem tud bejelentkezni, mert a jelszava meghaladja a megengedett maximális hosszt. A jelszó alaphelyzetbe állításához forduljon a rendszergazdához. Ha az SSPR engedélyezve van a bérlője számára, az "Elfelejtette a jelszavát" hivatkozásra kattintva alaphelyzetbe állíthatja a jelszavát.

február 2020.

A rendszer a bejelentkezési végpont minden HTTP-átirányításához hozzáfűzi az üres töredékeket.

Hatálybalépés dátuma: 2020. február 8.

Érintett végpontok: 1.0-s és 2.0-s verzió

A protokoll érintett: A használt response_type=query OAuth- és OIDC-folyamatok – ez bizonyos esetekben lefedi az engedélyezési kód folyamatát és az implicit folyamatot.

Ha a rendszer http-átirányítással küld hitelesítési választ login.microsoftonline.com egy alkalmazásnak, a szolgáltatás egy üres töredéket fűz a válasz URL-címéhez. Ez megakadályozza az átirányítási támadások osztályát azáltal, hogy biztosítja, hogy a böngésző törölje a hitelesítési kérelemben lévő összes meglévő töredéket. Egyetlen alkalmazásnak sem lehet függősége ehhez a viselkedéshez.

2019. augusztus

A POST űrlap szemantikája szigorúbban lesz érvényesítve – a szóközök és az idézőjelek figyelmen kívül lesznek hagyva

Hatálybalépés dátuma: 2019. szeptember 2.

Érintett végpontok: 1.0-s és 2.0-s verzió

A protokoll érintett: A post bárhol használható (ügyfél hitelesítő adatai, engedélyezési kód beváltása, ROPC, OBO és frissítési jogkivonat beváltása)

2019. szeptember 2-tól kezdődően a POST metódust használó hitelesítési kérelmek szigorúbb HTTP-szabványok használatával lesznek érvényesítve. Pontosabban a szóközök és a dupla idézőjelek (") többé nem lesznek eltávolítva a kéreleműrlap értékeiből. Ezek a módosítások várhatóan nem szakítják meg a meglévő ügyfeleket, és biztosítják, hogy a Microsoft Entra ID-nak küldött kérések minden alkalommal megbízhatóan legyenek kezelve. A jövőben (lásd fent) azt tervezzük, hogy emellett elutasítjuk az ismétlődő paramétereket, és figyelmen kívül hagyjuk a BOM-t a kéréseken belül.

Példa:

Ma ugyanúgy van elemezve, ?e= "f"&g=h mint ?e=f&g=h - így e == f. Ezzel a módosítással most elemezni kell, hogy e == "f" - ez valószínűleg nem lesz érvényes argumentum, és a kérés most meghiúsulna.

2019. július

Az egybérlős alkalmazásokhoz csak akkor adnak ki csak alkalmazásjogkivonatokat, ha az ügyfélalkalmazás létezik az erőforrás-bérlőben

Hatálybalépés dátuma: 2019. július 26.

Érintett végpontok: 1.0-s és 2.0-s verzió

A protokoll érintett: Ügyfél hitelesítő adatai (csak alkalmazásalapú jogkivonatok)

2019. július 26-án életbe lépett egy biztonsági változás, amely megváltoztatja a csak alkalmazásalapú jogkivonatok (az ügyfél hitelesítő adatainak megadásán keresztüli) kiadásának módját. Korábban az alkalmazások jogkivonatokat kaphattak bármely más alkalmazás hívásához, függetlenül attól, hogy a bérlőben vagy az adott alkalmazáshoz hozzájárult szerepkörökben van-e jelenlét. Ez a viselkedés úgy lett frissítve, hogy az erőforrások (más néven webes API-k) egybérlősnek (alapértelmezett) legyenek, az ügyfélalkalmazásnak léteznie kell az erőforrás-bérlőn belül. Az ügyfél és az API közötti meglévő hozzájárulás továbbra sem szükséges, és az alkalmazásoknak továbbra is saját engedélyezési ellenőrzéseket kell végezniük annak biztosítása érdekében, hogy egy roles jogcím jelen legyen, és tartalmazza az API várt értékét.

A forgatókönyvhöz tartozó hibaüzenet jelenleg a következőt közli:

The service principal named <appName> was not found in the tenant named <tenant_name>. This can happen if the application has not been installed by the administrator of the tenant.

A probléma megoldásához használja a Rendszergazdai hozzájárulás felületet az ügyfélalkalmazás-szolgáltatásnév létrehozásához a bérlőben, vagy hozza létre manuálisan. Ez a követelmény biztosítja, hogy a bérlő engedélyt adott az alkalmazásnak a bérlőn belüli működésre.

Példa kérésre:

https://login.microsoftonline.com/contoso.com/oauth2/authorize?resource=https://gateway.contoso.com/api&response_type=token&client_id=00001111-aaaa-2222-bbbb-3333cccc4444&... Ebben a példában az erőforrás-bérlő (szolgáltató) contoso.com, az erőforrásalkalmazás egy egybérlős alkalmazás, amely a Contoso-bérlőhöz van meghívva gateway.contoso.com/api , az ügyfélalkalmazás pedig 00001111-aaaa-2222-bbbb-3333cccc4444. Ha az ügyfélalkalmazás szolgáltatásnévvel rendelkezik Contoso.com belül, a kérés folytatódhat. Ha azonban nem, akkor a kérés a fenti hibával meghiúsul.

Ha azonban a Contoso átjáróalkalmazás több-bérlős alkalmazás volt, akkor a kérés folytatódik, függetlenül attól, hogy az ügyfélalkalmazás rendelkezik szolgáltatásnévvel Contoso.com.

Az átirányítási URI-k mostantól tartalmazhatnak lekérdezési sztringparamétereket

Hatálybalépés dátuma: 2019. július 22.

Érintett végpontok: 1.0-s és 2.0-s verzió

A protokoll érintett: Minden folyamat

Az RFC 6749-es verziónként a Microsoft Entra-alkalmazások mostantól regisztrálhatják és használhatják az átirányítási (válasz) URI-kat statikus lekérdezési paraméterekkel (például https://contoso.com/oauth2?idp=microsoft) OAuth 2.0-kérésekhez. A dinamikus átirányítási URI-k továbbra is tiltottak, mivel biztonsági kockázatot jelentenek, és ez nem használható az állapotadatok hitelesítési kérések közötti megőrzésére – ehhez használja a paramétert state .

A statikus lekérdezési paraméterre az átirányítási URI bármely más részéhez hasonlóan sztringegyeztetés vonatkozik az átirányítási URI-khoz – ha nincs olyan sztring regisztrálva, amely megfelel az URI-dekódolt redirect_uri, a kérést a rendszer elutasítja. Ha az URI megtalálható az alkalmazásregisztrációban, akkor a rendszer a teljes sztringet használja a felhasználó átirányítására, beleértve a statikus lekérdezési paramétert is.

Jelenleg (2019. július végén) az alkalmazásregisztrációs UX az Azure Portalon továbbra is letiltja a lekérdezési paramétereket. Az alkalmazásjegyzéket azonban manuálisan is szerkesztheti, hogy lekérdezési paramétereket adjon hozzá, és tesztelje azt az alkalmazásban.

2019. március

A hurkolt ügyfelek megszakadnak

Hatálybalépés dátuma: 2019. március 25.

Érintett végpontok: 1.0-s és 2.0-s verzió

A protokoll érintett: Minden folyamat

Az ügyfélalkalmazások néha helytelenül viselkednek, és rövid idő alatt több száz azonos bejelentkezési kérést bocsátanak ki. Előfordulhat, hogy ezek a kérések sikeresek, de mind hozzájárulnak a gyenge felhasználói élményhez és az identitásszolgáltató megnövekedett számítási feladataihoz, növelik az összes felhasználó késését, és csökkentik az identitásszolgáltató rendelkezésre állását. Ezek az alkalmazások a normál használat határain kívül működnek, és a helyes működés érdekében frissíteni kell őket.

Az ismétlődő kéréseket többször kibocsátó ügyfelek a következő hibaüzenetet invalid_grant kapják: AADSTS50196: The server terminated an operation because it encountered a loop while processing a request.

A legtöbb ügyfélnek nem kell módosítania a viselkedést a hiba elkerülése érdekében. Ez a hiba csak a hibásan konfigurált ügyfelekre (a jogkivonatok gyorsítótárazásával nem rendelkező vagy a parancssori hurkokat már kiállító ügyfelekre) lesz hatással. Az ügyfelek nyomon követése példányonként történik helyileg (cookie-n keresztül) a következő tényezők alapján:

• Felhasználói tipp, ha van ilyen

• A kért hatókörök vagy erőforrások

• Ügyfél azonosítója

• Átirányítási URI

• Válasz típusa és módja

A több kérést (15+) rövid idő alatt (5 perc) küldő alkalmazások hibaüzenetet invalid_grant kapnak, amely azt jelzi, hogy hurkolnak. A kért jogkivonatok elég hosszú élettartamúak (alapértelmezés szerint 10 perc, alapértelmezés szerint 60 perc), ezért az ezen időszak alatt ismétlődő kérések szükségtelenek.

Minden alkalmazásnak invalid_grant interaktív üzenet jelenik meg a jogkivonat csendes kérése helyett. A hiba elkerülése érdekében az ügyfeleknek gondoskodniuk kell arról, hogy megfelelően gyorsítótárazzák a kapott jogkivonatokat.

október 2018.

Az engedélyezési kódok már nem használhatók újra

Hatálybalépés dátuma: 2018. november 15.

Érintett végpontok: 1.0-s és 2.0-s verzió

A protokoll érintett: Kódfolyamat

2018. november 15-től a Microsoft Entra ID nem fogadja el az alkalmazásokhoz korábban használt hitelesítési kódokat. Ez a biztonsági változás segít abban, hogy a Microsoft Entra-azonosító összhangban legyen az OAuth-specifikációval, és az 1. és a 2. v2-végpontokon is érvénybe lép.

Ha az alkalmazás újra felhasználja az engedélyezési kódokat, hogy több erőforrás jogkivonatait szerezze be, javasoljuk, hogy a kóddal szerezze be a frissítési jogkivonatot, majd ezt a frissítési jogkivonatot használva szerezzen be további jogkivonatokat más erőforrásokhoz. Az engedélyezési kódok csak egyszer használhatók, de a frissítési jogkivonatok több erőforráson keresztül többször is használhatók. Minden új alkalmazás, amely megpróbál újra felhasználni egy hitelesítési kódot az OAuth-kódfolyamat során, invalid_grant hibaüzenetet kap.

További információ a jogkivonatok frissítéséről: A hozzáférési jogkivonatok frissítése. Az ADAL vagy az MSAL használata esetén ezt a tár kezeli Ön helyett – cserélje le a második példányt AcquireTokenByAuthorizationCodeAsync a következőre AcquireTokenSilentAsync: .

2018. május

Az azonosító jogkivonatok nem használhatók az OBO-folyamathoz

Dátum: 2018. május 1.

Érintett végpontok: 1.0-s és 2.0-s verzió

Érintett protokollok: Implicit folyamat és a folyamat nevében

2018. május 1-je után id_tokens nem használható az új alkalmazások OBO-folyamatában. A hozzáférési jogkivonatokat inkább az API-k védelmére kell használni, még ugyanazon alkalmazás ügyfél- és középső rétege között is. A 2018. május 1. előtt regisztrált alkalmazások továbbra is működni fognak, és id_tokens cserélhetnek egy hozzáférési jogkivonatra; ez a minta azonban nem tekinthető ajánlott eljárásnak.

A módosítás megkerüléséhez tegye a következőket:

1. Hozzon létre egy webes API-t az alkalmazáshoz egy vagy több hatókörrel. Ez a explicit belépési pont lehetővé teszi a részletesebb szabályozást és biztonságot.
2. Az alkalmazás jegyzékfájljában, az Azure Portalon vagy az alkalmazásregisztrációs portálon győződjön meg arról, hogy az alkalmazás jogosult hozzáférési jogkivonatok kiadására az implicit folyamaton keresztül. Ezt a oauth2AllowImplicitFlow kulcs vezérli.
3. Amikor az ügyfélalkalmazás id_token response_type=id_tokenkér, kérjen hozzáférési jogkivonatot (response_type=token) a fent létrehozott webes API-hoz. Így a 2.0-s verziójú végpont használatakor a scope paraméternek a következőhöz hasonlónak api://GUID/SCOPEkell lennie. Az 1.0-s verziójú végponton a resource paraméternek a webes API alkalmazás URI-jának kell lennie.
4. Adja át ezt a hozzáférési jogkivonatot a középső rétegnek a id_token helyett.