Herstellen Team Member Lizenzkompatibilität
Nachdem nun feststeht welche Systembenutzer konform mit der TML sind und welche nicht, stellt sich die nächste entscheidende Frage: für welche Benutzer/-gruppen kommt dieser Lizenztyp überhaupt infrage? Und weiter: Wie können diese “kompatibel” mit dem Team Member Lizenztyp gemacht werden?
Kurzfassung: Es müssen spezialisierte, mit der TML konforme, Benutzerrollen konzipiert werden (1) und anschliessend entsprechende Sicherheitsrollen implementiert werden (2).
Konzeption
Es gibt hierbei keine Musterlösung, vielmehr ist dieser Reviewprozess so individuell wie die möglichen kundenspezifischen Anwendungsbereiche von Dynamics 365 selbst. Dabei hilfreich ist ein gut dokumentiertes Sicherheitskonzept, welches neben den eher technischen Sicherheitsrollen insbesondere auch typische Benutzerrollen (Personas) im Kontext Ihrer Dynamics 365 Lösung beschreibt. Letztere sind Grundlage für eine erste grobe Kosten-Nutzen-Rechnung, um die zu erwartenden Aufwände für Review und Rekonzeption des Sicherheitskonzepts den möglichen Einsparungen durch die günstigeren TML gegenüber zu stellen. Trotz möglicher Einsparungen von bis zu 80% pro Benutzer, lohnen umfangreiche Rekonzeptionsmassnahmen am Sicherheitskonzept sowie dessen Implementierung meist nur ab einer gewissen (höheren) Benutzerzahl.
Bei der Suche nach Optimierungspotenzial können folgende offensichtliche Indikatoren zur ersten Orientierung dienen:
- Anzahl Benutzer
- Anzahl Vollzugriffe auf Entities je Benutzer
Mit dem Tool “Team License Checker” haben wir im vorherigen Kapitel als Schwellenwert “15” angegeben, um einen ersten raschen Überblick zu bekommen welche Benutzerkonten denn das Maximum überschreiten und daher nicht konform mit der TML sind. Erhöhen wir diesen Schwellenwert nun z.B. auf “250”, so ergibt sich ein präziseres Bild der Situation:
Wir sehen nun, wie viele Entitätsberechtigungen (exkl. der laut License Guide zulässigen Standardentitäten) konkret jeder einzelne Benutzer besitzt und folglich wie viele Benutzer aktuell in-/kompatibel mit der TML sind. Von hier aus können nun weitere Überlegungen angestellt werden.
Nachfolgend zur Hilfestellung eine Frageliste mit wesentlichen Punkten:
- Benötigen tatsächlich alle Benutzer mit dieser Sicherheitsrolle Vollzugriff auf die definierten Entitäten?
- Wie häufig machen die Benutzer Gebrauch von ihren erweiterten Zugriffsrechten?
- Um wie viele Entitäten müsste der Vollzugriff reduziert werden, um unterhalb der maximal 15 zulässigen Entitätsvollzugriffe zu bleiben?
- Sind alle übrigen Team Member Lizenzbedingungen ebenfalls umsetzbar für möglichen Benutzerrollen? (s. D365 Licence Guide, Abschnitt B)
- Gibt es neben der Team Member Lizenz noch weitere Lizenzarten, die zum Zugriffsprofil einzelner Benutzer passen und gleichzeitig kostengünstiger sind?
Eine weitere konzeptionelle Limitierung ergibt sich zudem indirekt über die in Kapitel 3 behandelte Limitierung “Workaround Custom App Zugriffslimitierung”: pro Dynamics 365 Business App (Customer Service, Sales oder Project Service Automation) steht nur eine einzige Team Member App zur Verfügung. Das bedeutet, dass einer der Hauptvorteile von Model-driven Apps, nämlich das Erstellen von schlanken hochspezialisierten “Mini-Fachanwendungen”, nur bedingt ausgenutzt werden kann. Denn zwar kann mehr als eine Benutzerrolle konzipiert und implementiert werden, doch müssen sich all diese eine einzige Model-driven App “teilen”. Anstatt reduzierter scharf abgegrenzter “Mini-Fachanwendungen”, müsste die eine Team Member App entsprechend umfangreich ausgestattet werden, um die Anforderungen aller in ihr vereinten Benutzerrollen abzubilden.
Implementierung
Wurden spezialisierte Benutzerrollen bzw. Personas identifiziert und deren benötigte Zugriffsrechte definiert, kann die Implementierung erfolgen. Der Einfachheit halber empfiehlt sich in diesem Fall pro Persona eine eigene Sicherheitsrolle, welche gründlich und so schlank wie möglich konfiguriert wird. Denn bei der Prüfung und Durchsetzung der Team Member Lizenzbestimmungen zieht Microsoft Dynamics 365 die Sicherheitsrollen heran, welche einem Benutzer zugewiesen wurden oder welche er als Mitglied eines Teams geerbt hat. Eine einzige Unachtsamkeit wie bspw. ein Schreib-Privileg zu viel, führt zum Verstoß gegen die Lizenzbestimmung.
Es muss daher vom Systemadministrator bzw. Customizer sichergestellt werden, dass
- Sicherheitsrollen exakt so konfiguriert werden wie im Sicherkonzept definiert (Achtung auf jedes einzelne Privileg!)
- Benutzer nur exakt eine Sicherheitsrolle bekommen, welche ihrer Rolle bzw. Persona laut Sicherheitskonzept entspricht
- Benutzer je nach verwendeter Team Member App die dazugehörige vordefinierte Sicherheitsrolle bekommen, um überhaupt Zugriff auf ebendiese zu erhalten (am Beispiel der “Sales Team Member App” wäre das die Sicherheitsrolle “Sales Team Member”)
