Stirling PDF mit Entra ID: preferred_username ist null

Die Anmeldung bei Entra ID gelingt, Stirling PDF verweigert danach aber den Zugang: Ein Attribut wie preferred_username dürfe nicht null sein. Im archivierten Bericht zu Version 3.2.2 war das Attribut im ID-Token vorhanden, fehlte aber in UserInfo. Nur die tatsächlich reproduzierten Teile dieses Berichts dienen hier als Fallbeleg. Q1

Zwei Datenquellen auseinanderhalten

Microsoft dokumentiert unterschiedliche Informationsumfänge für ID-Token und UserInfo. Ein im Token sichtbares Attribut muss deshalb nicht in der UserInfo-Antwort auftauchen. Deren Inhalt lässt sich nicht beliebig erweitern. Q3 Mehr Scopes oder zusätzliche Token-Claims sind ohne Prüfung der gelesenen Quelle keine nachgewiesene Reparatur.

Den Anmeldeablauf gezielt vergleichen

1. Zugriff zur Administration bewahren. Sichere die bisherige Konfiguration und einen funktionierenden administrativen Zugang, bevor du SSO-Einstellungen änderst. Ein Claim-Experiment sollte nicht alle Benutzer gleichzeitig aussperren.
2. Versions- und Callbackdaten erfassen. Notiere Stirling-Version, Providername, Issuer und registrierte Rückgabe-URL ohne Secrets. Prüfe die genaue Übereinstimmung des Callback-Pfads. Ein falscher Rücksprung ist ein anderer Fehler als ein fehlendes Benutzerattribut.
3. Claimquelle feststellen. Prüfe mit einem autorisierten Testkonto, welcher Schritt den Null-Fehler erzeugt. Vergleiche vorhandene Claim-Namen in ID-Token und UserInfo getrennt. Protokolliere möglichst keine vollständigen Tokens. Kurzzeitig nötige Diagnoseausgaben müssen anschließend wieder ausgeschaltet und geschützt behandelt werden. Q2
4. Unterstützte Einstellung abgleichen. Die aktuelle Stirling-Dokumentation begrenzt die Werte für useAsUsername. Sie nennt sub, upn und oid ausdrücklich als nicht akzeptierte Werte. Q2 Kopiere deshalb keine vermeintliche Einzeilenlösung aus einem Quellcodevorschlag in die laufende Konfiguration.
5. Bestehende Konten berücksichtigen. Prüfe vor einem Attributwechsel, ob derselbe Mensch weiterhin dem richtigen vorhandenen Konto zugeordnet wird. Ein erfolgreicher Login in ein neu angelegtes Konto kann frühere Berechtigungen und Dokumente unerreichbar erscheinen lassen.

Eine Korrektur kontrolliert abnehmen

Geeignet sind eine zur installierten Version passende Konfiguration oder eine nachweislich anwendbare Herstellerkorrektur. Teste Anmeldung, Abmeldung und den erneuten Zugriff eines berechtigten Kontos. Kontrolliere zusätzlich, dass ein nicht berechtigtes Testkonto keinen unerwünschten Zugang erhält. Deaktiviere Authentifizierung nicht als Umgehung des Fehlers.

Für die Übergabe helfen Version, bereinigte Konfiguration, Claim-Namen samt Quelle und der erste aussagekräftige Fehler. Client-Secret, Access-Token und echte personenbezogene Claim-Werte gehören nicht in das Kontaktformular.

Häufige Fragen

Kann ich einfach useAsUsername=sub setzen?

Die aktuell geprüfte Stirling-Dokumentation erlaubt diesen Wert nicht. Ein Codevorschlag ist keine verfügbare Konfigurationsoption.

Beweist ein Claim im ID-Token dessen Verfügbarkeit überall?

Nein. Entscheidend ist, welche Antwort die Anwendung an der Fehlerstelle tatsächlich verarbeitet.

Fall beschreiben