Entwicklung einer regelbasierten Benutzerkontensteuerung für Microsoft Active Directory und CRM 2011

Transkript

1 Fachbereich Elektrotechnik und Informatik Fachhochschule Münster Entwicklung einer regelbasierten Benutzerkontensteuerung für Microsoft Active Directory und CRM 2011 Bachelorarbeit Daniel Eisele Matrikel-Nummer Erstprüfer Zweitprüfer Prof. Dr. rer. nat. Nikolaus Wulff, FH Münster Dipl.-Ing. M.Sc. Christian Elberfeld, connectiv! esolutions GmbH

2

3 Erklärung Hiermit versichere ich, dass ich die vorliegende Arbeit selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe, dass alle Stellen der Arbeit, die wörtlich oder sinngemäß aus anderen Quellen übernommen wurden, als solche kenntlich gemacht und dass die Arbeit in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegt wurde. Ort, Datum Unterschrift

4 Inhaltsverzeichnis Inhaltsverzeichnis 1 Einleitung Unternehmensprofil Gliederung der Arbeit Technologien Microsoft Dynamics CRM CRM - Customer Relationship Management Microsoft Dynamics CRM Grundlegender Aufbau Sicherheitskonzept Erweiterbarkeit CRM Webservices CRM aus Entwicklersicht Microsoft Active Directory Grundlegender Aufbau Objekte im Active Directory Domänenstrukturen Microsoft Silverlight Silverlight aus Entwicklersicht Silverlight und CRM Projektübersicht Analyse der Ausgangssituation Motivation I -

5 Inhaltsverzeichnis 4 Das Projekt Analyse der Anforderungen Entwurf der Architektur Grundlegende Entwurfsentscheidungen Konfiguration und Speicherung der Daten Regeldesign Konzept der Attributszuordnungen Design neuer Entitäten für das CRM Connector Funktionsweise Änderungen im Active Directory verfolgen Active Directory und Vertrauensstellungen Laden der Active Directory Inhalte Laden aller benötigten Datensätze des CRM Benutzerzuordnung Auswertung und Anwendung der Regeln Grafische Benutzeroberflächen Globale Optionen Attributszuordnungen Regeldesigner Test Abschlussbetrachtungen Fazit Ausblick Abbildungsverzeichnis 95 Tabellenverzeichnis 97 Quellenverzeichnis 99 Anhang 103 A Felderzuordnung II -

6 Kapitel 1. Einleitung 1 Einleitung Im Rahmen dieser Bachelorarbeit werden Einblicke in ein Softwareentwicklungsprojekt zur automatisierten Datensynchronisation zwischen zwei bestehenden Systemen gegeben. Das Projekt wurde zusammen mit Firma connectiv! esolutions GmbH geplant und umgesetzt. Im Folgenden wird zunächst ein kurzes Firmenprofil gegeben und der allgemeine Aufbau der Arbeit dargelegt. 1.1 Unternehmensprofil Die Firma connectiv! esolutions GmbH ist ein im Jahre 1998 gegründetes, im mittelständischen Sektor angesiedeltes Unternehmen mit 37 Mitarbeitern und den beiden Firmenstandorten Lingen (Ems) und Münster. Die Leistungen umfassen ISP- Dienste wie Internetzugänge, Domainservices und , sowie Web-Entwicklung, Suchmaschinenoptimierung und E-Commerce. Darüber hinaus bietet das Unternehmen die Konzeption, Installation und Anpassung einer Reihe von Microsoft Unternehmensanwendungen wie Microsoft Dynamics NAV und Microsoft Dynamics CRM an. In letzterem Bereich ist auch die vorliegende Arbeit entstanden. 1.2 Gliederung der Arbeit Die Arbeit liefert in Kapitel 2 einen einführenden Überblick über die verwendeten Technologien Microsoft Dynamics CRM, Microsoft Active Directory und Microsoft Silverlight. Hierbei wird auf die für das Verständnis des Projektes benötigten Punkte vertieft eingegangen, sowie die beteiligten Strukturen erläutert. Auch werden hierbei Ähnlichkeiten und Unterschiede in der Grundstruktur der einzelnen Systeme hervorgehoben, welche bei der Implementierung von Bedeutung waren

7 Kapitel 1. Einleitung 1.2. Gliederung der Arbeit Das Kapitel 3 gibt einen Überblick über das Projekt in Planung, Konzeption und Umsetzung. Hierbei wird zunächst das Projekt in seiner Entstehung betrachtet, die Ausgangssituation analysiert, sowie die Motivation und Anforderungen herausgearbeitet. Daraufhin werden in Kapitel 4 grundlegende Designentscheidungen dargelegt, das Konzept und Design analysiert und die letztendliche Umsetzung beschrieben. Ein abschließender Abschnitt beinhaltet den Grundsätzlichen Aufbau der Testumgebung, sowie Stresstest-Daten. Das letzte Kapitel 5 liefert ein Fazit der Projektarbeit und eine Bewertung des erzielten Erfolges sowie einen Ausblick auf mögliche Weiterentwicklungen und Ergänzungen, welche bisher im Produkt nicht enthalten sind

8 Kapitel 1. Einleitung 1.2. Gliederung der Arbeit - 3 -

9 Kapitel 2. Technologien 2 Technologien 2.1 Microsoft Dynamics CRM CRM - Customer Relationship Management Im allgemeinen dienen CRM-Systeme dem sogenannten Customer Relationship Management - der Kundenpflege. Durch zentralisierte, aktuelle Datenhaltung und -aufbereitung können alle Informationen über die Kunden des einsetzenden Unternehmens schnell und aktuell abgerufen und in passendem Zusammenhang jedem Mitarbeiter zur Verfügung gestellt werden. Dies dient dazu, jedem Mitarbeiter stets die aktuellen Informationen zur Verfügung zu stellen, die dieser benötigt, um sowohl die Kundenbindung durch gezielte Informationen, Angebote und Unterstützungsleistungen zu erhöhen, das eigene Absatzpotential durch gezielteres Marketing zu steigern, als auch die Kosten für das einsetzende Unternehmen durch zentrale und automatisierte Datenhaltung zu senken. Die grundlegenden Anwendungsfälle in einem allgemeinen CRM bestehen aus zwei zentralen Bereichen: Kundengewinnung: Hier soll durch gezieltes Ansprechen der in der CRM- Datenbank hinterlegten Interessenten ein neuer Kunde oder Auftrag gewonnen werden. Dabei ermöglicht das CRM durch genauere Informationen über das Kundenprofil eine direkte und gezielte Kontaktaufnahme und Angebotsunterbreitung. Bestandskundenpflege: In diesem Bereich fallen alle Aufgaben, die sich mit bereits bestehenden Kunden des Unternehmens beschäftigen. Hierzu gehören sowohl Service, Öffentlichkeitsarbeit und die Gewährung von Sonderangeboten, als auch das direkte Zugehen auf Bestandskunden, um die Kundenbindung - 4 -

10 Kapitel 2. Technologien 2.1. Microsoft Dynamics CRM zu stärken. Das CRM kann dabei unterstützen, auf die speziellen Bedürfnisse des Kunden gezielt einzugehen. CRM-Systeme existieren sowohl Open Source, als auch kommerziell von einer Vielzahl von Herstellern, wie beispielsweise Oracle, SAP und Microsoft. Im weiteren Verlauf wird ausschließlich auf das Microsoft Dynamics CRM eingegangen, da dieses die Grundlage für das Projekt dieser Arbeit bildet Microsoft Dynamics CRM 2011 Die CRM-Lösung von Microsoft ist Bestandteil der Dynamics-Palette, welche die Unternehmenslösungen von Microsoft umfasst. Die Dynamics-Reihe enthält neben dem CRM noch eine Anzahl verschiedener ERP-Systeme. Das Dynamics CRM unterteilt sich in drei Hauptmodule, welche alle auf den gleichen Basisdaten arbeiten, darüber hinaus jedoch auch spezifische Datenbereiche enthalten: 1. Vertrieb - In diesen Bereich gehören alle Aufgaben, die sich mit dem kaufmännischen Bereich der Kundenbeziehungen beschäftigen. Dazu gehören beispielsweise Verkaufschancen, Mitbewerberanalysen, Angebote oder auch Rechnungen. 2. Marketing - Hier können gezielte Kampagnen (Newsletter, Massenversand von Informationen) gestartet oder ausgewertet werden, um sowohl Öffentlichkeitsarbeit zu betreiben als auch die Kundenbindung zu erhöhen. 3. Service - Dieser Bereich enthält ein Ticketing-System für Support-Anfragen, einen Servicekalender zum Planen von Ressourcen (wie Mitarbeiter, Werkzeuge, Betriebsmittel) für Service-Einsätze und eine Wissensdatenbank. Das CRM ist darüber hinaus in viele Microsoft-Produkte integrierbar. So besteht die Möglichkeit einer Anbindung an Microsoft Outlook, welche sowohl die Datenverwaltung als auch den Massenversand von s beinhaltet, eine Datenexportmöglichkeit für Microsoft Word und Excel und eine Anbindung an das Dokumentenmanagement von Microsoft SharePoint

11 Kapitel 2. Technologien 2.1. Microsoft Dynamics CRM Anpassung Microsoft Dynamics CRM bietet vielfältige Möglichkeiten Aussehen, Bedienbarkeit und Logik an die Wünsche des Kunden anzupassen. So können kleinere Veränderungen direkt im System vorgenommen, eine Menge an Veränderungen zu sogenannten Lösungen (siehe 2.1.5) zusammengefasst und bequem hinzugefügt und wieder entfernt oder sogar komplette Programmlogiken über Plugins und Workflows ins System eingespielt werden. Microsoft stellt online einen sogenannten Marketplace zur Verfügung, der eine große Anzahl an sowohl kostenlosen als auch kostenpflichtigen Erweiterungen beinhaltet, die über simple Mechanismen ins eigene System eingepflegt und gewartet werden können. Die Bandbreite der Anpassungen reicht von kosmetischen Änderungen über kleinere Erweiterungen der bestehenden Logik (beispielsweise um häufig auftretende Arbeitsabläufe zu vereinfachen) bis hin zu komplett neuer Funktionalität und neuen grafischen Benutzeroberflächen Grundlegender Aufbau Abb. 2.1: Die Dynamics CRM Weboberfläche - 6 -

12 Kapitel 2. Technologien 2.1. Microsoft Dynamics CRM Der Zugriff auf das Microsoft CRM geschieht aus Anwendersicht stets über einen Browser oder die Integration in Outlook. Der CRM-Server stellt eine Weboberfläche und diverse Webservices zur Verfügung (siehe z.b. Kapitel 2.1.6) über die auf das System zugegriffen werden kann. Für die Einrichtung des Servers bestehen die Möglichkeiten, diesen entweder als Cloud-Anwendung von Microsoft hosten zu lassen oder auf einem eigenen Server ( On-Premise - Variante) zu betreiben. Das Projekt dieser Arbeit wurde rein auf On-Premise-Systemen entwickelt und getestet, weshalb sich die weiteren Ausführungen auch auf diese Variante beschränken werden. Der CRM-Server kann mehrere Organisationen bereitstellen, welche über eine eigene Webadresse, Nutzerverwaltung, Datenhaltung sowie eigene Anpassungen und Erweiterungen verfügen. Diese Organisationen können als getrennt voneinander existierende Instanzen des CRM-Servers betrachtet und unabhängig voneinander aktiviert und deaktiviert werden. Zur Datenhaltung wird auf einen Microsoft SQL-Server aufgesetzt, welcher aber auch von einer anderen Maschine in der gleichen Domäne bereitgestellt werden kann Sicherheitskonzept Nutzerverwaltung Für die Authentifizierung von Benutzern gegenüber dem CRM werden auf die Anmeldeinformationen und den Authentifizierungsserver der Active-Directory- Domäne (siehe 2.2) zurückgegriffen. Daher können sich im CRM nur Benutzer authentifizieren, welche entweder über einen Account in der gleichen Domäne wie der CRM-Server verfügen, oder deren Domäne entweder eine bidirektionale oder eine unidirektionale, ausgehende Vertrauensstellung (siehe 2.2.3, S. 42) zu der Domäne des CRM-Servers besitzen 2. Benutzer, auf die eines dieser Kriterien zutrifft, können im CRM angelegt werden und sich mit ihrer Domänen-Authentifizierung am Server anmelden. Um den Zugriff der einzelnen Nutzer auf die Datenmenge und die Funktionen des CRM einzugrenzen, verfügt das System über mehrere 1 vgl. Microsoft MSDN: Supported CRM Configurations. URL: com/en-us/library/hh aspx Zuletzt besucht am: vgl. a. a. O

13 Kapitel 2. Technologien 2.1. Microsoft Dynamics CRM Verwaltungsmechanismen, die in den folgenden Abschnitten näher dargelegt werden. Unternehmenseinheiten Unternehmenseinheiten bilden die gröbste Möglichkeit zur Gliederung des Zugriffs auf das CRM und seine Daten. Darüber hinaus kann über diese auch die organisatorische Struktur des Unternehmens selbst nachgebildet werden, wodurch das CRM besser organisiert und überschaubarer ist. Dadurch ist es auch einfacher zu warten. Alle Daten, sowie auch die Benutzer selbst gehören stets zu genau einer Unternehmenseinheit. Kundenbetreuung Unternehmen Service Vertrieb Marketing Hauptsitz Nebenstelle National International Abb. 2.2: Unternehmenseinheiten Einer Unternehmenseinheit können beliebig viele weitere Unternehmenseinheiten untergeordnet werden, sie muss aber stets genau einer Unternehmenseinheit zugeordnet sein (ausgenommen hiervon ist lediglich die Basis- Unternehmenseinheit). Die Abbildung 2.2 demonstriert diesen Aufbau. Da im CRM enthaltene Daten entweder einem Benutzer oder einer Unternehmenseinheit als Besitzer zugeordnet sind, kann die Zugehörigkeit zu einer Unternehmenseinheit entscheidend für die Menge an Daten sein, auf die ein Benutzer zugreifen kann. Eine wichtige Ausnahme bilden hier Teams, welche Mitglieder aus unterschiedlichen Unternehmenseinheiten enthalten und somit ein Sicherheitskonzept bieten, das mehrere Unternehmenseinheiten umfassen kann 3. In diesem Zusammenhang ist es Problematisch, wenn ein Benutzer in eine andere Unternehmenseinheit verschoben wird - denn seine Daten (Firmendaten, Kontaktdaten von Ansprechpartnern, Auftragsdaten etc.) müssen entweder mit dem Besitzer verschoben oder einem anderen Benutzer aus der alten Unternehmenseinheit zugewiesen werden. Hierbei kann der Zugriff auf diese Daten verlorengehen und muss über andere Berechtigungsmechanismen (wie beispielsweise die Teams) wieder hergestellt werden. Aus diesem Grund ist es sinnvoll, die Unternehmenseinheiten nicht unmittelbar aus der realen 3 vgl. Snyder, M./Steger, J./Reid, K.: Arbeiten mit Microsoft Dynamics CRM 2011: Konfiguration, Anpassung und Erweiterung. Microsoft GmbH, 2011, ISBN , S

14 Kapitel 2. Technologien 2.1. Microsoft Dynamics CRM Organisationsstruktur zu übernehmen, sondern in ihnen ein Berechtigungskonzept und keine Strukturnachbildung des realen Unternehmensaufbaus zu sehen. Lizenzen und Zugriffsmodi Eine grundlegende Sicherheitskonzeption stellen bereits die Lizenzen des CRM dar. Es stehen drei verschiedene Lizenztypen zur Verfügung: Lesen-Schreiben, Administrativ und Lesezugriff. Lesen-Schreiben stellt hierbei die volle Lizenz dar. Der Lesezugriff ist eine kostengünstigere Variante, in der lediglich Lesezugriff auf die Daten erlaubt ist und auch als Zugriffssteuerung genutzt werden kann. Die Administrativen Lizenzen sind generell kostenfrei, erlauben aber lediglich Zugriff auf die Bereiche des CRM, in denen Einstellungen möglich sind. Mit ihnen kann aber nicht auf Datensätze zugegriffen werden. Mit einem administrativen Zugang ist es also nicht möglich die Adresse eines im CRM geführten Kunden auszulesen, wodurch die Möglichkeiten bei der Fehlersuche und beim Support innerhalb des Systems stark eingeschränkt sind. Daher muss für solche Tätigkeiten auf einen Account mit vollen Rechten zurückgegriffen werden. Feldsicherheitsprofile Feldsicherheitsprofile stellen ein Sicherheitskonzept auf Ebene der Benutzeroberfläche dar. Wenn in der Weboberfläche im Browser Datensätze betrachtet werden, so verfügen diese über verschiedenste Eingabefelder für Daten (Textfelder, Auswahldialoge etc.). Für diese Eingabefelder kann in den Einstellungen die Option Feldsicherheit einzeln aktiviert werden und somit Berechtigungen an erstellte Feldsicherheitsprofile geknüpft werden. So kann sichergestellt werden, dass ein Vertriebsmitarbeiter beispielsweise die Telefonnummer eines Kontaktes aktualisieren, den Kontakt jedoch nicht einer anderen Firma zuordnen oder den Namen verändern kann, da diese Felder von ihm nicht beschreibbar sind. Neben der Möglichkeit, das Verändern von Feldern zu Unterbinden, können diese für bestimmte Profile auch komplett ausgeblendet werden, um den Datenschutz zu gewährleisten. Eine denkbare Einsatzmöglichkeit hierfür ist das Ausblenden der Kontoinformationen von Kunden bei allen Support-Mitarbeitern. Ruft dieser die Übersicht des Kunden auf, so ist das Feld leer und eine Information sichtbar, dass dieser Inhalt mit dem - 9 -

15 Kapitel 2. Technologien 2.1. Microsoft Dynamics CRM aktuellen Benutzerprofil nicht lesbar ist. Der Benutzer kann aber davon unabhängig über die Möglichkeit verfügen, das Feld zu verändern und somit neue Informationen einzutragen, ohne die Alten zu kennen. Dies ist vergleichbar mit einem Passwort- Feld, welches von einem Administrator mit einem neuen Wert versehen werden kann, ohne dass dieser den alten Wert kennt. Feldsicherheitsprofile können einzelnen Benutzern oder Teams zugewiesen werden. Aufgrund der Einschränkung, dass Feldsicherheitsprofile nur auf Felder benutzerdefinierter Entitäten (siehe Kapitel 2.1.5, S.13) anwendbar sind und wegen des durch ihre Feingranularität bedingten hohen administrativen Aufwandes, wird jedoch meist auf ihren Einsatz verzichtet. Sicherheitsrollen Sicherheitsrollen verwalten vielfältige Sicherheitseinstellungen aus den Kernbereichen des CRM. Hiermit können Einstellungen auf Basis der zugehörigen Entitäten (siehe 2.1.5) definiert werden, die unter anderem das Erstellen, Lesen, Verändern oder Löschen der einzelnen Entitäten erlauben. Darüber hinaus können über Sicherheitsregeln allgemeinere Optionen wie die Erlaubnis zum Installieren von Erweiterungen oder die Möglichkeit zum Seriendruck vergeben werden. Abbildung 2.3 veranschaulicht dieses anhand der Konfigurationsoberfläche für Sicherheitsrollen im CRM. Abb. 2.3: Einstellungen für Sicherheitsrollen Sicherheitsrollen sind dabei fest einer Unternehmenseinheit zugeordnet - in untergeordneten Unternehmenseinheiten wird eine Kopie der Sicherheitsrolle erstellt. Dieser Mechanismus beruht darauf, dass die Berechtigungen, welche eine Sicherheitsrolle zuweist, über einen Geltungsbereich verfügen. So kann bestimmt

16 Kapitel 2. Technologien 2.1. Microsoft Dynamics CRM werden, ob ein Benutzer, die vergebenen Berechtigungen nur auf Daten erhält, die ihm selbst, seiner Unternehmenseinheit (inklusive oder exklusive untergeordneter Unternehmenseinheiten) oder der gesamten Organisation zugeordnet sind. Dass jedoch einzelne Sicherheitsrollen stets beim Erstellen in alle untergeordneten Unternehmenseinheiten kopiert werden und einem Benutzer ausschließlich eine Sicherheitsrolle aus der eigenen Unternehmenseinheit zugewiesen werden kann, stellt eines der Probleme der automatisierten Vergabe von Sicherheitseinstellungen dar. Wird eine Sicherheitseinstellung mit unterschiedlichen Werten in mehreren Rollen vergeben, und beide einem Nutzer zugewiesen, so erhält der Nutzer effektiv die Summe aller dieser Berechtigungen für die Daten. Erlaubt beispielshalber eine Rolle das Lesen der Daten und eine weitere das Schreiben, so erhält der Benutzer mit beiden Rollen Lese und Schreibberechtigungen, kann aber erst einen neuen Datensatz anlegen, wenn er auch über die Berechtigung zum Erstellen verfügt. Daraus erklärt sich, dass im CRM generell keine Rechte explizit verweigert werden, sondern jede Berechtigung stets explizit vergeben werden muss. Teams Teams ermöglichen es, mehrere Benutzer in einem Objekt zusammenzufassen und diesem dann Sicherheitsrollen und Feldsicherheitsprofile zuzuweisen, die für alle im Team enthaltenen Nutzer gelten sollen. Teams können Benutzer aus unterschiedlichen Unternehmenseinheiten enthalten und stellen somit eine gute Möglichkeit dar, Sicherheitseinstellungen für eine große Bandbreite von Benutzern zu verwalten. Im Falle von Sicherheitsrollen ist es hierbei irrelevant, ob die Rolle in der Unternehmenseinheit des Benutzers existiert oder nicht - die Berechtigungen werden in jedem Falle vergeben Erweiterbarkeit Das Microsoft Dynamics CRM verfügt über eine Vielzahl an Möglichkeiten, das System anzupassen und zu erweitern. In diesem Abschnitt wird auf die wichtigsten eingegangen und ihre Funktionalität erläutert

17 Kapitel 2. Technologien 2.1. Microsoft Dynamics CRM Workflows Workflows stellen im CRM eine Möglichkeit dar, Geschäftsprozesse zu automatisieren und zu standardisieren. Ein Workflow kann entweder manuell oder durch ein definiertes Ereignis gestartet werden und daraufhin Aufgaben durchführen wie das Senden einer , das Erstellen und Zuweisen einer neuen Aktivität (Telefonanrufe tätigen, Briefe versenden u.a.) oder das Aktualisieren von Daten. Workflows werden häufig zur Automatisierung einer großen Anzahl manuell zu wiederholender Schritte verwendet. Sie erleichtern es somit, Geschäftsprozess-Standards einzuhalten. Beispielsweise ist vorstellbar, einen Workflow zu verwenden, welcher aktiviert wird, sobald der geschätzte Wert eines Auftrages eine definierten Grenze überschreitet, dann dessen Priorität erhöht und den Auftrag einem Bearbeiter mit höherer Entscheidungsbefugnis zuweist und gleichzeitig die Beteiligten per über die Vorgänge informiert. Plugins Sollen jedoch Prozesse automatisiert werden, deren Aufgaben über die eingeschränkten Möglichkeiten von Workflows hinausgehen, können hierfür eigene Plugins entwickelt werden. Diese enthalten benutzerdefinierten Programmcode, welcher in den CRM-Server integriert und bei definierten Ereignissen ausgeführt wird. Plugins werden in der Programmiersprache C# geschrieben, für die Microsoft als Bestandteil des Microsoft Dynamics CRM SDK Assemblies zum Zugriff auf die Funktionalität des CRM liefert. Mit Plugins ist es möglich, benutzerdefinierte Logik auf Basis von Ereignissen auszuführen, die mit Workflows nicht realisierbar ist. Webressourcen Webressourcen stellen Dateien dar, welche in der Datenbank des CRM-Servers liegen und durch eine eindeutige URL-Adresse zugreifbar sind. Die unterstützten Dateitypen umfassen HTML-Seiten, Silverlight-Anwendungen (siehe Kapitel 2.3) sowie Skript- oder Bilddateien. Diese Dateien dienen hauptsächlich der Anpassung der Benutzeroberfläche, können aber auch Logik und Automatisierung beinhalten

18 Kapitel 2. Technologien 2.1. Microsoft Dynamics CRM Entitäten Entitäten bilden die Möglichkeit, auf einfache Art und Weise die SQL-Datenbank des CRM-Servers zu erweitern und so neue Datenstrukturen zu definieren. Das Erstellen einer neuen Entität entspricht dem Erstellen einer neuen Tabelle in der SQL-Datenbank (vgl Tabelle 2.1). Für eine Entität können sowohl Felder für konkrete Attributswerte (bei- Bezeichnung SQL Bezeichnung CRM Tabelle Entität spielsweise Text oder Zahlen) als Spalte Feld auch Beziehungen (der Form 1:1, Relation Beziehung 1:n, n:1 und n:n) zu anderen Entitäten definiert werden. Diese werden Tab. 2.1: Bezeichnungen in CRM und SQL in der SQL-Datenbank als Spalten oder neue Relationstabellen umgesetzt. Tabelle 2.2 verdeutlicht die Umsetzung der neuen Entität in der SQL-Datenbank. Jede Entität erhält außerdem einen Satz systemdefinierter Werte, unter anderem eine eindeutige GUID als Primärschlüssel zur Identifikation einzelner Datensätze, sowie Verwaltungsdaten wie das Erstellungsdatum, das Datum der letzten Modifikation, den Besitzer des Datensatzes, die zugehörige Unternehmenseinheit und weitere. Felder, die Beziehungen zwischen Entitäten, deren Wert genau ein anderer Datensatz ist, werden durch eine Spalte in der SQL-Datenbank realisiert. Deren Eintrag stellt den Primärschlüssel des verwiesenen Datensatzes dar. In Abbildung 2.4 ist dies am Beispiel der Zuordnung von Benutzern zu Filialen zu sehen. Die Spalte Filiale der SQL-Benutzertabelle enthält jeweils die ID des dem Nutzer zugeordneten Filial-Datensatzes. Dieses Verfahren ist möglich, solange es sich bei der Beziehung nicht um eine n:n-relation handelt. Ist die Beziehung jedoch von diesem Typ, muss diese im SQL über Relationstabellen umgesetzt werden. Hierbei werden Beziehungen, deren Wertebereich eine Liste mehrerer Datensätze umfasst, automatisch in eine Relationstabelle übersetzt, die jeder hergestellten Beziehung einen eigenen Schlüssel, sowie die beiden Primärschlüssel der beteiligten Datensätze zuordnet. Im Diagramm 2.4 wird dies am Beispiel der Zuordnung von Sicherheitsrollen und Benutzern erläutert. Hierfür

19 Kapitel 2. Technologien 2.1. Microsoft Dynamics CRM wird eine neue Tabelle angelegt, in der jede Zuordnung durch eine eigene Zeile mit eigener ID realisiert wird (im Beispiel SQL-Relationstabelle für Benutzer und Sicherheitsrollen ). Jede Zuordnung enthält dabei mindestens die IDs der beiden beteiligten Datensätze - im Beispiel Benutzer-ID und Sicherheitsrollen-ID. Datentyp CRM Datentyp SQL Beschreibung einzelne Textzeile nvarchar Feld für einen kurzen Text Optionssatz int Hier können Auswahldialoge definiert werden, deren Werte einer Position innerhalb der Liste der definierten Werte darstellen Zwei Optionen boolean Ein Optionssatz mit zwei Auswahlmöglichkeiten Ganze Zahl Integer Feld für ganze Zahlen Gleitkommazahl float Feld für Gleitkommazahlen Dezimalzahl decimal Feld für Dezimalzahlen Währung money Feld für Währungeseingaben Mehrere Textzeilen nvarchar Feld für längeren Text, der im Gegensatz zu der einzelnen Textzeile innerhalb der Benutzeroberfläche automatisch als großes Textfeld dargestellt wird Datum und Uhrzeit datetime Feld für Datumseingaben Suche uniqueidentifier Dieses Feld kann der Realisierung von Beziehungen zu anderen Entitäten verwendet werden. Hier wird der Primärschlüssel des Datensatzes eingetragen, auf den das Feld verweist. Tab. 2.2: Datentypen in CRM und SQL Dieses komplexe Vorgehen wird für den Benutzer vom CRM-Server übernommen. Das Erstellen, Verknüpfen und Verändern von Entitäten und Datensätzen erfolgt über die grafische Benutzeroberfläche, die Umsetzung in die SQL-Datenbank übernimmt die Logik des CRM-Servers. Abbildung 2.4 verdeutlicht die Speicherung von Datensätzen in der SQL-Datenbank. Hierbei wurden vereinfachte Beispieldaten (im System wird eine GUID durch eine 16-Bit-Zahl dargestellt, dies wurde hier abgekürzt) für Benutzer, ihre Rollen und die Zuordnung zu einer Filiale eingefügt, um die Beziehungen und ihre Umsetzung zu verdeutlichen

20 Kapitel 2. Technologien 2.1. Microsoft Dynamics CRM Entitäts/Tabellendefinitionen in CRM und SQL Benutzer Feldname CRM-Datentyp GUID SQL-Datentyp ID Name Filiale GUID Textzeile Textzeile Suche uniqueidentifier nvarchar nvarchar uniqueidentifier Rollen n:n-beziehung Relationstabelle Feldname ID Name Ort Mitarbeiter Filiale CRM-Datentyp GUID GUID Textzeile Textzeile 1:n-Beziehung SQL-Datentyp uniqueidentifier nvarchar nvarchar Sicherheitsrolle Feldname CRM-Datentyp GUID SQL-Datentyp ID Name Mitglieder GUID Textzeile n:n-beziehung uniqueidentifier nvarchar Relationstabelle Tabellen innerhalb der SQL-Datenbank ID B085[ ]1 B085[ ]2 B085[ ]3 SQL-Tabelle für Benutzer Name - Adresse Franz Müller ma.de Hans Meier a.de Ulrike Becker ma.de Filiale A085[ ]1 A085[ ]1 A085[ ]2 SQL-Tabelle für Filialen ID Name Ort A085[ ]1 Hauptsitz Berlin A085[ ]2 Nebenstelle München SQL-Relationstabelle für Benutzer und Sicherheitsrollen ID Benutzer-ID Sicherheitsrollen-ID C085[ ]1 B085[ ]1 D085[ ]1 C085[ ]2 B085[ ]1 D085[ ]2 C085[ ]3 B085[ ]2 D085[ ]1 C085[ ]4 B085[ ]3 D085[ ]2 C085[ ]5 B085[ ]3 D085[ ]1 Abb. 2.4: Datentypen und Relationen in CRM und SQL SQL-Tabelle für Sicherheitsrollen ID Name D085[ ]1 Mitarbeiter D085[ ]2 Administratoren Aus Programmierersicht wird der Zugriff durch das Microsoft Dynamics CRM SDK erheblich erleichtert. Dort sind Klassen enthalten, welche es ermöglichen, bestimmte Datensätze eines Entitätstyps zu laden und ihre Felder als Liste von Attributen zu lesen und zu verändern. Müller : Entity EntityLogicalName : string = Benutzer Attributes : AttributeCollection Id : Guid = B085[...]1 Müller.Attributes : AttributeCollection Name : string string Filiale : EntityReference Rollen : EntityReferenceCollection Müller.Attributes.Filiale : EntityReference EntityLogicalName : string = Filiale Id : Guid = A085[...]1 Müller.Attributes.Rollen : EntityReferenceCollection Entities : EntityReference Abb. 2.5: Entitäten-Objekt Mitarbeiter : EntityReference EntityLogicalName : string = Sicherheitsrolle Id : Guid = D085[...]1 Administratoren : EntityReference EntityLogicalName : string = Sicherheitsrolle Id : Guid = D085[...]2 Beziehungen werden im Falle der Relation zu genau einem anderen Datensatz als einzelne EntityReference oder im Falle der Beziehung zu mehreren Datensätzen

21 Kapitel 2. Technologien 2.1. Microsoft Dynamics CRM als Liste dieses Datentyps übergeben. Ein Objekt dieser Klasse enthält den Entitätstyp und den Primärschlüssel des verknüpften Datensatzes. Dadurch können sie vergleichbar einfach ausgelesen und verändert werden. In Abbildung 2.5 wird dies anhand von Beispieldaten verdeutlicht. Abbildung 2.6 bildet die Darstellung der Beispieldaten in der Weboberfläche des CRM ab. Beim Zugriff über das Abb. 2.6: Datensatz in der Weboberfläche SDK erhält man somit ein Objekt vom Typ Entity, welches seinen eigenen Typ, seine ID und eine Liste von Attributen enthält. In der Abbildung ist dies an einer konkreten Instanz einer Benutzer-Entität verdeutlicht. Die Attributsliste einer Entität ist vom Typ AttributeCollection und enthält die einzelnen Werte der Datenbanktabelle, sowie im Falle der Beziehungen entweder eine EntityReference (Im Beispiel: Filiale ) für ein-, sowie eine EntityReferenceCollection für mehrwertige Beziehungen (Im Beispiel: Rollen ). Ein EntityReference-Objekt enthält die ID, den Typ und den Namen des Datensatzes, auf den es verweist. Entitäten können aber nicht rein als Definitionen von SQL-Tabellen angesehen werden. Zu einer Entität gehören stets auch Formulare Ansichten, die steuern, wie diese Entität in der Oberfläche dargestellt wird sowie vorgefertigte Diagramme, die zur statistischen Auswertung dienen. Wird eine Entität in ein anderes System exportiert, werden diese mit übernommen, sie gehören zu der Entität ebenso wie ihre Felder und Beziehungen. Lösungen Mithilfe von Lösungen können Erweiterungen wie Entitäten, Plugins, Workflows, aber auch Sicherheitsrollen und Webressourcen zu einem Paket zusammengefasst und in bestehende Systeme verteilt werden. Diese Lösungs-Pakete können in einer CRM-Organisation (siehe Abschnitt 2.1.3) als ganzes de- oder installiert werden. Darüber hinaus besteht die Möglichkeit, Lösungen entweder als verwaltet oder

22 Kapitel 2. Technologien 2.1. Microsoft Dynamics CRM nicht verwaltet zu verteilen. Verwaltetete Lösungen bieten den Vorteil, dass alle in der Lösung enthaltenen Anpassungen, schreibgeschützt sind und bei einer Deinstallation vollkommen aus dem System entfernt werden. Bei nicht verwalteten Lösungen hingegen würde nur der Lösungs-Container bei einer Deinstallation entfernt werden. Die Anpassungen befänden sich weiterhin im System. Verwaltete Lösungen lassen sich mit Apps vergleichen - sie stellen komplette Anwendungspakete dar. Passend dazu bietet Microsoft eine Online-Plattform, den sogenannten Marketplace an, über den kostenlose und kostenpflichtige Lösungen vertrieben werden können - ähnlich eines Appstores CRM Webservices Der CRM-Server stellt dem Entwickler verschiedene Webservices zur Verfügung, über die auf die im CRM hinterlegten Daten zugegriffen werden kann: IOrganizationService oder auch SOAP-Endpoint - Dieser stellt den mächtigeren der beiden Webservices dar. Durch eine Vielzahl von Request-Response- Paaren können nahezu alle Operationen auf den Daten des CRM ausgeführt werden. Hierunter fallen unter anderem Associate - und Disassociate - Requests zum Herstellen und Entfernen von Beziehungen, SetState-Requests um den Status von Datensätzen zu verändern oder SetBusinessSystemUser - Requests, um Benutzer in andere Unternehmenseinheiten zu verschieben. Allerdings ist das Entwickeln mit diesem Service durch die Masse an unterschiedlichen Request/Response-Paaren unhandlich. Für den Zugriff auf die Daten des CRM aus Webressourcen heraus, empfiehlt Microsoft die Nutzung des REST Endpoint Service 4, da dieser eine bessere developing Experience verspricht und um den SOAP-Service zu nutzen wesentlich mehr Programmieraufwand notwendig ist. Im weiteren Verlauf der Arbeit wird dieser als SOAP-Service bezeichnet. REST Endpoint - Dieser ist in der aktuellen Version beschränkt auf Lesen, Löschen, Verändern und Erstellen von Datensätzen, sowie das Herstellen und 4 Microsoft MSDN: REST and SOAP Services. URL: library/gg aspx Zuletzt besucht am:

23 Kapitel 2. Technologien 2.1. Microsoft Dynamics CRM Lösen von Beziehungen. Für andere Operationen muss auf den SOAP-Service zurückgegriffen werden. Jedoch ist angekündigt, den REST-Service in späteren Versionen um weitere Funktionalitäten zu erweitern. Microsoft empfiehlt, diesen Dienst zu verwenden, wenn keine anderen als die unterstützten Operationen innerhalb der Anwendung nötig sind 5. Des Weiteren kann das gleichzeitige Absenden von Anforderungen zur Manipulation von Datensätzen zu erheblichen Komplikationen führen. Dies führt zu erhöhtem Aufwand, bezüglich Synchronisation und Multithreading, aber auch zu umständlichen Lösungen bei der Manipulation großer Datenmengen. Letzteres ist besonders bei inhomogenen Datenmengen (die beispielsweise aus vielen unterschiedlichen Daten-/Entitätstypen bestehen) der Fall, da hier für jeden Typ eine eigene Anfrage gesendet werden muss, wobei erst nach deren vollständiger Abarbeitung der nächste Bearbeitungsvorgang gestartet werden kann. Discovery-Webservice - Dieser stellt eine Auflistung aller CRM-Organisationen zur Verfügung. Er wird primär dann eingesetzt, wenn eine Anwendung nicht fest für eine bestimmte Organisation konzipiert wurde, sondern diese erst zur Laufzeit (durch eine Benutzereingabe, Konfigurationseinstellung etc.) festgelegt wird. Bei der Entwicklung von Erweiterungen für das Microsoft Dynamics CRM stellt die Wahl des verwendeten Webservices zur Kommunikation mit dem CRM-Server einen entscheidenden Schritt für die spätere Architektur dar. Jedoch gibt es bei der Entwicklung von Anwendungsprogrammen, die nicht innerhalb einer Webressource veröffentlicht werden sollen, kaum Gründe dafür, nicht auf den SOAP-Endpoint zurückzugreifen. Bei der Entwicklung von Webressourcen, muss hier vor der Implementierung analysiert werden, ob die Möglichkeiten des REST-Services für die Erfüllung der Anforderungen genügen CRM aus Entwicklersicht Der Zugriff auf die im CRM enthaltenen Entitäten und Daten stellen sich aus Entwicklersicht zwei unterschiedliche Herangehensweisen: 5 Microsoft MSDN: REST and SOAP Services

24 Kapitel 2. Technologien 2.1. Microsoft Dynamics CRM 1. Earlybound Entites: Sowohl bei der Entwicklung für Webressourcen als auch für.net-anwendungen stellt Microsoft die Möglichkeit zur Verfügung, Klassen zu generieren, die die aktuell im System enthaltenen Entitäten abbilden. Im Falle von.net wird eine einzelne Ressourcen-Datei erstellt, die alle Entitätendefinitionen als erweiterbare (partial)-klassen enthält, bei Webressourcen kann eine Dienst-Refenrenz in das Projekt eingebunden und über diese auf die Entitäten zugegriffen werden. Vorteile: Nachteile: Earlybound Entites vereinfachen den Zugriff, da alle Eigenschaften und Felder durch die Klassendefinition der Entwicklungsumgebung bekannt sind. Die exakte Kenntnis der Bezeichnungen und Datentypen ist daher nicht notwendig, es kann sowohl die automatische Syntaxvervollständigung als auch die Überprüfung des Codes zur Kompilierzeit genutzt werden. Die Definition aller im System vorhandenen Entitäten erhöht den Speicherbedarf der Anwendung signifikant. Auch muss bei jeder Veränderung im CRM die Definition der Entitäten im Entwicklungsprojekt aktualisiert werden. Außerdem ist die Erweiterung der vordefinierten Klassen um eigene Logik oder neue Eigenschaften aufwendig und Fehleranfällig, da definierte Events und Schnittstellen eingehalten werden müssen, auch wenn diese im eigenen Code nicht verwendet werden. Auch ist es nicht Möglich, eine eigene Vererbungshierarchie zwischen den Entitäten aufzubauen. 2. Latebound Entites: Hierbei wird ausschließlich mit Objekten der Klasse Entity gearbeitet. Alle Eigenschaften, Felder und Attribute müssen vom Entwickler ohne Hilfestellung mit passenden Daten und Typen gefüllt werden, da keine Unterstützung zur Laufzeit erfolgt. Vorteile - Es kann eine eigene Vererbungshierarchie implementiert werden. Neue Unterklassen von Entity können nach Belieben modelliert werden, es besteht keine Anforderung an neue Eigenschaften, Methoden oder Attribute. Darüber hinaus kann so die Menge an neuen Klassen auf die vom Code verwendeten Entitäten beschränkt und der Speicherbedarf der Anwendung reduziert werden. Veränderungen an den Entitäten un

25 Kapitel 2. Technologien 2.1. Microsoft Dynamics CRM terliegen der Behandlung durch den Entwickler und benötigen keinen automatisierten Abgleich. Nachteile - Fehleranfälliger, da die Code-Überprüfung erst zur Laufzeit stattfindet. Aufwendiger, da stets der exakte interne Name einer Entität und aller benötigter Attribute und Beziehungen bekannt sein muss

26 Kapitel 2. Technologien 2.2. Microsoft Active Directory 2.2 Microsoft Active Directory Das Microsoft Active Directory stellt den Verzeichnisdienst von Microsoft dar. Ein Verzeichnisdienst hat die Aufgabe, im Netzwerk Daten zur Verfügung zu stellen. Meist handelt es sich hierbei um Informationen über gespeicherte Objekte wie beispielsweise Benutzer- und Computerkonten, Gruppen, Drucker oder Netzwerkfreigaben. Abgesehen vom Active Directory existieren Verzeichnisdienste von Novell (edirectory), Apple (OpenDirectory) und Sun (Sun Directory Server) sowie weitere weniger verbreitete. Außerdem soll der Linux-Daemon Samba in der angekündigten Version 4 einen vollständig zum Active Directory kompatiblen Verzeichnisdienst bereitstellen können 6. Allen diesen Verzeichnisdiensten ist gemein, dass sie über das LDAP-Protokoll (siehe Kapitel 2.2.2, S. 26) ansprechbar sind und es somit generischen LDAP-Anwendungen (wie sie unter anderem in Telefonanlagen zu finden sind) möglich ist, mit allen genannten Verzeichnisdiensten zu kommunizieren und grundlegende Informationen, wie die Zuordnung von Mitarbeitern und ihren Telefonnummern, abzurufen. Verzeichnisdienste bieten unter anderem den Vorteil, zentral gespeicherte und oftmals strukturelle Informationen gesichert zur Verfügung zu stellen und somit die Datenhaltung dieser Informationen zu erleichtern und diese zwischen allen an den Verzeichnisdienst angeschlossenen Teilnehmern auf dem gleichen Stand zu halten. Trotz ihrer Ähnlichkeit zu relationalen Datenbanken unterscheiden sich Verzeichnisdienste von diesen in mehreren Punkten. Zum einen bieten Verzeichnisdienste die Möglichkeit, auf mehrere Server aufgeteilt zu werden, wobei auf jedem Server sowohl Teile des gesamten Verzeichnisses, als auch eine komplette Kopie liegen kann. Darüber hinaus sind Verzeichnisdienste im Gegensatz zu relationalen Datenbanken stets hierarchisch aufgebaut und ihre Zugriffe auf Lesevorgänge optimiert 7. 6 Siehe: 7 Vgl. Liebel, O./Ungar, J.M.: OpenLDAP. Galileo Press, 2006, Galileo computing, ISBN , S. 20f

27 Kapitel 2. Technologien 2.2. Microsoft Active Directory Grundlegender Aufbau Ein Active Directory besteht stets aus einer Anzahl von Servern, welche die gespeicherten Informationen beinhalten, sich bei Veränderungen untereinander synchronisieren und die gespeicherten Inhalte den angeschlossenen Geräten bereitstellen. Diese Server werden als Domänencontroller bezeichnet. Im Falle des Active Directory bestehen die wichtigsten Aufgaben der Domänencontroller aus: - dem Bereitstellen der gespeicherten Informationen über das LDAP-Protokoll (siehe auch Abschnitt 2.2.2) - der Authentifizierung von Teilnehmern über das Kerberos-Protokoll - der Beantwortung von Anfragen zur Namensauflösung über einen DNS-Dienst Ein Domänencontroller im Active Directory ist also nicht nur für die Bereitstellung von Informationen, sondern auch für die Überprüfung und Einhaltung von Sicherheitskonzepten zuständig. Üblicherweise enthalten in einem Unternehmen die Domänencontroller die Informationen über alle Benutzer und Computer des Unternehmens. So kann der Domänencontroller bei der Anmeldung an einer ihm zugeordneten Maschine überprüfen, ob die eingegebenen Zugangsdaten korrekt sind und der Benutzer berechtigt ist, sich an dieser Maschine anzumelden. Auch administrative Berechtigungen sowie die Erlaubnis, auf bestimmte Netzwerkressourcen wie Drucker, Freigaben oder Dienste zuzugreifen, lassen sich über den Verzeichnisdienst zentral und global vergeben. Sicherheitseinstellungen über Gruppenrichtlinien Über die angesprochenen Berechtigungen hinaus bietet das Active Directory die Möglichkeit der Gruppenrichtlinien. Diese können gezielt auf einzelne Benutzer oder Computer, aber auch global für ganze Gruppen, Organisationseinheiten oder Domänen definiert werden und bieten umfangreiche Möglichkeiten, Voreinstellungen auf Systemen vorzunehmen. Über Gruppenrichtlinien ist es beispielsweise möglich, bei der Anmeldung eines Benutzers aus einer definierten Gruppe auf einer bestimmten Maschine bestimmte Voreinstellungen des Betriebssystems zu sperren, zu

28 Kapitel 2. Technologien 2.2. Microsoft Active Directory verändern oder gar bestimmte Programme zu starten. Gruppenrichtlinien geben den Administratoren somit ein Werkzeug an die Hand, globale Richtlinien zu definieren, um stetig wiederkehrende Aufgaben zu automatisieren Objekte im Active Directory Die im Active Directory gespeicherten Objekte sind in einer hierarchischen Struktur organisiert, welche der in einem Datei-Verzeichnisbaum ähnelt. Es existiert stets ein Wurzel-Eintrag, der sogenannte rootdse. Bei globalen Suchen stellt dieser den Ausgangspunkt der Suche dar, da ihm alle anderen Objekte untergeordnet sind. Darüber hinaus bringt die verteilte Struktur eines Active Directorys auf mehrere Domänencontroller die Notwendigkeit der Synchronisation mit sich. Die Domaincontroller gleichen sich in einem festen Zeitintervall ab und bringen ihre Informationen anhand von Zeitstempeln auf den jeweils aktuellsten Stand. Dies bringt eine Vielzahl von Problemen mit sich, wie beispielsweise die Umsetzung von vergebenen Rechten, welche im äußersten Fall erst nach der nächsten Synchronisation erfolgt. Dies ist der Fall, da der Domänencontroller, auf dem die Veränderungen getätigt wurden nicht zwingend auch der Domänencontroller ist, der die Authentifizierungsanfrage erhält und somit die Information erst synchronisiert/repliziert werden muss. Aus demselben Grund werden Objekte im Active Directory auch nicht direkt vollständig gelöscht. Wird beispielsweise ein Nutzerkonto auf einem Domänencontroller entfernt, so wird es in einen separaten Container verschoben und ein Bit-Flag gesetzt. Dieses sogenannte Tombstone -Flag signalisiert bei einer Synchronisation den anderen Domänencontrollern, dieses Benutzerkonto ebenfalls zu löschen. Ohne diese Vorgehensweise könnte im Falle einer Synchronisation nicht entschieden werden, ob ein Objekt, welches auf nur einem Domänencontroller existiert, auf diesem gerade erstellt, oder auf allen anderen schon gelöscht wurde. Endgültig gelöscht wird ein Objekt im Active Directory nach einer konfigurierbaren Zeitspanne, die mit dem setzen des Tombstone-Flags einsetzt - der sogenannten Tombstone-Lifetime. Diese beträgt in der Standard-Einstellung eines Windows Server 2008(R2) 180 Tage. Dies ist einer der Gründe, aus dem sich Domänencontroller innerhalb einer Tombstone-Lifetime stets mindestens einmal synchronisieren sollten und das Aus

29 Kapitel 2. Technologien 2.2. Microsoft Active Directory schalten von Domänencontrollern für einen längeren Zeitraum, oder das Zurücksetzen auf einen älteren Zustand (durch einspielen eines Backups oder das Zurücksetzen eines Speicherpunkts auf einer virtuellen Maschine) möglichst vermieden werden sollte. Durch ihre zentrale Funktion können Fehlfunktionen oder Probleme auf Domänencontrollern weitreichende und unvorhersehbare Folgen haben. AD-Struktur Um Objekte innerhalb der Struktur zu klassifizieren und zu unterscheiden, greift das Active Directory auf Schemata zurück. Es existieren zwei Schema-Kategorien, die von grundlegender Bedeutung sind: - Attribute (attributeschema-objekte) definieren Attribute von Objekten. Sie liefern unter anderem Informationen über den internen Namen und den Anzeigenamen des Attributs, seinen Wertebereich, seinen Standardwert, ob es beim Löschen in dem Tombstone-Objekt noch auslesbar sein wird und ob es sich um ein zwingendes oder ein optionales Attribut handelt. - Klassen (classschema-objekte) definieren Klassen von Objekten. Im Besonderen ist in ihnen enthalten, welche Attribute ein derartiges Objekt enthält, wie es heißt und von welchen anderen Klassen es erbt. Gerade die Vererbung ist im Active Directory ein ebenso mächtiges Werkzeug wie es Fehlerquelle sein kann. Klassen von Objekten können von anderen Klassen erben und erhalten dabei alle von der Elternklasse beinhalteten Attribute, sowie auch alle, die diese durch Vererbung von ihren Elternklassen erhält. Außerdem können Klassen weitere Hilfs-Klassen, sogenannte Auxiliary Classes spezifizieren, deren Attribute zusätzlich mit eingebunden werden. Ähnlich wie in objektorientierten Programmiersprachen die Klasse Object, existiert im Active Directory eine Klasse top von der alle anderen Klassen abgeleitet sind. Diese umfasst hauptsächlich die Attribute, welche für die interne Organisation des Active Directory benötigt werden und stellt somit sicher, dass diese in jedem Objekt vorhanden sind. Ein Beispiel hierfür ist die Klassenhierarchie für Benutzer und Computer-Objekte (siehe Abbildung 2.7)

30 Kapitel 2. Technologien 2.2. Microsoft Active Directory top Object-Class Object-Guid Common-Name Canonical-Name... person Common-Name User-Password SurName Telephone-Number... organizationalperson Company Address... User NT-Pwd-History Logon-Count... Computer DNS-Hostname Location... Legende: Klassenname zwingendes Attribut Optionales Attribut Security-Principal Object-Sid SAM-Account-Name SID-History... Auxiliary Class Abb. 2.7: Schemata-Vererbung Die Vererbungshierarchie umfasst die Klasse top, von der abgeleitet werden muss, da sie Verwaltungsattribute wie Namen und GUID sowie das Attribut Object-Class definiert. Letzteres enthält eine Auflistung aller Klassen der Vererbungs-Hierarchie des aktuellen Objekts. Von top erbt die Klasse person. Diese erweitert top um Informationen, welche für Benutzer entscheidend sind, wie Passwort, Vorname oder Telefonnummer. Darüber hinaus wird der Status des Namens-Attributs Common-Name in dieser Klasse auf zwingend gesetzt. Während er in top noch optional war, müssen alle Objekte von der Klasse person dieses Attribut mit einem Wert versehen. Darunter liegt organizational-person, welches von person erbt und organisationsspezifische Attribute dem Benutzer zur Verfügung stellt. So können bei einer organizational-person beispielsweise eine Firma und eine Adresse eingetragen werden. Hiervon abgeleitet ist nun die eigentliche Klasse für einen Benutzer - User. Diese bindet mehrere Hilfsklassen ein, von denen die wichtigste die Klasse SecurityPrincipal ist. Diese sorgt dafür, dass jeder Benutzer über einen Security-Identifier ( object-sid ), einen SAM-Account-Name (der Security Accounts Manager stellt die Benutzerkontenverwaltung in jedem lokalen Windows sowie jedem Active Directory dar) sowie weitere Sicherheitsattribute verfügt. Das Besondere dabei ist, dass die Klasse Computer, die alle Maschinen im Active Directory repräsentiert, von der Klasse User abgeleitet ist. Sie verfügt also über alle Attribute eines Benutzers, man könnte also auch einen Vornamen vergeben. In

31 Kapitel 2. Technologien 2.2. Microsoft Active Directory ihr werden zusätzlich zu den Nutzerinformationen nur noch maschinenspezifische Informationen vermerkt, darunter Hardware-Adressen oder Aufstellungsort des Geräts. Da alle diese Objekte von top erben, besitzen alle das zwingende Attribut Object-Class. Dieses stellt eine Auflistung aller Basisklassen dar, stets beginnend mit top - im Falle eines Computers wäre sein Inhalt also: ObjectClass = top;person;organizationalperson;user;computer Dieses Phänomen führt dazu, dass bei Suchanfragen im Active Directory, wenn nach der Klasse User gesucht wird, auch Computer-Objekte im Suchergebnis auftauchen, wenn die Filter nicht explizit so konfiguriert wurde, dass Objekte der Klasse Computer ausgeschlossen werden. Dieses ist darauf zurückzuführen, dass Suchanfragen ans Active Directory lediglich die Existenz der Klasse im Object-Class -Attribut als ausreichend ansehen, auch wenn das Objekt von einem untergeordneten Typ ist. Eine Übersicht über alle Klassen im Active Directory sowie ihre Attribute und Vererbungen kann im MSDN abgerufen werden 8. LDAP Das Lightweight Directory Access Protocol definiert eine Art und Weise, in welcher Anfragen an einen Verzeichnisdienst gesendet werden können und bildet die Schnittstelle für beinahe jeden heutzutage eingesetzten Verzeichnisdienst - so auch das Microsoft Active Directory. Es basiert auf dem im X.500 -Standard spezifizierten Directory Access Protocol (DAP) 9. Da dieser Standard für viele Anwendungen zu umfangreich war, wurde er im LDAP-Protokoll weniger strikt gehalten. Das hat zur Folge, dass die Kommunikation mit X.500-DAP-Services erfolgreich sein kann, aber nicht muss, da nicht alle Spezifikationen des DAP-Protokolls im LDAP-Protokoll eingehalten werden 10. Das LDAP-Protokoll in der aktuellen Version 3 ist durch die IETF in den RFCs und spezifiziert. 8 Microsoft MSDN: Active Directory Schema Classes. URL: com/en-us/library/windows/desktop/ms680938(v=vs.85).aspx Zuletzt besucht am: vgl. Clines, S./Loughry, M.: Active Directory For Dummies. John Wiley & Sons, 2009, For dummies, ISBN , S siehe a. a. O

32 Kapitel 2. Technologien 2.2. Microsoft Active Directory Zu Beginn einer Anfrage muss stets ein bind-vorgang durchgeführt werden. Bei diesem wird spezifiziert, mit welchem Verzeichnis sich die Anwendung über welchen Port (Standard 389) verbinden soll und welche Benutzerinformation zur Authentifizierung verwendet werden sollen. Danach muss ein Eintrag des Verzeichnisses als Ausgangspunkt sowie ein Suchbereich (scope) angegeben werden. Der Suchbereich kann dabei nur das Objekt (base), nur eine Ebene unterhalb des Objekts (one) oder den gesamten Baum unterhalb des Ausgangspunktes (sub - manchmal auch subtree) umfassen. Eine Suche über das gesamte Verzeichnis führt also einen bind auf den RootDSE mit dem scope sub aus. Abbildung 2.8 demonstriert den Zusammenhang zwischen scope einer Suche und den Ergebnissen. scope = base Domäne scope = one Organisationseinheit Organisationseinheit scope = sub(tree) Organisationseinheit Benutzer Benutzer Abb. 2.8: Active Directory Suchanfragen-Scopes Eine Suche kann darüber hinaus über Filter eingeschränkt werden, die auf Werte vorhandener Attribute prüfen. So kann beispielsweise das ObjectClass -Attribut auf das Vorkommen von User, aber nicht Computer als Filter angegeben werden. Hierdurch werden von der Suche nur Benutzer-Accounts zurückgeliefert, welche dann über einen weiteren Filter beispielsweise nach einem speziellen Namen oder einer -Adresse durchsucht werden können. Um die Menge der Daten, welche eine Antwort enthält zu verringern, können außerdem die Attribute spezifiziert werden, welche diese zurückliefern soll, so dass nicht alle Informationen über das gefundene Objekt übertragen werden müssen, wenn nur eine bestimmte Information benötigt wird

33 Kapitel 2. Technologien 2.2. Microsoft Active Directory Neben der Möglichkeit zur Abfrage können über LDAP auch Attribute manipuliert werden, was natürlich entsprechende Berechtigungen für die zu verändernden Objekte voraussetzt. Berechtigungen spielen im Active Directory stets eine große Rolle - so kann eine Suche mit Domänen-Administrator-Berechtigungen wesentlich mehr Ergebnisse liefern, als die gleiche Suche mit niedrigeren Rechten. Gerade die internen Ordner (Beispielsweise der Container für Tombstone-Objekte) werden im Normalfall nur bei einer Suche mit administrativen Berechtigungen angezeigt. Unter Microsoft Windows kann auf den LDAP-Server mithilfe der Kommandozeilen- Werkzeuge dsquery.exe (für die Suche) und dsmod.exe (für die Manipulation) zugegriffen werden. Innerhalb des.net-frameworks liefert der DirectoryServices 13 - Namespace Klassen und Methoden, welche den Zugriff und die Manipulation von Objekten im Active Directory ermöglichen. Identifikation von Objekten Nach der Abfrage von Objekten über das LDAP-Protokoll stellt sich die Problematik, diese Menge von Ergebnissen zu verarbeiten und untereinander zuzuordnen. Attributsname Object-Class Object-Guid Common-Name Obj-Dist-Name Cannonical-Name Object-Sid SAM-Account-Name SID-History definierende Klasse top top top top top Tab. 2.3: Active Directory Identifikationsattribute securityprincipal securityprincipal securityprincipal Hierbei kann es darum gehen, ihre hierarchische Struktur zu analysieren, sie mit vorherigen Suchen nach eventuellen Veränderungen zu vergleichen oder ihre Beziehungen untereinander zu analysieren. Die meisten der hierfür benötigten Attribute werden durch die Klasse top spezifiziert. Diese enthält alle Attribute, die vom System intern verwendet werden, um Identifikation und Beziehungen zu realisieren. Für alle Objekte, die einen Sicherheitsaspekt beinhalten, wird im Active Directory die Klasse securityprincipal als Hilfsklasse mit eingebunden. Nahezu alle für die Identifikation von Objekten nötigen Attribute

34 Kapitel 2. Technologien 2.2. Microsoft Active Directory werden in diesen beiden Klassen spezifiziert. Die Wichtigsten sind in Tabelle 2.3 aufgeführt und werden im folgenden kurz erläutert: Object-Class Dieses Attribut dient der Identifikation des Typs des Objektes - er enthält eine hierarchisch organisierte Liste aller Klassen, von denen der Typ des Objektes abgeleitet ist - beginnend mit top und endend mit der Klasse des Objektes. Ein Objekt der User -Klasse enthält beispielsweise folgenden Wert im Object-Class -Attribut: ObjectClass = top;person;organizationalperson;user Durch dieses Attribut kann die Klasse eines Objektes eindeutig festgestellt werden. Object-Guid Beim Erstellen eines Objektes im Active Directory wird ein eindeutiger Bezeichner vergeben - die Object-Guid (Global Unique Identifier). Sie ist weltweit eindeutig und verändert sich zur Lebzeit des Objektes nie. Durch die GUID ist jedes Objekt jederzeit eindeutig bestimmt. Common-Name Der Common-Name (in der LDAP-Abfrage Syntax als cn bezeichnet und unter dieser Bezeichnung weit verbreitet) wird beim Erstellen eines Objektes vergeben und wird bei Suchanfragen als Bezeichner verwendet. Er ist mit dem Dateinamen einer Datei in einem Verzeichnisbaum vergleichbar - Ebenso wie dieser muss er zwar innerhalb eines Containers, nicht aber innerhalb der Gesamtstruktur einzigartig sein. SAM-Account-Name Dieses Attribut enthält den Account-Namen des Objektes, der beim Authentifizieren verwendet wird. Daher ist dieses Attribut nur in Klassen vorhanden, die von Security-Principal ableiten. Der SAM-Account-Name entspricht beispielsweise dem Benutzernamen eines Benutzeraccounts innerhalb eines Active-Directory, mit dem sich dieser Nutzer an einem Computer anmelden kann. Oft ist er identisch mit dem Objektnamen. Allerdings ist dies nicht zwingend der Fall, solange er innerhalb der Domäne eindeutig ist. Obj-Dist-Name Der Distinguished-Name spiegelt - ähnlich wie ein Dateipfad innerhalb eines Verzeichnisbaumes - den Namen des aktuellen Objektes und seine

35 Kapitel 2. Technologien 2.2. Microsoft Active Directory Verordnung im Verzeichnisbaum wieder. Hierbei wird eine spezielle Syntax verwendet, die beginnend mit dem Common-Name des Objektes von links nach rechts alle Knoten im Pfad zum rootdse-objekt enthält. Jeder Knoten erhält dabei abhängig von seinem Typ einen Modifizierer. firma.de Benutzer Administratoren Admin Abb. 2.9: Benutzer in einer AD-Hierarchie Im Falle von Domänen wird der Knoten mit dc=name ( dc steht für domain component), im Falle von Organisationseinheiten mit ou=name ( ou für organizational unit) angegeben. Name entspricht hier jeweils dem Common-Name des Knotens. Abbildung 2.9 verdeutlicht dieses Prinzip. Der Canonical-Name für den Benutzer Admin wäre in diesem Falle: Obj-Dist-Name = cn=admin,ou=administratoren,ou=benutzer,dc=firma,dc=de Mithilfe dieses Attributes kann die hierarchische Struktur nachvollzogen werden, in der sich das Objekt befindet Cannonical-Name Der canonical-name eines Objektes entspricht im Grunde dem distinguished-name mit anderer Syntax. Auch dieses Attribut liefert die Position des Objektes im Verzeichnisbaum, allerdings mithilfe der von Internet- Adressen weit verbreiteten Syntax mit. und / als Trennzeichen. Der Cannonical- Name des Admin-Benutzers aus Abbildung 2.9 wäre somit: Canonical-Name = firma.de/benutzer/administratoren/admin Object-SID Dieses Attribut stellt einen Wert zur Verfügung, welcher seit Windows NT zur Authentifizierung von Benutzern und Gruppen verwendet wird. Es ist in der Klasse security-principal enthalten. Daher steht es vorrangig in den Objekten zur Verfügung, die an einer Authentifizierung beteiligt sind - also Domänen, Benutzern, Gruppen und Computern. Eine SID (Security Identifier) ist zwar als Byte-Feld variabler Länge definiert 14 jedoch wird meist eine String-Repräsentation

36 Kapitel 2. Technologien 2.2. Microsoft Active Directory verwendet, welche Aufschlüsse über das beschriebene Objekt ermöglicht - das Byte-Feld einer SID ist wie folgt definiert 15 : Revision SubAuthCount IdentifierAuthority SubAuthority0 } General Max. 15 SubAuthorityN Abb. 2.10: Bitfeld einer SID Die Revision ist hierbei stets 1, da es bisher keine andere SID-Revisionsnummer gibt. SubAuthCount spezifiziert die Anzahl der folgenden untergeordneten Authoritäten, die zur Identifikation herangezogen werden müssen und IdentifierAuthority gibt die Authorität an, unter welcher die SID erzeugt wurde - hierbei sind bisher die folgenden Werte definiert 16 : 0 - NULL-Authorität, die den Wert Niemand bei einer Berechtigung symbolisiert. 1 - WORLD-Authorität - wird verwendet, um den globalen Jeder -Wert zu definieren. 2 - LOCAL-Authorität - diese SID wird auf der Lokalen Maschine authorisiert. 3 - CREATOR-Authorität - wird als Platzhalter verwendet, um dem des Objektes spezielle Berechtigungen zuzuweisen. 5 - NT_AUTHORITY-Authorität. Diese Form ist der häufigste Fall innerhalb des Active Directory - hierbei spezifizieren die SubAuthorities die entsprechende Domäne, die für die Authentifizierung der SID verwendet werden muss. 15 Siehe: 16 Siehe:

37 Kapitel 2. Technologien 2.2. Microsoft Active Directory 10 - MANDATORY-LABEL-AUTHORITY-Authorität umfasst die ins System integrierten Accounts und Gruppen SECURITY_APP_PACKAGE_AUTHORITY-Authorität enthält die Accounts, die Zugriff auf bestimmte integrierte Dienste und Programme (wie die Nutzerkonten- Verwaltung oder die Firewall) besitzen. Die SubAuthorities werden meist dazu verwendet, um bei domänenübergreifendem Zugriff die Heimatdomäne anzugeben, welche das zu Authentifizierende Objekt enthält und die Authentifizierung übernehmen muss. Dieses Bit-Feld wird wie folgt in einer Zeichenkette dargestellt 17 : S-v-id-s1-s2-s3-s4-s5-s6-s7-s8-s9-s10-s11-s12-s13-s14-s15 S Zeigt an, dass es sich um eine SID handelt v gibt die Version der SID an - derzeit immer 1 id die IdentifierAuthority der SID s1-s15 - die SubAuthorities der SID - bei einer Domänen-SID ist stets s1 = 21, gefolgt von s2-s4, welche die SID der Ursprungsdomäne des Accounts definieren. Sie enthalten die SID der Domäne gefolgt von einer RID (Relative Identifier), die das Objekt identifiziert. Diese RID ist als ganze Zahl realisiert und beginnt im Falle von neu angelegten Benutzeraccounts bei dem Wert Der erste, in einem Windows-System erstellte Account erhält somit die RID Eine übliche SID folgt also dem Schema: S xxx-yyy-zzz-RID wobei die Werte von xxx, yyy und zzz die Domäne (oder den lokalen Computer) definieren, in der sich dieser Account befindet. Sie werden bei der Erstellung 17 Siehe Desmond, B. et al.: Active Directory: Designing, Deploying, and Running Active Directory. O Reilly Media, 2008, O Reilly Series, ISBN , S

38 Kapitel 2. Technologien 2.2. Microsoft Active Directory einer Domäne oder der Installation eines Betriebssystems auf einem Computer einmalig generiert. Der Wert von RID stellt den Relative Identifier des Objektes dar. Es existieren einige vordefinierte ( Well-Known ) RIDs, welche die vordefinierten System-Accounts und Gruppen umfassen. Ihre RIDs sind im Normalfall kleiner als 1000, um sie eindeutig von nachträglich angelegten SIDs zu unterscheiden. Einige Beispiele hierfür sind: RID SID Beschreibung 544 S lokale Administratoren-Gruppe eines Computers 545 S lokale Benutzergruppe eines Computers 513 S <domain-SID>-513 Gruppe aller Benutzer einer Domäne 515 S <domain-SID>-515 Gruppe aller Computer einer Domäne - S Alle Benutzer - S Netzwerk-Dienst-Account Tab. 2.4: Well-Known RIDs Eine umfassende Übersicht findet sich unter: kb/ SID-History Da die SID einen Domänenspezifischen Anteil enthält, muss beim Umzug eines Nutzers in eine andere Domäne eine neue SID vergeben werden. Um weiterhin Berechtigungen über die alte SID vergeben zu können oder die Möglichkeit der Nachverfolgung zu haben, werden in diesem Attribut ältere SIDs abgelegt. Da ein Umzug zwischen Domänen aber selten vorkommt, ist dieses Feld in den meisten Fällen leer. Organisationseinheiten Um das Active Directory hierarchisch zu organisieren, bedarf es einer Anzahl an Containern, welche andere Objekte beinhalten und auf diese Weise strukturieren können. Sieht man einmal von Sites und ganzen Domänen ab, gibt es die Möglichkeit, Objekte entweder in Containern oder Organisationseinheiten (oft als OU - Organizational Unit bezeichnet) zu größeren Einheiten zusammenzufassen. Der

39 Kapitel 2. Technologien 2.2. Microsoft Active Directory einzige, aber entscheidende Unterschied besteht darin, dass Organisationseinheiten mit Gruppenrichtlinien (siehe 2.2.1) verknüpft werden können. Diese ermöglichen es, Einstellungen für alle Objekte (wie Benutzer oder Computer) einer Organisationseinheit mit einer einzigen Gruppenrichtlinie festzulegen. Ihr Verhalten ist dabei kumulativ - d.h. es existiert die Möglichkeit, generelle Einstellungen auf einer oberen Ebene der OU-Struktur vorzunehmen und diese dann in den unteren Ebenen weiter zu verfeinern oder abzuändern. Da Container im Vergleich zu Organisationseinheiten keinerlei Vorteile bieten, finden diese (abgesehen von den Standard-Containern eines Active Directory nach der Erstellung) kaum Verwendung. Benutzer Diese Objekt-Kategorie spiegelt in ihrer Summe alle Accounts wieder, mit welchen sich an Systemen authentifiziert werden kann. Hierunter fallen normale Mitarbeiter eines Unternehmens sowie spezielle Accounts für administrative Berechtigungen zur Ausführung von Dienstanwendungen oder Gast-Accounts. Ein Benutzer-Objekt verfügt über Attribute, die die persönlichen Informationen des Benutzers enthalten. Hierzu zählen sein Arbeitsplatz, Telefonnummer, -Adresse oder sein Vorgesetzter. Letzteres wird über ein sogenanntes Linked-Attribute 18 realisiert, welches BackwardLink Vorgesetzter distinguishedname: cn=vorgestzter, ou=user, dc=firma, dc=de directreports: cn=mitarbeiter, ou=user, dc=firma, dc=de Mitarbeiter distinguishedname: cn=mitarbeiter, ou=user, dc=firma, dc=de Manager: cn=vorgesetzter, ou=user, dc=firma, dc=de Abb. 2.11: Linked-Attribute ForwardLink den distinguishedname eines anderen Benutzers enthalten kann. Es ist daher nur ein Verweis auf einen anderen Benutzer im Active Directory, der innerhalb der realen Unternehmensstruktur in einer bestimmten Beziehung zu dem Besitzer des 18 Siehe Desmond et al.: Active Directory: Designing, Deploying, and Running Active Directory, S

40 Kapitel 2. Technologien 2.2. Microsoft Active Directory verweisenden Accounts steht. Da der distinguishedname allerdings Veränderungen unterliegen kann - ähnlich wie der Dateipfad einer Datei beim Verschieben - existiert in dem referenzierten Objekt ein Feld mit dem Namen directreports. Dieses enthält alle referenzierenden Objekte für die Mitarbeiter-Vorgesetzter Beziehung. In der deutschen Übersetzung der GUI wird der Inhalt dieses directrepots -Feldes als Liste mit dem Namen Mitarbeiter angezeigt - es spiegelt alle Benutzer wieder, für die der aktuelle Account als Vorgesetzter eingetragen wurde. Somit ist die Verknüpfung zwischen den Accounts von Vorgesetzten und Mitarbeitern bidirektional und bei einer Veränderung des distinguishedname-attributes eines beteiligten Accounts wird auch der entsprechende Verweis auf der anderen Seite der Verbindung aktualisiert. Die beiden Verweisrichtungen werden mit ForwardLink und BackwardLink bezeichnet, wobei die Bezeichnung von dem betrachteten Benutzer abhängig ist. Aus der Sicht des Managers ist das Attribut directreports der ForwardLink und das Manager -Attribut des Benutzers der BackwardLink, liegt der Ausgangspunkt der Betrachtung bei dem Benutzer, ist die Benennung umgekehrt. Abbildung 2.11 illustriert diese Umsetzung anhand des Manager -Attributes eines Benutzers. Diese Linked-Attributes kommen ebenso bei der Mitgliedschaft von Benutzern und Gruppen zum Einsatz. Der Unterschied in diesem Falle besteht lediglich darin, dass hier auf beiden Seiten eine Liste an Werten möglich ist, da ein Benutzer zwar (nach dem Modell des Active Directory) nur einen direkten Vorgesetzten haben, aber Mitglied einer Vielzahl von Gruppen sein kann. Ein weiteres wichtiges Attribut des Benutzer-Objektes ist die User-Account- Control. Hierbei handelt es sich um ein Bitfeld, welches in der Klasse User definiert wird und somit für Computer-Objekte ebenso zur Verfügung steht und hier auch umfassende Verwendung findet. Es dient der Definition des Typs und Zustandes eines Benutzer- oder Computeraccounts. Die einzelnen Bitflags sind in Abbildung 2.12 erläutert 19. Über die Werte dieses Feldes kann eine Vielzahl von Informationen und Status festgelegt werden. So kennzeichnet das Feld NORMAL_ACCOUNT einen Benutzeraccount, welcher je nach Wert des Feldes ACCOUNTDISABLE aktiviert oder deaktiviert ist. Ist das Bit WORKSTATION_TRUST_ACCOUNT gesetzt, handelt es sich um einen normalen Domänencomputer, im Falle von der Kombination aus 19 Siehe:

41 Kapitel 2. Technologien 2.2. Microsoft Active Directory SCRIPT ACCOUNTDISABLE HOMEDIR_REQUIRED ACCOUNT_LOCKED PASSWD_NOTREQD PASSWD_CANT_CHANGE ENCRYPTED_TEXT_PWD_ALLOWED TEMP_DUPLICATE_ACCOUNT NORMAL_ACCOUNT INTERDOMAIN_TRUST_ACCOUNT WORKSTATION_TRUST_ACCOUNT SERVER_TRUST_ACCOUNT TRUSTED_FOR_DELEGATION DONT_EXPIRE_PASSWORD MNS_LOGON_ACCOUNT SMARTCARD_REQUIRED NOT_DELEGATED USE_DES_KEY_ONLY DONT_REQ_PREAUTH PASSWORD_EXPIRED TRUSTED_TO_AUTH_FOR_DELEGATION PARTIAL_SECRETS_ACCOUNT Abb. 2.12: UserAccount-Control-Bitfeld eines normalen Benutzeraccounts SERVER_TRUST_ACCOUNT und TRUSTED_FOR_DELEGATION um einen Domänencontroller. Das Attribut User-Account-Control wird innerhalb der.net-implementation als Dezimalzahl zurückgeliefert, jedoch können durch Bitvergleichsoperationen einfach Typ und Status des Objekts ausgelesen und durch Setzen der entsprechenden Bits verändert werden. Gruppen Gruppen stellen auf abstrakter Basis einen Container dar, der ausschließlich andere Gruppen oder Objekte der Klasse User enthalten kann. Computer-Accounts können daher ebenso wie Benutzer in einer Gruppe enthalten sein, da ihre Klasse Unterklasse von User ist. Die Group -Klasse ist direkt von top abgeleitet, bindet aber zusätzlich security-principal mit ein und verfügt somit über ein Attribut für eine SID. Die Mitgliedschaft in Gruppen wird, ähnlich wie dem Manager -Attribut eines Benutzers durch ein Linked-Attribute (vgl ) realisiert, wobei die Gruppe die jeweiligen Common-Name -Attributswerte ihrer Mitglieder und jedes Mitglied eine Liste aller Common-Names der Gruppen enthält, in denen es eingetragen wurde. Auf diese Weise können bei Veränderungen an einer Gruppe oder einem Mitglied diese Informationen an das entsprechende andere Objekt weitergegeben

42 Kapitel 2. Technologien 2.2. Microsoft Active Directory Scope Mögliche Mitglieder Kann Mitglied sein von Kann Berechtigungen erteilen in Universal Global Local -gültige Objekte aus der gleichen Domäne -globale und universelle Gruppen jeder anderen Domäne im gleichen Forest(2.2.3) -gültige Objekte der gleichen Domäne -andere globale Gruppen der gleichen Domäne -gültige Objekte von jeder vertrauten Domäne -globale Gruppen jeder vertrauten Domäne -universelle Gruppen jeder Domäne im gleichen Forest -andere lokale Gruppen der gleichen Domäne -Objekte, globale und universelle Gruppen anderer Forests -anderen universellen Gruppen im gleichen Forest -lokalen Domänengruppen oder lokalen Gruppen auf Computern im gleichen oder einem vertrauten Forest -universellen Gruppen jeder Domäne im gleichen Forest -anderen globalen Gruppen der gleichen Domäne -lokalen Gruppen jeder Domäne im gleichen Forest oder direkter Vertrauensstellung -anderen lokalen Gruppen der gleichen Domäne -Lokale Gruppen auf Maschinen der gleichen Domäne, wobei Gruppen mit Well-Known-SIDs(2.4) ausgenommen sind Tab. 2.5: Group-Scopes jeder Domäne im gleichen oder vertrauten Forest jeder Domäne im gleichen Forest oder jeder Domäne oder Forest mit direkter Vertrauensstellung der eigenen Domäne und dort verarbeitet werden, beispielsweise wenn sich der canonical-name durch Verschieben geändert hat. Grundsätzlich unterteilt sich die Menge an Gruppen-Objekten in zwei unterschiedliche Kategorien - distribution und security, wobei ersteres den weniger verbreiteten Typus darstellt. Distributive-groups verfügen über keine eigene SID, sondern dienen lediglich dazu, ihre enthaltenen Objekte zu einer organisatorischen Gruppe zusammenzufassen. Die eigentlichen Auswirkungen der Mitgliedschaft in einer solchen Gruppe wird durch die Auswertung anderer Logiken bestimmt. Als Beispiel für die Anwendung einer distributive-group ist beispielsweise eine Mailing-Liste denkbar, bei der eine Mail über die Adresse der Gruppe an alle Mitglieder weitergeleitet

43 Kapitel 2. Technologien 2.2. Microsoft Active Directory wird. Security-Groups hingegen verfügen über eine eigene SID, wodurch dieser Berechtigungen erteilt und entzogen werden. Die SID der Gruppe wird der SID jedes enthaltenen Objekts bei seiner Authentifizierung hinzugefügt, wodurch die Berechtigungen der Gruppe übernommen werden. Ein weiterer entscheidender Mechanismus der Gruppen innerhalb des Active Directory ist deren scope. Dieser kann drei unterschiedliche Werte annehmen: domain local, domain global sowie universal. Der Scope einer Gruppe steuert, aus welchen Strukturen sie andere Objekte aufnehmen und in welchen anderen Strukturen auf sie zugegriffen werden kann. Der Zugriff ist meist entweder notwendig, um sie in andere Gruppen aufzunehmen oder ihr Berechtigungen und Sicherheitseinstellungen zuzuordnen. Die Tabelle 2.5 zeigt die Unterschiede zwischen den einzelnen Werten auf 20. Die Scopes führen dazu, das vor dem Erstellen einer Gruppe genau modelliert werden muss, welche Objekte sie beinhalten und in welchen anderen Gruppen oder Sicherheitskonzepten sie enthalten sein soll. Hierbei kann das UGLy-Prinzip Users into Global, Global into Local, Local get permissions 21 eine grobe Rahmenlinie geben. Generell gibt es aber meist mehrere Möglichkeiten, die Gruppen anzulegen und ineinander zu verschachteln. Gruppen spielen in den meisten Active Directory- Strukturen die zentrale Rolle im Berechtigungsmanagement, da über ihre SID der Zugriff auf nahezu alle Ressourcen wie Computer, Drucker, Netzwerkfreigaben und Server an zentraler Stelle verwaltet wird. Möglichkeiten der automatisierten Abfrage von Objekten Das.NET-Framework stellt mit dem DirectoryServices-Namespace Klassen und Interfaces zur Verfügung, mit denen ein Active Directory abgefragt werden kann. Die wichtigste stellt hierbei sicherlich der DirectorySearcher dar, welcher an ein Objekt im Active Directory (über dessen distinguishedname oder die objectguid ) gebunden werden kann und ausgehend von diesem eine Suche initiieren kann. Dieser Suche können über Parameter auch Attributswerte als Filterargumente oder ein Scope mitgegeben werden. Der Scope kann angeben, ob nur das Objekt selbst, alle Objekte in der gleichen Ebene der Baumstruktur oder alle Objekte unterhalb 20 vgl Desmond et al.: Active Directory: Designing, Deploying, and Running Active Directory, S.255, Z

44 Kapitel 2. Technologien 2.2. Microsoft Active Directory zurückgegeben werden sollen. Durch Scope und Filter kann die Suche eingeschränkt und somit auf die Bedürfnisse angepasst werden. Des Weiteren kann über eine Liste die Menge an abzufragenden Attributen spezifiziert werden, um die Größe der übertragenen Datenmenge zu reduzieren, da nicht angegebene Attribute nicht übertragen werden. Dennoch liefert diese Art der Suche stets Objekte in ihrem aktuellen Status. Soll die Aufgabe gelöst werden, Objekte und ihre Veränderungen zu überwachen, stehen mit dem.net-framework hierzu zwei unterschiedliche Herangehensweisen zur Wahl: 1. Observer-Notification - der Active-Directory-Domänencontroller stellt eine Möglichkeit zur Verfügung, über welche sich Programme für Benachrichtigung bei Veränderung registrieren können. Hierzu müssen zwar einige der Standard-.Net-Klassen modifiziert werden, aber es besteht so die Möglichkeit durch Events über Veränderungen benachrichtigt zu werden und kein aktives Polling verwenden zu müssen. Hierbei wird per Programmcode ein Active- Directory-Objekt als Ausgangspunkt der Suche, sowie optional ein Scope und Filterkriterien spezifiziert. Sobald sich ein Objekt innerhalb dieser Suchkriterien verändert, wird das Event ausgelöst und die Veränderungen können von der Programmlogik verarbeitet werden. Problematisch hierbei ist zum einen, dass keine Beschränkung der Attribute möglich ist. Das Event wird bei jeder Veränderung gerufen und liefert stets das gesamte Objekt zurück, die einzelne Veränderung muss über einen Vergleich mit dem vorherigen Status von der Programmlogik gebildet werden. Zum anderen ist die Anzahl gleichzeitig registrierter Observer je Domänencontroller auf fünf beschränkt. Dieses lässt sich in den internen Einstellungen der LDAP-Policies beliebig verändern, jedoch lieferte der Microsoft-Support auf Nachfrage folgende Begründung für diese Beschränkung: MaxNotificationPerConn is a quota to avoid resource monopolization and overhead n AD. Note EVERY AD change MUST be checked against the filter in the notification request. The bigger the AD, the worse this is. You can raise it until your DCs start falling over

45 Kapitel 2. Technologien 2.2. Microsoft Active Directory So notifications are not a very good way to get AD changes, esp. when you need them for many objects (big object trees) and for an extended time. Microsoft Partner Services per Mail Da gemäß dieser Aussage jede Veränderung an einem beliebigen Active Directory-Objekt eine Überprüfung aller registrierten Observer nach sich zieht, benötigt dieser Mechanismus mit wachsender Anzahl an Observern und Objekten im Active-Directory Verzeichnisbaum immer mehr Ressourcen. Da aber manche Objekte über Attribute verfügen, die häufig gesetzt oder verändert werden, wie beispielsweise ein Attribut im Benutzer-Account, welches den Zeitpunkt der letzten Anmeldung speichert, ist diese Methode in ihrem Einsatz stark eingeschränkt. 2. DirSync-Cookie Als Alternative zu einer Event-basierten Benachrichtigung kann das DirSync-Cookie verwendet werden. Es kann nach einer Suche mithilfe eines DirectorySearcher-Objektes gesichert und der nächsten Suche mit diesem Objekt (bei gleichen Filterregeln und Scope) mitgegeben werden. Die Suche liefert dann als Resultat lediglich die Objekte, deren in der Suche spezifizierten Attribute sich seit dem letzten Suchvorgang verändert haben. Hiermit ist aber stets ein aktives Polling verbunden. Die Vorteile liegen in der Möglichkeit, die Menge der übertragenen Daten zu beschränken und gezielter auf Veränderungen zu reagieren. Außerdem wird der Domänencontroller weniger stark ausgelastet. Die Wahl der Methode muss je nach Anforderung getroffen werden. Die Observer- Variante eignet sich im Allgemeinen eher für das gezielte Beobachten einzelner Objekte eignet, wenn zeitnah auf Veränderungen reagiert werden muss. Bei der Abfrage großer Datenbestände (insbesondere ganzer Active Directory-Verzeichnisbäume) bei denen zeitnahe Verarbeitung nicht oberste Priorität genießt, ist hingegen der DirSync-Cookie die bessere Wahl

46 Kapitel 2. Technologien 2.2. Microsoft Active Directory Domänenstrukturen Um ein Active Directory zu konstruieren, muss zunächst ein existierender Server zu einem Domänencontroller promoted werden. Unter Windows Server geschieht dies mithilfe der Kommandozeilenanwendung dcpromo.exe. Nach der Installation der Active Directory Dienstes, des DNS-Servers (der zwingend für die Installation vonnöten ist) und anderer Dienste, muss entschieden werden, ob die neue Domäne eine eigenständige Struktur bildet oder einer bestehenden Struktur eingefügt werden soll. Entscheidet man sich an dieser Stelle dafür, eine neue Struktur zu erstellen, wird ein komplett eigenständiger Verzeichnisbaum mit eigenem Namenskontext generiert. Diese so erstellte Struktur wird als Domäne bezeichnet. Sie ist dadurch definiert, dass sie 22 : - eine eigene Containerstruktur besitzt, welche sich über X.500 kompatible Protokolle (LDAP) abfragen lässt - einen einzigartigen DNS-Domainnamen besitzt (wie beispielsweise myfirstdomain.local) - mindestens einen Domänencontroller, der einen Sicherheitsdienst zur Authentifizierung, sowie Richtlinien für Maschinen und Benutzer bereitstellt Aufgrund ihrer hierarchischen Struktur wird bereits eine einzelne Domäne als Tree bezeichnet. Innerhalb ihrer Baumstruktur sind die einzelnen Objekte durch Organisationseinheiten zusammengefasst und organisiert. Eine Domäne kann auch weitere Domänen beinhalten. Diese werden als childdomains oder subdomains bezeichnet, wobei die oberste Domäne stets als rootdomain referenziert wird. Der DNS-Name einer Subdomäne wird stets um den Namenskontext ihrer übergeordneten Domäne erweitert. Auch alle enthaltenen Objekte enthalten diesen Kontext in ihrem canonicalname sowie dem distinguishedname. Durch die Tatsache, dass eine Domäne über beliebig viele subdomänen verfügen und diese selbst wiederum subdomänen enthalten können, werden komplexe Domänenstrukturen der Bezeichnung Tree gerecht. Abbildung 2.13 veranschaulicht eine solche Struktur. Anhand 22 vgl. Desmond et al.: Active Directory: Designing, Deploying, and Running Active Directory, 20f

47 Kapitel 2. Technologien 2.2. Microsoft Active Directory myfirstdomain.local subdomain.myfirstdomain.local secondsubdomain.myfirstdomain.local subsubdomain.subdomain.myfirstdomain.local Abb. 2.13: Domänen-Tree ihrer distinguishedname -Attribute kann man Objekte ihrer Ursprungsdomäne zuordnen: Objekt aus Domäne subdomain: distinguishedname = [...],dc=subdomain,dc=myfirstdomain, dc=local Objekt aus Domäne subsubdomain: distinguishedname = [...],dc=subsubdomain,dc=subdomain,dc=myfirstdomain, dc=local Darüber hinaus ist auch die erste subauthority der SID eines Objektes (vgl. 2.10) gleich der SID des Domänen-Objektes, in dem es enthalten ist. Über diese Mechanismen können Objekte eindeutig einer Domäne zugeordnet werden. Vertrauensstellungen Sollen nun domänenübergreifende Zugriffe gestattet werden, beispielsweise Benutzern ermöglicht werden, sich an Computern einer anderen Domäne anzumelden, so wird ein Objekt stets an dem Domänencontroller seiner eigenen Domäne authentifiziert. Die bei dieser Authentifikation generierte Bestätigung, dass beispielsweise Benutzername und Passwort bekannt und übereinstimmend sind, muss dann von

48 Kapitel 2. Technologien 2.2. Microsoft Active Directory dem Domänencontroller, der die gewünschte Ressource beinhaltet, akzeptiert werden. Innerhalb einer Domäne ist dies meist der gleiche Server, womit sichergestellt werden kann, dass der Bestätigung für einen gültigen Account vertraut wird. Vertrauensstellungen zwischen Domänen Handelt es sich hierbei jedoch um zwei unterschiedliche Domänen und Domänencontroller, so wird die Anmeldung generell abgewiesen, da der Authentifikation nicht vertraut wird. Um dennoch domänenübergreifende Authentifizierungen zu ermöglichen, bietet das Active Directory die sogenannten Trusts (im Deutschen: Vertrauensstellungen). Mit ihnen können Domänen spezifiziert werden, deren Authentifizierungen vertraut wird und deren Accounts daher auch auf Ressourcen der eigenen Domäne Zugriff gewährt werden kann. Trusts stellen ein komplexes Modell dar, dass jedoch, solange lediglich die Trusts zwischen zwei Domänen betrachtet werden, in unidirektionale und bidirektionale Trusts aufgeteilt werden kann. Diese werden in Abbildung 2.14 dargestellt. Domäne1 Domäne2 Domäne1 Domäne2 Domäne1 Domäne2 (a) unidirektional (b) unidirektional (c) bidirectional Abb. 2.14: Trust-Relationships zwischen Domänen Ein Unidirektionaler Trust wird je nachdem, ob er von der entsprechenden Domäne ausgehend oder eingehend ist, als Inbound oder Outbound bezeichnet. Tabelle 2.6 erläutert die Zugriffsmöglichkeiten der in Abbildung 2.14 dargestellten Trusts. Domäne 1 Domäne 2 Authentifizierung 1->2 Authentifizierung 1<-2 (a) Inbound Outbound ja nein (b) Outbound Inbound nein ja (c) Bidirectional Bidirectional ja ja Tab. 2.6: Zugriffsmöglichkeiten unterschiedlicher Vertrauensstellungen

49 Kapitel 2. Technologien 2.2. Microsoft Active Directory Dies Bedeutet, dass Benutzer auf Ressourcen einer anderen Domäne zugreifen können, wenn zwischen ihrer eigenen und der Domäne, in der sich die Ressource befindet, entweder eine bidirektionale oder eine unidirektionale, in der eigenen Domäne als Inbound klassifizierte Vertrauensstellung hergestellt ist. Transitive Vertrauensstellungen Jede Vertrauensstellung zwischen Domänen kann über ihre Eigenschaft uni- oder bidirektional zu sein hinaus, entweder transitiv oder nicht-transitiv sein. Bei einer transitiven Vertrauensstellung zwischen Domänen wird die Vertrauensstellung auf alle weiteren Vertrauensstellungen der beteiligten Domänen erweitert, bei Nicht-transitivität bleibt sie auf die beiden unmittelbar betroffenen beschränkt. Ist die in Abbildung 2.15 dargestellte Vertrauensstellung zwischen Domäne1 und Domäne2 transitiv, so könnten sich Benutzer aus Domäne1 auf Ressourcen Domäne1 Domäne2 Domäne3 von Domäne3 zugreifen und umgekehrt. Transitive Vertrauensstellungen müssen Abb. 2.15: Transitive Vertrauensstellung aber nicht bidirektional sein - bei einer unidirektionalen, transitiven Vertrauensstellung werden die Vertrauensstellungen nur auf der Outbound -Seite weitergereicht. Alle Domänen innerhalb eines Forest sind automatisch durch sogenannte Strukturvertrauensstellungen miteinander verbunden - diese sind stets bidirektional und transitiv. Dadurch ist sichergestellt, das sich Benutzer aus einer Subdomäne auch ihrer übergeordneten Domäne gegenüber authentifizieren können und umgekehrt. Wichtig hierbei ist, dass die Möglichkeit der Authentifizierung (im Normalfall) nicht gleichbedeutend mit der Erlaubnis des Zugriffs ist. Daher wird oft davon abgeraten, Ressourcen für die vordefinierten Gruppen (siehe Tabelle 2.4) Jeder und Alle authentifizierten Benutzer freizugeben. Sicherer ist hier, die Berechtigungen auf eigene Gruppen (oder die Gruppen mit allen Benutzern einer bestimmten Anzahl von Domänen) zu beschränken, da gerade über transitive Vertrauensstellungen schnell Veränderungen in der Mitgliedschaft der allgemeinen Gruppen eintreten können, über die ungewünschte Accounts Zugriff auf eigene Ressourcen erhalten

50 Kapitel 2. Technologien 2.2. Microsoft Active Directory Vertrauensstellungen zwischen Forests Grundsätzlich gilt für Vertrauensstellungen das gleiche wie zwischen Domänen. Lediglich mit der Einschränkung, dass Forst-Trusts immer transitiv sind, sich dabei aber auf die Domänen der jeweiligen Forests beschränken, also nicht außerhalb der jeweiligen Forestgrenzen erweiterbar sind. Eine Vertrauensstellung zwischen zwei Forests wirkt so wie eine Menge an Vertrauensstellungen gleicher Art (Bi- oder Unidirektional) zwischen allen Domänen des einen beteiligten Forests mit allen Domänen des anderen. Domänen eines weiteren Forests werden nicht mit eingeschlossen, selbst wenn dieser eine transitive Vertrauensstellung zu einer der betroffenen Domänen besitzt. Foreign Security Principals Vertrauensstellungen ermöglichen nicht nur domänenübergreifenden Zugriff auf Ressourcen, sondern sorgen auch dafür, dass Accounts in Gruppen aufgenommen werden können, die einer anderen Domäne angehören. Da die Gruppenmitgliedschaft aber über das Linked-Attribute (siehe Kapitel 2.2.2, S. 34) members geregelt wird und dieses ausschließlich distinguishedname -Werte der eigenen Domäne akzeptiert, besteht hierin ein strukturelles Problem, da diese Accounts nicht innerhalb der gleichen Domäne wie die Gruppe verordnet sind. Dieses Problem wird dadurch gelöst, das in der Domäne der Gruppe ein neues Objekt generiert wird, dass als eine Art Stellvertreter für das Objekt der verweisenden Domäne verstanden werden kann. Diese Objekte werden als ForeignSecurityPrincipals bezeichnet und liegen in dem Gleichnamigen Container unterhalb des rootdse jeder Domäne. Sie werden für jeden Account einer Domäne aus einem anderen Forest angelegt, das in eine Gruppe aufgenommen wird oder dem anderweitig Berechtigungen zugewiesen werden. Ein ForeignSecurityPrincipal besitzt sowohl als commonname als auch als objectsid die SID des Objektes, auf das es verweist. Da die SID die Domäne, aus der das Objekt stammt, in seinem SubAuthority-Wert enthält, kann diese leicht identifiziert und das Objekt anhand seiner SID dort identifiziert werden. Abbildung 2.16 verdeutlicht dieses Prinzip. In dem dort abgebildeten Beispiel wird der Administrator-Account aus Domäne1 in die Gruppe der Administratoren der Domäne2 aufgenommen. Da beide Domänen

51 Kapitel 2. Technologien 2.3. Microsoft Silverlight Bidirectional Trust Domäne1 Domäne2 User ForeignSecurtiyPrincipals User Administrator SID: S <Domäne1-SID>-RID S <Domäne1-SID>-RID SID: S <Domäne1-SID>-RID Administratoren Abb. 2.16: ForeignSecurityPrincipal zwischen zwei Domänen in unterschiedlichen Forests verordnet, aber durch einen bidirektionalen Trust verbunden sind, wird ein ForeginSecurityPrincipal in Domäne2 erzeugt. Dieses erhält als Namen und SID die SID des Administrator-Accounts aus Domäne1 und wird über seinen distinguishedname in Domäne2 in die Liste der Miglieder der Administratoren-Gruppe aufgenommen. Durch diesen Mechanismus erhält der Administrator-Account die Berechtigungen der Gruppe in Domäne2. Bei der automatisierten Abfrage von Gruppenmitgliedern kann in diesem Falle recht schnell erkannt werden, dass es sich um einen Account aus einer anderen Domäne handelt, da das Objekt, welches Mitglied der Gruppe ist, aus dem Ordner ForeignSecurityPrincipals stammt. Über seinen Namen erhält man die SID des eigentlichen Objektes, sowie die SID der Domäne, in der dieses enthalten ist. Entsprechende Berechtigungen in der verweisenden Domäne vorausgesetzt, kann diese nun nach dem Objekt durchsucht werden und die gewünschten Informationen abgefragt und ausgewertet werden - Beispielsweise Name oder ob es sich um eine weitere Gruppe oder einen Nutzeraccount handelt. 2.3 Microsoft Silverlight Microsoft Silverlight ist ein Framework, mit dessen Hilfe Rich Internet Aplications entwickelt werden können. Diese Anwendungen erlauben es, innerhalb von Internetseiten komplexere Programmlogik auszuführen, als dies mit reinem HTML

52 Kapitel 2. Technologien 2.3. Microsoft Silverlight möglich wäre. So können Multimediainhalte wie Videos in Seiten eingebunden werden oder komplexe grafische Benutzeroberflächen entwickelt werden, welche aufwendigere Eingabetechniken wie beispielsweise Drag and Drop ermöglichen. Silverlight wurde von Microsoft als Alternative zu der Flash-Technologie von Adobe entwickelt und wird mittlerweile durch Plugins von nahezu allen weit verbreiteten Browsern unterstützt. Allerdings gilt dies lediglich für Browser unter Windows - für Linux existiert zwar eine Silverlight-Adaption von Novell mit dem Namen Moonlight jedoch wurde deren Weiterentwicklung mittlerweile eingestellt, so dass für aktuelle Silverlight-Anwendungen auf eine Windows-Umgebung zurückgegriffen werden muss Silverlight aus Entwicklersicht Bei der Entwicklung von Silverlight-Anwendungen wird für die grafische Gestaltung auf das Windows Presentation Framework (WPF) zurückgegriffen. Dieses sieht eine klare Trennung der Gestaltung von Benutzeroberflächen und der Programmlogik vor. Bei der Entwicklung der Logik bringt dies für den Programmierer auf den ersten Blick wenig Veränderungen mit sich. Silverlight-Anwendungen werden in C# geschrieben, wobei sich ein im Funktionsumfang reduziertes.net-framework nutzen lässt. Diesem fehlen insbesondere Namespaces, welche auf das Betriebssystem zugreifen müssen. So sind beispielsweise keine Active-Directory-Abfragen möglich, es stehen keine Semaphoren zur Threadsynchronisierung zur Verfügung und Zugriffe auf das lokale Dateisystem gestalten sich komplizierter als in einer reinen C#-.NET-Anwendung. Für die Entwicklung grafischer Bestandteile Abb. 2.17: Silverlight-Oberfläche hingegen wird in WPF eine Klasse mit grafischer Oberfläche in zwei Quellda

53 Kapitel 2. Technologien 2.3. Microsoft Silverlight 1 < UserControl 2 xmlns : sdk =" http :// schemas. microsoft. com / winfx /2006/ xaml / presentation / sdk " 3 x: Class =" SilverlightApplication1. MainPage " 4 xmlns =" http :// schemas. microsoft. com / winfx /2006/ xaml / presentation " 5 xmlns :x=" http :// schemas. microsoft. com / winfx /2006/ xaml "> 6 <StackPanel > 7 <sdk : Label Content =" Bitte geben Sie Benutzername und Passwort ein :"/ > 8 < StackPanel Orientation =" Horizontal " > 9 <sdk : Label Content =" Benutzername : " / > 10 < TextBox Width =" 100 "/> 11 </ StackPanel > 12 < StackPanel Orientation =" Horizontal " > 13 <sdk : Label Content =" Passwort : " / > 14 < TextBox Width =" 100 "/> 15 </ StackPanel > 16 < StackPanel Orientation =" Horizontal " > 17 < Button Content =" Anmelden " Click =" Anmelden_Click "/ > 18 < Button Content =" Abbrechen " Click =" Abbrechen_Click "/ > 19 </ StackPanel > 20 </ StackPanel > 21 </ UserControl > Abb. 2.18: Beispiel einer XAML-Datei teien aufgeteilt. Es entsteht eine herkömmliche.cs-datei, die Programmierung und Logik enthält, sowie eine.xaml-datei innerhalb derer die grafische Repräsentation definiert wird. Letztere wird dazu verwendet, die grafische Darstellung der Klasse nach dem XAML-Standard (Extended Application Markup Language) zu beschreiben. In ihr wird, ähnlich dem Aufbau einer HTML-Seite mit Tags und Attributen das Layout, die Positionierungen und Eigenschaften sowie Ereignisse der beinhalteten Steuerelemente definiert, die dann in der zugehörigen (gleichnamigen).cs-datei ihre Logik erhalten. Die Abbildung 2.18 zeigt eine solche XAML-Datei und Abbildung 2.17 die durch diese erzeugte Oberfläche. In diesem Beispiel müsste nur noch die Logik in der entsprechenden.cs-datei, insbesondere die Eventhandler für die beiden Buttons implementiert werden und die Anwendung wäre einsetzbar. Dieses Modell erlaubt eine klare Trennung von Design und Logik, da Designer und Programmierer unabhängig voneinander an unterschiedlichen Dateien arbeiten können, solange sich auf eine klare Konvention, wie unter anderem die Benennung der Komponenten und ihrer Eventhandler oder einheitliche Schnittstellen, geeinigt wurde

54 Kapitel 2. Technologien 2.3. Microsoft Silverlight Silverlight und CRM 2011 Das Microsoft CRM 2011 unterstützt die Einbindung von Silverlight-Anwendungen als Erweiterungen in seine Benutzeroberfläche. Auch der Zugriff auf die im CRM enthaltenen Daten wird durch vorgefertigte Namespaces und Klassen erleichtert. So ist es beispielsweise möglich, sich für eine Silverlight-Anwendungen eine Reihe von Klassen zu generieren, die alle im System enthaltenen Entitäten repräsentieren und bereits alle Attribute mit entsprechenden Datentypen beinhalten, sowie Events bei Veränderungen von Attributswerten ermöglichen. Dennoch besteht ein grundlegender Unterschied bei der Kommunikation mit dem CRM aus Silverlight heraus. Das einbinden des SOAP-Services ist wesentlich aufwendiger und umständlicher als in einer reinen.net-anwendung und Microsoft empfiehlt dessen Verwendung ausschließlich in den Fällen, in denen die Möglichkeiten des REST-Services für die Anwendungslogik nicht ausreichen (vgl. Abschnitt 2.1.6, S. 17). Im Falle des Rest-Services führt dies dazu, dass jede Anfrage und Antwortauswertung asynchron stattfindet und dementsprechend behandelt werden muss. Dies in Verbindung mit der Tatsache, dass mehrere gleichzeitig abgesendete Anfragen zu Problemen führen können und durch den reduzierten Umfang der verfügbaren.net-bibliotheken nur eingeschränkte Synchronisationsmechanismen innerhalb der Silverlight-Anwendung zur Verfügung stehen führt zu erheblichem Mehraufwand besonders beim Schreiben von Daten in das CRM. Allgemein lassen sich jedoch durch Silverlight Oberflächen in das CRM integrieren, die von der Bedienbarkeit nahe an den Komfort von Desktop-Anwendungen gelangen und weit über die Möglichkeiten reiner Webseiten hinausgehen. Jedoch müssen diese Vorteile stets mit dem höheren Aufwand und der damit einhergehenden höheren Fehleranfälligkeit abgewogen werden

55 Kapitel 3. Projektübersicht 3 Projektübersicht In diesem Kapitel wird zunächst die Ausgangssituation der Integration des CRM in das Active Directory untersucht und die daraus entstehende Problematik dargestellt. Nachfolgend wird die Motivation für die Entwicklung einer automatisierten Integration erläutert. 3.1 Analyse der Ausgangssituation Die On-Premise-Variante des Microsoft CRM arbeitet bereits eng mit dem Active Directory zusammen: - Es können nur Benutzer im CRM angelegt werden, die einen Account im Active Directory besitzen. - Beim Anlegen eines neuen Benutzers werden einige Benutzerinformationen (unter anderem Vorname und Nachname) aus dem Active Directory ausgelesen und im CRM eingetragen. - Anmeldung im CRM erfolgt über den Active-Directory-Account. Gelöschte oder deaktivierte Benutzer können sich nicht mehr authentifizieren und das CRM somit nicht mehr verwenden. Jedoch beschränkt sich diese Integration lediglich auf das Erstellen und Authentifizieren im CRM. Eine weitergehende Automatisierung der Synchronisation wurde von Kunden, die beide Systeme verwenden, oft angefragt. Hierunter fallen insbesondere folgende Punkte: 1. Benutzerinformationen (Vorname, Nachname, Telefonnummer) werden zwar beim Anlegen eines Benutzers im CRM übertragen, danach aber nicht mehr abgeglichen

56 Kapitel 3. Projektübersicht 3.2. Motivation 2. Es gibt keine Möglichkeit, die übertragenen Informationen zu beeinflussen. Welche Informationen das CRM beim Anlegen eines Accounts aus dem Active Directory übernimmt, ist fest vorgegeben. 3. Deaktivierte oder gelöschte Benutzer können sich zwar nicht mehr anmelden, werden im CRM aber nicht automatisch deaktiviert. Dies ist besonders unter dem Gesichtspunkt problematisch, dass diese weiterhin Lizenzen verbrauchen, die ansonsten von anderen Nutzern verwendet werden könnten. 4. Die Sicherheitskonzepte des CRM müssen nach dem Anlegen eines neuen Benutzers von Hand zugewiesen werden. Es existiert keine Möglichkeit, bestimmte Einstellungen auf Basis seiner Gruppen- oder OU-Zugehörigkeit im Active Directory zu definieren, so wie dies dort über Gruppenrichtlinien möglich ist. Gerade in einem System, dass seinen Nutzen zu einem großen Teil aus der Aktualität der in ihm enthaltenen Daten zieht, bedeuten diese Punkte einen erheblichen Nachteil. Die Daten eines Kunden oder Interessenten können von den sachkundigen Mitarbeitern gepflegt werden, im Falle der Benutzer ist dies nicht unbedingt der Fall oder nur mit erheblichen Kompromissen im Sicherheitskonzept möglich. Andere Systeme, unter anderem Microsoft SharePoint, ermöglichen es den Benutzern bereits, ihre eigenen Daten im Active Directory anzupassen - oftmals eingeschränkt auf bestimmte Informationen und mit direkter Synchronisation. Dieses führt dazu, dass die Benutzerinformationen zwar im Active Directory gepflegt und aktuell gehalten werden können, im CRM aber entweder auf einem alten Stand bleiben, oder häufig manuell angepasst werden müssen. 3.2 Motivation Der Sinn eines Verzeichnisdienstes wie dem Active Directory besteht gerade darin, Informationen zentral, aktuell und gesichert zur Verfügung zu stellen. Daher stellt das Active Directory in den meisten Unternehmen die zentrale Speicherstelle für organisatorische Informationen über Benutzer dar und wird von einer Vielzahl

57 Kapitel 3. Projektübersicht 3.2. Motivation von Programmen verwendet, um Informationen abzurufen oder Zugriffsrechte zu steuern. Im Falle des CRM führt der einmalige Abgleich und die geringen Konfigurationsmöglichkeiten jedoch zu doppelter Datenhaltung, erhöhtem Administrationsaufwand und Dezentralisierung der Administration. Da die Daten und Sicherheitseinstellungen stets manuell aktualisiert werden müssen und die Administration der Benutzer im Active Directory und die Einrichtung des CRM in manchen Firmen von unterschiedlichen Personen übernommen wird, birgt dies das Risiko zeitverzögert aktualisierter Daten und Sicherheitskonzepte mit sich. Durch eine automatisierte Integration des Active Directory in das Microsoft CRM kann also eine höhere Aktualität der Daten, eine höhere Sicherheit und gleichzeitig ein geringerer Administrativer Aufwand erzielt werden. Zusätzlich dazu sinkt die Lernhürde und Fehleranfälligkeit durch Fehlkonfiguration, da das Sicherheitskonzept des CRM einmalig ausgearbeitet werden muss und danach automatisiert umgesetzt wird. Zusätzlich können durch automatisierte Nutzerdeaktivierung (ein Löschen von Benutzern im CRM ist nicht möglich) Lizenzen effektiver genutzt und somit Lizenzkosten gespart werden. Der Einsatz zusammen mit einer Software, die es Benutzern ermöglicht, ihre eigenen Informationen im Active Directory anzupassen, verringert bei einem automatisierten Datenabgleich den administrativen Aufwand zusätzlich, da diese von dort automatisiert ins CRM übernommen werden. Hierdurch können Benutzer ihre eigenen Informationen zentral und in allen System selbst aktualisieren, wobei die Daten gesichert und an einer zentralen Stelle gespeichert werden. Eine derartige Lösung bietet also zusammengefasst folgende Vorteile: 1. Aktuelle und zentrale Datenhaltung. 2. Verringerung des administrativen Aufwands. 3. Senkung der Lizenz- und Administrationskosten. 4. Erhöhung der Sicherheit durch automatisierte Sicherheitseinstellungen. 5. Pflege der eigenen Informationen im CRM durch den Nutzer, solange eine andere Anwendung diesem das Schreiben im Active Directory ermöglicht

58 Kapitel 3. Projektübersicht 3.2. Motivation

59 Kapitel 4. Das Projekt 4 Das Projekt Dieses Kapitel beinhaltet die Umsetzung der in Kapitel 3 skizzierten Software. Es beinhaltet eine Anforderungsanalyse, den Entwurf einer Architektur, um diese Anforderungen zu realisieren sowie deren Umsetzung. Das Kapitel schließt mit einigen Ergebnissen aus dem Praxiseinsatz des fertigen Produkts wie Stresstestdaten und die Tests in einer internen Umgebung sowie auf Kundensystemen. 4.1 Analyse der Anforderungen Aus der Analyse der Ausgangssituation ergeben sich folgende funktionale Anforderungen für eine automatisierte Synchronisation von Benutzern von einem Active Directory in ein Dynamics CRM: 1. Allgemeine Anforderungen a) Das Active Directory stellt die Datenbasis dar. Hier finden ausschließlich Lesezugriffe statt. b) Sicherheitseinstellungen und Attributswerte werden stets auf Basis des Active Directory gesetzt. c) Bei Veränderungen im Active Directory werden die CRM-Benutzer automatisch aktualisiert. d) Einzelne Benutzer können von der Attributssynchronisation ausgeschlossen werden. e) Das automatisierte setzen von Sicherheitseinstellungen kann für einzelne Benutzer deaktiviert werden. f) Die Veränderungen an Benutzern sowie aufgetretene Fehler werden an zentraler Stelle protokolliert

60 Kapitel 4. Das Projekt 4.1. Analyse der Anforderungen 2. Synchronisation von Benutzerattributen a) Es können alle textbasierten Attribute der Benutzer im Active Directory in Text-Felder des CRM synchronisiert werden (für eine Übersicht der Attribute siehe Anhang A, S. 103). b) Die Zuordnung, welcher Wert im Active Directory in welches Feld im CRM geschrieben wird, ist frei konfigurierbar. c) Das Manager-Attribut eines Benutzers im Active Directory kann auf das Manager-Feld im CRM abgebildet werden. Dieses Verhalten kann von der allgemeinen Synchronisation getrennt ein- und ausgeschaltet werden. 3. Automatisiertes Setzen von Sicherheitseinstellungen a) Sicherheitsrollen, Feldsicherheitsprofile und Teams können anhand der Mitgliedschaft eines Benutzer in einer Gruppe oder einer Organisationeinheit im Active Directory automatisch im CRM gesetzt werden. b) Die Unternehmenseinheit, das Gebiet und der Ort eines Benutzers im CRM, sowie sein Lizenztyp und seine -Zugriffstypen können anhand einer Mitgliedschaft in einer Gruppe oder Organisationseinheit im Active Directory automatisiert gesetzt werden. c) Diese Zuordnungen sind frei konfigurierbar und bieten die Möglichkeit, enthaltene Gruppen oder Organisationseinheiten mit einzuschließen. 4. Erstellen und Deaktivieren von Benutzern a) Es kann eine Menge von Active Directory-Gruppen und Organisationseinheiten spezifiziert werden. Die in diesen enthaltenen Benutzer stellen die Menge der Accounts dar, die das CRM verwenden dürfen. b) Sind diese bereits im CRM enthalten, wird ihr Active Directory Accountstatus (aktiviert/deaktiviert) mit dem des CRM-Accounts synchronisiert. c) Wenn einem Active Directory-Account keinem bestehenden CRM-Account, aber durch eine der Zuordnungen aus 3b eindeutig einer Unternehmenseinheit zugeordnet werden kann, wird der Benutzer im CRM angelegt und dieser Unternehmenseinheit hinzugefügt

61 Kapitel 4. Das Projekt 4.2. Entwurf der Architektur d) Wird ein Benutzer im Active Directory gelöscht, wird sein Account im CRM deaktiviert. 5. Konfiguration a) Die Einstellungen der Synchronisation werden an zentraler Stelle getätigt. b) Die Oberfläche der Konfiguration soll dabei bedienungstechnisch möglichst nah an den bestehenden Systemen Active Directory und Dynamics CRM liegen, um eine einfache Bedienbarkeit und geringe Eingewöhnungszeit zu gewährleisten. 4.2 Entwurf der Architektur Dieses Kapitel beschreibt die gewählte Architektur, um die in Abschnitt 4.1 festgelegten Anforderungen zu realisieren. Es werden die technischen Anforderungen spezifiziert, sowie die getroffenen Designentscheidungen und beteiligten Komponenten erläutert Grundlegende Entwurfsentscheidungen Um eine Synchronisation zwischen Active Directory und CRM zu realisieren wird eine Konsolenanwendung entwickelt. Diese ist in der Programmiersprache C# geschrieben und ist für alle Lese- und Schreiboperationen in CRM und Active Directory zuständig. Diese Anwendung wird im folgenden als Connector bezeichnet. Alle Veränderungen am CRM-System, die der Connector benötigt, werden in einer eigenen Lösung bereitgestellt. Diese Lösung enthält alle neuen und veränderten Entitäten, Anpassungen der Benutzeroberfläche und für diese eventuell benötigte Ressourcen. Der Connector wird von einem Windows-Dienst gestartet, welcher nicht Bestandteil der in dieser Arbeit beschriebenen Implementierung ist, sondern bereits innerhalb des Unternehmens existiert. Dieser Service übergibt dem Connector

62 Kapitel 4. Das Projekt 4.2. Entwurf der Architektur CRM-Server Domänencontroller Windows-Service startet Connector LDAP-Server Active Directory CRM-Webservice SQL-Server SQL-Datenbank Abb. 4.1: Netzwerkstruktur des Connectors beim Starten alle benötigten Informationen als Kommandozeilenparameter. Hierzu gehören: 1. Name der CRM-Organisation 2. Vollständige URL des zu verwendenden SOAP-Endpoints 3. Verbindungszeichenfolge für die SQL-Datenbank des CRM-Servers Die Zuordnung eines Active-Directory Benutzers zu einem CRM-Benutzer findet auf Grundlage der GUID des Active Directory-Benutzerobjekts statt. Da dieser Wert nur durch direkten Zugriff auf die SQL-Datenbank des CRM ermittelt werden kann, muss der Connector diesbezüglich über Lese- und Schreibzugriff verfügen. Alle Veränderungen an Benutzern im CRM werden als eigener Datensatz im CRM abgelegt. Für Fehler im Programmablauf wird sowohl ein Eintrag in der Ereignisanzeige des Computers, auf dem die Anwendung läuft, als auch ein eigener Datensatz im CRM-Server angelegt. Betreffen diese Fehler die Kommunikation mit dem CRM-Server, ist letzteres nicht möglich und es wird nur ein Eintrag in der Ereignisanzeige erstellt. Die Konfiguration des Programmablaufs wird in einer Konfigurationsoberfläche im CRM getätigt

63 Kapitel 4. Das Projekt 4.2. Entwurf der Architektur Der Connector wird auf dem CRM-Server gestartet und muss in einem Benutzerkontext laufen, welcher über Leserechte in jeder zu synchronisierenden Active- Directory Domäne, sowie Schreib- und Leseberechtigungen auf dem CRM-Server und der zugrundeliegenden SQL-Datenbank verfügt. Abbildung 4.1 veranschaulicht den Aufbau im lokalen Netzwerk. Der Windows- Service startet den Connector, welcher mit dem LDAP-Server, der CRM-Weboberfläche und der SQL-Datenbank kommuniziert, um die eigentliche Synchronisation zu realisieren. Hierbei ist es nicht zwingend notwendig, dass SQL-Server und CRM-Server von der gleichen Maschine bereitgestellt werden. Dass jedoch CRM-Server und Domänencontroller von der gleichen Maschine zur Verfügung gestellt werden kommt in der Praxis zwar vor, ist von Microsoft aber ausdrücklich nur für die Small Business Server-Installation Supported: Except for Windows Small Business Server, Microsoft Dynamics CRM is not supported when you install it on an Active Directory domain controller Konfiguration und Speicherung der Daten Bei der Entscheidung zur Ablage der Konfigurationsdaten standen drei Möglichkeiten zu Diskussion, deren Vor- und Nachteile gegeneinander abgewägt wurden. Die Tabellen 4.1 und 4.2 geben einen Überblick über die Kriterien. Da das Lesen und Schreiben der Konfiguration keine zeitkritische Anforderung darstellt, die Sicherung und Steuerung des Zugriffs jedoch entscheidend sind, werden die Einstellungen des Connectors in einer eigenen Entität im CRM abgelegt. Ausschlaggebend ist hierbei auch die Möglichkeit, für die Konfiguration bereits ohne weitere Implementierung die Weboberfläche des CRM nutzen zu können, wodurch der Wechsel in eine andere Anwendung entfällt. Für die endgültige Lösung ist die Konfiguration auf drei eigenständige und in die CRM-Oberfläche integrierte Silverlight-Anwendungen verteilt. Diese Lösung wurde gewählt, da Silverlight offiziell von Microsoft für Weboberflächen im CRM vorgesehen ist und unterstützt wird. Durch Silverlight kann eine ins CRM integrierte Oberfläche geschaffen werden, die vom Benutzer als Teil des Systems wahrgenommen 1 vgl. Microsoft MSDN: Supported CRM Configurations

64 Kapitel 4. Das Projekt 4.2. Entwurf der Architektur Lokale XML-Datei Eigene SQL-Tabelle Entität im CRM -einfach zu sichern und exportieren -leicht zu bearbeiten -selbst definiertes Modell möglich -Änderungen als Ereignisse implementierbar -vom CRM entkoppelt -umfangreiche Möglichkeiten -gesamte SQL-Syntax nutzbar -schneller Zugriff -Entwicklungstools nutzbar -Konfiguration über Weboberfläche möglich -Sicherung erfolgt automatisch -Konfiguration wird bei Kopie der DB übernommen -Berechtigungen für Zugriff durch CRM realisierbar Tab. 4.1: Vorteile verschiedener Speicherarten von Einstellungen wird und die vielfältige Möglichkeiten bietet, die Nutzbarkeit den bestehenden Systemen anzugleichen. Lokale XML-Datei Eigene SQL-Tabelle Entität im CRM -nur lokal vorhanden -Konfiguration erfordert Zugriff auf Server -Sicherung nicht automatisch -eigenes Modell notwendig -komplexe Umsetzung -eigenes SQL-Modell notwendig -Software für Im- /Export benötigt -zeitintensiver Zugriff -neue Entitätsdefinition erforderlich -Konfiguration wird bei Kopie der DB übernommen -Software für Im-/Export benötigt Tab. 4.2: Nachteile verschiedener Speicherarten von Einstellungen Darüber hinaus war es so möglich, die gesamte Implementation einheitlich in der Programmiersprache C# zu halten, die innerhalb des Unternehmens bereits verbreitet eingesetzt wird. Das Verwenden einer bekannten und einheitlichen Programmiersprache und die Tatsache, dass Silverlight bereits bei anderen Lösungen der Firma verwendet wird, dient hier besonders der Wiederverwend- und Wartbarkeit des Programmcodes

65 Kapitel 4. Das Projekt 4.2. Entwurf der Architektur Regeldesign Um Sicherheitseinstellungen Benutzern zuzuordnen, wird auf selbst definierte Regeln zurückgegriffen. Diese sind an die Gruppenrichtlinien des Active Directory angelehnt, können aber im Gegensatz zu diesen nicht nur auf eine Organisationseinheit, sondern auch auf eine Active Directory-Gruppe angewendet werden. Eine Regel besteht aus einer Bedingung und einer Reihe von Folgen. Bedingungen Die Bedingung einer Regel ist mit der Suche in einem Active Directory Verzeichnisbaum vergleichbar. Sie bestehen aus einem eindeutig spezifizierten Ausgangspunkt, entweder eine Gruppe oder eine Organisationseinheit im Active Directory und einem scope. Dieser gibt die Tiefe an, in der die Regel auf Benutzer in untergeordneten Gruppen oder Organisationseinheiten wirken soll. Im Gegensatz zu einer Active Directory Suche wird der scope hier nicht auf drei Werte beschränkt, sondern seine Einstellungsmöglichkeiten sind vom Typ des Ausgangspunktes abhängig. Sowohl für Gruppen als auch Organisationseinheiten lässt sich angeben, ob enthaltene Container des gleichen Typs mit umfasst werden sollen. Diese Option wird intern als include subcontainers bezeichnet. Im Falle von Gruppen wirkt die Regel dann entweder nur auf die Mitglieder der Gruppe selbst oder auch auf alle in Untergruppen enthaltene Accounts. Ist der Ausgangspunkt der Regel eine Organisationseinheit, steuert diese Option, ob auch Benutzer in untergeordneten Organisationseinheiten betroffen sein sollen (siehe Abbildung 4.2). Für Regeln, die sich auf eine Organisationseinheit beziehen, lässt sich zusätzlich angeben, ob auch enthaltene Gruppen - jeweils mit oder ohne Untergruppen - mit eingeschlossen werden sollen. Je nachdem, ob auch untergeordnete Organisationseinheiten umfasst werden, werden auch in diesen enthaltene Gruppen behandelt. Dieses Verhalten wird intern über eine dreiwertige Option namens recursionmode, die folgende Werte annehmen kann: recursionmode = 0 - enthaltene Gruppen werden ignoriert. recursionmode = 1 - nur direkt enthaltene Gruppen. recursionmode = 2 - enthaltene Gruppen und ihre Untergruppen

66 Kapitel 4. Das Projekt 4.2. Entwurf der Architektur include subcontainers = false Gruppe Gruppe include subcontainers = true Organisationseinheit include subcontainers = false, recursionmode = 0 include subcontainers = true, recursionmode = 0 Organisationseinheit Gruppe Organisationseinheit (a) Gruppen (b) Organisationseinheiten Abb. 4.2: include subcontainers - Regeloption Das genaue Verhalten dieser Option ist in Abbildung 4.3 dargestellt. Bezieht sich die Bedingung auf eine Active Directory-Gruppe wird dieser Wert ignoriert. recursionmode = 1, include subcontainers = false recursionmode = 2, include subcontainers = false Organisationseinheit Gruppe Gruppe recursionmode = 1, include subcontainers = true recursionmode = 2, include subcontainers = true Organisationseinheit Gruppe Gruppe Abb. 4.3: recursionmode - Option für Bedingungen Zusammengefasst besteht die Bedingung einer Regel aus einem Active Directory Container (Gruppe oder Organisationseinheit) und einem scope. Sie definieren zusammen die Menge der Benutzer im Active Directory, die von der Regel betroffen sind

67 Kapitel 4. Das Projekt 4.2. Entwurf der Architektur Folgen Die Folgen einer Regel bestimmen, welche Sicherheitseinstellungen für die von der Bedingung umfassten Benutzer gelten sollen. Hierbei wird zwischen expliziten und kumulativen Folgen unterschieden. Kumulative Folgen umfassen alle Sicherheitseinstellungen, die auf Benutzer kumulativ angewendet werden können. Ein Benutzer kann in alle Teams aufgenommen werden, die für ihn durch Regeln spezifiziert sind, daher ist diese Folge kumulativ. Explizite Folgen umfassen alle Sicherheitseinstellungen, die für Benutzer lediglich explizit festgelegt werden können. Hierunter fällt unter anderem die Unternehmenseinheit im CRM, da ein Benutzer lediglich Mitglied einer einzigen Unternehmenseinheit sein kann. Eine Übersicht über alle expliziten und kumulativen Folgen einer Regel findet sich in Tabelle 4.3. Eine besondere explizite Folge einer Regel ist die Option activate User. Ein Benutzer im CRM wird nur dann automatisiert aktiviert oder angelegt, wenn auf ihn mindestens eine Regel zutrifft, bei der diese Option aktiviert ist. Die Bedingungen aller Regeln mit dieser Option ergeben als Summe die Bedingungen für die Benutzer, die das CRM verwenden können. Treffen für einen Benutzer die Bedingungen mehrerer Regeln zu, die unterschiedliche Werte für eine explizite Folge festlegen, so muss entschieden werden, welcher Wert für den Benutzer gesetzt wird. Um dieses Problem zu lösen, besitzen alle Regeln eine Priorität. Diese Priorität wird durch eine ganze Zahl repräsentiert, wobei jeder Prioritätswert innerhalb eines CRM einzigartig sein muss. Ein kleinerer Prioritätswert stellt hierbei eine größere Priorität dar. Daher besitzt die Regel mit der Priorität 0 Vorrang vor allen anderen Regeln. Ein erläuterndes Beispiel für eine konkrete Regel ist im Abschnitt (S. 87) Explizite Folgen Unternehmenseinheit Zugriffsmodus Zugriffsmodus ausgehend Zugriffsmodus eingehend Vertriebsgebiet Ort Kumulative Folgen Sicherheitsrollen Teams Feldsicherheitsprofile Tab. 4.3: Explizite und kumulative Folgen

68 Kapitel 4. Das Projekt 4.2. Entwurf der Architektur zusammen mit einer Abbildung der grafischen Benutzeroberfläche zum Anlegen von Regeln zu finden Konzept der Attributszuordnungen Zur automatisierten Synchronisation von Attributen der Benutzer wird ein Mapping verwendet. Dieses ordnet ein Attribut eines Benutzers im Active Directory genau einem Benutzerattribut im CRM zu. Hierzu wurden zwei Typen definiert: das Active Directory Attribut und das CRM Benutzer Attribut. Diese Typen finden sich sowohl im Quellcode als Klassen als auch im CRM in Form von Entitäten wieder. CRMUserAttribute 0..* Name : string +Description : string ADUserAttribute +Name : string +Description : string +MappedTo : CRMUserAttribute Abb. 4.4: Schematische Darstellung der Attributszuordnung Abbildung 4.4 verdeutlicht diese Verknüpfung. Jede Attributsdarstellung verfügt über ihren Namen, der den Namen des Attributs im CRM oder Active Directory darstellt, und eine Description, die eine lesbare Beschreibung dessen enthält, was der Wert des Attributs im jeweiligen System darstellt. Es kann weiterhin ein CRM Benutzer Attribut an ein Active Directory Benutzer Attribut gebunden werden. Im CRM wird dies über eine 1:n-Relation umgesetzt. Innerhalb des Quellcodes verfügt jedes Active Directory Attribut über eine Liste von CRM Benutzer Attributen, auf die es abgebildet werden soll. Eine Abbildung mehrerer Werte im Active Directory auf das gleiche Feld im CRM ist nicht möglich. Jedoch können mehrere Felder im CRM mit dem gleichen Attribut verknüpft und so mit dem gleichen Inhalt gefüllt werden. Die Summe aller dieser Zuordnungen stellt das gesamte Mapping dar. Im Anhang (A, S. 103ff) findet sich eine Auswahl von Attributen und ihrem Inhalt. Die Attribute, die eindeutig im anderen System zugeordnet werden können,

69 Kapitel 4. Das Projekt 4.2. Entwurf der Architektur stellen die Standard-Attributszuordnung des Connectors dar. Diese Zuordnung wird beim Programmstart geladen, wenn sich im System keine Zuordnung findet, und kann auf Nutzerwunsch jederzeit wiederhergestellt werden. Alle Attribute, die über das Mapping verbunden werden, werden vom Connector als reine Zeichenketten aufgefasst. Es findet weder Analyse noch Interpretation statt, sondern es werden lediglich Textfelder mit als Text interpretierbaren Inhalten gefüllt. Enthält ein Feld mehrere Werte in Form einer Liste, werden diese als eine einzelne, kommaseparierte Zeichenkette in das zugeordnete Feld geschrieben. Ein Ausnahmefall stellt der Manager eines Benutzers dar, da dieses Attribut im Active Directory den Verweis auf einen anderen Benutzer-Account im distinguishedname- Format enthält. Aus diesem Grund wird diese Zuweisung nicht über das Standard- Mapping geregelt, sondern durch eine eigene Logik innerhalb des Connectors. Die Synchronisation dieses Feldes kann von der Attributssynchronisation getrennt einoder ausgeschaltet werden. Ist dieses Feature aktiviert, wird der Wert des Manager -Attributes des Active Directory Benutzers ausgelesen, der Account des eingetragenen Managers bestimmt und der korrespondierende Account im CRM als Manager gesetzt. Ist der Account des Managers im CRM nicht vorhanden, wird er deaktiviert angelegt, um keine Lizenzen zu verbrauchen. Ist das Attribut im Active Directory mit keinem Wert versehen, im CRM aber ein Manager gesetzt, wird die Verknüpfung aufgehoben. Ein weiterer Sonderfall ist der Anmeldename des Benutzers. Im Active Directory existiert für Benutzer ein Feld mit dem Namen userprincipalname welches im Normalfall den Anmeldenamen des Benutzers in dem einer -Adresse ähnlichen Format enthält. Dieses ist aber kein Pflichtattribut und kann daher leer sein, weshalb der Anmeldename eines Benutzers nicht über eine Attributszuordnung synchronisiert werden kann. Ist der userprincipalname ohne Wert, muss der Accountname aus dem Attribut samaccountname gelesen und um -Zeichen sowie den Domänenanteil des Distinguishedname erweitert werden. Der Anmeldename des Benutzers aus Abbildung 2.9 (S. 30) beispielsweise admin@firma und sein Distinghuishedname: cn=admin,ou=administratoren,ou=benutzer,dc=firma,dc=de. Ist der userprincipalname gesetzt, enthält er admin@firma und dieser Wert kann einfach übernommen werden. Ist er jedoch leer, muss der samaccountname,

70 Kapitel 4. Das Projekt 4.2. Entwurf der Architektur welcher den Wer admin enthält ausgelesen und mit dem ersten dc= -Anteil des Distinguishedname und -Zeichen ergänzt werden, wodurch wiederum admin@firma entsteht und mit dem Wert im CRM verglichen werden kann. Da diese Logik nicht in das Konzept der Attributszuordnungen passt, ist die Synchronisation des Anmeldenamens eine globale Option, die aktiviert oder deaktiviert werden kann, um die Synchronisation dieses Feldes ein- oder auszuschalten. Seine Synchronisation bietet zwar keine Vorteile bei der Anmeldung - diese läuft intern über die SID, die sich nicht verändert und funktioniert auch nach Veränderungen des Accountnamens - jedoch wird im CRM weiterhin der alte Accountname angezeigt, was mitunter zu Problemen oder Irritationen führen kann Design neuer Entitäten für das CRM Die Lösung, welche alle benötigten Änderungen am CRM beinhaltet, umfasst unter anderem alle Benötigten neuen Entitäten. Um das Konzept der Regeln umzusetzen und diese zugleich leicht anpassbar zu gestalten, wurde eine neue Entität zur Darstellung dieser Regeln designed. Ebenso sind Entitäten für Logeinträge und die Attributszuordnungen enthalten und eine weitere neue Entität, um die Gruppen und Organisationseinheiten des Active Directory im CRM abzubilden. Das CRM schreibt für zusätzlich angelegte Felder und Entitäten ein Präfix vor, um diese eindeutig als nicht zum Lieferumfang gehörig zu kennzeichnen. Dieses besteht aus genau drei Buchstaben und soll Rückschluss auf Projekt und/oder Firma geben. Daher sind im folgenden alle Felder mit dem Präfix con_ versehen, um den Bezug zu der Firma connectiv! zu geben. Alle Entitäten erhalten ebenfalls dieses Präfix und einen mit ad4mscrm_ beginnenden Namen, um die Zuordnung zu dem Projekt zu ermöglichen. Die Namen von im Rahmen des Projekts definierten Entitäten beginnen daher stets mit con_ad4mscrm_. Die Entitätsdefinitionen werden im folgenden dargestellt und erläutert. Entität für Regeln Diese Entität definiert den Datensatz einer Regel. Das Diagramm 4.5 verdeutlicht die Definition. Ein Datensatz vom Typ dieser Entität kann Beziehungen zu den meisten der Folgen einer Regel (Sicherheitsrolle, Team, Unternehmenseinheit etc.)

71 Kapitel 4. Das Projekt 4.2. Entwurf der Architektur PK FK1 FK2 FK3 FK4 FK5 FK6 con_ad4crm_securityrule con_ad4crm_securityruleid Name con_priority con_activateuser con_accessmode con_recursiv con_recursionmode con_incomingmailtype con_outgoingmailtype RoleId FieldsecurityProfileId LocationId BusinessunitId TerritoryId TeamId con_ad4mscrm_activedirectorycontainerid Team Role PK TeamId PK RoleId Name Name Territory PK TerritoryId Location Name PK LocationId Businessunit Name PK BusinessunitId Name con_ad4mscrm_activedirectorycontainer PK con_ad4mscrm_activedirectorycontainerid Name Abb. 4.5: Entitätsdefinition: Sicherheitsregeln beinhalten und enthält Felder um alle anderen Folgen einer Regel setzen zu können. Hierzu gehören Optionsfelder, in denen ein -Versandmodus spezifiziert oder die Option zum aktivieren der betroffenen Benutzer gesetzt werden kann. Problematisch hierbei ist lediglich, dass das CRM es nicht vorsieht, Beziehungen zu Feldsicherheitsprofilen herzustellen, weshalb das Feld zum Festlegen des Feldsicherheitsprofils durch ein Textfeld mit der GUID des gewünschten Profils realisiert wurde. Auch die einzelnen Rekursionsmodi zum umfassen von untergeordneten (con_recursiv) und enthaltenen (con_recursionmode) Containern werden in dem Datensatz gesetzt. Jede Regel verfügt über eine eindeutige GUID und Priorität und kann darüber hinaus zur Identifikation mit einem Namen versehen werden. Diese Realisation des Regelkonzeptes sorgt dafür, dass die Daten einer Regel stets gebündelt an zentraler Stelle und durch die Sicherheitseinstellungen des CRM vor unbefugtem Zugriff geschützt abgelegt werden. Ein Nebeneffekt ist es, dass im CRM bereits über die bestehende Weboberfläche die Möglichkeit besteht, die Regeln anzuzeigen und zu

72 Kapitel 4. Das Projekt 4.2. Entwurf der Architektur verändern. Abbildung 4.6 veranschaulicht dies anhand einer Regel, bei der alle Optionen mit eine Wert versehen wurden. Abb. 4.6: Regel in der CRM-Weboberfläche Obwohl diese Oberfläche bereits ein komfortables Werkzeug zum Anlegen und Manipulieren von Regeln darstellt, ist sie bei einer großen Anzahl von Regeln unübersichtlich. Außerdem ist die Auswahl des betroffenen Active-Directory Containers aus einer Liste unhandlich und nicht intuitiv. Dies ist mit dem Vorgang vergleichbar, in einem Verzeichnisbaum eines Datenträgers eine Datei auswählen zu müssen und die Auswahl dabei nicht über den vertrauten Verzeichnisbaum, sondern über eine Liste aller im System enthaltenen Dateien tätigen zu müssen. Hierbei ist sowohl die Anzahl der Container problematisch, welche auch bei kleinen Systemen schnell über 500 betragen kann, als auch die Tatsache, dass mehrere Container in unterschiedlichen Zweigen den gleichen Namen besitzen können. Dies ist der Entscheidende Grund dafür, zur Bearbeitung von Regeln nicht auf die standard-weboberfläche des CRM zurückzugreifen, sondern eine Silverlight- Benutzeroberfläche bereitzustellen, die dem Benutzer die Möglichkeit bietet, den Container aus dem gewohnten Verzeichnisbaum auszuwählen. Entität für Active Directory Container Um eine komfortablere und sichere Konfiguration der Regeln zu ermöglichen, müssen alle im Active Directory enthaltenen Container, die als Bedingung für eine Regel in Frage kommen, in das CRM geschrieben werden. Hierzu wird eine neue Entität

73 Kapitel 4. Das Projekt 4.2. Entwurf der Architektur angelegt, welche die Daten der einzelnen Container repräsentiert. Abbildung 4.7 zeigt den Aufbau dieser Entität. con_ad4mscrm_activedirectorycontainer PK FK1 FK2 FK3 con_ad4mscrm_activedirectorycontainerid Name con_ad_guid con_adname con_ad_domainguid con_ad_parentguid con_ad_containertype con_parent con_ad4mscrm_memberids con_ad4crm_securityruleid con_ad4crm_securityrule1 PK con_ad4crm_securityruleid Name Abb. 4.7: Entitätsdefinition: Active Directory Container Diese speichert folgende Informationen des von ihr repräsentierten Active Directory Containers, die vom Connector bei Veränderungen aktualisiert werden: Durch den Inhalt des Feldes con_parent kann der Active-Directory-Verzeichnisbaum im CRM rekonstruiert werden. Dadurch besteht die Möglichkeit, diesen innerhalb einer Silverlight-Anwendung dem Benutzer anzuzeigen und damit die Regelkonfiguration an diese bekannte Struktur anzulehnen. Entitäten für Logeinträge und Attributszuordnungen Abschliessend werden drei weitere Entitäten definiert, die für die Attributszuordnung und das Logging verwendet werden. Abbildung 4.8 stellt die beiden Entitäten zur Repräsentation von Attributen im Active Directory und dem CRM dar

74 Kapitel 4. Das Projekt 4.2. Entwurf der Architektur Feldname Name con_ad_guid con_adname con_ad_domainguid con_ad_parentguid con_ad_containertype con_parent con_ad4mscrm_memberids con_ad4crm_securityruleid Wert des Containers Common-Name Object-Guid Distinguishedname die GUID der Domäne, die den Container enthält GUID der übergeordneten Organisationseinheit (im Falle des rootdse leer) Optionsfeld, dessen Wert angibt, ob es sich um eine Gruppe oder eine Organisationseinheit handelt Enthält Verweis auf die übergeordnete Organisationseinheit Liste mit allen enthaltenen Containern (Gruppen und Organisationseinheiten) Liste aller Regeln, die diesen Container direkt als Bedingung enthalten - Regeln, die diesen Container über rekursion mit einschliessen, sind hier nicht enthalten Tab. 4.4: Felder der activedirectorycontainer-entität PK con_ad4mscrm_activedirectoryattribute con_ad4mscrm_activedirectoryattributeid Name con_description con_ismultiline PK FK1 con_ad4mscrm_systemuserattribute con_ad4mscrm_systemuserattributeid Name con_description con_ismultiline con_ad4mscrm_activedirectoryattributeid Abb. 4.8: Entitätsdefinition: Attribute Dabei wird der interne Bezeichner des Attributs im Namen des Datensatzes abgelegt, die Description enthält eine Beschreibung des Inhalts. Die zweiwertige Option ismultiline ist für eine spätere Erweiterung vorgesehen. Diese soll der besseren grafischen Aufbereitung von Attributen, die Listen beinhalten, dienen. Aufgrund der geringen Anzahl und dem seltenen Einsatz dieser Attribute wurde aber bisher auf eine Verarbeitung dieses Attributs verzichtet. Wird im CRM eine Beziehung zwischen zwei Datensätzen dieser Entitäten hergestellt, stellt dieses eine Verknüpfung der beiden Attribute vom Active Directory zum CRM dar und der Connector synchronisiert die Werte des Active-Directory- Attributs mit denen im CRM

75 Kapitel 4. Das Projekt 4.3. Connector Die in Abbildung 4.9 dargestellte Entität dient zur besseren Aufbereitung von Logeinträgen. PK FK1 con_ad4mscrm_logentry con_ad4mscrm_logentryid con_correlationid con_info con_logtype con_message systemuserid PK Systemuser systemuserid Name Abb. 4.9: Entitätsdefinition: Logeinträge Alle Veränderungen an Benutzern oder aufgetretene Fehler werden in einen Datensatz dieser Entität gespeichert. Hierdurch entsteht ein lesbares Log, auf das sich Filter anwenden lassen. Die Correlation-ID stellt hierbei einen Synchronisationsdurchlauf dar - bei jedem neuen Durchlauf wird eine neue GUID generiert, die diesen kennzeichnet. Hierdurch lassen sich Logmeldungen gruppieren und der Ablauf eines Synchronisationsvorganges besser reproduzieren. Wird eine Veränderung an einem Benutzer vorgenommen, so wird zusätzlich auf den betroffenen Nutzer verwiesen. Da diese Verweise als Liste in den Details des Benutzers zu finden sind, entsteht so ein aussagekräftiges Changelog dieses Benutzers. Der Datensatz an sich enthält eine Typen-Klassifizierung (change, info, error), eine genauere Beschreibung, die in vordefinierte Kategorien (Benutzer angelegt, deaktiviert, Attribut verändert, Manager gesetzt etc.) unterteilt ist, sowie ein freies Textfeld für exakte Informationen. Diese Entität ermöglicht mithilfe von Suchfiltern das Erstellen von präzisen Berichten zur Übersicht oder der Fehlersuche. 4.3 Connector Der Connector stellt das zentrale Element der Entwicklung dar. Er übernimmt das Auslesen aller benötigter Daten sowie die eigentliche Synchronisation. Aufbau und Funktionsweise des Connectors sind Inhalt dieses Abschnitts Funktionsweise Der Ablauf des Connectors ist in mehrere Einzelschritte unterteilbar. Der Ablauf dieser Schritte wird in Abbildung 4.10 abgebildet

76 Kapitel 4. Das Projekt 4.3. Connector Kommandozeilenargumente auswerten Domänenanalyse CRM-Verbindung initialisieren Sleep() Konfiguration aus dem CRM laden User aktualisieren und Veränderungen ins CRM schreiben Lizenz überprüfen Regeln laden/aktualisieren und auf User anwenden Attributemapping laden/aktualisieren ADContainer-Informationen im CRM aktualisieren Daten aus allen Domänen laden/aktualisieren Daten aus dem CRM laden/aktualisieren Abb. 4.10: Programmablauf des Connectors Der Inhalt der einzelnen Abschnitte ist wie folgt festgelegt: Kommandozeilenargumente auswerten: Hier werden die übergebenen Parameter ausgewertet, welche festlegen, mit welcher CRM-Organisation auf welchem CRM-Server der Connector sich verbinden soll. Darüber hinaus wird die Verbindungszeichenfolge für die dieser Organisation zugrundeliegende SQL- Datenbank gespeichert. Domänenanalyse: In diesem Schritt bestimmt der Connector alle Domänen, auf die lesender Zugriff möglich ist. CRM-Verbindung initialisieren: Aufbau einer Verbindung zum CRM-Server und

77 Kapitel 4. Das Projekt 4.3. Connector der spezifizierten Organisation. Konfiguration aus dem CRM laden: Laden der Konfigurationseinstellungen aus dem CRM, da diese für die Synchronisation benötigt werden. Lizenz überprüfen: Überprüfen, ob eine gültige Lizenz vorliegt und welche Features der Synchronisation von dieser unterstützt werden. Nicht unterstützte Funktionen werden entsprechend im weiteren Verlauf übersprungen. Hierzu gehört insbesondere die Umsetzung des Regelwerks. Außerdem wird die Anzahl der Benutzer im CRM mit der von der Lizenz unterstützten abgeglichen und bei Überschreitung mit einer Fehlermeldung abgebrochen. Attributemapping laden/aktualisieren: Laden der Attributszuordnung aus dem CRM, da die Menge der Attribute darüber entscheidet, welche Eigenschaften der Objekte aus Active Directory und CRM ausgelesen werden. Nicht zugeordnete Werte werden bei den Lesezugriffen in beiden Systeme von der Übertragung ausgeschlossen, um die Bandbreitennutzung zu optimieren. Daten aus allen Domänen laden/aktualisieren: Abrufen der benötigten Daten aus allen in der Domänenanalyse als lesbar identifizierten Active Directory- Domänen. Liegen bereits Daten aus dieser Domäne im Speicher vor, werden diese aktualisiert. Daten aus dem CRM laden/aktualisieren: Zugriff auf das CRM und laden aller benötigten Datensätze. Bei bereits vorhandenen Datensätzen Abgleich der Inhalte und eventuelle Aktualisierung. ADContainer-Informationen im CRM aktualisieren: Eventuell aufgetretene Veränderungen an den Active Directory Containern ins CRM schreiben. Hierunter fallen das Umbenennen, Verschieben oder Löschen von bestehenden Containern sowie das Erstellen von neuen. Regeln laden/aktualisieren und auf User anwenden: Laden der Regeln aus dem CRM und Feststellung der von den Regeln betroffenen Benutzer. Jeder Benutzer verfügt über eine Auflistung, von welchen Regeln er betroffen ist

78 Kapitel 4. Das Projekt 4.3. Connector User aktualisieren und Veränderungen ins CRM schreiben: Abgleichen des Ist- Standes der einzelnen Benutzer mit dem Soll-Zustand, der sich aus der Summe aller Attributszuordnungen und ihn betreffenden Regeln ergibt. Bei Abweichungen wird der Benutzer im CRM auf den Soll-Zustand aktualisiert Änderungen im Active Directory verfolgen Um die Veränderungen im Active Directory nachzuverfolgen, verwendet der Connector für jeden Datentyp eine eigene Abfrage mit eigenem DirSync-Cookie (vgl , S. 38). Diese Herangehensweise wurde gewählt, da zum einen eine große Menge an Objekten abgerufen wird und dies eine eventbasierte Synchronisation aufwendig machen würde und zum anderen der DirSync-Cookie eine Auswahl der zu ladenden Attribute ermöglicht, wodurch die benötigte Bandbreite reduziert wird. Zudem verfügt insbesondere ein Benutzer-Objekt im Active Directory über mehrere Attribute, die sich häufig verändern und deren Veränderung bei einer eventbasierten Abfrage zu einer großen Anzahl an Abgleichen führen würde, die jedoch keine Aktualisierung der Daten nach sich zieht. Hierzu gehören Attribute, die beispielsweise den letzten Anmeldezeitpunkt oder die Anzahl der Fehlversuche der Passworteingabe. Aus diesem Grund enthält der erste Ladevorgang aus dem Active Directory alle enthaltenen Objekte, welche zwischengespeichert werden. Darauffolgende Abfragen haben lediglich die seit der letzten Anfrage veränderten Objekte als Ergebnis, wodurch sich die benötigte Zeit für den Abgleich erheblich reduziert. Daraus folgt jedoch, dass der erste Zugriff auf das Active Directory laufzeittechnisch mit erheblich höheren Kosten verbunden ist, als alle darauffolgenden, da nicht nur alle Objekte verarbeitet, sondern auch die Struktur des Active Directory über die distinghuishedname-attributwerte reproduziert werden muss. Über diesen Weg benötigt der Connector für die erste Synchronisation nach Programmstart (den Initial-sync) wesentlich mehr Zeit als für alle darauffolgenden, jedoch können diese erheblich schneller und kostengünstiger behandelt werden als dies bei einer erneuten Abfrage des gesamten Inhaltes oder einer eventbasierten Lösung der Fall wäre. Zwar werden Änderungen bei diesem Ansatz nicht unmittelbar im CRM umgesetzt, jedoch war dies auch keine Anforderung an die Synchronisation. Durch die

79 Kapitel 4. Das Projekt 4.3. Connector derart beschleunigten Folgeabgleiche lässt sich zudem das Intervall zwischen zwei Vergleichen derart gering wählen, dass ein gefühltes Echtzeitverhalten erreicht wird. Weitere Faktoren zum Laufzeitverhalten und genauere Betrachtungen finden sich im Abschnitt 4.5 Stresstests (S. 90) Active Directory und Vertrauensstellungen Für eine automatisierte Synchronisation einer Active Directory Domäne ist zwingenderweise ein Lesezugriff auf diese Domäne notwendig. Diese Anforderung ist trivial, da ohne Lesezugriff weder die Objekte noch ihre aktuelle Konfiguration zur Verfügung steht und die Synchronisation somit keine Grundlage hätte. Stets die entsprechenden Berechtigungen für den Account, in dessen Kontext der Connector ausgeführt wird, vorausgesetzt ist der Lesezugriff in den folgenden Domänen möglich: 1. Der eigenen Domäne. 2. Jeder Domäne, die mit der eigenen über eine bidirektionale Vertrauensstellung verbunden ist. 3. Jeder Domäne, die mit der eigenen über eine unidirektionale Vertrauensstellung verbunden ist, die von der eigenen Domäne aus gesehen als Inbound eingestuft wird. Diese Vertrauensstellungen können über die Zugehörigkeit zum gleichen Domain- Tree, Forest oder eine Strukturvertrauensstellung zu einem anderen Forest stammen oder direkt zwischen den beteiligten Domänen bestehen. Für den Zugriff ist dies irrelevant. Diese Bedingungen sind in Abbildung 4.11 dargestellt. Die Besonderheit liegt nun darin, dass Benutzer aus einer Domäne mit unidirektionaler (Outbound)- Vertrauensstellung (im Beispiel: Domäne2 ) im CRM angelegt werden können, da die CRM-Domäne ihrer Ursprungs-Domäne vertraut. Diese Benutzer können jedoch nicht synchronisiert werden, da der Connector nicht berechtigt ist, ihre Informationen im Active Directory auszulesen. Im Gegensatz dazu ermöglicht eine unidirektionale (Inbound)-Vertrauensstellung (im Beispiel: Domäne3 ) zwar das auslesen der Benutzer, diese können jedoch nicht

80 Kapitel 4. Das Projekt 4.3. Connector Legende: können automatisiert, synchronisiert werden können nicht, synchronisiert werden Bidirectional Trust können eingeschränkt, synchronisiert werden Connector Domain-Controller Benutzer Gruppe Domäne1 Outbound-Trust Domain-Controller Domain-Controller CRM-Server SQL-Server Gruppe Benutzer CRM-Domäne Inbound-Trust Domain-Controller Benutzer Gruppe Domäne3 Benutzer Gruppe Domäne2 Abb. 4.11: Synchronisation von Domänen über Vertrauensstellungen im CRM angelegt werden, da ihrer Domäne nicht vertraut wird. Es können jedoch in dieser Domäne durchaus (Local)-Gruppen existieren, die Benutzer enthalten, die auch im CRM existieren. Der Connector akzeptiert daher alle Container aus einer solchen Domäne als Bedingung für Regeln, jedoch werden bei der Auswertung lediglich Benutzer berücksichtigt, die auch im CRM angelegt sind oder angelegt werden können. Die eigene Domäne sowie bidirektional vertraute Domänen stellen hierbei keine Probleme dar. Die entsprechenden Berechtigungen für den Account vorausgesetzt können dort alle Informationen gelesen sowie die Benutzer im CRM angelegt werden. Der Connector führt nach dem Programmstart eine Domänenanalyse aus, bei der die Vertrauensstellungen der eigenen Domäne nach weiteren lesbaren Domänen durchsucht werden. Diese Domänen werden weiterhin dahingehend überprüft, ob sie mindestens einen Domänencontroller enthalten, der auf Anfragen auf Port 389 (der standard LDAP-Port) reagiert sowie eine LDAP-Anfrage beantwortet. Enthält eine Domäne mehrere Domänencontroller, so werden bei dem ersten Zugriff auf das Active Directory an jeden Domänencontroller vier ICMP-Pakete gesendet und ihre durchschnittliche Antwortzeit berechnet. Für den weiteren Zugriff wird der Domänencontroller mit der geringsten durchschnittlichen Antwortzeit gewählt und steht damit für den gesamten weiteren Programmablauf fest

81 Kapitel 4. Das Projekt 4.3. Connector Laden der Active Directory Inhalte Der Connector verfügt zur Laufzeit über eine Liste der aktuell synchronisierten Domänen. Jede Domäne enthält dabei drei unterschiedliche DirectorySearcher die für die Suche nach den benötigten Objekten: User, Container und ForeignSecurityPrincipals benötigt werden. Jedes dieser Objekte verfügt über einen eigenen DirSync-Cookie und einen speziellen Filter, der dafür sorgt, dass als Antwort lediglich Objekte des gesuchten Typs zurückgeliefert werden. Gegen eine Abfrage mit nur einer einzigen Suche wurde aus mehreren Gründen entschieden. Zum einen hätten die Suchergebnisse im Quellcode nach ihren Typen sortiert werden müssen, da alle Ergebnisse einer LDAP-Suche in C# vom Typ DirectoryEntry sind - unabhängig davon, um was für ein Objekt es sich im Active Directory handelt. Zum anderen bieten einzelne Suchanfragen die Möglichkeit, sich speziell auf die Abfrage nach den Attributen zu beschränken, die für die Programmlogik von Bedeutung sind. Eine Allgemeine Abfrage hätte das Problem, dass manche dieser Attribute nicht in allen Objekten spezifiziert sind oder würde zumindest zu einer erheblich größeren Menge an übertragenen Daten führen. Die in der Ergebnissuche enthaltenen DirectoryEntries werden in ihrem Typ entsprechenden Wrapper-Klassen im Speicher abgelegt. Die Struktur dieser Klassen ist in Abbildung 4.12 dargestellt. Die Suchergebnisse enthalten ein Dictionary, welches die mit Werten versehenen Attribute und deren Inhalte enthält. Dieses wird in der allgemeinen ADObject-Klasse in den Properties abgelegt. Alle hiervon abgeleiteten Klassen enthalten in dieser Struktur die Attribute und Inhalte des Active-Directory-Objektes, auf welches sie verweisen. Dies ermöglicht einen schnellen Abgleich bei Veränderungen des zugrundeliegenden Objektes, da lediglich die Inhalte der beiden Attribut-Dictionaries miteinander verglichen werden müssen. Die Auswertung von Attributswerten zur Laufzeit bezieht sich stets auf den Inhalt dieses Dictionaries und dadurch automatisch auf den aktuellen Stand des Objekts im Active Directory. Oftmals werden diese Werte jedoch durch Eigenschaften gekapselt, die auf Existenz prüfen und gegebenenfalls eine Typumwandlung vornehmen. Wird Beispielsweise im Code der Status eines Benutzers abgefragt, wird intern der Wert des User Access Control (vgl. 2.12, S. 36) auf den Wert des ACCOUNTDISABLE-Bits überprüft und das Ergebnis als Boolean zurück

82 Kapitel 4. Das Projekt 4.3. Connector Abb. 4.12: Klassen für Active Directory-Objekte gegeben. Dies hat den Vorteil, dass bei Veränderungen im UAC-Bytefeld keine interne Variable für den Status verändert werden muss, sondern jeder Zugriff auf die Eigenschaft des Objekts stets den aktuellen Zustand liefert. Da die Domänen und die enthaltenen Objekte innerhalb des Projekts zur Laufzeit genau einmal vorliegen und global verfügbar sein sollen, wurde hier zur Speicherung auf das Erzeugungsmuster des Singleton 2 zurückgegriffen. Innerhalb des Projektes existiert eine Klasse Data, die global und eindeutig Datenobjekte zur Verfügung stellt. Hierzu gehören: 1. alle synchronisierten Domänen 2. die aktuelle Attributszuordnung 3. die Liste aller Container 4. das synchronisierte CRM 2 Gamma, E. et al.: Entwurfsmuster: Elemente wiederverwendbarer objektorientierter Software. Addison Wesley Verlag, 2004, Programmer s Choice, ISBN , S.157ff

83 Kapitel 4. Das Projekt 4.3. Connector 5. der aktuelle Lizenztyp 6. die globalen Einstellungen für den Connector 7. die aktuell geltenden Regeln 8. eine Liste aller Benutzer Abbildung 4.13 veranschaulicht das Konzept. Abb. 4.13: Dataholder-Singleton Data Der erste Zugriff auf eine Eigenschaft dieser Klasse erzeugt eine Instanz, die gespeichert und bei jedem darauffolgenden Zugriff verwendet wird. Die Eigenschaften sind zwar statisch, verweisen aber intern stets auf die einzige Instanz der Klasse. Dadurch ist sichergestellt, dass alle anderen Objekte stets auf den gleichen Daten der gleichen Instanz operieren. Hiermit wird der globale Zugriff auf diese Daten vereinfacht und sichergestellt, dass alle Objekte stets auf den gleichen Grundlagen arbeiten und keine inkonsistenten Daten entstehen oder Werte an mehreren Stellen aktualisiert werden müssen Laden aller benötigten Datensätze des CRM Der Connector lädt in mehren Schritten alle benötigen Datensätze aus dem zu synchronisierenden CRM. Hierzu wird der SOAP-Service verwendet, da der Connector

84 Kapitel 4. Das Projekt 4.3. Connector unter anderem die Unternehmenseinheit oder den Manager von Benutzern verändern muss, was mit dem REST-Endpoint nicht möglich ist. Die geladenen Daten werden in eigene Wrapper-Klassen gewandelt. Hierzu wurde die Basis-Klasse CRMEntity implementiert, welche die im CRM-SDK enthaltene Entity -Klasse um einen einfacheren Zugriff auf allgemein vorhandene Attribute (wie die CRM-GUID oder den Namen des Datensatzes) erweitert. Der Connector besitzt für alle Entitätstypen eigene Klassen, welche diese Basisklasse um spezielle, vom Connector benötigte Methoden und Eigenschaften erweitern. Dieser Aufbau wird in Abbildung 4.14 abgebildet. Jede Klasse enthält dabei eine Auflistung AttributesToLoad der vom Abb. 4.14: Klassen für Entitäten Connector benötigten Felder, so dass der Ladevorgang der einzelnen Datensätze auf die benötigten Daten beschränkt werden kann. Durch diese Vererbungshierarchie können Ladevorgänge durch eine generische Methode realisiert werden. Diese liefert als Ergebnis ein Dictionary mit allen im CRM enthaltenen Datensätzen dieses Typs, wobei ihre CRM-GUID den Schlüsselwert des Dictionary darstellt. Die GUID des Datensatzes wurde als Schlüssel gewählt, da alle Verweise zwischen Datensätzen über diese GUID realisiert werden und durch diese Implementierung eine schnelle und eindeutige Auflösung von Verweisen möglich ist

85 Kapitel 4. Das Projekt 4.3. Connector Abb. 4.15: User-Klasse Benutzerzuordnung Um die Benutzeraccounts im CRM eindeutig den Benutzern im Active Directory zuzuordnen, wird die Active Directory-GUID verwendet, da diese die einzige Eigenschaft eines Accounts ist, die sich nach der Erstellung nicht mehr ändert. Dieser Wert existiert auch in der CRM-Datenbank als Spalte der Tabelle für Benutzeraccounts. Dieser ist jedoch als systemintern deklariert und lässt sich durch den Zugriff auf den SOAP-Webservice nicht auslesen. Um dies zu umgehen, erweitert die CRM-Lösung, welche als Grundlage für den Connector dient, die Benutzerentität um ein weiteres Feld con_activedirectoryguid, deren Wert vor jeder Synchronisation mit dem Wert der systeminternen Tabelle abgeglichen wird. Der erste Ansatz war, dies über einen Datenbank-Trigger zu realisieren, der diesen Vorgang automatisch bei Veränderungen durchführt. Jedoch wurde dieser Ansatz verworfen, da ein solches Vorgehen von Microsoft nicht unterstützt wird. Die gewählte Lösung besteht nun darin, dass der Connector sich vor jeder Synchronisation mit dem SQL-Server verbindet und ein manuelles Update durchführt. Dieses gleicht in jedem Benutzeraccount den systeminternen Wert mit denen des im SOAP-Service lesbaren Feldes ab. Über den Wert dieses Feldes ist nun eine eindeutige Zuordnung von CRM- Accounts zu Active Directory Benutzern möglich

86 Kapitel 4. Das Projekt 4.3. Connector Um den Abgleich der Nutzerinformationen zu ermöglichen, werden die Klassen für Benutzer im CRM und Active Directory in einer Klasse User (siehe Abbildung 4.15) zusammengefasst. Alle Objekte dieser Klasse sind in der Auflistung UserList (Abbildung 4.16) des Data-Objekts vorhanden und bilden die Menge aller Benutzer, die entweder im CRM oder Active Directory existieren. Dabei enthält jedes User- Objekt verweise auf den Active Directory-Account und CRM-Account des Benutzers. Ist der Nutzer in beiden Systemen vorhanden, sind beide Werte gesetzt, ansonsten existiert der Nutzer nur in einem der beiden Systeme. Abb. 4.16: Klasse für die Zuordnung und den Abgleich der Nutzer Zur Auswertung der Regeln ist die Mitgliedschaft der Nutzer in Gruppen oder Organisationseinheiten im Active Directory entscheidend. Gruppen-Mitgliedschaften werden über das member -Attribut der Gruppe festgestellt. Dieses enthält alle Distinguishedname-Werte der enthaltenen Benutzer. Diese werden nach dem entsprechenden ADUser -Objekt aufgelöst und dieses dann der Gruppe hinzugefügt oder nicht länger enthaltene Mitglieder aus der Gruppe entfernt. Der Distinguishedname wird auch dazu verwendet, die Organisationseinheit festzustellen, in der sich ein Objekt befindet. Diese steht durch die ParentOU - Eigenschaft der Klasse ADObject in allen Unterklassen zur Verfügung. Hierbei wird lediglich der eigene Name aus dem Wert des Attributs entfernt und der Rest des Pfades gegen ein OU-Objekt aufgelöst. Im Falle eines Benutzers mit dem distinguishedname: Obj-Dist-Name = cn=admin,ou=administratoren,ou=benutzer,dc=firma,dc=de liefert dieses Verfahren den Wert: Obj-Dist-Name ou=administratoren,ou=benutzer,dc=firma,dc=de