<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=1732033&amp;fmt=gif">
Skip to content
Kontakt
All posts

Kerberos statt NTLM: eigene Android-Apps mit dem Hypergate SDK umstellen

  ISEC7 Redaktion  ·  5 minute read

Gegen Ende seines Fahrplans zum Abschalten von NTLM zählt Microsoft die Schritte auf, die Organisationen jetzt angehen können. Einer davon landet bei der Entwicklung: Abhängigkeiten erfassen und dafür gegebenenfalls die Entwickler kritischer Anwendungen ansprechen (Microsoft Windows IT Pro Blog, 29.01.2026). Für eine selbst entwickelte Android-App, die sich an einem internen Dienst per NTLM anmeldet, beschreibt dieser eine Punkt die ganze Aufgabe.

Für Windows ist der Weg beschrieben: erweitertes NTLM-Auditing, dazu IAKerb und Local KDC, die Microsoft für die zweite Jahreshälfte 2026 auf Windows Server 2025 und Windows 11 ab 24H2 ankündigt. Auf einem Android-Gerät läuft davon nichts. Die App bleibt bei NTLM, bis jemand ihren Code ändert.

Dieser Beitrag ist für diese Entwickler geschrieben und für die IT-Leitung, die den Wechsel plant. Microsofts Fahrplan im Ganzen und seine Folgen für Mobilgeräte fasst der erste Beitrag dieser Reihe zusammen.

Wann eine NTLM-App nicht mehr funktioniert

Was Microsoft im Oktober 2026 an BlockNTLMv1SSO ändert, gilt für Windows-Geräte und NTLMv1-abgeleitete Anmeldedaten für Single Sign-on, nicht für Ihre Android-App. Für die App zählt der spätere Schritt: Mit dem nächsten großen Windows-Server-Release ist Netzwerk-NTLM ab Werk deaktiviert. Läuft der Zielserver auf diesem Stand, bekommt ein NTLM-Handshake der App keine Antwort mehr, es sei denn, jemand schaltet NTLM auf diesem Server per Richtlinie wieder ein. Eine Jahreszahl nennt Microsoft für dieses Release nicht, und die Zeitpläne stehen ausdrücklich unter Vorbehalt.

Das lässt Zeit, aber keine beliebige. Kerberos in einer App heißt Codeänderung, Testlauf und Verteilung über das UEM. Und es hilft erst, wenn auf dem Gerät auch die Kerberos-Seite steht.

Was das SDK macht

Auf Android liegt die Kerberos-Identität in einer Authenticator-App auf dem Gerät, etwa Hypergate Authenticator, und ist über das Android-Kontosystem erreichbar. Hypergate Authenticator läuft auf Android-Enterprise-Geräten ab Android 7.0. Seine Tickets holt er direkt beim Key Distribution Center auf Ihren Domain Controllern. Im ISEC7-Webcast vom 23. September 2026 hat Hypergate dafür zwei Wege beschrieben: PKINIT mit einem Benutzerzertifikat, das das MDM verteilt, oder Benutzername und Passwort. Die Aufzeichnung ist kostenfrei nach Registrierung.

Das SDK ist das Gegenstück in Ihrer App. Ruft die App einen per Kerberos geschützten Dienst auf, fragt das SDK beim Konto ein SPNEGO-Negotiate-Token für den Principal-Namen des Dienstes an. Zurück kommt es als Zeichenkette. Die App setzt es in den Header Authorization: Negotiate, damit ist die Anfrage angemeldet. Die App sieht laut Hypergate kein Passwort und speichert keine Zugangsdaten. Welche Server überhaupt Tokens bekommen dürfen, legt die IT in einer Managed Configuration fest, nicht der Code.

Veröffentlicht ist das SDK auf Maven Central als com.hypergate:sdk, aktuell in Version 1.6.0. Quellcode und Dokumentation liegen unter MIT-Lizenz auf GitHub.

Einbau: eine Abhängigkeit, ein Manifest-Eintrag

Zwei Änderungen bringen das SDK ins Projekt. In die build.gradle der App kommt die Abhängigkeit implementation "com.hypergate:sdk:1.6.0". Hat die App keine eigenen App Restrictions, bekommt die AndroidManifest.xml einen meta-data-Eintrag android.content.APP_RESTRICTIONS, der auf @xml/hypergate_sdk_restrictions zeigt. Bringt sie schon eigene mit, übernehmen Sie die Einträge aus hypergate_sdk_restrictions.xml in Ihre Datei.

Danach bietet die App drei Managed Configurations an, die die IT in der UEM-Konsole setzt:

  • Account type for HTTP Negotiate authentication: welches Konto auf Anmeldeanfragen antwortet. Für Hypergate ist das ch.papers.hypergate.
  • Authentication server allowlist: welche Server Tokens anfordern dürfen, als Platzhalter (*) oder als Liste von Domains.
  • Whether NTLMv2 authentication is enabled: ein Rückfallweg der WebView, der mit Hypergate nichts zu tun hat. Soll die App ohne NTLM auskommen, empfiehlt Hypergate, ihn ausgeschaltet zu lassen.

Die Allowlist hat eine angenehme Folge für die Releaseplanung. Wer den Kreis der Server enger zieht, ändert eine Einstellung im UEM und braucht dafür keine neue App-Version.

Weg 1: WebViews ohne Code

Ist Ihre App hybrid, etwa mit Cordova oder Capacitor gebaut, oder zeigt sie interne Dienste in einer WebView, ist der Einbau oben schon alles. Jede WebView im Projekt beantwortet dann HTTP-Negotiate-Anfragen selbst, beim Laden der Seite wie bei AJAX-Aufrufen. Für Cordova stellt Hypergate ein Plugin und eine Beispiel-App bereit.

Eine Ausnahme gibt es: Schickt eine Hybrid-App ihre HTTP-Anfragen über ein natives Plugin statt über die WebView, ist dieses Plugin ein nativer Client. Dann gilt Weg 2.

Weg 2: native Aufrufe mit Token und Header

Bei nativen HTTP-Aufrufen holt Ihr Code das Token selbst. Dafür gibt es eine Methode in vier Varianten, blockierend oder nicht, mit oder ohne Oberfläche:

  • requestTokenSync und requestTokenAsync erwarten eine Activity und dürfen eine Oberfläche zeigen, etwa eine Kontoauswahl oder einen Zustimmungsdialog.
  • requestTokenSilentlySync und requestTokenSilentlyAsync erwarten einen Context, zeigen nie eine Oberfläche und schlagen stattdessen fehl. Das passt zu Sync-Adaptern, Workern und Push-Handlern.

Das Muster ist für jede HTTP-Bibliothek gleich: Token für den Principal-Namen anfordern, Header setzen, senden. In der README ist der Aufruf eine Zeile, Hypergate.requestTokenSync(activity, "HTTP@myhost.com"). Das OkHttp-Beispiel packt ihn in einen Interceptor, der den Principal-Namen als "HTTP/${request.url.host}" bildet und jeder Anfrage Authorization: Negotiate mitgibt. Das Volley-Beispiel macht dasselbe in getHeaders(). Laut Hypergate ersetzt dieser Interceptor die NTLM-Bibliothek oder den selbst geschriebenen Challenge-Response-Code in der App.

Für Server, die über mehrere Runden verhandeln, gibt es die Varianten requestTokenBundle*. Sie nehmen das vorige Token des Servers (incomingAuthToken) und einen spnegoContext entgegen und liefern das vollständige AccountManager-Bundle. Mit Hypergate.hasAccount(context) prüft die App beim Start, ob überhaupt ein Konto da ist, und kann eine verständliche Meldung zeigen, statt an der ersten Anfrage zu scheitern.

Fehler kommen als HypergateException mit Zahlencode und englischer Meldung. Der erste, dem Sie wahrscheinlich begegnen, ist 101, „no accounts found“. Laut README fehlt dann meist der Paketname der App in der Discoverability-Liste von Hypergate. Das behebt die IT in der UEM-Konsole, nicht die Entwicklung im Code.

Was die IT bereitstellen muss

Das SDK funktioniert nur, wenn das Gerät schon eine Kerberos-Identität hat. Praktisch heißt das vier Dinge:

  1. Hypergate Authenticator als verwaltete App über das UEM verteilt, mit einem eingerichteten Konto auf dem Gerät.
  2. Die Managed Configuration der App gesetzt: Kontotyp und Server-Allowlist.
  3. Der Paketname der App in der Discoverability-Liste der Hypergate-Konfiguration.
  4. Ein auflösbarer Principal-Name für jeden Dienst, den die App aufruft. Das erweiterte NTLM-Auditing von Microsoft führt „the target name could not be resolved by Kerberos“ als einen der Gründe, aus denen Windows auf NTLM zurückfällt (KB5064479). Eine App mit abgeschaltetem NTLMv2-Rückfall hat keinen Rückweg. Prüfen Sie die Namen deshalb vor der Umstellung.

Die Grundlagen von Android Enterprise und der Anbindung an das UEM vermittelt unser eintägiger Kurs Android Enterprise Fundamentals.

Den Nachweis liefert der Domain Controller. Meldet sich der Authenticator an, protokolliert Ereignis 4768 das Ticket Granting Ticket. Fordert die App ein Token für einen Dienst an, erscheint im Security-Log Ereignis 4769, „A Kerberos service ticket was requested“, mit Konto, Dienstname und Client-Adresse. Dafür muss „Audit Kerberos Service Ticket Operations“ aktiv sein (Microsoft Learn). Am Zielserver sollten die NTLM-Ereignisse für diesen Nutzer gleichzeitig verschwinden. Wie Sie diese Ereignisse finden, steht im zweiten Beitrag dieser Reihe.

Erst die Apps, dann das SDK

Die NTLM-Ereignisse auf den Servern zeigen, welche Dienste mobile Nutzer noch per NTLM erreichen. Ist eine eigene App als Verursacher erkannt, lässt sie sich in ISEC7 SPHERE ab Version 20.9.0 als „Monitored application“ führen. Dann sehen Sie, bei welchen Nutzern und auf welchen Geräten sie installiert ist, und wissen, wen ein neues Release der App erreicht.

Hypergate stellt Authenticator und SDK her und hat im selben Webcast einen kostenlosen Proof of Concept über rund 30 Tage angeboten. Ihre Entwickler bauen das SDK ein. Authenticator und Managed Configurations bringt ISEC7 als Hypergate-Partner für Deutschland, Großbritannien und die USA über Ihr vorhandenes UEM auf die Geräte. Das kann Microsoft Intune sein, Ivanti, Omnissa Workspace ONE, BlackBerry UEM, SOTI oder 42Gears.

Wo Ihre Umgebung steht, schauen wir uns in einer kostenfreien Ersteinschätzung an. Den Einstieg dafür finden Sie auf unserer Seite zum NTLM-Ausstieg auf Mobilgeräten.

Quellen

ISEC7-Ressourcen