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.
- Lync RBAC
- RBAC - Role Based Access Control
- AdminSDHolder
- Adminkonzept
- Lync User Provisioning
- Lync Control Panel
- Lync Groupprovisioning
- Lync 2010 - Role-Based Access Control
http://technet.microsoft.com/en-us/library/gg425917.aspx
- Understanding Role Based Access Control
http://technet.microsoft.com/en-us/library/dd298183.aspx - RBAC and the Triangle of Power
http://blogs.technet.com/b/exchange/archive/2009/11/16/453222.aspx -
Planning for role-based access control in Lync Server 2013
https://docs.microsoft.com/en-us/lyncserver/lync-server-2013-planning-for-role-based-access-control
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
- Enable-CsUser : The EXECUTE permission
was denied on the object 'XdsPublishItems',
database 'xds', schema 'dbo'
https://social.technet.microsoft.com/Forums/ie/en-US/6400db50-971b-430d-8430-c052b6191f52/enablecsuser-the-execute-permission-was-denied-on-the-object-xdspublishitems-database-xds?forum=lyncdeploy - The EXECUTE permission was denied on the
object 'XdsPublishItems', database 'xds',
schema 'dbo'
http://communicationsknowledge.blogspot.com/2014/03/the-execute-permission-was-denied-on.html - It’s all about Lync 2013 RBAC
http://www.fots.nl/lync-rbac-role-based-access-control/