Der Zugriff für Gäste wird von Microsoft standardmässig mit einer limitierten Berechtigung konfiguriert. In dieser Konfiguration könnten Gäste Informationen über interne Benutzerkonten auswerten.
Wird ein neuer M365 Tenant erstellt konfiguriert Microsoft in Azure AD bei External Collaboration Settings standardmässig diese Konfiguration für externe Konten.
Was die Konfiguration bewirkt hat Daniel Chronlund in seinem Beitrag gut beschrieben. Da ich es in meinen Testtenants nachstellen wollte probierte ich es aus.
- In meinem Konto wird mir unter Organisationen angezeigt mein Konto ist Gast in meinem TAM365 Demo Tenant.
- Für den Zugriff auf den externen Tenant ist die Tenant ID erforderlich. Die Frage ist wie ich die ID des externen Tenants erhalte? Es gibt mehrere Wege, eine Google Suche hilft. Ein einfacher Weg ist über Teams. Bist du Mitglied in einem Team der externen Organisation wählst du den Link zum Team zu kopieren.
In dem Link ist die Tenant ID inkludiert.
- Jetzt ist das PowerShell Modul für Azure AD erforderlich.
- Jedes Gastkonto kann sich in der Standardkonfiguration per PowerShell in externen Tenants über die eigenen Anmeldedaten anmelden. Ich verbinde mich über Connect-AzureAD und der Tenant ID zum externen Tenant. Die Verbindung wird erfolgreich hergestellt.
- Es ist nicht möglich initial alle Benutzerkonten abzurufen. Der externe Tenant verweigert die Abfrage. Aber ich arbeite über meinen Kontakt Tanja Korsio mit dem Unternehmen zusammen. Also setze ich gezielt eine Abfrage für ihr Konto ab. Da der UserPrincipalName bekannt sein muss kann es teils ein Probieren sein. Oft ist die Emailadresse der UPN, manchmal nicht.
- In der limitierten Standardkonfiguration liefert PowerShell nur einen Teil von Daten des Kontos zurück. Interessanter ist die Möglichkeit als Gast abzufragen in welchen Gruppen Tanja Mitglied ist. Der externe Tenant liefert alle Arten von Gruppen zurück (mit Ausnahme von versteckten Gruppen). Wird der externe Tenant über AD Sync mit einem On-prem AD gesynct sind auch diese Gruppen inkludiert.
- Über die ObjectId der Gruppe ist es mir nun möglich alle Mitglieder der Gruppe aufzulisten. An meinem Beispiel ist der Vermerk über alle Mitarbeiter sehr praktisch, oder zu wissen welche Gruppen sich mit welchen Themen beschäftigen. Gruppenbeschreibungen können nützlich sein. So kann ich gezielt Mitglieder der Gruppe auflisten und kenne als externe Person welche internen Konten es gibt und könnte die Daten exportieren. Eine Ausgangslage um mich für eine bösartige Attacke vorzubereiten.
An meinem zuvor durchgeführten Beispiel, wie sieht es mit der Azure AD Konfiguration “most restrictive” aus?
- Es ist mir als Gast weiterhin möglich mich über PowerShell mit dem externen Tenant zu verbinden.
- Die Abfrage über das Konto von Tanja Korsio wird verweigert.
- Ebenfalls nicht mehr möglich ist als Gast Mitglieder der Gruppen aufzulisten.
Bevor die Konfiguration in Azure AD auf “most restrictive” angepasst wird sollte man sich mit Nebenwirkungen beschäftigen.
Soll der Zugriff für externe Personen über PowerShell unterbunden werden kann eine Conditional Access Policy helfen. In den Baselines von Daniel Chronlund gibt es zur Konfiguration hilfreiche Tipps. Für Conditional Access Policies ist Azure AD Premium erforderlich.
 |  |
Ist die Policy aktiv wird mir als externe Person signalisiert ich sei über PowerShell nicht mehr zur Anmeldung berechtigt.
In den Sign-in Logs von Azure AD werden die Anmeldungen für das externe Konto protokolliert. Als ich die Conditional Access Policy aktivierte ist die Anmeldung fehlerhaft.
Als letzter Vergleich noch die Azure AD Konfiguration “most inclusive”, ohne der Conditional Access Policy.
Ein Gast hat mit seinem externen Konto, ähnlich wie interne Personen, Lesezugriff auf alle Properties des internen Kontos.
