KCD für BlackBerry Work einrichten und prüfen

Ein Benutzer öffnet BlackBerry Work, und Mail, Kalender und Kontakte synchronisieren sich mit Exchange, ohne dass er sein AD-Passwort in die App tippen muss. Dafür sorgt Kerberos Constrained Delegation (KCD): UEM holt im Namen des Benutzers ein Kerberos-Ticket für Exchange, und Work meldet sich damit an.

Wir richten das am Beispiel uemfaq.de als Pilot ein: ein Realm, ein UEM Core, ein Exchange-Server, ein Pilotpostfach, Work auf dem iPhone. Es gilt für BlackBerry UEM 12.24 on-premises, BlackBerry Work 3.20 und Exchange Server SE. Die gemeinsame AD- und UEM-Grundlage, also KCD-Konto, Keytab und UEM-Felder, steht in der gemeinsamen AD- und UEM-Einrichtung für KCD. Hier geht es um alles, was Work und Exchange zusätzlich brauchen.

Warum KCD für BlackBerry Work?

Ohne KCD meldet sich Work mit Benutzername und AD-Passwort an Exchange an. Das Passwort tippt der Benutzer in die App, und nach jedem Passwortwechsel will Work das neue. Es gibt andere Wege ohne Passwort, aber sie lösen andere Aufgaben:

• Clientzertifikat. Work meldet sich mit einem Benutzerzertifikat an [1]. Dafür braucht jeder Benutzer ein Zertifikat, und Exchange muss die Zertifikatsanmeldung annehmen.
• Modern Authentication. Work holt ein Token bei einem Identity Provider statt eines Passworts. Dafür brauchen Exchange, Identity Provider und Work eine eigene, aufeinander abgestimmte Konfiguration [2][3]. Das ist ein eigenes Projekt.

KCD setzt an der bestehenden Windows-Anmeldung von Exchange an. Exchange bekommt ein ganz normales Kerberos-Ticket des Benutzers, nur besorgt es UEM statt des Geräts [4]. Für die KCD-Anmeldung braucht Work kein AD-Passwort, und ein Passwortwechsel des Benutzers berührt den Weg nicht.

Was danach funktioniert und wer das Ticket holt

Der Pilotbenutzer pilot01 öffnet Work, und Work synchronisiert über Exchange ActiveSync (EAS) Mail, Kalender und Kontakte. Funktionen wie Kalenderanhänge oder freigegebene Kalender laufen über Exchange Web Services (EWS) [1][5]. Beide Wege melden sich mit KCD an. Das Entsperren von Work mit Dynamics-Passwort oder Biometrie bleibt davon unberührt.

Wie beim Browser laufen zwei Wege nebeneinander. Der Datenweg führt Work über das Dynamics-Connectivity-Profil zu Exchange, im Pilot über BlackBerry Proxy [6]. Den Ticketweg eröffnet Exchange, indem es Kerberos verlangt. Work bittet dann UEM Core um ein Ticket. Core holt es mit seinem KCD-Konto per Protokollübergang und eingeschränkter Delegation beim KDC und gibt es an Work zurück, und Work legt es Exchange vor [4].

Daraus ergeben sich drei Bausteine:

1. Die KCD-Identität von UEM, im Pilot svc_uem mit seiner Keytab. Sie stammt aus der gemeinsamen Einrichtung.
2. Die Identität, mit der Exchange Tickets entschlüsselt. Bei Exchange ist das ein Alternate Service Account (ASA), ein Computerkonto, das die SPNs der Exchange-Namen trägt [7].
3. Die Delegation: Für Work ergänzen wir sie um genau den Exchange-SPN, den Work braucht. Ziele, die andere Apps schon nutzen, bleiben erhalten.

Ein Ticket heißt noch nicht, dass Exchange die Anmeldung annimmt, und eine angenommene Anmeldung heißt noch nicht, dass Work Mail abruft. Diese drei Stufen prüfen wir am Ende getrennt.

Unser Pilot: ein Postfach, ein Realm, ein fester Zielname

Wir starten mit abgeschlossener gemeinsamer KCD-Einrichtung: UEM Core meldet sich mit der Keytab beim KDC an, und Work ist für pilot01 aktiviert, bisher mit Passwort. Exchange SE läuft auf einem Server, ex01.uemfaq.de, erreichbar unter outlook.uemfaq.de. Die Uhren von Exchange, UEM und DC laufen synchron. Liegen Exchange und UEM zeitlich auseinander, zeigt Work „Offline“ oder fragt doch nach dem Passwort [8].

Für den Pilot nehmen wir das ASA-Konto von Anfang an, obwohl nur ein Server antwortet. So steht der Ticketempfänger fest, und beim späteren Ausbau auf mehrere Server bleibt der Namensraum gleich [7].

Work bekommt im Pilot feste Endpunkte für EAS und EWS. Autodiscover bleibt leer, damit Work direkt mit outlook.uemfaq.de spricht und du nur einen Namen vorbereiten und prüfen musst [9]. Wie Autodiscover dazukommt, steht weiter unten unter „Was wäre wenn …“.

Für die Produktion

Im Pilot ist svc_uem zugleich UEM-Dienstkonto und KCD-Konto. In der Produktion trennst du beides, damit die Keytab nicht den Schlüssel des Dienstkontos enthält und ein Keytab-Wechsel die UEM-Dienste nicht anhält [10]. Die Gründe und den Umzug des SPN beschreibt die gemeinsame Einrichtung. Die Delegationsziele aus Schritt 4 trägt dann das KCD-Konto.

Ein Core und ein Realm halten den Pilot überschaubar. Betreibst du mehrere Cores, richtest du jeden gleich ein und nimmst jeden einzeln ab, denn ein einziger abweichender Core reicht für sporadische Anmeldefehler in Work [11]. Wie das geht, steht in der gemeinsamen Einrichtung unter mehrere UEM Cores. Liegt Exchange in einem anderen Realm, muss dort ein Core im Realm der Exchange-Ressource stehen [4]; die übrigen Voraussetzungen stehen unter Ziele in mehreren Realms.

Exchange für Kerberos vorbereiten

1. Den Ausgangszustand lesen

Bevor du etwas änderst, liest du in der Exchange Management Shell auf ex01 aus, was die virtuellen Verzeichnisse für EAS und EWS heute anbieten [12][15]:

PS C:\> Get-ActiveSyncVirtualDirectory -Server ex01 | Format-List Identity,*url*,*auth*
PS C:\> Get-WebServicesVirtualDirectory -Server ex01 | Format-List Identity,*url*,*auth*

Notier dir die Werte, sie sind dein Rückweg. Ab Werk bietet EAS im Frontend nur Basic an, EWS bietet Windows-Authentifizierung an [14].

2. Windows-Authentifizierung an EAS einschalten

Work braucht an EAS und EWS Windows-Authentifizierung mit Negotiate. Bei EAS fehlt sie meist, und genau dort scheitert KCD dann [15]. Du schaltest sie zusätzlich ein; Basic bleibt für andere Clients bestehen:

PS C:\> Set-ActiveSyncVirtualDirectory -Identity "ex01\Microsoft-Server-ActiveSync (Default Web Site)" -WindowsAuthEnabled $true

Falls die Abfrage aus Schritt 1 bei EWS keine Windows-Authentifizierung zeigt, ergänzt du sie dort ebenso [15]:

PS C:\> Set-WebServicesVirtualDirectory -Identity "ex01\EWS (Default Web Site)" -WindowsAuthentication $true

Bei EAS zählt der Schalter selbst: Ein Eintrag Negotiate in einer Methodenliste ersetzt dort keine eingeschaltete Windows-Authentifizierung [15][12].

Für die Produktion

Die eigene Work-Konfiguration begrenzt nur, wer die Pilotwerte bekommt. Die Windows-Authentifizierung an EAS bietet Exchange allen Clients an. Ist KCD global eingeschaltet, nehmen Work, Tasks und Notes auf iOS den KCD-Weg, sobald Exchange ihn anbietet, auch wenn ihre eigene Konfiguration KCD nicht vorsieht [16]. Schalte EAS deshalb erst um, wenn ASA und Delegation aus Schritt 3 und 4 stehen, und beobachte danach auch die Anmeldungen anderer iOS-Benutzer. Wirklich getrennt vom Betrieb testest du nur in einer eigenen Testumgebung.

3. Das ASA-Konto anlegen und den Exchange-SPN zuordnen

Das ASA-Konto ist ein Computerkonto ohne eigenen Server. Wir legen es so an [7]:

PS C:\> New-ADComputer -Name EXASA -AccountPassword (Read-Host "Kennwort" -AsSecureString) -Description "Alternate Service Account fuer Exchange" -Enabled $true -SamAccountName EXASA
PS C:\> Set-ADComputer EXASA -Add @{"msDS-SupportedEncryptionTypes"="28"}

Dann verteilst du die Anmeldedaten des Kontos auf Exchange. Das Skript liegt im Scripts-Verzeichnis der Exchange-Installation [7]:

PS C:\> .\RollAlternateServiceAccountPassword.ps1 -ToSpecificServer ex01.uemfaq.de -GenerateNewPasswordFor 'UEMFAQ\EXASA$'

Erst danach ordnest du den SPN dem ASA-Konto zu, mit Duplikatprüfung. Vorher prüfst du, ob er schon an einem anderen Konto hängt [7]:

PS C:\> setspn -F -Q HTTP/outlook.uemfaq.de
PS C:\> setspn -S HTTP/outlook.uemfaq.de 'UEMFAQ\EXASA$'

Ob Exchange die Anmeldedaten übernommen hat, zeigt der Status, ohne dass ein Kennwort ausgegeben wird [19]:

PS C:\> Get-ClientAccessService -Identity ex01 -IncludeAlternateServiceAccountCredentialStatus | Format-List Name,AlternateServiceAccountConfiguration

Das IIS-Rezept aus dem Browser-Pilot, ein eigenes App-Pool-Konto mit useAppPoolCredentials=true, überträgst du nicht auf Exchange. Bei Exchange verwaltet der Dienst „Microsoft Exchange Service Host“ das ASA-Konto [7].

4. Die Delegation um das Exchange-Ziel ergänzen

svc_uem darf bisher zu den Zielen aus der gemeinsamen Einrichtung delegieren. Jetzt kommt der Exchange-SPN dazu. Zuerst liest du die bestehende Liste, dann ergänzt du sie; -Add fügt hinzu und lässt vorhandene Ziele stehen [4][20]:

PS C:\> Get-ADUser svc_uem -Properties msDS-AllowedToDelegateTo,TrustedToAuthForDelegation
PS C:\> Set-ADUser svc_uem -Add @{'msDS-AllowedToDelegateTo'='HTTP/outlook.uemfaq.de'}

„Trust this user for delegation to specified services only“ und „Use any authentication protocol“ sind aus der gemeinsamen Einrichtung schon gesetzt [4].

Für die Produktion

Jedes Delegationsziel erweitert, für welche Dienste UEM im Namen beliebiger Benutzer Tickets holen darf. Trag deshalb nur die Namen ein, die Work tatsächlich anspricht, und notiere, welche Ziele du für Work ergänzt hast. Nur diese nimmst du beim Rückweg wieder heraus.

UEM und Work für den Pilot konfigurieren

5. Den Benutzernamen prüfen: „Use explicit UPN“

UEM baut für jedes Ticket den Principal des Benutzers. Für KCD muss das der implizite UPN sein, also Anmeldename plus AD-Domäne. Ist global „Use explicit UPN“ eingeschaltet, nimmt UEM stattdessen das UPN-Attribut aus dem AD. Weichen beide ab, scheitert der Protokollübergang [19].

Für pilot01 sind beide gleich, pilot01@uemfaq.de. Dann spielt die Stellung des Schalters keine Rolle.

In unserer eigenen Umgebung war genau das der erste Stolperstein. Das AD hieß intern anders als der Anmeldesuffix, mit dem die Benutzer arbeiten. Mit eingeschaltetem „Use explicit UPN“ scheiterte der Protokollübergang mit Fehler 63, „No service creds“. Nachdem wir den Schalter global ausgeschaltet und in der Work-Konfiguration keinen eigenen UPN-Typ gesetzt hatten, lieferte UEM die Tickets für beide Exchange-Namen, ohne Neustart von UEM und ohne neue Aktivierung von Work. Einen Neustart verlangt der Schalter auch nicht [20].

Für die Produktion

„Use explicit UPN“ gilt für alle Dynamics-Apps [20]. Brauchen andere Apps den expliziten UPN, etwa Work mit Microsoft 365, bleibt global der implizite UPN und nur deren eigene Work-Konfiguration bekommt „Explicit UPN“ als UPN-Typ [3].

Verwaltet UEM auch ChromeOS-Geräte, kann deren Synchronisation den UPN überschreiben, den Dynamics für KCD verwendet. Sie läuft alle zwölf Stunden. Plane dann nach jedem ChromeOS-Lauf eine Company Directory Sync ein und prüf danach UPN und Ticket [21].

6. Den Datenweg zu Exchange freigeben

Im Dynamics-Connectivity-Profil des Pilotbenutzers trägst du outlook.uemfaq.de als zusätzlichen Server mit Port 443 ein. Als Route wählst du BlackBerry Proxy und als Primary deinen vorhandenen Proxy-Cluster [6]:

Hat die Work-App selbst ein eigenes Connectivity-Profil als Override, gilt dieses statt des Benutzerprofils [22]. Prüf das, bevor du dich über eine falsche Route wunderst.

Für die Produktion

Im Pilot reicht ein Proxy-Cluster. In der Produktion trägst du für den Exchange-Namen zusätzlich einen Secondary-Cluster ein, sofern du einen hast, damit Work bei Ausfall des ersten weiter synchronisiert [6].

7. Die Work-App-Konfiguration anlegen

Unter Apps > BlackBerry Work > BlackBerry Dynamics > App configuration legst du Work-KCD-Pilot an, als Kopie der bisherigen Konfiguration oder neu [23]. In der Pilotkopie schaltest du außerdem „Allow users to perform app diagnostics“ ein, damit du in Schritt 8 die Diagnose aufrufen kannst [1].

Anmeldeweg. „Use Kerberos Constrained Delegation in place of login/password“ ist an, „Use client certificate in place of login/password“ bleibt aus.

Exchange-Endpunkte. Unter „ActiveSync Server“ steht nur der Hostname outlook.uemfaq.de. „Default Domain“ bleibt leer, weil wir mit UPN arbeiten, und „Autodiscover URL“ bleibt im Pilot ebenfalls leer. „Enable Automated Autodiscover“ und „Use BEMS to perform AutoDiscover of the EAS/EWS endpoint for the user“ bleiben aus, damit Work wirklich nur die festen Endpunkte nimmt [1][9].

„Disable Exchange Web Services“ bleibt aus, und das Feld „Exchange Web Services URL endpoint“ bekommt die EWS-URL [1].

Vollständig lautet sie:

https://outlook.uemfaq.de/EWS/Exchange.asmx

Authentifizierung auf iOS. Für iOS gibt es zwei Methodengruppen, eine für ActiveSync und Autodiscover, eine für EWS. In beiden wählst du nur Negotiate. Damit antwortet Work auf das Negotiate-Angebot von Exchange und nimmt den KCD-Weg. Scheitert KCD, fällt Work nicht auf ein Passwort zurück [4]. Ob am Ende wirklich Kerberos angemeldet hat, zeigt erst die Prüfung, denn Negotiate kann auch NTLM aushandeln [24].

Benutzername. „UPN type“ bleibt ohne Auswahl (- Select -), damit die globale Einstellung aus Schritt 5 gilt. Bei den iOS-Benutzernamenformaten wählst du für ActiveSync und für EWS jeweils nur UPN. Beide Gruppen setzt du gleich, sonst meldet sich Work an EWS anders an als an EAS [1][5].

Durchsetzen. „Enforce App Configuration“ ist an. Damit übernimmt Work die Anmelde- und Endpunktwerte aus der Konfiguration neu, statt bei bisher gespeicherten Werten zu bleiben [25].

Eine alte Work-Konfiguration im JSON-Format liegt nicht in deiner Pilotkopie, sondern appweit im „Server configuration payload“ der Work-App. Werte, die dort stehen, gewinnen gegen die App-Konfiguration [26]. Lies den Payload deshalb vor dem Pilot. Für den Pilot darf er keinen der Anmelde- und Endpunktwerte von oben enthalten. Steht dort etwas, stellst du in einem eigenen Schritt für alle Work-Benutzer auf App-Konfiguration um [27].

Für die Produktion

„Nur Negotiate“ und „nur UPN“ gelten in der Work-Konfiguration, nicht am Exchange-Server. Basic und NTLM an Exchange schaltest du dafür nicht ab, solange andere Clients sie brauchen. Rolle die Konfiguration gruppenweise aus, jeweils als eigene Kopie, und prüf vorher, welche Overrides bei diesen Benutzern gelten.

8. Speichern, zuweisen und den Empfang prüfen

Du speicherst Work-KCD-Pilot und weist sie nur pilot01 zu, zusammen mit dem Connectivity-Profil aus Schritt 6. Auf dem iPhone öffnest du Work und startest im BlackBerry Dynamics Launcher die Diagnose („Run Diagnostics“). Sie zeigt, welche Konfigurationswerte Work tatsächlich bekommen hat [27]. Ob sich Work damit auch anmeldet, prüfen wir im nächsten Abschnitt.

Prüfen: Ticket, Exchange-Anmeldung und Work-Funktion

Dass Work nicht nach dem Passwort fragt, beweist noch kein KCD. Den Nachweis führst du in drei Stufen, jede mit einem frischen Zugriff, dessen Uhrzeit du notierst:

Ein erstes HTTP 401 von Exchange ist dabei normal: Damit verlangt Exchange Kerberos, und erst danach legt Work das Ticket vor. Damit die Events entstehen, muss am DC die Überwachung der Kerberos-Diensttickets und auf ex01 die Anmeldeüberwachung für erfolgreiche Vorgänge aktiv sein [28][24]. Ein 4624 entsteht nur für eine neue Anmeldesitzung; verwendet Work eine bestehende Sitzung weiter, fehlt es. Erst wenn alle drei Stufen zum selben Zugriff gehören, ist KCD für Work abgenommen. Scheitert eine Stufe, führt dich KCD für BlackBerry Work: Offline und Anmeldefehler lösen vom Symptom zur fehlerhaften Komponente.

Gegenprobe. Du sperrst die Delegation nur für den Pilotbenutzer und notierst vorher den bisherigen Wert [31]:

PS C:\> Get-ADUser pilot01 -Properties AccountNotDelegated
PS C:\> Set-ADAccountControl -Identity pilot01 -AccountNotDelegated $true

Werten kannst du das erst, wenn UEM wirklich ein neues Ticket holen muss. Die Änderung muss auf dem DC angekommen sein, den UEM fragt, und Work darf weder ein noch gültiges Ticket noch eine bestehende Exchange-Sitzung weiterverwenden. Ein Neustart der App reicht dafür nicht. Am einfachsten wartest du, bis Ticket und Sitzung abgelaufen sind. Dann muss Stufe 1 scheitern: am DC kein erfolgreiches 4769 mit Delegation für pilot01, in Work keine neue Synchronisierung. Synchronisiert Work weiter, ohne dass ein neuer Ticketversuch zu sehen ist, hast du die Gegenprobe noch nicht ausgewertet, und bestanden ist sie damit auch nicht. Anschließend setzt du den notierten Wert zurück, im Beispiel -AccountNotDelegated $false, und wiederholst den Positivlauf.

Rückweg

Halte vor dem Pilot fest, was du änderst: Windows-Authentifizierung an EAS und EWS, ASA-Konto und SPN, das Delegationsziel, „Use explicit UPN“, Connectivity-Profil und Work-Zuweisung. Zurück heißt: alte Work-Konfiguration und Zuweisung wiederherstellen, „Use explicit UPN“ auf den notierten Wert setzen und nur das Delegationsziel entfernen, das du für Work ergänzt hast:

PS C:\> Set-ADUser svc_uem -Remove @{'msDS-AllowedToDelegateTo'='HTTP/outlook.uemfaq.de'}

Die Exchange-Werte setzt du auf den Ausgangszustand aus Schritt 1. War Windows-Authentifizierung an EAS vorher aus, nimmst du sie wieder heraus:

PS C:\> Set-ActiveSyncVirtualDirectory -Identity "ex01\Microsoft-Server-ActiveSync (Default Web Site)" -WindowsAuthEnabled $false

ASA-Konto und SPN bleiben, wenn andere Clients mit Kerberos daran hängen. Die gemeinsame KCD-Einrichtung bleibt unangetastet, weil auch andere Dynamics-Apps sie nutzen. Zum Schluss prüfst du, dass pilot01 mit der alten Konfiguration wieder Mail abruft.

Was wäre wenn …

Für die Produktion

Der Pilot lässt bewusst einiges weg. Bevor du ausrollst, gehst du deshalb diese Fälle durch:

• Mehrere Exchange-Server: Alle Server hinter dem Namensraum brauchen dieselben ASA-Anmeldedaten, sonst scheitert Kerberos nur an manchen Knoten [7].
• Weitere Benutzer: Jeder Benutzer muss delegierbar sein. Konten in „Protected Users“ [30] oder mit „sensitive and cannot be delegated“ [29] fallen heraus.
• Logs: Erhöhte Protokollierung für die Abnahme setzt du danach zurück; Kerberos-Debugdaten enthalten Identitäten und gehören in kein Helpdesk-Ticket.

… Work Autodiscover nutzen soll?

Dann bleibt „ActiveSync Server“ leer, und das Feld „Autodiscover URL“ bekommt die Autodiscover-URL. „Enable Automated Autodiscover“ und die Ermittlung über BEMS bleiben auch hier aus; die automatische Suche gilt als Sicherheitsrisiko, und die Ermittlung über BEMS setzt ein leeres URL-Feld voraus [9].

Vollständig lautet sie:

https://autodiscover.uemfaq.de/autodiscover/autodiscover.xml

Der Name autodiscover.uemfaq.de braucht dann denselben Weg wie outlook.uemfaq.de: Windows-Authentifizierung am Autodiscover-Verzeichnis, den SPN am ASA-Konto, das Delegationsziel und einen Eintrag im Connectivity-Profil [31][7]:

PS C:\> Get-AutodiscoverVirtualDirectory -Server ex01 | Format-List Identity,*auth*
PS C:\> Set-AutodiscoverVirtualDirectory -Identity "ex01\Autodiscover (Default Web Site)" -WindowsAuthentication $true
PS C:\> setspn -F -Q HTTP/autodiscover.uemfaq.de
PS C:\> setspn -S HTTP/autodiscover.uemfaq.de 'UEMFAQ\EXASA$'
PS C:\> Set-ADUser svc_uem -Add @{'msDS-AllowedToDelegateTo'='HTTP/autodiscover.uemfaq.de'}

Ab Werk bietet Autodiscover Windows-Authentifizierung schon an [14]; die Abfrage zeigt dir, ob das bei dir noch so ist. Prüf die Stufen 1 und 2 dann auch für HTTP/autodiscover.uemfaq.de. Ein Ticket für diesen Namen allein zeigt nicht, dass Work Autodiscover erfolgreich abgefragt hat. Abgenommen ist Autodiscover erst, wenn Work damit seine Exchange-Endpunkte findet und danach synchronisiert.

… mehrere Exchange-Server hinter einem Load Balancer stehen?

Dann gilt derselbe Namensraum für alle, und jedes Ticket für HTTP/outlook.uemfaq.de muss jeder Server entschlüsseln können. Das ASA-Konto verteilst du deshalb auf alle Server, den ersten mit -GenerateNewPasswordFor, alle weiteren mit -CopyFrom [7]:

PS C:\> .\RollAlternateServiceAccountPassword.ps1 -ToSpecificServer ex02.uemfaq.de -CopyFrom ex01.uemfaq.de

Die SPNs bleiben am ASA-Konto, nicht an jedem Computerkonto. Sticky Sessions sind dafür nicht nötig [32]. Mit Extended Protection verträgt Exchange kein TLS-Offloading am Load Balancer; beim TLS-Bridging braucht der Load Balancer dasselbe Zertifikat wie Exchange [33].

… der Anmeldesuffix nicht zum AD-Realm passt?

Das war unser eigener Fall: Die Benutzer melden sich als name@uemfaq.de an, das AD heißt intern anders. Der alternative UPN-Suffix ist kein eigener Realm. Für KCD zählt der implizite UPN aus Anmeldename und AD-Domäne, deshalb bleibt „Use explicit UPN“ global aus, wie in Schritt 5 beschrieben [19].

… UEM-Dienst und KCD-Konto schon getrennt sind?

Dann bekommt das KCD-Konto, zum Beispiel svc_kcd, die Delegationsziele aus Schritt 4, nicht das Dienstkonto. In unserer eigenen Umgebung laufen die UEM-Dienste unter einem eigenen Dienstkonto, das die Keytab lesen darf. Das KCD-Konto trägt den Principal, die Delegation, das Recht „Act as part of the operating system“ und die Mitgliedschaft in der Windows Authorization Access Group. So eingerichtet holt UEM die Tickets für beide Exchange-Namen.

… BlackBerry Tasks und Notes dazukommen?

Tasks und Notes sprechen Exchange über EWS an, nicht über EAS [34]. Die EWS-Vorbereitungen gelten also auch für sie. Auf iOS nutzen Work, Tasks und Notes KCD, sobald es global aktiv ist und Exchange es anbietet, auch wenn ihre eigene Konfiguration es nicht vorsieht [16].

… deine Domänencontroller RC4 abschalten oder Windows Server 2025 nutzen?

Dann kann schon Stufe 1 scheitern, obwohl alles richtig eingerichtet ist. Die Einzelheiten und den bekannten Workaround findest du in der gemeinsamen Einrichtung im Abschnitt zu RC4 und Windows Server 2025 [35].