Partager via

RBAC : Procédure pas à pas de création d’un rôle capable d’effacer à distance les périphériques ActiveSync

  • Article

Article d’origine publié le mercredi 12 septembre 2012

Une question a souvent été posée ces derniers mois : comment créer des rôles RBAC qui ne présentent qu’une fonctionnalité de gestion ActiveSync très limitée ?

Avant de plonger dans la réponse, rappelons brièvement ce qu’est le RBAC (contrôle d’accès en fonction du rôle).

Avant Exchange 2010, les autorisations étaient définies par le biais d’outils comme DSACLS et ADSIEdit. Cela vous permet de spécifier les objets qu’un utilisateur ou un groupe peut toucher et ce qu’ils pourraient faire à l’objet dans son ensemble. Si un utilisateur avait besoin d’un accès en écriture à une propriété spécifique d’un objet, mais pas aux autres propriétés, la situation était difficile à gérer. Le RBAC ne définit par les autorisations relatives à l’objet. Il définit les autorisations sur les applets de commande PowerShell qui peuvent modifier l’objet. Les applets de commande PowerShell sont ajoutées à un rôle auquel est affecté un utilisateur ou un groupe. Si l’applet de commande et les paramètres dont vous avez besoin font partie d’un rôle auquel vous participez, vous avez la possibilité d’exécuter l’applet de commande.

Dans l’environnement de ligne de commande Exchange Management Shell (EMS), vous pouvez exécuter (get-excommand).count pour voir à combien d’applets de commande Exchange vous avez actuellement accès. Dans le Panneau de configuration Exchange (ECP) et la Console de gestion Exchange les applets de commande auxquelles vous avez accès déterminent les options qui sont affichées. Par conséquent, si une fenêtre dans l’une ou l’autre interface utilisateur exige que vous ayez des applets de commande PowerShell spécifiques dans votre rôle, mais que vous n’en avez pas, deux scénarios sont possibles :

  • La fenêtre n’est pas affichée (en réalité, il est peu probable que les options qui y conduisent soient proposées)
  • La fenêtre s’affiche, mais son contenu est désactivé (ce qui est courant si vous avez les applets de commande Get- pertinentes, mais pas celles de Set, New, Add ou autre)

Pour plus d’informations sur RBAC, veuillez commencer par ce qui suit :

Exchange 2010 SP2 contient 71 rôles RBAC. Toutefois, aucun d’eux n’offre de sous-ensembles limités des commandes ActiveSync pouvant être affectés au personnel de support technique. Pour créer des rôles de ce type, vous devez les maîtriser vous même. Si votre support technique utilise PowerShell, la tâche est relativement aisée car vous pouvez créer un rôle qui ne possède que l’applet de commande PowerShell et les paramètres voulus. Si les utilisateurs opèrent uniquement via le panneau de configuration Exchange (ECP), ce processus est plus complexe, car l’utilisateur doit être capable de naviguer jusqu’au point où l’opération est conduite.

Dans cet exemple, le client avait besoin que le personnel du support technique puisse effacer les périphériques ActiveSync via le panneau de configuration Exchange. Le problème était que seuls les membres du groupe de rôles Gestion des organisations étaient capables de naviguer jusqu’à la fenêtre appropriée de l’ECP pour effectuer un effacement à distance de périphérique. Ajouter les utilisateurs Support technique au groupe de rôles Gestion des organisations était hors de question – il possède trop de droits !

L’administrateur a essayé de créer un rôle RBAC qui ne contenait que l’applet de commande Clear-ActiveSyncDevice. Le problème résidait dans le fait que le nouveau rôle ne leur permettait pas d’accéder à la fonctionnalité via l’ECP. L’ECP n’autorisait pas les utilisateurs à naviguer jusqu’au bouton « Effacer l’appareil » car celui-ci est imbriqué quelques niveaux plus bas. L’utilisateur doit être capable de lister les utilisateurs de l’organisation, de voir leurs propriétés Téléphone et Voix et de pouvoir ouvrir les dialogues en chemin. Un rôle qui contient uniquement l’applet de commande Clear-ActiveSyncDevice n’inclut pas les autres applets de commande qui sont requises par ces autres étapes dans l’ECP. Ensuite, nous devons déterminer ce qu’il faut ajouter à ce rôle pour pouvoir naviguer jusqu’à la fenêtre et cliquer sur le bouton « Effacer l’appareil ».

La première étape de ce processus consiste à regarder de quels rôles se compose le groupe de rôles Gestion des organisations. Pour ce faire, nous exécutons :

[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}

À partir de là, nous devons ignorer les rôles qui ne vont pas être directement liés à l’effacement d’un périphérique. Certains rôles, tels que « Domaines distants et acceptés », ne vont à l’évidence pas contenir d’applets de commande pertinentes. Pour les rôles potentiellement intéressants, notre prochaine étape sera de découvrir ce qu’ils contiennent. Pour ce faire, nous exécutons une applet de commande comme celle-ci :

[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,...

J’ai coupé un extrait de la sortie dont je fournis ici quelques lignes en démonstration (l’appel de commande produit en réalité 96 résultats).

L’étape suivante consiste à créer de nouveaux rôles enfants des rôles dont nous pensons qu’ils sont utiles pour notre travail. Voici un exemple :

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

Le rôle que nous venons de créer est un enfant de Destinataires de message, qui possède donc toutes les autorisations de ses parents. Pourquoi ne pas utiliser directement le rôle Destinataires de message ? À mesure que nous avançons, j’ai l’intention de supprimer des éléments de ce rôle de sorte de réduire autant que possible le niveau d’autorisation. Ne modifiez jamais les rôles intégrés tels que Destinataires de message car cela détruirait la fonctionnalité. Autre point à soulever : un enfant d’un rôle ne peut recevoir que la fonctionnalité de son parent ; il ne peut recevoir aucun droit ou accéder à une fonctionnalité qui n’est pas déjà incluse dans le parent.

Après avoir créé notre rôle nous devons créer un Groupe de rôles. Cela permettra d’assigner plus facilement le rôle aux utilisateurs à l’avenir. Pour notre test, nous utilisons un compte appelé WipeTest. Une fois le test terminé, remplacez WipeTest par le ou les comptes ou groupes voulus.

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

WipeTest peut se connecter à OWA et accéder à l’ECP. Nous constatons que nous pouvons parcourir la quasi totalité du chemin de l’option voulue dans l’ECP, mais pas tout le chemin. Cela indique qu’un rôle supplémentaire est nécessaire.

Si vous regardez dans le répertoire Exchange (c:\Program Files\Microsoft\Exchange par défaut) vous trouverez le chemin suivant « ClientAccess\ecp\PhoneVoice ». Passer en revue certains des fichiers qui s’y trouvent vous donnera des indications sur ce qu’il serait judicieux d’ajouter ensuite. Le fichier Web.Config contient de nombreuses références à OrganizationConfig, mais cela n’est pas suffisamment explicite. Nous pouvons vérifier dans le dossier si l’un des fichiers mentionne des applets de commande spécifiques que nous pourrions utiliser et qui ne figurent pas déjà dans le rôle que nous avons défini. L’applet Set-CasMailbox (qui se trouve dans QuarantinedDevices.ASCX) sort du lot. Nous avons alors vérifié où cette applet de commande réside :

[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}

Il est intéressant de noter les différences de paramètres. Nous pouvons exclure MyBaseOptions et UserOptions car leurs paramètres ne nous aideraient pas à effacer un périphérique. Nous avons déjà essayé un rôle enfant de Destinataires de message et ce rôle n’a pas fonctionné. Il reste donc le rôle « Organization Client Access » que nous pourrions essayer d’utiliser. Vous remarquerez qu’il a accès aux paramètres ActiveSyncAllowedDeviceIDs et ActiveSyncBlockedDeviceIDs et qu’ils ne sont pas présents dans le rôle Destinataires de message.

Puisque nous avons vu Set-CasMailbox figurant parmi les fichiers, nous pouvons essayer de créer un nouveau rôle enfant d’«Organization Client Access » et tout retirer à l’exception de Set-CasMailbox.

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

Nous pouvons maintenant ajouter ce nouveau rôle au groupe de rôles que nous avons créé précédemment :

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

À présent, lorsque WipeTest essaie d’effacer le périphérique à distance, ils peuvent accéder au bouton dans l’ECP. Il reste un problème : StrictlyRecipActiveSyncDeviceWipe (un enfant de « Destinataires de message ») a encore trop de droits. Nous retirons alors la plupart des applets de commande de StrictlyRecipActiveSyncDeviceWipe à l’aide de l’applet de commande suivante :

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

Dans l’étape suivante, nous allons remettre des applets de commandes une par une dans le rôle jusqu’à ce que nous puissions naviguer jusqu’à l’emplacement approprié dans l’ECP et procéder à un effacement de périphérique. Le programme est simple : ajouter une applet de commande, essayer l’opération. Si elle échoue, quitter OWA, ajouter une autre applet de commande et réessayer. Lorsque nous arrivons au résultat voulu, nous pouvons soit arrêter ou revenir en arrière et supprimer des applets de commande individuelles et atteindre un niveau d’autorisation minimum. Ci-dessous quelques exemples des applets de commande que nous pouvons utiliser.

Pour remettre une applet de commande, nous devons procéder comme suit :

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

/Aside

Si vous souhaitez remettre plusieurs applets de commande, vous pouvez utiliser la syntaxe de l’exemple ci-dessous :

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

Dans ce blog, je veux juste insérer les applets de commande l’une après l’autre, mais j’ai inclus ceci dans un but d’illustration.

/End Aside

Pour retirer une applet de commande particulière du rôle, nous pouvons procéder ainsi :

Remove-ManagementRoleEntry "StrictlyRecipActiveSyncDeviceWipe\Get-Mailbox"

(Lorsque l’invite « Are You Sure? » [Êtes-vous sûr ?] apparaît, sélectionnez Yes [Oui] ou Yes to All [Oui à tous])

Dans ce blog, j’ai indiqué de nombreux détails sur la manière avec laquelle j’accède au jeu d’applets de commande final. J’ai laissé de côté la plupart des tentatives infructueuses et des erreurs, mais j’espère avoir inclus suffisamment de détails pour vous permettre de réaliser vous-même le processus.

Ci-dessous j’ai collé un résumé de toutes les applets de commande pour ceux d’entre vous qui veulent disposer d’une présentation unique qui rassemble tout à la fois :

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

(Lorsque l’invite « Are You Sure? » [Êtes-vous sûr ?] apparaît, sélectionnez A)

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

(Lorsque l’invite « Are You Sure? » [Êtes-vous sûr ?] apparaît, sélectionnez 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

Une fois que ces applets de commande sont exécutées, l’utilisateur du WipeTest (ou l’utilisateur ou groupe que vous spécifiez) sera capable d’ouvrir OWA, de naviguer jusqu’au ECP et d’ouvrir chacun des dialogues requis pour atteindre le point leur permettant d’effacer un périphérique à distance.

Merci à Matt Byrd et à Brad Hughes pour leur contribution à la rédaction de ce billet.

Chris Pollitt

Ceci est un billet de blog localisé. L’article d’origine est disponible à l’adresse RBAC: Walkthrough of creating a role that can wipe ActiveSync Devices