Anmeldeinformationen-Prozesse in der Windows-Authentifizierung
Gilt für: Windows Server 2022, Windows Server 2019, Windows Server 2016
In diesem Referenzthema für den IT-Experten wird beschrieben, wie Windows-Authentifizierung Anmeldeinformationen verarbeitet.
Die Verwaltung von Windows-Anmeldeinformationen ist der Prozess, bei dem das Betriebssystem die Anmeldeinformationen vom Dienst oder Benutzer empfängt und diese Informationen für die zukünftige Präsentation für das authentifizierende Ziel sichert. Bei einem in die Domäne eingebundenen Computer ist das Authentifizierungsziel der Domänencontroller. Bei den bei der Authentifizierung verwendeten Anmeldeinformationen handelt es sich um digitale Dokumente, die die Identität des Benutzers einer Form des Echtheitsnachweises zuordnen, z. B. einem Zertifikat, einem Kennwort oder einer PIN.
Standardmäßig werden Windows-Anmeldeinformationen mit der SAM-Datenbank (Security Accounts Manager) auf dem lokalen Computer oder mit Active Directory auf einem in die Domäne eingebundenen Computer über den Winlogon-Dienst überprüft. Anmeldeinformationen werden über die Benutzereingabe auf der Anmelde-Benutzeroberfläche oder programmgesteuert über die Anwendungsprogrammierschnittstelle (APPLICATION Programming Interface, API) gesammelt, die dem authentifizierenden Ziel angezeigt werden.
Lokale Sicherheitsinformationen werden in der Registrierung unter HKEY_LOCAL_MACHINE\SECURITYgespeichert. Gespeicherte Informationen umfassen Richtlinieneinstellungen, Standardsicherheitswerte und Kontoinformationen, z. B. zwischengespeicherte Anmeldeinformationen. Hier wird auch eine Kopie der SAM-Datenbank gespeichert, obwohl sie schreibgeschützt ist.
Das folgende Diagramm zeigt die erforderlichen Komponenten und die Pfade, die Anmeldeinformationen über das System führen, um den Benutzer oder Prozess für eine erfolgreiche Anmeldung zu authentifizieren.
In der folgenden Tabelle werden die einzelnen Komponenten beschrieben, die Anmeldeinformationen im Authentifizierungsprozess zum Zeitpunkt der Anmeldung verwaltet.
Authentifizierungskomponenten für alle Systeme
| Komponente | BESCHREIBUNG |
|---|---|
| Anmelden des Benutzers | Winlogon.exe ist die ausführbare Datei, die für die Verwaltung sicherer Benutzerinteraktionen verantwortlich ist. Der Winlogon-Dienst initiiert den Anmeldeprozess für Windows-Betriebssysteme, indem die von der Benutzeraktion gesammelten Anmeldeinformationen auf dem sicheren Desktop (Anmelde-UI) über Secur32.dll an die lokale Sicherheitsbehörde (Local Security Authority, LSA) übergeben werden. |
| Anwendungsanmeldung | Anwendungs- oder Dienstanmeldungen, für die keine interaktive Anmeldung erforderlich ist. Die meisten vom Benutzer initiierten Prozesse werden mithilfe von Secur32.dll im Benutzermodus ausgeführt, während beim Start initiierte Prozesse wie Dienste im Kernelmodus mit Ksecdd.sys ausgeführt werden. Weitere Informationen zum Benutzer- und Kernelmodus finden Sie unter Anwendungen und Benutzermodus oder Dienste und Kernelmodus in diesem Thema. |
| Secur32.dll | Die mehrere Authentifizierungsanbieter, die die Grundlage des Authentifizierungsprozesses bilden. |
| Lsasrv.dll | Der LSA-Serverdienst, der sowohl Sicherheitsrichtlinien durchsetzt als auch als Sicherheitspaketmanager für die LSA fungiert. Die LSA enthält die Negotiate-Funktion, die entweder das NTLM- oder Kerberos-Protokoll auswählt, nachdem ermittelt wurde, welches Protokoll erfolgreich sein soll. |
| NTLM-Sicherheitssupportanbieter | Eine Reihe von Anbietern, die ein oder mehrere Authentifizierungsprotokolle einzeln aufrufen können. Die Standardanbieter können sich mit jeder Version des Windows-Betriebssystems ändern, und benutzerdefinierte Anbieter können geschrieben werden. |
| Netlogon.dll | Die Dienste, die der Net Logon-Dienst ausführt, sind wie folgt: - Verwaltet den sicheren Kanal des Computers (nicht zu verwechseln mit Schannel) zu einem Domänencontroller. |
| Samsrv.dll | Der Security Accounts Manager (SAM), der lokale Sicherheitskonten speichert, erzwingt lokal gespeicherte Richtlinien und unterstützt APIs. |
| Registrierung | Die Registrierung enthält eine Kopie der SAM-Datenbank, lokale Sicherheitsrichtlinieneinstellungen, Standardsicherheitswerte und Kontoinformationen, auf die nur das System zugreifen kann. |
Dieses Thema enthält folgende Abschnitte:
Eingabe von Anmeldeinformationen für die Benutzeranmeldung
In Windows Server 2008 und Windows Vista wurde die GINA-Architektur (Graphical Identification and Authentication) durch ein Anmeldeinformationsanbietermodell ersetzt, das es ermöglichte, verschiedene Anmeldetypen mithilfe von Anmeldekacheln aufzulisten. Beide Modelle werden unten beschrieben.
Grafische Identifizierungs- und Authentifizierungsarchitektur
Die GINA-Architektur (Graphical Identification and Authentication) gilt für die Betriebssysteme Windows Server 2003, Microsoft Windows 2000 Server, Windows XP und Windows 2000 Professional. In diesen Systemen erstellt jede interaktive Anmeldesitzung eine separate Instanz des Winlogon-Diensts. Die GINA-Architektur wird in den von Winlogon verwendeten Prozessbereich geladen, empfängt und verarbeitet die Anmeldeinformationen und führt die Aufrufe der Authentifizierungsschnittstellen über LSALogonUser aus.
Die Instanzen von Winlogon für eine interaktive Anmeldung werden in Sitzung 0 ausgeführt. Sitzung 0 hostet Systemdienste und andere wichtige Prozesse, einschließlich des LSA-Prozesses (Local Security Authority).
Das folgende Diagramm zeigt den Anmeldeinformationsprozess für Windows Server 2003, Microsoft Windows 2000 Server, Windows XP und Microsoft Windows 2000 Professional.
Anmeldeinformationsanbieter-Architektur
Die Architektur des Anmeldeinformationsanbieters gilt für die Versionen, die in der Liste Gilt für am Anfang dieses Themas angegeben sind. In diesen Systemen wurde die Anmeldeinformationseingabearchitektur mithilfe von Anmeldeinformationsanbietern in einen erweiterbaren Entwurf geändert. Diese Anbieter werden durch die verschiedenen Anmeldekacheln auf dem sicheren Desktop dargestellt, die eine beliebige Anzahl von Anmeldeszenarien zulassen – unterschiedliche Konten für denselben Benutzer und verschiedene Authentifizierungsmethoden wie Kennwort, Smartcard und Biometrie.
Mit der Architektur des Anmeldeinformationsanbieters startet Winlogon immer die Anmeldeoberfläche, nachdem sie ein sicheres Aufmerksamkeitssequenzereignis erhalten hat. Die Anmeldeschnittstelle fragt jeden Anmeldeinformationsanbieter nach der Anzahl der verschiedenen Anmeldeinformationstypen ab, für die der Anbieter konfiguriert ist. Anmeldeinformationsanbieter haben die Möglichkeit, eine dieser Kacheln als Standard anzugeben. Nachdem alle Anbieter ihre Kacheln aufgelistet haben, zeigt die Anmeldeoberfläche diese dem Benutzer an. Der Benutzer interagiert mit einer Kachel, um seine Anmeldeinformationen anzugeben. Die Anmeldeoberfläche übermittelt diese Anmeldeinformationen für die Authentifizierung.
Anmeldeinformationsanbieter sind keine Erzwingungsmechanismen. Sie werden verwendet, um Anmeldeinformationen zu sammeln und zu serialisieren. Die lokale Sicherheitsbehörde und die Authentifizierungspakete erzwingen Die Sicherheit.
Anmeldeinformationsanbieter sind auf dem Computer registriert und sind für Folgendes verantwortlich:
Beschreibung der Anmeldeinformationen, die für die Authentifizierung erforderlich sind.
Verarbeiten von Kommunikation und Logik mit externen Authentifizierungsstellen.
Packen von Anmeldeinformationen für die interaktive Und Netzwerkanmeldung.
Das Packen von Anmeldeinformationen für die interaktive Und Netzwerkanmeldung umfasst den Prozess der Serialisierung. Durch Serialisieren von Anmeldeinformationen können mehrere Anmeldekacheln auf der Anmeldeoberfläche angezeigt werden. Daher kann Ihre Organisation die Anmeldeanzeige steuern, z. B. Benutzer, Zielsysteme für die Anmeldung, Zugriff vor der Anmeldung auf das Netzwerk und Sperren/Entsperren von Arbeitsstationen – durch die Verwendung von benutzerdefinierten Anmeldeinformationsanbietern. Auf demselben Computer können mehrere Anmeldeinformationsanbieter gleichzeitig vorhanden sein.
Anbieter für einmaliges Anmelden (Single Sign-On, SSO) können als Standardanbieter für Anmeldeinformationen oder als Pre-Logon-Access-Anbieter entwickelt werden.
Jede Version von Windows enthält einen Standardanbieter für Anmeldeinformationen und einen Standardanbieter für den Pre-Logon-Access (PLAP), der auch als SSO-Anbieter bezeichnet wird. Der SSO-Anbieter ermöglicht Benutzern, eine Verbindung mit einem Netzwerk herzustellen, bevor sie sich am lokalen Computer anmelden. Wenn dieser Anbieter implementiert ist, listet der Anbieter keine Kacheln auf der Anmeldeoberfläche auf.
Ein SSO-Anbieter ist für die Verwendung in den folgenden Szenarien vorgesehen:
Netzwerkauthentifizierung und Computeranmeldung werden von verschiedenen Anmeldeinformationsanbietern verarbeitet. Zu diesem Szenario gehören folgende Variationen:
Ein Benutzer hat die Möglichkeit, eine Verbindung mit einem Netzwerk herzustellen, z. B. eine Verbindung mit einem virtuellen privaten Netzwerk (VPN), bevor er sich am Computer anmeldet, ist jedoch nicht erforderlich, um diese Verbindung herzustellen.
Die Netzwerkauthentifizierung ist erforderlich, um Informationen abzurufen, die während der interaktiven Authentifizierung auf dem lokalen Computer verwendet werden.
Auf mehrere Netzwerkauthentifizierungen folgt eines der anderen Szenarien. Beispielsweise authentifiziert sich ein Benutzer bei einem Internetdienstanbieter (ISP), authentifiziert sich bei einem VPN und verwendet dann seine Benutzerkontoanmeldeinformationen, um sich lokal anzumelden.
Zwischengespeicherte Anmeldeinformationen sind deaktiviert, und zur Authentifizierung des Benutzers ist vor der lokalen Anmeldung eine Remotezugriffsdiensteverbindung über VPN erforderlich.
Ein Domänenbenutzer hat kein lokales Konto auf einem in die Domäne eingebundenen Computer eingerichtet und muss vor abschluss der interaktiven Anmeldung eine RAS-Verbindung über eine VPN-Verbindung herstellen.
Netzwerkauthentifizierung und Computeranmeldung werden von verschiedenen Anmeldeinformationsanbietern verarbeitet. In diesem Szenario muss der Benutzer eine Verbindung mit dem Netzwerk herstellen, bevor er sich am Computer anmeldet.
Enumeration der Anmeldekachel
Der Anmeldeinformationsanbieter listet Anmeldekacheln in den folgenden Instanzen auf:
Installieren Sie ein Clientbetriebssystem, das in der Liste Gilt für am Anfang dieses Themas aufgeführt ist.
Der Anmeldeinformationsanbieter listet die Kacheln für die Arbeitsstationsanmeldung auf. Der Anmeldeinformationsanbieter serialisiert in der Regel Anmeldeinformationen für die Authentifizierung bei der lokalen Sicherheitsautorität. Dieser Prozess zeigt Kacheln an, die für jeden Benutzer spezifisch und für die Zielsysteme jedes Benutzers spezifisch sind.
Die Anmelde- und Authentifizierungsarchitektur ermöglicht es einem Benutzer, vom Anmeldeinformationsanbieter aufgezählte Kacheln zu verwenden, um eine Arbeitsstation zu entsperren. In der Regel ist der aktuell angemeldete Benutzer die Standardkachel. Wenn jedoch mehrere Benutzer angemeldet sind, werden zahlreiche Kacheln angezeigt.
Der Anmeldeinformationsanbieter listet Kacheln als Reaktion auf eine Benutzeranforderung auf, um sein Kennwort oder andere private Informationen, z. B. eine PIN, zu ändern. In der Regel ist der aktuell angemeldete Benutzer die Standardkachel. Wenn jedoch mehrere Benutzer angemeldet sind, werden zahlreiche Kacheln angezeigt.
Der Anmeldeinformationsanbieter listet Kacheln basierend auf den serialisierten Anmeldeinformationen auf, die für die Authentifizierung auf Remotecomputern verwendet werden sollen. Die Benutzeroberfläche für Anmeldeinformationen verwendet nicht dieselbe Instanz des Anbieters wie die Anmeldeoberfläche, die Arbeitsstation entsperren oder das Kennwort ändern. Daher können Zustandsinformationen nicht im Anbieter zwischen Instanzen der Anmeldeinformationsoberfläche verwaltet werden. Diese Struktur führt zu einer Kachel für jede Remotecomputeranmeldung, vorausgesetzt, die Anmeldeinformationen wurden ordnungsgemäß serialisiert. Dieses Szenario wird auch in der Benutzerkontensteuerung (User Account Control, UAC) verwendet, die dazu beitragen kann, nicht autorisierte Änderungen an einem Computer zu verhindern, indem der Benutzer zur Eingabe einer Berechtigung oder eines Administratorkennworts aufgefordert wird, bevor Aktionen zugelassen werden, die möglicherweise den Computerbetrieb beeinträchtigen oder Einstellungen ändern können, die sich auf andere Benutzer des Computers auswirken.
Das folgende Diagramm zeigt den Anmeldeinformationsprozess für die Betriebssysteme, die in der Liste Gilt für am Anfang dieses Themas angegeben sind.
Eingabe von Anmeldeinformationen für die Anmeldung von Anwendungen und Diensten
Windows-Authentifizierung dient zum Verwalten von Anmeldeinformationen für Anwendungen oder Dienste, die keine Benutzerinteraktion erfordern. Anwendungen im Benutzermodus sind in Bezug auf die Systemressourcen beschränkt, auf die sie Zugriff haben, während Dienste uneingeschränkten Zugriff auf den Systemspeicher und externe Geräte haben können.
Systemdienste und Anwendungen auf Transportebene greifen auf einen Sicherheitsunterstützungsanbieter (Security Support Provider, SSP) über die Security Support Provider Interface (SSPI) in Windows zu, die Funktionen zum Aufzählen der auf einem System verfügbaren Sicherheitspakete, auswählen eines Pakets und Verwenden dieses Pakets zum Abrufen einer authentifizierten Verbindung bereitstellt.
Wenn eine Client/Server-Verbindung authentifiziert wird:
Die Anwendung auf der Clientseite der Verbindung sendet Anmeldeinformationen an den Server mithilfe der SSPI-Funktion
InitializeSecurityContext (General).Die Anwendung auf der Serverseite der Verbindung antwortet mit der SSPI-Funktion
AcceptSecurityContext (General).Die SSPI-Funktionen
InitializeSecurityContext (General)undAcceptSecurityContext (General)werden wiederholt, bis alle erforderlichen Authentifizierungsmeldungen ausgetauscht wurden, um entweder eine erfolgreiche oder eine fehlgeschlagene Authentifizierung durchzuführen.Nachdem die Verbindung authentifiziert wurde, verwendet die LSA auf dem Server Informationen vom Client, um den Sicherheitskontext zu erstellen, der ein Zugriffstoken enthält.
Der Server kann dann die SSPI-Funktion
ImpersonateSecurityContextaufrufen, um das Zugriffstoken an einen Identitätswechselthread für den Dienst anzufügen.
Anwendungen und Benutzermodus
Der Benutzermodus in Windows besteht aus zwei Systemen, die E/A-Anforderungen an die entsprechenden Kernelmodustreiber übergeben können: das Umgebungssystem, das Anwendungen ausführt, die für viele verschiedene Arten von Betriebssystemen geschrieben wurden, und das integrale System, das systemspezifische Funktionen im Namen des Umgebungssystems betreibt.
Das integrale System verwaltet die betriebssystemspezifischen Funktionen im Namen des Umgebungssystems und besteht aus einem Sicherheitssystemprozess (LSA), einem Arbeitsstationsdienst und einem Serverdienst. Der Prozess des Sicherheitssystems befasst sich mit Sicherheitstoken, gewährt oder verweigert Berechtigungen für den Zugriff auf Benutzerkonten basierend auf Ressourcenberechtigungen, verarbeitet Anmeldeanforderungen und initiiert die Anmeldeauthentifizierung und bestimmt, welche Systemressourcen das Betriebssystem überwachen muss.
Anwendungen können im Benutzermodus ausgeführt werden, in dem die Anwendung als beliebiger Prinzipal ausgeführt werden kann, einschließlich im Sicherheitskontext von Lokales System (SYSTEM). Anwendungen können im Benutzermodus ausgeführt werden, in dem die Anwendung als beliebiger Prinzipal ausgeführt werden kann, einschließlich im Sicherheitskontext von Lokales System (SYSTEM).
SSPI ist über das Modul Secur32.dll verfügbar, bei dem es sich um eine API handelt, die zum Abrufen integrierter Sicherheitsdienste für Authentifizierung, Nachrichtenintegrität und Nachrichtendatenschutz verwendet wird. Es bietet eine Abstraktionsebene zwischen Protokollen auf Anwendungsebene und Sicherheitsprotokollen. Da verschiedene Anwendungen unterschiedliche Möglichkeiten zum Identifizieren oder Authentifizieren von Benutzern und verschiedene Möglichkeiten zum Verschlüsseln von Daten erfordern, während sie über ein Netzwerk übertragen werden, bietet SSPI eine Möglichkeit, auf DlLs (Dynamic Link Libraries) zuzugreifen, die unterschiedliche Authentifizierungs- und Kryptografiefunktionen enthalten. Diese DLLs werden als Sicherheitsunterstützungsanbieter (Security Support Providers, SSPs) bezeichnet.
Eigenständige verwaltete Dienstkonten und virtuelle Konten wurden in Windows Server 2008 R2 und Windows 7 eingeführt, um die erforderlichen Anwendungen wie Microsoft Exchange Server und Internetinformationsdienste (IIS) mit der Isolation ihrer eigenen Domänenkonten bereitzustellen, ohne dass ein Administrator den Dienstprinzipalnamen (SPN) und die Anmeldeinformationen für diese Konten manuell verwalten muss. Weitere Informationen zu diesen Features und ihrer Rolle bei der Authentifizierung finden Sie in der Dokumentation zu verwalteten Dienstkonten für Windows 7 und Windows Server 2008 R2 und übersicht über gruppenverwaltete Dienstkonten.
Dienste und Kernelmodus
Obwohl die meisten Windows-Anwendungen im Sicherheitskontext des Benutzers ausgeführt werden, der sie startet, gilt dies nicht für Dienste. Viele Windows-Dienste, z. B. Netzwerk- und Druckdienste, werden vom Dienstcontroller gestartet, wenn der Benutzer den Computer startet. Diese Dienste werden möglicherweise als lokaler Dienst oder lokales System ausgeführt und werden möglicherweise weiterhin ausgeführt, nachdem sich der letzte Benutzer abge meldet.
Hinweis
Dienste werden normalerweise in Sicherheitskontexten ausgeführt, die als lokales System (SYSTEM), Netzwerkdienst oder Lokaler Dienst bezeichnet werden. Mit Windows Server 2008 R2 wurden Dienste eingeführt, die unter einem verwalteten Dienstkonto ausgeführt werden, bei denen es sich um Domänenprinzipale handelt.
Vor dem Starten eines Diensts meldet sich der Dienstcontroller mit dem Konto an, das für den Dienst festgelegt ist, und zeigt dann die Anmeldeinformationen des Diensts für die Authentifizierung durch die LSA an. Der Windows-Dienst implementiert eine programmgesteuerte Schnittstelle, mit der der Dienstcontroller-Manager den Dienst steuern kann. Ein Windows-Dienst kann automatisch gestartet werden, wenn das System gestartet wird, oder manuell mit einem Dienststeuerungsprogramm. Wenn beispielsweise ein Windows-Clientcomputer einer Domäne beitritt, stellt der Messengerdienst auf dem Computer eine Verbindung mit einem Domänencontroller her und öffnet einen sicheren Kanal. Um eine authentifizierte Verbindung zu erhalten, muss der Dienst über Anmeldeinformationen verfügen, denen die lokale Sicherheitsautorität (LSA) des Remotecomputers vertraut. Bei der Kommunikation mit anderen Computern im Netzwerk verwendet LSA die Anmeldeinformationen für das Domänenkonto des lokalen Computers, ebenso wie alle anderen Dienste, die im Sicherheitskontext des lokalen System- und Netzwerkdiensts ausgeführt werden. Dienste auf dem lokalen Computer werden als SYSTEM ausgeführt, sodass Anmeldeinformationen nicht dem LSA vorgelegt werden müssen.
Die Datei Ksecdd.sys diese Anmeldeinformationen verwaltet und verschlüsselt und verwendet einen lokalen Prozeduraufruf in die LSA. Der Dateityp ist DRV (Treiber) und wird als Sicherheitsunterstützungsanbieter im Kernelmodus (Security Support Provider, SSP) bezeichnet, und in den Versionen, die in der Liste Gilt für am Anfang dieses Themas angegeben sind, ist FIPS 140-2 Level 1-kompatibel.
Der Kernelmodus hat Vollzugriff auf die Hardware- und Systemressourcen des Computers. Der Kernelmodus verhindert, dass Dienste und Anwendungen im Benutzermodus auf kritische Bereiche des Betriebssystems zugreifen, auf die sie keinen Zugriff haben sollten.
Lokale Sicherheitsautorität
Die lokale Sicherheitsautorität (Local Security Authority, LSA) ist ein geschütztes Subsystem, das Benutzer auf dem lokalen Computer authentifiziert und anmeldet. Darüber hinaus verwaltet LSA Informationen zu allen Aspekten der lokalen Sicherheit auf einem Computer (diese Aspekte werden zusammen als lokale Sicherheitsrichtlinie bezeichnet) und bietet verschiedene Dienste für die Übersetzung zwischen Namen und Sicherheitsbezeichnern (SIDs). Der Sicherheitssystemprozess LSASS (Local Security Authority Server Service) verfolgt die Sicherheitsrichtlinien und die Konten, die auf einem Computersystem wirksam sind.
Die LSA überprüft die Identität eines Benutzers basierend darauf, welche der beiden folgenden Entitäten das Konto des Benutzers ausgestellt hat:
Lokale Sicherheitsautorität Die LSA kann Benutzerinformationen überprüfen, indem die SAM-Datenbank (Security Accounts Manager) überprüft wird, die sich auf demselben Computer befindet. Jede Arbeitsstation oder Jeder Mitgliedsserver kann lokale Benutzerkonten und Informationen zu lokalen Gruppen speichern. Diese Konten können jedoch nur für den Zugriff auf diese Arbeitsstation oder den Computer verwendet werden.
Sicherheitsautorität für die lokale Domäne oder für eine vertrauenswürdige Domäne. Die LSA kontaktiert die Entität, die das Konto ausgestellt hat, und fordert die Überprüfung an, ob das Konto gültig ist und ob die Anforderung vom Kontoinhaber stammt.
Der Subsystemdienst für die lokale Sicherheitsautorität (Local Security Authority Subsystem Service, LSASS) speichert Anmeldeinformationen für Benutzer mit aktiven Windows-Sitzungen im Arbeitsspeicher. Dadurch können Benutzer nahtlos auf Netzwerkressourcen wie Dateifreigaben, Exchange Server-Postfächer und SharePoint-Websites zugreifen, ohne ihre Anmeldeinformationen für jeden Remotedienst erneut eingeben zu müssen.
LSASS kann Anmeldeinformationen in verschiedenen Formaten speichern. Diese umfassen Folgendes:
Reversibel verschlüsselter Nur-Text
Kerberos-Tickets (Ticket-Granting Tickets (TGTs), Servicetickets)
NT-Hash
LAN-Manager(LM)-Hash
Wenn sich der Benutzer mit einer Smartcard bei Windows anmeldet, speichert LSASS kein Nur-Text-Kennwort, sondern den entsprechenden NT-Hashwert für das Konto und die Nur-Text-PIN für die Smartcard. Wenn das Kontoattribut für eine Smartcard aktiviert ist, die für die interaktive Anmeldung erforderlich ist, wird für das Konto automatisch ein zufälliger NT-Hashwert anstelle des ursprünglichen Kennworthashes generiert. Der automatisch beim Festlegen des Attributs generierte Kennworthash wird nicht geändert.
Wenn sich ein Benutzer mit einem mit LM-Hashes kompatiblen Kennwort bei Windows anmeldet, ist dieser Authentifikator im Arbeitsspeicher vorhanden.
Die Speicherung von Nur-Text-Anmeldeinformationen im Arbeitsspeicher kann nicht deaktiviert werden, auch nicht, wenn die diese Informationen anfordernden Anmeldeinformationsanbieter deaktiviert sind.
Die gespeicherten Anmeldeinformationen werden den LSASS-Anmeldesitzungen, die seit dem letzten Neustart gestartet und nicht geschlossen wurden, direkt zugeordnet. LSA-Sitzungen mit gespeicherten LSA-Anmeldeinformationen werden beispielsweise erstellt, wenn ein Benutzer eine der folgenden Aktionen ausführt:
Anmelden bei einer lokalen oder RDP-Sitzung auf dem Computer
Ausführen einer Aufgabe mit der Option RunAs
Ausführen eines aktiven Windows-Diensts auf dem Computer
Ausführen einer geplanten Aufgabe oder eines Batchauftrags
Ausführen einer Aufgabe auf dem lokalen Computer mithilfe eines Remoteverwaltungstools
Unter bestimmten Umständen werden die LSA-Geheimnisse, bei denen es sich um geheime Daten handelt, auf die nur SYSTEM-Kontoprozesse zugreifen können, auf der Festplatte gespeichert. Einige dieser geheimen Schlüssel sind Anmeldeinformationen, die nach dem Neustart beibehalten werden müssen und verschlüsselt auf dem Festplattenlaufwerk gespeichert werden. Als geheime LSA-Schlüssel gespeicherte Anmeldeinformationen können Folgendes umfassen:
Kontokennwort für das Active Directory Domain Services-Konto (AD DS) des Computers
Kontokennwörter für auf dem Computer konfigurierte Windows-Dienste
Kontokennwörter für konfigurierte geplante Aufgaben
Kontokennwörter für IIS-Anwendungspools und -Websites
Kennwörter für Microsoft-Konten
Ab dem Betriebssystem Windows 8.1 steht zusätzlicher Schutz für die lokale Sicherheitsautorität zur Verfügung, um das Auslesen des Arbeitsspeichers und das Einschleusen von Code durch ungeschützte Prozesse zu verhindern. Dies sorgt für eine erhöhte Sicherheit in Bezug auf Anmeldeinformationen, die von der lokalen Sicherheitsautorität gespeichert und verwaltet werden.
Weitere Informationen zu diesen zusätzlichen Schutzmaßnahmen finden Sie unter Konfigurieren des zusätzlichen LSA-Schutzes.
Zwischengespeicherte Anmeldeinformationen und Validierung
Validierungsmechanismen basieren auf der Darstellung von Anmeldeinformationen zum Zeitpunkt der Anmeldung. Wenn der Computer jedoch von einem Domänencontroller getrennt ist und der Benutzer Domänenanmeldeinformationen vorgibt, verwendet Windows den Prozess der zwischengespeicherten Anmeldeinformationen im Überprüfungsmechanismus.
Jedes Mal, wenn sich ein Benutzer bei einer Domäne anmeldet, speichert Windows die angegebenen Anmeldeinformationen zwischen und speichert sie in der Sicherheitsstruktur in der Registrierung des Betriebssystems.
Mit zwischengespeicherten Anmeldeinformationen kann sich der Benutzer bei einem Domänenmitglied anmelden, ohne mit einem Domänencontroller innerhalb dieser Domäne verbunden zu sein.
Speicherung und Validierung von Anmeldeinformationen
Es ist nicht immer wünschenswert, einen Satz von Anmeldeinformationen für den Zugriff auf verschiedene Ressourcen zu verwenden. Beispielsweise kann ein Administrator beim Zugriff auf einen Remoteserver Administratoranmeldeinformationen anstelle von Benutzeranmeldeinformationen verwenden. Ebenso kann ein Benutzer, wenn er auf externe Ressourcen wie ein Bankkonto zugreift, nur Anmeldeinformationen verwenden, die sich von seinen Domänenanmeldeinformationen unterscheiden. In den folgenden Abschnitten werden die Unterschiede bei der Verwaltung von Anmeldeinformationen zwischen aktuellen Versionen von Windows-Betriebssystemen und den Betriebssystemen Windows Vista und Windows XP beschrieben.
Prozesse für Remoteanmeldeinformationen
Das Remotedesktopprotokoll (RDP) verwaltet die Anmeldeinformationen des Benutzers, der eine Verbindung mit einem Remotecomputer über den Remotedesktopclient herstellt, der in Windows 8 eingeführt wurde. Die Anmeldeinformationen in Klartextform werden an den Zielhost gesendet, auf dem der Host versucht, den Authentifizierungsprozess durchzuführen, und bei erfolgreicher Ausführung wird der Benutzer mit zulässigen Ressourcen verbunden. RDP speichert die Anmeldeinformationen nicht auf dem Client, aber die Domänenanmeldeinformationen des Benutzers werden im LSASS gespeichert.
Der in Windows Server 2012 R2 und Windows 8.1 eingeführte eingeschränkte Admin-Modus bietet zusätzliche Sicherheit für Remoteanmeldungsszenarien. Dieser Modus des Remotedesktops bewirkt, dass die Clientanwendung eine Anforderungsantwort für die Netzwerkanmeldung mit der unidirektionalen NT-Funktion (NTOWF) ausführt oder bei der Authentifizierung beim Remotehost ein Kerberos-Dienstticket verwendet. Nachdem der Administrator authentifiziert wurde, verfügt der Administrator nicht über die entsprechenden Kontoanmeldeinformationen in LSASS, da sie nicht für den Remotehost bereitgestellt wurden. Stattdessen verfügt der Administrator über die Computerkontoanmeldeinformationen für die Sitzung. Administratoranmeldeinformationen werden nicht für den Remotehost bereitgestellt, sodass Aktionen als Computerkonto ausgeführt werden. Ressourcen sind auch auf das Computerkonto beschränkt, und der Administrator kann nicht mit seinem eigenen Konto auf Ressourcen zugreifen.
Anmeldeinformationsvorgang für automatischen Neustart
Wenn sich ein Benutzer auf einem Windows 8.1-Gerät anmeldet, speichert LSA die Benutzeranmeldeinformationen im verschlüsselten Speicher, auf den nur lsass.exe zugreifen kann. Wenn Windows Update einen automatischen Neustart ohne Benutzerpräsenz initiiert, werden diese Anmeldeinformationen verwendet, um die automatische Anmeldung (AutoLogon) für den Benutzer zu konfigurieren.
Beim Neustart wird der Benutzer automatisch über den AutoLogon-Mechanismus angemeldet und dann zusätzlich gesperrt, um die Sitzung des Benutzers zu schützen. Die Sperrung wird über Winlogon initiiert, während die Verwaltung der Anmeldeinformationen über LSA erfolgt. Durch automatisches Anmelden und Sperren des Benutzers an der Konsole werden die Sperrbildschirmanwendungen des Benutzers neu gestartet und sind verfügbar.
Weitere Informationen zu ARSO finden Sie unter Winlogon Automatic Restart Sign-On (ARSO).
Gespeicherte Benutzernamen und Kennwörter in Windows Vista und Windows XP
In Windows Server 2008, Windows Server 2003, Windows Vista und Windows XP vereinfacht gespeicherte Benutzernamen und Kennwörter in Systemsteuerung die Verwaltung und Verwendung mehrerer Anmeldeinformationen, einschließlich X.509-Zertifikaten, die mit Smartcards und Windows Live-Anmeldeinformationen (jetzt als Microsoft-Konto bezeichnet) verwendet werden. Die Anmeldeinformationen – Teil des Benutzerprofils – werden gespeichert, bis sie benötigt werden. Diese Aktion kann die Sicherheit pro Ressource erhöhen, indem sichergestellt wird, dass bei einer Kompromittierung eines Kennworts nicht die gesamte Sicherheit gefährdet wird.
Nachdem sich ein Benutzer angemeldet hat und versucht, auf zusätzliche kennwortgeschützte Ressourcen zuzugreifen, z. B. eine Freigabe auf einem Server, und wenn die Standardanmeldeinformationen des Benutzers für den Zugriff nicht ausreichen, werden gespeicherte Benutzernamen und Kennwörter abgefragt. Wenn alternative Anmeldeinformationen mit den richtigen Anmeldeinformationen unter Gespeicherte Benutzernamen und Kennwörter gespeichert wurden, werden diese Anmeldeinformationen verwendet, um Zugriff zu erhalten. Andernfalls wird der Benutzer aufgefordert, neue Anmeldeinformationen anzugeben, die dann zur Wiederverwendung gespeichert werden können, entweder später in der Anmeldesitzung oder während einer nachfolgenden Sitzung.
Es gelten folgende Einschränkungen:
Wenn gespeicherte Benutzernamen und Kennwörter ungültige oder falsche Anmeldeinformationen für eine bestimmte Ressource enthalten, wird der Zugriff auf die Ressource verweigert, und das Dialogfeld Gespeicherte Benutzernamen und Kennwörter wird nicht angezeigt.
Gespeicherte Benutzernamen und Kennwörter speichern Anmeldeinformationen nur für die NTLM-, Kerberos-Protokoll-, Microsoft-Konto- (früher Windows Live ID) und SSL-Authentifizierung (Secure Sockets Layer). Einige Versionen von Internet Explorer verwalten einen eigenen Cache für die Standardauthentifizierung.
Diese Anmeldeinformationen werden zu einem verschlüsselten Teil des lokalen Profils eines Benutzers im Verzeichnis \Dokumente und Einstellungen\Benutzername\Anwendungsdaten\Microsoft\Anmeldeinformationen. Daher können diese Anmeldeinformationen mit dem Benutzer übertragen werden, wenn die Netzwerkrichtlinie des Benutzers Roamingbenutzerprofile unterstützt. Wenn der Benutzer jedoch über Kopien von gespeicherten Benutzernamen und Kennwörtern auf zwei verschiedenen Computern verfügt und die Anmeldeinformationen ändert, die der Ressource auf einem dieser Computer zugeordnet sind, wird die Änderung nicht an gespeicherte Benutzernamen und Kennwörter auf dem zweiten Computer weitergegeben.
Windows-Tresor und Anmeldeinformations-Manager
Der Anmeldeinformations-Manager wurde in Windows Server 2008 R2 und Windows 7 als Systemsteuerungsfunktion zum Speichern und Verwalten von Benutzernamen und Kennwörtern eingeführt. Mit dem Anmeldeinformations-Manager können Benutzer Anmeldeinformationen speichern, die für andere Systeme und Websites im sicheren Windows-Tresor relevant sind. Einige Versionen von Internet Explorer verwenden dieses Feature für die Authentifizierung bei Websites.
Die Verwaltung der Anmeldeinformationen mithilfe der Anmeldeinformationsverwaltung wird durch den Benutzer auf dem lokalen Computer gesteuert. Benutzer können Anmeldeinformationen von unterstützten Browsern und Windows-Anwendungen speichern, um ihnen das erneute Anmelden bei diesen Ressourcen zu erleichtern. Anmeldeinformationen werden auf dem Computer in dem Profil des Benutzers in speziellen verschlüsselten Ordnern gespeichert. Von Anwendungen wie Webbrowsern und Apps, die dieses Feature (durch die Verwendung von Anmeldinformationsverwaltungs-APIs) unterstützen, können während des Anmeldevorgangs anderen Computern und Websites die richtigen Anmeldeinformationen vorgelegt werden.
Wenn eine Website, eine Anwendung oder ein anderer Computer die Authentifizierung über NTLM oder das Kerberos-Protokoll anfordert, wird ein Dialogfeld angezeigt, in dem Sie das Kontrollkästchen Standardanmeldeinformationen aktualisieren oder Kennwort speichern aktivieren. Dieses Dialogfeld, in dem ein Benutzer Anmeldeinformationen lokal speichern kann, wird von einer Anwendung generiert, die die Anmeldeinformations-Manager-APIs unterstützt. Aktiviert der Benutzer das Kontrollkästchen Passwort speichern, werden der Benutzername, das Kennwort und zugehörige Informationen von der Anmeldeinformationsverwaltung für den verwendeten Authentifizierungsdienst gespeichert.
Bei der nächsten Verwendung des Diensts werden die im Schließfach für Anmeldeinformationen gespeicherten Anmeldeinformationen automatisch von der Anmeldeinformationsverwaltung bereitgestellt. Werden diese nicht akzeptiert, wird der Benutzer zur Eingabe der richtigen Information für den Zugriff aufgefordert. Wird der Zugriff mit den neuen Anmeldeinformationen gewährt, werden die vorherigen Anmeldeinformationen von der Anmeldeinformationsverwaltung mit den neuen Anmeldeinformationen überschrieben, und diese werden im Schließfach für Anmeldeinformationen gespeichert.
SAM-Datenbank
Der Security Accounts Manager (SAM) ist eine Datenbank, in der lokale Benutzerkonten und Gruppen gespeichert werden. Es ist in jedem Windows-Betriebssystem vorhanden; Wenn jedoch ein Computer mit einer Domäne verbunden ist, verwaltet Active Directory Domänenkonten in Active Directory-Domänen.
Beispielsweise können in eine Windows-Clientdomäne eingebundene Computer an einer Netzwerkdomäne teilnehmen, indem sie mit einem Domänencontroller kommunizieren, selbst wenn kein menschlicher Benutzer angemeldet ist. Zum Einleiten der Kommunikation muss der Computer über ein aktives Konto in der Domäne verfügen. Bevor Kommunikationsverbindungen vom Computer akzeptiert werden, authentifiziert die lokale Sicherheitsautorität auf dem Domänencontroller die Identität des Computers und definiert dann den Sicherheitskontext des Computers genauso wie für einen menschlichen Sicherheitsprinzipal. Dieser Sicherheitskontext definiert die Identität und die Fähigkeiten eines Benutzers oder Dienstes auf einem bestimmten Computer oder eines Benutzers, Dienstes oder eines Computers in einem Netzwerk. Beispielsweise definiert das im Sicherheitskontext enthaltene Zugriffstoken die Ressourcen (z. B. eine Dateifreigabe oder einen Drucker), auf die zugegriffen werden kann, und die Aktionen (z. B. Lesen, Schreiben oder Ändern), die von diesem Prinzipal ausgeführt werden können – ein Benutzer, Computer oder Dienst auf dieser Ressource.
Der Sicherheitskontext eines Benutzers oder Computers kann je nach Computer unterschiedlich sein, z. B. wenn sich ein Benutzer bei einem Server oder einer Arbeitsstation authentifiziert, die nicht seine primäre Arbeitsstation ist. Er kann auch je nach Sitzung variieren, z. B. wenn ein Administrator die Rechte und Berechtigungen des Benutzers ändert. Außerdem unterscheidet sich der Sicherheitskontext, wenn ein Benutzer oder Computer eigenständig, in einer gemischten Netzwerkdomäne oder als Teil einer Active Directory-Domäne ausgeführt wird.
Lokale Domänen und vertrauenswürdige Domänen
Wenn zwischen zwei Domänen eine Vertrauensstellung besteht, vertrauen die Authentifizierungsmechanismen für jede Domäne den Authentifizierungen, die von der anderen Domäne stammen. Vertrauensstellungen unterstützen den kontrollierten Zugriff auf freigegebene Ressourcen in einer Ressourcendomäne (die vertrauende Domäne), indem sie überprüfen, ob eingehende Authentifizierungsanforderungen von einer vertrauenswürdigen Zertifizierungsstelle (die vertrauenswürdige Domäne) stammen. Auf diese Weise fungieren Vertrauensstellungen als Brücken, die nur überprüfte Authentifizierungsanforderungen zwischen Domänen übertragen lassen.
Wie eine bestimmte Vertrauensstellung Authentifizierungsanforderungen weiterleitet, hängt von ihrer Konfiguration ab. Vertrauensstellungen können unidirektional sein, indem Zugriff von der vertrauenswürdigen Domäne auf Ressourcen in der vertrauenden Domäne bereitgestellt wird, oder bidirektional, indem Zugriff von jeder Domäne auf Ressourcen in der anderen Domäne bereitgestellt wird. Vertrauensstellungen sind außerdem entweder nicht transitiv, in diesem Fall besteht Vertrauen nur zwischen den beiden Vertrauenspartnerdomänen, oder transitiv, in diesem Fall erstreckt sich das Vertrauen automatisch auf alle anderen Domänen, denen einer der Partner vertraut.
Informationen zu Domänen- und Gesamtstrukturvertrauensbeziehungen in Bezug auf die Authentifizierung finden Sie unter Delegierte Authentifizierung und Vertrauensstellungen.
Zertifikate in der Windows-Authentifizierung
Die Public Key Infrastructure (PKI) ist eine Kombination aus Software, Verschlüsselungstechnologien, Prozessen und Diensten, mit deren Hilfe eine Organisation ihre Daten sowie Kommunikation und Geschäftstransaktionen schützen kann. Die Fähigkeit einer PKI, Kommunikation und Geschäftstransaktionen zu schützen, basiert auf dem Austausch digitaler Zertifikate zwischen authentifizierten Benutzern und vertrauenswürdigen Ressourcen.
Ein digitales Zertifikat ist ein elektronisches Dokument, das Informationen über die Entität, zu der es gehört, die Entität, von der es ausgestellt wurde, eine eindeutige Seriennummer oder eine andere eindeutige Identifikation, Ausstellungs- und Ablaufdaten sowie einen digitalen Fingerabdruck enthält.
Bei der Authentifizierung wird ermittelt, ob ein Remotehost vertrauenswürdig ist. Um seine Vertrauenswürdigkeit festzustellen, muss der Remotehost ein akzeptables Authentifizierungszertifikat bereitstellen.
Remotehosts stellen ihre Vertrauenswürdigkeit fest, indem sie ein Zertifikat von einer Zertifizierungsstelle (CA) abrufen. Die Zertifizierungsstelle kann wiederum von einer höheren Autorität zertifiziert werden, wodurch eine Vertrauenskette entsteht. Um zu bestimmen, ob ein Zertifikat vertrauenswürdig ist, muss eine Anwendung die Identität der Stammzertifizierungsstelle ermitteln und dann ermitteln, ob sie vertrauenswürdig ist.
Ebenso muss der Remotehost oder der lokale Computer ermitteln, ob das vom Benutzer oder der Anwendung vorgelegte Zertifikat authentisch ist. Das vom Benutzer über die LSA und SSPI vorgelegte Zertifikat wird auf dem lokalen Computer für die lokale Anmeldung, im Netzwerk oder in der Domäne über die Zertifikatspeicher in Active Directory auf Echtheit ausgewertet.
Um ein Zertifikat zu erstellen, durchlaufen Authentifizierungsdaten Hashalgorithmen, z. B. Secure Hash Algorithm 1 (SHA1), um einen Nachrichtendigest zu erstellen. Der Nachrichtendigest wird dann digital signiert, indem der private Schlüssel des Absenders verwendet wird, um nachzuweisen, dass der Nachrichtendigest vom Absender erstellt wurde.
Hinweis
SHA1 ist die Standardeinstellung in Windows 7 und Windows Vista, wurde jedoch in Windows 8 in SHA2 geändert.
Authentifizierung mit Smartcards
Smartcardtechnologie ist ein Beispiel für die zertifikatbasierte Authentifizierung. Die Anmeldung bei einem Netzwerk mit einer Smartcard bietet eine starke Form der Authentifizierung, da bei der Authentifizierung eines Benutzers bei einer Domäne kryptografiebasierte Identifizierung und Besitznachweis verwendet werden. Active Directory Certificate Services (AD CS) stellt die kryptografische Identifizierung durch die Ausstellung eines Anmeldezertifikats für jede Smartcard bereit.
Informationen zur Smartcardauthentifizierung finden Sie in der technischen Referenz zu Windows-Smartcards.
Die Technologie virtueller Smartcards wurde in Windows 8 eingeführt. Sie speichert das Smartcardzertifikat auf dem PC und schützt es dann mithilfe des manipulationssicheren TPM-Sicherheitschips (Trusted Platform Module). Auf diese Weise wird der PC tatsächlich zur Smartcard, die die PIN des Benutzers erhalten muss, um authentifiziert zu werden.
Remote- und Drahtlosauthentifizierung
Die Remote- und Drahtlosnetzwerkauthentifizierung ist eine weitere Technologie, die Zertifikate für die Authentifizierung verwendet. Der Internetauthentifizierungsdienst (IAS) und virtuelle private Netzwerkserver verwenden Extensible Authentication Protocol-Transport Level Security (EAP-TLS), PEAP (Protected Extensible Authentication Protocol) oder Internet Protocol Security (IPsec), um zertifikatbasierte Authentifizierung für viele Arten des Netzwerkzugriffs durchzuführen, einschließlich vpn (Virtual Private Network) und drahtlosen Verbindungen.
Informationen zur zertifikatbasierten Authentifizierung im Netzwerk finden Sie unter Netzwerkzugriffsauthentifizierung und Zertifikate.