Wie sollte eine FIM-Laborumgebung aussehen?

Diese Frage führt bei den FIM-Konstruktionssitzungen immer zu einer lebhaften Diskussion, da es zu diesem Thema viele verschiedene Standpunkte gibt.

Ein FIM-Projekt unterscheidet sich insofern von den meisten IT-Projekten, als es sich um ein "typisches Infrastruktur-" und ein "typisches Entwicklungsprojekt" handelt, die miteinander verschmolzen sind und zudem mit einer Reihe anderer Systeme integriert werden. Wenn man diese Aussage für bare Münze nimmt, scheint es nicht so, als würde sich ein FIM-Labor grundlegend von einem typischen Projektlabor unterscheiden, bis man anfängt, über die zugrundeliegende Bedeutung dessen nachzudenken, was zum Erreichen der Entwicklungs- und Testziele erforderlich ist.

Es gibt zwar keinen einheitlichen Ansatz für den Aufbau einer guten Laborumgebung, aber ich habe festgestellt, dass die FIM-Entwicklung und -Implementierung umso erfolgreicher ist, je enger die Entwicklungsumgebung an die Produktionsumgebung angelehnt ist. Die Übereinstimmung der Laborkonfiguration mit der Produktionskonfiguration trägt aus folgenden Gründen zur Risikominderung und zu einer erfolgreichen Implementierung bei:

• Validiert Entwurfsannahmen
• Validiert hardware und Serverkonfigurationen
• Erhöht die Genauigkeit des Entwicklungsaufwands
• Erhöht die Fähigkeit, genaue Tests durchzuführen
• Ermöglicht die Identifizierung und Entschärfung von Problemen, die bei Produktionsdaten vor der Einführung auftreten werden
• Kann die Anzahl der Probleme reduzieren, die bei der Portierung von Code und Produktkonfigurationen zwischen verschiedenen Umgebungen auftreten können
• Leichtere Übertragung von Konfigurationsänderungen von der Entwicklung in die Produktion

Ich verwende die folgende Reihe von Fragen, um die Diskussion zu leiten und die übergeordneten Ziele des Labors zu ermitteln:

• Welches ist das Risikoprofil (Toleranzniveau) der Organisation?
• Was ist der Zweck des Labors?
  • Einmalige Entwicklung
  • Fortlaufende Entwicklung nach der ersten Einführung
  • Integrationstests vor der Produktion (z. B. Hotfixes, Service Packs, Konfigurationsänderungen, Load Balancer-Konfiguration usw.)
  • Vorproduktionsleistungstests

• Welche Systeme müssen in das Labor aufgenommen werden?
  • Jedes System, mit dem sich FIM verbinden muss, sollte Teil des Labors sein.
  • Können wir eine Kopie der Produktionsdaten zur Verwendung im Labor erstellen? (Physisch zu virtuell (P2V) oder VM-Export)

• Welche Art von Informationen wird FIM im Entwurf verwalten? (z. B. Objekttypen - AD-Benutzer, AD-Gruppen, AD-Kontakte, HR-Datensätze, Sun-Benutzer usw...)

• Welche Ausrüstung ist für die Einrichtung der Entwicklungsumgebung vorhanden?
  • Mit welcher Virtualisierungsplattform arbeitet das Unternehmen?
  • Können alle Datenquellen im Labor isoliert werden? (z. B. können einige Systeme nicht zum Labor hinzugefügt werden, wie z. B. Midrange- oder Mainframe-Systeme) Kann ein TMG-Server so eingerichtet werden, dass Datenverkehr von einem isolierten Labor zu einem Produktionssystem möglich ist?

• Welche Arten von Tests möchten Sie durchführen?
  • Einheitliche Prüfung
  • Integrationstests
  • Systemprüfung
  • Leistungsprüfung
  • Abnahmetests

• Welche Komponenten des Entwurfs möchten Sie vor der Produktion entwickeln und testen?
  • Es gibt eine Reihe von verschiedenen Tests, die im Rahmen des Projekts in Betracht gezogen werden sollten. Im Folgenden werden einige der zu berücksichtigenden Testbereiche aufgeführt:

• Welche Fähigkeiten sind für die Einrichtung und Wartung der Umgebung erforderlich?
  • Interne Verwaltungskenntnisse
  • Gibt es neue Technologien wie Clustering oder SCSM, die eingeführt werden?

Bewährte Praktiken rund um ein FIM-Labor:

Sobald klar ist, welche Ziele das Labor erfüllen soll, ist es wichtig, die folgenden bewährten Verfahren für die Gestaltung des Labors zu prüfen und anzuwenden:

1. Sammeln Sie vor dem Aufbau des Labors alle Anforderungen

• Wenn sich die Anforderungen an das Labor ändern, nachdem es gebaut wurde, kann ein kompletter Neuaufbau des Labors erforderlich sein.

2. Die Laborsysteme sollten von den Produktionssystemen getrennt sein.

• Fehler in der Entwicklung können zu Produktionsproblemen führen
• Die Möglichkeit, Änderungen an der Konfiguration vor der Produktionseinführung zu testen, ist begrenzt.

3. Wenn nicht genügend hardware vorhanden ist, um ein richtiges Labor einzurichten, sollten Sie den Einsatz von Virtualisierungstechnologien wie Hyper-V

• Weniger hardware erforderlich
• Einfachere Erstellung von Sicherungskopien der Konfiguration zu einem bestimmten Zeitpunkt und Rückgriff auf frühere Konfigurationen

4. Die Laborumgebung sollte eine Darstellung jedes Systems enthalten, mit dem sich FIM verbinden wird

• Eine Darstellung jedes Systems, das von FIM verwaltet wird
  • Die Systeme sollten die gleiche Plattform haben.
    • Identifizierung der Versionsstufe des Betriebssystems (Hotfixes, Service Packs) und der installierten Produkte
    • Die Systeme sollten die gleichen Versions- und Patch-Stände aufweisen.
    • Das Schema für jedes System sollte das Produktionssystem widerspiegeln (z.B. SQL-DB-Schema, AD-Schema, usw.)
    • Pflege der Konfiguration bestehender Systeme (z.B. Windows Trust-Konfigurationen, DNS -Konfiguration, AD-Site-Konfiguration, etc...)

• In einer Mehrdomänenstruktur sollte Active Directory die gleiche Anzahl/Platzierung der Verzeichnispartition(en) haben wie die Produktion

• Alle Systeme, für die FIM Objekte bereitstellen kann, sollten im Labor vorhanden sein. Einige Beispiele für zusätzliche Systeme, die FIM verwalten kann, sind:
  • Austausch
  • LYNC
  • Home-Verzeichnis-Server

5. Zusätzlich zu den von FIM zu verwaltenden Systemen werden weitere Infrastrukturdienste benötigt, um ein funktionierendes Netz zu unterstützen. Die folgenden Dienste sollten ebenfalls für den Einsatz im Labor in Betracht gezogen werden:

• DNS
• Sicherungssystem
• Zertifizierungsstelle
• E-Mail-System für Workflow-Benachrichtigungsaktivitäten
• Code-Repository (z. B. Team Foundation Server)
• DHCP
• Software Bereitstellung (SCCM)
• Firewalls (TMG/UAG) - für die Veröffentlichung von Anwendungen

6. Je nach der geplanten Lösung und den Prüfanforderungen sollten der Vollständigkeit halber auch die folgenden Systeme berücksichtigt werden:

• Hardware Lastenausgleicher
• UAG/TMG/Firewalls
• Client-Geräte (IPADs/IPhones/Smart Phones)
• Möglichkeit zur Verbindung mit einem externen E-Mail-Server für OTP
• Möglichkeit der Verbindung zum SMS-Gateway für OTP
• Zwei-Faktor-Authentifizierung (RSA/Smartcards)

7. Alle Client-Betriebssysteme, die vor der Bereitstellung des FIM-Clients getestet werden müssen

• Unterstützte Betriebssysteme
  • OS
  • Version (x86 oder x64)
  • Service-Pack-Stufen
  • Microsoft Office-Versionen und Patch-Levels
• Verschiedene Builds der unterstützten OS(s)

8. Datendarstellung - Wenn ich ein IDM-Labor aufbaue, exportiere ich gerne die Produktionsdaten und importiere diese Daten in meine Laborumgebung, damit ich alle Änderungen an den vorhandenen Daten sehen kann.

• Die Daten sollten aktuell und relevant sein
• Die Daten sollten aus einer Momentaufnahme über alle Systeme hinweg bestehen, um einen Datenabgleich zu ermöglichen (z. B. sollte das HR-System über Datensätze verfügen, die mit einem AD-Konto abgeglichen werden können).
• Die Daten sollten eine Darstellung aller Daten enthalten, die in jedem System importiert/exportiert werden sollen.
  • Verschiedene Klassen von Objekten sollten vorhanden sein (z. B. Benutzer, Gruppen, Kontakte)
  • Die Objekte sollten an demselben Ort wie in der Produktion platziert werden (z. B. relativ zur Verzeichnispartition der Umgebung).
    • Die OU Produktionsstandort von Objekten: ou=Company Users, dc=prod, dc=company, dc=com würde in der Entwicklung in ou=Company Users, dc=dev, dc=company, dc=com übersetzt
    • Die Attribute sollten mit Produktionswerten gefüllt werden (Vorname, SN, DisplayName, usw.). Dies ermöglicht Tests, um zu sehen, wie die Attribute geändert werden
• Benutzerkonten sollten mailboxfähig sein, um Arbeitsabläufe zu erleichtern

9. Datenqualität - Nachdem das anfängliche Labor aufgebaut und mit Daten gefüllt ist, gibt es eine Reihe von Entscheidungen im Design, die es erforderlich machen, die aktuellen Daten zu überprüfen, um festzustellen, ob die aktuellen Daten ausreichen, um die Designentscheidungen zu erfüllen.

• Welches ist das Verknüpfungsattribut zwischen den verschiedenen Systemen? In jedem System sollte ein Linker-Attribut vorhanden sein, um den Prozess der Verknüpfung der Objekte in den verschiedenen Systemen (HR-Datensatz, AD-Konto) mit einer FIM-Identität (MV-Objekt) zu erleichtern.
• Wenn die Daten in einem System nicht verfügbar sind, gibt es dann ein anderes System oder andere Systeme, die die benötigten Attributdaten bereitstellen können?
• Sind die Daten einheitlich formatiert? Schlecht formatierte Daten können eine Herausforderung für die Entscheidungslogik darstellen
• Welche Attributdaten werden benötigt, um Ansprüche zu ermitteln?
  • Wer darf ein Konto haben?
  • Wer darf einen Briefkasten haben?
• Welche Attributdaten werden für Bereitstellungsregeln benötigt?
  • Wie wird die DN bestimmt?
  • Wie wird der Kontoname berechnet?
  • Wer bekommt einen Briefkasten?
  • Welcher Datenbank sind sie zugewiesen?
  • Werden sie für LYNC zur Verfügung gestellt?
• Welche Attributdaten werden für Attributtransformationen benötigt?
  • Sind die Attributdaten für die Umwandlung eines Anzeigenamens vorhanden, um einen gültigen Anzeigenamen zu erstellen?
• Welche Attributdaten werden für die Personalisierung von Anwendungen benötigt?
  • Wo muss sie existieren?
  • In welchem Format müssen die Daten vorliegen?
• Welche Attributdaten werden für die Erstellung von kriterienbasierten Gruppen benötigt?
• Welche Attributdaten werden für die Erteilung delegierter Genehmigungen benötigt?
  • MPRs, die Rechte über eine Beziehung zum Objekt delegieren. (z. B. ein Manager, der die Benutzerkonten seiner Berichte im FIM-Portal aktualisieren darf, benötigt das Attribut "Manager" für jeden seiner Berichte)
  • MPRs, die administrative Rechte delegieren, erfordern, dass die Objekte mit einem oder mehreren Attributen versehen werden, die es FIM ermöglichen, sie in Gruppen zu identifizieren. Beispielsweise müssen die Attribute für alle Benutzer in einer bestimmten Geschäftseinheit und an einem bestimmten Standort mit der Geschäftseinheit und dem Standort des Benutzers gefüllt werden.
  • Bei Workflow-Aktivitäten, wie z. B. Genehmigungs-Workflows für den Eigentümer, muss das angezeigte Eigentümer-Attribut mit dem Eigentümer der Gruppe ausgefüllt sein.

10. Vertraulichkeit der Daten

• Gibt es sensible Daten in einem der Systeme, die geschützt oder maskiert werden müssen?
  • Gehaltsabrechnung
  • SSN
  • Geburtsdatum

11. Prüfung

• Wie bei allen Entwicklungsprojekten ist es hilfreich, die Rolle des Entwicklers von der des Testers zu trennen. Tester finden oft Wege, den Code zu brechen, die der Entwickler nicht vorgesehen hat.
• Der Bau eines großartigen Labors ist zwar wichtig, aber nur der erste Teil des Projekts. Ein gründlicher Testplan ist erforderlich, um zu überprüfen, ob der implementierte Entwurf auch das tut, was Sie wollen.