Microsoft Entra ID er að hætta með MemberOf-regluna fyrir kvika(Dynamic) hópa

Microsoft hefur tilkynnt að það muni hætta að styðja MemberOf forskoðunareiginleikann fyrir kvika (Dynamic) hópa, stjórnunareiningar og sjálfvirkar úthlutunarstefnur í entitlement management.

Ef þú ert að nota MemberOf-reglur í dag er mikilvægt að grípa til aðgerða sem fyrst, því eftir tilteknar dagsetningar munu þessir hlutir annaðhvort hætta að uppfærast eða verða settir í sóttkví.

Hvað er að breytast?

Microsoft er að leggja niður MemberOf-reglubaseraða virkni í þessum sviðum:

• Kvikir hópar í Microsoft Entra ID
• Kvikar stjórnunareiningar
• Sjálfvirkar úthlutunarstefnur í entitlement management

Þetta þýðir að ef hópur eða stefna reiðir sig á MemberOf-reglu, þá mun hún ekki lengur virka eins og áður eftir lokadagsetningarnar.

Mikilvægar dagsetningar

Dagsetning	Áhrif
27 Október 2026	Entitlement management sjálfvirkar úthlutunarstefnur sem nota MemberOf verða settar í sóttkví
3 Nóvember 2026	Allir kvikir hópar og kvikar stjórnunareiningar sem nota MemberOf hætta að uppfærast; aðild frýs í núverandi stöðu

Hvað gerist eftir 3 Nóvember 2026?

Eftir 3. nóvember 2026 munu hópar sem nota MemberOf ekki lengur endurreikna aðild sína.

Það þýðir í framkvæmd:

• Núverandi meðlimir haldast áfram í hópnum
• Nýir notendur bætast ekki sjálfkrafa inn
• Notendur sem ættu að detta út úr hópnum verða ekki fjarlægðir sjálfkrafa
• Aðild hópsins verður í raun „fryst“

Þetta getur haft veruleg áhrif ef þú notar þessa hópa fyrir:

• leyfaúthlutanir
• aðgangsstýringar
• sjálfvirka aðild í kerfum
• stjórnun eða úthlutun aðgangspakka

Áhrif á entitlement management

Fyrir entitlement management gerist þetta enn fyrr. Frá og með 27. október 2026 verða sjálfvirkar úthlutunarstefnur sem nota MemberOf settar í sóttkví.

Þegar stefna fer í sóttkví þýðir það að hún er ekki lengur keyrð með eðlilegum hætti og sjálfvirka úthlutunin sem hún átti að sjá um verður ekki lengur áreiðanleg.

Engin undanþága eða framlenging

Microsoft gefur til kynna að það verði:

• engin undanþága
• engin framlenging
• engin leið til að afþakka breytinguna

Ef þú ert með MemberOf-reglur í notkun þarftu því að skipuleggja flutning yfir í aðra lausn.

Hvernig finnurðu hvaða hópar eru undir áhrifum?

Microsoft mælir með að þú finnir alla hópa og stjórnunareiningar sem nota MemberOf-reglur. Til þess er hægt að nota PowerShell með Microsoft Graph einingunum, sérstaklega:

• Microsoft.Graph.Groups
• Microsoft.Graph.Identity.DirectoryManagement

Markmiðið er að finna:

• kvika hópa með MemberOf-reglu
• kvikar stjórnunareiningar með MemberOf-reglu
• entitlement management stefnur sem byggja á MemberOf

Þetta er fyrsta skrefið áður en nokkur breyting er gerð, svo þú vitir nákvæmlega hvar áhættan liggur.

Hvað eru valkostirnir?

Það eru nokkrar leiðir í boði, eftir því hvernig þú notar hópana í dag.

1. Endurskrifa reglurnar með notendaeigindum

Ef hægt er, er best að skipta út MemberOf-rökfræði fyrir reglur sem byggja á eigindum notenda, til dæmis:

• department
• jobTitle
• companyName
• officeLocation
• sérsniðnum eigindum
• extensionAttribute

Þetta er yfirleitt besta langtímalausnin, því hún notar studda kvika hópareglu sem Microsoft heldur áfram að styðja.

Til dæmis, ef þú varst áður að nota MemberOf til að setja notendur í leyfishóp út frá annarri hópaðild, gæti verið betra að setja viðeigandi gildi í department eða extensionAttribute og byggja kvika hópinn á því í staðinn.

2. Breyta hópnum í úthlutaðan hóp

Ef reglubundin kvik aðild er ekki lengur raunhæf, geturðu breytt yfir í assigned membership, það er handvirkt eða stýrt aðildarlíkan.

Þetta hentar betur þegar:

• aðild breytist sjaldan
• þú vilt meiri stjórn
• hópurinn er lítill eða vel skilgreindur
• sjálfvirkni er ekki nauðsynleg

Ókosturinn er að þú missir kvika hegðunina og þarft annaðhvort handvirka umsýslu eða aðra sjálfvirkni.

3. Sjálfvirknivæða samstillingu með PowerShell eða Graph API

Ef MemberOf-reglan endurspeglaði flóknari viðskiptarökfræði sem ekki er auðvelt að endurskapa með einföldum notendaeigindum, getur verið skynsamlegt að búa til sérsniðna sjálfvirkni.

Það er til dæmis hægt að:

• lesa aðild eins eða fleiri upprunahópa
• reikna út hverjir ættu að vera í markhópi
• uppfæra markhópinn sjálfvirkt með PowerShell eða Graph API

Þetta gefur mesta sveigjanleika, en eykur líka rekstrarflækju. Þá þarftu að hugsa um:

• keyrslutíðni
• villumeðhöndlun
• skráningu breytinga
• heimildir forrits eða þjónustuaðila
• eftirlit og viðvaranir

Lausn fyrir group-based licensing

Greinin bendir sérstaklega á að ef þú notar MemberOf fyrir group-based licensing, þá sé oft hægt að leysa það með því að byggja hópa á eigindum eins og:

• user.department
• extensionAttribute

Í stað þess að segja „allir sem eru í hópi X fara í hóp Y“, er betra að skilgreina eiginleika sem segja beint til um hver á að fá leyfið og nota þá eiginleika í kviku reglunni.

Þetta er bæði stöðugra og auðveldara að viðhalda til lengri tíma.

Eru samstilltir staðbundnir hópar undir áhrifum?

Nei, ekki beint.

Ef þú ert með on-premises hópa sem eru samstilltir inn í Entra ID með Entra Connect, þá eru þeir sjálfir ekki vandamálið.

Það sem er undir áhrifum er þegar þú ert með Entra dynamic group sem vísar í slíka hópa með MemberOf reglu. Með öðrum orðum:

• samstillti staðbundni hópurinn er ekki vandamálið
• kviki Entra-hópurinn sem byggir aðild sína á MemberOf er vandamálið

Þetta er mikilvægur munur fyrir umhverfi sem reiða sig mikið á blendingsuppsetningu.

Hvernig ættirðu að undirbúa flutninginn?

Greinin mælir með skipulagðri nálgun.

1. Finndu alla hópa og stefnur sem nota MemberOf

Byrjaðu á að kortleggja allt sem er háð þessum eiginleika. Þetta á við um:

• kvika hópa
• kvikar stjórnunareiningar
• entitlement management sjálfvirkar úthlutunarstefnur

2. Skráðu hvernig þeir eru notaðir

Fyrir hvern hlut þarftu að skilja:

• til hvers hann er notaður
• hvaða kerfi eða ferli reiða sig á hann
• hvort hann stýrir leyfum, aðgangi eða úthlutun
• hversu oft aðild breytist

3. Veldu staðgengilslausn

Fyrir hvern hóp eða hverja stefnu þarftu að taka ákvörðun:

• endurskrifa sem kvika reglu byggða á eigindum
• breyta í úthlutaðan hóp
• byggja sérsniðna sjálfvirka samstillingu

4. Prófaðu niðurstöðuna

Áður en þú slekkur á gömlu lausninni ættirðu að bera saman gamla og nýja aðild.

Greinin leggur til að:

• flytja út aðild í CSV
• bera saman niðurstöður
• nota til dæmis Compare-Object til að sjá mismun

Þannig geturðu sannreynt að nýja lausnin skili sambærilegri útkomu áður en breytingin fer í framleiðslu.

5. Uppfærðu skjölun og rekstrarferla

Þegar ný lausn hefur verið valin og prófuð þarftu að uppfæra:

• tækniskjölun
• rekstrarleiðbeiningar
• eigendaskráningu hópa
• verklag um breytingar og bilanagreiningu

Af hverju skiptir þetta máli?

MemberOf var þægileg leið til að byggja hópa út frá aðild annarra hópa, en það varð líka auðvelt að fela í því flókna og stundum ógegnsæja rökfræði.

Þegar þessi virkni hverfur neyðast mörg teymi til að færa sig yfir í skýrari og betur viðhaldshæfar lausnir. Þó það krefjist vinnu til skamms tíma, getur það til lengri tíma bætt:

• sýnileika
• rekstraröryggi
• bilanagreiningu
• stjórnhæfni

Ráðlegging

Ef þú ert að nota MemberOf-reglur ættirðu ekki að bíða fram á haust 2026.

Skynsamlegasta leiðin er að:

• bera kennsl á alla hópa og stefnur sem verða fyrir áhrifum
• forgangsraða þeim sem tengjast leyfum og aðgangsstýringu
• velja nýtt aðildarlíkan fyrir hvern hlut
• prófa niðurstöður vel
• ljúka flutningi fyrir lokadagsetningar