Claude Code × Microsoft 365 — wie KI unseren ersten Tenant-Audit verändert hat

Die Ausgangslage

Als MSP betreue ich mehrere Microsoft-365-Tenants. Die Realität sieht so aus: kleine Lizenzen, kein Entra ID Premium, kein Defender for Office 365. Die meisten Admin-Aufgaben laufen über das Browser-basierte Admin Center — Klick für Klick, Domain für Domain.

Die Frage war: Was passiert, wenn ich Claude Code nicht nur als Code-Assistenten nutze, sondern als interaktiven Audit-Partner, der direkt mit der M365-Infrastruktur kommuniziert?

Die Verbindung: PowerShell als Brücke

Claude Code läuft im Terminal. PowerShell 7 läuft im Terminal. Die Verbindung war naheliegend: Claude schreibt und führt PowerShell-Befehle aus, die sich über die Microsoft Graph API und Exchange Online Management Shell mit dem Tenant verbinden.

Technisch sieht das so aus:

Connect-MgGraph -Scopes @(
    "Organization.Read.All"
    "User.Read.All"
    "Group.Read.All"
    "Reports.Read.All"
    "Policy.Read.All"
    "Sites.Read.All"
) -NoWelcome

Connect-ExchangeOnline -Device

Ein wichtiges Detail für macOS-Nutzer: Die Standard-Browser-Authentifizierung von Exchange Online funktioniert auf macOS nicht. Der -Device Flag aktiviert den Device Code Flow — man bekommt einen Code im Terminal und autorisiert im Browser. Claude hat das nach dem ersten Fehler selbst erkannt und korrigiert.

Kein Premium nötig

Erster Fallstrick: Claude versuchte initial, SignInActivity abzufragen — ein Property, das Entra ID P1 voraussetzt. Der API-Fehler Authentication_RequestFromNonPremiumTenantOrB2CTenant war eindeutig. Ab diesem Punkt hat Claude alle Abfragen auf Scopes beschränkt, die mit Business Basic funktionieren.

Das ist eine Stärke des interaktiven Ansatzes: Die KI lernt die Einschränkungen des konkreten Tenants in Echtzeit und passt ihre Strategie an.

Session 1: Der Basis-Report

Die erste Session am 10. April dauerte etwa zwei Stunden. Claude hat 14 Bereiche inventarisiert und daraus einen HTML-Report im Dark-Dashboard-Design generiert:

Bereich	Ergebnis
Benutzer	13 Konten, 2 lizenziert, 0 Gäste
Lizenzen	3 SKUs (Business Basic, OneDrive Plan 2, Flow Free)
Domains	8 verifiziert
Speicher	33 TB SharePoint, 640 GB OneDrive, 34 GB Exchange
SharePoint Sites	16 Sites, davon 10 aktiv
Postfächer	11, größtes bei 68 % Auslastung
App Secrets	2 Apps, eines mit Ablauf in 57 Tagen
Security Defaults	Aktiviert, kein Conditional Access

Das Ergebnis: ein vollständiges Bild des Tenants — automatisch gesammelt, als JSON exportiert und als visueller HTML-Report aufbereitet. Alles Daten, die sonst über fünf verschiedene Admin-Center-Seiten verteilt sind.

Session 2: Der Security-Audit

Zwei Tage später, am 12. April, folgte der eigentliche Audit. Diesmal mit Fokus auf E-Mail-Sicherheit. Was Claude in der Exchange-Online-Umgebung gefunden hat, war ernüchternd:

Was Claude sofort gefixt hat

Drei Änderungen wurden direkt in der Session umgesetzt:

1. Audit Log aktiviert — ein einziger PowerShell-Befehl, der ab sofort alle Anmeldevorgänge protokolliert.
2. Anti-Spam verschärft — Phishing-Mails gehen jetzt in Quarantäne statt in den Junk-Ordner.
3. Externe-Mail-Warnung — eine Transport-Regel, die bei eingehenden externen Mails einen Warnhinweis voranstellt.

Alle drei Maßnahmen kosten nichts extra und sind in jeder Business-Basic-Lizenz enthalten.

DKIM: Sieben Domains, zwei Formate

Die DKIM-Aktivierung war der aufwändigste Teil. Für jede Domain mussten zwei CNAME-Records (selector1, selector2) im DNS hinterlegt und anschließend in Exchange Online aktiviert werden.

Dabei zeigte sich ein Detail, das in keiner Microsoft-Dokumentation prominent steht: Domains, die vor 2024 in M365 angelegt wurden, bekommen DKIM-Einträge im alten Format (*.onmicrosoft.com). Domains ab Mitte 2024 verwenden das neue Format (*.dkim.mail.microsoft). Claude hat beide Formate korrekt aus Get-DkimSigningConfig ausgelesen — hätten wir die CNAME-Werte manuell konstruiert, wäre die Hälfte der Domains fehlgeschlagen.

Ein Punkt, der anfangs übersehen wurde: Shared Mailboxes senden aktiv E-Mails. Deren Domains brauchen ebenfalls DKIM. Erst als wir die Shared-Mailbox-Liste durchgegangen sind, kamen drei weitere Domains dazu — easytry.de, itfuhrmann.de und kirstinbienek.de.

DMARC: Die richtige Strategie finden

Bei DMARC stand die Frage im Raum: Brauchen wir eine rua-Adresse für Aggregate-Reports? Die Bedenken waren berechtigt — ein dediziertes Postfach für DMARC-Reports kann selbst zum Spam-Ziel werden, und Cross-Domain-rua braucht Extra-DNS-Records.

Claude hat daraufhin die DMARC-Records großer Organisationen abgefragt. Das Ergebnis war aufschlussreich:

Domain	Policy	rua
google.com	reject	Eigene Adresse
microsoft.com	reject	Eigene Adresse
gmx.de	quarantine	Eigene Adresse
web.de	quarantine	Eigene Adresse
apple.com	quarantine	Externer Dienst

gmx.de und web.de — Deutschlands größte Freemail-Anbieter setzen beide auf p=quarantine mit aktiven Aggregate-Reports. Google und Microsoft gehen direkt auf p=reject. Das Muster ist klar: Wer eigene Reports auswertet, kann schneller hochstufen. Für einen kleinen Tenant ohne dediziertes Report-Monitoring ist der konservative Weg sinnvoller: v=DMARC1; p=none als Start für Mail-Domains, p=reject sofort für Domains ohne Mailversand. Die Hochstufung auf quarantine und später reject folgt schrittweise.

Die DNS-Migration: Wo die KI an ihre Grenzen stieß

Parallel zum Audit haben wir eine Domain von einem klassischen Hoster zu Cloudflare migriert. Claude sollte zunächst alle bestehenden DNS-Records erfassen — per externem Scan.

Das hat nicht funktioniert.

Der externe Scan über HackerTarget-API und Certificate-Transparency-Logs fand 26 von 32 Records. Sechs fehlten:

• IPv6-Records (AAAA) — wurden nicht systematisch gescannt
• Individuelle Subdomain-Namen wie vault-clone oder pdsm2 — nicht erratbar
• Records hinter Wildcard-Einträgen — von außen nicht sichtbar

Die Lektion war klar: Bei DNS-Migrationen immer den Zone-Export vom Provider verwenden. Externe Scans sind per Definition unvollständig. Erst nachdem ich die vollständige Record-Liste aus dem Provider-Panel exportiert hatte, konnten alle 33 Records korrekt in Cloudflare angelegt werden.

Claude hat diesen Fehler offen eingeräumt und die Methodik für alle folgenden Migrationen angepasst. Das ist der Vorteil eines interaktiven Workflows: Fehler werden sofort korrigiert und fließen in die nächste Iteration ein.

Cloudflare-Inventarisierung per API

Ein Nebeneffekt der Session: Claude hat über einen temporären Read-Only-API-Token alle zehn Cloudflare-Zonen inventarisiert. Dabei wurde eine Domain entdeckt, die M365-Records eines anderen Tenants enthielt — ein Detail, das beim manuellen Review leicht übersehen wird.

Alle API-Tokens wurden nach der Session gelöscht. Für den DNS-Write-Zugriff wurde ein separater Token mit eingeschränkten Berechtigungen erstellt — ein Pattern, das Claude selbst vorgeschlagen hat.

Was danach kam: Die Reporting-Suite

Aus den Ad-hoc-Abfragen der Audit-Sessions sind fünf eigenständige PowerShell-Skripte entstanden:

Skript	Funktion
Get-SPAccessStats	SharePoint-Zugriffsstatistiken über konfigurierbare Zeiträume
Get-SPArchivInventar	Archiv-Analyse großer SharePoint-Bibliotheken (getestet mit 21 TB)
Get-DMARCReadiness	DNS-Security-Check aller Domains auf SPF/DKIM/DMARC-Status
Get-SecretExpiry	Monitoring ablaufender App-Registration-Secrets
Get-SPHygieneAudit	Externe Freigaben, Versionierung, Speicherverschwendung

Jedes Skript folgt demselben Muster: Verbinden, Sammeln, Aggregieren, HTML-Report generieren. Alle Reports nutzen dasselbe Dark-Dashboard-Design mit KPI-Karten, farbcodierten Status-Badges und Print-CSS.

Was wir gelernt haben

Nach drei Sessions sind das die wichtigsten Erkenntnisse:

1. Business Basic reicht weiter als gedacht. Audit-Logging, DKIM, DMARC, Anti-Spam-Quarantäne, Transport-Regeln — alles kostenlos enthalten. Nur Impersonation-Schutz und Mailbox Intelligence brauchen Defender for Office 365 Plan 1.
2. Claude als Audit-Partner funktioniert. Nicht weil die KI alles weiß — der DNS-Scan-Fehler beweist das Gegenteil — sondern weil sie Fehler in Echtzeit korrigiert und den Kontext über eine lange Session hält.
3. Die Skripte sind das bleibende Ergebnis. Claude ist flüchtig, PowerShell-Skripte bleiben. Jedes Audit-Pattern, das sich bewährt, wird in ein wiederverwendbares Skript überführt.

Alle genannten Tools und Dienste sind selbst finanziert. Dieser Artikel enthält keine bezahlten Empfehlungen.