Freigeben über

Controllo di accesso basato sui ruoli - Procedura per la creazione di un ruolo in grado di cancellare i dispositivi ActiveSync

  • Artikel

Articolo originale pubblicato mercoledì 12 settembre 2012

Un quesito emerso diverse volte negli ultimi mesi riguarda il modo in cui creare ruoli RBAC che presentino solo una funzionalità di gestione ActiveSync molto limitata.

Prima di passare alla risposta, spieghiamo brevemente cosa sia il controllo di accesso basato sui ruoli (Role Based Access Control, RBAC).

Prima di Exchange 2010 le autorizzazioni venivano definite mediante strumenti come DSACLS e ADSIEdit. Questo consentiva di specificare su quali oggetti un utente o un gruppo poteva intervenire e quali operazioni poteva eseguire sull'oggetto nel suo complesso. Se un utente aveva necessità dell'accesso in scrittura a una proprietà specifica di un oggetto ma non alle altre proprietà, non vi era un modo semplice per procedere. Il controllo di accesso basato sui ruoli non definisce le autorizzazioni nell'oggetto, bensì nei cmdlet di PowerShell che possono modificare l'oggetto. I cmdlet di PowerShell vengono aggiunti a un ruolo e un utente o un gruppo viene assegnato al ruolo. Se il cmdlet e i parametri necessari fanno parte di un ruolo a cui si partecipa, sarà possibile eseguire il cmdlet.

In Exchange Management Shell è possibile eseguire (get-excommand).count per vedere a quanti cmdlet di Exchange si ha attualmente accesso. Nel Pannello di controllo di Exchange e in Exchange Management Console i cmdlet a cui si ha accesso determinano quali opzioni vengono visualizzate. Se pertanto una finestra dell'una o dell'altra interfaccia utente grafica richiede che nel proprio ruolo siano inclusi cmdlet di PowerShell specifici ma non si dispone di tali cmdlet, è possibile uno dei due risultati seguenti:

  • La finestra non verrà visualizzata (anzi, è improbabile che vengano presentate le opzioni che consentono di accedervi).
  • La finestra verrà visualizzata, ma tutto il contenuto sarà disabilitato (questa situazione in genere si verifica se si dispone dei cmdlet Get- pertinenti, ma mancano uno o più cmdlet Set, New, Add e così via).

Per ulteriori informazioni sul controllo di accesso basato sui ruoli, iniziare dagli articoli seguenti:

In Exchange 2010 SP2 sono inclusi 71 ruoli RBAC. Nessuno di essi però offre sottoinsiemi limitati di comandi ActiveSync da poter assegnare al personale dell'helpdesk. Per creare tali ruoli, è necessario occuparsene personalmente. Se l'helpdesk utilizza PowerShell, il processo è relativamente semplice perché è possibile creare un ruolo che disponga solo del cmdlet di PowerShell e dei parametri necessari. Se gli utenti lavorano esclusivamente con il Pannello di controllo di Exchange, tale processo è più complesso in quanto l'utente deve poter accedere al punto in cui l'operazione viene eseguita.

In questo esempio il cliente aveva necessità che il personale dell'helpdesk fosse in grado di cancellare i dispositivi ActiveSync mediante il Pannello di controllo di Exchange. Il problema era rappresentato dal fatto che solo i membri di Gestione dell'organizzazione (Organization Management) potessero accedere alla finestra appropriata del Pannello di controllo di Exchange ed eseguire una cancellazione dei dispositivi. Non era praticabile la soluzione di aggiungere gli utenti dell'helpdesk al gruppo di ruoli Gestione dell'organizzazione perché dispone di troppi diritti.

L'amministratore ha provato a creare un ruolo RBAC contenente solo il cmdlet Clear-ActiveSyncDevice, ma il nuovo ruolo non consentiva l'accesso alla funzionalità mediante il Pannello di controllo di Exchange, il quale a sua volta non consentiva agli utenti di spostarsi nella posizione in cui è visualizzato il pulsante "Cancella dispositivo" perché tale pulsante è nidificato alcuni livelli più in basso. L'utente deve poter elencare gli utenti dell'organizzazione, visualizzare le relative proprietà per telefono e voce e aprire le finestre di dialogo durante il processo. Un ruolo contenente solo il cmdlet Clear-ActiveSyncDevice non include gli altri cmdlet richiesti da questi altri passaggi nel Pannello di controllo di Exchange. A questo punto dobbiamo pensare a cosa aggiungere a questo ruolo per poter accedere alla finestra e fare clic sul pulsante "Cancella dispositivo".

Il primo passaggio di questo processo consiste nell'esaminare i ruoli da cui è costituito il gruppo di ruoli Gestione dell'organizzazione (Organization Management). A tale scopo, eseguiamo quanto segue:

[PS] C:\>$FormatEnumerationLimit=999
[PS] C:\>get-rolegroup "organization management" | fl roles

Roles : {Active Directory Permissions, Address Lists, ApplicationImpersonation, Audit Logs, Cmdlet Extension Agents, Database Availability Groups, Database Copies, Databases, Disaster Recovery, Distribution Groups, Edge Subscriptions, E-Mail Address Policies, Exchange Connectors, Exchange Server Certificates, Exchange Servers, Exchange Virtual Directories, Federated Sharing, Information Rights Management, Journaling, Legal Hold, Mail Enabled Public Folders, Mail Recipient Creation, Mail Recipients, Mail Tips, Mailbox Import Export, Mailbox Search, Message Tracking, Migration, Monitoring, Move Mailboxes, Organization Client Access, Organization Configuration, Organization Transport Settings, POP3 And IMAP4 Protocols, Public Folder Replication, Public Folders, Receive Connectors, Recipient Policies, Remote and Accepted Domains, Retention Management, Role Management, Security Group Creation and Membership, Send Connectors, Support Diagnostics, Transport Agents, Transport Hygiene, Transport Queues, Transport Rules, UM Mailboxes, UM Prompts, UnScoped Role Management, Unified Messaging, User Options, View-Only Audit Logs, View-Only Configuration, View-Only Recipients, MyBaseOptions, MyContactInformation, MyDiagnostics, MyDistributionGroupMembership, MyDistributionGroups, MyProfileInformation, RetentionPolicies, MyTextMessaging, MyVoiceMail, MyMailboxDelegation}

Da qui dobbiamo eliminare i ruoli che non saranno direttamente correlati alla cancellazione di un dispositivo. Alcuni ruoli, come quello per i domini remoti e accettati, ovviamente non includeranno cmdlet correlati. Per i ruoli potenzialmente interessanti, il passaggio successivo consiste nel determinarne il contenuto. A tale scopo, eseguiamo un cmdlet simile al seguente:

[PS] C:\storage>Get-ManagementRoleEntry "Mail Recipients\*"

Name Role Parameters
---- ---- ----------
Write-AdminAuditLog Mail Recipients {Comment, Confirm, Debug, DomainController, ErrorAction, Er...
Update-Recipient Mail Recipients {Confirm, Credential, Debug, DomainController, ErrorAction,...
Test-MAPIConnectivity Mail Recipients {Archive, Confirm, Debug, ErrorAction, ErrorVariable, Ident...
Set-User Mail Recipients {AssistantName, CertificateSubject, City, Company, Confirm,...

Ho troncato qui l'output e incluso solo alcune righe a scopo dimostrativo. Il cmdlet effettivo genera 96 risultati.

Il passaggio successivo consiste quindi nel creare nuovi ruoli figlio dei ruoli che riteniamo siano utili per il nostro lavoro. Ecco un esempio:

new-managementrole -parent "Mail Recipients" -name StrictlyRecipActiveSyncDeviceWipe

Il ruolo appena creato è un ruolo figlio di Destinatari posta elettronica (Mail Recipients), pertanto dispone di tutte le autorizzazioni del relativo ruolo padre. Perché non utilizzare direttamente il ruolo Destinatari posta elettronica (Mail Recipients)? Man mano che andiamo avanti, ho intenzione di rimuovere alcune parti da questo ruolo in modo da poter giungere al livello di autorizzazioni più basso possibile. Non modificare mai i ruoli incorporati, come Destinatari posta elettronica (Mail Recipients) perché si comprometterebbe la funzionalità. Un altro aspetto da sottolineare è che un ruolo figlio di un altro ruolo può avere assegnata solo la funzionalità del relativo ruolo padre e non può ricevere diritti o accedere a una funzionalità che non sia già inclusa nel ruolo padre.

Dopo avere creato il nostro ruolo, dobbiamo creare un gruppo di ruoli. Questo faciliterà l'assegnazione del ruolo agli utenti in futuro. Per il nostro testing, stiamo utilizzando un account denominato WipeTest. Al termine del testing, sostituire WipeTest con uno o più account o gruppi desiderati.

New-RoleGroup -Name "OnlyActiveSyncDeviceWipe" -Roles "StrictlyRecipActiveSyncDeviceWipe " -members WipeTest

WipeTest può eseguire l'accesso a OWA e passare al Pannello di controllo di Exchange. Scopriamo di poterci spostare quasi fino all'opzione desiderata nel Pannello di controllo di Exchange, ma non proprio fino a tale opzione. Questo significa che è necessario un ulteriore ruolo.

Se si cerca nella directory di Exchange (per impostazione predefinita, c:\Programmi\Microsoft\Exchange), si trova il percorso "ClientAccess\ecp\PhoneVoice". Esaminando i file in esso contenuti, è possibile capire cosa è opportuno aggiungere a questo punto. Nel file Web.Config sono inclusi numerosi riferimenti a OrganizationConfig, ma non sono sufficientemente specifici. Possiamo controllare nella cartella per vedere se un file qualsiasi faccia riferimento a cmdlet specifici da poter utilizzare che non siano inclusi nel ruolo già definito. Il più evidente è Set-CasMailbox, contenuto in QuarantinedDevices.ASCX. Abbiamo quindi verificato dove risieda tale cmdlet:

[PS] C:\>Get-ManagementRoleEntry "*\set-casmailbox" | fl name,role,parameters

Name : Set-CASMailbox
Role : Mail Recipients
Parameters : {ActiveSyncDebugLogging, ActiveSyncEnabled, ActiveSyncMailboxPolicy, Confirm, Debug, DisplayName, DomainController, ECPEnabled, EmailAddresses, ErrorAction, ErrorVariable, EwsAllowEntourage, EwsAllowList, EwsAllowMacOutlook, EwsAllowOutlook, EwsApplicationAccessPolicy, EwsBlockList, EwsEnabled, HasActiveSyncDevicePartnership, Identity, IgnoreDefaultScope, ImapEnabled, ImapEnableExactRFC822Size, ImapMessagesRetrievalMimeFormat, ImapSuppressReadReceipt, ImapUseProtocolDefaults, MAPIBlockOutlookNonCachedMode, MAPIBlockOutlookRpcHttp, MAPIBlockOutlookVersions, MAPIEnabled, Name, OutBuffer, OutVariable, OWAEnabled, OwaMailboxPolicy, PopEnabled, PopEnableExactRFC822Size, PopMessagesRetrievalMimeFormat, PopSuppressReadReceipt, PopUseProtocolDefaults, PrimarySmtpAddress, SamAccountName, ShowGalAsDefaultView, Verbose, WarningAction, WarningVariable, WhatIf}

Name : Set-CASMailbox
Role : Organization Client Access
Parameters : {ActiveSyncAllowedDeviceIDs, ActiveSyncBlockedDeviceIDs, Confirm, Debug, DomainController, ErrorAction, ErrorVariable, Identity, OutBuffer, OutVariable, Verbose, WarningAction, WarningVariable, WhatIf}

Name : Set-CASMailbox
Role : User Options
Parameters : {ActiveSyncDebugLogging, Confirm, ErrorAction, ErrorVariable, Identity, ImapMessagesRetrievalMimeFormat, ImapSuppressReadReceipt, ImapUseProtocolDefaults, OutBuffer, OutVariable, PopMessagesRetrievalMimeFormat, PopSuppressReadReceipt, PopUseProtocolDefaults, ShowGalAsDefaultView, WarningAction, WarningVariable, WhatIf}

Name : Set-CASMailbox
Role : MyBaseOptions
Parameters : {ActiveSyncDebugLogging, Confirm, ErrorAction, ErrorVariable, Identity, ImapMessagesRetrievalMimeFormat, ImapSuppressReadReceipt, ImapUseProtocolDefaults, OutBuffer, OutVariable, PopMessagesRetrievalMimeFormat, PopSuppressReadReceipt, PopUseProtocolDefaults, ShowGalAsDefaultView, WarningAction, WarningVariable, WhatIf}

È interessante notare le differenze nei parametri. Possiamo escludere MyBaseOptions e UserOptions perché i relativi parametri non sarebbero utili per cancellare un dispositivo. Abbiamo già provato con un ruolo figlio di Mail Recipients, che però non ha funzionato. Non resta che provare con il ruolo "Organization Client Access". Si noterà che dispone dell'accesso ai parametri ActiveSyncAllowedDeviceIDs e ActiveSyncBlockedDeviceIDs, che non sono presenti nel ruolo Mail Recipients.

Poiché Set-CasMailbox è elencato nei file, possiamo provare a creare un nuovo ruolo figlio di "Organization Client Access" e a eliminare tutto il resto tranne Set-CasMailbox.

new-managementrole -parent "organization client access" -name OrgClientAccessWipeDeviceOnly
get-managementroleentry "OrgClientAccessWipeDeviceOnly\*" |where{$_.name -notlike "*set-casm*"}| Remove-ManagementRoleEntry

Aggiungiamo ora questo nuovo ruolo al gruppo di ruoli creato in precedenza:

New-ManagementRoleAssignment -Name "OCA Child ActiveSyncDevice Wipe" -SecurityGroup "OnlyActiveSyncDeviceWipe" -Role OrgClientAccessWipeDeviceOnly

Ora quando WipeTest tenta di cancellare il dispositivo, può accedere al pulsante nel Pannello di controllo di Exchange. Resta un problema: StrictlyRecipActiveSyncDeviceWipe (ruolo figlio di "Mail Recipients") dispone ancora di troppi diritti. A questo punto rimuoviamo la maggior parte dei cmdlet da StrictlyRecipActiveSyncDeviceWipe utilizzando il cmdlet seguente:

get-managementroleentry "StrictlyRecipActiveSyncDeviceWipe\*" |where{$_.name -notlike "*activesync*"}| Remove-ManagementRoleEntry

La fase successiva consiste nel riaggiungere i cmdlet nel ruolo uno alla volta finché non riusciamo a spostarci nella posizione appropriata del Pannello di controllo di Exchange e a eseguire una cancellazione dei dispositivi. La routine è semplice: aggiungere un cmdlet e provare l'operazione. Se l'esito è negativo, disconnettersi da OWA, aggiungere un altro cmdlet e ritentare. Quando funziona, possiamo fermarci o tornare indietro e rimuovere i singoli cmdlet per provare a raggiungere un livello minimo di autorizzazioni. Di seguito sono riportati alcuni esempi dei cmdlet che possiamo utilizzare.

Per riaggiungere un cmdlet, è necessario eseguire quanto segue:

add-ManagementRoleEntry "Mail Recipients\get-mailbox" -role StrictlyRecipActiveSyncDeviceWipe

/Aside

Per reinserire più cmdlet, è possibile utilizzare la sintassi dell'esempio seguente:

Get-ManagementRoleEntry "Mail Recipients\*" | where{$_.name -like "get-m*"} | add-ManagementRoleEntry -role StrictlyRecipActiveSyncDeviceWipe

In questo blog desidero semplicemente inserire i cmdlet uno alla volta, ma ho incluso questo esempio a scopo dimostrativo.

/End Aside

Per rimuovere un singolo cmdlet dal ruolo, è possibile utilizzare quanto segue:

Remove-ManagementRoleEntry "StrictlyRecipActiveSyncDeviceWipe\Get-Mailbox"

Quando viene visualizzata la richiesta "Are You Sure?", selezionare Yes o Yes to All.

In questo blog ho incluso numerosi dettagli relativi al modo in cui sono giunto al set finale di cmdlet. Ho lasciato fuori gran parte della serie noiosa di tentativi, ma ritengo di aver inserito dettagli sufficienti per consentirvi di eseguire il processo da soli.

Di seguito ho incollato un riepilogo di tutti i cmdlet per chi desidera vedere tutto in un'unica presentazione concisa:

new-managementrole -parent "Mail Recipients" -name StrictlyRecipActiveSyncDeviceWipe
new-managementrole -parent "organization client access" -name OrgClientAccessWipeDeviceOnly
get-managementroleentry "OrgClientAccessWipeDeviceOnly\*" |where{$_.name -notlike "*set-casm*"}| Remove-ManagementRoleEntry

Quando viene visualizzata la richiesta "Are you sure?", selezionare A.

get-managementroleentry "StrictlyRecipActiveSyncDeviceWipe\*" |where{$_.name -notlike "*activesync*"}| Remove-ManagementRoleEntry

Quando viene visualizzata la richiesta "Are you sure?", selezionare A.

add-ManagementRoleEntry "Mail Recipients\get-mailbox" -role StrictlyRecipActiveSyncDeviceWipe
add-ManagementRoleEntry "Mail Recipients\get-user" -role StrictlyRecipActiveSyncDeviceWipe
add-ManagementRoleEntry "Mail Recipients\get-recipient" -role StrictlyRecipActiveSyncDeviceWipe
add-ManagementRoleEntry "Mail Recipients\get-casmailbox" -role StrictlyRecipActiveSyncDeviceWipe
New-RoleGroup -Name "OnlyActiveSyncDeviceWipe" -Roles StrictlyRecipActiveSyncDeviceWipe,OrgClientAccessWipeDeviceOnly -members WipeTest

Dopo l'esecuzione di questi cmdlet, l'utente WipeTest (oppure l'utente o il gruppo specificato) sarà in grado di aprire OWA, passare al Pannello di controllo di Exchange e visualizzare le singole finestre di dialogo necessarie per raggiungere il punto in cui può cancellare un dispositivo.

Grazie a Matt Byrd e Brad Hughes per avere collaborato con me mentre stavo scrivendo questo post.

Chris Pollitt

Questo è un post di blog localizzato. L'articolo originale è disponibile in RBAC: Walkthrough of creating a role that can wipe ActiveSync Devices.