New-CsAdminRole
Dernière rubrique modifiée : 2012-03-23
Crée un nouveau rôle RBAC (Contrôle d’accès basé sur un rôle). Les rôles de contrôle d’accès basé sur un rôle (RBAC) sont utilisés pour définir les tâches de gestion que les utilisateurs peuvent réaliser, et pour déterminer l’étendue dans laquelle les utilisateurs sont en mesure de réaliser ces tâches.
Syntaxe
New-CsAdminRole -Identity <String> -Template <String> [-ConfigScopes <PSListModifier>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-InMemory <SwitchParameter>] [-UserScopes <PSListModifier>] [-WhatIf [<SwitchParameter>]]
Description détaillée
Le Contrôle d’accès basé sur un rôle (RBAC) permet aux administrateurs de déléguer le contrôle de tâches de gestion spécifiques dans Microsoft Lync Server 2010. Par exemple, au lieu d’octroyer au personnel du support technique de l’organisation des privilèges d’administrateur complets, vous pouvez lui donner des droits très spécifiques : le droit de gérer uniquement des comptes d'utilisateurs, le droit de gérer uniquement des composants Enterprise Voice, le droit de gérer uniquement l'archivage et le serveur d’archivage. De plus, ces droits peuvent être limités par l’étendue : une personne peut avoir le droit de gérer Enterprise Voice, mais uniquement sur le site de Redmond ; une autre personne peut avoir le droit de gérer les utilisateurs, mais uniquement les comptes des utilisateurs dans l’unité d’organisation Finance.
L’implémentation du contrôle RBAC dans Lync Server 2010 repose sur deux éléments clés : les groupes de sécurité Active Directory et les cmdlets Windows PowerShell. Lorsque vous installez Lync Server 2010, certains groupes universels de sécurité sont créés pour vous : CsAdministrator, CsArchivingAdministrator et CsHelpDesk, etc. Ces groupes universels de sécurité disposent d’une correspondance exacte avec des rôles RBAC : cela signifie que tout utilisateur du groupe de sécurité CsArchivingAdministrator bénéficie des droits octroyés au rôle RBAC CsArchivingAdministrator. Les droits accordés au rôle RBAC sont à leur tour basés sur les cmdlets affectées à ce rôle (vous pouvez affecter des cmdlets à plusieurs rôles RBAC). Par exemple, imaginons que les cmdlets suivantes aient été affectées à un rôle :
Get-ArchivingPolicy
Grant-ArchivingPolicy
New-ArchivingPolicy
Remove-ArchivingPolicy
Set-ArchivingPolicy
Get-ArchivingConfiguration
New-ArchivingConfiguration
Remove-ArchivingConfiguration
Set-ArchivingConfiguration
Get-CsUser
Export-CsArchivingData
Get-CsComputer
Get-CsPool
Get-CsService
Get-CsSite
La liste ci-dessus ne répertorie que les cmdlets qu’un utilisateur assigné à un rôle RBAC hypothétique peut exécuter au cours d’une session Windows PowerShell. Si l’utilisateur tente d’exécuter la cmdlet Disable-CsUser, cette commande échouera ; ceci est dû au fait que les utilisateurs auxquels le rôle hypothétique a été affecté n’ont pas le droit d’exécuter Disable-CsUser. Cela s’applique également au Panneau de configuration Lync Server. Par exemple, un administrateur d’archivage ne peut pas désactiver un utilisateur à l’aide du Panneau de configuration Lync Server (ceci parce que le Panneau de configuration Lync Server est conforme aux rôles RBAC). Chaque fois que vous exécutez une commande dans le Panneau de configuration Lync Server, vous appelez en fait une cmdlet Windows PowerShell. Si vous n’êtes pas autorisé à exécuter Disable-CsUser, peu importe si vous exécutez directement cette cmdlet depuis Windows PowerShell ou si vous l’exécutez indirectement la cmdlet depuis le Panneau de configuration Lync Server : cette commande échouera.
Notez que le contrôle d’accès basé sur un rôle (RBAC) ne s’applique qu’à la gestion à distance. Si vous êtes connecté à un ordinateur équipé de Lync Server 2010 et ouvrez Lync Server Management Shell, les rôles RBAC ne sont pas appliqués. Au lieu de cela, la sécurité est principalement renforcée par le biais des groupes de sécurité RTCUniversalServerAdmins, RTCUniversalUserAdmins et RTCUniversalReadOnlyAdmins.
Lorsque vous installez Lync Server 2010, le programme d'installation crée plusieurs rôles RBAC intégrés. Ces rôles couvrent des tâches administratives courantes comme l'administration de la voix, la gestion des utilisateurs et l'administration Response Group. Ces rôles intégrés ne peuvent en aucune manière être modifiés : il n’est pas possible d’ajouter ou de supprimer des cmdlets ni de supprimer ces rôles (Tout essai de supprimer un rôle intégré générera une erreur.) Cependant, vous pouvez utiliser les rôles intégrés pour créer des rôles RBAC personnalisés. Ces rôles personnalisés peuvent être modifiés en changeant les étendues d’administration. Par exemple, il est possible de limiter le rôle de gestion des comptes d’utilisateur à une unité d’organisation Active Directory particulière.
Pour créer un nouveau rôle, vous devez d’abord créer un groupe de sécurité universel dans services de domaine Active Directory (AD DS) qui partage un nom avec le rôle. Par exemple, pour créer un nouveau rôle appelé DialInConferencingAdministrator, vous devez créer un groupe de sécurité avec le nom SamAccountName DialInConferencingAdministrator. Notez que New-CsAdminRole ne créera pas ce groupe pour vous. Si le groupe DialInConferencingAdministrator n'existe pas lorsque vous appelez New-CsAdminRole, votre commande échouera. L’identité que vous affectez à votre nouveau rôle doit être le nom SamAccountName du groupe Active Directory correspondant.
Après avoir créé le groupe de sécurité Active Directory, vous devez sélectionner un rôle RBAC intégré qui servira de modèle pour votre nouveau rôle personnalisé. Il n’est pas possible de créer un rôle RBAC vide à l’aide de la cmdlet New-CsAdminRole. Au lieu de cela, tous les rôles personnalisés doivent être basés sur l’un des rôles RBAC intégrés. Cela signifie que les cmdlets affectées à un rôle personnalisé doivent être identiques à l’un des rôles intégrés. Cependant, vous pouvez utiliser Set-CsAdminRole pour modifier le rôle administratif de ce rôle personnalisé.
Personnes autorisées à exécuter cette cmdlet : Par défaut, les membres des groupes qui suivent sont autorisés à exécuter localement la cmdlet New-CsAdminRole : RTCUniversalServerAdmins. Pour retourner une liste de tous les rôles RBAC (Contrôle d’accès basé sur un rôle) auxquels cette cmdlet a été affectée (y compris les rôles RBAC personnalisés créés par vos soins), exécutez la commande suivante à l’invite Windows PowerShell :
Get-CsAdminRole | Where-Object {$_.Cmdlets –match "New-CsAdminRole"}
Paramètres
Paramètre | Obligatoire | Type | Description |
---|---|---|---|
Identity |
Obligatoire |
Chaîne |
Identificateur unique du rôle RBAC à créer. L’identité d’un rôle RBAC doit être identique au nom SamAccountName du groupe de sécurité universel Active Directory associé à ce rôle. Par exemple, l’identité du rôle Help Desk (support technique) est égale à CsHelpDesk. CsHelpDesk est également le SamAccountName du groupe de sécurité Active Directory associé à ce rôle. |
Template |
Obligatoire |
Chaîne |
Nom du rôle RBAC intégré qui servira de modèle pour le rôle RBAC personnalisé qui est créé. Tous les nouveaux rôles RBAC doivent être basés sur un rôle existant. Il n’est pas possible de créer un rôle RBAC « vide » (c’est-à-dire, un rôle non affecté à une cmdlet ou comportant une propriété ConfigScope ou UserScope sans valeur affectée). Cependant, une fois le rôle personnalisé créé, vous pouvez utiliser la cmdlet Set-CsAdminRole pour modifier ses propriétés. |
ConfigScopes |
Facultatif |
Modificateur de liste PS |
Utilisé pour limiter l’étendue de la cmdlet aux paramètres de configuration sur le site spécifié. Pour limiter l’étendue de la cmdlet à un seul site, utilisez une syntaxe semblable à ceci : -ConfigScopes site:Redmond. Vous pouvez spécifier plusieurs sites avec une liste séparée par des virgules : -ConfigScopes « site:Redmond », « site:Dublin ». Vous pouvez également définir la propriété ConfigScopes sur « global ». Lorsque vous affectez une valeur au paramètre ConfigScopes, vous devez utiliser le préfixe « site: », suivit de la valeur de la propriété SiteId pour le site. Notez que la valeur SiteID n'est pas nécessairement identique à celle de la propriété Identity ou DisplayName du site. Pour déterminer la valeur SiteId d'u site donné, vous pouvez utiliser une commande similaire à celle-ci : Get-CsSite "Redmond" | Select-Object SiteId Vous devez spécifier une valeur pour l’une des propriétés (ou les deux) ConfigScopes et UserScopes. |
UserScopes |
Facultatif |
Modificateur de liste PS |
Utilisé pour limiter l’étendue de la cmdlet aux activités de gestion des utilisateurs dans l’unité d’organisation spécifiée. Pour limiter l’étendue de la cmdlet à une unité d’organisation unique, utilisez la syntaxe suivante : -UserScopes « OU:ou=Redmond,dc=litwareinc,dc=com ». Vous pouvez spécifier des unités d’organisation en utilisant une liste séparée par des virgules : -UserScopes « OU:ou=Redmond,dc=litwareinc,dc=com », « OU:ou=Dublin,dc=litwareinc,dc=com ». Pour ajouter de nouvelles étendues (ou supprimer des étendues existantes) d’un rôle, vous devez utiliser la syntaxe des modificateurs de liste Windows PowerShell. Pour plus d’informations, consultez les exemples de cette rubrique d'aide. Vous devez spécifier une valeur pour l’une des propriétés (ou les deux) ConfigScopes et UserScopes. |
Force |
Facultatif |
Paramètre de commutateur |
Supprime l’affichage de tous les messages d’erreur récupérable susceptibles d’apparaître lors de l’exécution de la commande. |
InMemory |
Facultatif |
Paramètre de commutateur |
Crée une référence d’objet sans valider l’objet comme une modification définitive. Si vous affectez à une variable la sortie de cette cmdlet appelée avec ce paramètre, vous pouvez apporter des modifications aux propriétés de la référence d’objet, puis les valider en appelant la cmdlet Set- correspondante. |
WhatIf |
Facultatif |
Paramètre de commutateur |
Décrit ce qui se passe si vous exécutez la commande sans l’exécuter réellement. |
Confirm |
Facultatif |
Paramètre de commutateur |
Vous demande confirmation avant d’exécuter la commande. |
Types d’entrées
Aucun.
Types de retours
New-CsAdminRole crée de nouvelles instances de l’objet Microsoft.Rtc.Management.WritableConfig.Settings.Roles.Role.
Exemple
-------------------------- Exemple 1 ------------------------
New-CsAdminRole -Identity "RedmondVoiceAdministrator" -Template "CsVoiceAdministrator"
La commande illustrée dans l’exemple 1 duplique le rôle RBAC CsVoiceAdministrator. Du fait qu'aucun paramètre supplémentaire n'est utilisé, le nouveau rôle RedmondVoiceAdministrators sera un doublon exact de CsVoiceAdministrator, qui inclut les propriétés UserScopes et ConfigScopes définies sur « global ».
-------------------------- Exemple 2 ------------------------
New-CsAdminRole -Identity "RedmondVoiceAdministrator" -Template "CsVoiceAdministrator" -UserScopes "OU:ou=Redmond,dc=litwareinc,dc=com"
La commande précédente crée un nouveau rôle RBAC (RedmondVoiceAdministrator), puis configure le rôle afin qu’il autorise une seule étendue Utilisateur : l’unité d’organisation (OU) de Redmond. Pour ce faire, le paramètre UserScopes est inclus conjointement avec la valeur de paramètre suivante : « OU:ou=Redmond,dc=litwareinc,dc=com ». Cette valeur de paramètre remplace la valeur actuelle de la propriété UserScopes par un élément : l’unité d’organisation (OU) portant le nom unique (DN) « ou=Redmond,dc=litwareinc,dc=com ».
-------------------------- Exemple 3 ------------------------
New-CsAdminRole -Identity "RedmondVoiceAdministrator" -Template "CsVoiceAdministrator" -UserScopes "OU:ou=Redmond,dc=litwareinc,dc=com","OU:ou=Portland,dc=litwareinc,dc=com"
La commande illustrée dans l’exemple 3 est une variante de la commande citée dans l’exemple 2. La seule différence ici est l’ajout de deux unités d’organisation à la propriété UserScopes. Cette opération est effectuée en affectant une liste séparée par des virgules à la méthode Replace : les deux éléments de la liste représentent les identificateurs des deux unités d'organisation (Redmond et Portland) à affecter au nouveau rôle RBAC.
-------------------------- Exemple 4 ------------------------
New-CsAdminRole -Identity "RedmondVoiceAdministrator" -Template "CsVoiceAdministrator" -ConfigScopes "site:Redmond"
Dans l'exemple 4, le site avec l'identificateur SiteId Redmond est affecté à la propriété ConfigScopes pour un nouveau rôle RBAC. Notez que la syntaxe pour la propriété ConfigScopes nécessite l'utilisation du préfixe « site: » suivi de la valeur de la propriété SiteId pour que le site soit ajouté.