KCD für BlackBerry Work: Offline und Anmeldefehler lösen

Work ist aktiviert, Kerberos Constrained Delegation (KCD) ist eingerichtet, und trotzdem bleibt die App offline oder bekommt keine neuen Mails. Dann verfolgen wir einen einzelnen fehlgeschlagenen Zugriff bis zur ersten Übergabe, die nicht klappt, und korrigieren genau dort. Das gilt für UEM 12.24 on-premises, Work 3.20 auf iOS und Exchange Server SE. Änderungen an AD und Exchange übernimmt der zuständige Administrator.

Warum wir zuerst den Fehlerort suchen

An einer KCD-Anmeldung arbeiten mehrere Beteiligte mit. Work erreicht Exchange und bekommt eine Anmeldeaufforderung, die sogenannte Challenge. UEM Core holt dann beim Key Distribution Center (KDC) im Active Directory (AD) das Ticket des Benutzers und gibt es an Work zurück. Work legt es Exchange vor. Danach muss Exchange noch die Postfachfunktion erledigen, die Work angefordert hat [1].

Tauschst du gleichzeitig die Keytab, den Benutzernamen und Exchange-Einstellungen, kannst du den nächsten Befund kaum noch erklären. Wir lesen deshalb zuerst den Zustand, wie er ist, und ändern nur die Stelle, an der der Zugriff nachweislich abbricht. Den Maßstab liefert die Drei-Stufen-Prüfung für Work: Ticketbeschaffung, Exchange-Anmeldung und neue Work-Funktion beurteilen wir getrennt.

Was dein Work-Symptom schon eingrenzt

Was Work anzeigt, bestimmt, wo wir einsteigen. Für eine Ursache brauchen wir mehr: die Komponente, die Meldung und die Phase, in der der Fehler auftritt. Das gilt auch für Zahlen wie 63 oder 41 und für HTTP 401. Derselbe kurze Befund kann in ganz unterschiedlichen Abläufen auftreten [11][20][21][42].

Erwartet Work wirksam KCD, unterdrückt es die normale Netzwerk-Anmeldemaske und fällt bei einem KCD-Fehler nicht auf eine andere Methode zurück [1]. Auf iOS kann trotzdem Please Check and Re-Enter your Username & Password here - Login Failed erscheinen [34]. Das Dynamics-Passwort zum Entsperren ist davon unabhängig; eine fehlende Passwortfrage beweist keinen KCD-Erfolg [54].

Wie wir einen fehlgeschlagenen Zugriff verfolgen

Bevor wir Logs lesen, vergleichen wir die Uhren von UEM-Cores, DCs und Exchange-Knoten: Zeitabweichungen können Offline, eine Kennwortabfrage oder 401 verursachen. Liegt eine Abweichung vor, korrigieren wir zuerst die Zeitsynchronisation [25]. Danach prüfen wir im CORE-Log, ob die Antwort für diesen Zugriff ein Ticket oder einen Fehler enthält. Damit wissen wir, ob wir auf der UEM- oder der Exchange-Seite weitersuchen.

Für den Pilot

Wir nehmen pilot01, eine neue Funktion und ein kurzes Zeitfenster. Notiere den Zeitpunkt mit Zeitbasis, den verwendeten Endpunkt, den tatsächlich gewählten Core und den Exchange-Knoten, der antwortet. Work-KCD-Pilot und Dynamics-KCD-Pilot liest du zuerst nur aus. Eine bestehende Produktionsroute bleibt der Ausgangspunkt für den Vergleich.

Im Beispiel verfolgen wir eine neue Mail, die schon im Postfach liegt, über https://outlook.uemfaq.de/Microsoft-Server-ActiveSync. Für den späteren EWS-Vergleich nehmen wir https://outlook.uemfaq.de/EWS/Exchange.asmx. Eine Mail, die Work schon gespeichert hat, sagt nichts über den aktuellen Serverzugriff. Weil die Protokolle getrennt laufen, brauchst du für jedes eine eigene neue Funktion [26].

Zuerst prüfen, welche Konfiguration Work wirklich verwendet

Vergleiche die Work-Zuweisung von pilot01 mit den Werten, die in Run Diagnostics als empfangen erscheinen. Dafür muss Allow users to perform app diagnostics freigegeben sein. Prüfe die KCD-Erwartung, den EAS-Host, die EWS-URL, beide iOS-Methodengruppen samt Benutzerformaten und den UPN-Override [2][3]. Lies außerdem unter Settings > BlackBerry Dynamics > Global properties, ob Enable KCD (gc.krb5.enabled) aktiv ist [10].

Steht im appweiten Server configuration payload noch Legacy-JSON, gewinnt ein dort definierter Schlüssel gegen den entsprechenden Wert der App-Konfiguration. Fehlt der Schlüssel im JSON, gilt der App-Wert [3]. Einen widersprüchlichen JSON-Schlüssel korrigierst du deshalb im Payload, einen falschen App-Wert in der Work-Konfiguration, die tatsächlich zugewiesen ist. Enforce App Configuration kann die dafür vorgesehenen Endpunktwerte erneut anwenden. Prüfe danach wieder, was ankommt, und löse eine neue Funktion aus [2].

Für die Route schaust du zuerst, ob die App einen eigenen Connectivity-Override hat. Er ersetzt das Profil des Benutzers [4]. Im wirksamen Profil gewinnt Additional servers gegen Allowed domains. Vergleiche Host, Port und Route, die Work tatsächlich benutzt [5]. Passt der Weg nicht, korrigierst du das Profil oder seinen Override und verfolgst denselben neuen Zugriff noch einmal. Ein Proxycluster mit Primary und Secondary beschreibt den Datenweg. Welcher Core das Ticket holt, legt er nicht fest [1][5].

Für die Produktion

Eine Pilotkopie wirkt nur auf die Benutzer, denen sie zugewiesen ist. Der appweite JSON-Payload und die globalen UPN-Einstellungen reichen weiter [3][10]. Plane Änderungen daran mit Blick auf alle anderen, die davon abhängen. Unter iOS schließt ein ausgeschalteter KCD-Haken in der App allein den KCD-Weg nicht aus: Work für iOS nutzt KCD, solange es global aktiv ist [6]. Für die Wiederherstellung nutzt du den Work-Rückweg.

CORE, DC, IIS und HttpProxy demselben Zugriff zuordnen

Jeder Core schreibt eigene CORE-Dateien auf seinem Host. Standard ist C:\Program Files\BlackBerry\UEM\Logs\yyyymmdd, maßgeblich ist der konfigurierte Server-log-path [7]. RequestKerberosKCDServiceTicket und der Ziel-SPN zeigen die Anfrage. Die trackingID hilft, ihre Verarbeitung im CORE-Log zuzuordnen; sie verbindet CORE nicht mit DC oder Exchange [11][19]. Der Service Principal Name (SPN) bezeichnet den Kerberos-Dienst, im Beispiel HTTP/outlook.uemfaq.de.

Impersonating User for= nennt den Benutzer erst auf Debug-Level [11][19]. Setze deshalb vor dem Testzugriff unter Settings > Infrastructure > Logging > Global logging settings > Service logging override das CORE-Level auf Debug. Das gilt für alle CORE-Instanzen und braucht keinen Neustart [8]. Der serverbezogene Schalter gc.krb5.debug verlangt dagegen einen Neustart [9].

KerberosKCDServiceTicket heißt auch eine Fehlerantwort. Selbst Writing to Endpoint … KerberosKCDServiceTicket kann ein error-Objekt mit errorCode enthalten. Lies den Antwortinhalt; der Nachrichtenname und die Schreiboperation beweisen kein Ticket [11][42]. Am DC zeigt Ereignis 4769 eine Dienstticketanforderung, 0x0 steht für Erfolg. Service Name nennt das Zielkonto: für S4U2Self svc_uem, für das Exchange-Ticket per S4U2Proxy EXASA$ [12][39].

Auf Exchange verbinden IIS und HttpProxy Zeit, Pfad, Identität und Knoten. IIS-W3C schreibt in UTC und nach dem jeweiligen #Fields:-Header. cs-username = - bedeutet anonym [14]. Die HttpProxy-Logs liegen unter %ExchangeInstallPath%\Logging\HttpProxy\Eas und Ews, wenn Work Autodiscover nutzt, auch unter Autodiscover. Welche Felder es für RequestId, AuthenticatedUser, ServerHostName, TargetServer, Status und Fehler gibt, liest du aus dem tatsächlichen CSV-Header [15][16].

Für eine ausgewählte IIS-Datei nimmst du auf dem bedienenden Exchange-Knoten diese PowerShell. Du brauchst Leserechte auf die Datei. Setze ihren tatsächlichen Pfad und dein UTC-Zeitfenster ein. Der Parser richtet sich nach dem aktiven Header [14]. Als Ergebnis bekommst du die zusammengehörigen EAS- und EWS-Zeilen mit ihren drei Statusfeldern.

PS C:\> function Read-IisW3c {
PS C:\>     param([Parameter(Mandatory)][string]$Path)
PS C:\>     $columns = $null
PS C:\>     foreach ($line in (Get-Content -LiteralPath $Path)) {
PS C:\>         if ($line -match '^#Fields:\s*(.+)$') {
PS C:\>             $columns = $Matches[1] -split '\s+'
PS C:\>             continue
PS C:\>         }
PS C:\>         if ([string]::IsNullOrWhiteSpace($line) -or $line.StartsWith('#')) { continue }
PS C:\>         if (-not $columns) { throw 'W3C-Header fehlt.' }
PS C:\>         $cells = $line.Trim() -split '\s+'
PS C:\>         if ($cells.Count -ne $columns.Count) { throw 'Zeile passt nicht zum Header.' }
PS C:\>         $row = [ordered]@{}
PS C:\>         for ($i = 0; $i -lt $columns.Count; $i++) { $row[$columns[$i]] = $cells[$i] }
PS C:\>         [pscustomobject]$row
PS C:\>     }
PS C:\> }
PS C:\> $iisFile = Read-Host 'Vollständiger Pfad der IIS-W3C-Datei'
PS C:\> $fromUtc = [datetimeoffset](Read-Host 'Beginn als ISO-Zeit mit Z für UTC')
PS C:\> $toUtc = [datetimeoffset](Read-Host 'Ende als ISO-Zeit mit Z für UTC')
PS C:\> Read-IisW3c -Path $iisFile | Where-Object {
PS C:\>     if (-not $_.date -or -not $_.time -or -not $_.'cs-uri-stem') {
PS C:\>         throw 'date/time/cs-uri-stem fehlen.'
PS C:\>     }
PS C:\>     $stamp = [datetimeoffset]::ParseExact(
PS C:\>         ($_.date + ' ' + $_.time + ' +00:00'), 'yyyy-MM-dd HH:mm:ss zzz',
PS C:\>         [System.Globalization.CultureInfo]::InvariantCulture)
PS C:\>     $stamp -ge $fromUtc -and $stamp -lt $toUtc -and
PS C:\>         ($_.'cs-uri-stem' -like '/Microsoft-Server-ActiveSync*' -or
PS C:\>          $_.'cs-uri-stem' -like '/EWS/*')
PS C:\> } | Select-Object date,time,cs-method,cs-uri-stem,cs-host,cs-username,
PS C:\>     sc-status,sc-substatus,sc-win32-status

Der Filter nimmt Unterpfade wie /Microsoft-Server-ActiveSync/default.eas mit. Liegt das virtuelle Verzeichnis woanders, passt du das Präfix an. Fehlt ein Zugriff, prüfst du Datei, Knoten, Zeitfenster, Schema und Auditierung sowie den noch nicht geschriebenen IIS-Puffer [14]. Bestehende Tickets und Anmeldesitzungen können weiterlaufen, ohne neue Ereignisse 4769 oder 4624 zu erzeugen. Work nur wieder zu öffnen, erzwingt deshalb keinen frischen Anmeldebefund [12][13]. Vorhandene Request-IDs helfen beim Zuordnen. Eine gemeinsame ID über alle vier Stellen setzen wir nicht voraus.

Für die Produktion

Erhöhe nur das Level, das du brauchst, und begrenze Dauer, Zugriff und Aufbewahrung. Ein globales CORE-Level erfasst alle Core-Instanzen. Den Neustart für serverbezogenes KCD-Debug planst du separat [8][9]. Stelle danach das Ausgangslevel wieder her. Identitäten und mögliches Ticketmaterial bleiben im geschützten Diagnosebereich.

UEM liefert kein Ticket: Wo bricht der Kerberos-Weg ab?

Das KCD-Konto meldet sich schon beim Start nicht an

Beginnt der Abbruch mit KCD failed to login und Unable to obtain password from user, schauen wir uns die Anmeldung der Dienstidentität an. Ein falsches KCD-Konto kann diesen Befund auslösen, eine unpassende Keytab ebenfalls [17][19]. Folgt stattdessen Pre-authentication information was invalid (24), prüfst du das Kennwort und seine Zeichen gegen den Keytab-Stand [19]. Den Korrekturweg findest du im Kennwortwechsel-Abschnitt. Die Benutzervertretung kommt erst danach. Mit S4U2Self holt sich der Dienst für den Benutzer ein Ticket zu sich selbst, mit S4U2Proxy anschließend das Ticket zum Exchange-Dienst [39].

Vergleiche auf dem betroffenen Core den konfigurierten Principal, den Keytab-Pfad, ob der Dienst die Keytab lesen kann, und den Schlüsselstand mit der vorhandenen Einrichtung. Eine nachgewiesene Abweichung korrigierst du über die gemeinsame AD- und UEM-Einrichtung. Nach einer korrigierten Keytab oder krb5.conf ist der CORE-Neustart nötig [19]. Danach erwartest du zuerst einen funktionierenden Dienstlogin und dann einen neuen Ticketversuch für den Benutzer.

S4U2Self braucht ein FORWARDABLE-Ticket

Steht S4U2self needs a FORWARDABLE ticket im Stack, prüfst du ab UEM 12.20 die krb5.conf: Fehlt die Datei, der Eintrag oder steht er auf false, scheitert dieser Übergang [19]. Ergänze in C:/kcd/krb5.conf:

[libdefaults]
forwardable = true

Trage die Datei in den KCD-Eigenschaften des betroffenen Cores unter Location of krb5.config file (gc.krb5.config.file) ein und starte BlackBerry UEM - UEM Core neu [9][19]. Der gemeinsame KCD-Konfigurationsschritt zeigt den Zusammenhang. Danach verfolgen wir einen neuen Ticketversuch. Dieser Fehler trägt keinen Kerberos-Code und steht deshalb nicht in der Codeliste unten.

Fehler 63: Welchen Benutzer versucht UEM zu vertreten?

Steht Fail to create credential. (63) - No service creds im Stack, in dem UEM den Benutzer per S4U2Self vertritt, vergleichen wir den tatsächlich verwendeten Benutzerprincipal mit den UPN-Vorgaben [20]. Im Fehlerfall nennt Failed to impersonate userPrincipal … den verwendeten Namen [20]. Den User Principal Name (UPN) gibt es in zwei Formen. Der explizite UPN ist das AD-Attribut UserPrincipalName. Der implizite setzt sich aus Anmeldename und AD-DNS-Domäne zusammen. Im einfachen Beispiel ergeben beide pilot01@uemfaq.de. Ein abweichender Anmeldesuffix kann diese Gleichheit aufheben [20].

Mit dem ActiveDirectory-Modul und den nötigen AD-Rechten liest du Benutzer, Domäne und das tatsächliche KCD-Konto aus. Hast du Dienst- und KCD-Konto getrennt, ersetzt du svc_uem durch die konfigurierte KCD-Identität [18][20].

PS C:\> Get-ADUser -Identity pilot01 -Properties UserPrincipalName,AccountNotDelegated |
PS C:\>     Select-Object SamAccountName,UserPrincipalName,AccountNotDelegated
PS C:\> Get-ADDomain | Select-Object DNSRoot
PS C:\> Get-ADUser -Identity svc_uem -Properties ServicePrincipalName,
PS C:\>     msDS-AllowedToDelegateTo,TrustedToAuthForDelegation |
PS C:\>     Select-Object SamAccountName,ServicePrincipalName,
PS C:\>         msDS-AllowedToDelegateTo,TrustedToAuthForDelegation

Richte die Abfragen an die tatsächliche Benutzerdomäne. Passt der Stack zu abweichenden UPNs, haben wir zwei Wege: Entweder gleichen wir expliziten und impliziten UPN an, oder wir schalten Use explicit UPN global aus und wählen den UPN je App-Konfiguration. Dieser zweite Weg gilt ab UEM 12.18 und Work 3.12 [20]. Beim zweiten Weg bleibt Work-KCD beim impliziten UPN; entferne dafür einen eigenen Explicit UPN-Override in Work-KCD-Pilot [2]. Die globale UPN-Auswahl braucht keinen Neustart [10].

Für die Produktion

Use explicit UPN gilt für alle Dynamics-Apps [10]. Muss der Schalter aktiv bleiben, etwa für Modern Authentication, gleichen wir die beiden UPNs an [20]. Beim zweiten Weg bekommen nur die Apps, die es brauchen, ihre eigene Explicit UPN-Auswahl [2][20]. Bei übereinstimmenden UPNs kann die gemeinsame Einrichtung den globalen Schalter aktiviert lassen. Notiere vor einer Änderung den Ausgangswert.

Passt der verwendete Name zu keinem der beiden UPNs, prüfst du bei aktivem ChromeOS-Management den Synchronisationslauf: Er kann den Dynamics-UPN durch GoogleUserName ersetzen. Ein Company Directory Sync nach dem ChromeOS-Sync stellt ihn wieder her; bei unbekanntem Zeitpunkt lässt du ihn häufiger laufen [56]. Prüfe danach Zuweisung, empfangene Werte und den neuen Ticketversuch. Erst nach erfolgreicher Ticketbeschaffung beurteilen wir Exchange.

Der Work-Override bestimmt den UPN-Typ unabhängig vom ActiveSync-Benutzerformat [2]. Im gezeigten zweiten Lösungsweg bleibt das Dropdown ohne eigene Auswahl.

Das ActiveSync-Benutzerformat liest du in seiner eigenen Feldgruppe. Die UPN-Auswahl dieser Gruppe ersetzt keinen KCD-UPN-Override [2].

In unserer eigenen Umgebung lag die Grenze genau an diesem Übergang. Wir haben die explizite UPN-Vorgabe global und in Work zurückgenommen. Danach lieferte der laufende Core Tickets, Exchange antwortete aber weiter mit 401 ohne authentifizierten Benutzer. Die Ticketbeschaffung war damit repariert, und die nächste Prüfung gehörte an Exchange.

Fehler 41, 13 oder 7: Welche Gegenprüfung entscheidet?

Lies die Tabelle zusammen mit dem passenden Stack oder Zielbefund. Die SPN-Suche ändert nichts. Du führst sie mit den nötigen AD-Rechten für den angeforderten Namen aus [46]:

PS C:\> setspn -F -Q HTTP/outlook.uemfaq.de

• 41 (0x29) beim Dienstlogin: Prüfe Realm - Active Directory (gc.krb5.realm) auf jedem Core. Ein klein geschriebener Realm verhindert den Dienstlogin mit 41 [55]; UEM 12.24 verlangt ihn in Großbuchstaben [9]. Korrigiere ihn auf UEMFAQ.DE, starte CORE neu und prüfe den Dienstlogin erneut.
• 41 bei S4U2Self: Vergleiche Java, UEM und den angesprochenen DC mit dem Härtungsfall unten. Am betroffenen Server-2025-DC kann Ereignis 4769 mit 0x29 den Abbruch bestätigen [42][43].
• 13 (0xD) bei S4U2Proxy: Vergleiche den tatsächlichen SPN mit msDS-AllowedToDelegateTo, Protokollübergang und Delegierbarkeit des Benutzers. Ergänze nur das benötigte Ziel und erhalte die übrigen Ziele. Benutzerschutz bleibt eine eigene Entscheidung [1][11][18].
• 13 vor der Delegation: Prüfe zuerst global Enable KCD. Ist der Schalter aus, scheitert die Anfrage vor jeder Delegation; unter UEM 12.9 stand dann kerberos is not enabled mit Code 13 im CORE-Log [57]. Aktiviere den Schalter und beachte seinen Neustartbedarf [10].
• 7 (0x7) beim Zielticket: Frage den angeforderten SPN forestweit und seinen Eigentümer ab. Korrigiere einen falschen Endpunkt oder eine fehlende oder falsche Zuordnung an ihrer Quelle [12][45][46].

Findet die Suche keinen SPN, gehst du zurück zu Name und Registrierung. Bei einem Treffer prüfst du, ob er am vorgesehenen Eigentümer hängt. Bei mehreren Treffern geht es um die Eindeutigkeit. Der gemeinsame Exchange-Namespace gehört an die Identität des Alternate Service Account (ASA), im Beispiel EXASA$ [35]. Nach einer Korrektur im AD berücksichtigen wir die Replikation und verfolgen dann erneut Ticketanforderung, Zielanmeldung und Funktion.

Das Ticket kommt an, Exchange antwortet weiter mit 401

Eine Challenge oder eine gescheiterte Anmeldung?

Auf eine erste anonyme Anfrage kann Exchange regulär mit 401 und Negotiate antworten. Work holt daraufhin das Ticket über Core und versucht die Anmeldung erneut [1][21]. Negotiate kann Kerberos oder NTLM aushandeln, und auch mehrere 401 können zu einer Challengefolge gehören [21]. Entscheidend sind deshalb der Mechanismus und das Endergebnis des Zugriffs, den du verfolgst.

IIS ordnet 401.1 einem fehlgeschlagenen Logon zu, 401.2 einem Konfigurationsbezug und 401.3 einer Zugriffskontrolle auf die Ressource [22]. Lies dazu immer sc-win32-status, Pfad und Identität. Auch wenn IIS eine Identität auflöst, brauchst du den passenden Kerberos-Befund: Ein 4624 zur selben Zeit mit Authentication Package Kerberos belegt eine neue Anmeldesitzung am Ziel [13].

Was IIS und HttpProxy über denselben Aufruf sagen

Verbinde den IIS-Aufruf mit den HttpProxy-Feldern, die es für Benutzer, Frontend, Backend und Status gibt [14][16]. Filterst du zuerst nach dem Benutzer, dürfen anonyme Fehlerzeilen dabei nicht herausfallen. Fehlt eine Proxyzeile, prüfst du zuerst Protokollordner, Knoten, Schema und Zeitbasis. Der Abbruch kann auch vor einer auswertbaren Proxyzeile liegen [15].

401 2 5 passt zur ersten anonymen Challenge; 401.1 bezeichnet einen fehlgeschlagenen Logon [22][53]. Bleibt die Folge bei der Challenge stehen, suchen wir die nächste Anfrage samt Authentifizierungskontext. Eine 401.1 lenkt uns zur abgelehnten Anmeldung. Die Statusfelder allein beweisen weder die Vorlage eines Kerberos-Tickets noch dessen Mechanismus.

Legt Work keinen passenden Kerberos-Kontext vor, gehst du zurück zu Work, Route und einer neuen Anfrage. Kommt er an und lehnt das Ziel ihn ab, vergleichst du die Exchange-Dienstidentität des Knotens, der antwortet [35][45]. Nimmt Exchange den Benutzer an, geht es mit der fachlichen Antwort von EAS oder EWS weiter.

0x8009030E: Welche Credentials fehlen an welcher Stelle?

0x8009030E heißt SEC_E_NO_CREDENTIALS: Dem Security Package stehen keine Credentials zur Verfügung. Dezimal erscheint dasselbe Bitmuster als 2148074254, vorzeichenbehaftet als -2146893042 [23]. Eine ASA-Ursache folgt aus diesem SSPI-Befund noch nicht. Den Wert kann auch eine reguläre NTLM-Challengefolge enthalten, wenn der Kernelmodus der Windows-Authentifizierung ausgeschaltet ist [53].

Auf ex01 liest der Exchange-Administrator in der Exchange Management Shell aus, welche Anmeldung Exchange tatsächlich anbietet [24]. EAS-KCD braucht eingeschaltete Windows-Authentifizierung. Eine Abweichung korrigierst du gezielt am betroffenen Frontend über den Einrichtungsweg für Work.

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

Kommt der Kerberos-Kontext am richtigen Ziel an und wird abgelehnt, folgt weiter unten der Vergleich von ASA und Knoten. Nach der passenden Korrektur erwartest du eine angenommene Anmeldung im selben Pfad und danach die neue Funktion.

Die Anmeldung klappt, aber Work bekommt keine neuen Inhalte

EAS-Sync und EWS-Zusatzfunktion getrennt prüfen

Work nutzt Exchange ActiveSync (EAS) für Mail und Exchange Web Services (EWS) unter anderem für Kalenderanhänge und freigegebene Kalender oder Postfächer [26]. Kommt die neue Mail an, scheitert aber die zugehörige EWS-Funktion, vergleichst du die iOS-Methoden und Benutzerformate, die für EAS und EWS getrennt eingestellt sind, und die vollständige EWS-URL https://outlook.uemfaq.de/EWS/Exchange.asmx [2][58]. Eine Abweichung korrigierst du in der wirksamen Konfiguration und wiederholst genau die Funktion, die gescheitert ist.

EWS hat daneben eine eigene Methodengruppe. Vergleiche sie separat; eine passende ActiveSync-Auswahl stellt EWS nicht mit ein [2][58].

Der EAS-Sync-Status steht im Antwortkörper, auf Ebene des Kommandos, der Collection oder der Aktion; Status 1 bedeutet Erfolg [27]. Den Antwortkörper siehst du im EAS-Postfachlog; sammeln kann es der Exchange-Administrator etwa mit Get-EASMailboxLogs.ps1 für pilot01 [61]. IIS und HttpProxy zeigen diesen Körper nicht. Eine leere Syncantwort mit HTTP 200 kann regulär sein, wenn sich nichts geändert hat [49].

Die Exchange-Seite von EWS liest du zusätzlich unter %ExchangeInstallPath%\Logging\Ews [15]. ResponseClass, ResponseCode und gegebenenfalls MessageText stehen in der zugehörigen SOAP-Antwort; ordne eine erfasste Antwort dem protokollierten Aufruf zu [29]. Auch HTTP 200 kann einen fachlichen Fehler enthalten [28]. Begrenze zusätzliche Protokolldiagnose auf das betroffene Postfach und Zeitfenster; die Inhalte bleiben geschützt.

Mit Verwaltungsrechten für Exchange SE prüfst du die Freigabe des Postfachs, die EWS-Zugriffslisten und den Gerätezugriff [30][31][47][48]:

PS C:\> Get-CASMailbox -Identity pilot01 |
PS C:\>     Format-List ActiveSyncEnabled,EwsEnabled,EwsApplicationAccessPolicy,EwsAllowList,EwsBlockList
PS C:\> Get-OrganizationConfig |
PS C:\>     Format-List EwsEnabled,EwsApplicationAccessPolicy,EwsAllowList,EwsBlockList
PS C:\> Get-MobileDeviceStatistics -Mailbox pilot01 -ActiveSync |
PS C:\>     Format-List DeviceAccessState,DeviceAccessStateReason,LastSuccessSync

Ist eine Sperre für Postfach oder Gerät bestätigt, gibt der zuständige Administrator gezielt frei, und du wiederholst denselben Funktionsversuch. ErrorAccessDenied weist auf einen fachlichen Zugriffsfehler in EWS hin. Bei ErrorServerBusy wartest du die angegebene Zeit ab, statt immer schneller neue Anmeldeversuche zu starten [28][29]. Fehlen Felder in der Ausgabe, prüfst du erst das verfügbare Objektschema, bevor du daraus etwas schließt.

Autodiscover oder nur die Benachrichtigung?

Autodiscover verfolgen wir nur, wenn Work es wirklich aufruft, um Endpunkte zu ermitteln. Ist der ActiveSync-Host fest eingetragen, beweist ein zusätzlich eingetragener Autodiscover-Name keinen Aufruf [32]. Nutzt Work https://autodiscover.uemfaq.de/autodiscover/autodiscover.xml, prüfst du die Ermittlung und den anschließenden Zugriff auf die ermittelten Endpunkte getrennt. Eine Abweichung korrigierst du an der zugehörigen Konfigurations- oder Zielstelle. Danach wiederholst du Ermittlung und Funktion [2][32].

Synchronisiert Work eine neue Mail beim Öffnen, aber die Benachrichtigung fehlt, wechseln wir zum Push-Weg. Daran wirken BlackBerry Enterprise Mobility Server (BEMS) und Apple Push Notification service (APNs) mit [33]. Prüfe dort die Voraussetzungen für Benachrichtigungen und Hintergrundbetrieb. Solange der Sync im Vordergrund funktioniert, gibt es keinen Anlass, KCD neu aufzubauen.

Was wäre, wenn Knoten wechseln oder sich die Umgebung ändert?

Mehrere UEM Cores: welchem Core folgt der Fehler?

Die Runtime bevorzugt einen Core, dessen DNS-Domain zum Ziel passt. Gibt es keinen Treffer, wählt sie zufällig unter den verfügbaren Cores [1]. Vergleiche deshalb zwischen einem gelingenden und einem scheiternden Versuch, welcher Core gewählt wurde, dazu Principal, Dateien und Dienstlogin. Ein falsch eingerichteter Core reicht für sporadische Anmeldefehler, etwa Please check settings - the attempt to login failed [59]. Eine festgestellte Abweichung korrigierst du auf diesem Core und prüfst ihn über den gemeinsamen Mehr-Core-Weg.

Ist dagegen eine Container-Management-Instanz länger nicht erreichbar, kommt ein anderer Wartungsfall hinzu. Im Dynamics-Connectivity-Profil unter App servers > App servers for Container Mgmt App (com.good.gd.gdgc) setzt du die betroffene Instanz für die längere Wartung auf SECONDARY und nach ihrer Rückkehr wieder auf PRIMARY [34]. Diese Priorität betrifft das Container-Management. Sie ist getrennt von der Proxycluster-Route mit Primary und Secondary zum Exchange-Ziel [5]. Prüfe nach beiden Änderungen den zugehörigen Work-Zugriff.

Exchange und Load Balancer: welcher Knoten nimmt das Ticket an?

Alle Client-Access-Knoten desselben Namespace brauchen dieselbe ASA-Credential. MSExchangeServiceHost verwaltet sie und muss laufen [35]. Auf jedem bedienenden Knoten liest du mit Exchange-Verwaltungsrechten Status und Dienstzustand. Den Schalter, der das Passwort ausgibt, lässt du aus [36].

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

Die Ausgabe nennt das ASA-Konto und die Kennwortstände Latest und Previous. Sie zeigt die Konfiguration, keinen gelungenen Logon. Scheitert die Abfrage an Registry oder Remotezugriff, prüfst du den Verwaltungszugriff oder fragst lokal ab [36]. Lehnt Exchange das vorgelegte Ticket ab, vergleichst du angefragten Namespace-SPN und bedienende Dienstidentität [35][45].

Für den Pilot

Ordne gelingende und gescheiterte Work-Zugriffe den Knoten zu: Lies deren IIS-Dateien und das HttpProxy-Feld ServerHostName [14][16]. Vergleiche zuerst diese Knoten bei gleichem Benutzer, Namespace und Pfad. Der direkte Weg in der Grafik ist eine zusätzliche Vergleichsmöglichkeit für das Exchange-Team. Er braucht eine gezielt eingerichtete Route mit unverändertem outlook.uemfaq.de, SPN und gültigem TLS-Namen; eine IP-URL oder ein anderer Host verändert die Vergleichsbasis [35][37].

Extended Protection unterstützt kein TLS-Offloading. Beim TLS-Bridging braucht der LB dasselbe Zertifikat wie Exchange [37]. Einen bestätigten Widerspruch im Konzept für TLS und LB korrigierst du mit dem zuständigen Team. Bei belegter Credential-Abweichung verteilt das Skript RollAlternateServiceAccountPassword.ps1 mit -CopyFrom eine vorhandene ASA-Credential. -GenerateNewPasswordFor erzeugt oder rotiert sie [35]. Wähle die passende Korrektur und wiederhole den Vergleich. Eine allgemeine HTTP-Session-Affinity verlangt Exchange nicht [50].

Für die Produktion

Begrenze Änderungen an DNS, Pools und Credentials auf den vereinbarten Bereich. Eine ASA-Kopie verändert die Credentials am Ziel. Wähle dafür eine Quelle, die bekannt funktioniert, und berücksichtige alle anderen, die davon abhängen [35]. Ist unklar, welcher Knoten oder welcher TLS-Weg den Fehler trägt, unterstützt dich dein UEM-Berater zusammen mit dem Exchange- und dem Netzwerkteam.

Wenn Logs nicht reichen: Ticket und Pakete am richtigen Ort lesen

Eine Aufzeichnung zwischen Core und KDC zeigt Ticketanforderung, Antwort oder Kerberos-Fehler. An PA-FOR-USER erkennst du den benutzerbezogenen S4U2Self-Weg, mit S4U2Proxy fordert der Dienst das Zielticket an [39][52]. Am HTTP-Ziel zeigt ein erkennbarer AP-REQ die Vorlage des Tickets im Authorization-Header [60]. Bei HTTPS ist er erst nach der TLS-Entschlüsselung an einer geeigneten Messstelle sichtbar. Ein passiver Mitschnitt legt Header und Funktionsantworten nicht offen [51]. Die Annahme und die Funktion prüfen wir zusätzlich in den Zielprotokollen.

Auf einem Windows-Rechner zeigt klist ohne Sessionparameter die Tickets des angemeldeten Windows-Benutzers [38]. Was du dort als Admin siehst, ersetzt nicht den Lauf von UEM unter Java und von Work. Ticketverschlüsselung, Sitzungsschlüsseltyp und Keytab-Schlüsseltyp sind außerdem getrennte Angaben [38][43][52]. Wähle die Messstelle nach dem Übergang, der noch offen ist. Schlüssel, Tickets und vollständige Authorization-Header bleiben im geschützten Diagnosebereich.

Nach Rotation, Härtung oder einer älteren Version

Nach einem Kennwortwechsel vergleichst du auf allen betroffenen Cores den Schlüsselstand und alle Stellen, an denen das Kennwort gespeichert ist. Teilen sich Dienst und KCD ein Konto, kann eine Keytab mit einem anderen Kennwort den Dienststart mit Fehler 1069 scheitern lassen [40]. Eine alte Keytab kann nach dem Kennwortwechsel außerdem das AD-Konto sperren [41]. Korrigiere dann den festgestellten Rotationsstand über den gemeinsamen Kennwortwechsel-Weg und prüfe Dienstlogin und Benutzerzugriff erneut.

Bei Java 17 mit einem DC unter Windows Server 2025 oder UEM 12.21+ nach RC4-Deaktivierung kann schon S4U2Self scheitern, auch mit AES-Keytab [42][43]. Vergleiche die Stackphase, den tatsächlich benutzten DC, den Updatestand und die Verschlüsselungsrichtlinien. Microsofts RC4-Härtung 2026 verändert zusätzlich die KDC-Defaults [44]. Den begrenzten Korrekturweg ordnet der Abschnitt zu RC4 und Windows Server 2025 in der gemeinsamen Einrichtung ein. Ältere Rezepte mit Neustart oder Reaktivierung bewertest du an der Version, für die sie gelten.

Für die Produktion

Ein befristeter RC4-Workaround verändert die Härtung im AD. Bestätige erst, dass die passende S4U2Self-Konstellation vorliegt, und plane betroffene DCs, Dauer und erneute Prüfung mit dem AD-Team [42][43]. Mit dem Juli-2026-Update betrifft der verlinkte Workaround sowohl die GPO als auch msDS-SupportedEncryptionTypes am DC-Konto [43]. Danach müssen Zielticket, Exchange-Annahme und Funktion zum selben Zugriff passen.

Schreib dir nach jeder Korrektur auf, wo der Zugriff abgebrochen ist, was du geändert hast und welche neue Funktion du danach ausgelöst hast. Dann siehst du, welche Übergabe jetzt gelingt und wo der Zugriff noch abbricht.