Skip to main content

Identität & Zugriff

Der Bereich Benutzer & Zugriff liest Ihre Microsoft Entra ID live aus. Er hat vier Seiten: Alle Leserollen sehen die Auswertungen; Aktionen und die Karte Privilegierte Zugänge sind Portal-Admins vorbehalten. Aktionen, die Ihren Tenant ändern, brauchen die Freigabe eines zweiten Portal-Admins im Approval Center — ausgenommen die Sofortaktionen an einzelnen Konten (sperren, entsperren, Passwortwechsel erzwingen, Sitzungen beenden, Temporary Access Pass), die ein Portal-Admin mit Begründung selbst ausführt (siehe Abschnitt 6).

1. Kennzahlen

Oben im Bereich: Anzahl der Benutzer, Gruppen, Gastbenutzer, App-Registrierungen, Service Principals, Admins, aktiven Conditional-Access-Richtlinien und Risiko-Benutzer. Geteilte Postfächer, Raum- und Ressourcenpostfächer erscheinen in Microsoft Entra ID als Benutzerkonten. Das Portal zählt sie nicht als Benutzer (Hinweis „ohne N Postfächer“) und zeigt sie nicht unter den gesperrten Konten.

2. MFA und Anmeldungen

  • MFA-Abdeckung: Anteil der aktiven Konten mit registrierter Multi-Faktor-Authentifizierung und die Liste der Konten ohne MFA. Gesperrte Konten und geteilte Postfächer zählen nicht mit, weil sich mit ihnen niemand anmelden kann. „MFA-Rollout beauftragen“ erzeugt ein Ticket mit den betroffenen Benutzern.
  • Anmeldeaktivität (24 h): Anmeldungen gesamt, fehlgeschlagene und riskante Anmeldungen.
  • Inaktive Konten: Konten ohne Anmeldung über längere Zeit oder nie angemeldet. Inaktive Konten vergrößern die Angriffsfläche; „Bereinigung beauftragen“ erzeugt ein Ticket, Portal-Admins können einzelne Konten sofort sperren (mit Begründung).
  • Verifizierte Domains Ihres Tenants.

3. Zugriffsschutz (Conditional Access)

Conditional Access sind die Zugriffsregeln Ihres Microsoft-Kontos: Wer darf sich wann, von wo und mit welchem Nachweis anmelden? twisb betreut dafür einen einheitlichen Zugriffsschutz-Standard (aktuell Version 1.0) mit Regeln für alle Konten, Administratoren, Mitarbeitende, Dienstkonten und Gäste. Welche Regeln für Ihr Unternehmen gelten, legt twisb mit Ihnen fest — abhängig von Ihren Lizenzen und Ihrer Umgebung. Die Karte Zugriffsschutz zeigt, wie weit dieser Standard bei Ihnen umgesetzt ist.

Was die Karte zeigt

  • Kopfzeile: etwa „Ihr Zugriffsschutz: 18 von 23 Regeln aktiv · 3 im Testbetrieb · 2 fehlen“, dazu der Stand (live oder Stand der letzten Nachtprüfung).
  • Grundschutz: Vier Regeln sind Pflicht — zweiter Faktor für alle Anmeldungen, veraltete Anmeldeverfahren sperren, phishingsichere Anmeldung für Administratoren und verdächtige Anmeldungen sperren. Fehlt eine davon, steht das rot in der Karte. Eine Pflichtregel, die für Ihr Unternehmen abgewählt ist, zählt weiter als offen („Pflicht, nicht ausgewählt“), bis mit twisb eine Ausnahme vereinbart ist.
  • Je Regel ein Bullauge als schneller Überblick, darunter die Regeln nach Personengruppen (Alle Konten, Administratoren, Mitarbeitende, Dienstkonten, Gäste). Gruppen mit Lücken sind aufgeklappt. Jede Regel nennt in einem Satz, was sie schützt, seit wann sie ihren Zustand hat und — wenn jemand sie geändert hat — wann und von wem (Administrator bei Ihnen oder twisb; die Anmeldung der Person sehen nur Portal-Admins).
  • Weitere Richtlinien Ihres Unternehmens: Regeln, die Ihr Unternehmen selbst angelegt hat, stehen getrennt darunter. twisb ändert sie nicht.

Was die Zustände bedeuten

Bewusst anders eingestellt heißt: Die Abweichung ist mit twisb vereinbart und wird nicht als Fehler gewertet.

Was Portal-Admins tun können

Portal-Admins stellen Anträge direkt in der Karte. Jeder Antrag braucht die Freigabe eines zweiten Portal-Admins im Approval Center (im Ein-Admin-Modus können Sie selbst freigeben) und wird genau so ausgeführt, wie er beantragt wurde.
1

Standard einrichten (Testbetrieb)

Legt die fehlenden Regeln an — immer nur im Testbetrieb, sie blockieren also noch niemanden. Ihr Notfallzugang ist in jeder Regel ausgenommen.
2

Testbetrieb auswerten

Mindestens 7 Tage lang protokollieren die Regeln, was sie tun würden. Beim Scharfschalten sehen Sie die Summe, z. B. „In den letzten 7 Tagen wären 3 Anmeldungen blockiert worden (2 Personen)“ — ohne Namen.
3

Scharf schalten …

Wählen Sie die Regeln, die mindestens 7 Tage im Testbetrieb liefen, und bestätigen Sie „Ich habe das Ergebnis des Testbetriebs geprüft.“ Regeln für Administratoren folgen zuletzt und erst nach einer zusätzlichen Prüfung durch twisb.
  • Notbremse: Schaltet die gewählten aktiven Regeln sofort zurück in den Testbetrieb. Sie schützen dann nicht mehr, sperren aber auch niemanden aus. Die Notbremse hat keine weiteren Voraussetzungen.
  • Regel weicht ab: Mit „twisb um Prüfung bitten“ entsteht ein Ticket. twisb setzt die Regel dann auf den Standard zurück oder übernimmt Ihre Einstellung als bewusste Abweichung — beides nur nach Absprache, im Portal selbst gibt es dafür keinen Knopf.
  • Noch kein Standard festgelegt: Die Karte sagt das; mit „Einrichtung anfragen“ entsteht ein Ticket.
Aussperr-Schutz: Scharf geschaltet wird nur, wenn ein Notfallzugang (Break-Glass) hinterlegt ist, mindestens ein Konto enthält und in jeder Regel ausgenommen ist. Sind bei Ihnen die Microsoft-Sicherheitsstandards (Security Defaults) eingeschaltet, stimmt twisb den Wechsel vorher mit Ihnen ab. Antwortet Microsoft unklar (Zeitüberschreitung, Drosselung), wird nichts wiederholt; der Antrag endet als „unklar“, und twisb prüft den Stand.

Neue Versionen des Standards

twisb entwickelt den Zugriffsschutz-Standard weiter. Eine neue Version kommt nicht auf einmal zu allen Kunden, sondern in Stufen: erst bei twisb selbst, dann bei Pilotkunden, danach bei allen übrigen. Steht ein Update für Sie an, zeigt die Karte oben eine Zeile:
  • „Update auf Version 1.1 geplant“ — twisb führt die neue Version bei Ihnen demnächst ein.
  • „Update auf Version 1.1 läuft“ — die Anträge sind gestellt oder ausgeführt, twisb beobachtet die Wirkung.
  • „Version 1.1 seit 14.11. aktiv“ — das Update ist abgeschlossen (die Zeile bleibt 30 Tage stehen).
Mit „Was ändert sich?“ klappen Sie die Änderungen der neuen Version in einfachen Sätzen auf.
  • Zustand bleibt: Aktive Regeln bleiben aktiv, Regeln im Testbetrieb bleiben im Testbetrieb. Neue Regeln starten im Testbetrieb.
  • Strengere Fassung zuerst im Test: Wird eine aktive Regel strenger, läuft die neue Fassung zunächst als Testkopie im Testbetrieb neben der bisherigen Regel. Erst nach mindestens 7 Tagen Auswertung beantragt twisb, sie durchzusetzen; dabei wird die Testkopie entfernt.
  • Entfallene Regeln: Eine Regel, die es in der neuen Version nicht mehr gibt, wird ausgeschaltet, nicht gelöscht.
  • Ihre Freigabe: Jeden Schritt stellt twisb als Antrag. Sie geben ihn im Approval Center frei — vorher ändert sich nichts. Ist für Sie „Verwaltet durch twisb“ eingeschaltet, gibt ein zweiter twisb-Administrator frei, und Sie sehen jeden Schritt im Approval Center.
Im Portal gibt es für Updates keinen eigenen Knopf; Fragen dazu stellen Sie per Ticket.
Viewer und Asset-Manager sehen die Karte ohne Antragsknöpfe; Rückfragen per Ticket sind mit Ticket-Recht möglich. Diese Karte ist die einzige Detailansicht des Zugriffsschutzes; „Unser Standard“ unter Sicherheit › Sicherheitslage zeigt dazu nur eine Zusammenfassungszeile mit Link hierher. Secure-Score-Empfehlungen, die der Zugriffsschutz abdeckt (z. B. MFA, alte Anmeldeverfahren, Risiko-Richtlinien), tragen dort den Hinweis „Abgedeckt durch Zugriffsschutz“. Die früheren einzelnen Vorlagen nach Chronlund lassen sich nicht mehr beantragen; offene Altanträge können im Approval Center nur noch abgelehnt oder zurückgezogen werden.

4. Risiko-Benutzer und Risiko-Erkennungen

Aus Entra ID Protection (erfordert Entra ID P2):
  • Risiko-Benutzer mit Risikostufe (hoch, mittel, niedrig) und Direktlink in das Entra Admin Center. Für Benutzer mit hohem Risiko können Portal-Admins einen Passwortwechsel mit MFA erzwingen — als Sofortaktion mit Begründung.
  • Risiko-Erkennungen wie ungewöhnliche Anmeldeorte oder kompromittierte Zugangsdaten.
  • „Untersuchen lassen“ erzeugt ein Ticket für das twisb-Team.

5. Privilegierte Zugänge (nur Portal-Admins)

Die Karte fasst zusammen, wer in Ihrem Tenant besonders viel darf: Fehlt eine optionale Berechtigung, zeigt der betroffene Block „Zustimmung ausstehend“ — der Rest funktioniert weiter. Details: Microsoft-Berechtigungen. Wer eine Rolle nur über PIM für Gruppen bekommen kann (berechtigtes, noch nicht aktiviertes Mitglied einer Admin-Rollen-Gruppe), ist mit „über PIM berechtigt“ markiert. Solche Personen zählen nicht als aktive Admins.

Admin-Rollen entfernen

Portal-Admins können einer Person eine Admin-Rolle wieder wegnehmen — als Antrag, den ein zweiter Portal-Admin im Approval Center freigibt (im Ein-Admin-Modus geben Sie selbst frei). Einstiege:
  • In der Karte Privilegierte Zugänge der Knopf Entfernen an einer Rolle bzw. Aus Gruppe entfernen … an einer Person, die ihre Rollen über eine Gruppe bekommt.
  • Im Mitarbeiterverzeichnis über das Menü „⋮“ → Admin-Rollen …: zeigt alle Admin-Rollen dieser Person mit Entfernen.
  • Im Offboarding-Antrag, wenn er wegen einer Admin-Rolle abgelehnt wird: Link Admin-Rollen entfernen.
Entfernt werden können direkt vergebene Rollen (dauerhaft, befristet oder per PIM aktiviert), über PIM nur berechtigte Rollen und Rollen über eine Admin-Rollen-Gruppe (rollenzuweisbare Gruppe, auch über PIM für Gruppen). Bei einer Gruppe wird nur diese Person aus der Gruppe genommen; die übrigen Mitglieder bleiben unberührt. Die Person verliert dabei alle Rollen, die diese Gruppe vergibt — der Dialog listet sie vorher auf, und Sie bestätigen das ausdrücklich.
  • Begründung ist Pflicht (5–500 Zeichen). Sie steht im Antrag, im Audit-Log und im Änderungsticket.
  • Aktivierte PIM-Rolle oder aktivierte PIM-Mitgliedschaft in einer Gruppe: Die Aktivierung endet; eine daneben bestehende Berechtigung bleibt und lässt sich getrennt entfernen (Eintrag „über PIM berechtigt“). Der Antrag weist Sie darauf hin.
  • Ohne Microsoft-Anmeldung der Freigebenden: Rollen, die ohne Privileged Identity Management (PIM) vergeben sind, und feste Mitgliedschaften in Admin-Rollen-Gruppen entfernt das Portal nur, wenn die freigebende Person sich mit ihrer eigenen Microsoft-Anmeldung bestätigt (Entra-Rolle „Privileged Role Administrator“). Ist diese Anmeldung bei Ihnen nicht eingeschaltet, nennt der Antrag das, und Sie entfernen die Rolle in Microsoft Entra. Hintergrund: Der App-Zugriff des Portals darf Rollen bewusst nur entfernen, nie vergeben.
  • Grenzen zum Schutz: Ihre eigene Rolle können Sie so nicht entfernen. Notfallkonten (Break-Glass) behalten ihre Rollen. Der letzte aktive Globale Administrator bleibt immer erhalten — nur berechtigte oder gesperrte Konten zählen dabei nicht als verbleibend. Lässt sich das gerade nicht sicher prüfen, nimmt das Portal keinen Antrag an.
  • Verschachtelte Gruppen und lokal synchronisierte Gruppen: Ist die Person nur über eine weitere Gruppe Mitglied oder kommt die Gruppe aus Ihrem lokalen Active Directory, ändern Sie die Mitgliedschaft dort.
  • Microsoft-Berechtigung: Ist die Microsoft-Verifizierung der Freigebenden eingerichtet, braucht die freigebende Person die Entra-Rolle Privileged Role Administrator. Sonst braucht das Portal die zusätzlichen Berechtigungen aus Microsoft-Berechtigungen; fehlen sie, lehnt es den Antrag mit dem Hinweis „Microsoft-Zustimmung erneuern“ ab.
  • Unklares Ergebnis: Antwortet Microsoft nicht eindeutig, wird nichts wiederholt. Prüfen Sie den Stand dann im Entra Admin Center.

6. Mitarbeiterverzeichnis

Durchsuchbares Verzeichnis aller Benutzer mit Rolle, Abteilung, MFA-Status und letzter Anmeldung, filterbar nach Abteilung und MFA. Je Person können Sie direkt ein Ticket anlegen; Portal-Admins können das Offboarding beantragen und über das Menü „⋮“ Sofortaktionen ausführen.

Sofortaktionen

Wenn es schnell gehen muss — etwa bei einem verdächtigen Konto —, führt ein Portal-Admin diese Aktionen sofort und ohne zweiten Admin aus: So läuft eine Sofortaktion ab:
  • Begründung ist Pflicht (mindestens 5, höchstens 500 Zeichen). Beim Sperren bestätigen Sie zusätzlich, dass sich die Person danach nicht mehr anmelden kann.
  • Nachvollziehbar: Begründung und Ergebnis stehen im Audit-Log und in einem Änderungsticket („Sofortaktion ohne Zweitfreigabe“). Die anderen Portal-Admins erhalten eine kurze Info in der Glocke — ohne Namen und ohne Begründung. Im Approval Center erscheint die Ausführung mit dem Hinweis Sofortaktion, ohne Freigabe-Knöpfe.
  • Grenzen zum Schutz: Ihr eigenes Konto können Sie so nicht sperren, abmelden oder mit einem Zugangscode versehen. Notfallkonten (Break-Glass) lassen sich nicht sperren oder zurücksetzen. Für Administratorkonten wird kein Zugangscode ausgestellt. Höchstens 20 Sofortaktionen je Stunde für Ihr Unternehmen.
  • Unklares Ergebnis: Antwortet Microsoft nicht eindeutig, wird nichts wiederholt. Prüfen Sie den Stand dann im Entra Admin Center.
Temporary Access Pass: Sie wählen die Gültigkeit (60, 120 oder 480 Minuten, soweit Ihre Microsoft-Richtlinie das erlaubt) und ob der Code nur einmal nutzbar ist. Der Code wird nur Ihnen und nur einmal angezeigt und nirgends gespeichert — geben Sie ihn auf sicherem Weg weiter. Hat das Konto schon einen gültigen Code, stellt das Portal keinen neuen aus. Voraussetzung: Temporary Access Pass ist in Ihrem Tenant eingeschaltet und gilt für das Konto, und die Microsoft-Berechtigung dafür ist erteilt (Microsoft-Berechtigungen).

Mitarbeiter ausscheiden (Offboarding)

Ein Portal-Admin wählt im Verzeichnis Mitarbeiter ausscheiden und stellt einen Antrag mit Begründung. Wählbare Schritte: Ein zweiter Portal-Admin gibt den Antrag frei und führt ihn damit aus. Schritte, die nicht vollständig gelingen, landen als Aufgabe im Ticket.
Schutzregeln: Das eigene Konto lässt sich so nicht ausscheiden. Hat die Person eine Entra-Admin-Rolle (auch über eine rollenzuweisbare Gruppe), lehnt das Portal den Antrag ab. Der Dialog bietet dann Admin-Rollen entfernen an (Admin-Rollen entfernen); ist das freigegeben, beantragen Sie das Offboarding erneut.

Eigenschaften mehrerer Benutzer ändern

Portal-Admins können im Verzeichnis mehrere Personen ankreuzen und Eigenschaften ändern wählen. Änderbar sind Abteilung, Position, Büro, Firma, Ort und Vorgesetzter — je Feld „unverändert“, „setzen“ oder „leeren“, für bis zu 50 Personen auf einmal. Vor dem Absenden zeigt die Vorschau:
  • Personen, deren Konto aus Ihrem lokalen Active Directory synchronisiert wird — diese ändern Sie dort, sonst überschreibt der nächste Abgleich die Änderung;
  • Personen, bei denen sich nichts ändern würde;
  • dynamische Gruppen, deren Regel eine der geänderten Eigenschaften auswertet. Ihre Mitglieder können sich dadurch ändern — und mit ihnen Lizenzen, Zugriffsregeln oder Geräte-Zuweisungen.
Ein zweiter Portal-Admin gibt den Antrag frei. Wurde eine Person seit dem Antrag anderweitig geändert, wird sie übersprungen; die übrigen werden geändert.

7. Gruppen anlegen

In der Karte Gruppen legen Portal-Admins eine neue Sicherheitsgruppe an:
  • fest zugewiesen — die Gruppe startet leer;
  • dynamisch — Microsoft Entra ermittelt die Mitglieder selbst nach einer Regel, zum Beispiel user.department -eq "Vertrieb". Dafür ist Microsoft Entra ID P1 nötig (z. B. in Microsoft 365 Business Premium enthalten). Mit Regel prüfen sehen Sie vorab, ob Microsoft die Regel annimmt.
Regeln dürfen nur Merkmale wie Abteilung, Position, Firma, Büro, Ort, Land, Kontotyp oder Geräteeigenschaften nutzen — keine Namen, Anmeldenamen oder E-Mail-Adressen. Eine neue Gruppe wirkt erst, wenn sie irgendwo zugewiesen wird. Auch hier gibt ein zweiter Portal-Admin frei.
Sie können den KI-Begleiter bitten, eine Gruppe oder eine Änderung vorzubereiten („Lege eine dynamische Gruppe für alle aus dem Vertrieb an“, „Setze bei allen aus dem Einkauf Frau Schmidt als Vorgesetzte“). Er sucht die passenden Personen, prüft die Regel und öffnet den ausgefüllten Antrag — abschicken und freigeben bleibt bei Ihnen.

8. Identitäts-Aktionen im Überblick