EXIT-Management - Ein Mitarbeiter verlässt das Unternehmen

Je größer die Firma wird, desto komplexer und umfangreicher sind die Prozesse beim der Einstellung und beim Verlassen eines Unternehmens.

Entry-Management

Für die Neueinstellung haben sich viele Administratoren schon etwas überlegt, da dieser Vorgang nicht "verschoben" werden kann. In der Windows Welt bedeutet dies oft:

  • Anlegen eines Active Directory Benutzers
  • Anlegen eines Exchange Postfaches
  • Anlegen eines Lync Benutzers bzw. Telefonanschlusses, wenn Sie noch nicht mit Lync arbeiten
  • Aufnahme des Benutzers in die entsprechenden Berechtigungsgruppen
  • Bereitstellen eines Windows PCs
  • Weitere Dinge
    z. B. SAP-Login, Token, VPN-Zugang, Zertifikat, Smartcard

Und die Liste ist sicher nicht vollständig. Vielleicht haben Sie ja einen klassischen "Laufzettel", der vom neuen Mitarbeiter mitgeführt wird. Andere Firmen bilden solch einen Prozess elektronisch über einen Sharepoint Workflow ab oder ein entsprechendes Identity-Management übernimmt das Anlegen und Berechtigen der neuen Konten. Sehr oft kommen aber Fragen wie bestimmte Einstellungen per "Default" hinterlegt werden können, z.B. bei neuen Benutzern in Exchange die POP3 oder OWA-Zugänge zu unterbinden. Es gibt dabei mehrere "Stufen" der Automatisierung:

  1. Manuell „als Prozess“
    Es ist nicht unüblich, dass ein User nicht nur „angelegt“ wird. Er muss ja auch in Gruppen rein, einen PC bekommen etc. etc. Und da ist „Exchange Feinheiten“ eben nur ein weiter Schritt. Und speziell kleine Firmen werden einfach weiterhin manuell alle Schritte nach einer Papiercheckliste abarbeiten.
  2. Admin Skript
    Mit wenig Arbeit sollte es möglich sein, ein Batch, VBScript oder gar PowerShell-Script zu erstellen, was die Anlage eines Benutzers komplett automatisiert übernimmt. Eingabemaske könnte ja auch eine HTA-Datei oder eine Webseite sein. Das macht den Prozess "sicherer" und sogar einfach protokollierbar. Allerdings lohnt sich dies nicht, wenn Sie nur ganz wenige Benutzer anlegen.
  3. Metadirectory
    Vielleicht haben Sie aber auch eine andere "verlässliche" Datenquelle, z.B. die Personalbuchhaltung, die ihnen regelmäßig eine Liste der gültigen Benutzer samt relevanter Stammdaten zukommen lässt. Das könnten Sie mit einem Skript sogar auch die Bestandsbenutzer pflegen und bei Bedarf sogar deaktivieren. Vielleicht sind Sie ja "groß" genug, einen Prozess wie FIM dafür einzusetzen.
  4. Managed Agent
    Wenn es primär um Exchange geht, dann können Sie die Commandlets um eigenen Code über CmdLetExtensionAgents erweitern. Die werden dann z.B. bei einem "Enable Mailbox" gestartet und passen die Werte entsprechend an. Sie sind auch nicht zwingend auf Exchange beschränkt aber nur im Zusammenhang mit Exchange nutzbar
  5. Getriggerte Aktion
    Mit GET-USNChanges habe ich ein Skript, welches auf geänderte Objekte reagiert. Damit könnte man einen „Nachläufer“ bauen, der eben auf dem Server alles „Fixt“ was der Admin vergisst
  6. ISA/TMG
    Wer Zugriffe auf bestimmte Dienste verhindern will, muss dies nicht auf dem Dienst direkt machen, sondern kann auch den Weg zum System verbauen. Das ist z.B. bei Exchange für OWA oder ActiveSync oder anderen Webdiensten ganz hilfreich, wenn der Dienst über einen Reverse Proxy (TMG o.ä.) erreichbar ist und dieser eine Preauthentication machen. Dann kann über die Mitgliedschaft in einer Windows Gruppen bestimmt werden, ob der Zugriff möglich ist. So kann eine Firma z.B.: OWA schon generell intern erreichbar machen aber nur eine bestimmte Benutzerschar darf auch von extern zugreifen. Und das ist eine „Positivliste“, d.h. wer in der Gruppe nicht drin ist, darf nicht zugreifen.

Sie sehen also, dass auch das "Entry-Management" durchaus potential hat.

Exit

Anders sieht es aber aus, wenn ein Konto wegfallen soll. Da gibt es gleich mehrere Dinge, die schief gehen können:

  • Keine Information
    Das erste Dilemma ist, dass die IT-Abteilung in der Regel erst spät oder gar nicht die Information erhält, wann ein Benutzer ausscheidet.
  • Überzählige Dienstkonten
    Aber auch innerhalb der IT wird gerne übersehen, wenn ein Konto nicht mehr benötigt wird. Besonders die "Dienstkonen" von Produkten oder temporäre Konten externer Dienstleister werden oft als Altlast ewig mitgeschleppt und sind oft sträflich unsicher, was das Kennwort betrifft. Zudem sind diese Konten oft mit sehr vielen Berechtigungen versehen.
  • Irrtümlich gelöschte Konten
    Das ist ihnen sicher auch schon mal passiert, dass Sie ein Konto nicht mehr zuordnen konnten und daher gelöscht haben und später ist aufgefallen, dass da doch noch was mit verbunden war.

Das Pendel kann also in beide Richtungen ausschlagen: Zum einen Konten die ein Sicherheitsrisiko darstellen als auch das Risiko des Aufräumens.

Ermitteln von Konten

Ideal wäre es natürlich schon, wenn zu jedem Konto quasi ein "Stammdatenblatt" angelegt wird, welches verantwortliche Personen und Einsatzzweck dokumentiert. zudem sollten die Konten von "natürliche Personen" von Personalabteilung oder anderen Stellen zuverlässig gemeldet werden. Wenn die Lohnabteilung keine Zahlungen mehr leistet, braucht das Konto auch keine Zugriffe mehr. Aber die Welt ist nicht immer schön, so dass Sie als Administrator sich behelfen können.

  • Trick1: Konten immer "verfallen lassen"
    Wenn Sie schon keine Meldung bekommen, welche Konten ausscheiden, könnten Sie ein Active Directory Konto wie einen Personalausweis mit einer "Gültigkeitsdauer" versehen.

    Wenn Sie dann noch zu jedem Konto einen "Manager" pflegen, können Sie dessen einige Wochen vor dem "Ablauf" des Kontos über das Ende informieren, so dass dieser reagieren kann.

    Reagiert er nicht, dann ist das Konto nach Ablauf der Frist eben nicht mehr nutzbar.
  • KennwortÄnderungen verfolgen
    Es gehört zum guten Stiel, dass zumindest natürliche Personen regelmäßig ihr Kennwort ändern müssen. Das Datum der letzten KennwortÄnderung kann im Active Directory recht einfach ermittelt werden. Konten die also schon länger als die maximale Gültigkeitsdauer ihr Kennwort nicht mehr geändert haben, sind entweder Ausnahmen oder nicht mehr aktiv. Ein Grund mehr hier nachzufragen und diese Konten im ersten Schritt mal ablaufen zu lassen.
  • LastLogin aus dem AD ermitteln
    Ein dritter Weg ist die Ermittlung, wann das Konto das letzte Mal tatsächlich für eine Anmeldung genutzt wurden. Natürlich gibt es auch Systeme, die sich einmal anmelden und dann angemeldet bleiben, aber auch Kerberos-Tickets werden ersetzt, Computer werden gepatched und gebootet und letztlich kann man schon davon ausgehen, dass auch Dienstkonten vielleicht nach spätestens 3 Monaten doch mal eine neue Anmeldung durchführen. Das letzte Anmeldedatum eines Kontos wird z.B. im Active Directory hinterlegt.
  • LastLogin aus dem Eventlog ermitteln
    Alternativ kann man natürlich auf allen Servern das Security-Eventlog auf Anmeldungen untersuchen. In vielen Firmen gibt es sogar schon entsprechende Lösungen, um die Anmeldevorgänge zwecks Auditing und Erkennen von Einbruchsversuchen zentral zu sammeln. Dann ist es natürlich noch einfacher, solche "toten" Benutzer zu finden. Zudem kann man so auch erkennen, von welchem Client die Anmeldung gekommen ist. Der Weg über ein Auditing auf Dateien o.ä. ist aber nur bedingt geeignet, da sie dann ja alle Ressourcen überwachen müssten.

Sie sehen, dass eine Menge Möglichkeiten gibt, Konten auf ihre Verwendung zu prüfen. Und seit Windows 2008R2 PowerShell gibt es sogar ganz einfache Tools, um relativ tote Accounts auf Basis des Felds "LastLogonDate" zu erkennen.

Achtung:
Das Feld "LastLogonDate" kann bis zu 9.-14 Tage "veraltet" sein. Es ist also nicht "Realtime". Siehe dazu auch
“The LastLogonTimeStamp Attribute” – “What it was designed für and how it works”
http://blogs.technet.com/b/askds/archive/2009/04/15/the-lastlogontimestamp-attribute-what-it-was-designed-for-and-how-it-works.aspx

import-module ActiveDirectory

# Listet alle user mit deren LastLogonDate
get-aduser -f * -pr lastlogondate | ft samaccountname,lastlogondate -auto

# listet alle user, die mehr als 10-20 Tage nicht angemeldet waren
get-aduser -f * -pr lastlogondate | where {$_.lastlogondate -le (get-date).adddays(-10)} | ft samaccountname,lastlogondate

#Geziele Suche nach Konten die in im letzten Jahrn nicht angemeldet waren.
search-adaccount -accountinactive -usersonly -timespan "365" |ft samaccountname

Benutzer einfach löschen - oder?

Angenommen Sie haben nun Konten gefunden und bestimmt, dass diese nicht mehr genutzt werden dürfen. Dann könnten Sie diese einfach im Active Directory löschen. Aber halt, das ist vielleicht nicht die beste Option. Welche Optionen gibt es ?

  • Konto löschen
    Das ist die endgültige Lösung für das Problem. Allerdings ist ein "undo" nicht gerade einfach. Vielleicht sollten Sie ein Konto nicht sofort löschen, sondern erst nach bestätigter Inaktivität. Zudem gibt es andere Fakten, die ein schnelles Löschen verbieten: Gerade im Bereich der Revision kann es auch später interessant sein, welche Konten es in der Vergangenheit gegeben hat und welche SIDs und Gruppenmitgliedschaften diese zuletzt inne hatten. Gerade die nicht mehr zuzuordnenden SIDs in Berechtigungen können Fragen aufwerfen. Wenn Sie ein Konto also final löschen, sollten Sie vielleicht doch die Informationen mit LDIFDE oder einem anderen Tools exportieren.
  • Konto deaktivieren
    Wenn Sie das Konto nicht löschen wollen, dann könnten Sie natürlich das Konto erst mal deaktivieren. Aber halt: für Exchange haben deaktivierte Konten eine besondere Bedeutung. Siehe auch Disabled Account. Die Auswirkungen wollen also bedacht sein.
  • Konto "verfallen lassen"
    Wenn also deaktivieren keine gute Wahl ist, dann könnten Sie das "Verfallsdatum" einfach in die Vergangenheit legen. Damit wäre keine Anmeldung mehr möglich aber das Konto ist weiterhin da. Unschön ist dabei, dass ein Administrator nicht an einem Icon erkennen kann, das dieses Konto eigentlich "Administrativ verfallen" ist.
  • Kennwort ändern
    Eine andere, aber selten genutzte Option ist das Festlegen eines neuen Kennworts. Damit kann zwar der Anwender sich nicht mehr anmelden aber jemand anderes könnte sich nun als Benutzer ausgeben.

Welche Regelung für ihre Umgebung die passende Lösung darstellt, müssen Sie selbst definieren.

Daten

Zuletzt möchte ich noch ein paar Worte über die Nutzdaten verlieren, die mit so einem Konto verbunden sein können.

  • Benutzer mit SID und Owner
    Auf den Verlust der Informationen zur SID und die Verwendung in entsprechenden ACLs bin ich schon eingegangen. Aber auch der "Besitz" von Dateien ist eine Information, die nach dem Löschen des Kontos nicht mehr angezeigt werden kann.
  • Benutzer und MemberOf
    Auch die Information, in welchem Verteiler oder welcher Gruppe der Benutzer enthalten war
  • Mailadresse für Messagetracking und Dubletten
    Wird der Benutzer vorzeitig gelöscht, dann können Sie beim Exchange Messagetracking den Anwender natürlich nicht mehr als "Empfänger" oder Sender aus der Liste auswählen. Sie müssten also schon wissen, wie die Mailadresse des Benutzers war. Aber eventuell müssen Sie auch sicherstellen, dass eine früher verwendete Mailadresse nicht sofort wieder vergeben werden kann. Stellen Sie sich vor ein langgedienter hoher Mitarbeiter scheidet aus und ein neue Azubi hat zufällig den gleichen Namen. In großen Firmen ist dies gar nicht mal zu ungewöhnlich. Der Azubi sollte aber weder unwissentlich in dem Namen senden noch vertrauliche Mails erhalten, die irrtümlich noch an die Mailadresse des früheren Mitarbeiters gehen.
  • Benutzerprofil
    Per Default kann nur der Benutzer auf die Daten in seinem Profil zugreifen. Natürlich sollte jede Firma darauf achten, dass im individuellen Profil natürlich keine Daten durch Anwender gespeichert werden, sondern diese zentral auf einem Dateiserver, Sharepoint o.ä. liegen. Wird ein Benutzer gelöscht, bleibt das Profil auf Clients allerdings erhalten. Aus Datenschutzüberlegungen sollte also beim abschließenden Löschen eines Benutzers auch geprüft werden, auf welchen Systemen ein vorhandenes Profil entfernt werden muss. Darauf zu warten, dass der PC neu installiert wird, ist keine gute Idee.
  • Zertifikate und EFS-Schlüssel
    Benutzer können Mails und Dateisystem "verschlüsseln". Schade, wenn diese Daten mit dem Löschen des Benutzers nicht mehr entschlüsselbar wären. Allerdings hilft ihnen hierbei das Active Directory Konto nicht wirklich weiter, weil Sie auch mit einem zurück gesetzten Kennwort nicht mehr an die Daten heran kommen. Windows gibt dann die Schlüssel im "Protected Store" nicht frei. Es kann daher sinnvoll sein, dass der Mitarbeiter sein Kennwort mit dem Ausscheiden an die Firma aushändigt, um den Zugriff auf solche Daten zu erhalten. Das Problem ist natürlich nicht existent, wenn Sie EFS blockieren bzw. Recovery-Konten definieren und für Zertifikate ein "Private Key Recovery" eingerichtet haben.
  • Computerkonto und Bitlocker-Schlüssel
    Computerkonten sind natürlich auch "löschbar", wenn diese nicht mehr vorhanden sind. Wer mit Bitlocker arbeitet, kann an das Computerkonto auch die Recovery-Schlüssel anbinden. Sie sollten also schon sicher sein, dass der entsprechende PC samt Festplattendaten wirklich nicht mehr erforderlich ist, sonst nehmen Sie sich die Möglichkeit eine verschlüsselte Disk zu öffnen.
  • Exchange
    An einem Active Directory Benutzer hängen natürlich auch die Einstellungen für das Postfach, d.h. Datenbank, Quotas aber auch Mailadressen und auch Verteilermitgliedschaften sind von Interesse. Weiter oben habe ich schon erläutert, welche Auswirkungen die verschiedenen Optionen haben, einen Benutzer zu deaktivieren, zu sperren etc. Spätestens mit dem Löschen des AD-Kontos verliert Exchange aber auch die Verbindung dieses Postfachs zur Datenbank und nach 30 Tagen (Default) würde das Postfach auch gelöscht. Aber mittlerweile gibt es ja auch noch ein Archivpostfach und die "Suche über Postfächer" mit der Discovery-Mailbox funktioniert nur, wenn die Postfächer auch da sind. gelöschte Objekte werden nicht durchsucht. Insofern kann das schon ein Aspekt sein, Benutzer nicht zu löschen.
    Es kann also eine Lösung sein, diese ausgeschiedenen Postfächer einfach in eine eigene Datenbank "Alte Anwender" zu verschieben.
  • Lync Einstellungen
    Auch wenn Lync eine eigene Datenbank (Lync CMS) nutzt, so sind auch hier am Active Directory Konto verschiedene Daten hinterlegt, z.B. Rufnummern, Richtlinien etc. Das Löschen des Kontos entfernt natürlich auch all diese Informationen aber nicht die Einträge in der CDR-Datenbank oder in Meetings des Anwenders. Hier sollte also geprüft werden, ob Informationen über den Anwender z.B. für die Abrechnung von Telefongesprächen ö.ä. noch benötigt werden, ehe das Konto gelöscht wird.
    Wird es hingegen nicht gelöscht, dann muss natürlich sichergestellt werden, dass Rufe an diese Nummer bei einem Stellvertreter oder Nachfolger landen. Die Einrichtung einer Umleitung ist hier ratsam.
  • RMS-Schutz
    Wenn Sie also Firma auf Rights Management Services setzen, dann sollten Sie wissen, dass der RMS-Services die Rechte an dem Feld "mail" und "ProxyAddresses" festmacht. Wenn ein Mitarbeiter ausscheidet und gelöscht wird, können eventuell Dokumente nicht mehr geöffnet werden, es sei denn sein Rechtsnachfolger bekommt die Mailadresse des früheren Mitarbeiters.
    Beachten Sie dies auch, wenn ein Mitarbeiter ausscheidet und ein neuer gleichnamiger Mitarbeiter später wieder eingestellt wird. RMS ist kein Zugriffsschutz.

Aktionsplan

Wenn Sie sich bislang noch nie Gedanken über das "Ausscheiden" von Benutzern, Diensten und Computern in ihrem Netzwerk gemacht und sie es bis zum Ende dieser Seite geschafft haben, dann könnte ich einen wunden Punkt in ihrer Ablauforganisation gefunden haben. Nun sind Sie an der Reihe sich zu überlegen, wie Sie diese Lücke stopfen.

Pause Management

Wenn Sie nun glauben, Sie hätten die relevanten Fälle bedacht, dann geben ich ihnen noch zwei Fälle mit:

  • Mutterschutz und Elternzeit (auch Väter !)
    Dieser "Vorfall" ist planbar, zumindest für den Arbeitgeber, wenn ihm die Mitarbeiter Bescheid sagen. Da der Arbeitnehmer in der Regel wieder kommt, muss man das Konto vielleicht nicht komplett entfernen. In der Buchhaltung wird es ja auch weiter geführt. Aber es muss gegen Missbrauch geschützt werden und im Sinne des unternehmens muss eine Datenübergabe verfolgen.
  • Plötzliche oder längere Krankheit
    Nicht immer verlässt ein Kollege das Büro "geplant", sondern landet im Krankenhaus oder ist einfach unvorhergesehen länger abwesend. Auch wenn er vielleicht im Krankenhaus noch seine Mails per PDA liest, so sollte dies nicht der Normallfall sein. "Krank"-Zeiten erfordern Ruhe zur Genesung.

In beiden Fällen müssen Sie als Firma sich natürlich Gedanken machen, wie die Arbeit fortgesetzt werden kann. Kann der Mitarbeiter im ersten Fall noch aktiv daran mitwirken, muss im zweiten Fall natürlich überlegt werden, wie damit umgegangen wird. Werden Mails an das Postfach umgeleitet oder wird zentral eine OOF-Meldung eingerichtet ?. Vielleicht soll auch ein Stellvertreter die Berechtigungen erhalten, nach dem Postfach zu schauen. Nicht immer kann der Mitarbeiter noch seine Einwilligung geben. Fein raus ist, wer hier z.B.: eine private Nutzung untersagt hat. Aber auch dann sollte es vorab entsprechende Regelungen geben, die jeder Mitarbeiter auch kennt und zugestimmt hat.

Und dann hoffen wir, dass alles gut wird, dass aus der Unterbrechung kein Exit-Management wird.

Weitere Links