다음을 통해 공유


Role-Based Access Control (RBAC): Il nuovo modo per gestire Exchange (Parte 3) – I Management Role

Ed ecco la terza parte del mio post su RBAC ed Exchange 2010.
Come promesso nel mio post precedente stavolta mi occuperò dei management role.

I management role contengono la lista dei CmdLet e dei parametri disponibili a ogni ruolo (attributo: msExchRoleEntries)

image

E’ importante ricordarsi che i ruoli utilizzano una struttura gerarchica in cima alla quale ci sono i ruoli Built-In.

Ci sono 3 tipi di management role:

  1. I ruoli Built-In
  2. I ruoli Custom
  3. I ruoli Unscoped Top-Level

Vediamo esattamente come si differenziano.

Ruoli Built-In

I ruoli Built-In sono quelli predefiniti e sono la base da cui partire per creare i ruoli custom. Si possono dividere in due macro-categorie: Gestione Amministrativa e Gestione basata su utente.

I ruoli di gestione amministrativa servono per dare l’accesso a specifiche aree di gestione dell’organizzazione (ad esempio: Database o Message Tracking) mentre i ruoli basati su utente servono principalmente agli utenti per il fai-da-te e l’autogestione (ad esempio: MyDistributionGroups o MyVoiceMail)

Ruoli Custom

I ruoli Custom sono i ruoli definiti da voi. Volete un ruolo che permetta di fare il mount dei DB ma non il dismount ? Volete un ruolo che permetta di aggiungere una mailbox ma non di rimuoverla ? Usate un ruolo custom.

Quando create un ruolo custom dovete usare come base di partenza i cmdlet disponibili a un ruolo built-in e poi togliere quello che non serve. Un esempio pratico: Il vostro helpdesk deve essere in grado di creare una mailbox ma non di cancellarla.

Domanda 1: Quale ruolo built-in si avvicina di più a questa descrizione ?
Risposta: “Mail Recipient Creation”

Domanda 2: Quali dei Cmdlet/parametri disponibili a questo ruolo non servono al mio helpdesk ?
Risposta: Remove-mailbox

Domanda 3: e adesso ?
Risposta: Adesso creiamo un custom role chiamato “Helpdesk Add Mailbox” basato su “Mail Recipient Creation” e gli togliamo l’uso di remove-mailbox :-)

Passo 1 (creazione custom role): New-ManagementRole -Name “Helpdesk Add Mailbox” -Parent “Mail Recipient Creation”

Passo 2 (rimozione di remove-mailbox): Get-ManagementRoleEntry “Helpdesk Add Mailbox” | Where { $_.Name -NotLike "remove-mailbox*" } | Remove-ManagementRoleEntry

Con il primo cmdlet create un custom role con l’attributo msExchRoleEntries identico a quello di Mail Recipient Creation mentre con il secondo togliete il cmdlet remove-mailbox da questo ruolo

Importante: Un custom role può usare al massimo i cmdlet disponibili al ruolo “padre”. Nel mio esempio “Helpdesk Add Mailbox” non potrà mai avere a disposizione cmdlet o parametri che non siano disponibili a “Mail Recipient Creation”. Se volete “aggiungere” dovete usare come template un ruolo che abbia già i cmdlet/parametri che vi servono e poi togliere il resto.

Ruoli Unscoped Top-Level

Questi ruoli sono particolari. Non sono built-in ma sono al loro stesso livello in AD. All’atto pratico vuol dire che quando li create l’attributo msExchRoleEntries è vuoto perchè non avete usato nessun ruolo built-in come template. Per creare un ruolo di tipo Unscoped Top-Level dovete usare il parametro –UnscopedTopLevel di New-ManagementRole. Questi ruoli sono indicati a chi vuol dare accesso a script o cmdlet non-Exchange a un particolare ruolo. Gli script e i cmdlet da aggiungere a questo tipo di ruolo devono prima essere aggiunti come Unscoped Top-Level Role Entries usando il Cmdlet New-ManagementRoleEntry. Gli script che aggiungete devono trovarsi nella cartella Scripts di Exchange 2010 (C:\Program Files\Microsoft\Exchange Server\V14\Scripts). I cmdlet non-Exchange che volete aggiungere devono essere disponibili sui server su cui gli amministratori dovranno usarli.

La prossima volta parlerò dei Management Scope.

Un saluto dal vostro Gabriele