Microsoft Dynamics CRM 2011 | Verwirrspiel Teams & Zugriffsrechte

Immer wieder begegne ich Installationen, die im Vorfeld hinsichtlich einzurichtender Organisationseinheiten, Teams und Sicherheitsrollen nicht ausreichend geplant wurden. So ist es kaum verwunderlich, dass in der Praxis bei bereits eingerichteten Systemen schnell Verwirrungen auftauchen, sofern Datensätze plötzlich und ungewollt sichtbar werden, Sicherheitsrollen scheinbar “ausgehebelt” werden und eine Nachbesserung nach der anderen erfolgen muss.

Mit Sicherheit gibt es auch im laufenden Betrieb immer wieder Korrekturmaßnahmen, die sich auch auf das Sicherheitskonzept auswirken. Da werden Organisationseinheiten neu formiert oder aufgelöst, Teams werden zusammengestellt, neu zusammengestellt oder gar aufgelöst.

Da lohnt es sich in jedem Fall ein Testsystem zu haben, mit dem alle Zugriffsrechte im Vorfeld getestet werden können, denn schnell verliert man dank der neuen Möglichkeiten den Überblick und kann kaum mehr nachvollziehen, warum ein Datensatz jetzt gesehen werden kann, obwohl dies eigentlich nicht möglich sein sollte.

Erinnern wir uns an die Möglichkeiten, die wir nunmehr haben:

• Standard-Sicherheitsrollen in der Root-Unternehmenseinheit
• Benutzerdefinierte Sicherheitsrollen in der Root-Unternehmenseinheit
• Standard (vererbte) Sicherheitsrollen an untergeordneten Unternehmenseinheiten
• Benutzerdefinierte (vererbte) Sicherheitsrollen an untergeordneten Unternehmenseinheiten
• Benutzerdefinierte Sicherheitsrollen nur in untergeordneten Unternehmenseinheiten
• Benutzer, denen Sicherheitsrollen zugewiesen sind,
• Benutzer, die Teams zugewiesen sind
• Benutzer, die Teams zugewiesen sind, denen zusätzliche Rechterollen zugewiesen wurden
• Freigaben von Benutzern für Benutzer
• Freigaben von Benutzern für Teams
• Freigaben durch Prozesse, die automatisch für gewissen Datensätze getätigt wurden
• Freigaben von Benutzern, denen das Freigabe-Recht erteilt wurde und die jene freigegebenen Datensätze ebenfalls freigegeben haben.
• Feldsicherheitsrollen

Ihr seht, da kommt so mancher “Stolperstein” zu Tage, an den im Vorfeld nicht gedacht wurde.

Verdeutlichen möchte ich Euch die Auswirkungen an einem kleinen Beispiel.

Wir haben einen User Will West in der Unternehmens-einheit Serviceteam Westregion eingerichtet.

Und wir haben einen weiteren User Earl East in der Unternehmens-einheit Serviceteam Ostregion eingerichtet.

Des Weiteren ist im System ein Administrator Vorname, Nachname eingerichtet, der in der Unternehmenseinheit Contoso verweilt.

Durch den Systemadministrator wurde die Standard-Sicherheitsrolle Kundenservicemitarbeiter jeweils innerhalb der Unternehmenseinheiten Serviceteam Ostregion und Westregion eingerichtet.

Die jeweilige Sicherheitsrolle wurde so modifiziert, dass für Aktivitäten und Anfragen die Berechtigung maximal auf Unternehmenseinheit erteilt wurde.

Will West wurde anschließend seine Rolle zugewiesen.

Earl East wurde ebenfalls seine Rechterolle aus seiner Unternehmenseinheit zugewiesen. Weitere Rechterollen wurden nicht zugeordnet.

Serviceregion West und Serviceregion Ost arbeiten unabhängig voneinander und können Serviceanfragen und zugehörige Aktivitäten anlegen. In Ausnahmefällen jedoch, können Situationen entstehen, in denen die Mitarbeiter gemeinsam an Servicefällen arbeiten oder Serviceanfragen aus den jeweils anderen Regionen komplett übernehmen.

Für diese Fälle – und nur für diese Fälle – ist es erforderlich, die Datensätze miteinander bearbeiten zu können.

Der Administrator hat sämtliches Servicepersonal in ein Team eingestellt, welches er in der übergeordneten Unternehmenseinheit angelegt hat. Er hat sich ebenfalls diesem Team zugeordnet. Dem Team selbst wurde im 1. Schritt keine Sicherheitsrolle zugewiesen.

Szenario 1: Earl East hat eine Anfrage im System erzeugt und dieser Anfrage eine Serviceaktivität hinzugefügt.

Bei der Bearbeitung stellt er fest, dass er Will West hinzuziehen muss und stellt sich die Frage, ob Will den Datensatz sehen kann?

Er kontaktiert Will und bittet Ihn, die Ansicht Alle Anfragen zu öffnen, um gemeinsam mit Ihm auf dem Datensatz arbeiten zu können.

Doch – wie gewollt – sind dem Nutzer zunächst keine Rechte erteilt, um die Anfrage oder auch die Serviceaktivität sehen zu können.

Da sich Earl East nicht im Detail mit dem System auskennt, kontaktiert er seinen Systemadministrator, der sich nunmehr Gedanken macht, den Zugriff zu gestatten.

Szenario 2: Er weiß um die Tatsache, dass er dem Team ebenfalls Rechterollen zuweisen kann. Doch jetzt stellt sich ein Problem für Ihn dar. Denn das Team ist der Unternehmenseinheit Contoso zugewiesen. Wenn er Rechte auswählen will, sieht er nur Rechterollen, die dieser UE zugewiesen sind. Nur zu gern hätte er dem Team die Rechterollen Kundenservicemitarbeiter Region Ost und Kundenservicemitarbeiter Region West zugewiesen. Doch diese sind der untergeordneten UE zugewiesen und stehen damit nicht zur Auswahl. Kein Problem denkt sich der Administrator und vergibt die in der UE Contoso liegende Standard-Rechterolle Kundenservicemitarbeiter.

Er bittet anschließend die Mitarbeiter Earl East und Will West sich erneut im System einzuloggen bzw. zu aktualisieren (F5). Für Earl East ändert sich nichts. Er hat Zugriff auf seine erzeugten Anfragen und Aktivitäten.

Für Will West ändert sich das Bild und bei Ansicht Alle Anfragen sieht er nunmehr die Anfrage und könnte mit Earl East am Vorgang arbeiten.

Ist diese Konfiguration richtig?

Es kommt darauf an. Denn neben dieser Anfrage stehen Will West fortan über die höheren Rechte des Teams auch weitere Datensätze zur Einsicht zur Verfügung. Wir erinnern uns – dies ist nicht gewollt!

Szenario 3: Der Administrator kann diese Rechterolle jedoch nicht bearbeiten, da die Rechte in dieser Konstellation durch Mitarbeiter in der UE Contoso benötigt werden.

Er erinnert sich an die Möglichkeit die Rechterolle zu kopieren, tut dies und vergibt auf der neuen Rechterolle für Aktivitäten und Anfragen ebenfalls wieder nur die max. Rechte auf Unternehmenseinheit. Er richtet ebenfalls eine Anfrage ein, um das Verhalten der neuen Rechtevergabe zu testen. Erneut bittet er die Mitarbeiter Ihre Systeme zu aktualisieren.

Nunmehr sehen beide Mitarbeiter seine zusätzlich erzeugte Anfrage, aber Will West kann die Anfrage von Earl East nicht einsehen.

Eine Zusammenarbeit ist so nicht möglich. Hinzu kommt, dass alle Anfragen aus der UE Contoso auch über diesen Weg von den anderen Teammitgliedern einsehbar sind. Das war so auch nicht gewollt!

Des Weiteren hat dieses Szenario den Nachteil, dass Standard-Rechterollen in Kopie erstellt wurden, jedoch die Rechte hier reduziert wurden. Wenn jetzt keine ausreichende Bezeichnung gewählt wurde, geht für die Zukunft die Übersicht in den Rechterollen kurz über lang verloren.

Szenario 4: Der Administrator entzieht dem Team wieder die Rechterolle und erinnert sich an eine weitere Möglichkeit: Der Freigabe durch den Benutzer.

Er bittet Earl East, die Anfrage für Benutzer freizugeben. Earl East startet den erforderlichen Dialog hierfür und vergibt entsprechende Lese-Berechtigung auf die Anfrage.

Nach einer Aktualisierung kann Will West und auch Vorname, Nachname auf den Datensatz zugreifen.

Eine Zusammenarbeit ist damit möglich, ohne dass dem Team eine Sicherheitsrolle zugewiesen werden muss.

Des Weiteren wäre es möglich in der Freigabe nunmehr auch das Team auszuwählen und damit den Bedienkomfort zu steigern. Allerdings sind die Datensätze in diesem Moment den gesamten Teammitgliedern bereitgestellt. Es gilt daher die Fragestellung: Was will ich erreichen?

Ihr seht anhand des von mir gewählten Beispiels, wie wichtig es ist, sich im Vorfeld genau über die jeweilige Aufgabenstellung im Klaren zu werden und exakt zu definieren, was nicht möglich sein soll. Darüber hinaus gilt es, die Nutzer aufzuklären, ob es in einer Freigabe erforderlich ist, nur Benutzer heranzuziehen oder ein Team auszuwählen und welche Konsequenzen dadurch “drohen”.

Wir erinnern uns: Teams können individuell zusammengestellt sein, Teammitglieder jederzeit hinzugefügt, aber auch aus dem Team entfernt werden.

Erst im Anschluss daran kann man abwägen, welche Methodik angewendet werden sollte. In meinem Beispiel hatte ich den Vorteil eines leeren Demo-Systems. Ich gebe zu bedenken, wie ein Test in einem Live-System hätte enden können. Eine klare Empfehlung also: Richtet Eure Überlegungen zunächst in einem Testsystem mit Demo-Daten ein und rollt es erst anschließend in Eurer Produktivumgebung aus.

In meinem Beispiel sieht es danach aus, dass die persönliche Freigabe die beste Methode zur Erreichung der Zielvorgaben ist, doch bedenkt: In der Praxis können Mitarbeiter/Innen ausscheiden und die Benutzer werden dann im System deaktiviert. Wie wirkt sich dies auf Freigaben aus?

Will West behält den Zugriff, während Earl East sich nicht mehr einloggen kann. Dies ist wohl auch der Grund, warum man Benutzer nicht endgültig löschen kann. Doch nunmehr können auch keine Freigaberechte mehr verändert werden, wird nicht der Nutzer Earl East wieder reaktiviert.

Außerdem gibt es im Standard keine Möglichkeit für einen Systemadministrator nachzuvollziehen, welcher Benutzer Freigaben für wen und auf was gesetzt hat.

Analysieren, designen, konfigurieren, validieren, freigeben, ausrollen, nachsorgen

Dies gilt nicht nur für Eure Sicherheitsrollen und Teameinrichtung, sondern sollte auch für das gesamte Projekt angewendet werden.

Ich hoffe, Euch mit diesem Artikel wichtige Hinweise bei der Planung vermittelt zu haben und wünsche Euch

<X-mas> eine besinnliche Weihnachtszeit. </X-mas>

Technorati Tags: Microsoft – Dynamics – CRM – 2011 – Sicherheitsrollen – Teams – Tipps & Tricks