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.

Checkliste: Microsoft 365 Offboarding-Prozess ohne Datenverlust
https://www.netatwork.de/checkliste-microsoft-365-offboarding-prozess-ohne-datenverlust/

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

In Office 365 ist es nicht so einfach das "Last Login"-Feld zu lesen, da es das nicht gibt. Sie können aber die Daten indirekt ermitteln, indem Sie das LoginAudit auslesen. Für Benutzer mit einem Exchange Online Postfach können Sie dort ein "Last Login"-Feld auslesen.

# Exchange Online PowerShell
(Get-Mailbox) | Foreach {`
   Get-MailboxStatistics $_.Identity `
   | Select DisplayName, LastLogonTime} `
   | Export-CSV LastLogonDate.csv

Umgang mit Exchange-Postfach

Wenn ein Benutzer ausscheidet aber niemand sein Kennwort kennt, dann passiert ja erst einmal nichts mehr. Sicher wird der Arbeitsplatz "recycled" aber seine Dokument auf den On-Premises-Servern bleiben bestehen und die Kollegen kommen weiter dran. Sein Status von Skype for Business ist natürlich "abwesend" aber kritisch ist erst einmal das Exchange Postfach. Es ist ja von intern und extern erreichbar aber wird nicht mehr gelesen. So ein totes Postfach wird von Absendern nur schwer oder spät bemerkt, wenn eine erwartete Reaktion ausbleibt. Das kann aber schon einige Folgen für das Unternehmen selbst haben. Leider gibt es hier keinen "Standard", wie eine Firma mit einem solchen Postfach umgeht. Hier einige Varianten, die ich alle schon gesehen habe.

Einstellung Bewertung

Postfach löschen

Benutzer weg = Postfach weg. Damit ist zumindest kein Missbrauch mehr möglich aber der Zugriff auf bisherige Inhalte ist auch weg. Irgendwann wird das auch passieren aber frühestens nach der geregelten Übergabe des Postfachs

Gefährlich

SharedMailbox

Um Lizenzen zu sparen, können Sie aus dem Postfach eine "Shared Mailbox" machen. Sie ist damit weiter erreichbar aber das Benutzerkonto ist "deaktiviert". Der Rechtsnachfolger kann das Postfach zusätzlich einbinden und die Daten überführen. Er muss dies aber auch tun, denn es kommen ja weiter neue Mails in das Postfach. Er sollte also die Absender über die neuen richtigen Adressen informieren und irgendwann wird das Postfach gelöscht.

Die Wandlung in einer SharedMailbox spart ihnen die Postfach-Lizenz, insbesondere mit ExchangeOnline, aber verführt zu Missbrauch. Mein Tipp: lassen sie das Postfach bestehen, deaktivieren Sie den Benutzer und tragen Sie auch so einen Nachfolger ein, der sich z.B. 4 Wochen um das Postfach kümmert, ehe es gelöscht wird

Nutzbar über einige Wochen

OOF-Meldung/Regel

Sie können das "Ende des Postfachs" auch mit einer Regel oder OOF-Meldung unterstützen, so dass die Absender eine Information bekommen. Das kann aber zu "Schleifen" führen und nicht alle Absender, insbesondere automatisierte Systeme, regieren darauf. Es sollte also schon noch jemand das Postfach kontrollieren, solange es Mails empfängt.

Nutzbar über einige Wochen

0 Byte-Quota

Den Empfang selbst können Sie natürlich unterbinden. Eine Option ist die Reduzierung des Quota auf 0 Bytes. Der externe und interne Absender bekommt dann die Information, dass das Postfach "voll" ist. Über die Außenwirkung dürfen Sie selbst mit ihrem CEO diskutieren.

Ungern

Empfangsbeschränkung

Eine weitere Option ist die Beschränkungen des Empfangs auf bestimmte Absender. Auch hier bekommen alle anderen Absender eine NDR-Meldung.

Ungern

Mailadresse "invalid"

Sie können dem Empfänger auch die Mailadressen wegnehmen oder verändern. Externe Absender erreichen den Empfänger nicht mehr (NDR) aber interne Absender könnten über das Adressbuch das Postfach immer noch finden, wenn es nicht "verborgen" wird.

Ungern

Sie können die verschiedenen Optionen auch kombinieren aber einen goldenen Weg gibt es nicht aber wohl eine Empfehlung wenn Sie eine private Nutzung der Mailbox von vorneherein ausgeschlossen haben.

Um einen regelten Übergang zu erlauben, sollten Sie den Posteingang dem Rechtsnachfolger übertragen, sei es als Stellvertreter oder eine Umleitung/Weiterleitung, so dass dieser Nachfolger über einige Zeit die die Absender auf eine Umstellung der Adressierung hinweisen kann. Der Nachfolger kann auch auszugsweise Mails und insbesondere Anlagen aus dem Postfach "überführen" ehe das Postfach nach einer Karenzzeit (meist ein paar Wochen) gelöscht wird.

Umgang mit Office 365

Wenn Sie das Postfach löschen oder sogar das Konto im Active Directory, dann wird in Verbindung mit Office 365 auch das Konto in der Cloud gelöscht. Das ist sinnvoll, damit die Lizenzen eingespart werden können aber auf der anderen Seite können dann durchaus größere Datenbestände verloren gehen. Primär sind das die Mails, Termine, Kontakte im Postfach aber auch die Dateien im OneDrive des Anwenders und alle Informationen die in diesen beiden Speichern noch so abgelegt werden, z.B. Teams Chats, Besprechungsaufzeichnungen u.a. Aber es gibt noch mehr

Einstellung Bewertung

Teams Besitzer

Eine Person kann der Besitzer eines Microsoft Teams sein. Wenn er ausscheidet, und keine weiteren Besitzer vorhanden sind, haben Sie ein "orphaned Team"

Task/Planner Owner

Wenn Sie Planner nutzen, um Ausgaben zu verteilen, dann sollten Sie sicher sein, dass die Aufgaben eines ausgeschiedenen Benutzers an eine andere Person übertragen werden und nicht in der Luft hängen

OneDrive Dateien und Freigaben

"Teilen statt Mailen" ist die neue Art der Zusammenarbeit und dazu gehören nicht nur gemeinsame Teams und Sharepoint-Libraries sondern auch das individuelle OneDrive. Prüfen Sie, welche Daten der Anwender dort gespeichert hat, die noch an einen gemeinsamen Ort übertragen werden müssen. Interessant sind hier auch individuelle Freigaben von Dateien an externe Personen.

Teams Meeting Organisator

Wer ein Meeting organisiert, ist der Inhaber und kann als einziger die Einladung ändern, Optionen einstellen und absagen. Wenn jemand ausscheidet, sollten die Meetings abgesagt und neu geplant werden.

Weitere Dinge

Überprüfen sie all ihre Microsoft 365 Dienste auf solche Abhängigkeiten. Meine Liste ist nur ein Denkanstoß

Sie können natürlich überlegen, ob sie beim Deprovisionieren des Benutzer all diese "Probleme" lösen oder ein z.B. täglich laufendes Reporting solche Unstimmigkeiten erkennt und meldet.

Allerdings ist hier der "Druck" schon höher, da jeder Benutzer in Office 365 laufende Kosten verursacht und schon daher die Karenzzeit eher in Wochen oder Monaten definiert wird. Jahrelang "gehaltene" Postfächer wie bei einer lokalen On-Premises-Nutzung sind hier eher die Ausnahme.

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