AADConnect Objekte ausschliessen (z.B. Einen Benutzer nicht synchronisieren)

Manchmal muss der Admin genau ein einziges Objekt, oder nur wenige ganz bestimmte Objekte von der Synchronisation vom lokalen AD in das Microsoft 365 Azure AD ausschließen.

Das geht überraschend einfach, mann kann exclude-Regeln einfach im „Synchronization Rule Editor“ hinzufügen.

Schritt für Schritt Anleitung um ein Objekt nicht mehr zu synchroniseren

  1. Zeitplan für die Synchronisation abschalten, damit keine automatischen Aufgaben die Änderungen durcheinander bringen:
Set-ADSyncScheduler -SyncCycleEnabled $False

Der Status des ADSyncSchedulers lässt sich jeder überprüfen mittels:

Get-ADSyncScheduler | Format-List SyncCycleEnabled

2. „Synchronization Rules Editor“ starten (als Administrator)

3. In der „View and manage …“ Liste die „Direction“ auf „Inbound“ stellen und eine freie Nummer unterhalb der bestehenden „Precedence“ Regeln finden (und merken). In der Regel ist das irgendetwas <100.

4. Oben rechts „Add New rule“

5. Den „Create inbound synchronization rule“ Assistenten nun ausfüllen:

  • Name: Ein beschreibender Name, z.B. „In from AD – Bernd auslassen“
  • Connected System: Der lokale AD Forest
  • Connected System Object Type: user
  • Metaverse Object Type: Person
  • Link Type: join
  • Precedence: Die gemerkte Nummer von oben (z.B. „90“)
  • „Tag“, „Enable Password Sync“ oder „Disabled“ nicht verändern
  • Next > …

6. „Add group“ > dann > „Add clause“

7. Als „Attribut“ ein zu filterned Attribut wählen, zum Beispiel den „name“ oder ein anderes Attribut. Bei größeren Mengen an Objekten nutzen wir hier gerne die „Extended Attributes“, die normalerweise solange ungenutzt und leer sind. Der Operator ist im Beispiel „equal“, der „Value“ der zu matchende Inhalt.

8. „Next >“, an den nun angezeigten „Add join Rules“ nichts ändern > „Next >“

9. Bei den „Add join rules“ eine Transformation hinzufügen:

  • „Add transformation“ >
  • FlowType: Constant
  • Target Attribute: cloudFiltered
  • Source: True
  • Apply Once: leer lassen
  • Merge Type: Update
  • Unten auf „Add“

10. „Synchronization Rules Editor“ schliessen, „Synchronization Service“ öffnen

11. „Connectors“ > Actions > Run > Full Synchronization > OK

12. „Operations“ Den Zyklus abwarten, Full dauert immer einen Moment …

13. Den Synchronization Schedule wieder einschalten:

Set-ADSyncScheduler -SyncCycleEnabled $True

14. Und einmal die Initial-Synchronisation laufen lassen:

Start-ADSyncSyncCycle -PolicyType Initial 

Remote-Postfächer in Exchange Hybrid-Konfiguration im lokalen ECP anzeigen und bearbeiten

Problem

Wenn ein Benutzer in einer Hybrid-Umgebung erstellt wird und ihm dann eine Exchange Online-Lizenz zugeordnet wird, wird für diesen Benutzer ein Cloud-Postfach erstellt.

Der OnPremises Exchange Server erfährt davon aber nichts, daher ist der Benutzer im lokalen ECP nicht aufzufinden und das Mailrouting („Nachrichtenfluss“) von intern nach extern schlägt fehl.

Wenn man Office 365 zum ersten Mal im Hybridmodus verwendet, erstellt man oft neue Benutzer, indem man einfach ein AD-Konto erstellt und dieses via ADConnect synchronisiert. Danach wird der neue User lizenziert und bekommt ein Postfach. Das erzeugt genau das oben genannte Problem – die OnPremises Exchange Adressliste weiss nichts von dem neuen Objekt und routet keine E-Mails in die Cloud.

Beim Verschieben einer solchen Mailbox zurück nach On Premises tritt dieser Fehler auf:

Error: MigrationPermanentException: Cannot find a recipient that has mailbox GUID ''. --> Cannot find a recipient that has mailbox GUID '<‎GUID>'

Die „richtige“ Methode zum Bereitstellen neuer Benutzer in Office 365 besteht darin, neue Remotepostfächer zu erstellen.

Lösung

Man kann einen OnPremises-Benutzer auch nachträglich mit seiner „echten“ Exchange-Online Mailbox verbinden.

Man schaltet einfach die Remote-Mailx im Exchgange ein und trägt die Online-GUID des Postfaches ein.

1. In der OnPremises Exchange PowerShell (EMS) die Remote-Mailbox einschalten:

Enable-RemoteMailbox <USER> –RemoteRoutingAddress <[email protected]>

Die RemoteRoutingAddress via AADConnect und dem Hybrid-Agenten sieht immer gleich aus „[email protected]“.

2. Die GUID der Exchange Online Mailbox in der Exchange Online PowerShell abfragen:

Get-Mailbox –Identity <UPN> | fl Identity,ExchangeGUID

3. In der OnPremises Exchange PowerShell (EMS) genau diese GUID wieder eintragen:

Set-RemoteMailbox <USER> –ExchangeGUID <GUID>

Das funktioniert natürlich in beide Richtungen, also auch für Benutzer-Objekte die in der Exchange Online EMC nicht mehr angezeigt werden. Interessanterweise beschreibt Microsoft in diesem Artikel nur den Weg in die Cloud 😇

App Kennwort für Microsoft 365 Exchange Online Postfach erstellen

Nicht schnell eingerichtet, aber sehr hilfreich: App Kennwörter als Ergänzung zur Multi-Faktor Authentifizierung – als Teil von Microsoft 365 ist ein fundamentaler und sehr gut umgesetzer Schutzfaktor für den Zugang.

Der geneigte Microsoft 365 Administrator kann Multi-Faktor Authentifizierung mit wenigen Klicks (oder via PowerShell) für einzelne oder alle Anwender aktivieren. Wie steht es aber um statische App Kennwörter – Wie erstellt man nun für ältere Programme oder SMTP-Clients (Kopierer, Scanner, CNC-Maschinen …) App-Kennwörter?

Limitierungen bei App Kennwörtern

  • Pro Benutzer maximal 40 App-Kennwörter
  • App-Kennwörter funktionieren nur in Microsoft 365, auch bei Hybrid-Szenarien nicht im lokalen Server
  • Funktioniert nicht bei „bedingtem Zugriff“ mit MFA (und modernern Auth)
  • App Kennwörter werden generiert (z.B. xmnfgsaofn3DSk) vorgegeben und können nicht geändert werden. Muss ein Kennwort „getauscht“ werden, geht das nur über löschen > Neu
  • Bei den „Hohen Sicherheitsstandarts“ muss MFA pri User erzwungen sein

Schritt 1 – App-Kennwörter für Benutzer erlauben

Man kann App Kennwörter nur erlauben, wenn die Azure AD Multi-Factor Authentication für den betreffenden Nutzer aktiviert ist.

  1. „Mehrstufige Authentifizierung“ Center als Administrator öffnen: https://account.activedirectory.windowsazure.com/UserManagement/MultifactorVerification.aspx
  2. Ganz Oben (!) unter „diensteinstellungen“ den „Benutzern das Erstellen von App-Kennwörtern zum Anmelden bei nicht browserbasierten Apps gestatten“

Schritt 2 – MFA erzwingen

Ganz oben unter „benutzer“ muss die Verwendung von MFA erzwungen werden, wenn die „Hohen Sicherheitsstandarts“ für das AzureAD eingeschaltet sind (Standard seit 2020).

Die Einstellung wird in aller Regel nicht sofort aktiv, aber man kann die Übernahme erzwingen, indem man als Administrator alle Sitzungen des Nutzers abmeldet und der Nutzer sich neu (in einem Browser) anmeldet

Schritt 2 – App Kennwort erstellen

  1. Das My-Signins Center als Benutzer (nicht mehr als Administrator) öffnen: https://mysignins.microsoft.com/security-info
  2. Unter Sicherheitsinformationen > Methode hinzufügen ein App Kennwort einrichten

Exchange OnPremises Ressourcen (Ressourcen-Postfächer wie Räume) nach Exchange Online migrieren

Benutzer-Postfächer kann man im Exchange Control Panel (ECP) durch einen schnellen Klick auf „Postfach verschieben > Zu Exchange Online“ recht einfach verschieben.

Leider hat Microsoft noch keine solche Funktion für Ressourcenmailboxen eingebaut. Also muss man Räume und Geräte manuell an der PowerShell verschieben. Das geht allerdings relativ problemlos.

Raum- oder Gerätepostfächer zu Exchange online verschieben

Zuerst eine Verbindung zur Exchange Online PowerShell herstellen:

PS C:\> Import-Module ExchangeOnlineManagement
PS C:\> Connect-ExchangeOnline

Dann ein Credential-Objekt für die lokale Domäne erstellen:

PS C:\> $OnPremCred = Get-Credential

Und schliesslich die Migrationsaufträge (MoveRequests) erstellen:

PS C:\> New-MoveRequest -Identity "<Name der Ressource>" -Remote -RemoteHostName <Name Exchange> -TargetDeliveryDomain <Tenant Name>.onmicrosoft.com -RemoteCredential $OnPremCred

Mit den üblichen Tools wie Get-MoveRequest lässt sich der Auftrag dann verfolgen. Im GUI sieht man diese allerdings leider nicht – dafür freifen Parameter wie das BadItemLimit und so weiter.

Benutzerprofil-Datenträger Maximal Größe nachträglich anpassen

In einer RDS-Sammlung kann man die maximal Größe einer User Profile Disk bei der Erstellung vorgeben. Nachträgliche Änderungen sind jedoch nicht mehr möglich. Die Option „Maximale Größe“ ist ausgegraut. Man müsste die ganze Sammlung dafür eigentlich neu erstellen …

Screenshot RDS Sammlung Konfiguration, Maximale Größe der VHDX ist ausgegraut
Die Option maximal Größe ist ausgegraut

Lösung

Man muss direkt das VHDX-Template das die Sammlung bei der Erstellung anlegt bearbeiten. Das Template heisst UVHD-template.vhdx und liegt in dem in der Sammlung festgelegten Share.

Die VHDX „Festplatte“ vergrößert man am einfachsten mit DISKPART.

C:> Diskpart

DISKPART> select vdisk file="F:\vhdx\UVHD-template.vhdx"
(Datei auswählen)

DISKPART> expand vdisk maximum=20000
(Vergrößern, 20000 = 20 Gbyte)

DISKPART> attach vdisk
(vDisk mounten)

DISKPART> list volume
(Volumes auflisten)

DISKPART> select volume <VOLUME-ID>
(Auswählen des Volumes, die ID der VHDX-Partition wählen)

DISKPART> extend

DISKPART> detach vdisk

DISKPART> exit

Im Live-Betrieb sieht das dann so aus:

Leider wird die Anzeige im Windows Server-Manager dazu nie aktualisiert, der Wert bleibt im GUI auf dem erstmalig eingetragenen Wert stehen. Die Box also müsste eigentlich „Maximale Größe bei erstellung“ heißen. Da der Server-Manager aufgrund seiner Fehler und generellen Schwerfälligkeit grundsätzlich aber nicht unbedingt das Lieblingswerkzeug von Administratoren ist, kann man diese rein kosmetische Angabe dort ganz gut ignorieren.