Skip to main content

Enterprise Server 3.20 ist derzeit als Release Candidate verfügbar.

Deaktivieren und Reaktivieren von Benutzern mit SCIM

Erfahre mehr über die Deprovisionierung oder Wiederherstellung von Benutzern.

Wer kann dieses Feature verwenden?

Enterprises that use Enterprise Managed Users, or GitHub Enterprise Server instances with SCIM enabled

Wenn du SCIM für Ihre GitHub Enterprise Server-Instance aktiviert hast, wirst du SCIM für folgende Zwecke nutzen:

  • Deprovisionieren von Benutzern und Gruppen, um ihren Zugriff zu entfernen.
  • Reaktivieren von zuvor deaktivierten Benutzern.

Bevor du einen Benutzer deaktivierst, ist es wichtig, die Auswirkungen der Deaktivierung nachzuvollziehen, die vom Typ des API-Aufrufs für die Deaktivierung abhängt, den GitHub von deinem Identitätsanbieter empfängt.

Wichtig

Stelle vor dem Fortfahren sicher, dass du verstehst, wie SCIM in deinem Unternehmen implementiert wurde. GitHub bietet eine Anwendung mit vorgefertigtem Pfad, wenn du für die Authentifizierung und Bereitstellung einen unterstützten Identitätsanbieter (IdP) verwendest. Wenn du keine Anwendung mit vorgefertigtem Pfad verwendest, verwende für SCIM-Anforderungen die REST-API. Weitere Informationen findest du unter Informationen zur Benutzerbereitstellung mit SCIM auf GitHub Enterprise Server.

Arten der Deaktivierung von Benutzern

Wenn ein Benutzer deprovisioniert wird, wird das GitHub Konto suspendiert, was bedeutet, dass der Benutzer keinen Zugriff auf Ihr Unternehmen hat. Unabhängig von der Art der DeProvisionierung wird ein deprovisioniertes Konto niemals aus dem Unternehmenssystem gelöscht.

Durch den Typ des Deaktivierungsaufrufs, den GitHub von deinem Identitätsanbieter empfängt, wird bestimmt, ob ein deaktivierte Benutzer entsperrt (reaktiviert) werden kann.

  •           **Soft-deprovision**: In bestimmten Szenarien kann der Benutzer über Ihre SCIM-Integration wieder freigeschaltet werden.
    
  •           **Hard-deprovision**: Es ist nicht möglich, die Suspendierung des Benutzers aufzuheben. Ein neues Konto muss bereitgestellt werden, wenn die Person wieder Zugriff benötigt.
    

Auswirkungen der Deaktivierung eines Benutzers

Wenn du ein Benutzerkonto über deinen IdP oder die REST-API deaktivierst, nimmt GitHub Änderungen an dem Benutzerkonto vor.

Auswirkungen der vorläufigen Deaktivierung

  • Der Benutzer wird gesperrt und verliert den Zugriff auf dein Unternehmen und alle privaten Ressourcen.
  • Nachdem das Benutzerkonto gesperrt wurde, wird es auf der Seite „Suspended members“ anstelle der Seite „Members“ im Abschnitt „People“ der Unternehmenseinstellungen aufgeführt.
  • Der **Benutzername des Benutzers wird ** zu einem Hash des ursprünglichen Benutzernamens.
  • Mit Entra ID bleibt die E-Mail-Adresse des Benutzers gleich. In allen weiteren Fällen wird die E-Mail des Benutzers verschleiert.
  • Die SCIM-Identität des Benutzers bleibt auf GitHub mit seinem Benutzerkonto verknüpft. Mit Entra ID wird der Wert des Attributwerts active in der gespeicherten verknüpften SCIM-Identität von True auf False aktualisiert.
  • Wenn der Benutzer über Forks privater oder interner Repositorys verfügt, werden die Forks innerhalb von 24 Stunden gelöscht. Die Forks werden wiederhergestellt, wenn der Benutzer innerhalb von 90 Tagen entsperrt wird.
  • Wenn der Benutzer Mitglied einer über SCIM bereitgestellten Identitätsanbietergruppe ist, wird er aus diesen Gruppen ausgeblendet und aus allen Teams entfernt, die diesen Gruppen zugeordnet sind. Beachte, dass dies auch dann geschieht, wenn der Benutzer weiterhin Mitglied der Gruppe auf der IdP-Seite ist.
  • Wenn die Organisationsmitgliedschaft durch Identitätsanbietergruppen verwaltet wird, wird der Benutzer aus Organisationen entfernt, wenn er aus diesen Identitätsanbietergruppen oder aus allen Teams entfernt wird, die Identitätsanbietergruppen in der Organisation zugeordnet sind.
  • Wenn die Organisationsmitgliedschaft direkt verwaltet wird, bleibt der Benutzer als „gesperrtes Mitglied“ in der Organisation ohne Zugriff, ** bis er manuell entfernt wird**.

Auswirkungen der schweren Deprovisionierung

  • Der Benutzer wird gesperrt und verliert den Zugriff auf dein Unternehmen und alle privaten Ressourcen.
  • Nachdem das Benutzerkonto gesperrt wurde, wird es auf der Seite „Suspended members“ anstelle der Seite „Members“ im Abschnitt „People“ der Unternehmenseinstellungen aufgeführt.
  • Der **Benutzername des Benutzers wird ** zu einem Hash des ursprünglichen Benutzernamens.
  • Die E-Mail-Adresse des Benutzers wird verschleiert.
  • Der Anzeigename des Benutzers wird auf eine leere Zeichenfolge festgelegt.
  • Die verknüpfte SCIM-Identität des Benutzers wird einschließlich aller SCIM-Attribute des Benutzers gelöscht.
  • Die personal access tokens, fine-grained personal access tokens, SSH-Schlüssel, GPG-Schlüssel und Anwendungsautorisierungen des Benutzers werden gelöscht. Das Löschen von Schlüsseln kann sich auf die Überprüfung von Commits auswirken. Weitere Informationen findest du unter Informationen zur Verifizierung einer Commit-Signatur.
  • Repositorys im Besitz eines Benutzers werden gelöscht.
  • Vom Benutzer erstellte Ressourcen wie Kommentare werden beibehalten.
  • Wenn der Benutzer Mitglied einer über SCIM bereitgestellten Identitätsanbietergruppe ist, wird er aus diesen Gruppen ausgeblendet und aus allen Teams entfernt, die diesen Gruppen zugeordnet sind. Beachte, dass dies auch dann geschieht, wenn der Benutzer weiterhin Mitglied der Gruppe auf der IdP-Seite ist.
  • Wenn die Organisationsmitgliedschaft durch Identitätsanbietergruppen verwaltet wird, wird der Benutzer aus Organisationen entfernt, wenn er aus diesen Identitätsanbietergruppen oder aus allen Teams entfernt wird, die Identitätsanbietergruppen in der Organisation zugeordnet sind.
  • Wenn die Organisationsmitgliedschaft direkt verwaltet wird, bleibt der Benutzer als „gesperrtes Mitglied“ in der Organisation ohne Zugriff, ** bis er manuell entfernt wird**.

Aktionen, die eine Deprovisionierung auslösen

Verschiedene Aktionen lösen die vorläufige und endgültige Deprovisionierung aus, und die Auslöser variieren je nach SCIM-Integration. In der Regel lösen die meisten Aktionen, die du in den "paved-path" IdP-Anwendungen ausführst, lediglich eine weiche Deprovisionierung aus, mit einigen Ausnahmen.

Auslöser für eine weiche Deaktivierung

SCIM-IntegrationAuslöser für eine weiche Deaktivierung
REST-APIEine PUT- oder PATCH-Anforderung wird an /scim/v2/Users/{scim_user_id} gesendet, wodurch das Feld active eines Benutzers auf false aktualisiert wird.
Entra IDEin Benutzer ist in Entra ID deaktiviert, seine Zuweisung zur Anwendung wurde aufgehoben, sie wurde aus allen zugewiesenen Gruppen entfernt oder durch die Administration vorläufig aus dem Mandanten gelöscht. Weitere Informationen findest du in der Microsoft-Dokumentation unter Vorläufige Löschungen.
OktaDie Zuweisung eines Benutzers zur Anwendung wird aufgehoben, oder der Benutzer wird aus allen zugewiesenen Gruppen entfernt oder mit der Schaltfläche „Deactivate“ deaktiviert. Beachte, dass die Schaltfläche „Suspend“ keine Anforderung an GitHub sendet. Okta sendet lediglich Aufrufe für weiche Deaktivierungen.
PingFederateDer Benutzer wird gesperrt, deaktiviert oder aus dem Benutzerspeicher entfernt, der vom Bereitstellungsdienst angesprochen wird.

Auslöser für harte Deaktivierungen

SCIM-IntegrationAuslöser für harte Deaktivierungen
REST-APIEine DELETE-Anforderung wird an /scim/v2/Users/{scim_user_id} gesendet.
Entra IDDie endgültige Löschung eines Entra ID-Benutzerkontos, wie in der Microsoft-Dokumentation unter Endgültige Löschungen beschrieben. Entra ID-Benutzer, die vorläufig gelöscht werden (auf der Seite „Benutzer > Gelöschte Benutzer“ des Entra ID-Verwaltungsportals) werden 30 Tage nach dem vorläufigen Löschen durch Entra ID automatisch endgültig gelöscht.
OktaN/V. Okta sendet keine Aufrufe für harte Deaktivierungen.
PingFederateWenn die Einstellung „Benutzeraktion entfernen“ durch eine Fehlkonfiguration auf „Löschen“ anstelle von „Deaktivieren“ festgelegt ist, wird durch diese Aktion ein Aufruf zu einer harten Deaktivierung ausgelöst. Weitere Informationen findest du in der PingIdentity-Dokumentation.

Reaktivieren eines vorläufig deaktivierten Benutzerkontos

Um die Zugriffs- und Kontodetails des Benutzers wiederherzustellen, können Sie das Konto eines Benutzers, der soft-deprovisioniert wurde, wiederherstellen, solange das IdP-Benutzerkonto dasselbe ist. Das IdP-Benutzerkonto muss dasselbe bleiben, da ein soft-deprovisioniertes Benutzerkonto weiterhin mit dieser externen Identität verknüpft ist, basierend auf der SCIM external ID (IdP-Benutzerobjekt-ID) und SCIM User ID. Die externe Identität, die mit einem einzelnen weich deaktivierten Benutzerkonto verknüpft ist, kann nicht geändert werden.

Auswirkungen der Reaktivierung

  • Der Benutzer ist entsperrt und erhält wieder Zugriff auf dein Unternehmen.
  • Der Benutzername und die E-Mail-Adresse des Benutzers werden wiederhergestellt.
  • Wenn der Benutzer Mitglied einer durch SCIM bereitgestellten Identitätsanbietergruppe ist, die einem Team in einer Organisation zugeordnet ist, wird der Benutzer unmittelbar nach der Reaktivierung seines Benutzerkontos zur Organisation hinzugefügt. Wenn er zuvor Mitglied der Organisation war, wird seine Mitgliedschaft reaktiviert, solang seit der Entfernung nicht mehr als 90 Tage vergangen sind. Weitere Informationen findest du unter Reaktivieren eines ehemaligen Mitglieds deiner Organisation.
  • Wenn der Benutzer kein Mitglied einer durch SCIM bereitgestellten Identitätsanbietergruppe ist, die einem Team in einer Organisation zugeordnet ist, muss ein GitHub-Organisationsinhaber das Benutzerkonto manuell zur Organisation hinzufügen, nachdem es erneut bereitgestellt wurde.
  • Gelöschte Forks werden wiederhergestellt, wenn der Benutzer innerhalb von bis zu 90 Tagen nach der Sperrung entsperrt wird.
  • Dem Benutzer zugeordnete Elemente werden einschließlich der folgenden Elemente wiederhergestellt:
    • GitHub Apps, OAuth apps und App-Autorisierung
    • Personal access tokens
    • SSH-Schlüssel
    • Token- und Schlüsselautorisierungen
    • Repositorys im Besitz von Benutzern

Aktionen, die eine Reaktivierung auslösen

Wie du einen Benutzer neu bereitstellst, hängt von deiner SCIM-Integration und der Aktion ab, die die weiche Deaktivierung ausgelöst hat.

SCIM-ImplementierungAktionen zur Reaktivierung von Benutzern
Entra IDDu kannst ein deaktiviertes Konto reaktivieren oder einen Benutzer direkt oder über eine zugewiesene Gruppe der Anwendung neu zuweisen. Warte 40 Minuten, bis die Änderungen verarbeitet wurden, oder beschleunige den Vorgang mit die Schaltfläche „Provision on Demand“.
OktaReaktiviere das Konto, oder weise den Benutzer der Anwendung direkt oder über eine Gruppe neu zu.
PingFederateEntsperre oder reaktiviere den Benutzer in der Benutzerdatenbank, oder füge den Benutzer erneut der Datenspeichergruppe oder dem Filter hinzu, auf die die Bereitstellungsinstanz ausgerichtet ist.
REST-APISende eine PUT- oder PATCH-Anforderung an /scim/v2/Users/{scim_user_id}, und aktualisiere das Feld active des Benutzers auf true.

Reaktivieren eines hart deaktivierten Benutzerkontos

Sie können ein GitHub Benutzerkonto nicht wiederherstellen, das über SCIM hart-deprovisioniert wurde. Stattdessen musst du ein neues GitHub-Konto für den Benutzer bereitstellen.

Du kannst den Benutzernamen des hart deaktivierten Benutzers beim Bereitstellen des neuen Kontos wiederverwenden. Es ist jedoch nicht möglich, das hart deaktivierte Benutzerkonto mit dem neuen Benutzerkonto auf GitHub zusammenzuführen.

  • Wenn die E-Mail-Adressen des hart-deprovisionierten Benutzers und des neuen Benutzers übereinstimmen, ordnet GitHub vorhandene Git-Commits, die der E-Mail-Adresse zugeordnet sind, dem neuen Benutzer zu.
  • Vorhandene Ressourcen und Kommentare, die vom ursprünglichen Benutzer erstellt wurden, werden nicht dem neuen Benutzer zugeordnet.

Überwachungsprotokollereignisse

Das Überwachungsprotokoll für Ihr Unternehmen zeigt Details zu Aktivitäten in Ihrem Unternehmen an. Sie können das Überwachungsprotokoll verwenden, um Ihre Konfiguration von SCIM zu unterstützen. Weitere Informationen finden Sie unter Überwachungsprotokoll für ein Unternehmen.

Wichtig

Es wird dringend empfohlen, dass ein Unternehmensbesitzer Unternehmensüberwachungsprotokollfeatures wie Überwachungsprotokollstreaming, Offenlegung der Quell-IP und die Option zum Streamen von API-Anforderungen ermöglicht. Wenn du diese Ereignisse streamst, kann die Administration eine Protokollaufbewahrungsrichtlinie festlegen, die den Anforderungen ihres Unternehmens entspricht, und ihre bevorzugten Tools zum Abfragen dieser Protokolle verwenden.

Ereignisse für die weiche Deaktivierung

Wenn Sie die Bereitstellung eines Benutzers vorläufig aufheben, wird das Ereignis external_identity.update nicht im Überwachungsprotokoll angezeigt. Die folgenden Ereignisse werden im Überwachungsprotokoll angezeigt:

  • user.suspend
  • user.remove_email
  • user.rename
  • external_identity.deprovision
  • Wenn die Anforderung erfolgreich war, external_identity.scim_api_success
  • Wenn die Anforderung fehlschlägt, external_identity.scim_api_failure
  • Wenn der Benutzer Mitglied von IdP-Gruppen ist, die mit Teams verknüpft sind: team.remove_member
  • Wenn die Mitgliedschaft eines Benutzers in einer Organisation durch den Identitätsanbieter verwaltet wird und sie aus allen Teams entfernt wird, die Identitätsanbietergruppen in der Organisation zugeordnet sind: org.remove_member

Ereignisse für die harte Deaktivierung

  • external_identity.deprovision
  • user.remove_email
  • Wenn die Anforderung erfolgreich war, external_identity.scim_api_success
  • Wenn die Anforderung fehlschlägt, external_identity.scim_api_failure
  • Wenn der Benutzer Mitglied einer IdP-Gruppe ist, die den Teams zugeordnet ist, team.remove_member
  • Wenn die Mitgliedschaft eines Benutzers in einer Organisation durch den Identitätsanbieter verwaltet wird und sie aus allen Teams entfernt wird, die Identitätsanbietergruppen in der Organisation zugeordnet sind: org.remove_member

Ereignisse für die Reaktivierung

Wenn Sie einen Benutzer reaktivieren, wird das external_identity.update-Ereignis nicht im Überwachungsprotokoll angezeigt. Die folgenden Ereignisse werden im Überwachungsprotokoll angezeigt:

  • user.unsuspend
  • user.remove_email
  • user.rename
  • external_identity.provision
  • Wenn die Anforderung erfolgreich war, external_identity.scim_api_success
  • Wenn die Anforderung fehlschlägt, external_identity.scim_api_failure
  • Wenn der Benutzer Mitglied einer durch SCIM bereitgestellten Identitätsanbietergruppe ist und diese Gruppe einem Team in einer Organisation zugeordnet ist: org.add_member

Weiterführende Lektüre

  •         [AUTOTITLE](/admin/managing-iam/provisioning-user-accounts-with-scim/provisioning-users-and-groups-with-scim-using-the-rest-api)