Externe Member, Gast, Kontakt

Diese Seite beschäftigst sich mit den vier grundlegenden Benutzerkonten im EntraID, den Exchange Kontakten und deren Verwendung in Exchange/Outlook und Teams. Dies ist besonders interessant für Multi-Tenant-Umgebungen mit Verzeichnisabgleich.

Diese Seite hantiert mit vielen Benutzerobjekten und ich warne gleich. Sie ist nicht einfach zu verstehen, weil auch das Thema nicht trivial ist

Einstieg

Die meisten Microsoft 365 Administratoren wissen, dass zum Zugriff auf Cloud-Dienste eine Authentifizierung und Autorisierung erfolgen muss und dazu ein Benutzerkonto im EntraID vorliegen muss. Dies kann entweder ein "Cloud Only"-Konto sein, welches ein Administrator oder Provisioning-Prozess direkt in der Cloud angelegt hat oder ein vom lokalen Active Directory z.B. mit ADSync / AADConnect synchronisiert wurde. Das ist aber nur ein Teil, denn wer Benutzern aus anderen Tenants die Mitarbeiter gestatten möchte, kann diese als "Externe Gäste" einladen. Wussten Sie aber auch, dass es zudem "Interne Gäste" aber auch "externe Mitglieder" gibt und weil das alles noch nicht genug ist, können Sie noch EntraID-Kontakte anlegen, die Sie im Entra ID-Portal gar nicht sehen können. Das geht dann nur per PowerShell, Exchange Management, Graph und andere APIs. All diese Objekte haben aber sehr wohl eine Funktion und Sichtbarkeit in Microsoft Teams und Exchange Online.

Wenn nun eine Firma mit mehreren Tenants arbeitet, dann gehört ein Verzeichnisabgleich zwischen zwei Tenants eigentlich zum guten Ton, d.h. die Postfächer und Verteiler eines Tenants erscheinen beim anderen Tenant als Kontakte und/oder Gäste. Cross-Tenant Sync ist z.B. eine Komponente aber nicht die einzige Lösung und schon gar nicht perfekt. Diese Seite soll das Verständnis fördern, so dass sie die richtige Konfiguration für ihre Umgebung finden.

Spoiler: Cross-Tenant Sync funktioniert genial für Die Zusammenarbeit mit Teams aber hilft ihnen nicht beim Abgleich von Exchange Empfängern zwischen Tenants. Für einen "Tenant GalSync" gibt es keine eingebaute Lösug von Microsoft. Wenn beide Seiten "Exchange Hybrid" nutzen, sollten Sie die beiden OnPremises Umgebungen mit einem GalSync versehen, damit ADSync auch die Objekte in den Tenant abgleicht.

Ansonsten können sie sich gerne an meine Kollegen oder mich bei Net at Work wenden.

Übersicht

Von den fünf Benutzertypen, die eine Person repräsentieren können, habe ich die "Internal Gast" ausgeklammert, denn ich kenne keinen Fall, in dem ich diesen Type schon einmal genutzt habe und kann mir aktuell auch keinen Anwendungsfall vorstellen.

Wenn einer meiner Leser mit "Internal Guests" arbeitet, dann würde mich die Begründung interessieren. Kontakt

Die anderen vier Personen-Objekte habe ich aber regelmäßig im Gebrauch.

Verwaltung durch Interne Member External Gast Externer Member Contact

Kurzfassung

Das sind ihre eigenen regulären Anwender, die als CloudOnly oder DirSync Konten angelegt werden und sich gegen ihre AzureAD authentifizieren.

Sie können Gäste regulär "einladen", damit diese z.B. in Microsoft Teams Kanälen mitarbeiten können. Sie sind aber in der Funktion an verschiedenen Stellen eingeschränkt.

Sie können aber auch externe Identitäten i ihrem Tenant als "Member" einladen. Es ist quasi ein Gast aber mit Rechten eines Members.

Schon immer können Sie externe Kontakte im Outlook Adressbuch über serverseitige Kontaktobjekte anlegen. Sie sich aber nicht anmelden können.

EntraID Portal

 Add (Invite)
Edit
Delete		 Add
Edit
Delete		 Add (Invite)
Edit
Delete		 Unsichtbar!. Sie sehen die Kontakte nicht in der Admin Portal.

AzureAD PowerShell

 Add
Edit
Delete		 Add
Edit
Delete		 Add
Edit
Delete		 kein ADD !!
Edit
Delete

Exchange Online PowerShell

Get-User
Enable
Disable		 GuestMailUser Get-User
Enable
Disable		 Add
Edut
Delete

Sichtbar im Exchange GAL

 Ja, wenn Mailbox oder MailUser Default Nein Ja Ja, wenn Mailcontact

Anmeldung

 Ja

Über Hometenant

 Ja

Nein

ADSync / AADConnect

 Regelfall
Meist nur Admins als CloudOnly User		 Nein Nein Möglich, Empfohlen bei Exchange Hybrid

Cross-Tenant Sync

Entfällt

Optional

Default

 Nein

Teams Kanalnutzung

 Ja Ja Ja Nein

Teams Federation

 User Awareness User Awareness User Awareness Objekt nicht sichtbar

Mitgliedschaft in Gruppen/Verteiler

 DirSync
CloudOnly		 Nur CloudOnly Nur CloudOnly DirSync
CloudOnly

Mitgliedschaft in Teams

 Ja Ja Nicht Supported?
Typ-Wechsel nicht supportet?		 Nein

ProxyAddresse

 Ja Nein (?) Nein (?) Ja

Auswirkungen

Die unterschiedlichen Nutzungsmöglichkeiten haben natürlich direkt Einfluss auf verschiedene Produkte und Module, speziell beim Einsatz mit mehreren Tenants, ADSync und Cross Tenant Sync . Hier ein paar Beispiele:

  • Exchange Adressbuch
    Wenn Sie Empfänger aus einem anderen Tenant oder System in ihrem Exchange Online Adressbuch sichtbar machen wollen, dann geht dies nur über Kontakte oder Member. Gäste sind nicht im Exchange Adressbuch sichtbar
  • Teams Mitglieder
    Offizielle können nur reguläre Mitglieder und Gäste in einem Team mitarbeiten
  • Federation und Gäste
    Wenn ein Benutzer in einem anderen Tenant mit Teams arbeitet und keinen Gast in ihrem Tenant hat, können ihre Anwender über Federation mit ihm kommunizieren. Sobald es aber einen Gast gibt, werden die Anwender das Gastkonto als Ziel nutzen. Das kann gut und gewollt sein, wenn Sie als Firma auf Federation verzichten und alle Daten in ihrem Tenant bleiben sollen. Für den externen Mitarbeiter bedeutet dies aber, dass er den Tenant wechseln muss, um zu chatten und er mit einem unterschiedlichen Status arbeitet
  • Exchange Kontakte anlegen
    Für jeden Exchange Online Kontakt gibt es auch ein Objekt im EntraID. Allerdings können Sie EntraID-Kontakte nicht per PowerShell oder API anlegen. Das geht nur über Exchange Online, welches dann auch das EntraID-Objekt anlegt
  • Doppeleinträge
    Einige Elemente können sogar doppelt angelegt werden aber andere wieder nicht. So muss z.B. die "ProxyAddress" oder der UPN im Tenant eindeutig sein und das kann schon zu Konflikten mit Exchange Kontakten und Gasteinladungen führen.
  • Cross Tenant Sync legt keine Kontakte an
    Wenn sie einfach nur die Empfänger eines Tenant als Exchange Empfänger im Outlook Adressbuch sehen wollen, dann könnte Cross-Tenant Sync

Es gibt sicher noch viele andere Konfliktfälle, die ich nach und nach ergänze.

Test 1: MailContact

Um die Thematik etwas zu beleuchten, habe ich eine kleine Testserie durchgeführt. Ich starte mit einem Exchange Kontakt, der entweder per ADSync oder CloudOnly-Objekt angelegt wird. Das ist ein häufiges Szenario, wenn zwei Firmen mit engerem Kontakt ihre Empfänger abgleichen wollen. Entweder bauen Sie eine entsprechende Lösung auf dem lokalen AD/Exchange auf und lassen ADSync die Kontakte in die Cloud replizieren oder sie lassen die Kontakte direkt in Microsoft 365 verwalten. Ich habe einfach einen Kontakt als "MailContact" über das Exchange Online Portal angelegt.


Quelle: https://admin.exchange.microsoft.com

Das Exchange Online Portal erlaubt ihnen auch die Anlage eines "MailUser", was dann einen regulären CloudOnly-Benutzerkonto in ihrem Tenant anlegt. Ich habe ihn "Cloudcontact1" genannt und eine SMTP-Zieladresse angegeben.

In der Folge nutze ich manchmal noch die AzureAD Powershell, welches aber abgekündigt ist. (Siehe EOL MSOnline und AzureAD PowerShell). Die Befehle für die die Microsoft Graph PowerShell (Siehe MGGraph PowerShell) sind sehr ähnlich.

 

Die Kontakt konnte ich dann per Exchange Online Powershell als auch AzureAD PowerShell sehen:

Entra ID Exchange Online PowerShell 
PS C:\> Get-AzureADContact -Filter "displayname eq 'Cloudcontact1'" | fl


DeletionTimestamp          :
ObjectId                   : 832c1b00-267c-49e9-b53c-9c4ce83bf8c0
ObjectType                 : Contact
City                       :
CompanyName                :
Country                    :
Department                 :
DirSyncEnabled             :
DisplayName                : Cloudcontact1
FacsimileTelephoneNumber   :
GivenName                  : Cloudcontact1
JobTitle                   :
LastDirSyncTime            :
Mail                       : Cloudcontact1@uclabor.de
MailNickName               : Cloudcontact1
Mobile                     :
PhysicalDeliveryOfficeName :
PostalCode                 :
ProvisioningErrors         : {}
ProxyAddresses             : {SMTP:Cloudcontact1@uclabor.de}
SipProxyAddress            :
State                      :
StreetAddress              :
Surname                    : Cloudcontact1
TelephoneNumber            :
 
PS C:\> Get-MailContact cloudcontact1| fl

ExternalEmailAddress                   : SMTP:Cloudcontact1@uclabor.de
MaxRecipientPerMessage                 : Unlimited
UseMapiRichTextFormat                  : Never
UsePreferMessageFormat                 : False
MessageFormat                          : Mime
MessageBodyFormat                      : TextAndHtml
MacAttachmentFormat                    : BinHex
UserCertificate                        : {}
UserSMimeCertificate                   : {}
HasPicture                             : False
HasSpokenName                          : False
IsDirSynced                            : False
AcceptMessagesOnlyFrom                 : {}
AcceptMessagesOnlyFromDLMembers        : {}
AcceptMessagesOnlyFromSendersOrMembers : {}
AddressListMembership                  : {\All Contacts(VLV),
                                          \All Recipients(VLV),
                                          \Default Global Address List,
                                          \AllContacts...}
AdministrativeUnits                    : {}
Alias                                  : Cloudcontact1
ArbitrationMailbox                     :
BypassModerationFromSendersOrMembers   : {}
CustomAttribute1 ..15                  :
ExtensionCustomAttribute1..5           : {}
DisplayName                            : Cloudcontact1
EmailAddresses                         : {SMTP:Cloudcontact1@uclabor.de}
GrantSendOnBehalfTo                    : {}
ExternalDirectoryObjectId              : 832c1b00-267c-49e9-b53c-9c4ce83bf8c0
HiddenFromAddressListsEnabled          : False
LastExchangeChangedTime                :
MaxSendSize                            : Unlimited
MaxReceiveSize                         : Unlimited
ModeratedBy                            : {}
ModerationEnabled                      : False
PoliciesIncluded                       : {}
PoliciesExcluded                       : {{26491cfc-9e50-4857-861b-0cb8df22b5d7}}
EmailAddressPolicyEnabled              : False
PrimarySmtpAddress                     : Cloudcontact1@uclabor.de
RecipientType                          : MailContact
RecipientTypeDetails                   : MailContact
RejectMessagesFrom                     : {}
RejectMessagesFromDLMembers            : {}
RejectMessagesFromSendersOrMembers     : {}
RequireSenderAuthenticationEnabled     : False
SimpleDisplayName                      :
SendModerationNotifications            : Always
UMDtmfMap                              : {}
WindowsEmailAddress                    : Cloudcontact1@uclabor.de
MailTip                                :
MailTipTranslations                    : {}
Identity                               : Cloudcontact1
Id                                     : Cloudcontact1
IsValid                                : True
ExchangeVersion                        : 0.20 (15.0.0.0)
Name                                   : Cloudcontact1
ObjectClass                            : {top, person, organizationalPerson, contact}
OrganizationalUnitRoot                 : msxfaqdev.onmicrosoft.com

 

Den Kontakt könnten sie genau mit Get-EXOObject, Get-MGContact u.a. Befehle abfragen. Bedenken Sie aber, dass einige Tools das Entra ID abfragen und andere das Exchange Online Directory. Das sind unterschiedliche Verzeichnisdienste, die aber von Microsoft repliziert werden. Siehe dazu auch Azure AD - Ein Verzeichnisdienst, oder zwei oder mehr. Es gibt zwar einen Kontakt im EntraID aber im Azure-Portal finde ich das Objekte dennoch nicht:

Das mag vielleicht daran liegen, dass Kontakte im Gegensatz zur Benutzern, Gästen und Gruppen keine richtig aktiven Identitäten sind, die sich anmelden könnten oder Berechtigungen ausüben. Dennoch hätte ich mir gewünscht, dass auch das Azure-Portal die Kontakte zumindest anzeigt. Neben dem Exchange Online Admin Center könne sie aber auch im eigentlichen Microsoft 365 Admin Portal ebenfalls Kontakte einsehen und ändern.

 

Die UI unterscheidet sich aber etwas vom Exchange Admin Center. So gibt es hier keinen Mailuser". Über Microsoft Graph können Sie auch Kontakte anlegen, ändern, löschen. Bei "New-MgContact" können Sie auch Felder wie "Mailnickname" und "ProxyAddresses" setzen, was sich auf Exchange auswirkt. Allerdings habe ich keinen Parameter gefunden, um z.B. die Sichtbarkeit im Adressbuch zu steuern.

Hinweis: Bei der Arbeit mit Graph und Kontakten verweisen viele Seite auf die "persönlichen Kontakte" im Exchange Postfach. Um die geht es auf dieser Seite nicht! Es gibt einen Unterschied zwischen "*-MGContact" und "*-MGUserContact". hier geht es um die "OrgContacts".

Wir haben nun einen Kontakt im Exchange Online Adressbuch mit einer Mailadresse. Es ist aber keine Identität, die für eine Anmeldung genutzt werden kann.

Produkt  Beschreibung 

Exchange Online

Anwender können den Kontakt in Outlook auflösen und Mails an den Kontakt versenden. Administratoren können den Kontakt in CloudOnly-Verteiler aufnehmen. Sollten die Verteiler aus einem lokalen AD mit ADSync repliziert werden, dann sollte Sie auch die Kontakte im lokalen AD als "MailContacts" mit den lokalen Exchange Management Tools anlegen, in die Verteiler aufnehmen und durch ADSync replizieren lassen.

Microsoft Teams

Ein Kontakt ist in Microsoft Teams nicht sichtbar. Sie können ihn daher nicht als Mitglied in ein Team aufnehmen.

Auch die Suche nach Federation-Partnern listet den Exchange Kontakt nicht auf:

Kontakte sind eigentlich "Exchange Kontakte" und auch wenn es in Entra-ID natürlich ein Gegenstück gibt, wird der Kontakt weitgehend ignoriert.

Test 2: Gastkonto

Nun spinnen wir die Geschichte etwas weiter. Der Tenant mit den Kontakten der befreundeten Firma möchte die anderen Benutzer gerne als Gast bei sich in Teams nutzen. Lange Zeit konnte der Teams-Besitzer direkt einen Gast in Teams addieren und damit eine Einladung aussprechen. Im Hintergrund wird dann ein Gastkonto angelegt. Größere Firmen haben hier Prozesse etabliert, um Gäste einzuladen. In meinem Test-Tenant bin ich zugleich Administrator und konnte in ein Team einen neuen Benutzer aus einem anderen Tenant addieren:

Sie sehen aber auch, dass der vorhandene Exchange Kontakt und AzureAD Kontakt nicht angeboten wird. Im Hintergrund wurde nun ein AzureAD-Gastkonto angelegt. Eine Suche mit der AzureAD-PowerShell liefert nun.

PS C:\> Get-AzureADContact -Filter "mail eq 'Cloudcontact1@uclabor.de'" | fl ObjectID,Displayname,Mail,Proxy*,UserType

ObjectId       : 832c1b00-267c-49e9-b53c-9c4ce83bf8c0
DisplayName    : Cloudcontact1
Mail           : Cloudcontact1@uclabor.de
ProxyAddresses : {SMTP:Cloudcontact1@uclabor.de}

PS C:\> Get-AzureADUser -Filter "mail eq 'Cloudcontact1@uclabor.de'" | fl ObjectID,Displayname,Mail,Proxy*,UserType

ObjectId : aaa15964-57df-4608-afc9-7a22c9934fbd
DisplayName    : Cloudcontact1
Mail           : Cloudcontact1@uclabor.de
ProxyAddresses : {}
UserType       : Guest

Wir haben nun zwei unterschiedliche Objekte, die sogar die gleiche  Mailadresse haben. Wenn ich danach in Teams wieder nach dem Benutzer zum Chatten gesucht habe, dann wurde nun der Gast angezeigt. Ich konnte aber auch weiter nach externen Empfängern mit der Adresse suchen. Eine Federation wird durch das Gastkonto nicht verhindert.

Aber natürlich müssen Sie ihre Anwender schulen, damit sie wissen, wohin die Nachrichten gehen. Wer hier den Gast auswählt, sendet die Nachricht nicht über Federation an den Heimattenant des Gasts sondern an das Gastkonto. Der Gast muss zum Lesen dann zu ihrem Tenant wechseln.

Natürlich wurde mir der Gast auch angeboten, wenn ich Mitglieder in einem bestehenden Microsoft Teams addieren wollte.  Allerdings ist der Gast "versteckt", da das Attribut "HiddenFromAdressListsEnabled = $true" ist.

PS C:\> Get-Recipient Cloudcontact1@uclabor.de `
>>           | fl displayname,RecipientType,RecipientTypeDetails,externalemailaddress,`
>>                primarysmtpaddress,emailaddresses,HiddenFromAddressListsEnabled

DisplayName                   : Cloudcontact1
RecipientType                 : MailContact
RecipientTypeDetails          : MailContact
ExternalEmailAddress          : SMTP:Cloudcontact1@uclabor.de
PrimarySmtpAddress            : Cloudcontact1@uclabor.de
EmailAddresses                : {SMTP:Cloudcontact1@uclabor.de}
HiddenFromAddressListsEnabled : False

DisplayName                   : Cloudcontact1
RecipientType                 : MailUser
RecipientTypeDetails          : GuestMailUser
ExternalEmailAddress          : SMTP:Cloudcontact1@uclabor.de
PrimarySmtpAddress            :
EmailAddresses                : {}
HiddenFromAddressListsEnabled : False

Der Gastbenutzer ist aber auch im Adressbuch versteckt und hat keine ProxyAdressen (EmailAddreses). Es ist im Grunde aber ein MailUser ist, habe ich einfach mal versucht, dieses Objekt "sichtbar" zu machen:

PS C:>Set-MailUser Cloudcontact1@uclabor.de -HiddenFromAddressListsEnabled:$false

PS C:\> Get-Recipient Cloudcontact1*@uclabor.de `
           | ft displayname,RecipientTypeDetails,HiddenFromAddressListsEnabled

DisplayName      RecipientTypeDetails HiddenFromAddressListsEnabled
-----------      -------------------- -----------------------------
Cloudcontact1    MailContact                                  False
Cloudcontact1    GuestMailUser                                False

Auf die Idee sind ja schon weitere Personen gekommen:

Achtung: Es kann angeblich bis zu 24h dauern, bis Exchange Online diese Änderungen dann auch bis zu den Clients gebracht hat.

Prüfen, ob das nach einiger Zeit immer noch so ist. Angeblich dauert es bis zu 24h

Damit ich im Exchange Adressbuch die beiden Objekte besser unterscheiden kann, habe ich den Displaynamen des Gastusers etwas angepasst.

Set-MailUser `
   -Identity Cloudcontact1@uclabor.de `
   -HiddenFromAddressListsEnabled:$false `
   -DisplayName Cloudcontact1g

 

Natürlich wollte ich auch in Outlook bzw. Outlook Web Access das Ergebnis sehen, wie die Benutzer dies nun sehen:

Leider kann ich da nur den MailContact finden aber nicht den Gastbenutzer. Ich habe schon absichtlich in der "Default Global Address List" gesucht, da es ja kein Kontakt, sondern ein User ist. Nach etwas Suche habe ich eine zuverlässige Quelle gefunden.

These users were not appearing in the global address list. This is by design.
The Exchange Online provisioning process only adds users to the global address list if the guest account type is member.
Quelle: Office 365: Guest accounts do not appear in the global address list. https://timmcmic.wordpress.com/2021/08/16/office-365-guest-accounts-do-not-appear-in-the-global-address-list/

Damit macht es auch Sinn, wenn Cross-Tenant Sync im Ziel als Standard die Gäste als "Member" anlegt.

Auch wenn ich Gäste mit einer Mailadresse im Exchange Admin Center als Empfänger sehe, sind Sie denn noch nicht im Outlook Client zu finden.

Test 3: Externer Member

Wenn externe Identitäten vom Typ "Gast" nicht im Exchange Adressbuch auftauchen, obwohl Sie mit "-HiddenFromAddressListsEnabled:$false" nachträglich entsprechend gekennzeichnet wurden aber externe Konten von Typ" Member" auftauchen sollen, dann muss das getestet werden. Um mein CloudContact1 nicht zu stören, habe ich einen neuen Kontakt "CloudContact2" angelegt.

PS C:> New-MailContact `
          -Name Cloudcontact2@uclabor.de `
          -ExternalEmailAddress Cloudcontact2@uclabor.de

Da Microsoft Teams beim Addieren neuer Gäste den Typ nicht vorgeben kann, habe ich über das Azure Portal den externen Member angelegt.

 

Per PowerShell geht dies natürlich auch mittels Graph.

Bei einer Suche in Teams zeigt mir Teams den "Member"-Gast. Zudem erlaubt mit Teams immer noch nach extern zu suchen, so denn der Endanwender den Unterschied kennt

 

Das ist wichtig hier die Anwender zu schulen, den richtigen Kommunikationspartner zu nutzen.

Wenn sie Identitäten in ein Team hinzufügen wollen, dann stehen beide Typen der externen Identitäten , d.h. "Guest" und "Member"  zur Auswahl.

 

In Exchange sieht das Bild wieder anders aus. In der Exchange PowerShell finde ich mit "Get-Recipient" mittlerweile mehrere Empfänger, die ich auch alle "HiddenFromAddressListsEnabled = $False" gesetzt habe.

Hier erscheinen aber nur echte Exchange Kontakte und "externe Identitäten (Guest)" aber keine "externe Identitäten (Member)" Im AzureAD-Portal sind die beiden "externen Identitäten" sichtbar aber keine Exchange Kontakte , die in EntraID auch Kontakte sind und im Portal nicht unter "Users" angezeigt werden.

In Outlook Web Access sehe ich aber folgende Empfänger:

 

Das ist nun schon etwas überraschend, den in der Exchange PowerShell sehe ich doch 5 Empfänger. Zur Sicherheit habe ich noch einmal die Mitgliedschaft in den Adresslisten ausgeben lassen:

Für die Sichtbarkeit in Exchange, Outlook, OWA und anderen Exchange Funktionen gibt es hier anscheinend noch einen versteckten Filter, der bestimmte Objekte ausblendet.

Auch in Teams sind nicht alle Objekt sichtbar aber zumindest ist die Auswahlliste bei Federation und Mitgliedschaft in Teams identisch

 

Achtung: Denken Sie bei solchen Aktionen und Tests immer an die Verzögerungen durch Replikationen zwischen lokalen AD, AzureAD, Exchange Online AD, Teams Directory und dann kommen noch Cache-Funktionen dazu. Ein gelöschter Kontakt kann durchaus einmal mehrere Stunden als "Leiche" noch sichtbar sind. Meist bekommen Sie dann aber einen Fehler, wenn Sie das Objekte verwenden wollen, z.B.

Auch der umgekehrte Fall ist natürlich möglich, d.h. sie legen ein neues Objekt an und es erscheint erst deutlich verzögert.

Exchange GAL, Teams Gast und Federation

Dann stellen wir mal die verschiedenen Objekte und ihre Sichtbarkeit dar. Für die Powershell geht es recht einfach:

 

Nicht jeder User ist auch ein Recipient (z.B. CloudUser2 ohne Lizenz) aber auch nicht jeder Recipient ist auch ein User (z.B. Cloudcontact1)

Name  EntraID Exchange Admin
(Get-User)		 Exchange Admin
(Get-Recipient)		 Outlook Teams Personensuche Teams Mitglied

Cloudcontact1 

 Contact (nicht sichtbar) Nicht vorhanden MailContact Kontakt Nicht vorhanden    Nicht vorhanden   

Cloudcontact1g

 External Guest GuestMailuser  GuestMailuser  Nicht sichtbar   Vorhanden Teammitglied

Cloudcontact2 

 Contact (nicht sichtbar) Nicht vorhanden MailContact  Kontakt  Nicht vorhanden    Nicht vorhanden  

Cloudcontact2m

 External Member User Nicht vorhanden Nicht sichtbar   Vorhanden Teammitglied

Cloudcontact3 

 Contact (nicht sichtbar) Nicht vorhanden MailContact  Kontakt  Nicht vorhanden  Nicht vorhanden 

Cloudcontact4m

 External Member User Nicht vorhanden  Nicht vorhanden     Vorhanden Teammitglied

Die Tabelle erscheint mir selbst noch nicht ganz schlüssig. Vor allem, dass ExternalMember unterschiedlich zu ExternalGuest behandelt werden und ExternalGuest zwar im Exchange Management erscheinen aber nicht im Adressbuch bei den Clients, obwohl er nicht versteckt (HiddenFromAddressListsEnabled : False) ist

Vielleicht habe ich aber nur eine kleine Einstellung übersehen, damit "External Member" oder ""External Guest" auch in der Exchange GAL sichtbar werden. "External Guest" sind ja schon mal als Objekte vorhanden.

Sonderfall "ShowInAdressList"

Bei der Recherche bin ich schon weiter oben auf das Exchange Property "HiddenFromAddressList" gestoßen und konnte es mit Set-MailContact auch unabhängig vom AzureAD setzen. Es gibt aber auch im AzureAD ein Property "ShowInAddressList", welches ich lesen und setzen kann. Zuerst habe ich den aktuellen Status der AzureAD-User und AzureAD-Contacts über die neue Microsoft Graph Powershell ausgelesen. Die alte "AzureAD-Powershell" ist schon länger abgekündigt (EOL MSOnline und AzureAD PowerShell)

Die "-Filter"-Funktion der AzureAD oder MSGraph-PowerShell ist leider komplett abweichend von dem, was ein Exchange Admin so kennt. Oft geht nur "eq, and, or" aber kein Like. Ich habe daher alle Objekte abgerufen und dann nachträglich mit "where" gefiltert.
Zudem rufen die Graph Commandlets nicht alle Werte ab und lassen die Felder dann aber leer. Ich muss die erforderlichen Properties explizit angeben.

Get-MgUser -all -property Displayname,ShowInAddressList   `
   | Where {$_.DisplayName -like 'cloudcontact*'}  `
   | ft displayname,showinaddresslist
Get-Mgcontact -property Displayname,ShowInAddressList   `
   | Where {$_.DisplayName -like 'cloudcontact*'}  `
   | ft displayname,showinaddresslist

Es ist gut zu sehen, dass die Entra ID User diese Property haben und es aus "False" steht. Das könnte ein Grund sein, dass diese Objekte nicht in Exchange Online als Empfänger in der GAL erscheinen. Bei den Entra ID-Kontakten hingegen, welche ich über die Exchange Online PowerShell angelegt habe, ist das Feld "$null". Um die Zusammenhänge weiter zu verstehen, haben ich mir vier weitere Benutzer angelegt

Displayname       Typ             Mailadresse                Beschreibung
=========================================================================================================
cloudcontact8m    External Member CloudContact8m@uclabor.de  (So würde Cross-Tenant Sync den User anlegen)
cloudcontact8g    Externel Guest  CloudContact8g@uclabor.de  (So sind in Teams eingeladene Benutzer
cloudcontact8u    Internal Member CloudContact8u@uclabor.de  (interner User als Member, d.h. reguläre Anwender)
cloudcontact8i    Internal Guest  CloudContact8i@uclabor.de  (interner User als Gast, möglich habe habe ich noch nie genutzt.)

Interessant sind natürlich nur die externen Benutzer, denn das interne User-Konto kann ich ganz einfach zu MailUser oder MailboxUser machen während ich noch keinen Anwendungsfall für "internal Guest" gesehen habe. Per Get-MGUser sehe ich aber, dass nur die externen Objekte auch ein Attribut bekommen haben.

In der Exchange PowerShell sind diese Objekte auch nach einiger Zeit noch nicht als "Recipients" aufgetaucht aber sehr wohl als User.

Sowohl den "External User" als auch den "Internal User" könnte ich mit einer Exchange Lizenz zu einen MailboxUser machen und mit "Enable-MaiUser" auch zum Kontakt hochstufen. Mir geht es aber um die Funktion der Kontakte und daher habe die beiden User nun im AzureAD umgesetzt.

Leider konnte ich dies, warum auch immer, nicht mit "Update-MGUser" umsetzen. Graph hat mit einem "403 Authorization_RequestDenied" dies abgelehnt, obwohl ich "User.ReadWrite" hatte. Per AzureAD-Powershell war es aber möglich.

PS C:\> Get-AzureADuser -Filter "DisplayName eq 'cloudcontact8g'" | Set-AzureADUser -ShowInAddressList $true
PS C:\> Get-AzureADuser -Filter "DisplayName eq 'cloudcontact8i'" | Set-AzureADUser -ShowInAddressList $true
PS C:\> Get-AzureADuser -Filter "DisplayName eq 'cloudcontact8m'" | Set-AzureADUser -ShowInAddressList $true
PS C:\> Get-AzureADuser -Filter "DisplayName eq 'cloudcontact8u'" | Set-AzureADUser -ShowInAddressList $true

Die Kontrolle per Get-MGGraphUser liefert dann die Bestätigung: Alle Objekte sind nun im AzureAD als "ShowInAddressList = $True" gesetzt.

Nun warten wir einige Zeit ab, bis die Replikation erfolgt ist. Um dies besser zu sehen, habe ich danach den Displaynamen der vier Objekte erweitert um direkt in Exchange, Teams u.a. zu sehen, ob die Änderungen schon angekommen sind. Auch das hat MGGraph angeblich mangels Berechtigungen abgelehnt aber noch funktionierte ja die AzureAD-PowerShell.

Get-AzureADuser -all $true `
| where {$_.DisplayName -like 'cloudcontact8*'} `
| %{set-azureaduser -ObjectId $_.objectid -DisplayName "$($_.displayname)-2"}

Es hat nur ein paar Sekunden gedauert, bis ich die User auch in der Exchange PowerShell gesehen habe:

Get-user cloudcontact8* | ft displayname,recipienttypedetails

DisplayName        RecipientTypeDetails
-----------        --------------------
cloudContact8m-2   User
CloudContact8u-2   User

Ich habe das so erwartet, dass die "Internal-Member" (= reguläre User) und "External-Member" auch in Exchange Online als User aber ohne Mailfunktion erscheinen. Ich habe aber nicht erwartet, dass meine neu angelegten Gäste überhaupt nicht in Exchange sichtbar geworden sind. Ich habe dann als Gegenprobe noch einmal in Teams einen weiteren Gast eingeladen:

Unter den Mitgliedern in Teams habe ich auch den neuen CloudUser9 als Mitglied gesehen aber weder in Exchange Online noch EntraID ist der Gast erschienen.

Es ist wohl Zeit für eine Pause. Anscheinend werden auch Gasteinladungen in Teams nicht sofort in ein Entra ID-Objekt umgesetzt oder das Entra ID hatte zu dem Zeitpunkt eine Störung, so dass die Replikation verzögert war. Ich habe dann erst einmal eine "Pause" eingelegt, damit Microsoft 365 all die Änderungen umsetzen kann. Einige Stunden später war dann auch mein "CloudUser9" in EntraID und Exchange Admin Center sichtbar aber nicht im Exchange Adressbuch

Bewertung

Wenn das aber so stimmt und nicht verändert wird, dann hat das durchaus Auswirkungen auf die engere Zusammenarbeit von zwei Tenants samt Verzeichnisabgleich mit Cross-Tenant Sync. Wenn ich mit Cross-Tenant Sync im anderen Tenant "External Member" anlegen lasse, was der Default ist, dann funktioniert das sehr gut mit Teams aber hilft mit in Exchange nicht weiter. Wenn ich Cross-Tenant Sync aber anweise, stattdessen Objekte vom Typ "External Guest" anzulegen dann können Sie in Teams genutzt werden, erscheinen auch im Exchange Management als "GuestMailUser" aber dennoch nicht im Exchange Adressbuch.

Egal ob sie aber nun durch Cross-Tenant Sync im anderen Tenant "External Guest" oder "External Member" anlegen lassen, so vereinfacht dies zwar die Zusammenarbeit in Teams und Kanälen, aber die Anwender müssen bei 1:1 Chat über Federation aufpassen, dass sie das gewünschte Konto erwischen. Wer den von Teams vorgeschlagenen Kontakt nutzt, zwingt den Partner einen Tenant-Wechsel vorzunehmen. Nur wer auf "Extern nach ... suchen" klickt, kann den Partner in dessen Heimattenant finden und dann über Federation chatten.

Wie Sie aber an den Paarungen "CloudContact1/CloudContact1g" und "CloudContact2/CloudContact2m" gut sehen können, kann ich durchaus Objekte mit der gleichen Mailadresse versehen. Wenn ich eine Person aus einem anderen Tenant in meinem Tenant sowohl im Exchange Adressbuch als auch in Teams als verwaltetes Objekt haben möchte, dann muss ich zwei Objekte verwalten. Das wird aber dann knifflig, wen Sie ADSync einsetzen, denn lokale Exchange-Objekte mit einer Mailadresse können nicht expliziert werden, wenn ein Gastkonto die Adresse blockiert.

Weitere Links