SfB Provisioning und XDSPublishItems

Die Verwaltung von Skype for Business-Anwendern wird ein Administrator nur am Anfang noch von Hand machen. Irgendwann werden Sie diesen Prozess aber automatisieren. Hier können Sie manchmal ein seltsames Verhalten feststellen.

Enable-CSUser und mehr

Um einen Benutzer für Skype for Business zu aktivieren, benötigen Sie natürlich die entsprechenden Berechtigungen. Skype for Business hat dazu eine eine etwas abgeschwächte RBAC-Funktion, bei der Sie ihre Befehle an den den Skype for Business Server per CSCP oder PowerShell übergeben und der Server dann mit seinen privilegierten Rechten die Aktionen ausführt. Dazu habe ich schon auf verschiedenen Seiten etwas geschrieben. Ursprünglich dürften die Exchange Entwickler wieder für die Einführung dieser Verwaltungsmethode gesorgt haben, damit Administratoren eben nicht mehr an den offiziellen Tools vorbei per LDAP oder ADSIEDIT an den Fehlern Veränderungen vornehmen.

Entsprechend der Vorgaben von Microsoft gibt es dann auch in Skype for Business entsprechende "RoleGroups", die bestimmte Berechtigungen steuern.

PS C:\> Get-CsAdminRole | ft identity

Identity
--------
CSAdministrator
CSVoiceAdministrator
CSUserAdministrator
CSResponseGroupAdministrator
CSLocationAdministrator
CSArchivingAdministrator
CSViewOnlyAdministrator
CSServerAdministrator
CSHelpDesk
CSResponseGroupManager
CsPersistentChatAdministrator

Passend dazu gibt es in der Root-Domain dann auch dazu passende Gruppe:

Sie müssen also "nur" ihren Anwender in die entsprechende Gruppe addieren, damit er die Funktionen ausüben kann. In meinem Fall möchte ich nun einem Dienstkonto das Recht geben, per PowerShell die Benutzer zu verwalten. Ich addiere also einfach das Dienstkonto in die Gruppe "CSUserAdministrator". Gemäß de Aussagen auf "https://docs.microsoft.com/de-de/lyncserver/lync-server-2013-planning-for-role-based-access-control" sollte das Konto dann folgende Funktionen ausüben können:


Quelle: https://docs.microsoft.com/de-de/lyncserver/lync-server-2013-planning-for-role-based-access-control

Sie ahnen sicher schon, dass das nur die halbe Wahrheit ist.

Fehler bei Enabled-CSUser

Da ich die Verwaltung der Benutzer nicht von Hand machen wollte, gibt es ein PowerShell-Script, welches die Mitglieder eine Gruppen ausliest und die Mitglieder für Skype for Business aktiviert. Sowohl beim "Enabled-CSUser" als auch bei "Disable-CSUser" bin ich aber auf einen Fehler gelaufen

Enable-CsUser : The EXECUTE permission was denied on the object 'XdsPublishItems', database 'xds', schema 'dbo'. At line:1 char:1 

Dabei stelle ich mir natürlich die Frage, was die Powershell hier versucht. Ich hatte mich per "Remote PowerShell" mit dem Skype for Business Server verbunden aber anscheinend versucht die PowerShell dennoch auch noch eine direkte SQL-Verbindung zum Backend-Server und will dort eine Stored Procedure starten. Einen genauen Grund dazu konnte ich noch nicht ermitteln. Nur einige Hinweise im Internet sagen mir, dass der Fehler auch bei anderen Installationen vorkommt.

Testweise habe ich das Skript dann als Administrator gestartet und hier kam es zu keinen Fehlern. Es kann also weder eine fehlende Softwarekomponente oder falsche Programmierung sein, sondern es muss an fehlenden Berechtigungen liegen.

Interessanterweise waren die Anwender auch mit der Fehlermeldung im Active Directory komplett und korrekt provisioniert. Auch der Lync User Replicator hat die AD-Änderungen in die SQL-Datenbank übertragen und es war keine Einschränkung der Funktion ersichtlich. Insofern bin ich nicht sicher, ob die "XdsPublishItems"-Funktion einfach nur ein Überbleibsel ist.

SQL-Rechte

Also war es an der Zeit die erforderlichen Berechtigungen im SQL-Server nachzuschauen. Über das Enterprise Studio habe ich in der "XDS"-Datenbank die "Stored Procedues" und damit verbundenen Berechtigungen angezeigt. Zuerst fand ich, dass der aufrufende Prozess die "PublisherRole" innehaben muss

Über die Konfiguration der Datenbank selbst können Sie dann erkennen, dass die Gruppe der "RTCUniversalServerAdmins" dieses Recht hat.

In der Gruppe waren alle Frontend-Server der Installation enthalten. Die Gruppe der "CSUserAdministratoren" war allerdings nicht enthalten. Hier scheint RBAC also nicht zum Einsatz zu kommen. Würde nämlich der Skype for Business Server selbst die "Stored Procedure" starten, dann gäbe es auch keine Fehler.

Allerdings ist die Gruppe durchaus umfangreich berechtigt. Die Beschreibung der Windows Sicherheitsgruppe sagt dazu:

Members can manage all aspects of RTC servers in this forest.

Das sind also durchaus mehr Berechtigungen, als ich eigentlich vergeben möchte.

Root Cause

An vielen Stellen steht, dass RBAC nicht zum Einsatz kommt, wenn ich direkt auf dem Server eine Skype for Business PowerShell starte. In meinem Fall war dies aber nicht auf einem Server sondern auf einer Management-Station, auf der aber die Skype for Business AdminTools installiert waren. Wenn ich also direkt eine PowerShell gestartet habe, dann waren die Skype for Business Commandlets dennoch vorhanden. Natürlich habe ich mit eine Remote Skype for Business PowerShell mit folgenden Befehlen eingebunden:

[string]$lyncuri = "https://sfb01.msxfaq.de/ocspowershell"
$session = new-pssession `
   -ConnectionUri $lyncuri `
   -Authentication NegotiateWithImplicitCredential
import-pssession `
   -Session $session `
   -AllowClobber

Ein "Get-Command Enable-CSUser" hat auch angezeigt, dass das Commandlet aus der Session importiert wurde. Dennoch scheint irgendwie die lokale Installation immer noch einen Einfluss darauf gehabt zu haben. Wenn ich die Zeilen für eine "Remote Lync PowerShell" aber auf einem Server ausgeführt habe, auf der keine Skype for Business Admin Tools installiert waren, dann konnte ich die Befehle problemlos ausführen.

Wenn ich irgendwann verstanden habe, was die PowerShell und die Skype for Business AddOns hier durcheinanderbringen werde ich die Seite aktualisieren.

Abhilfe

Was nun genau das Verhalten verursacht, habe ich nicht weiter untersucht. Für mich bedeutet das aber einfach, dass allein die Mitgliedschaft in "CSUserAdministrator" nur dann funktioniert, wenn die "Remote Lync Powershell" auf einem System genutzt wird, auf dem keine lokale "Skype for Business PowerShell" installiert ist. Auch wenn diese "eigentlich" gar nichts genutzt wird, scheint Powershell hier dennoch auf lokale Komponenten zurück zu greifen.

Wenn ein Service auf einem Skype for Business Server bestimmte Aktionen ausführen muss, zu denen die PowerShell eine Verbindung zum SQL-Server aufbaut, dann muss das Dienstkonto eben auch in die Gruppe "CSUserAdministratoren" aufgenommen werden. Das ist was nicht "schön", aber der Weg ist auf jeden Fall besser nachzuvollziehen und auch einfach reversibel. Änderungen an den Berechtigungen im SQL-Server sind aus meiner Sicht der schlechtere Weg.

Weitere Links