Symptom, Ursache, Abhilfe · Stand September 2026 (Server 1.0.31, Agent 1.0.36)

Bekannte Fehlerbilder

Jeder Abschnitt beschreibt ein Fehlerbild, wie ein Administrator es sieht, nennt die Ursache und die Abhilfe. Die Fehlerbilder hängen nicht zusammen; lesen Sie nur den Abschnitt, dessen Symptom Sie beobachten.

1. Der Browser fragt nach dem Kennwort, oder Zugriff verweigert trotz Berechtigung

In der Regel ist hier nichts zu tun. Kerberos meldet Domänenbenutzer automatisch über das Computerkonto des Servers an; der SPN für den eigenen Servernamen existiert bereits. Etwas einzurichten gibt es nur, wenn das Portal zusätzlich unter einem anderen Namen erreichbar sein soll, etwa hinter einem Network Load Balancer (NLB) mit gemeinsamer Adresse für mehrere Knoten. Davon raten wir ab: ZeroPortal braucht für Hochverfügbarkeit keinen Lastverteiler, der Agent wechselt selbst zum nächsten erreichbaren Knoten (siehe Hochverfügbarkeit einrichten). Ein SPN auf einem gemeinsam genutzten Alias ist genau die Fehlerquelle, die dieser Abschnitt beschreibt — aus demselben Grund vermeiden viele Hersteller NLB vor Kerberos-gesicherten Diensten.

1.1 Symptom

• Beim Aufruf des Portals erscheint ein Anmeldefenster; nach Eingabe der Domänenanmeldung funktioniert alles. Nach Abbrechen erscheint die Seite „Sign in required".
• Oder: Die Kopfzeile zeigt das Konto, aber das Portal meldet „kein Zugriff", obwohl der Benutzer in der richtigen AD-Gruppe ist.

1.2 Ursache

Das Portal meldet Domänenbenutzer still per Windows-Authentifizierung an (Negotiate: Kerberos oder NTLM). Browser senden das Windows-Konto nur an Websites in der Zone Lokales Intranet; fehlt der Zoneneintrag, erscheint das Anmeldefenster (401). „Kein Zugriff" (403) ist dagegen eine Berechtigungsfrage: Gruppe keiner Portalgruppe zugeordnet oder Ticket älter als die Gruppenänderung. NTLM statt Kerberos entsteht bei einem Aliasnamen ohne SPN oder beim Zugriff per IP-Adresse; die Berechtigungen im Portal sind in beiden Fällen gleich.

1.3 Abhilfe

1. Portal-URL in die Intranetzone, per Gruppenrichtlinie für alle Benutzer: Benutzerkonfiguration → Administrative Vorlagen → Windows-Komponenten → Internet Explorer → Internetsystemsteuerung → Sicherheitsseite → Site-zu-Zone-Zuweisungsliste, Portal-URL (z. B. https://zeroportal.firma.local oder *.firma.local) mit dem Wert 1; dieselbe Einstellung gibt es unter Computerkonfiguration. Zum Test auf einem einzelnen Rechner: Internetoptionen → Sicherheit → Lokales Intranet → Sites → Erweitert.

2. Alternativ für Edge und Chrome: Browserrichtlinie AuthServerAllowlist mit dem Portalnamen (mehrere durch Komma getrennt). Firefox: network.negotiate-auth.trusted-uris.

3. SPN nur für einen Aliasnamen. Für den eigenen Servernamen ist der SPN bereits vorhanden. Wird das Portal unter einem DNS-Alias (z. B. zeroportal.firma.local auf ZPSRV01) aufgerufen, registrieren Sie ihn am Computerkonto des Servers:

powershell setspn -Q HTTP/zeroportal.firma.local # ist der Name schon vergeben? setspn -S HTTP/zeroportal.firma.local ZPSRV01$ setspn -L ZPSRV01$ # Kontrolle

Ein SPN darf nur an einem Konto stehen; kein Portal-Neustart nötig; für eine IP-Adresse gibt es keinen SPN. Lastverteiler vor mehreren Knoten: NTLM, oder ein gemeinsames gMSA.

4. Bei „kein Zugriff": Berechtigungen im Portal prüfen (siehe Benutzer, Rechte, Lizenzen und Protokolle); nach einer Gruppenänderung am Windows-Client ab- und anmelden.

1.4 Prüfen

Das Portal von einem Client aus aufrufen: Es darf kein Anmeldefenster erscheinen, und die Kopfzeile zeigt Konto und Verfahren (Username: DOMÄNE\benutzer Auth: Kerberos).

Auf dem Client zeigt klist das Ticket HTTP/zeroportal.firma.local, whoami /groups die Gruppen im Token. Im Portal-Log C:\ProgramData\NickIT\ZPServer\Logs\ZeroPortalLogs.log steht jede abgewiesene Aktion als Warnung Access denied (403): user '…' tried …; ein Anmeldefenster (401) wird nicht protokolliert. Ein Browser auf dem Portalserver selbst zeigt meist NTLM; das ist kein Fehler.

2. Die Installation eines MSIX-Pakets dauert Minuten auf Geräten ohne Internet

Manche Geräte haben aus gutem Grund keinen Internetzugang: Fertigungsnetze, Kassensysteme, klassifizierte oder anderweitig abgeschottete Netze, oder ein Proxy, der nur angemeldete Benutzer durchlässt und das Systemkonto ausschließt. Windows prüft die Paketsignatur aber grundsätzlich online — ohne Erreichbarkeit läuft jede Prüfung erst in eine Zeitüberschreitung, bevor die Installation weitergeht. Dieser Abschnitt verkürzt die Wartezeit, ohne die Prüfung abzuschalten.

2.1 Symptom

• MSIX- und App-Attach-Pakete brauchen auf Geräten ohne Internetzugang oder hinter einem Proxy pro Paket ein bis mehrere Minuten, auf anderen nur Sekunden; die Übertragung des Pakets selbst ist längst fertig. Der Windows-App-Installer zeigt dasselbe beim Doppelklick.
• Im Tray-Menü des Agenten zeigt Deployment times eine lange Paketbereitstellung.
• Im Agent-Log steht die Warnung 3410, sobald eine Bereitstellung länger als 30 Sekunden gedauert hat (Schwelle Agent/SlowDeployWarnSeconds, Standard 30, 0 = aus). Sie nennt das fehlende Zwischenzertifikat oder die nicht erreichbaren Sperrlisten-Adressen.

2.2 Ursache

Windows prüft vor der Installation die Signatur jedes Pakets und will dafür aus dem Internet das Zwischenzertifikat nachladen (falls es lokal fehlt) sowie die Sperrliste (CRL) oder OCSP-Auskunft abrufen. Ohne Internet läuft jeder Abruf in eine Zeitüberschreitung: standardmäßig 15 Sekunden je Adresse und bis zu 20 Sekunden je Prüfung; ein Paket wird mehrfach geprüft, so summieren sich Minuten. Die Bereitstellung läuft unter dem Systemkonto; ein Proxy nur für angemeldete Benutzer hilft ihr nicht (netsh winhttp show proxy).

2.3 Abhilfe

Alle Schritte brauchen Administratorrechte; keiner schaltet die Signaturprüfung ab. Schritte 1 und 2 sind auf jedem Gerät unbedenklich, Schritt 3 nur für Geräte ohne Internet.

1. Zwischenzertifikat in den Computerspeicher. Auf einem Rechner mit Internet: Rechtsklick auf das Paket → Eigenschaften → Digitale Signaturen → Details → Zertifikat anzeigen → Zertifizierungspfad, das Zertifikat zwischen Herausgeber und Stamm markieren, Zertifikat anzeigen → Details → In Datei kopieren (DER, .cer). Auf dem Gerät in den Speicher Zwischenzertifizierungsstellen des lokalen Computers importieren:

powershell Import-Certificate -FilePath .\Zwischen-CA.cer -CertStoreLocation Cert:\LocalMachine\CA

Zentral: Computerkonfiguration → Richtlinien → Windows-Einstellungen → Sicherheitseinstellungen → Richtlinien für öffentliche Schlüssel → Zwischenzertifizierungsstellen. Das Vertrauen entscheidet weiterhin die Stammstelle.

2. Wartezeit für Zertifikatsabrufe begrenzen. Die Sperrprüfung bleibt an, scheitert ohne Internet aber nach Sekunden statt nach einer Viertelminute je Adresse:

powershell $key = 'HKLM:\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config' New-Item -Path $key -Force | Out-Null New-ItemProperty -Path $key -Name ChainUrlRetrievalTimeoutMilliseconds -Value 3000 -PropertyType DWord -Force | Out-Null New-ItemProperty -Path $key -Name ChainRevAccumulativeUrlRetrievalTimeoutMilliseconds -Value 6000 -PropertyType DWord -Force | Out-Null

Zentral: dieselben Werte als Registrierungselement (Computerkonfiguration → Einstellungen → Windows-Einstellungen → Registrierung) oder die Richtlinie Richtlinien für öffentliche Schlüssel → Einstellungen für die Überprüfung des Zertifikatpfads, Registerkarte Netzwerkabruf, beide Timeouts in Sekunden.

Konsequenz: Die Signaturprüfung selbst wird nicht abgeschaltet, nur schneller abgebrochen, wenn eine Adresse nicht antwortet. Auf Geräten, die gelegentlich ein langsames oder instabiles Netz haben, kann die Sperrprüfung dadurch häufiger als „nicht feststellbar" statt als „gültig" enden — Windows lässt die Installation in diesem Fall trotzdem zu, prüft die Sperrliste aber nicht mehr vollständig. Auf Geräten mit verlässlichem Internetzugang die Werte nicht setzen.

3. Defender-Cloudabfrage abschalten (nur Geräte ohne Internet). Der Echtzeitschutz bleibt aktiv:

powershell Set-MpPreference -MAPSReporting Disabled -SubmitSamplesConsent NeverSend -DisableBlockAtFirstSeen $true

Zentral: Computerkonfiguration → Administrative Vorlagen → Windows-Komponenten → Microsoft Defender Antivirus → MAPS. Auf Geräten mit zeitweisem Internet weglassen.

4. Bereitstellungsdienst neu starten. Das Zertifikat wirkt sofort, die Timeout-Werte sicher erst nach einem Neustart des Dienstes AppXSvc oder des Geräts:

powershell Restart-Service AppXSvc -Force

Der Neustart bricht laufende Bereitstellungen ab; nicht während eines Abgleichs ausführen. Bei Verteilung per Gruppenrichtlinie genügt der nächste Neustart der Geräte.

5. Sperrlisten-Adressen erreichbar machen (empfohlen). Dürfen die Geräte die CRL- und OCSP-Adressen erreichen (Proxy- oder Firewall-Ausnahme, interner Spiegel), ist die Prüfung schnell und vollständig. Die Adressen nennen die Warnung 3410 und die Ausgabe von certutil -verify -urlfetch (Abschnitt 2.4).

Nur als letzter Ausweg: Die Optionen Auf gesperrte Serverzertifikate überprüfen und Auf gesperrte Zertifikate von Herausgebern überprüfen (Internetoptionen, Erweitert) gelten nur für das Benutzerkonto, nicht zuverlässig für das Systemkonto, und zurückgezogene Zertifikate werden nicht mehr erkannt. Rücknahme: Registrierungswerte löschen.

2.4 Prüfen

Vorher und nachher messen (Zwischenspeicher leeren, damit die Messung ehrlich ist):

certutil -urlcache * delete
Measure-Command { Get-AuthenticodeSignature 'C:\Pfad\App.msix' }

Unter einer Sekunde: in Ordnung. Zweistellige Sekunden oder mehr: Das Gerät ist betroffen.

Kette und Adressen einzeln prüfen (zeigt je Adresse, ob der Abruf gelang):

$sig = Get-AuthenticodeSignature 'C:\Pfad\App.msix'
[IO.File]::WriteAllBytes("$env:TEMP\signer.cer", $sig.SignerCertificate.Export('Cert'))
certutil -verify -urlfetch "$env:TEMP\signer.cer"

Agent-Log: C:\ProgramData\NickIT\ZeroPortalAgent\Logs\agent-<Datum>.log, Zeile mit [3410]. „Certificate chain INCOMPLETE … '' is not in the local store": das Zwischenzertifikat fehlt (Schritt 1). „Certificate chain is complete locally … revocation checking (CRL/OCSP) … Endpoints: …": Sperrlisten-Abrufe (Schritte 2 und 5).

Anhang: Registrierung (lokaler Computer)

Registrierung (je Benutzerkonto, nicht empfohlen)