New-CsAdminRole

Syntax

New-CsAdminRole -Identity <String> -Template <String> [-ConfigScopes <PSListModifier>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-InMemory <SwitchParameter>] [-UserScopes <PSListModifier>] [-WhatIf [<SwitchParameter>]]

Detaillierte Beschreibung

Die rollenbasierte Zugriffssteuerung ermöglicht es Administratoren, die Steuerung spezifischer Verwaltungsaufgaben in Microsoft Lync Server 2010 zu delegieren. Anstatt beispielsweise den Helpdeskmitarbeitern Ihrer Organisation vollständige Administratorrechte zu gewähren, können Sie diesen Mitarbeitern spezielle Rechte erteilen: das Recht zur ausschließlichen Verwaltung von Benutzerkonten; das Recht zur ausschließlichen Verwaltung von Enterprise-VoIP-Komponenten; das Recht zur ausschließlichen Verwaltung von Archivierung und Archivierungsserver. Darüber hinaus können Sie den Gültigkeitsbereich dieser Rechte einschränken: Beispielsweise könnten Sie einem Benutzer das Recht zur Verwaltung der Enterprise-VoIP-Anwendung nur für den Standort Redmond erteilen und einem anderen Benutzer das Recht zum Verwalten ausschließlich der Benutzer, deren Benutzerkonten der Organisationseinheit "Finance" angehören.

Die Lync Server 2010-Implementierung der rollenbasierten Zugriffssteuerung basiert auf zwei Hauptelementen: Active Directory-Sicherheitsgruppen und Windows PowerShell-Cmdlets. Beim Installieren von Lync Server 2010 werden verschiedene universelle Sicherheitsgruppen erstellt, darunter "CsAdministrator", "CsArchivingAdministrator" und "CsHelpDesk". Diese universellen Sicherheitsgruppen entsprechen jeweils einer spezifischen rollenbasierten Zugriffssteuerungsrolle, d. h., dass jedem Benutzer in der Sicherheitsgruppe "CsArchivingAdministrator" die Rechte der Rolle "CsArchivingAdministrator" erteilt werden. Die einer rollenbasierten Zugriffssteuerungsrolle erteilten Rechte basieren wiederum auf den dieser Rolle zugewiesenen Cmdlets. (Cmdlets können mehreren rollenbasierten Zugriffssteuerungsrollen zugewiesen werden.) Angenommen, einer Rolle wurden die folgenden Cmdlets zugewiesen:

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

Diese Liste enthält nur Cmdlets, die von einem Benutzer mit einer hypothetischen rollenbasierten Zugriffssteuerungsrolle während einer Windows PowerShell-Remotesitzung ausgeführt werden dürfen. Wenn der Benutzer versucht, das Cmdlet Disable-CsUser auszuführen, wird ein Fehler zurückgegeben, da Benutzer mit dieser hypothetischen Rolle nicht berechtigt sind, "Disable-CsUser" auszuführen. Gleiches gilt auch für die Lync Server-Systemsteuerung. Ein Archivadministrator kann einen Benutzer beispielsweise nicht über die Lync Server-Systemsteuerung deaktivieren, da die Lync Server-Systemsteuerung den rollenbasierten Zugriffssteuerungsrollen unterliegt. Beim Ausführen eines Befehls in der Lync Server-Systemsteuerung wird tatsächlich ein Windows PowerShell-Cmdlet aufgerufen. Wenn Sie nicht zum Ausführen von Disable-CsUser berechtigt sind, spielt es keine Rolle, ob Sie das Cmdlet direkt aus Windows PowerShell oder indirekt über die Lync Server-Systemsteuerung ausführen: Es tritt immer ein Fehler auf.)

Beachten Sie, dass die rollenbasierte Zugriffssteuerung nur für die Remoteverwaltung gilt. Wenn Sie an einem Computer mit Lync Server 2010 angemeldet sind und die Lync Server-Verwaltungsshell öffnen, werden rollenbasierte Zugriffssteuerungsrollen nicht erzwungen. Stattdessen erfolgt die Erzwingung der Sicherheit primär über die Sicherheitsgruppen "RTCUniversalServerAdmins", "RTCUniversalUserAdmins" und "RTCUniversalReadOnlyAdmins".

Bei der Installation von Lync Server 2010 erstellt das Setupprogramm verschiedene integrierte rollenbasierte Zugriffssteuerungsrollen. Diese decken Routineverwaltungsbereiche wie VoIP-Verwaltung, Benutzerverwaltung und Reaktionsgruppenverwaltung ab. Die integrierten Rollen können nicht verändert werden: Sie können den Rollen keine Cmdlets hinzufügen oder Cmdlets aus diesen entfernen. Ferner können Sie diese Rollen auch nicht löschen. (Der Versuch, eine integrierte Rolle zu löschen, führt zu einer Fehlermeldung.) Sie können jedoch anhand dieser Rollen benutzerdefinierte rollenbasierte Zugriffssteuerungsrollen erstellen. Diese benutzerdefinierten Rollen können anschließend geändert werden, indem die Verwaltungsbereiche geändert werden. So können Sie beispielsweise die Rolle auf die Verwaltung von Benutzerkonten in einer bestimmten Active Directory-OU beschränken.

Um eine neue Rolle zu erstellen, müssen Sie zunächst eine universelle Sicherheitsgruppe in Active Directory-Domänendienste (AD DS) erstellen, die den gleichen Namen wie die Rolle aufweist. Wenn Sie z. B. eine neue Rolle mit dem Namen "DialInConferencingAdministrator" erstellen möchten, müssen Sie zunächst eine Sicherheitsgruppe mit dem Wert "DialInConferencingAdministrator" für "SamAccountName" erstellen. Beachten Sie, dass diese Gruppe nicht von New-CsAdminRole für Sie erstellt wird. Wenn die Gruppe "DialInConferencingAdministrator" beim Aufrufen von New-CsAdminRole nicht vorhanden ist, führt der Befehl zu einem Fehler. Der Identitätswert, den Sie der neuen Rolle zuweisen, muss der "SamAccountName" der entsprechenden Active Directory-Gruppe sein.

Nach dem Erstellen der Active Directory-Sicherheitsgruppe müssen Sie eine integrierte rollenbasierte Zugriffssteuerungsrolle als Vorlage für die neue benutzerdefinierte Rolle auswählen. Sie können keine leere rollenbasierte Zugriffssteuerungsrolle mit New-CsAdminRole erstellen. Alle benutzerdefinierten Rollen müssen vielmehr auf einer der integrierten rollenbasierten Zugriffssteuerungsrollen basieren. Das bedeutet, dass einer benutzerdefinierten Rolle das gleiche Cmdlet zugewiesen sein muss wie einer der integrierten Rollen. Sie können jedoch mit Set-CsAdminRole den Verwaltungsbereich für diese benutzerdefinierte Rolle ändern.

Dieses Cmdlet kann von folgenden Benutzern ausgeführt werden: Standardmäßig dürfen Mitglieder der folgenden Gruppen das Cmdlet New-CsAdminRole lokal ausführen: RTCUniversalServerAdmins. Geben Sie den folgenden Befehl an der Windows PowerShell-Eingabeaufforderung ein, um eine Liste aller rollenbasierten Zugriffssteuerungsrollen zurückzugeben, die diesem Cmdlet zugewiesen wurden (einschließlich der benutzerdefinierten rollenbasierten Zugriffssteuerungsrollen, die Sie selbst erstellt haben):

Get-CsAdminRole | Where-Object {$_.Cmdlets –match "New-CsAdminRole"}

Parameter

Eingabetypen

Keine.

Rückgabetypen

Mit New-CsAdminRole werden neue Instanzen des Objekts "Microsoft.Rtc.Management.WritableConfig.Settings.Roles.Role" erstellt.

Beispiel

-------------------------- Beispiel 1 --------------------------

New-CsAdminRole -Identity "RedmondVoiceAdministrator" -Template "CsVoiceAdministrator"

Der Befehl in Beispiel 1 dupliziert die rollenbasierte Zugriffssteuerungsrolle "CsVoiceAdministrator". Da keine zusätzlichen Parameter verwendet werden, handelt es sich bei der neuen Rolle (RedmondVoiceAdministrators) um eine exakte Kopie von "CsVoiceAdministrator", bei der sowohl die Eigenschaft "UserScopes" als auch die Eigenschaft "ConfigScopes" auf "global" festgelegt sind.

-------------------------- Beispiel 2 --------------------------

New-CsAdminRole -Identity "RedmondVoiceAdministrator" -Template "CsVoiceAdministrator" -UserScopes "OU:ou=Redmond,dc=litwareinc,dc=com"

Mit dem vorstehenden Befehl wird eine neue rollenbasierte Zugriffssteuerungsrolle (RedmondVoiceAdministrator) erstellt, und die Rolle wird anschließend für einen einzigen Benutzerbereich konfiguriert: die OU "Redmond". Hierzu wird der Parameter "UserScopes" zusammen mit dem folgenden Parameterwert verwendet: "OU:ou=Redmond,dc=litwareinc,dc=com". Dieser Parameterwert ersetzt den aktuellen Wert der Eigenschaft "UserScopes" durch ein Element, nämlich die OU mit dem Distinguished Name (DN) "ou=Redmond,dc=litwareinc,dc=com".

-------------------------- Beispiel 3 --------------------------

New-CsAdminRole -Identity "RedmondVoiceAdministrator" -Template "CsVoiceAdministrator" -UserScopes "OU:ou=Redmond,dc=litwareinc,dc=com","OU:ou=Portland,dc=litwareinc,dc=com"

Der Befehl in Beispiel 3 ist eine Variante des Befehls in Beispiel 2; der einzige Unterschied besteht darin, dass in diesem Beispiel der Eigenschaft "UserScopes" zwei OUs hinzugefügt werden. Dies wird erreicht, indem der Replace-Methode eine durch Trennzeichen getrennte Liste zugewiesen wird: die zwei Elemente in der Liste repräsentieren die IDs für die zwei OUs ("Redmond" und "Portland"), die der neuen rollenbasierten Zugriffssteuerungsrolle zugewiesen werden sollen.

-------------------------- Beispiel 4 -------------------------

New-CsAdminRole -Identity "RedmondVoiceAdministrator" -Template "CsVoiceAdministrator" -ConfigScopes "site:Redmond"

In Beispiel 4 wird der Standort mit der ID "Redmond" der Eigenschaft "ConfigScopes" einer neuen rollenbasierten Zugriffssteuerungsrolle zugewiesen. Beachten Sie, dass die Syntax für die Eigenschaft "ConfigScopes" die Verwendung des Präfixes "site:" erfordert, gefolgt vom Wert der Eigenschaft "SiteId" für den hinzuzufügenden Standort.