KCD für BlackBerry Access einrichten und prüfen

Ein Benutzer öffnet in BlackBerry Access eine interne Webseite und soll dort kein AD-Passwort mehr eingeben. Dafür gibt es Kerberos Constrained Delegation (KCD): UEM holt im Namen des Benutzers ein Kerberos-Ticket für die Webseite, und Access meldet sich damit an.

Wir richten das am Beispiel uemfaq.de als kleinen Pilot ein: ein Realm, ein UEM Core, eine IIS-Testseite ohne Load Balancer, Access auf dem iPhone. Es gilt für BlackBerry UEM 12.24 on-premises und Access 3.20. Am Ende weißt du, welcher Wert in Active Directory, UEM und Access wohin gehört und wie du nachweist, dass wirklich KCD die Anmeldung übernimmt. Für die Exchange-Anmeldung hat Work eigene Endpunkte und App-Einstellungen; die Einrichtung zeigt KCD für BlackBerry Work einrichten und prüfen.

Warum KCD und nicht ein anderes „SSO“

Für interne Webseiten mit Windows-Anmeldung gibt es auf dem iPhone mehrere Wege, die sich wie Single Sign-on anfühlen. Sie unterscheiden sich darin, woher die Anmeldung kommt und was das Ziel dafür können muss:

• Gespeicherte Anmeldedaten. Access kann NTLM- und Kerberos-Anmeldedaten im App-Kontext speichern [7]. Der Benutzer tippt sein AD-Passwort seltener, aber es liegt auf dem Gerät, und nach jedem Passwortwechsel braucht Access das neue.
• Zertifikate und PKINIT. Der Benutzer weist sich mit einem Zertifikat statt mit dem Passwort aus, bei PKINIT gegenüber dem KDC. Dafür braucht jeder Benutzer ein passendes Zertifikat, und KDC bzw. Ziel müssen diese Anmeldung annehmen [4].
• SAML oder OpenID Connect. Das ist echtes Single Sign-on, setzt aber voraus, dass die Zielanwendung an einen Identity Provider angebunden ist [34]. Eine Anwendung, die nur Windows-Anmeldung anbietet, ist das nicht.

KCD setzt anders an. Die Webanwendung braucht keine neue Anbindung an einen Identity Provider, sie nutzt weiter ihre Windows-Anmeldung mit Kerberos. Auf dem Gerät liegt kein AD-Passwort, und ein Passwortwechsel des Benutzers berührt den Weg nicht, weil UEM das Ticket ohne dieses Passwort holt [1][26].

Was danach funktioniert

Der Pilotbenutzer öffnet https://portal.uemfaq.de/ in Access und ist angemeldet, ohne Netzwerk-Anmeldedaten einzugeben [1]. Das Entsperren von Access mit Dynamics-Passwort oder Biometrie bleibt davon unberührt.

Dabei laufen zwei Wege nebeneinander. Der Datenweg ist der gewohnte Dynamics-Weg: Access ruft portal.uemfaq.de auf, und die Verbindung läuft so, wie das Dynamics-Connectivity-Profil es für dieses Ziel vorsieht [5]. Im Pilot führen wir das Ziel ausdrücklich über BlackBerry Proxy. KCD verlangt das nicht, aber so wissen wir sicher, welchen Weg die Daten nehmen. Wie sich Proxy-Route, Direct Connect und BSCP unterscheiden, steht in BSCP und Dynamics auf dem iPhone.

Der Ticketweg beginnt, wenn die Webseite Kerberos verlangt. Access bittet UEM um ein Ticket. UEM fragt mit seinem KCD-Konto beim Domänencontroller (KDC) ein Ticket für den Benutzer an. Das AD prüft, ob dieses Konto genau zu diesem Zieldienst delegieren darf, und stellt dann ein Ticket aus, das auf den Benutzer lautet. Microsoft nennt das Protokollübergang (S4U2Self) plus eingeschränkte Delegation (S4U2Proxy) [26].

Daraus folgen drei Identitäten, die zusammenpassen müssen:

1. UEM braucht eine Kerberos-Identität: ein Konto mit SPN und eine Keytab-Datei mit dessen Schlüssel.
2. Das Ziel braucht einen HTTP-SPN auf genau dem Konto, mit dem der Webserver Tickets entschlüsselt.
3. Die Delegation verbindet beide: Das UEM-Konto darf nur zu diesem Ziel-SPN delegieren. Darin steckt das „Constrained“.

Unsere Beispielumgebung uemfaq.de

Startzustand: UEM 12.24 läuft on-premises, Access ist für den Pilotbenutzer aktiviert, und die Testseite ist über BlackBerry Proxy erreichbar, noch mit Passwortabfrage. Im Connectivity-Profil steht portal.uemfaq.de dafür als zusätzlicher Server; zusätzliche Server wertet UEM vor den erlaubten Domains aus [5].

Außerdem muss bereitstehen:

• Ein Realm. UEM steht im selben Kerberos-Realm wie das Ziel [2].
• Port 88 vom UEM-Server zum Domänencontroller ist offen. Das betrifft die UEM-Server, nicht die Geräte [2].
• DNS und Zeit: funktionierende Namensauflösung, erreichbare KDCs, synchrone Uhren [32].
• Domänencontroller: Ist RC4 in deiner Domäne abgeschaltet oder laufen DCs mit Windows Server 2025, lies vorher den Abschnitt dazu unter „Was wäre wenn“. In beiden Fällen kann KCD trotz AES-Keytab scheitern [18][19].
• Rechte: jemand, der SPNs und Delegation am AD-Konto setzen darf, Adminzugriff auf UEM-Server und IIS sowie die UEM-Konsole.

Für den Pilot nehmen wir ein Konto für beides: svc_uem betreibt die UEM-Dienste und ist zugleich das KCD-Konto. UEM lässt das zu [1].

Für die Produktion

Trenne die Rollen: svc_uem betreibt weiter die UEM-Dienste, ein eigenes Konto svc_kcd bekommt SPN, Keytab und Delegation. Erstens enthält die Keytab den Schlüssel des Kontos [27]; wer die Datei kopiert, kann sich als dieses Konto ausweisen, beim gemeinsamen Konto also als der UEM-Dienst selbst. Zweitens darf ein Konto mit Protokollübergang für beliebige Benutzer Tickets zu seinen Zielen holen [26]; diese Macht gehört an ein Konto, das sonst nichts darf. Drittens setzt ktpass das Kontopasswort neu, und beim gemeinsamen Konto starten die UEM-Dienste danach nur, wenn du das Passwort überall nachträgst [11][12]. Mit getrenntem Konto erneuerst du die Keytab, ohne die Dienstanmeldung anzufassen.

Keytab-Principal und UEM-Feld lauten dann svc_kcd@UEMFAQ.DE. Beim Umstieg vom Pilot zieht GCSvc/UEM auf svc_kcd um, denn ein SPN darf nur an einem Konto hängen [24]. Keytab, UEM-Feld und Delegationsliste wechseln gemeinsam. Keines der Dienstkonten gehört in die Gruppe „Protected Users“ [29].

Schritt für Schritt

Das Webziel vorbereiten

Wir beginnen beim Ziel, denn ein Webserver, der kein Kerberos spricht, lässt jede spätere UEM-Einstellung scheitern.

1. Windows-Authentifizierung am IIS. Den Rollendienst „Windows Authentication“ installieren, an der Testseite Windows Authentication aktivieren und Anonymous Authentication deaktivieren [23]. IIS bietet dann Kerberos und NTLM an [23].

2. Die Identität des Ziels festlegen. Der App-Pool der Testseite läuft als UEMFAQ\svc_portal. Der Ziel-SPN gehört auf genau das Konto, dessen Schlüssel IIS zum Entschlüsseln nutzt [24]. Weil IIS im Kernelmodus authentifiziert, braucht diese Variante mit eigenem App-Pool-Konto useAppPoolCredentials=true; den Kernelmodus musst du dafür nicht abschalten [24].

3. Den Ziel-SPN prüfen und setzen. Erst lesen, dann schreiben. -Q sucht den SPN, -F dehnt die Suche auf den Forest aus, -L listet die SPNs eines Kontos [24]:

PS C:\> setspn -F -Q HTTP/portal.uemfaq.de
PS C:\> setspn -L UEMFAQ\svc_portal

Fehlt der SPN und gibt es keinen Konflikt, setzt du ihn mit Duplikatprüfung:

PS C:\> setspn -S HTTP/portal.uemfaq.de UEMFAQ\svc_portal

Liegt derselbe SPN schon auf einem anderen Konto, klär erst, wem er gehört, statt ihn zu löschen. Ein doppelter SPN macht die Zuordnung für den KDC uneindeutig [24].

Die UEM-Identität in Active Directory anlegen

4. SPN für UEM setzen. Auf einem Domänencontroller in einer administrativen Eingabeaufforderung [1]:

PS C:\> setspn -S GCSvc/UEM UEMFAQ\svc_uem

GCSvc/UEM muss in der Domäne eindeutig sein [2].

5. Keytab erzeugen. ktpass ändert mehr als eine Datei: Es setzt das Passwort des Kontos, ordnet über /mapuser und /princ den Principal dem AD-Konto zu und setzt dabei standardmäßig auch den UPN [27]. Halte deshalb vorher fest, wie das Konto aussieht:

PS C:\> Get-ADUser svc_uem -Properties UserPrincipalName,servicePrincipalName

Dann erzeugst du die Keytab. Mit /pass * fragt ktpass das Passwort ab, statt es in der Befehlszeile stehen zu lassen [27]:

PS C:\> ktpass /out uem01.keytab /mapuser UEMFAQ\svc_uem /princ svc_uem@UEMFAQ.DE /pass * /ptype KRB5_NT_PRINCIPAL /crypto AES256-SHA1

Der UPN svc_uem@UEMFAQ.DE ist hier bewusst gewählt. Prüf vorher, ob andere Dienste das Konto unter einem anderen UPN nutzen, und wiederhol die Abfrage danach: Der UPN stimmt, und GCSvc/UEM ist weiterhin eingetragen.

Beim gemeinsamen Pilotkonto gibst du das bisherige Passwort von svc_uem ein. Ein neues Passwort ändert das AD-Passwort, und die UEM-Dienste starten mit dem gespeicherten alten nicht mehr: Windows meldet Fehler 1069 [11].

Achte auf die Zeichen im Passwort. Für die Keytab-Anmeldung von UEM taugen Buchstaben, Ziffern und ~ @ * _ . - + : ? / { } [ ]. Zeichen wie ! # $ % & = ; können die Anmeldung mit „Pre-authentication information was invalid (24)“ scheitern lassen [10]. Enthält das bestehende Passwort solche Zeichen, planst du den Wechsel samt Nachtragen in UEM [12] oder nimmst gleich das getrennte Konto aus der Box oben.

Dann prüfst du den Inhalt der Datei:

PS C:\> ktpass /in uem01.keytab

Die Ausgabe muss svc_uem@UEMFAQ.DE, KRB5_NT_PRINCIPAL und AES256-SHA1 zeigen [10]. Sie enthält auch Schlüsselmaterial, gehört also in kein Ticket und keinen Screenshot. Die Keytab ist so schutzbedürftig wie ein Passwort [27]: Lege sie auf uem01 nach C:/kcd/ und beschränke den Zugriff auf Administratoren und svc_uem.

6. Delegation freigeben. In „Active Directory Users and Computers“ am Konto svc_uem den Reiter Delegation öffnen [16][26]:

• „Trust this user for delegation to specified services only“
• „Use any authentication protocol“
• über „Add…“ den Dienst HTTP/portal.uemfaq.de am Konto svc_portal hinzufügen

Per PowerShell geht dasselbe so [26]. -Add ergänzt die Delegationsliste; im Pilot setzen wir eine leere Liste voraus, und die dritte Zeile zeigt, was danach eingetragen ist:

PS C:\> Set-ADUser svc_uem -Add @{'msDS-AllowedToDelegateTo'='HTTP/portal.uemfaq.de'}
PS C:\> Set-ADAccountControl svc_uem -TrustedForDelegation $false -TrustedToAuthForDelegation $true
PS C:\> Get-ADUser svc_uem -Properties msDS-AllowedToDelegateTo,TrustedToAuthForDelegation,servicePrincipalName

„Use any authentication protocol“ ist der Protokollübergang. Ohne ihn könnte UEM kein Ticket für einen Benutzer holen, der sich bei UEM gar nicht mit Kerberos angemeldet hat [26]. „Trust this user for delegation to any service“ wäre die unbeschränkte Delegation, und genau die willst du nicht.

7. Gruppenabfrage erlauben. UEM muss die Gruppenmitgliedschaften der Benutzer lesen können [1]. Dafür nimmst du svc_uem in die „Windows Authorization Access Group“ auf; deren Mitglieder dürfen genau das Attribut lesen, aus dem sich die Gruppen eines Benutzers ergeben [28]:

PS C:\> Add-ADGroupMember -Identity "Windows Authorization Access Group" -Members svc_uem

8. Lokales Recht auf dem UEM-Server. Auf uem01 unter Local Security Policy > Local Policies > User Rights Assignment bekommt svc_uem das Recht „Act as part of the operating system“ [1]. Das Recht reicht weit, denn damit darf ein Prozess im Namen anderer Benutzer handeln [28]. Es wirkt erst nach dem nächsten Start des UEM-Dienstes.

KCD in UEM konfigurieren

9. Globale Eigenschaften. In der UEM-Konsole unter Settings > BlackBerry Dynamics > Global properties „Use explicit UPN“ und „Enable KCD“ aktivieren und speichern [1].

„Use explicit UPN“ lässt UEM den UPN aus dem AD-Attribut des Benutzers verwenden. KCD braucht aber den impliziten UPN, also Anmeldename plus Domäne. Beide müssen deshalb übereinstimmen; für pilot01 lauten beide pilot01@uemfaq.de. Trägt ein Benutzer einen abweichenden UPN, etwa mit zusätzlichem Anmeldesuffix, scheitert KCD für ihn [14].

Für die Produktion

Beide Schalter gelten für die ganze UEM-Umgebung, nicht nur für den Pilot [3]. Prüf vor dem Einschalten, welche Benutzer ein abweichendes UPN-Suffix tragen und ob schon PKINIT für Dynamics im Einsatz ist (siehe „Was wäre wenn“). Ist in UEM das ChromeOS-Management aktiv, prüf den UPN auch nach dessen Synchronisation; sie kann den für KCD genutzten UPN mit dem Google-Benutzernamen überschreiben [22].

10. Serverbezogene Eigenschaften. Unter Settings > BlackBerry Dynamics > Properties den Server uem01 wählen und die KCD-Felder füllen [1]:

• Location of krb5.config file (gc.krb5.config.file): C:/kcd/krb5.conf
• Fully qualified name for the KDC (gc.krb5.kdc): dc01.uemfaq.de
• Location of keytab file (gc.krb5.keytab.file): C:/kcd/uem01.keytab
• Service account name under which KCD service is running (gc.krb5.principal.name): svc_uem@UEMFAQ.DE
• Realm - Active Directory (gc.krb5.realm): UEMFAQ.DE

Dann speicherst du die Werte mit Save [1].

In gc.krb5.principal.name gehört exakt der Principal aus der Keytab. UEM meldet sich beim Start mit diesem Namen beim KDC an und sucht dafür den passenden Schlüssel in der Keytab [10][35]. Passt der Name nicht, findet UEM keinen Schlüssel, und seine Anmeldung scheitert [13][35]. Den Realm schreibst du in beiden Feldern groß. Mit klein geschriebenem Realm startet der KCD-Dienst nicht, und Access fragt wieder nach Anmeldedaten [15].

Die Datei C:/kcd/krb5.conf legst du auf uem01 an. Sie braucht für KCD mindestens diesen Abschnitt; ohne ihn scheitert UEM ab Version 12.20 schon am ersten Schritt des Protokollübergangs [2][10]:

[libdefaults]
    forwardable = true

11. Neustart. Die KCD-Eigenschaften außer „Use explicit UPN“ verlangen einen Neustart [3]. Nach Änderungen an Keytab oder krb5.conf startest du den Dienst „BlackBerry UEM - UEM Core“ auf uem01 neu [10][11].

12. Anmeldung von UEM im CORE-Log prüfen. Nach dem Neustart schreibt UEM seine KCD-Werte ins CORE-Log, standardmäßig unter C:\Program Files\BlackBerry\UEM\Logs\ im Ordner des Tages [6][10]. Such nach diesen Zeilen:

INFO keyTabFile = C:/kcd/uem01.keytab
INFO java.security.krb5.realm = UEMFAQ.DE
INFO principalName = svc_uem@UEMFAQ.DE

Folgt darauf ERROR KCD failed to login, konnte sich UEM nicht mit der Keytab anmelden. Bei „Unable to obtain password from user“ prüfst du Keytab-Pfad, Principal und Verschlüsselungstyp mit ktpass /in [10][13]. Bei „Pre-authentication information was invalid (24)“ prüfst du das Passwort, seine Zeichen und die Schreibweise von Principal und Realm [10].

Access für den Pilot konfigurieren

13. Eigene App-Konfiguration für den Pilot. Unter Apps > BlackBerry Access > BlackBerry Dynamics > App configuration legst du eine Konfiguration an, speicherst sie und weist sie pilot01 zu [7]. So bleiben die anderen Benutzer unberührt. Viel musst du darin nicht einstellen:

• „Force authenticate using NTLM over Kerberos“ bleibt aus. Die Option erzwingt NTLM, sobald die Webseite neben Kerberos auch NTLM anbietet, und genau das tut unser IIS [7][23].
• Ein Realm-Mapping brauchst du hier nicht. Access leitet den Realm aus dem Servernamen ab, und portal.uemfaq.de ergibt UEMFAQ.DE [8]. Wann das nicht reicht, steht unter „Was wäre wenn“.
• Die Startseite bzw. Lesezeichen verwenden den vollständigen Namen https://portal.uemfaq.de/, keine IP-Adresse und keinen Kurznamen [8].
• Den KCD/PKINIT-Schalter in der Access-Konfiguration brauchst du nicht; er gilt für die Mail-App unter Windows und macOS, nicht für den Browser auf dem iPhone [7].

Prüfen: Meldet wirklich KCD an?

Dass sich die Seite ohne Passwortabfrage öffnet, beweist noch kein KCD. Access kann Anmeldedaten speichern [7], und eine gespeicherte Anmeldung sieht für den Benutzer genauso bequem aus. Den Nachweis holst du dir auf der Serverseite.

Sauberer Ausgangszustand. Vor jedem Lauf löschst du in Access unter Settings im Bereich Browsing Data die gespeicherten Anmeldedaten, Cookies und den Cache („Clear Credentials“, „Clear Cookies and Data“, „Clear Cache“) [9]. Als Alternative kannst du Access löschen, neu installieren und neu aktivieren; den Aktivierungsweg, also UEM Client, Zugangsschlüssel oder QR-Code, legst du dafür vorher bereit [9].

Damit die Ereignisse unten entstehen, muss am DC die Überwachung „Audit Kerberos Service Ticket Operations“ und am IIS-Server „Audit Logon“ für erfolgreiche Vorgänge aktiv sein [30][31].

Positivlauf. pilot01 öffnet https://portal.uemfaq.de/ in Access. Notier dir die Uhrzeit. Dann prüfst du drei Stellen:

• UEM-CORE-Log: Eine Anfrage RequestKerberosKCDServiceTicket mit dem Host portal.uemfaq.de zeigt, dass Access UEM um ein Ticket für dieses Ziel bittet. Mit dem Log-Level Debug [6] nennt Impersonating User for= pilot01@UEMFAQ.DE den Benutzer, für den UEM es holt. Folgt ein ERROR KRB, steht dort der Grund [10]. Mehr Kerberos-Details liefert „Enable KCD debugging mode“ (gc.krb5.debug, Neustart nötig) [3].
• Domänencontroller, Event 4769: eine erfolgreiche Ticketanforderung zum Zielkonto svc_portal, angefragt vom UEM-Server. Entscheidend ist das Feld Transited Services: Es enthält bei eingeschränkter Delegation die dabei angefragten SPNs; ohne Delegation steht dort - [31].
• IIS-Server, Event 4624: die Anmeldung von pilot01 mit Authentication Package Kerberos, nicht NTLM [30].

Erst wenn alle drei zum selben Aufruf gehören und das 4769 den Delegationsbefund zeigt, ist KCD nachgewiesen. Ein Kerberos-4624 und ein 4769 allein können auch aus einer gewöhnlichen Kerberos-Anmeldung stammen [30][31]. Fehlt ein Ereignis, prüf zuerst Überwachung und Zeitfenster, bevor du KCD verdächtigst.

Gegenprobe. Schalte in der Pilot-Konfiguration „Force authenticate using NTLM over Kerberos“ ein, speichere und warte, bis die Konfiguration auf dem Gerät angekommen ist. Lösch die gespeicherten Anmeldedaten wie oben und öffne die Seite erneut. Bei der Anmeldeabfrage gibt pilot01 Benutzername und AD-Passwort ein; danach protokolliert IIS eine 4624 mit Authentication Package NTLM [7][30]. Anschließend schaltest du die Option wieder aus, löschst die gespeicherten Anmeldedaten erneut und wiederholst den Positivlauf. Bei aktiver FIPS-Richtlinie ignoriert Access die Option; dann taugt sie nicht als Gegenprobe [7]. Wechselt das Authentication Package mit der Option zwischen Kerberos und NTLM und zeigt der Kerberos-Lauf den Delegationsbefund, ist das Ergebnis belastbar.

Wenn es hakt. Für eine vollständige Fehlersuche ist hier kein Platz; für den Pilot reichen diese ersten Prüfpunkte:

Ein Fehlercode zeigt die Stelle, nicht immer die einzige Ursache.

Rückweg

Halte vor dem Pilot fest, was du änderst: SPNs, UPN und Principal-Zuordnung von svc_uem, Delegationsliste, Gruppenmitgliedschaft, lokales Recht, UEM-Eigenschaften und Access-Zuweisung. Zurücknehmen heißt, genau diese Änderungen rückgängig zu machen und fremde Einträge stehen zu lassen. Einen nur für den Pilot gesetzten SPN entfernt setspn -D gezielt [24].

Nach dem Pilot hast du einen nachweisbar funktionierenden KCD-Weg und eine Namenstabelle, die du für jedes weitere Ziel fortschreibst.

Was wäre wenn …

Für die Produktion

Der Pilot vereinfacht bewusst. Bevor du ausrollst, gehst du die Fälle unten mit diesem Blick durch:

• Weitere Ziele: Jedes Ziel kommt einzeln in die Delegationsliste. Je breiter die Liste, desto mehr Dienste kann das KCD-Konto im Namen delegierbarer Benutzer mit Tickets ansprechen [26][29]. Die Berechtigungen am Ziel gelten weiterhin.
• Mehrere Cores: Jede Kopie der Keytab ist ein weiterer Ort, an dem der Schlüssel des KCD-Kontos liegt. Setz die Dateirechte auf jedem Core gleich eng und nimm jeden Core einzeln ab [1][27].
• Load Balancer: Alle Backends entschlüsseln mit derselben Identität; den Ziel-SPN trägt genau ein Konto [24][25].
• Abweichende Namensräume: Das Realm-Mapping ändert nur die Realm-Ableitung. SPN, Trust und Delegation bleiben eigene Freigaben [8].
• Mehrere Realms: Plane Core im Realm der Ressource und Trusts ausdrücklich ein, denn das Mapping schafft keine realmübergreifende Delegation [2][8].
• SharePoint statt IIS-Testseite: Arbeite mit Zone und Pool-Identität von SharePoint; pauschale Änderungen an den von SharePoint verwalteten IIS-Sites können die Anmeldung beeinträchtigen [33].

… das Ziel kein Kerberos anbietet?

Dann hilft KCD dort nicht. Ein Kerberos-Ticket nutzt nur ein Ziel, das Kerberos annimmt [1][23]. Bietet eine Webanwendung nur NTLM, Basic oder ein eigenes Anmeldeformular, bleibt es bei einem der Wege aus dem ersten Abschnitt. Schau dir deshalb die Authentifizierung des Ziels an, bevor du UEM anfasst.

… du schon PKINIT für Dynamics nutzt?

UEM unterstützt für Dynamics-Apps entweder KCD oder PKINIT, nicht beides zugleich, und „Enable KCD“ gilt für die ganze Umgebung [4]. Wer PKINIT schon nutzt, entscheidet sich zuerst für eines der beiden Verfahren.

… Web-Name und AD-Realm nicht zusammenpassen?

Kerberos braucht für jedes Ticket den Realm, in dem der SPN des Ziels liegt. Access kennt diesen Realm nicht, sondern leitet ihn aus dem DNS-Namen des Servers ab: Es nimmt den Domänenteil und schreibt ihn groß [8]. Aus portal.uemfaq.de wird UEMFAQ.DE. Solange dein Web-Namensraum und dein AD-Realm gleich heißen, stimmt diese Ableitung.

Angenommen, das AD heißt intern uemfaq.local, das Intranet ist aber als intranet.uemfaq.de veröffentlicht. Access leitet dann UEMFAQ.DE ab und fragt einen Realm an, den es nicht gibt. Hier hilft das Realm-Mapping im Reiter Network der Access-Konfiguration. Links steht die DNS-Domain des Servers, rechts der Realm in Großbuchstaben, mehrere Zuordnungen trennst du mit Komma, und der erste Eintrag gilt zugleich als Standard [8]:

uemfaq.de=UEMFAQ.LOCAL

Kommen Ziele aus mehreren Domains, schreibst du jede Zuordnung aus, etwa uemfaq.de=UEMFAQ.LOCAL,partner-uemfaq.de=UEMFAQ.LOCAL.

Das Mapping korrigiert nur diese Namensableitung. Es legt keinen SPN an, schafft keinen Trust und gibt keine Delegation frei. Klassische Kerberos-Clients lösen dieselbe Frage übrigens im Abschnitt [domain_realm] ihrer krb5.conf [36]; Access hat dafür sein eigenes Feld. Zwei verwandte Fallen: Ein Kurzname wie http://intranet/ hat gar keinen Domänenteil, und eine IP-Adresse auch nicht. Ruf Ziele deshalb immer mit vollständigem Namen auf [8].

… ein Load Balancer vor dem Ziel steht?

Dann ruft Access den virtuellen Namen des Load Balancers auf, und genau für diesen Namen muss der HTTP-SPN registriert sein, etwa HTTP/portal.uemfaq.de [24]. Das Ticket ist mit dem Schlüssel des SPN-Kontos verschlüsselt. Alle Server hinter dem Load Balancer müssen es deshalb mit derselben Identität entschlüsseln: Alle App-Pools laufen als svc_portal, mit useAppPoolCredentials=true [24][25]. Ein Healthcheck des Load Balancers beweist kein KCD; nimm jeden Server dahinter einzeln mit dem Positivlauf ab.

… das Ziel SharePoint ist?

Dann gehört der HTTP-SPN auf das Konto des Application Pools der Webanwendung, und die angesprochene Zone muss Windows-Authentifizierung mit Kerberos (Negotiate) anbieten; NTLM allein reicht nicht [33]. Schritt 1 überträgst du nicht blind: SharePoint richtet seine IIS-Sites selbst ein, und wer dort pauschal Authentifizierungsarten abschaltet, kann Fehler erzeugen [33].

… du mehrere UEM Cores betreibst?

Nutzen alle Cores dasselbe KCD-Konto, kopierst du dieselbe Keytab auf jeden und trägst die Serverfelder für jeden Server ein [1]. Prüf jeden Core einzeln, denn ein einziger falsch eingerichteter Core reicht für sporadische Fehler. Fällt eine Instanz aus, die Container-Management-Anfragen bedient, können KCD-Anfragen zeitweise scheitern. Bei längerer Wartung setzt du diese Instanz im Dynamics-Connectivity-Profil unter den App-Servern für com.good.gd.gdgc auf SECONDARY und danach wieder auf PRIMARY [20].

… Ziele in mehreren Realms liegen?

Dann brauchst du mindestens einen UEM Core im Realm der Ressource, bidirektionale transitive Forest-Trusts und eine Latenz von höchstens 5 ms zwischen Core und SQL-Datenbank [2]. Ein Trust allein macht aus einem Single-Realm-Aufbau noch keine Multi-Realm-Lösung. Prüf außerdem die Core-Auswahl: Die Dynamics-Runtime vergleicht die DNS-Domain des Ziels mit den Cores und wählt ohne Treffer zufällig [21]. Fang auch dann mit einem Realm an und erweitere erst, wenn der Pilot läuft [2].

… deine DCs RC4 abschalten oder Windows Server 2025 nutzen?

Dann kann KCD am Protokollübergang scheitern, obwohl die Keytab AES verwendet. Im CORE-Log steht „Attempt to obtain S4U2self credentials failed“ mit „Message stream modified (41)“, am DC ein 4769 mit Failure Code 0x29 [18][19]. Ursache ist eine Prüfsumme in der Anfrage, die UEMs Java-Kerberos dafür bildet. Eine endgültige Lösung gibt es bei Redaktionsschluss nicht; der Workaround lässt RC4 auf den betroffenen DCs wieder zu [18][19]. Bei DCs mit dem Windows-Update vom Juli 2026 gehört dazu zusätzlich das Attribut msDS-SupportedEncryptionTypes am Computerkonto des DCs; genannt ist der Wert 0x1C [18]. Ob du das für einen Pilot in Kauf nimmst, ist eine Sicherheitsentscheidung, die du bewusst gegen deine AD-Härtung abwägst.

… deine Keytab mit GCSvc/… erzeugt ist?

Auch das geht. Wurde die Keytab mit /princ GCSvc/UEM@UEMFAQ.DE /ptype KRB5_NT_SRV_HST erzeugt, gehört genau dieser Name ins Feld gc.krb5.principal.name [1]. Für die Zuordnung müssen Feld und Keytab zeichengenau übereinstimmen, und die Keytab braucht wie oben eine starke Verschlüsselung; ktpass /in zeigt dir beides [10][27].

… sich das Passwort des KCD-Kontos ändert?

Dann erzeugst du die Keytab neu und ersetzt sie auf allen Cores, die das Konto nutzen; die alte Keytab passt nicht mehr zum neuen Schlüssel [12]. Beim gemeinsamen Pilotkonto kommen Verzeichnisverbindung und Anmeldung der UEM-Dienste dazu [12]. Mit getrenntem svc_kcd betrifft ein Passwortwechsel von svc_uem die Keytab nicht mehr [11].