SyncM365 Filterung
Die meisten größeren Firmen möchten nicht alle lokalen AD-Konten auch ins EntraID replizieren und nutzen dazu meist ein LDAP-Feld als Kriterium. Im Gegenzug sollten Sie aber immer alle Exchange Empfänger auch in Exchange Online vorhalten. Diese Seite beschreibt die Zusammenhänge und sinnvolle Prüfungen, wenn Sie z.B. über einen Wert wie "SyncM365" in einem AD-Feld die Synchronisation zu Microsoft 365 kontrollieren.
Zusammenhänge
Auf Seiten wie ADSync mit Exchange, ADSync mit Exchange Online Only, Exchange Online ADSync Provisioning und anderen habe ich die Zusammenhänge mit Exchange und Hybrid und ADSync schon oft beschrieben. Daher hier die Kurzfassung für den betrieb von Exchange mit ADSync bzw. Entra ID Connect Sync/CloudSync, die wie Bausteine mittlerweile genannt werden.
- Meine GAL ist deine GAL
Damit Exchange Hybrid fehlerfrei funktioniert, sollten alle Empfänger, d.h. Postfächer aber auch MailUser, MailContact, Verteiler etc. synchron sein. Alle lokalen Empfänger müssen in Exchange Online angelegt werden und sie sollten nie in Exchange Online Empfänger anlegen, für die es kein Gegenstück gibt. - Exchange Online ist teilweise ReadOnly
Die meisten Felder bei einem Benutzer oder Gruppe, die mit ADSync repliziert werden, können nicht in Exchange Online oder EntraID verwaltet werden. Eine Änderung muss immer lokal passieren
Die zweite Thematik betrifft das lokale AD. Es gibt keine "Schema-Erweiterung" für AzureAD/EntraID oder generell die Cloud Dienste. Aber die meisten Firmen haben im lokalen Active Directory viel mehr Objekte, als Sie in der Cloud preisgeben möchten. Bei der Einrichtung des Verzeichnisabgleich werden daher gerne Filter (Siehe ADSync Filterung) umgesetzt.
- Gruppenmitgliedschaft
Sie können über eine Gruppenmitgliedschaft, einzelne OUs und ein LDAP-Feld filtern. Die Gruppenmitgliedschaft kann nur bei der initialen Einrichtung konfiguriert werden und alle Objekte müssen natürlich auch Mitglied der Gruppe werden können. Diese Filterung ist primär für Pilotumgebungen gedacht. - OUs
Eine Filterung nach OUs funktioniert nur, wenn die OU-Struktur passt und Umbenennungen oder Umorganisationen selten sind. - AD-Feld
Daher nutzen viele Firmen dann doch wieder ein AD-Feld als Filterkriterium, um zu steuern, welche Objekte durch ADSync gelesen werden. Sie müssen die Pflege dieses Felds dann natürlich in ihrem Provisioning berücksichtigen.
Nur eher kleine Firmen verzichten komplett auf eine Filterung und replizieren alles, was ADSync so findet. Häufiger ist eine Filterung nach OUs oder auch per LDAP-Feld.
ExtensionAttribute und Exchange
Dazu muss man aber auch ein Feld finden, welches wieder bei allen Objekten vorhanden ist. Schließlich repliziert ADSync nicht nur Benutzer und Gruppen, sondern ggfls. auch Devices, InetOrgPerson und andere LDAP-Klassen, die man vielleicht heute noch nicht kennt. Denkbar wäre eine eigene proprietäre Schemaerweiterung aber davor schrecken die meisten Administratoren zurück. Durch die Installation von Exchange wurde das Schema aber schon umfangreich erweitert und einige Felder gibt es schon seit Jahrzehnten und werden von Exchange mittlerweile nicht gehr genutzt.
- Exchange LDAP-Felder
- Schemaerweiterungen von Exchange
- Benutzerdefinierte Attribute in Exchange
Server
https://learn.microsoft.com/de-de/exchange/recipients/mailbox-custom-attributes?view=exchserver-2019
Die meisten Administratoren nutzen z.B. eines der "Custom Attributes", die als "ExtensionAttributes" im Schema definiert wurden. Die Inhalt sind im Index und im Globalen Katalog und damit für solche Zwecke prädestiniert.
Beachten Sie aber, dass bei der Anlage eines Benutzers über die "Kopieren"-Funktion der "MMC Benutzer&Computer" das Feld ebenfalls kopiert wird. Dies passiert aber nicht, wenn Sie neue Benutzer klassisch anlegen. Sie müssen nun nur noch wissen, welches Feld nicht schon durch andere Prozesse "missbraucht" wurde. Denn ursprünglich waren die Felder durch das Exchange Produkt Team angelegt worden. Mittlerweile hat Microsoft selbst geschrieben, dass Sie die Felder "ExternsionAttribute1" bis "ExternsionAttribute15" aufgrund der vielfältigen Verwendung durch andere Produkte nicht mehr nutzen.
Microsoft Exchange Server 2013 includes 15 extension attributes. You can use
these attributes to add information about a recipient, such as an employee ID,
organizational unit (OU), or some other custom value für which there isn't an
existing attribute. These custom attributes are labeled in Active Directory as
ms-Exch-Extension-Attribute1 through ms-Exch-Extension-Attribute15. In the
Exchange Management Shell, the corresponding parameters are CustomAttribute1
through CustomAttribute15. These attributes aren't used by any Exchange
components.
Quelle: Custom Attributes http://technet.microsoft.com/en-us/library/ee423541.aspx
Microsoft hat sogar weitere Felder addiert:
In Exchange 2010 SP2, we have added five new multi-value custom attributes that
you can use to store information für mail recipient objects. They are the
ExtensionCustomAttribute1 to 5 (also can be referred to as
ms-exch-extension-custom-attribute-1 to 5).
Quelle:
http://blogs.technet.com/b/exchange/archive/2012/01/17/custom-aka-extension-attributes-in-exchange-2010-sp2-and-their-use.aspx
Die weiteren Felder ms-Exch-Extension-Attribute-16 bis 45 sind aber "verboten". Ob die bestehenden Felder 1-15 genutzt werden, können Sie einfach wie folgt abfragen:
1..15 | %{@{"CustomAttribute$($_)" = (Get-User -filter "(CustomAttribute$($_) -like '*')" -ResultSize 1 -WarningAction ignore).count}}
Über "Resultsize 1" beschleunige ich die Abfrage und die WarningAction unterdrückt die gelben Warnungen. Mit einem "Resultsize unlimited" würden Sie auch die Anzahl der Objekte sehen.
Achtung:
Microsoft schreibt zwar, dass Sie das Feld nicht mehr nutzen aber ein "Disable-Mailbox"
oder "Disable-RemoteMailbox" leer diese Felder. Wer die Felder mit anderen
Werten ohne Bezug zu Exchange füllt, verliert diese mit der Deaktivierung des
Objekts in Exchange und wenn ADSync diese Information als Filterkriterium nutzt,
dann wird auch das Konto in Microsoft 365 gelöscht!
Exchange Provisioning
Bei der Nutzung von lokalem AD und Exchange Hybrid sollten Sie bei der Anlage von Benutzern eine Besonderheit von Exchange Online kennen:
Exchange Online legt ein Postfach an, wen ein Benutzer ohne lokale Exchange Felder durch ADSync zu Microsoft 365 repliziert und mit einer Exchange Lizenz versehen wird.
Eine nachträgliche Konfiguration als "OnPremises-Postfach führt zu Doppelpostfächern. (Siehe auch Doppelpostfach mit Exchange Online). Wenn Sie die durch ADSync replizierten Objekte über den Inhalt eines Felds steuern, dann bietet es sich an das Feld erst am Ende der Konfiguration zu setzen.
- Doppelpostfach mit Exchange Online
- ADSync mit Exchange Online Only
- Cloud ProxyAddresses
- Exchange Online ADSync Provisioning
Exchange Prüfung
In der Theorie funktioniert alles perfekt aber die Nutzung eines Felds zur ADSync-Filterung kann in Verbindung mit Exchange Empfängern zu einem einfachen Test genutzt werden. Starten Sie die lokale Exchange PowerShell und prüfen Sie einfach, ob alle Exchange Empfänger auch das Feld haben:
Ich nutze dazu das Feld CustomAttribute15, welches schon bei der Migration von Exchange 5.5 zu Exchange 2000 eine besondere Funktion mit dem damaligen Active Directory Connector hatte und daher meist nicht anderweitig genutzt wird. Als ADSync-Kriterium muss der Inhalt "SyncM365" lauten
# Suche nach Altlasten. Dieser Wert sollte immer "0" sein. (Get-Recipient -filter "(CustomAttribute15 -ne 'NTDSNOMATCH')" -ResultSize unlimited).count # Zählen der Exchange Empfänger die noch nicht synchronisiert werden (Get-Recipient -filter "(CustomAttribute15 -ne 'SyncM365')" -ResultSize unlimited).count # Liste der lokalen Empfänger, die nicht in Microsoft 365 sind nach Objekttyp Get-Recipient -filter "(CustomAttribute15 -ne 'SyncM365')" -ResultSize unlimited | group Recipienttypedetails -noelement # Liste der lokalen Empfänger, die nicht in Microsoft 365 sind Get-Recipient -filter "(CustomAttribute15 -ne 'SyncM365')" -ResultSize unlimited
Um es deutlich zu machen: Sie sollten immer ALLE lokalen Exchange Empfänger auch nach Microsoft 365 mit allen Exchange Properties replizieren lassen.
Vielleicht macht es ja Sinn eine solche "Zählung" der inkonsistenten Objekte in ihr Monitoring einzubauen. Das geht auch ohne Exchange PowerShell einfach per LDAP-Suche
"(&(mailnickname=*)(!(ExtensionAttribute15=*)))
Die Gegenprobe, d.h. Das Feld ExtensionAttribute15 ist gesetzt aber es ist kein Exchange Emüfänger, ist hingegen nicht wichtig. Es kann ja durchaus auch Objekte geben, die nichts mit Exchange zu tun haben aber dennoch durch die Replikation zu Microsoft 365 synchronisiert werden. Interessant könnte aber die Gegenrichtung sein, d.h. welche Exchange Objekte in Exchange Online bekannt sind und zu denen es keine Gegenstück im lokalen AD gibt. Das ist dann aber etwas Aufwändiger, da sie die Exchange Online Empfänger erst auslesen und mit den lokalen Empfängern vergleichen müssen. Aber auch dazu habe ich schon Vorarbeit geleitet:
Exchange Reparatur
Sollten Sie bei der Prüfung nun Objekte finden, die im lokalen Exchange Server als "Empfänger" erscheinen und das Feld "CustomAttribute15" nicht auf den Wer "SyncM365" gesetzt ist, dann können Sie dies wie Folge recht einfach korrigieren.
(Get-Mailbox -filter "(CustomAttribute15 -ne 'SyncM365')" -ResultSize unlimited ) | Set-Mailbox -CustomAttribute15 "SyncM365" (Get-RemoteMailbox -filter "(CustomAttribute15 -ne 'SyncM365')" -ResultSize unlimited ) | Set-RemoteMailbox -CustomAttribute15 "SyncM365" (Get-MailUser -filter "(CustomAttribute15 -ne 'SyncM365')" -ResultSize unlimited ) | Set-Mailuser -CustomAttribute15 "SyncM365" (Get-MailContact -filter "(CustomAttribute15 -ne 'SyncM365')" -ResultSize unlimited ) | Set-MailContact -CustomAttribute15 "SyncM365"
Theoretisch können Sie diese Zeilen auch als "Geplanter Task" immer mal wieder automatisch ausführen lassen. Allerdings sollte dies Sie nicht davon abhalten, ihren Provisioning-Prozess zu überprüfen. Irgendwo in dem Ablauf der Verwaltung ihrer Identitäten haben Sie ja wohl vergessen, das Feld zu setzen.
Zusammenfassung
Die Filterung der von ADSync zu Microsoft 365 replizierten Objekte über ein LDAP-Feld ist eine geläufige Konfiguration und erlaubt die granulare Steuerung der Objekte in EntraID und davon abhängigen anderen Cloud-Diensten. Allerdings muss ihnen klar sein, dass in Verbindung mit Exchange Hybrid ein Objekt erst dann in Exchange Online erscheinen und mit einer Lizenz versehen werden darf, wenn die lokale Konfiguration des Exchange Empfängers, z.B. als Mailbox, RemoteMailbox oder MailUser erfolgt ist, da Sie im schlimmsten Fall ein Doppelpostfach mit Exchange Online erhalten. Daher muss der Replikation durch ADSync und die lokale Konfiguration aufeinander abgestimmt sein. Hier können aber immer Fehler passieren, die Sie entsprechend überwachen und ggfls. korrigieren sollten.