RBAC

Oké, túljutottunk a telepítésen. Itt az idő, hogy megvizsgáljuk, mit is kaptunk.

Nyilván neki lehet úgy is állni, hogy elkezdünk össze-vissza kattogtatni a grafikus felületen, aztán figyeljük, hogy mi történik. Csak éppen nem javasolt. Az RBAC-ról speciel a GUI-n keresztül egész konkrétan semmit sem fogunk megtudni.
Pedig az egyik leglényegesebb változás.

A rövidítés azt takarja, hogy Role-Based Access Control.

Gondoljuk el, hogy mennyire kényeztetett el eddig minket az Exchange, ha a jogosultságok finomhangolásáról volt szó?
Van ugye 4 admin jogkörünk:

• Organization admin: Maga az Atyaúristen.
• Server admin: Atyaúristen, csak kicsiben: képességeinek korláta egy Exchange szerver.
• Recipient admin: Szintén az Olümposz lakója: ő a postafiókok terén mindenható.
• View-only admin: Ő sem kispályás: mindent lát egy organizációban.

Egyébként pedig léteznek még a mezítlábas gyalogok, az úgynevezett júzerek.

Bármi ettől eltérő jogosultságot szerettünk volna kikeverni, be kellett merészkednünk a security descriptorok, access tokenek sűrű, sötét dzsungelébe. És ebben nem is az ismeretlen dzsungel volt a fő baj, hanem az, hogy a nagynehezen összefércelt jogosultságaink upgrade esetén mentek a levesbe.

Szerencsére itt van az RBAC. Illetve lesz.

Két irányban tágítja a lehetőségeket:

1. Lehetővé teszi ún. kicsi adminok létrehozását. Rengeteg előregyártott szerepkört tartalmaz, de a lista custom szerepkörökkel is bővíthető. Ezeket a szerepeket hozzárendelhetjük univerzális csoportokhoz, a csoportokba pedig behajigálhatunk felhasználót, csoportot, recipientet.
2. Többlet lehetőségeket biztosíthatunk az egyes felhasználóknak, természetesen csak a saját postafiókjaikra. Nem meglepő, hogy erre a célra házirendeket fogunk felhasználni.

1. Management Role Group

Az ábrán láthatjuk részletesen is, milyen környezetben létezhetnek a kicsi adminok.
Létezik egy Management Role Group (MRG). Ez egy univerzális group, ide szórjuk be a konkrét szereppel megbízott felhasználót, csoportot, recipientet. A másik oldalon létezik egy vagy több szerepkör. Mint írtam, ez lehet beépített, vagy általunk gyártott. (Első körben mindenképpen az előbbi. Ahogy elnéztem, nem túl egyszerű dolog szerepet gyártani.)
A kettő között egy összerendelés, egy Management Role Assignment hoz létre kapcsolatot. Ennek az összerendelésnek még van egy scope paramétere is, miszerint az MRG a címtár egyes névterein belül – eltekintve persze a schema névtértől – mihez fér hozzá írás/olvasás jogosultságokkal.

2. Management Role Assignment Policy

Itt elkövettem egy apró bakit, mert szerettem volna a két eset közötti hasonlóságot bemutatni. A valóságban természetesen nem a felhasználók esnek rá a házirendre, hanem pont fordítva.
Tehát. Létrehozunk egy Management Role Assignment Policy-t (MRAP), melyet majd valahogyan (powershell, powershell) ráküldünk bizonyos recipientekre. A jobb oldalon ugyanazok a szerepek találhatók, mint az előző ábránál. Alul pedig a Management Role Assignment kapcsolja össze a házirendet a szerepekkel. Fontos eltérés, hogy ebben az esetben nincs értelme scope-ról beszélni, hiszen a felhasználók a saját postafiókjaikhoz férnek hozzá.

Végül összefoglalva a két eset:

Ennyit az elméletről. A folytatásban kinevelünk egy nem is kicsi admint, akinek megadjuk azt a jogot, hogy az egész adatbázisban kereshessen (de az külön állítható, hogy meg is tekinthesse a keresés eredményét), illetve házirendből beállítjuk, hogy bizonyos felhasználók ne tudják módosítani a postafiókjukhoz kapcsolódó ún. nem túl fontos tulajdonságokat.