Lync RBAC

Sowohl Lync 2010 als auch Lync 2013 nutzen beide RBAC zur Delegierung von Berechtigungen. Zwar können sie auch direkt bei den Benutzern im AD die MSRTC-Felder bearbeiten, aber unterstützt ist das nicht mehr. Es ist auch nicht sinnvoll, da die PowerShell Commandlets einige Validierungen vornehmen und so falsche Daten gleich im Ansatz verhindert werden. Zudem werden die Änderungen dann durch den Lync Server "im Auftrag" und nicht mehr durch den Benutzer direkt verändert. So reduziert sich das Risiko, dass ein Virus o.ä. per LDAP direkt die Felder verändert. Zumindest wenn sie nicht anderweitig, z.B. als Domänen Administrator, sowieso zu viele Rechte für den Tagesbetrieb haben.

Vordefinierte Rollen

Die Verwaltung von Lync RBAC-Rollen erfolgt alleine über die PowerShell. Es gibt keine passende GUI dazu und dies ist in der Regel auch gar nicht erforderlich. Lync liefert von Hause aus eine ganze Menge vordefinierte Rollen mit, die in den meisten Umgebungen vollkommend ausreichend sind. Die meisten Administratoren werden zumindest die Rolle "CSAdministrator" können, in die Sie sich der Installation addiert haben, um überhaupt Lync Verwalten zu können. Denn auch das Lync Control Panel berücksichtigt die RBAC-Berechtigungen.

Ich möchte hier nun nicht alle Rollen im Detail wieder geben. Diese hat Microsoft ausreichend dokumentiert.

Zu jeder der Rollen gibt es eine Windows Sicherheitsgruppe, die mit der RBAC-Rolle verbunden ist. Diese liegt normal in der UserS-OU der Root-Domäne oder was immer sie beim Setup angegeben haben.

An diesen Rollen sollten Sie auch nichts ändern. Wenn Sie diese nicht mögen, dann lassen Sie einfach die Gruppen leer und legen ihre eigenen RBAC-Rollen an, wie ich später noch zeige.

RBAC bei CSCP

DAs Lync Control Panel zeigt sehr einfach an, welche Rollen jemand hat. Wer in gar keiner Rolle ist, kommt schon gar nicht an die Weboberfläche ran. Etwas versteckt ist aber links unten der Link zum "Sign in as a different User". Per Default nutzt das CSCP natürlich schon die integrierte Authentifizierung.

Wenn Sie in mindestens einer der CS-Gruppen sind, dann können Sie sich aber anmelden und auf dem Startbildschirm gleich ihre Rollen anzeigen lassen

Hinweis Änderungen an Gruppenmitgliedschaften werden von RBAC im laufenden Betrieb ausgewertet. Sie müssen sich nicht unter Windows "neu anmelden".

Hier bin ich nur mal in CSHelpDesk, was mir schon einen umfangreichen Einblick gewährt aber natürlich nur lesend. Andere Rollen erlauben in Teilbereichen den Schreibzugriff.

Rollen, Commandlets und Scopes

Sie wissen nun schon, dass es zu jeder RBAC-Rolle eine Windows Sicherheitsgruppe gibt, deren Mitglieder die Rechte bekommen. Anders als bei Exchange sind die Rollen und Verkettungen von Lync deutlich einfacher als bei Exchange. Schauen wir uns mal eine Rolle an

PS C:\> Get-CsAdminRole cshelpdesk

Identity       : CSHelpDesk
SID            : S-1-5-21-119234234-30211239-722211411-64877
IsStandardRole : True
Cmdlets        : {Name=Get-CSAccessEdgeConfiguration, Name=Get-CsAdContact, Name=Get-CSAddressBookConfiguration,
                 Name=Test-CsAddressBookService...}
ScriptModules  : {}
ConfigScopes   : {Global} UserScopes     : {Global}
Template       :

Mal abgesehen von dem Namen in Form der Identity und der SID, die auf die Windows Gruppe verlinkt, gibt es die Properties "Cmdlets", die die Commandlets namentlich aufführt, optionale SkriptModule und die beiden Scopes für User und Config. Es findet also keine Verschachtelung a la Exchange (Stichwort "Triangle of Power") statt, sondern eine Rolle fasst einfach eine menge von Commandlets zusammen, die optional auf Bereiche (Scope) beschränkt wird. Anders als bei Exchange kann man auch nicht auf einzelne Parameter eines Commandlet filtern.

Der Lync Anwender selbst ist hier im Gegensatz zu Exchange auch nicht präsent. Er kann über SIP über seinen ganz einfach seine individuellen Einstellungen (z.B. Rufweiterleitung, Parallelanruf, Lync Photo etc.) einrichten. Bei Exchange gibt es ja sogar dafür RBAC Rollen, damit der Anwender Aktionen auf seinem Postfach per ECP ausführen darf. (Stichwort "Self Service")

Adminkonzept

Gehen wir mal nicht von der XXL-Firma aus, in der sich viele Administratoren um die Systeme kümmern, dann kommen wir von den vordefinierten Rollen mit zwei oder drei Typen aus.

  • Voller Admin
    Dieses Recht sollten nur die Personen haben, die wissen, was sie tun.
  • User Admin, teils ändern, teil Helpdesk Only
    Eventuell delegieren Sie Rechte zur Verwaltung der Benutzer an dezentrale Administratoren. Hier kann es dann schon dazu kommen, dass Sie z.B. Rollen anlegen wie "CSUserAdmin EMEA, CSUserAdmin APAC, CSUserAdmin DACH, CSUserAdmin uS", die dann die CSUserAdministrator-Rolle als Template verwenden und den Scope auf die entsprechenden OUs legen.
  • Monitoring
    Eine Rolle, die Microsoft nicht als "Standard" vorgesehen hat, die ich aber immer mit aufführe, ist der Zugriff auf die CDR/QoE-Datenbank. Bei der Installation der Reporing Services wird ja schon eine Gruppe für den Zugriff definiert. Diese ist quasi auch eine "Rolle", die sogar besonders zu schützen. ist.

Ich selbst hatte bislang noch nicht damit zu tun, dass die Rolle "CSVoiceAdministrator" gesondert delegiert wurde, d.h. dass eine Person nur die für Telefonie relevanten Funktionen konfigurieren durfte. So eine Trennung mag zutreffen, wenn sich die Abteilungen für IT-Services und Telefonanlage gemeinsam um Lync kümmern sollen und sich vielleicht nicht grün sind. Oft sind aber gerade die Einstellungen im Backend (Konfiguration) nach einiger Einschwingzeit sehr statisch und es werden nur noch die Benutzer selbst verändert.

Wie kann ich administrieren ?

Es gibt verschiedene Wege, wie Sie die Einstellungen in Lync verändern können. Wenn wir nun den Topologiebuilder zur Pflege der Topologie und den Deployment Wizard zum Aufspielen der Dienste einmal außen vor lassen, bleiben für die Verwaltung von Lync immer noch ein paar Wege übrig. Ein Teil der Einstellungen werden von Lync in der SQL-Datenbank abgelegt und andere an AD-Objekten gespeichert.

Zugang Beschreibung Config User

CSCP

Das Silverlight-basierte Controlpanel wird für die meisten Lync Administratoren das erste Mittel der Wahl sein. Es lässt sich damit zwar nicht alles einrichten, vor allem keine RBAC-Rollen aber ich würde sagen, dass man damit 90% aller Tätigkeiten ausführen kann. Allerdings ist es "interaktiv" und müssenÄnderungen sind damit nicht wirklich möglich. Das CSCP zeigt ihnen nur an, was Sie per RBAC-Richtlinie auch ausführen dürfen.

Ja

Ja

Lync PS

Wer größere Änderungen durchführen will, ist mit der PowerShell deutlich besser bedient. Wer sich einmal damit beschäftigt hat, wird sehr schnell immer mehr damit erledigen oder sogar per Skript umsetzen und automatisieren. Auch hier werden die RBAC-Rollen beachtet

Ja

Ja

Provisioning

Je größer eine Firma wird, desto eher erfolgt die Verwaltung der Benutzer nicht mehr manuell sondern über ein Provisioning. Das kann ein Metadirectory wie FIM sein, eine Verwaltung wie Quest Active-Roles, Arvato Bizzpro oder auch einfach nur eigene Skripte, die per Taskplaner immer wieder eine Logik ausführen. Hier lassen sich dann auch feinere Abstufungen von Rechten und Prozessen abbilden und der ausführende Prozess hat die RBAC-Rechte.

Ja

Ja

ADSI

Es soll immer noch Administratoren geben, die per ADSI oder LDAP direkt die Objekte im Active Directory verändern. Wenn man genau weiß, was man da tut, dann ist das sogar möglich. Allerdings stecken Sie viel Zeit in die Validierung von Werten, die die Lync PowerShell Commandlets ihnen schon abnehmen. Und so schwer ist die Delegierung ja auch nicht. Ein rein lesender Zugriff ist unkritisch aber ein schreibender Zugriff ist meines Wissens nicht mehr supportet.

Nein

Ja

Welchen Weg sie letztlich nehmen, bleibt ihnen überlassen. Wenn es kein Provisioning oder Metadirectory gibt oder die Verbindung damit nicht hergestellt ist, dann bleibt für kleine Änderungen das Controlpanel (CSCP) und für müssenÄnderungen einfach die Lync PowerShell

*-CSAdminRole

Mit diesem Commandlet legen Sie eine neue Lync Adminrolle basierend auf einem Template an. Ehe Sie aber gleich loslegen können, müssen Sie manuell zuerst eine universelle Windows Sicherheitsgruppe mit gleichem Namen anlegen. Ansonsten klappt schon das Anlege mit New-CSAdminRole nicht

New-CsAdminRole : Security group not found für the given "sAMAccountName" :
"cstestc".Cannot save role-based access control (RBAC) role because the
associated security group does not exist in Active Directory. Create the
security group in Active Directory and then try again.
New-CsAdminRole : "CSTestFC" is not a universal security group. To use a group für a role-based access control (RBAC) role, the group must be a universal
security group.

Das Template sorgt bei Lync 2013 nur dafür, dass die Liste der Commandlets vorausgefüllt wird. Sie können jederzeit den Inhalt von "Templates" bei Lync 2013 selbst komplett ändern. Bei Lync 2010 war dies noch beschränkt und vom Template abhängig.

Wenn jemand in mehreren Lync Gruppen Mitglied ist, so addieren sich die Rechte. Es gibt kein "Deny" auf Commandlets.

Allerdings muss der Name des Commandlets natürlich gültig sein. Das wird beim Set-CSAdminRole geprüft und mit einer Warnung quittiert:

WARNING: The role-based access control (RBAC) role 'CSTestFC' cannot contain
'get-conferenc', because 'get-conferenc' is not a Lync Server cmdlet. Only Lync
 Server cmdlets can be added to the role.

Der Name der Gruppe wird beim Anlegen der Lync RBAC-Rolle im AD gesucht. Mit dem erfolgreichen Match wird in Lync aber die SID der Gruppe gespeichert.

Ich konnte keine abschließende Quelle finden, die ein verschieben der Gruppe in eine andere Domäne (ADMT, SIDHistory) oder OU oder gar ein Rename der Windowsgruppe behandelt. Ein Verschieben in der Domäne sehe ich unkritisch, da die SID und der SAMAccountName unverändert bleiben. Die Default Gruppen würde ich aber nicht verschieben. Daher sollten Sie vielleicht einfach bei der Neuanlagen von AdminRollen die Windows Gruppen vorher am gewünschten Platz anlegen.

Wurde eine Gruppe umbenannt, dann wird dies beim Get-CSAdminRole angezeigt aber beim Remove-CSAdminRole gibt es Probleme

Identity : CSTestFC2
SID : S-1-5-21-113445649-30445629-71842111-8902
IsStandardRole : False
Cmdlets : {Name=Get-CsConferenceDirectory}
ScriptModules : {}
ConfigScopes : {Global} UserScopes : {Global}
Template : csUseradministrator

PS C:\> remove-CsAdminRole cstestfc2
WARNING: Cannot find role-based access control (RBAC) role in the Central
Management Store with "Identity": "cstestfc2".

PS C:\> remove-CsAdminRole cstestfc
Performing operation "Remove-CsAdminRole" on Target "cstestfc".

Anscheinend ist der originale SAMAccountName in der Datenbank hinterlegt. Vorsicht also beim Rename einer Lync-Gruppe.

Die Windows Gruppe wird durch Remove-CSAdminRole nicht gelöscht !

Get-CsAdminRoleAssignment

Wenn Sie schnell eine Information erhalten wollen, welcher Benutzer welche Rollen innehat, können Sie natürlich einfach dessen "MemberOf"-Attribut auswerten. Wenn Sie die Lync Admingruppen z.B. anhand eine Namensprefix identifizieren können, dann geht das auch recht schnell. Umgekehrt könnten Sie einfach alle Lync Adminrollen durchgehen und deren "member" auslesen. Auf die schnelle hat aber auch die Lync PowerShell ein passendes Commandlet, dem Sie den SAMAccountName des fragliches Benutzers übergeben müssen

Die Ausgabe ist aber ziemlich ernüchternd.

PS > Get-CsAdminRoleAssignment adm-carius
netatwork\CSAdministrator
netatwork\CSServerAdministrator

Zwar weist auch die Microsoft Hilfe darauf hin, wie man mit Get-CSUser und einer Verkettung eine Liste aller Lync User zu Adminrollen herstellt, aber sinnvoller ist hierbei sicher die Analyse der Lync Gruppen und der Auflösung der Member

Get-CsAdminRole | %{
   $group=$_.identity ; 
   Get-ADGroupmember $_.identity -recursive | 
      %{
      new-object psobject `
         -property @{"group"=$group; "member"=$_.samaccountname}
      }
}

Weitere Links