IT-Onboarding & Offboarding Checkliste

Warum eine Checkliste unverzichtbar ist

In vielen KMU laeuft Onboarding und Offboarding nach Gefuehl – der zustaendige Techniker erinnert sich an die meisten Schritte, aber eben nicht an alle. Das Ergebnis: Neue Mitarbeitende warten am ersten Tag auf ihren Laptop-Zugang, oder ex-Angestellte haben noch Wochen nach dem Austritt aktive Konten und VPN-Zugaenge.

Beides ist vermeidbar. Mit einer festen Checkliste dauert ein sauber ausgefuehrtes Onboarding zwar gleichviel Zeit – aber kein Schritt geht vergessen, und du bist abgesichert, falls jemand fragt: “Hat die IT das auch wirklich gemacht?”

Onboarding: Neuer Mitarbeiter

Der Onboarding-Prozess beginnt idealerweise zwei bis drei Tage vor dem ersten Arbeitstag – nicht erst am Morgen des Eintritts.

Phase 1: Infrastruktur und Konten

Diese Schritte koennen und sollen vorab erledigt werden:

Active Directory / Entra ID:

# AD-User anlegen (On-Premise)
New-ADUser `
  -Name "Max Mustermann" `
  -GivenName "Max" `
  -Surname "Mustermann" `
  -SamAccountName "m.mustermann" `
  -UserPrincipalName "m.mustermann@firma.ch" `
  -AccountPassword (ConvertTo-SecureString "Temp@2026!" -AsPlainText -Force) `
  -Enabled $true `
  -Path "OU=Mitarbeiter,OU=Benutzer,DC=firma,DC=local" `
  -Department "Verkauf" `
  -Title "Sachbearbeiter" `
  -Company "Firma AG"

# In Sicherheitsgruppen aufnehmen
Add-ADGroupMember -Identity "GRP_Verkauf" -Members "m.mustermann"
Add-ADGroupMember -Identity "GRP_VPN_User" -Members "m.mustermann"

M365-Lizenz zuweisen (Microsoft Graph PowerShell):

# Module laden
Import-Module Microsoft.Graph.Users
Connect-MgGraph -Scopes "User.ReadWrite.All", "Directory.ReadWrite.All"

# Lizenz zuweisen (SKU-ID fuer Microsoft 365 Business Premium)
$userId = (Get-MgUser -Filter "userPrincipalName eq 'm.mustermann@firma.ch'").Id
Set-MgUserLicense -UserId $userId `
  -AddLicenses @{SkuId = "cbdc14ab-d96c-4c30-b9f4-6ada7cdc1d46"} `
  -RemoveLicenses @()

Checkliste Infrastruktur:

Phase 2: Hardware und Arbeitsplatz

Workstation aufsetzen, bevor der neue Mitarbeitende kommt:

# Hostname nach Firma-Standard setzen und in Domaene aufnehmen
Rename-Computer -NewName "PC-MMUSTERMANN" -Restart

# Nach dem Neustart: Domaenen-Beitritt
Add-Computer -DomainName "firma.local" `
  -OUPath "OU=Workstations,DC=firma,DC=local" `
  -Credential (Get-Credential) `
  -Restart

Checkliste Hardware:

Phase 3: Zugaenge und Berechtigungen

Berechtigungen immer nach dem Least-Privilege-Prinzip: so wenig Zugriff wie noetig, um die Arbeit zu erledigen.

Checkliste Zugaenge:

Netzlaufwerke per PowerShell oder GPO mappen:

# Einmalig per PowerShell (z.B. per Login-Skript)
New-PSDrive -Name "S" -PSProvider FileSystem -Root "\\fileserver\Abteilung\Verkauf" -Persist
New-PSDrive -Name "H" -PSProvider FileSystem -Root "\\fileserver\Home\m.mustermann" -Persist

Phase 4: Dokumentation

[ ] Asset-Register aktualisieren (Geraet + zugewiesener User, Seriennummer)
[ ] Ticketsystem-User anlegen (falls separates System)
[ ] Einweisung IT-Richtlinien dokumentieren (Datum, Unterschrift oder E-Mail-Bestaetigung)
[ ] Passwort-Uebergabe dokumentieren (wann, an wen, per welchem Kanal)

Mover-Prozess: Rollenwechsel ohne Rechte-Anhaeufung

Der Joiner-Mover-Leaver-Zyklus (JML) beschreibt die drei Lebensphasen eines Kontos: Eintritt, Wechsel und Austritt. Waehrend Joiner und Leaver meist gut abgedeckt sind, wird der Mover-Fall haeufig vergessen – und genau hier entsteht das groesste Sicherheitsrisiko: Rechte-Anhaeufung, auch Privilege Creep genannt.

Typisches Szenario: Ein Mitarbeitender wechselt von der Buchhaltung in den Verkauf. Die neue Abteilung braucht Zugriff auf CRM und Verkaufs-Freigaben – das wird meist zuegig eingerichtet. Die alten Berechtigungen aus der Buchhaltung (ERP-Finanzmodul, Lohn-Freigabe, Buchhaltungs-Postfach) werden aber selten aktiv entzogen, weil kein Prozess dafuer existiert und “es ja nicht schadet, wenn er noch Zugriff hat”.

Nach ein paar Jahren und mehreren internen Wechseln haben solche Mitarbeitende oft mehr Berechtigungen als jeder Neuzugang – ein ideales Ziel bei kompromittierten Zugangsdaten, weil ein einzelnes Konto dann quer durch mehrere Abteilungen reicht.

Der Mover-Prozess braucht die gleiche Sorgfalt wie Ein- und Austritt:

1. HR meldet den Rollenwechsel (neue Abteilung, Vorgesetzter, Stellenbezeichnung) so frueh wie moeglich.
2. IT vergleicht die Ist-Gruppenmitgliedschaften mit dem Soll-Profil der neuen Rolle.
3. Neue, rollenbasierte Berechtigungen werden hinzugefuegt.
4. Alle Berechtigungen der alten Rolle, die in der neuen nicht mehr gebraucht werden, werden aktiv entfernt – nicht “vorsichtshalber” behalten.
5. Der Wechsel wird dokumentiert: Datum, alte/neue Gruppen, wer hat freigegeben.

# Aktuelle Gruppenmitgliedschaften vor dem Wechsel sichern (Nachvollziehbarkeit)
Get-ADPrincipalGroupMembership -Identity "m.mustermann" |
  Select-Object Name | Export-Csv -Path "C:\Moves\mustermann_vorher.csv" -NoTypeInformation

# Aus den Gruppen der alten Rolle entfernen (Buchhaltung)
Remove-ADGroupMember -Identity "GRP_Buchhaltung" -Members "m.mustermann" -Confirm:$false
Remove-ADGroupMember -Identity "GRP_ERP_Finanzen" -Members "m.mustermann" -Confirm:$false

# In die Gruppen der neuen Rolle aufnehmen (Verkauf)
Add-ADGroupMember -Identity "GRP_Verkauf" -Members "m.mustermann"
Add-ADGroupMember -Identity "GRP_CRM_User" -Members "m.mustermann"

In groesseren Umgebungen mit Entra ID Governance uebernehmen Access Packages und dynamische Gruppen diesen Abgleich automatisch: Aendert sich das Attribut department im HR-System, werden Gruppenmitgliedschaften und damit Berechtigungen automatisch nachgefuehrt – siehe dazu den Abschnitt zur SCIM-Provisionierung weiter unten.

Contractor- und Externen-Onboarding: befristete Konten mit Ablaufdatum

Externe Mitarbeitende, Freelancer und Dienstleister brauchen oft echten Netzwerkzugang – aber nur fuer einen begrenzten Zeitraum. Der haeufigste Fehler: Ein Contractor-Konto wird wie ein normales Mitarbeiterkonto angelegt und dann vergessen, sobald der Auftrag beendet ist. Die Loesung: Ablaufdatum von Anfang an setzen, statt sich auf “manuell wieder daran denken” zu verlassen.

Active Directory:

# Contractor-Konto mit fixem Ablaufdatum anlegen
New-ADUser `
  -Name "Petra Extern (Contractor)" `
  -SamAccountName "p.extern.ext" `
  -UserPrincipalName "p.extern.ext@firma.ch" `
  -AccountPassword (ConvertTo-SecureString "Temp@2026!" -AsPlainText -Force) `
  -Enabled $true `
  -Path "OU=Externe,OU=Benutzer,DC=firma,DC=local" `
  -Description "Contractor - Projekt ERP-Migration, Vertrag bis 30.09.2026"

# Ablaufdatum setzen (Konto sperrt sich automatisch am Stichtag)
Set-ADAccountExpiration -Identity "p.extern.ext" -DateTime "2026-09-30"

# Alternative: relatives Ablaufdatum, z.B. 90 Tage ab heute
Set-ADAccountExpiration -Identity "p.extern.ext" -TimeSpan (New-TimeSpan -Days 90)

Wichtig: Ein abgelaufenes Konto wird von AD automatisch gesperrt, aber nicht geloescht. Es taucht trotzdem in Berichten auf, bis es aktiv bereinigt wird – ein wiederkehrender Rezertifizierungslauf (siehe Abschnitt weiter unten) faengt genau das ab.

Entra ID / Microsoft 365: Gastzugang statt vollem Mitgliedskonto

Fuer externe Personen, die nur auf freigegebene Teams-Kanaele, SharePoint-Seiten oder Dateien zugreifen muessen, ist ein Entra-ID-Gastkonto per B2B-Zusammenarbeit meist die bessere Wahl als ein vollwertiges internes Konto – Gaeste erhalten standardmaessig eingeschraenktere Rechte im Verzeichnis.

# Gast per Microsoft Graph einladen
New-MgInvitation `
  -InvitedUserEmailAddress "p.extern@partnerfirma.ch" `
  -InviteRedirectUrl "https://myapps.microsoft.com" `
  -SendInvitationMessage:$true

# Gast-Zugriffsdauer ueber ein Entra-ID-Governance-Zugriffspaket steuern
# (Zuweisung mit fixer Dauer, z.B. 90 Tage, automatische Entfernung danach)

Checkliste Contractor-Onboarding:

Offboarding: Austretender Mitarbeiter

Beim Offboarding gilt: Sicherheit vor Komfort. Im Zweifelsfall zuerst den Zugang sperren, dann klaeren.

Am letzten Arbeitstag (oder frueher)

# AD-Konto deaktivieren – NICHT loeschen!
Disable-ADAccount -Identity "m.mustermann"

# Konto in OU "Ausgetreten" verschieben (uebersichtlicher)
Move-ADObject `
  -Identity (Get-ADUser "m.mustermann").DistinguishedName `
  -TargetPath "OU=Ausgetreten,DC=firma,DC=local"

# Ablaufdatum auf gestern setzen (doppelte Absicherung)
Set-ADUser -Identity "m.mustermann" -AccountExpirationDate (Get-Date).AddDays(-1)

# Alle aktiven Sessions beenden (falls Remote-Zugang aktiv)
Get-PSSession | Where-Object {$_.ComputerName -like "*"} | Remove-PSSession

M365-Offboarding:

# M365-Postfach auf Shared Mailbox umwandeln (damit Mails erhalten bleiben)
Set-Mailbox -Identity "m.mustermann@firma.ch" -Type Shared

# Weiterleitung auf Vorgesetzten oder Nachfolger
Set-Mailbox -Identity "m.mustermann@firma.ch" `
  -ForwardingSmtpAddress "nachfolger@firma.ch" `
  -DeliverToMailboxAndForward $false

# Lizenz entfernen (Shared Mailbox braucht keine Lizenz bis 50 GB)
Set-MgUserLicense -UserId $userId -AddLicenses @() `
  -RemoveLicenses @("cbdc14ab-d96c-4c30-b9f4-6ada7cdc1d46")

# MFA-Geraete entfernen
# Im Entra Admin Center: Benutzer > Authentifizierungsmethoden > alle entfernen

Checkliste letzter Arbeitstag:

Hardware einziehen

[ ] Laptop oder Desktop zurueckfordern und inventarisieren
[ ] Lokale Daten sichern oder uebergeben (laut interner Richtlinie)
[ ] Geraet in Asset-Register als "verfuegbar" oder "in Aufbereitung" markieren
[ ] Mobile Geraete: MDM-Enrollment entfernen oder Remote Wipe ausloesen
[ ] Privates Geraet (BYOD): MDM-Profil entfernen, keine Firmendaten loeschen

Remote Wipe via Intune (falls konfiguriert):

Im Intune Admin Center unter Geraete > [Geraet auswaehlen] > Zuruecksetzen – oder als letztes Mittel “Ausserbetriebnehmen”, das nur Firmendaten entfernt und das private Geraet intakt laesst.

Nach 30 Tagen

Der Grund fuer den 30-Tage-Aufschub: Manchmal wird ein Konto doch noch benoetigt (laufende Projekte, Rechtsfragen, ausstehende Rechnungen). Nach 30 Tagen sollte aber endgueltig aufgeraeumt werden – im Abgleich mit HR und Rechtsabteilung.

# AD-Konto endgueltig loeschen
Remove-ADUser -Identity "m.mustermann" -Confirm:$false

# Aus allen Gruppen entfernen (vor dem Loeschen kontrollieren)
Get-ADPrincipalGroupMembership "m.mustermann" | 
  Where-Object {$_.Name -ne "Domain Users"} | 
  ForEach-Object { Remove-ADGroupMember -Identity $_ -Members "m.mustermann" -Confirm:$false }

Checkliste nach 30 Tagen:

Privilegierte und Service-Accounts beim Offboarding

Standard-Mitarbeiterkonten sind beim Offboarding meist gut abgedeckt. Zwei Kontotypen werden aber regelmaessig vergessen und sind gleichzeitig am gefaehrlichsten, wenn sie uebersehen werden.

1. Persoenliche Admin-Konten (privilegierte Zugaenge)

Hatte die austretende Person ein separates Admin-Konto, zum Beispiel m.mustermann-adm fuer Domaenen-Admin- oder Entra-Rollen, oder war sie in Privileged Identity Management (PIM) fuer zeitlich befristete Rollen eingetragen? Diese Zugaenge muessen zusaetzlich zum normalen Konto separat entfernt werden – Details zur PIM-Verwaltung selbst im Artikel Entra ID PIM und Governance.

# Separates Admin-Konto sofort deaktivieren
Disable-ADAccount -Identity "m.mustermann-adm"

# Alle aktiven und eligible PIM-Rollenzuweisungen der Person pruefen (Microsoft Graph)
Get-MgRoleManagementDirectoryRoleAssignmentScheduleInstance -Filter "principalId eq '$userId'"

2. Break-Glass- und Service-Accounts, auf die die Person Zugriff hatte

Break-Glass-Konten (Notfallzugaenge, die MFA und bedingten Zugriff bewusst umgehen) und Service-Accounts fuer Backups, Monitoring oder Schnittstellen haben oft geteilte Passwoerter, die mehreren Administratoren bekannt sind. Verlaesst einer dieser Administratoren das Unternehmen, muss jedes Passwort, das er kannte, rotiert werden – nicht nur sein eigenes Konto deaktiviert werden.

# Beispiel: Service-Account-Passwort rotieren und im Dienst neu setzen
$neuesPasswort = ConvertTo-SecureString "Kx9#mP2$vQ8zL!wR" -AsPlainText -Force
Set-ADAccountPassword -Identity "svc-backup" -NewPassword $neuesPasswort -Reset

# Dienst mit neuem Passwort neu registrieren, sonst faellt der Dienst aus
Set-Service -Name "BackupAgentService" -Credential (Get-Credential "firma\svc-backup")

Notfall-Offboarding-Runbook bei Insider-Threat-Verdacht

Ein normales Offboarding folgt einem geplanten Ablauf ueber Tage. Bei Verdacht auf Datendiebstahl, Sabotage oder anderen Insider-Missbrauch zaehlen Minuten, und die Reihenfolge der Schritte ist entscheidend – falsches Vorgehen vernichtet Beweise oder warnt die betroffene Person vorzeitig.

Reihenfolge im Notfall, in dieser Prioritaet:

1. Zugriff sperren, bevor irgendjemand informiert wird. Konto deaktivieren, aktive Sessions beenden, VPN-Zertifikat widerrufen – alles gleichzeitig, nicht nacheinander mit Pausen dazwischen.
2. Beweise sichern, bevor aufgeraeumt wird. Kein Geraet zuruecksetzen, keine Postfach-Regeln loeschen, keinen Papierkorb leeren, solange eine Untersuchung moeglich ist.
3. Physischen Zugang parallel sperren. Zutrittskarte, Schluessel, Zufahrtsberechtigung zeitgleich mit dem digitalen Zugang deaktivieren – sonst bleibt ein Weg ins Gebaeude offen.
4. Kommunikation erst danach, kontrolliert. HR, Vorgesetzte und gegebenenfalls die Rechtsabteilung erst informieren, wenn die technischen Schritte abgeschlossen sind – nicht vorher, um kein Leck zu riskieren.

# Notfall-Sperr-Skript: alles auf einmal, keine Wartezeit zwischen Schritten
$user = "m.verdacht"

# 1. AD-Konto sofort sperren und Passwort ungueltig machen
Disable-ADAccount -Identity $user
Set-ADAccountPassword -Identity $user -Reset -NewPassword (ConvertTo-SecureString (New-Guid).Guid -AsPlainText -Force)

# 2. Alle aktiven Entra-ID-Sessions und Refresh-Tokens widerrufen (Microsoft Graph)
$upn = "$user@firma.ch"
$targetUserId = (Get-MgUser -Filter "userPrincipalName eq '$upn'").Id
Revoke-MgUserSignInSession -UserId $targetUserId

# 3. MFA-Methoden bewusst NICHT entfernen, nur Sessions killen -
#    die Beweislage (registrierte Geraete/Methoden) bleibt so erhalten

Beweissicherung: was vor jeder Aufraeumaktion dokumentiert werden muss

Automatisierung mit Entra ID Lifecycle Workflows

Fuer Unternehmen mit regelmaessigem Personalwechsel lohnt sich die Automatisierung ueber Microsoft Entra ID Governance – Lifecycle Workflows. Das Feature erfordert eine Entra ID Governance-Lizenz (oder Entra Suite).

Damit kannst du Workflows definieren, die automatisch ausloesen:

• 2 Tage vor Einstellung: Temporaeren Zugangscode (TAP) generieren und an Vorgesetzten senden
• Am ersten Tag: Accounts aktivieren, Teams-Willkommensnachricht senden
• Am letzten Tag: Konten deaktivieren, E-Mail-Weiterleitung setzen

# Einstellungsdatum auf einem User-Objekt setzen (Trigger fuer Lifecycle Workflow)
Set-MgUser -UserId $userId -EmployeeHireDate "2026-07-01T00:00:00Z"

# Lebenszyklus-Workflows im Admin Center:
# Entra Admin Center > ID-Governance > Lebenszyklusworkflows > Neuer Workflow

Fuer kleinere KMU ohne Governance-Lizenz genuegen gut gepflegte PowerShell-Skripte und diese Checkliste.

SCIM-basierte automatisierte Provisionierung (HR zu Entra ID/AD)

Manuelles Anlegen von Konten skaliert schlecht und ist fehleranfaellig – Tippfehler im Namen, vergessene Abteilungszuordnung, verzoegerte Deaktivierung. Der Industriestandard fuer automatisierte Provisionierung ist SCIM, System for Cross-domain Identity Management: ein offenes REST/JSON-Protokoll, mit dem ein Quellsystem, typischerweise das HR-System, Benutzerkonten in einem Zielsystem automatisch anlegt, aktualisiert und deaktiviert. Microsoft hat die SCIM-2.0-APIs fuer Identitaets-Lifecycle-Operationen inzwischen allgemein verfuegbar gemacht.

Funktionsprinzip:

HR-System (Workday, SAP SuccessFactors, Personio, ...)
        |  SCIM 2.0 REST-API (HTTPS, JSON)
        v
Microsoft Entra ID (Attribut-Mapping: HireDate -> employeeHireDate)
        |  Entra Connect / Cloud Sync
        v
Lokales Active Directory (Benutzerobjekt wird angelegt/aktualisiert)

Microsoft Entra ID kann dabei in zwei Rollen auftreten: als SCIM-Client, der Konten in Drittanwendungen provisioniert, etwa Slack, Zoom oder Salesforce, und als SCIM-Service, der selbst Provisionierungsanfragen von einem HR-System ueber die Inbound-Provisioning-API entgegennimmt.

Provisionierungsjob und Attribut-Mapping pruefen:

Die Einrichtung erfolgt im Entra Admin Center unter Enterprise-Anwendungen, dort bei der jeweiligen HR-Anwendung unter Bereitstellung. Der Job selbst laesst sich per Microsoft Graph auslesen:

# Provisionierungs-Job einer HR-Quellanwendung anzeigen
Get-MgServicePrincipalSynchronizationJob -ServicePrincipalId $spId

# Konzeptionelles Attribut-Mapping (Konfiguration erfolgt im Portal):
# Quelle: HireDate          -> Ziel: employeeHireDate
# Quelle: Department        -> Ziel: department
# Quelle: ManagerEmployeeId -> Ziel: manager
# Quelle: TerminationDate   -> Ziel: employeeLeaveDateTime

Was SCIM-Provisionierung im JML-Kontext konkret loest:

Auch ohne dediziertes HR-System laesst sich ein einfacher, SCIM-aehnlicher Automatismus mit einem taeglichen PowerShell-Skript nachbauen, das eine CSV-Exportdatei aus dem Lohnsystem einliest und Konten entsprechend anlegt oder deaktiviert – fuer kleinere KMU oft der pragmatischere Einstieg vor einer vollen SCIM-Integration.

Access Recertification: periodische Rezertifizierung von Berechtigungen

Auch mit sauberem Onboarding-, Mover- und Offboarding-Prozess sammeln sich ueber Zeit Berechtigungen an, die niemand mehr aktiv widerrufen hat: Projektgruppen, die nie aufgeloest wurden, temporaerer Zugriff, der zur Dauerloesung wurde, oder Berechtigungen von Vorgesetzten, die “einfach mal kurz reinschauen” wollten. Access Recertification, auch Access Reviews oder periodische Rezertifizierung genannt, schliesst diese Luecke: In festgelegten Abstaenden bestaetigt eine verantwortliche Person aktiv, dass ein Zugriff noch gebraucht wird – tut sie das nicht, wird der Zugriff automatisch entzogen.

In Microsoft Entra ID Governance heisst das Feature Access Reviews. Es erlaubt periodische Ueberpruefungen fuer Gruppenmitgliedschaften, Anwendungszugriffe und Rollenzuweisungen, inklusive PIM-Rollen – siehe Entra ID PIM und Governance.

# Microsoft Graph PowerShell SDK fuer Identity Governance
Import-Module Microsoft.Graph.Identity.Governance
Connect-MgGraph -Scopes "AccessReview.ReadWrite.Membership"

# Vierteljaehrliche Rezertifizierung fuer eine kritische Sicherheitsgruppe erstellen
New-MgIdentityGovernanceAccessReviewDefinition `
  -DisplayName "Quartalsreview GRP_ERP_Finanzen" `
  -DescriptionForAdmins "Rezertifizierung der Finanzmodul-Zugriffe" `
  -DescriptionForReviewers "Bitte bestaetigen: braucht diese Person noch Zugriff auf das ERP-Finanzmodul?" `
  -Scope @{
    "@odata.type" = "#microsoft.graph.accessReviewQueryScope"
    Query = "/groups/{group-id}/transitiveMembers"
    QueryType = "MicrosoftGraph"
  } `
  -Reviewers @(@{ Query = "/groups/{group-id}/owners"; QueryType = "MicrosoftGraph" }) `
  -Settings @{
    MailNotificationsEnabled = $true
    ReminderNotificationsEnabled = $true
    JustificationRequiredOnApproval = $true
    AutoApplyDecisionsEnabled = $true
    RecommendationsEnabled = $true
    Recurrence = @{
      Pattern = @{ Type = "absoluteMonthly"; Interval = 3 }
      Range = @{ Type = "noEnd"; StartDate = (Get-Date -Format "yyyy-MM-dd") }
    }
  }

Was regelmaessig rezertifiziert werden sollte, und in welchem Rhythmus:

Ohne Governance-Lizenz laesst sich eine einfache Variante manuell umsetzen: ein wiederkehrendes Ticket, per Task Scheduler oder Ticketsystem-Vorlage angestossen, mit dem aktuellen Mitgliederexport jeder kritischen Gruppe, das an die zustaendige Fuehrungsperson zur Bestaetigung geht.

# Einfache manuelle Alternative: Export der Gruppenmitglieder fuer den Review-Verantwortlichen
Get-ADGroupMember -Identity "GRP_ERP_Finanzen" |
  Get-ADUser -Properties Department, Title |
  Select-Object Name, Department, Title |
  Export-Csv -Path "C:\Reviews\ERP_Finanzen_$(Get-Date -Format 'yyyy-MM').csv" -NoTypeInformation

Haeufige Fehler und wie du sie vermeidest

Crosslinks

• Active Directory – Benutzer und Gruppen – AD-User korrekt anlegen und verwalten
• Active Directory Grundlagen – Aufbau und Objekte im lokalen Verzeichnisdienst
• Microsoft 365 – Benutzer und Lizenzen – Lizenzen zuweisen und verwalten
• Entra ID Grundlagen – Cloud-Identitaeten und Verzeichnisdienst in Microsoft 365
• Entra ID PIM und Governance – Privilegierte Rollen zeitlich befristet aktivieren und ueberwachen
• Intune – Grundlagen – Mobile Geraete und Endpoints per MDM verwalten
• IT-Dokumentation und Inventar – Asset-Register fuehren und Geraete nachverfolgen
• Passwoerter und Passphrasen – Sichere Passwoerter beim Onboarding vergeben
• Incident-Response-Plan fuer KMU – Vorgehen bei Sicherheitsvorfaellen strukturieren
• IT-Notfallplanung und Disaster Recovery – Organisatorischer Rahmen fuer Notfaelle

Weiterlernen

• Microsoft Learn – Lebenszyklus-Workflows in Entra ID (DE)
• Microsoft Learn – Entra ID Governance: Lizenzierung und Voraussetzungen
• Microsoft Learn – Benutzerkonten in M365 per PowerShell verwalten
• ComputerWeekly – M365-Onboarding per PowerShell optimieren (DE)
• ComputerWeekly – M365-Offboarding per PowerShell automatisieren (DE)
• Rencore – Microsoft 365 Offboarding Security Guide
• Microsoft Learn – Access Reviews Uebersicht (Was sind Access Reviews)
• Microsoft Learn – New-MgIdentityGovernanceAccessReviewDefinition
• Microsoft Tech Community – SCIM 2.0 APIs fuer Identity-Lifecycle-Operationen
• Microsoft Learn – SCIM-Unterstuetzung in Entra ID
• Microsoft Learn – Notfallzugriffskonten verwalten (Break-Glass)
• Microsoft Learn – Set-ADAccountExpiration
• Microsoft Learn – Benutzerzugriff im Notfall widerrufen (Revoke-MgUserSignInSession)