Android-Apps weg von NTLM: Kerberos-SSO mit dem Hypergate SDK

Lukas Schönbächler · Juli 2026 · 9 Min. Lesezeit

Microsoft baut die Legacy-Authentifizierung Stück für Stück ab. NTLM-Audit-Ereignisse kamen mit Windows 11 24H2 und Server 2025, NTLMv1 Single Sign-on wird im Oktober 2026 blockiert (KB5066470), und netzwerkbasiertes NTLM verschwindet mit dem nächsten Windows Server LTSC vollständig. Was diese Abkündigung für mobile Flotten bedeutet, haben wir in Microsofts Plan zur Abschaltung von NTLM behandelt, und die verwandte Aufräumaktion, die Abschaltung von Kerberos RC4, hat diesen Monat bereits ihren Punkt ohne Rückkehr erreicht.

Die Serverseite dieser Migration ist gut dokumentiert. An der Clientseite bleiben mobile Teams hängen: Jede interne Android-App, die noch auf eine NTLM-Challenge antwortet, ob über einen WebView oder den eigenen HTTP-Stack, muss stattdessen Kerberos-Negotiate-Tokens senden. Die Alternative, Domänenpasswörter auf dem Telefon einzutippen, werden Nutzer nicht akzeptieren. Dieser Beitrag zeigt, wie Sie diese Lücke mit dem Hypergate SDK schliessen: was es tut, wie Sie es einrichten und welche seiner Request-Methoden wo zum Einsatz kommen.

Was das SDK tatsächlich tut

Das SDK ist der App-seitige Teil eines Kerberos-Single-Sign-on-Ablaufs. Die Kerberos-Identität des Nutzers liegt in einer Kerberos-Authenticator-App auf dem Gerät, etwa Hypergate Authenticator, bereitgestellt über das Standard-Konto-Framework von Android. Wenn Ihre App einen kerberisierten Dienst aufrufen muss, fragt das SDK bei diesem Konto ein SPNEGO-Negotiate-Token für den Principal-Namen des Dienstes an (zum Beispiel [email protected]) und gibt es Ihnen als String zurück. Sie setzen es in den Header Authorization: Negotiate, und die Anfrage ist authentifiziert.

Ihre App sieht nie ein Passwort und speichert nie Anmeldedaten. Sie fordert lediglich Tokens an. Genau das macht sie zum natürlichen Ziel einer NTLM-Migration: Das Design von NTLM dreht sich um passwortbasierte Challenge-Responses, also genau das Material, das Angreifer weiterleiten und knacken, während ein Negotiate-Token überhaupt kein Passwortmaterial enthält. Welche Server überhaupt Tokens empfangen dürfen, wird ebenfalls nicht im Code entschieden: Die IT steuert das zentral über eine Allowlist in der Managed Configuration.

Abbildung 1: Hybrid- und WebView-Apps sind nach der Einrichtung fertig. Native Apps ergänzen einen Token-Aufruf pro Anfrage.

Einrichtung: eine Dependency, ein Manifest-Eintrag

Fügen Sie das SDK von Maven Central zur build.gradle Ihrer App hinzu (die aktuelle Version finden Sie auf Maven Central):

dependencies {
    implementation "com.hypergate:sdk:1.6.0"
}

Wenn Ihre Anwendung keine eigenen App Restrictions definiert, verweisen Sie in Ihrer AndroidManifest.xml auf die Restrictions-Datei des SDK:

<application>
    <meta-data
        android:name="android.content.APP_RESTRICTIONS"
        android:resource="@xml/hypergate_sdk_restrictions" />
</application>

Wenn Sie bereits eigene Restrictions ausliefern, kopieren Sie stattdessen die Einträge aus hypergate_sdk_restrictions.xml in Ihre Datei. In beiden Fällen stellt Ihre App nun Managed Configurations bereit, die die IT in der EMM-Konsole setzt:

• Kontotyp für die HTTP-Negotiate-Authentifizierung: welcher Kontotyp auf Authentifizierungs-Challenges antwortet. Für Hypergate ist das ch.papers.hypergate.
• Allowlist der Authentifizierungsserver: welche Server Tokens anfordern dürfen. Entweder ein Wildcard (*) oder eine explizite Liste von Domänen.
• Ob die NTLMv2-Authentifizierung aktiviert ist: ein WebView-Fallback-Schalter, der nichts mit Hypergate selbst zu tun hat. Wenn Ihr Ziel eine NTLM-freie App ist, lassen Sie ihn deaktiviert, damit der WebView nur auf Negotiate-Challenges antwortet.

Bei dieser zentralen Allowlist lohnt sich ein kurzer Halt: Die Sicherheitsrichtlinie wandert mit der Geräteverwaltungsebene, nicht mit den App-Releases. Die Liste der Token-empfangenden Server zu verschärfen, erfordert nie ein Update Ihrer App.

Weg 1: WebViews, kein Code

Wenn Ihre App hybrid ist (Cordova, Capacitor oder ähnlich) oder interne Dienste in einem WebView darstellt, sind Sie bereits fertig. Mit der Dependency und den Restrictions beantwortet jeder WebView in Ihrem Projekt HTTP-Negotiate-Challenges transparent, sowohl beim Laden von Seiten als auch bei AJAX-Aufrufen. Es gibt keinen Interceptor zu schreiben und kein Token zu verwalten: Der Nutzer öffnet den Bildschirm und ist angemeldet.

Speziell für Cordova gibt es ein fertiges Plugin und eine Beispiel-App. Der einzige Fall, in dem die WebView-Magie nicht greift: eine Hybrid-App, die ihre HTTP-Anfragen über ein natives Plugin statt über den WebView-Stack ausführt. Dieses Plugin ist ein nativer Client und folgt daher Weg 2.

Weg 2: native Token-Anfragen

Für native HTTP-Aufrufe fordern Sie das Token selbst an. Die API ist eine Methode in vier Ausprägungen entlang zweier Achsen: synchron gegenüber asynchron und regulär gegenüber silent. Die regulären Varianten nehmen eine Activity entgegen und können eine Oberfläche anzeigen, wenn eine Nutzerinteraktion nötig ist, etwa ein Konto-Auswahldialog oder ein Zustimmungsbildschirm. Die Silent-Varianten nehmen einen einfachen Context entgegen, zeigen nie eine Oberfläche und schlagen stattdessen fehl, genau das, was Sie in einem Worker oder Sync-Adapter wollen.

Methode	Blockierend	Nimmt	Zeigt evtl. UI	Typischer Aufrufer
requestTokenSync	ja	Activity	ja	Interceptor auf einem Hintergrund-Thread
requestTokenAsync	nein	Activity	ja	UI-getriebene Abläufe
requestTokenSilentlySync	ja	Context	nie	WorkManager, Sync-Adapter
requestTokenSilentlyAsync	nein	Context	nie	Push-Handler, Dienste

Der synchrone Aufruf ist ein Einzeiler:

val token = Hypergate.requestTokenSync(activity, "[email protected]")

// or from a background component, without any UI:
val token = Hypergate.requestTokenSilentlySync(context, "[email protected]")

Die asynchrone Variante liefert das Token oder die Exception an Callbacks:

Hypergate.requestTokenAsync(activity, "[email protected]",
    { negotiateToken -> Log.d("TOKEN", negotiateToken) },
    { exception -> Log.d("ERROR", exception.message) })

In der Praxis kapseln die meisten Apps den Token-Aufruf einmal und vergessen ihn dann. Mit OkHttp ist dieser Wrapper ein Interceptor:

internal class HypergateOkHttpInterceptor(
    private val activity: Activity
) : Interceptor {

    override fun intercept(chain: Interceptor.Chain): Response {
        val request = chain.request()

        val token = Hypergate.requestTokenSync(
            activity,
            "HTTP/${request.url.host}"
        )
        val authenticatedRequest = request.newBuilder()
            .addHeader("Authorization", "Negotiate ${token}")
            .build()

        return chain.proceed(authenticatedRequest)
    }
}

val client = OkHttpClient.Builder()
    .addInterceptor(HypergateOkHttpInterceptor(activity))
    .build()

Jede Anfrage über diesen Client ist nun authentifiziert. Dasselbe Muster gilt für Volley (die Header-Map in getHeaders() aufbauen und zurückgeben) oder jeden anderen HTTP-Stack: Token anfordern, Header setzen, senden. Wenn Ihre App früher eine NTLM-Bibliothek oder selbst geschriebenen Challenge-Response-Code für diese Aufrufe mitführte, ist dieser Interceptor der Ersatz dafür.

Über die Grundlagen hinaus: Bundles, Round Trips, Konto-Helfer

Die requestToken*-Methoden geben nur den Token-String zurück, was den häufigsten Fall abdeckt. Wenn Sie das vollständige AccountManager-Ergebnis brauchen, geben die Gegenstücke requestTokenBundle* das rohe Bundle zurück, mit dem Token unter AccountManager.KEY_AUTHTOKEN. Die Bundle-Varianten nehmen zudem zwei zusätzliche Parameter für Server entgegen, die über mehrere Round Trips verhandeln: incomingAuthToken, das Token, das der Server im vorherigen Schritt zurückgegeben hat, und spnegoContext, eine opake Kennung, die den Verhandlungsstatus zwischen den Aufrufen trägt.

val bundle = Hypergate.requestTokenBundleSync(
    activity, "[email protected]", incomingAuthToken, spnegoContext
)
val token = bundle.getString(AccountManager.KEY_AUTHTOKEN, "")

Ein paar Helfer runden die API ab, um ein sinnvolles Onboarding zu bauen:

// true if a Hypergate account is present on the device
Hypergate.hasAccount(context)

// all Hypergate accounts (honors the managed configuration)
val accounts: Array<Account> = Hypergate.getAccounts(context)

// system intent to let the user pick or add an account
startActivity(Hypergate.getAccountChooserIntent(context))

Prüfen Sie hasAccount() beim Start: Gibt es false zurück, ist das Gerät nicht eingebunden oder der Authenticator noch nicht bereitgestellt, und Sie können eine aussagekräftige Meldung anzeigen, statt die erste Anfrage fehlschlagen zu lassen.

Abbildung 2: Die richtige Variante wählen. Hintergrundcode nimmt die Silent-Methoden, mehrstufige Verhandlungen die Bundle-Methoden, alles andere das Standardpaar.

Fehlerbehandlung

Alle Fehler-Callbacks liefern eine HypergateException mit zwei Eigenschaften: einem numerischen code, auf den Ihre App verzweigen kann, und einer ausführlichen englischen message für die Logs. Als Erstes begegnet Ihnen code 101, «no accounts found». Das bedeutet meist nicht, dass das Gerät kein Hypergate-Konto hat, sondern dass der Paketname Ihrer App in der Discoverability-Liste der Hypergate Managed Configuration fehlt, sodass das Konto für Ihre App unsichtbar ist. Fügen Sie den Paketnamen in der EMM-Konsole hinzu, und derselbe Aufruf gelingt.

Wo Sie damit stehen

Jede Frist bei der Legacy-Authentifizierung endet am selben Punkt: Kerberos mit AES und zunehmend Zertifikaten statt Passwörtern. Ihre Android-Apps dorthin zu bringen, läuft auf eine kleine Integrationsfläche hinaus: eine Dependency, einen Manifest-Eintrag und entweder gar nichts (WebViews) oder einen Token-Aufruf pro Anfrage (nativ). Schlüsselverwaltung und Ticket-Aushandlung bleiben im Authenticator, wo sie hingehören. Ihre App fordert Tokens an, und die IT steuert die Richtlinie über das EMM. Wenn im Oktober die NTLMv1-Blockade und der LTSC-Umstieg kommen, stehen Ihre Apps bereits auf der richtigen Seite. Der SDK-Quellcode und die vollständige API-Dokumentation liegen im GitHub-Repository.

---