„Hey Joe, ich brauch mal schnell ein Benutzerkonto für den Externen, der im Meetingraum sitzt und die Firewall konfigurieren soll“ – Quelle unbekannt

Sowas gibt es heutzutage nicht mehr? Leider weit gefehlt.

In unserem Blog-Beitrag für diesen Monat beschäftigen wir uns mit dem Thema Benutzer-Lifecycle-Prozesse. In jeder Firma kommen und gehen Mitarbeiter, Mitarbeiter heiraten, gehen in Elternzeit oder werden krank. Man sollte meinen, dass die Benutzer-Lifecycle-Prozesse in jedem Unternehmen vorhanden und aus Effizienz- und Sicherheitsgründen standardisiert und automatisiert sind.

Da wir uns im letzten Jahr bei einigen unserer Kunden intensiv um das Thema gekümmert haben, können wir sagen, auch im Jahr 2022 ist das Thema nicht in jedem Unternehmen zufriedenstellend gelöst.

In diesem Artikel möchten wir auf die wichtigsten Aspekte rund um das Thema Benutzer-Lifecycle eingehen, wir erheben aber keinen Anspruch auf Vollständigkeit. Auch muss klar sein, dass jedes Unternehmen andere Anforderungen und Voraussetzungen hat. Daher zeigen wir auch keine konkrete Lösung auf, sondern möchten Denkanstöße für die eigene Lösungsfindung geben. Bei der Betrachtung nehmen wir den Blickwinkel des Active Directory-Teams ein.

Wichtige Fragestellungen

Bevor wir näher auf einige der Aspekte eingehen, hier die wichtigsten Fragen, die man für sich beantworten sollte, wenn man die Benutzer-Lifecycle-Prozesse implementiert.

• • Wer „stellt Mitarbeiter ein“ (oft unterschiedlich nach internen und externen Mitarbeitern)?
  • Welches ist das führende System und in welchen Systemen müssen Benutzerkonten verwaltet werden (HR, Buchhaltung, IAM, AD, AAD, SAP etc.)?
  • Welche Schnittstellen zu anderen Prozessen gibt es (Hardware, Software, Facility Management, Buchhaltung etc.)
  • Welche Benutzerkonten-Typen brauche ich (interne, externe, administrative, technische Benutzerkonten etc.)?
  • Welche Daten/Attribute muss/möchte ich für die verschiedenen Kontentypen pflegen?
    • Welche davon sind standardisiert, welche sind frei wählbar?
    • Liegt die Organisationsstruktur vor und wie soll diese abgebildet werden?
  • Wer darf welchen Kontentyp beantragen? Sollen Prozesse vollautomatisiert werden (z.B. das Anlegen des Benutzerkontos im AD wird durch Änderung im HR-System gesteuert)?
  • Wer ist verantwortlich für die (technischen) Benutzerkonten. Was passiert, wenn ein verantwortlicher Mitarbeiter aus dem Unternehmen ausscheidet?
  • Wie erhält der Mitarbeiter die Zugangsdaten?
  • Wie kann ein Mitarbeiter das Passwort zurücksetzen lassen?
  • Wie geht man mit längeren Abwesenheiten wegen Elternzeit oder Krankheit um?
  • Wann kann ein Benutzerkonto gelöscht werden? Wie lange müssen die Daten des Benutzers nach Ausscheiden aufbewahrt werden und wie wird das sichergestellt?
  • Kann man sicherstellen, dass die Prozesse zu 100% gelebt werden, oder muss man einen „doppelten Boden“ einbauen (z.B. regelmäßiges Scannen nach inaktiven Benutzerkonten)?

Definition der involvierten Parteien

Aus den ersten Fragen ist direkt ersichtlich, dass das Thema Benutzer-Lifecycle-Prozesse nicht aus dem AD Team heraus vollständig gelöst werden kann und viel Abstimmung nötig ist. Daher ist es zunächst ratsam, sich seines Unternehmens bewusst zu machen.

Es gilt, zunächst die gelebte Praxis abzufragen und ggf. aufzuschreiben. Welche Prozesse gibt es schon, welchen Reifegrad haben sie, welche fehlen vielleicht komplett? Sind alle notwendigen Parteien bereits involviert bzw. haben die Anforderungen definiert? Aus unserer Erfahrung sind organisatorisch (mindestens) die Einheiten HR, Provider Management, Facility Management, Information Security, Compliance/Legal und Datenschutz zu involvieren. Auf der technischen Seite sind das (mindestens) die Teams Client, Collaboration und Service Management (für das Request Fulfillment Portal, siehe unten).

Sind nicht alle Applikationen ans Active Directory angebunden bzw. nutzen eine eigene Benutzerverwaltung, sollten die entsprechenden Application Teams ebenfalls eingebunden werden.

In größeren Umgebungen mit mehreren Verzeichnisdiensten und nicht integrierten Applikationen muss man sich die Frage stellen, ob nicht ein ausgewachsenes Identity- und Access-Management-System notwendig ist.

Scope- und Attributdefinition

Aus den Gesprächen mit den oben genannten Parteien ergeben sich einerseits die verschiedenen Kontentypen, die verwaltet werden müssen als auch die Attribute, die dabei zwingend oder sinnvollerweise gepflegt werden.

Nachfolgend als Startpunkt die Liste mit typischen Konten in einer Active Directory-Umgebung und die typischen Attribute:

Prozessdefinition

Aus der bisherigen Definition ergibt sich, welche Prozesse notwendig sind. In der Regel ist das für jeden Kontentyp: Anlage, Änderung, Löschung.

Der Änderungsprozess gliedert sich in der Regel in mehrere Unterkategorien, da nicht jedes Attribut auf die gleiche Weise geändert werden kann. Beispielsweise ist es in der Regel erlaubt, dass der Mitarbeiter die Änderung seiner Telefonnummer selbst beantragt, eine Positionsänderung jedoch kontrolliert wird.

An dieser Stelle auf jeden Prozess einzugehen, würde den Rahmen sprengen. Auch zum Thema Prozessdesign gibt es ganze Bücher, weshalb wir hier an der Stelle auf weitere Ausführungen verzichten.

Technische Umsetzung

Auch wenn es sich bei diesem Blog um ein nicht technisches Thema handelt, soll zumindest ein bisschen Technik behandelt werden 😊

Führendes System: HR

Nehmen wir an, dass wir den Anlageprozess in einer Organisation betrachten, deren führendes System das HR-System ist:

Erster Ansatzpunkt für das Anlegen neuer Benutzerkonten im Active Directory wäre eine Übertragung der neuen Mitarbeiter aus SAP nach Active Directory mittels eines regelmäßigen Batchauftrags. Technisch gibt es eine Reihe von Möglichkeiten, ein Script zur Benutzeranlage regelmäßig auszuführen. Das kann der Scheduler des Betriebssystems sein (Task Scheduler in Windows oder cron in UNIX/Linux) oder ein Job Scheduling Tool. Damit muss ein neuer Mitarbeiter im Unternehmen nur einmal manuell erfasst werden.

Führendes System: Active Directory

Sollte aus welchen Gründen auch immer kein führendes System aus HR nutzbar sein, kann man auch ein eigenentwickeltes Web-Portal implementieren oder die Automatisierung an ein bestehendes Request Fullfilment Portal anbinden. Denkbar hierbei ist auch die Implementierung eines Workflows, bei dem ein Vorgesetzter bestimmte Aktionen genehmigt.

Über ein Web-Portal können die Eingaben validiert werden, so dass ein Großteil von Fehleingaben hier schon ausgeschlossen werden kann. Zudem können Standardwerte wie zum Beispiel Adressen von Firmenstandorten in Auswahlfeldern hinterlegt werden und so einheitlich in den Benutzerkonten gesetzt werden. Dies ist gerade bei Attributen wichtig, die im Exchange-Adressbuch in Outlook sichtbar sind und eine Außenwirkung haben und deren Korrektheit die Zusammenarbeit im Unternehmen erleichtert.

Eine Beispiel-Lösung bei der Verwendung eines web-basierten Portals und einem Automatisierungs-Server, von dem die Skripte gestartet werden, könnte wie folgt aussehen:

Der Ablauf ist bei dieser Beispiellösung wie folgt:

Fazit

Ein ganz schön langer Artikel für ein Thema, das ja eigentlich jeder schon lebt. Der Teufel steckt allerdings im Detail. Habt Ihr alles im Griff?