Der „gleiche PC“ ist nicht dieselbe Ausführungsumgebung — Die Benutzergrenze zwischen AppData, HKCU, DPAPI und Anmeldeinformationen

Die App liest ihre Konfigurationsdatei, wenn sie aus dem Datei-Explorer startet, aber die Aufgabenplanung meldet sie als „nicht gefunden“. Machen Sie daraus einen Dienst, und das gespeicherte Kennwort lässt sich nicht mehr entschlüsseln. Der Browser am Arbeitsplatz ist angemeldet, in der CI landet er wieder auf der Anmeldeseite.

Bei dieser Art von Problem prüfen Sie als wen und auf welche Weise das Programm läuft, bevor Sie in den Code schauen. Dateien und Einstellungen, die auf demselben PC liegen, lassen sich von einem anderen Ausführungskonto nicht unbedingt auf dieselbe Weise nutzen.

Die Frage dieses Artikels ist, warum eine App bricht, obwohl sich am Code nichts geändert hat und sie lediglich zur geplanten Aufgabe, zum Dienst oder zum CI-Job geworden ist. Wenn Sie vom Symptom ausgehen wollen, gehen Sie in der folgenden Tabelle zum passenden Abschnitt.

Voraussetzungen dieses Artikels

1. Zuerst das Fazit

Die Grundeinheit, die eine Windows-Ausführungsumgebung teilt, ist nicht der PC, sondern das Zugriffstoken und die SID, also „als wer der Prozess läuft“. AppData, HKCU, DPAPI-Schlüssel, Browserprofile und Anmeldeinformationen gehören zur Umgebung dieses Benutzers.

Die Einstellungen und der Anmeldestatus, die Sie unter Ihrer eigenen interaktiven Anmeldung vorbereitet haben, werden nicht automatisch an SYSTEM oder ein anderes Dienstkonto weitergegeben. Die Bereiche für maschinenweite Daten sind ProgramData und HKLM, und auch das Teilen darüber verlangt, die Zugriffsrechte zu entwerfen.

flowchart TB
    accTitle: Zwei Welten im selben PC
    accDescr: Derselbe PC teilt nur HKLM und ProgramData, während die Welt Ihrer SID und die Welt einer anderen SID jeweils eigenes AppData, eigenes Registrierungshive und eigene DPAPI-Schlüssel haben, die über die Benutzergrenze hinweg unsichtbar füreinander sind
    pc["Gleicher PC"] --> shared["Geteilt: HKLM und ProgramData"]
    pc --> wa["Die Welt Ihrer SID"]
    pc --> wb["Die Welt einer anderen SID (SYSTEM usw.)"]
    wa --> ra["AppData, HKCU, DPAPI-Schlüssel"]
    wb --> rb["Anderes AppData, anderes Hive, andere Schlüssel"]
    ra -.-|"Benutzergrenze: füreinander unsichtbar"| rb

Abbildung 1: Auf demselben PC bedeuten ein anderes Ausführungskonto anderes AppData, eine andere Registrierung und andere Schlüssel.

Allerdings garantiert dieselbe SID auch nicht dieselbe Umgebung. Prüfen Sie außerdem den Anmeldetyp der Aufgabe, das Laden des IIS-Profils und den Unterschied der Anmeldesitzung, den eine UAC-Erhöhung erzeugt. Eine Erhöhung innerhalb desselben Kontos macht HKCU oder den Tresor nicht zu denen eines anderen Benutzers; entscheidend ist, getrennt zu denken, welche Grenzen sich ändern.

Der Rest des Artikels folgt dieser Reihenfolge: das Ausführungskonto als Voraussetzung (Kapitel 2), die fünf Grenzen (Kapitel 3 bis 7), die Prüfung je Ausführungsform (Kapitel 8) sowie Entwurf und Untersuchung (Kapitel 9).

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (33 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

2. Voraussetzung: „Als wer es läuft“ entscheidet alles

2.1 SID und Token prüfen, nicht den Benutzernamen

Die ID, mit der Windows einen Benutzer erkennt, ist nicht der Benutzername, sondern die SID (Sicherheitskennung). Ein Prozess hält ein Zugriffstoken, und das Token enthält die SID des Ausführungskontos. Dieses Ausführungssubjekt ist der Ausgangspunkt, sobald Sie über Datei-ACL-Prüfungen, die physische Registrierung hinter einem Alias oder Verschlüsselungsschlüssel nachdenken.

Verwenden Sie whoami /user für die erste Prüfung. Bestätigen Sie das Ergebnis in der Ausführungsumgebung, in der das Problem auftritt, nicht in Ihrem eigenen Terminal.

> whoami /user

BENUTZERINFORMATIONEN
----------------

Benutzername    SID
=============== =============================================
desktop\you     S-1-5-21-3623811015-3361044348-30300820-1001

C:\Users\you ist die Form des Benutzerprofils auf der Festplatte, das an diese SID gebunden ist. Ein Profil besteht aus einem Satz von Ordnern wie AppData und dem Benutzerregistrierungshive NTUSER.DAT. Weil es bei der ersten Anmeldung aus dem Standardprofil kopiert wird, startet das Profil eines anderen Benutzers von einem Anfangszustand, der von der Umgebung getrennt ist, die Sie eingerichtet haben.¹

flowchart TB
    accTitle: Vom Startpfad zum Profil
    accDescr: Ob per Doppelklick, Aufgabenplanung oder Dienst bzw. IIS gestartet, der Prozess hält die SID in seinem Zugriffstoken, und der Satz von Benutzerprofildaten, der an diese SID gebunden ist, wird seine Ausführungsumgebung
    e1["Doppelklick"] --> tok["Prozesstoken (SID)"]
    e2["Aufgabenplanung"] --> tok
    e3["Dienst oder IIS"] --> tok
    tok --> prof["An die SID gebundenes Profilset"]
    prof -.-> note["Eine andere SID bedeutet ein anderes Profil im Anfangszustand"]

Abbildung 2: Der Pfad, auf dem ein Prozess gestartet wird, entscheidet, wessen SID-Profil er während der Ausführung trägt.

2.2 Dienstkonten haben jeweils eine eigene Umgebung

Windows hat integrierte Konten, die ohne menschliche Anmeldung laufen. Jedes davon hat eine unabhängige Ausführungsumgebung.²

Der Unterschied zwischen den Startpfaden Doppelklick, Aufgabenplanung, Dienst und IIS wird zum Unterschied, wessen Umgebung genutzt wird. Gehen Sie nicht davon aus, dass die Einstellungen, Schlüssel und Anmeldeinformationen, die Sie unter Ihrer interaktiven Anmeldung vorbereitet haben, auch am Ausführungsziel liegen.

2.3 Drei Bedingungen, die nach „derselbe Benutzer“ zu prüfen sind

Hören Sie nicht bei der SID-Prüfung auf; sortieren Sie mit diesen dreien, was sich selbst bei demselben Konto unterscheidet. Aufgaben behandelt Kapitel 8 ausführlich, IIS die Kapitel 4 und 5, die Erhöhung Kapitel 7.

3. Grenze 1: AppData — Dieselbe Umgebungsvariable zeigt an einen anderen Ort

Das typische Symptom ist, dass die Konfigurationsdatei in dem Moment nicht mehr gefunden wird, in dem die App zur geplanten Aufgabe wird. Die Pfadauflösung ist nicht fehlgeschlagen; der Pfad kann korrekt an den Ort eines anderen Benutzers aufgelöst worden sein, an dem die Datei nicht existiert.

3.1 Die Bereiche von AppData und wie das Ausführungskonto sie ändert

AppData ist ein Ordner unter dem Benutzerprofil. Die Zwecke sind wie folgt geteilt.¹⁰

Selbst wenn derselbe Code %APPDATA% öffnet, ändert sich der Ort, auf den er zeigt, mit dem Ausführungskonto.

Die Datei, die Benutzer A gespeichert hat, existiert auf der SYSTEM-Seite nicht. Ein Fehler, der nur sagt, die Konfigurationsdatei fehle, macht das nicht offensichtlich; schauen Sie bei der Untersuchung daher auf den tatsächlich geöffneten Pfad, nicht auf den Namen der Umgebungsvariable.

flowchart TB
    accTitle: Wie %APPDATA% aufgelöst wird, hängt vom Benutzer ab
    accDescr: Auch wenn derselbe Code %APPDATA% öffnet, wird es unter C:\Users aufgelöst, wenn das Ausführungskonto Sie sind, und unter systemprofile, wenn es SYSTEM ist, und Ihre Konfigurationsdatei existiert im letzteren nicht
    code["Derselbe Code: %APPDATA% öffnen"] --> q{"Ausführungskonto?"}
    q -->|"Sie"| a["C:\Users\you\AppData\Roaming"]
    q -->|"SYSTEM"| b["AppData unter systemprofile"]
    b -.-> miss["Die Datei, die Sie dort abgelegt haben, fehlt"]

Abbildung 3: Umgebungsvariablen lügen nicht, aber wohin sie aufgelöst werden, hängt vom Token ab.

3.2 Auch PATH unterscheidet sich je Benutzer

Systemumgebungsvariablen sind maschinenweit geteilt, Benutzerumgebungsvariablen aber je Benutzer. Wenn ein Befehl, den Sie zu Ihrem eigenen PATH hinzugefügt haben, von einem Dienst nicht gefunden wird, prüfen Sie auch diesen Unterschied.

Entscheiden Sie den Speicherort danach, wer die Daten liest. Einstellungen nur für diesen Benutzer gehören unter AppData; Daten, die alle Benutzer oder Dienste teilen, unter %ProgramData%, und für Letzteres entwerfen Sie die ACLs. Eine ausführliche Wahlhilfe finden Sie unter „Wie Windows-Apps lokale Daten speichern sollten — Entscheidungstabelle für SQLite / JSON / Registrierung / Access“.

flowchart TB
    accTitle: Den Speicherort nach den Lesern wählen
    accDescr: Daten, die nur dieser Benutzer liest, gehören nach AppData oder HKCU, Daten, die alle Benutzer oder Dienste teilen, nach ProgramData oder HKLM, und Letzteres geht mit ACL-Entwurf einher
    q{"Wer liest diese Daten?"} -->|"Nur dieser Benutzer"| f1["AppData, HKCU"]
    q -->|"Alle Benutzer, Dienste"| f2["ProgramData, HKLM"]
    f1 -.-> w1["Neu bedenken, falls es zum Dienst werden kann"]
    f2 -.-> w2["Schreibrechte und ACLs entwerfen"]

Abbildung 4: „Sobald es Dienst ist, kann es nicht mehr lesen“ ist das Ergebnis, wenn dieser Zweig beim Entwurf übersprungen wurde.

4. Grenze 2: HKCU — „Aktueller Benutzer“ ändert sich mit dem Aufrufer

Das typische Symptom ist, dass ein Dienst die Lizenzinformationen nicht findet, die ein Installer geschrieben hat. Selbst wenn Schreiben und Lesen beide unter dem Namen HKCU liefen, sind sie nicht unbedingt dasselbe physische Hive.

4.1 HKCU ist ein Alias für das Hive des Benutzers

HKEY_CURRENT_USER (HKCU) ist kein unabhängiges Hive; es ist ein Alias, der je nach aufrufendem Benutzer auf einen physischen Ort umgeleitet wird. In einem gewöhnlichen Benutzerprozess zeigt er auf den Schlüssel dieser SID unter HKEY_USERS. Der Inhalt ist das bei der Anmeldung geladene NTUSER.DAT.¹

Die Ausnahme ist HKCU\Software\Classes, dessen physischer Ort eine eigene Hivedatei ist, UsrClass.dat. Diese Datei liegt unter %LOCALAPPDATA%\Microsoft\Windows.¹¹

Das HKCU von LocalSystem ist mit dem Standardbenutzer (HKEY_USERS\.DEFAULT) verknüpft. Wenn ein Installer unter einem Administratorkonto nach HKCU schreibt und ein SYSTEM-Dienst aus HKCU liest, zeigen beide auf unterschiedliche Orte.³

flowchart TB
    accTitle: Was der Alias HKCU wirklich ist
    accDescr: Wenn eine App HKCU öffnet, wird in Ihrem Prozess auf Ihren SID-Schlüssel unter HKEY_USERS umgeleitet und in einem LocalSystem-Prozess auf den Schlüssel des Standardbenutzers, sodass der vom Installer geschriebene Wert nicht mehr sichtbar ist
    app["App-Code: HKCU öffnen"] --> alias["HKCU ist ein Alias für den echten Schlüssel"]
    alias -->|"Ihr Prozess"| ha["Ihre SID unter HKEY_USERS"]
    alias -->|"SYSTEM-Prozess"| hd["HKEY_USERS\\.DEFAULT"]
    hd -.-> gone["Der Wert, den Sie geschrieben haben, existiert nicht"]

Abbildung 5: Selbst unter demselben Namen HKCU bedeutet ein anderer Benutzer, dass ein anderes Hive gelesen und geschrieben wird.

Legen Sie maschinenweite Einstellungen in HKLM ab. Microsoft empfiehlt den Zugriff auf HKCU aus einem Dienst nicht. Wenn Sie die Einstellungen eines Benutzers lesen müssen, wechseln Sie per Identitätswechsel in diesen Benutzer und verwenden Sie anschließend RegOpenCurrentUser.¹²

4.2 Auch prüfen, ob das Profil geladen ist

Über das Ausführungskonto hinaus kann auch das Nichtladen des Profils das Problem sein.

IIS-Anwendungspools laufen standardmäßig, ohne ein Benutzerprofil zu laden. Das Aktivieren von loadUserProfile macht AppData und das Hive unter dem Profil verfügbar.⁷ Diese Einstellung beeinflusst auch, wo die DPAPI- und ASP.NET-Core-Data-Protection-Schlüssel des nächsten Kapitels gespeichert werden.

Die Aufgabeneinstellung „Kennwort nicht speichern“ wird getrennt geprüft, als Einschränkung des Anmeldetyps. Selbst wenn derselbe Benutzer angegeben ist, kann eine S4U-Anmeldung das Netzwerk oder EFS nicht nutzen. Die konkreten Unterschiede der Konfigurationen fasst Kapitel 8 zusammen.⁶

5. Grenze 3: DPAPI — Die Verschlüsselung hängt am „Schlüssel des Benutzers“

Während AppData und HKCU Probleme des Suchens an einem anderen Ort sind, erzeugt DPAPI ein Problem, bei dem die Datei lesbar ist, der Inhalt aber nicht entschlüsselt werden kann. Eine App, die ein gespeichertes Kennwort nutzt, zum Dienst zu machen und eine CryptographicException zu erhalten, ist ein Beispiel.

5.1 Ein anderer Besitzer des Hauptschlüssels bedeutet keine Entschlüsselung

DPAPI (Data Protection API) ist die Verschlüsselungsfunktion, die Windows Anwendungen bereitstellt. Der Aufruf von CryptProtectData oder von ProtectedData.Protect in .NET lässt eine App Daten schützen, ohne einen Verschlüsselungsschlüssel in ihrem eigenen Code mitzuführen.¹³

Der Schlüssel wird dadurch nicht überflüssig. DPAPI verwendet einen vom Betriebssystem verwalteten Hauptschlüssel. Im CurrentUser-Gültigkeitsbereich wird ein zufällig erzeugter, benutzerspezifischer Hauptschlüssel mit einem aus den Anmeldeinformationen abgeleiteten Schlüssel geschützt und unter dem Profil gespeichert.¹⁴

flowchart TB
    accTitle: Die DPAPI-Schlüsselkette
    accDescr: Der zufällig erzeugte Benutzerhauptschlüssel wird durch einen aus den Anmeldeinformationen abgeleiteten Schlüssel geschützt, dieser Hauptschlüssel verschlüsselt die Geheimnisse der App, und der Hauptschlüssel eines anderen Benutzers kann denselben Geheimtext nicht entschlüsseln
    pwd["Anmeldeinformationen"] -->|"Schützt über abgeleiteten Schlüssel"| mk["Ihr Hauptschlüssel"]
    mk -->|"Verschlüsselt"| sec["App-Geheimnis (gespeichertes Kennwort usw.)"]
    mk2["Hauptschlüssel eines anderen Benutzers"] -.->|"Kann nicht entschlüsseln"| sec
    mk -.-> loc["Unter dem Profil gespeichert"]

Abbildung 6: Daten werden nicht direkt aus den Anmeldeinformationen verschlüsselt; ein aus den Anmeldeinformationen abgeleiteter Schlüssel schützt den Hauptschlüssel.

Als Nächstes ein Minimalbeispiel, in dem Benutzer A Daten verschlüsselt, sie an einem geteilten Ort ablegt und ein anderer Benutzer sie zu entschlüsseln versucht. Das Teilen des Speicherorts ändert nicht, wer unter CurrentUser entschlüsseln kann.

# In der Sitzung von Benutzer A: im CurrentUser-Gültigkeitsbereich verschlüsseln und an einem geteilten Ort speichern
Add-Type -AssemblyName System.Security
$bytes = [Text.Encoding]::UTF8.GetBytes("secret")
$enc = [Security.Cryptography.ProtectedData]::Protect($bytes, $null, "CurrentUser")
[Convert]::ToBase64String($enc) | Set-Content C:\ProgramData\demo.bin

# Als anderer Benutzer (zum Beispiel, nachdem Sie mit PsExec zu SYSTEM geworden sind) entschlüsseln versuchen
$enc = [Convert]::FromBase64String((Get-Content C:\ProgramData\demo.bin))
[Security.Cryptography.ProtectedData]::Unprotect($enc, $null, "CurrentUser")
# → CryptographicException: Der Schlüssel ist für die Verwendung im angegebenen Zustand nicht gültig.

5.2 Den Gültigkeitsbereich danach wählen, wer entschlüsseln können soll

Ein Geheimnis, das ein Dienst und der interaktive Benutzer beide lesen, sollte von Anfang an als LocalMachine kombiniert mit einer Datei-ACL entworfen werden, oder der Prozess sollte unter dem Konto der Person laufen, die verschlüsselt hat. Ändern Sie den Gültigkeitsbereich nicht nur, damit der Entschlüsselungsfehler verschwindet; entscheiden Sie, wem die Entschlüsselung erlaubt ist. Auf gemeinsam genutzten Maschinen beachten Sie auch das Risiko, dass der maschinenweite Schutz zu weit ist.¹⁵

flowchart TB
    accTitle: Wie der DPAPI-Gültigkeitsbereich gewählt wird
    accDescr: Wählen Sie den CurrentUser-Gültigkeitsbereich, wenn nur dieser Benutzer entschlüsseln können soll, und den LocalMachine-Gültigkeitsbereich, wenn mehrere Subjekte auf demselben PC es sollen, und schränken Sie die Leser des letzteren mit einer Datei-ACL ein
    q{"Wer soll entschlüsseln können?"} -->|"Nur dieser Benutzer"| cu["CurrentUser-Gültigkeitsbereich"]
    q -->|"Mehrere Subjekte auf demselben PC"| lm["LocalMachine-Gültigkeitsbereich"]
    cu -.-> r1["Entschlüsselung schlägt fehl, wenn als anderer Benutzer ausgeführt"]
    lm -.-> r2["Leser mit einer Datei-ACL einschränken"]

Abbildung 7: Wählen Sie den Gültigkeitsbereich als Entwurfsentscheidung darüber, wer entschlüsselt, nicht als „was zufällig funktioniert hat“.

5.3 Ein „Ändern“ und ein „Zurücksetzen“ des Kennworts sind verschieden

Der Schlüssel, der den Hauptschlüssel schützt, hängt von den Anmeldeinformationen ab. Wenn Benutzer ihr eigenes Kennwort ändern, wird der Hauptschlüssel mit einem aus dem neuen Kennwort abgeleiteten Schlüssel neu geschützt, und die Fähigkeit zur Entschlüsselung bleibt erhalten.

Wenn dagegen ein Administrator das Kennwort eines lokalen Kontos zurücksetzt, kann früherer Geheimtext nicht mehr entschlüsselbar sein. Selbst bei demselben Konto müssen Sie prüfen, wie die Anmeldeinformationen geändert wurden.¹⁴

5.4 Auch in ASP.NET Core prüfen, wo die Schlüssel gespeichert werden

Selbst Code, der DPAPI nie direkt aufruft, kann von dieser Grenze abhängen. ASP.NET Core Data Protection speichert den Schlüsselring, der Cookie-Authentifizierung und Ähnliches schützt, an einem vom Umfeld abhängigen Ort.¹⁶

Prüfen Sie loadUserProfile, setProfileEnvironment und das Hostingmodell als Satz, und verstehen Sie, welche Konfiguration entscheidet, wo die Schlüssel liegen. Wichtig ist nicht nur, dass die App startet, sondern ob sie nach einem Neustart dieselben Schlüssel verwenden kann.

Die Wahl des Gültigkeitsbereichs und wann stattdessen die Anmeldeinformationsverwaltung zu nutzen ist, behandelt ausführlich „Geheimnisse in Windows-Apps speichern – Klartextkonfiguration mit DPAPI vermeiden“.

6. Grenze 4: Browserprofile — „Angemeldet“ gehört dem Benutzer

Am Arbeitsplatz angemeldet, und doch steht der Browser in der CI wieder auf der Anmeldeseite. Dieses Problem wird handhabbar, sobald Sie den Speicherort des Profils vom Verschlüsselungsschlüssel trennen.

6.1 Es gibt zwei Grenzen: Speicherort und Schlüssel

Das Profil eines Chromium-Browsers wie Chrome oder Edge liegt standardmäßig im Ordner User Data unter %LOCALAPPDATA%. Verlauf, Cookies, Erweiterungen, gespeicherte Kennwörter und so weiter gehören zur Umgebung dieses Windows-Benutzers.¹⁷

Cookies und gespeicherte Kennwörter sind mit einem Verschlüsselungsschlüssel im Profil verschlüsselt, und dieser Schlüssel selbst ist durch DPAPI geschützt. Das Kopieren des Ordners zu einem anderen Benutzer oder auf eine andere Maschine scheitert daher an der Entschlüsselung, weil der Schlüssel nicht passt.

Aktuelles Chrome legt App-Bound Encryption darüber. Die Entschlüsselung des Schlüssels läuft über einen Dienst mit SYSTEM-Rechten, der nicht nur den Benutzer, sondern auch die Identität der anfragenden App prüft.¹⁸ Das gilt für Chromium-Browser; bei Browsern wie Firefox mit eigenem Profilschutz ist die Lage anders.

flowchart TB
    accTitle: Die zwei Grenzen hinter dem Anmeldestatus eines Browsers
    accDescr: Das Browserprofil liegt unter LOCALAPPDATA und gehört zu Grenze 1, und der Cookie-Verschlüsselungsschlüssel ist durch DPAPI geschützt und gehört zu Grenze 3, daher gehen weder Profil noch Schlüssel auf einen anderen Benutzer über
    prof["Browserprofil"] --> loc["Gespeichert unter LOCALAPPDATA"]
    prof --> key["Cookie-Verschlüsselungsschlüssel durch DPAPI geschützt"]
    loc -.-> ci["Das Ausführungskonto der CI erhält ein leeres, getrenntes Profil"]
    key -.-> copy["Lässt sich nicht durch Kopieren des Ordners mitnehmen"]

Abbildung 8: „Den angemeldeten Zustand mitnehmen“ wird von Grenze 1 und Grenze 3 blockiert.

6.2 In der Automatisierung die Entstehung des Anmeldestatus ausdrücklich machen

Selenium und Playwright starten standardmäßig mit einem Wegwerf-Temporärprofil. Selbst unter demselben Benutzer wird der Anmeldestatus Ihres Alltagsbrowsers also nicht automatisch verwendet.

Selbst wenn Sie ein dauerhaftes Profilverzeichnis angeben, bleiben die Speicherort- und Schlüsselprobleme des vorigen Abschnitts in dem Moment, in dem Sie zu einem CI-Job oder einem Dienst unter einem anderen Benutzer wechseln. Die Abhilfe ist nicht das Kopieren eines angemeldeten Profils, sondern eines der Folgenden.

• Die Anmeldeschritte eines Testkontos im Code hinterlegen.
• Den Speicherzustandsmechanismus des Automatisierungswerkzeugs nutzen, um Cookies und Ähnliches ausdrücklich zu speichern und wiederherzustellen.

Dass ein anderer Benutzer die Cookies nicht durch bloßes Kopieren nutzen kann, ist keine Unannehmlichkeit; es ist auch eine Sicherheitsgrenze. Entwerfen Sie die Automatisierung unter der Voraussetzung, dass diese Grenze existiert.

7. Grenze 5: Anmeldeinformationen und Zertifikate — Jeder Benutzer hat einen eigenen Tresor

Mit cmdkey gespeicherte Anmeldeinformationen werden bei der Aufgabenausführung nicht verwendet, und die Authentifizierung schlägt fehl. Auch hier prüfen Sie nicht „es wurde auf dem PC gespeichert“, sondern „als welcher Benutzer es gespeichert wurde“.

7.1 Die Anmeldeinformationsverwaltung ist ein Tresor je Ausführungskonto

Die Anmeldeinformationsverwaltung, die Sie mit cmdkey /list einsehen können, ist ein Tresor je Benutzer.¹⁹ Gespeicherte Anmeldeinformationen liegen auf der Festplatte, sind aber durch DPAPI geschützt und werden von Programmen genutzt, die als dieser Benutzer laufen.²⁰

Im Tresor liegen gespeicherte Anmeldeinformationen für Dateiserver und Netzlaufwerke, von git-credential-manager gespeicherte Git-Token, gespeicherte Kennwörter für RDP-Verbindungen, Geheimnisse von Apps, die die Credential API nutzen, und so weiter.

Im Tresor Ihrer interaktiven Anmeldung zu liegen bringt sie nicht in den Tresor des Kontos, das den Dienst oder die Aufgabe ausführt. Bereiten Sie einen Einrichtungsschritt vor, der die benötigten Anmeldeinformationen im Kontext des Ausführungskontos selbst einträgt. Wenn nur das git pull an Ihrem Arbeitsplatz gelingt, prüfen Sie auch den Unterschied der Tresore.

Eine mit S4U konfigurierte Aufgabe ist jedoch nicht allein durch das Eintragen von Anmeldeinformationen behoben. Prüfen Sie zuerst den Anmeldetyp, und erwägen Sie eine Konfiguration, die das Kennwort speichert, oder den Wechsel auf ein Dienstkonto. Die Reihenfolge der Schritte steht in Kapitel 8.

flowchart TB
    accTitle: Der Tresor der Anmeldeinformationen ist je Benutzer
    accDescr: Ihr Tresor hält Git-Anmeldeinformationen, gespeicherte Anmeldeinformationen für Dateiserver und RDP-Kennwörter, aber der Tresor des Dienstausführungskontos ist leer, solange nichts eingetragen wird, und das ist der eigentliche Authentifizierungsfehler
    you["Ihr Tresor"] --> g["Git-Anmeldeinformationen"]
    you --> n["Gespeicherte Anmeldeinformationen für Dateiserver"]
    you --> r["Gespeicherte RDP-Kennwörter"]
    svc["Tresor des Dienstausführungskontos"] -.-> empty["Leer, wenn nichts eingetragen = der eigentliche Authentifizierungsfehler"]

Abbildung 9: „Bei mir funktioniert die Authentifizierung“ ist nur die Kurzform von „mein Tresor ist verfügbar“.

7.2 Bei Zertifikaten Speicher und Berechtigungen des privaten Schlüssels getrennt prüfen

Für ein vom Dienst genutztes Zertifikat ist der Grundentwurf der LocalMachine-Speicher zusammen mit der ACL auf dem privaten Schlüssel.²¹ Der Benutzerspeicher liegt physisch unter HKCU\Software\Microsoft\SystemCertificates, also innerhalb der HKCU-Grenze.²²

Einzelheiten finden Sie unter „Windows-Zertifikatspeicher in der Praxis — Benutzer oder Computer, wofür entscheiden Sie sich?“.

7.3 Bei der UAC-Erhöhung „dasselbe Konto“ von „einem anderen Konto“ trennen

Wenn ein Administratorbenutzer mit aktivierter UAC angemeldet wird, entstehen zwei verknüpfte Token: ein Standardtoken mit eingeschränkten Rechten und ein vollständiges Administratortoken.⁸

Netzlaufwerkzuordnungen gelten je Anmeldesitzung. Z: kann im Datei-Explorer sichtbar und für ein als Administrator ausgeführtes Werkzeug unsichtbar sein.⁹

Nehmen Sie nicht an, jedes „es funktioniert nach der Erhöhung nicht mehr“ sei ein Benutzerwechsel; prüfen Sie zuerst, ob es dasselbe Konto ist.

flowchart TB
    accTitle: Die Spaltung innerhalb eines Benutzers durch UAC-Erhöhung
    accDescr: Eine UAC-aktivierte Administratoranmeldung erzeugt zwei Token, ein Standardtoken und ein erhöhtes Token, und ein auf der Standardtokenseite zugeordnetes Netzlaufwerk ist für einen Prozess mit dem erhöhten Token nicht sichtbar
    logon["Anmeldung des Administratorbenutzers"] --> t1["Standardtoken"]
    logon --> t2["Erhöhtes Token"]
    t1 --> d1["Hier zugeordnetes Laufwerk Z:"]
    t2 -.->|"Getrennte Anmeldesitzung"| d2["Erhöhtes Werkzeug sieht Z: nicht"]

Abbildung 10: Die Erhöhung erzeugt „eine andere Welt für denselben Benutzer“. Die Grenze ist nicht nur die SID.

8. Checkliste nach Ausführungsform

8.1 Bei Aufgaben nach dem Ausführungskonto den Anmeldetyp ansehen

In der Aufgabenplanung ändert sich das Verfügbare mit dem Anmeldetyp, selbst wenn derselbe Benutzer angegeben ist.⁶

Wenn eine Aufgabe gespeicherte Anmeldeinformationen nicht nutzen kann, prüfen Sie zuerst die S4U-Einschränkung. Machen Sie das Hinzufügen von Anmeldeinformationen zum Tresor bei bleibendem S4U nicht zu Ihrer Abhilfe. Erwägen Sie eine Konfiguration, die das Kennwort speichert, oder den Wechsel auf ein Dienstkonto, und tragen Sie erst danach bei Bedarf Anmeldeinformationen in den Tresor des Ausführungskontos ein.

Die Einzelheiten der Einstellungen behandelt „Wenn Aufgaben der Aufgabenplanung nicht laufen oder mit 0x1 enden — Ursachen eingrenzen und zuverlässigen Betrieb entwerfen“.

flowchart TB
    accTitle: Der Anmeldetyp der Aufgabe als zweite Achse
    accDescr: Eine Ausführungskonfiguration der Aufgabenplanung hat den Anmeldetyp interaktives Token, gespeichertes Kennwort oder S4U, und bei S4U wird das Kennwort nicht gespeichert und Netzwerk und EFS sind nicht erreichbar
    task["Ausführungskonfiguration der Aufgabe"] --> lt{"Anmeldetyp"}
    lt -->|"Interaktives Token"| it["Läuft in der angemeldeten Sitzung"]
    lt -->|"Gespeichertes Kennwort"| pw["Anmeldeinformationen auch nicht interaktiv nutzbar"]
    lt -->|"S4U (Kennwort nicht gespeichert)"| s4u["Netzwerk und EFS nicht erreichbar"]

Abbildung 11: Selbst bei demselben Ausführungskonto ändert die Art der Anmeldung, was verfügbar ist.

8.2 Die Prüftabelle, bevor das Ausführungsziel wechselt

Die letzte Zeile ist eine Warnung in die Gegenrichtung. Mehrere RDP-Sitzungen desselben Benutzers geben jeder Sitzung kein eigenes unabhängiges AppData und HKCU. Hier ist das Problem nicht, dass etwas unsichtbar ist, sondern dass dasselbe geteilt und beschrieben wird.

9. Leitlinien für Entwurf und Fehlersuche

9.1 Speicherorte und Einrichtung vom nutzenden Subjekt aus entscheiden

Wenn Sie die App später zum Dienst machen wollen, nehmen Sie dieses Ausführungssubjekt schon in der Phase, in der Sie Speicherorte festlegen, unter die Leser auf. Das Prinzip ist, eine Abhängigkeit von „was zufällig in der Entwicklerumgebung lag“ nicht in den Betrieb zu tragen.

9.2 Von dem Ausführungssubjekt zum tatsächlich referenzierten Ort untersuchen

flowchart TB
    accTitle: Untersuchungsablauf bei Problemen der Benutzergrenze
    accDescr: Das Ausführungskonto mit whoami bestätigen, das Token in Process Explorer ansehen, die tatsächlich gelesenen Pfade und Registrierungsschlüssel mit Process Monitor identifizieren und bei Bedarf aus der Welt der anderen Seite mit psexec nachstellen
    s1["Ausführungskonto mit whoami /all bestätigen"] --> s2["Token in Process Explorer prüfen"]
    s2 --> s3["Tatsächliche Pfade und Schlüssel mit ProcMon identifizieren"]
    s3 --> s4["Aus der Welt der anderen Seite mit psexec nachstellen"]
    s3 -.-> hint["Ein unerwarteter Profilpfad ist der Hinweis"]

Abbildung 12: Das Ausführungskonto bestätigen, die tatsächlichen Pfade und Registrierungsschlüssel ansehen, dann als Ziel-Ausführungssubjekt nachstellen.

Wenn Einstellungen fehlen, zurück zu AppData und HKCU; wenn die Datei lesbar, aber nicht entschlüsselbar ist, zu DPAPI; wenn nur die Authentifizierung scheitert, zu Tresor, Zertifikaten und Anmeldetyp. Urteilen Sie nicht allein nach der Fehlermeldung; der kürzeste Weg ist, „wer welchen Ort mit welchem Schlüssel oder welchen Anmeldeinformationen genutzt hat“ in eine Reihe zu stellen.

10. Zusammenfassung

„Bei mir funktioniert es“ bedeutet „es funktioniert als dieser Benutzer, mit diesem Profil, mit diesen Schlüsseln und diesem Tresor“. Selbst wenn dieselbe .exe auf demselben PC gestartet wird, muss das Verwandeln in eine Aufgabe, einen Dienst oder einen CI-Job als Migration der Ausführungsumgebung behandelt werden.

AppData und Benutzerumgebungsvariablen verweisen auf das Profil des Ausführungskontos, und HKCU zeigt ebenso auf das Hive dieses Benutzers. Der DPAPI-CurrentUser-Gültigkeitsbereich hängt vom Hauptschlüssel des Benutzers ab, und Browser-Anmeldestatus und Anmeldeinformationsverwaltung unterliegen ebenfalls dieser Grenze.

Außerdem bleiben selbst bei derselben SID die Unterschiede von Anmeldetyp, Profilladen und der durch UAC-Erhöhung entstehenden Sitzung. Umgekehrt, wenn mehrere Sitzungen desselben Benutzers AppData und HKCU teilen, denken Sie an Schreibkonflikte.

In Entwurfsreviews stellen Sie die folgende Frage.

Ist dieser Code unabhängig vom ausführenden Benutzer korrekt?

Stellen Sie die benötigten Speicherorte, Schlüssel und Anmeldeinformationen ausdrücklich für das tatsächliche Ausführungssubjekt bereit. Bestätigen Sie dieses Prinzip vor der Migration, und Sie können schon in der Entwurfsphase den Bruch verringern, bei dem „der Code sich nicht geändert hat und es trotzdem gebrochen ist“.

Verwandte Artikel

• Geheimnisse in Windows-Apps speichern – Klartextkonfiguration mit DPAPI vermeiden
• Wie Windows-Apps lokale Daten speichern sollten — Entscheidungstabelle für SQLite / JSON / Registrierung / Access
• Wenn Aufgaben der Aufgabenplanung nicht laufen oder mit 0x1 enden — Ursachen eingrenzen und zuverlässigen Betrieb entwerfen
• Das Konto eines Windows-Dienstes wählen — LocalSystem, virtuelle Konten und gMSA
• Windows-Zertifikatspeicher in der Praxis — Benutzer oder Computer, wofür entscheiden Sie sich?

Verwandte Beratungsbereiche

Die KomuraSoft LLC übernimmt den Entwurf von Ausführungsumgebungen, wenn Geschäftsanwendungen zu Diensten oder geplanten Aufgaben werden, die Untersuchung von Fehlern der Art „bei mir funktioniert es“ und den Entwurf der Geheimnisverwaltung für Windows-Apps.

• Windows-App-Entwicklung
• Fehleruntersuchung und Ursachenanalyse
• Nutzung und Migration bestehender Assets
• Kontakt

Referenzlinks

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Eine App, die aus dem Datei-Explorer startet, findet ihre Konfigurationsdatei nicht, wenn sie aus der Aufgabenplanung startet. Warum?

Weil Umgebungsvariablen wie %APPDATA% auf das Profil des Benutzers aufgelöst werden, der das Programm ausführt. Läuft die Aufgabe als SYSTEM oder unter einem anderen Konto, zeigen die Umgebungsvariablen auf ein anderes Profil (bei SYSTEM unter systemprofile), und die gespeicherte Konfigurationsdatei liegt dort nicht. Prüfen Sie das Ausführungskonto der Aufgabe, und legen Sie Daten, die geteilt werden sollen, dauerhaft unter ProgramData ab.

Ein mit ProtectedData.Protect gespeichertes Kennwort lässt sich nicht mehr entschlüsseln, sobald die App zum Dienst geworden ist.

DPAPI im CurrentUser-Gültigkeitsbereich hängt vom Hauptschlüssel des Benutzers ab, der die Daten verschlüsselt hat. Läuft der Dienst unter einem anderen Konto, ist der Hauptschlüssel ein anderer, und die Entschlüsselung schlägt mit einer CryptographicException fehl. Entwerfen Sie ein Geheimnis, das Dienst und interaktiver Benutzer beide lesen, neu mit dem LocalMachine-Gültigkeitsbereich plus einer Datei-ACL, oder führen Sie den Dienst unter dem Konto der Person aus, die verschlüsselt hat.

Was geschieht, wenn ein als SYSTEM laufender Prozess HKCU liest?

In einem LocalSystem-Prozess ist HKEY_CURRENT_USER mit dem Standardbenutzer (HKEY_USERS\.DEFAULT) verknüpft, daher sind die Werte unsichtbar, die der interaktive Benutzer nach HKCU geschrieben hat. Legen Sie maschinenweite Einstellungen in HKLM ab, und wenn Sie unbedingt die Einstellungen eines Benutzers lesen müssen, wechseln Sie per Identitätswechsel in diesen Benutzer und verwenden Sie anschließend RegOpenCurrentUser.

Kann ich ein angemeldetes Chrome- oder Edge-Profil auf eine CI-Maschine kopieren und verwenden?

In der Regel nein. Das Profil eines Chromium-Browsers wie Chrome oder Edge liegt unter %LOCALAPPDATA% des Benutzers, und der Verschlüsselungsschlüssel für Cookies und gespeicherte Kennwörter ist durch das DPAPI dieses Benutzers geschützt. Das Kopieren des Ordners zu einem anderen Benutzer oder auf eine andere Maschine scheitert an der Entschlüsselung, weil der Schlüssel nicht passt (Browser wie Firefox mit eigenem Profilschutz sind ein anderer Fall). Für die Automatisierung hinterlegen Sie die Anmeldeschritte eines Testkontos im Code oder nutzen Sie den Speicherzustandsmechanismus Ihres Automatisierungswerkzeugs.

Mit cmdkey gespeicherte Anmeldeinformationen werden nicht verwendet, wenn die Aufgabe aus der Aufgabenplanung läuft.

Weil der Tresor der Anmeldeinformationsverwaltung je Benutzer getrennt ist und das, was Sie gespeichert haben, in den Tresor Ihrer eigenen interaktiven Anmeldung ging. Außerdem läuft eine Aufgabe mit der Einstellung „Kennwort nicht speichern“ (S4U) ohne Netzwerkanmeldeinformationen, daher hilft das Eintragen in den Tresor nicht, solange sie bei S4U bleibt. Erwägen Sie zuerst eine Konfiguration, die das Kennwort speichert, oder den Wechsel auf ein Dienstkonto, und tragen Sie erst danach bei Bedarf die Anmeldeinformationen in den Tresor des Ausführungskontos selbst ein.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.