Grundlegendes zu Kontospeichern

AD FS ist eng in AD DS integriert. AD FS ruft Benutzerattribute ab und authentifiziert Benutzer mit AD DS. Zudem verwendet AD FS die Windows-integrierte Authentifizierung und von AD DS erstellte Sicherheitstokens.

Damit sich ein Benutzer bei AD DS anmelden kann, muss ein Benutzername im UPN-Format (benutzer@adatum.com) oder im SAM-Kontonamenformat (adatum\benutzer) eingegeben werden.

Zugriffstokens werden generiert, wenn sich ein Benutzer anmeldet. Sie enthalten Sicherheitskennungen (Security Identifiers, SIDs) für die Benutzer und alle Gruppen, denen der Benutzer angehört. Jedem Prozess, den der Benutzer startet, wird eine Kopie des Zugriffstokens zugewiesen.

Nachdem der Benutzer angemeldet und ein Identitätswechsel ausgeführt wurde, werden Benutzer-SIDs aus dem Zugriffstoken aufgezählt. Die SIDs werden dann Organisationsgruppenansprüchen zugeordnet.

Vorsicht

Wenn Sie die Windows-Vertrauensstellung im Kontoverbunddienst aktivieren, senden Sie über das Internet tatsächliche SIDs an die Ressourcenpartnerorganisation. Dies kann ein Sicherheitsrisiko darstellen. Diese SIDs werden in das AD FS-SAML-Token (Security Assertion Markup Language) verpackt. Daher sollten Sie diese Option nur auswählen, wenn Sie den Entwurf für Federated-Web-SSO (verbundene einmalige Webanmeldung, Single-Sign-On) mit Gesamtstruktur-Vertrauensstellung verwenden. Mit diesem Entwurf wird eine sichere Kommunikation innerhalb derselben Organisation ermöglicht.

E-Mail-Ansprüche, allgemeine Namensansprüche und benutzerdefinierte Ansprüche können aus in AD DS definierten Benutzerobjektattributen extrahiert werden, wenn das Verbunddienstkonto zum Ausführen einer LDAP-Suche eines Objekts verwendet wird.

Das Verbunddienstkonto muss Zugriff auf das Benutzerobjekt haben. Wenn sich das Benutzerobjekt in einer anderen Domäne als das Verbunddienstkonto befindet, muss die Domäne des Benutzerobjekts über eine AD DS-Vertrauensstellung mit der Domäne des Verbunddienstkontos verfügen.

Das Vorhandensein eines Benutzernamens in AD DS und in allen Verzeichnissen, denen AD DS vertraut (direkt oder transitiv), kann nicht direkt festgestellt werden. AD DS gibt nur dann einen Autorisierungsfehler zurück, wenn bei der Anmeldung infolge von Richtlinieneinschränkungen ein Fehler auftritt. Die folgende Liste enthält Beispiele für Fehler aufgrund von Richtlinieneinschränkungen:

• Das Konto ist deaktiviert.
  
  
• Das Kontokennwort ist abgelaufen.
  
  
• Das Konto ist nicht zur Anmeldung an diesem Computer berechtigt.
  
  
• Für das Konto gelten Einschränkungen der Anmeldezeit, und zu diesem Zeitpunkt ist eine Anmeldung nicht zulässig.
  
  

Ansonsten sind AD DS-Kontospeicherfehler immer nicht autorisierend, und der gemäß Prioritätsreihenfolge nächste Kontospeicher wird verwendet. Weitere Informationen zu Kontospeicher-Anmeldefehlern finden Sie unter Problembehandlung bei AD FS.

AD LDS stellt Datenspeicherung und Datenabruf für Active Directory-fähige Anwendungen bereit. Dabei gelten jedoch nicht die für AD DS erforderlichen Abhängigkeiten. AD LDS bietet eine ähnliche Funktionalität wie AD DS, erfordert jedoch nicht die Bereitstellung von Domänen oder Domänencontrollern. In ähnlicher Weise, wie AD FS Kontospeicherinformationen von AD DS nutzt, kann AD FS mit AD LDS auch Benutzerattribute abrufen und Benutzer authentifizieren.

	Hinweis
	AD FS kann keine AD LDS-Konten authentifizieren, deren Kontonamen Klammern enthalten. Konten mit einer offenen Klammer im Benutzernamen verursachen einen LDAP-Suchfehler, da der Benutzername einen ungültigen LDAP-Filter bildet.

Das Verbunddienstkonto ruft die Ansprüche ab, die zum Ausführen einer LDAP-Suche für das Objekt verwendet werden. Weitere Informationen finden Sie unter Grundlegendes zu Ansprüchen. Dieser Prozess umfasst zwei Schritte:

• Zunächst wird das Benutzerobjekt vom Verbunddienstkonto ausfindig gemacht, indem es nach dem Objekt sucht, dessen konfiguriertes Attribut dem angegebenen Benutzernamen entspricht. Das Verbunddienstkonto schützt die Kommunikation mithilfe der Kerberos-Authentifizierung oder der NTLM-Verschlüsselung.
  
  

  	Hinweis
  	Dieser Prozess setzt voraus, dass der AD LDS-Server einer Domäne hinzugefügt wird, die der Domäne des Verbunddiensts vertraut.

• Anschließend werden die Benutzeranmeldeinformationen bestätigt, indem das gefundene Benutzerobjekt mithilfe von LDAP an das angegebene Kennwort gebunden wird. Wenn in der Vertrauensrichtlinie TLS/SSL (Transport Layer Security/Secure Sockets Layer) für die AD LDS-Kontospeichereigenschaften konfiguriert ist, werden die Benutzeranmeldeinformationen geschützt.
  
  

  	Wichtig
  	Es wird ausdrücklich empfohlen, den Datenverkehr zwischen dem AD LDS-Server und dem Verbundserver mithilfe von TLS/SSL oder anderen Mechanismen, z. B. IPsec (Internet Protocol Security), zu schützen.

Wenn die LDAP-Abfrage für den eingegebenen Benutzernamen mehrere Objekte zurückgibt, gilt dies als Authentifizierungsfehler.

Es wird zunächst geprüft, ob das Benutzerkonto im AD LDS-Kontospeicher konfiguriert ist, und anschließend werden alle anderen LDAP-Speicher in dieser Reihenfolge konfiguriert. Wenn das Benutzerkonto von einem beliebigen Speicher gefunden wird, wird eine autorisierende Anmeldung des Benutzers vorgenommen. Anschließend wird die Benutzeranmeldeanforderung von keinem anderen Kontospeicher mehr verarbeitet.

Wenn ein Benutzer eine Anmeldeanforderung an AD DS oder AD LDS über einen AD FS-Client ausgibt, wird die Anforderung unmittelbar an den angegebenen Kontospeicher übergeben. Wird der Kontospeicher-URI (Uniform Resource Identifier) jedoch nicht angegeben, probiert der Verbunddienst jeden Speicher in der festgelegten Prioritätsreihenfolge aus, um den Benutzer anzumelden. Das Authentifizierungsergebnis wird in den folgenden Fällen zurückgegeben:

• Es ist nur ein Speicher konfiguriert, und Informationen zur Überprüfung der Anmeldeinformationen werden zurückgegeben.
  
  
• Der Speicher-URI wurde in der Anmeldeanforderung angegeben, und Informationen zur Überprüfung der Anmeldeinformationen werden zurückgegeben.
  
  
• Das Authentifizierungsergebnis von einem der Speicher ist autorisierend.
  
  
• Die Authentifizierung durch einen der Speicher kann erfolgreich ausgeführt werden.
  
  

Sie können jeden einzelnen Kontospeicher aktivieren oder deaktivieren. Wenn ein Kontospeicher deaktiviert ist, nimmt er nicht an kontospeicherspezifischen Vorgängen teil. Cookies mit Ansprüchen, die aus einem derzeit deaktivierten Kontospeicher stammen, werden verworfen oder gelöscht, und der Client wird zur Anmeldeseite umgeleitet.