Gast in anderen Tenants

Über die Funktion eines Gast-Kontos können Anwender eines TenantA auch zur Mitarbeiter in einem TenantB eingeladen werden. Als Administrator von TenantB sehe und kontrollieren ich diese Gäste. Aber auch als AdministratorA möchte ich gerne wissen, in welchen anderen Tenants meine Anwender Mitarbeiten. Denn per Default ist diese Funktion nicht blockiert.

Dennoch sollte eine Firma schon erkennen und ggfls. unterbinden können, ob und welche Anwender ich in anderen Tenant als Gast herumtreiben und dort vieleicht sogar "Werte" erschaffen, von denen die eigene Firma vielleicht gar nicht weiß oder sogar eine Kopie erhalten müsste.

Benutzer: Wo bin ich Gast?

Viele Anwender wissen gar nicht, dass Sie ihren Gast-Zugriff auf einen anderen Tenant selbst wieder entfernen können. Der Anwender geht selbst einfach auf "https://myaccount.microsoft.com" und entfernt sich aus der jeweiligen Organisation. Das Gast-Konto in der anderen Organisation wird dabei "Soft deleted" und nach 30 Tagen komplett entfernt. Als Administrator des Ressource Tenants können Sie dies meines Wissens nicht verhindern.

Die Seite https://myaccount.microsoft.com ist aber auch für den Anwender die einfachste Anlaufstelle, um rauszufinden, wo ich selbst Gast bin. Natürlich habe ich nachgeschaut, welche API der Browser hier nutzt. Es ist einfacher HTTPS-POST gegen folgende URL:

POST https://account.activedirectory.windowsazure.com/currentuser?forceRefreshTenantList=true

{
"forceRefreshTenantList": true
}

Dabei kommt ein Bearer-Token zum Einsatz, welches meinen Benutzernamen und das Recht ""scp": "tenants.read" enthält. Die Antwort ist dann eine JSON-Struktur mit allen Tenants.

Das ist zwar nicht nicht Graph API aber doch sehr ähnlich. Leider ist account.activedirectory.windowsazure.com aber nicht öffentlich dokumentiert.

Auch über das Recht "tenants.read" habe ich nicht wirklich einen Anhaltspunkte gefunden

Admin: Wer ist wo Gast?

Für den AdminA im TenantA ist es natürlich auch interessant, diese Verknüpfungen zu kennen. Wenn ein Anwender schon seine eigene Mitgliedschaft in anderen Organisationen ermitteln und sogar löschen kann, dann möchte ich als Administrator zumindest die Verwendung herausfinden. Die Frage haben wohl schon mehrere Personen gestellt:

Leider habe ich hier zwei APIs gefunden, die mir aber auch nur "meine Berechtigungen" zeigen. Dabei unterscheiden sich die APIs noch mal, weil "Azure REST API reference" nur die Azure-Berechtigungen auf andere Tenant anzeigt und damit irreführen ist während die API, die vom myaccount.microsoft.com-Portal genutzt wird, keine AppPermission erlaubt

Einladungen

Wenn ein BenutzerB oder AdministratorB jemand aus dem TenantA einlädt dann sendet Microsoft eine Mail mit einem Link an die Adresse des BenutzerA. Solche Mails können Sie natürlich über den Absender (invites@microsoft.com) und andere Kennzahlen durch Exchange Transport Regeln erfassen.

From: Microsoft Invitations im Namen von xxxxx <invites@microsoft.com>
Date: Tue, 22 Feb 2022 23:50:47 -0800
Subject: XXXX hat Sie zum Zugriff auf Anwendungen in der Organisation eingeladen
Message-Id: <NUZV8YOD5GU4.MYLRWFPH0SKX@localhost.localdomain>
To: frank.carius@netatwork.de
MIME-Version: 1.0
Content-Type: text/html; charset=utf-8
Return-Path: invites@microsoft.com
X-MS-TrafficTypeDiagnostic: MN0PR21MB3170:EE_IGANotification|VE1EUR03FT010:EE_|PAXPR04MB8425:EE_

Ob man den String "EE_IGANotification" als Kriterium nutzen kann, weiß ich nicht. Bis dahin wäre ein Tracking auf den Absender invites@microsoft.com vermutlich die einzige Option, die Einladungen zu behandeln. Exchange hat hier ja einige Optionen:

  • Moderator
    Sie könnten die Mail an eine Revisionsstelle senden, die diese erst freigeben muss
  • Löschen
    Wenn Sie den Zugriff als Gast auf andere Tenants erschweren wollen, können Sie die Mail einfach löschen. Aus meiner Sicht aber keine gute Idee und auch kein 100% Schutz
  • Kopieren
    Sie könnten einen weiteren Empfänger addieren, damit Sie zumindest die Einladungen tracken können

Weiterhin könnte en Skript natürlich alle Postfächer auf "vergangene" Einladungsmails durchsuchen. Da aber Anwender eine solche Einladung nach der Verarbeitung in der Regel löschen, finden Sie nur etwas mit aktivierten Archivrichtlinien. Einige Firmen setzen mittlerweile aber auch ein "aktives Gast-Management" um, d.h. sie senden regelmäßig "Sind sie noch da"-Mails an den Gast. Das ist aber noch nicht die Regel und auch kein sicherer Indikator für ein Gastkonto

Diese Methode ist natürlich nicht vollwertig, da solche Links theoretisch auch per Chat versendet werden und sie keine früheren Einladungen sehen.

SignIn Log

Die Einladung eines AnwenderA in einen TenantB als Gast liefert keine komplette Sicht. Aber jeder Anmeldevorgang in Microsoft 365 wird protokolliert. Der Administrator von TenantB kann über das LastLogin-Property des Gast-Kontos schnell ermitteln, ob und wann es zuletzt genutzt wurde. Der Administrator von TenantA hat aber darauf keine Berechtigungen. Er kann aber zumindest über die letzten 30 Tage in den Azure SignIn-Logs nachvollziehen, wo sich ein Anwender angemeldet hat. Über das Feld "Cross Tenant Access Type" können Sie "B2B collaboration" und "B2B direct connect" auswählen.

Sie können über "Columns" auch weitere Spalten wie Hometenant, Ressourcetenant etc. einblenden. Ein Detaildatensatz (gekürzt) zeigt dann aber meinen Zugriff auf einen anderen Tenant mit Teams:

Über Graph kann diese Information natürlich automatisch abgefragt werden.

#Initial connection
Connect-MgGraph -Scopes "AuditLog.Read.All"
Select-MgProfile -Name "beta"

#Get ID of my own tenantID
$TenantId = (Get-MgOrganization).id

$Outboundguests = Get-MgAuditLogSignIn `
      -Filter "ResourceTenantId ne '$TenantID'" `
      -All:$True `
   | Group ResourceTenantId,AppDisplayName,UserPrincipalName `
   | Select-Object count,@{n='TenantID/User';e={$_.name}}

$Outboundguests

Leider sind diese Datensätze nur max. 30 Tage in die Vergangenheit verfügbar. Wer hier längere Zeiten erfassen will, sollte sich die Daten regelmäßig exportieren, in einem SIEM-System erfassen, in Azure Log Analytics abspeichern oder in einem Runbook auswerten.

Azure Audit Log

Leider habe ich im Audit-Log von TenantA keine Spur gesehen, wenn ein Mitarbeiter eine Gast-Einladung annimmt. Hier wird anscheinend nichts protokolliert. Im Auditlog gibt es durchaus die Filtermöglichkeiten auf Gast-Aktionen.

Die Events beziehen sich alle auf "inbound Guest"-Veränderungen, d.h. es werden Gäste in meinem Tenant eingeladen. Die Neuanlage eines Gasts im gastgebenden Ressource-Tenant wird aber in meinem AzureAD anscheinend nicht protokolliert.

Das könnte auch ein Hinweis sein, warum ich am lokalen Benutzer-Objekt keinen Verweis auf die anderen Tenants finde, in denen ich selbst Gast bin.

Outbound Zugriff unterbinden

Wenn ich schon nicht zuverlässig sehen kann, in welchen anderen Tenants meine Anwender mitarbeiten, dann möchte ich vielleicht zumindest eine Kontrolle darüber erhalten. Hier müssen sie nun zwischen "Guest Access" und dem "B2B Collaboration" und "B2B Access" unterscheiden. B2B Collaboration betrifft auch die Gastkonten

All your internal users are enabled for B2B collaboration by default. This means your users can invite external guests to access your resources and they can be invited to external organizations as guests. MFA and device claims from other Azure AD organizations aren't trusted.
No organizations are added to your Organizational settings by default. This means all external Azure AD organizations are enabled for B2B collaboration with your organization.
Quelle: Overview: Cross-tenant access with Azure AD External Identities (Preview)  Default settings https://docs.microsoft.com/en-us/azure/active-directory/external-identities/cross-tenant-access-overview#default-settings

...you can use cross-tenant access settings to manage inbound and outbound B2B collaboration and scope access to specific users, groups, and applications. 
Quelle: Overview: Cross-tenant access with Azure AD External Identities (Preview) : Organizational settings https://docs.microsoft.com/en-us/azure/active-directory/external-identities/cross-tenant-access-overview#organizational-settings

Die Einstellung zu B2B Collaboration finden Sie im Azure Portal unter:

https://portal.azure.com/#blade/Microsoft_AAD_IAM/OutboundAccessSettings.ReactView/isDefault/true/name//id/

Hier können Sie die Default-Werte anpassen:

Analog lassen sich dann auch individuelle Tenants eintragen, denen man "vertraut".

Zwischenstand

Auch im März 2022 ist die Verwaltung von Gästen in Tenants noch nicht komplett. Ich kann zwar Gäste in meinem Tenant sehr gut steuern aber habe als Firma kaum Möglichkeiten, den es gibt anscheinend keine passenden APIs. Hier die Kurzfassung:

  • Ein Benutzer kann sehr einfach ermitteln, in welchem anderen Tenant er ein Gast Konto hat
  • Ein Administrator kann dies aktuell nicht abfragen
  • Ein Administrator kann aber über SignIn-Logs sehen, in welchem anderen Tenant sich seine Anwender anmelden
  • Das geht ohne regelmäßige Exports oder Azure Analytics nur 30 Tage in die Vergangenheit

Es ist leider noch nicht möglich, als Administrator für einen Benutzer die Mitgliedschaften zu ermitteln.

Weitere Links