AD FS-Anforderungen für Windows Server
Nachfolgend sind die verschiedenen Anforderungen aufgeführt, die Sie bei der Bereitstellung von AD FS erfüllen müssen:
Zertifikatanforderungen
Zertifikate spielen eine äußerst wichtige Rolle beim Sichern der Kommunikation zwischen Verbundservern, Webanwendungsproxys, Ansprüche unterstützenden Anwendungen und Webclients. Die Anforderungen für Zertifikate sind unterschiedlich, je nachdem, ob Sie einen Verbundserver oder einen Proxy-Computer einrichten, wie in diesem Abschnitt beschrieben.
Verbundserverzertifikate
| Zertifikattyp | Anforderungen, Support & Wissenswertes |
|---|---|
| SSL-Zertifikat: Dieses Standard-SSL-Zertifikat wird für das Sichern der Kommunikation zwischen Verbundservern und Clients verwendet. | – Dieses Zertifikat muss ein öffentlich vertrauenswürdiges* Zertifikat vom Typ X509 v3 sein. – Alle Clients, die auf einen AD FS-Endpunkt zugreifen, müssen diesem Zertifikat vertrauen. Wir empfehlen Ihnen dringend die Verwendung von Zertifikaten, die von einer öffentlichen Zertifizierungsstelle (Drittanbieter) ausgestellt werden. Sie können ein selbstsigniertes SSL-Zertifikat für Verbundserver in einer Testumgebung verwenden. Bei einer Produktionsumgebung wird jedoch empfohlen, dass Sie das Zertifikat von einer öffentlichen Zertifizierungsstelle beziehen. – Unterstützt alle Schlüsselgrößen, die von Windows Server 2012 R2 für SSL-Zertifikate unterstützt werden. – Unterstützt keine Zertifikate, die CNG-Schlüssel verwenden. – Wenn er zusammen mit dem Workplace Join/Device Registration Service verwendet wird, muss der alternative Antragstellername des SSL-Zertifikats für den AD FS-Dienst den Wert „enterpriseregistration“ enthalten, gefolgt vom Benutzerprinzipalnamen-Suffix Ihres Unternehmens, z. B. enterpriseregistration.contoso.com. – Platzhalterzertifikate werden unterstützt. Wenn Sie Ihre AD FS-Farm erstellen, werden Sie aufgefordert, den Dienstnamen für den AD FS-Dienst einzugeben (z. B. adfs.contoso.com). – Es wird dringend empfohlen, dasselbe SSL-Zertifikat für den Webanwendungsproxy zu verwenden. Es muss zwingend dasselbe Zertifikat sein, wenn Sie Endgeräte mit integrierter Windows-Authentifizierung über den Webanwendungsproxy unterstützt werden und wenn die erweiterte Schutzauthentifizierung aktiviert ist (Standardeinstellung). – Der Antragstellername dieses Zertifikats wird verwendet, um den Namen des Verbunddiensts für jede von Ihnen bereitgestellte Instanz von AD FS darzustellen. Aus diesem Grund sollten Sie einen Antragsstellernamen für jedes neue von einer Zertifizierungsstelle ausgestellte Zertifikat in Betracht ziehen, der den Namen Ihres Unternehmens oder Ihrer Organisation gegenüber Partnern am besten widerspiegelt. Die Identität des Zertifikats muss mit dem Namen des Verbunddienstes übereinstimmen (z. B. fs.contoso.com). Die Identität ist entweder eine Erweiterung für den alternative Antragstellernamen vom Typ dNSName oder, wenn keine alternativen Antragstellernamen vorhanden sind, der Antragstellername, der als allgemeiner Name angegeben ist. Im Zertifikat können mehrere Einträge für alternativer Antragstellernamen vorhanden sein, sofern einer der Einträge mit dem Namen des Verbunddienstes übereinstimmt. - Wichtig: Es wird dringend empfohlen, dasselbe SSL-Zertifikat für alle Knoten und alle Webanwendungsproxy-Server der AD FS-Farm zu verwenden. |
| Dienstkommunikationszertifikat: Mit diesem Zertifikat wird die WCF-Nachrichtensicherheit für den Schutz der Kommunikation zwischen Verbundservern ermöglicht. | – Standardmäßig wird das SSL-Zertifikat als Dienstkommunikationszertifikat verwendet. Sie können aber auch ein anderes Zertifikat als Dienstkommunikationszertifikat festlegen. - Wichtig: Wenn Sie das SSL-Zertifikat als Dienstkommunikationszertifikat verwenden und das SSL-Zertifikat abläuft, stellen Sie sicher, dass Sie das erneuerte SSL-Zertifikat als Dienstkommunikationszertifikat festlegen. Dies geschieht nicht automatisch. – Clients von AD FS, die die WCF-Nachrichtensicherheit verwenden, müssen diesem Zertifikat vertrauen. – Wir empfehlen die Verwendung eines Serverauthentifizierungszertifikats, das von einer öffentlichen (Drittanbieter-) Zertifizierungsstelle ausgestellt wurde. – Das Dienstkommunikationszertifikat darf kein Zertifikat sein, das CNG-Schlüssel verwendet. – Sie können das Zertifikat über die AD FS-Verwaltungskonsole verwalten. |
| Tokensignaturzertifikat: Dies ist ein Standard-X509-Zertifikat, das für die sichere Signierung aller Token verwendet wird, die der Verbundserver ausstellt. | – Standardmäßig erstellt AD FS ein selbstsigniertes Zertifikat mit 2048 Bitschlüsseln. – Von der Zertifizierungsstelle ausgestellte Zertifikate werden ebenfalls unterstützt und können mit dem AD FS-Verwaltungs-Snap-In geändert werden. – Die Speicherung von Zertifikaten, die von der Zertifizierungsstelle ausgestellt wurden, und der Zugriff auf diese Zertifikate müssen über einen CSP-Kryptografie-Anbieter erfolgen. – Das Tokensignaturzertifikat darf kein Zertifikat sein, das CNG-Schlüssel verwendet. – AD FS erfordert keine extern registrierten Zertifikate für die Tokensignatur. AD FS erneuert diese selbstsignierten Zertifikate automatisch, bevor sie ablaufen. AD FS konfiguriert die neuen Zertifikate zunächst als sekundäre Zertifikate, damit Partner sie nutzen können, und wechselt dann in einem Prozess, der als automatischer Zertifikatrollover bezeichnet wird, zum primären Zertifikat. Es wird empfohlen, die automatisch generierten Standardzertifikate für die Tokensignatur zu verwenden. Wenn die Richtlinien Ihres Unternehmens vorgeben, dass unterschiedliche Zertifikate für die Tokensignatur konfiguriert werden müssen, können Sie die Zertifikate bei der Installation in der PowerShell angeben (mit dem Parameter –SigningCertificateThumbprint des cmdlets Install-AdfsFarm). Nach der Installation können Sie die Tokensignaturzertifikate über die AD FS-Verwaltungskonsole oder mit den PowerShell-cmdlets Set-AdfsCertificate und Get-AdfsCertificate anzeigen und verwalten. Wenn extern registrierte Zertifikate für die Tokensignatur verwendet werden, führt AD FS die Zertifikatsverlängerung und Zertifikatrollover nicht automatisch aus. Dieser Prozess muss von einem Administrator ausgeführt werden. Um einen Zertifikatrollover zu ermöglichen, wenn ein Zertifikat kurz vor dem Ablauf steht, können Sie in AD FS ein sekundäres Tokensignaturzertifikat konfigurieren. Standardmäßig werden alle Zertifikate in den Verbundmetadaten veröffentlicht, aber zum Signieren von Token verwendet AD FS nur das primäre Tokensignaturzertifikat. |
| Tokenentschlüsselung/Verschlüsselungszertifikat: Dies ist ein X509-Standardzertifikat, das zum Entschlüsseln/Verschlüsseln aller eingehenden Token verwendet wird. Es wird außerdem in den Verbundmetadaten veröffentlicht. | – Standardmäßig erstellt AD FS ein selbstsigniertes Zertifikat mit 2048 Bitschlüsseln. – Von der Zertifizierungsstelle ausgestellte Zertifikate werden ebenfalls unterstützt und können mit dem AD FS-Verwaltungs-Snap-In geändert werden. – Die Speicherung von Zertifikaten, die von der Zertifizierungsstelle ausgestellt wurden, und der Zugriff auf diese Zertifikate müssen über einen CSP-Kryptografie-Anbieter erfolgen. – Das Zertifikat für die Tokenentschlüsselung/-verschlüsselung darf kein Zertifikat sein, das CNG-Schlüssel verwendet. – Standardmäßig generiert und verwendet AD FS eigene, intern erzeugte und selbstsignierte Zertifikate für die Tokenentschlüsselung. AD FS erfordert keine extern registrierten Zertifikate für diesen Zweck. Darüber hinaus erneuert AD FS diese selbstsignierten Zertifikate automatisch, bevor sie ablaufen. Wir empfehlen Ihnen, die automatisch generierten Standardzertifikate für die Tokenentschlüsselung zu verwenden. Wenn die Richtlinien Ihres Unternehmens vorgeben, dass unterschiedliche Zertifikate für die Tokenentschlüsselung konfiguriert werden müssen, können Sie die Zertifikate bei der Installation in der PowerShell angeben (mit dem Parameter –DecryptionCertificateThumbprint des cmdlets Install-AdfsFarm). Nach der Installation können Sie die Tokenentschlüsselungszertifikate über die AD FS-Verwaltungskonsole oder mit den PowerShell-cmdlets Set-AdfsCertificate und Get-AdfsCertificate anzeigen und verwalten. Wenn Sie extern registrierte Zertifikate für die Tokenentschlüsselung verwenden, führt AD FS keine automatische Zertifikatsverlängerung durch. Dieser Prozess muss von einem Administrator ausgeführt werden.. – Das AD FS-Dienstkonto muss über Zugriff auf den privaten Schlüssel des Tokensignaturzertifikats im persönlichen Speicher des lokalen Computers verfügen. Dafür wird während des Setups gesorgt. Sie können auch das AD FS-Snap-In „Verwaltung“ verwenden, um diesen Zugriff sicherzustellen, wenn Sie das Tokensignaturzertifikat anschließend ändern. |
Achtung
Zertifikate, die für die Tokensignatur und die Tokenentschlüsselung-/verschlüsselung verwendet werden, sind wichtig für die Stabilität des Verbunddiensts. Kunden, die ihre eigenen Zertifikate für Tokensignatur und Tokenentschlüsselung bzw. -verschlüsselung verwalten, sollten sicherstellen, dass diese Zertifikate gesichert werden und während eines Wiederherstellungsereignisses unabhängig voneinander verfügbar sind.
Hinweis
In AD FS können Sie die für digitale Signaturen verwendete SHA-Ebene (Secure Hash Algorithm) in SHA-1 oder SHA-256 (höhere Sicherheit) ändern. Die Verwendung von Zertifikaten mit anderen Hashmethoden als MD5 (Standardhashalgorithmus, der mit dem Befehlszeilentool „Makecert.exe“ verwendet wird) wird von AD FS nicht unterstützt. Als bewährte Sicherheitsmethode empfehlen wir die Verwendung von SHA-256 (Standardeinstellung) für alle Signaturen. SHA-1 wird nur in Szenarien empfohlen, in denen Sie mit einem Produkt interoperieren müssen, das keine Kommunikation über SHA-256 unterstützt, beispielsweise ein nicht von Microsoft stammendes Produkt oder alte Versionen von AD FS.
Hinweis
Nachdem Sie ein Zertifikat von einer Zertifizierungsstelle erhalten haben, stellen Sie sicher, dass alle Zertifikate in den persönlichen Zertifikatspeicher auf dem lokalen Computer importiert werden. Sie können Zertifikate über das MMC-Snap-In „Zertifikate“ in den persönlichen Speicher importieren.
Hardwareanforderungen
Die folgenden Mindest- und empfohlenen Hardwareanforderungen gelten für die AD FS-Verbundserver unter Windows Server 2012 R2:
| Hardwareanforderung | Mindestanforderung | Empfohlene Anforderung |
|---|---|---|
| CPU-Geschwindigkeit | 1,4-GHz-Prozessor mit 64 Bit | Quad-Core, 2 GHz |
| RAM | 512 MB | 4 GB |
| Speicherplatz | 32 GB | 100 GB |
Softwareanforderungen
Die folgenden AD FS-Anforderungen gelten für die Serverfunktionalität, die in das Betriebssystem Windows Server® 2012 R2 integriert ist:
Für den Extranetzugriff muss der Webanwendungsproxy-Rollendienst als Teil der Remotezugriffs-Serverrolle von Windows Server® 2012 R2 bereitgestellt werden. Frühere Versionen eines Verbundserverproxys werden von AD FS unter Windows Server® 2012 R2 nicht unterstützt.
Ein Verbundserver und der Webanwendungsproxy-Rollendienst können nicht auf demselben Computer installiert werden.
AD DS-Anforderungen
Anforderungen an den Domänencontroller
Domänencontroller in allen Benutzerdomänen und der Domäne, der die AD FS-Server beigetreten sind, müssen Windows Server 2008 oder höher ausführen.
Hinweis
Die Unterstützung von Umgebungen mit Windows Server 2003-Domänencontrollern endet nach dem Enddatum für den erweiterten Support für Windows Server 2003. Wir empfehlen Kunden daher dringend, ihre Domänencontroller so bald wie möglich zu aktualisieren. Weitere Informationen zum Microsoft Support Lifecycle finden Sie auf dieser Seite. Fehlerbehebungen für Probleme, die nur in Umgebungen mit Windows Server 2003-Domänencontrollerumgebungen auftreten, werden nur für Sicherheitsprobleme veröffentlicht und nur dann, wenn die Fehlerbehebung vor dem Ablauf des erweiterten Supports für Windows Server 2003 veröffentlicht werden kann.
Hinweis
AD FS erfordert einen vollständig beschreibbaren Domänencontroller; ein schreibgeschützter Domänencontroller reicht nicht aus. Wenn die geplante Topologie einen schreibgeschützten Domänencontroller umfasst, kann er für die Authentifizierung genutzt werden. Für die LDAP-Anspruchsverarbeitung ist eine Verbindung mit dem beschreibbaren Domänencontroller erforderlich.
Anforderungen an die Domänenfunktionsebene
Alle Benutzerkontodomänen und die Domäne, mit der die AD FS-Server verbunden sind, müssen auf der Domänenfunktionsebene von Windows Server 2003 oder höher betrieben werden.
Für die meisten AD FS-Features sind für einen erfolgreichen Betrieb keine Änderungen auf der AD DS-Funktionsebene erforderlich. Allerdings ist die Windows Server 2008-Domänenfunktionsebene oder höher erforderlich, damit die Clientzertifikatauthentifizierung erfolgreich betrieben werden kann, wenn das Zertifikat explizit einem Benutzerkonto in AD DS zugeordnet ist.
Schemaanforderungen
AD FS erfordert keine Schemaänderungen oder Modifikationen auf Funktionsebene an AD DS.
Um die Workplace Join-Funktion zu nutzen, muss das Schema der Gesamtstruktur, der AD FS-Server beigetreten sind, auf „Windows Server 2012 R2“ festgelegt werden.
Dienstkontenanforderungen
Sie können jedes Standard-Dienstkonto als Dienstkonto für AD FS verwenden. Über Gruppen verwaltete Dienstkonten werden ebenfalls unterstützt. Dafür ist mindestens ein Domänencontroller erforderlich (empfohlen wird die Bereitstellung von mindestens zwei Domänencontrollern), auf denen Windows Server 2012 oder höher ausgeführt wird.
Damit die Kerberos-Authentifizierung zwischen Clients, die in die Domäne eingebunden sind, und AD FS funktioniert, müssen Sie „HOST/<adfs_service_name>“ als SPN im Dienstkonto registrieren. Standardmäßig nimmt AD FS diese Konfiguration vor, wenn Sie eine neue AD FS-Farm erstellen, wenn die Berechtigungen zum Durchführen dieses Vorgangs vorliegen.
Das AD FS-Dienstkonto muss in jeder Benutzerdomäne vertrauenswürdig sein, die Benutzer enthält, die sich beim AD FS-Dienst authentifizieren.
Domänenanforderungen
Alle AD FS-Server müssen einer AD DS-Domäne beigetreten sein.
Alle AD FS-Server in einer Farm müssen in einer einzigen Domäne bereitgestellt werden.
Die Domäne, in die die AD FS-Server eingebunden sind, müssen jeder Benutzerkontodomäne vertrauen, die Benutzer enthält, die sich beim AD FS-Dienst authentifizieren.
Anforderungen für mehrere Gesamtstrukturen
Die Domäne, in die die AD FS-Server eingebunden sind, muss jeder Benutzerkontodomäne oder jeder Gesamtstruktur vertrauen, die Benutzer enthält, die sich beim AD FS-Dienst authentifizieren.
Das AD FS-Dienstkonto muss in jeder Benutzerdomäne vertrauenswürdig sein, die Benutzer enthält, die sich beim AD FS-Dienst authentifizieren.
Anforderungen an die Konfigurationsdatenbank
Nachfolgend finden Sie die Anforderungen und Einschränkungen, die je nach Typ des Konfigurationsspeichers gelten:
WID
Bei maximal 100 Vertrauensstellungen der vertrauenden Seite ist eine WID-Farm auf 30 Verbundserver begrenzt.
Das Artefaktauflösungsprofil von SAML 2.0 wird in der WID-Konfigurationsdatenbank nicht unterstützt. Die Erkennung der Tokenmehrfachverwendung wird in der WID-Konfigurationsdatenbank nicht unterstützt. Diese Funktionalität wird nur in Szenarien verwendet, in denen AD FS als Verbundanbieter fungiert und Sicherheitstoken von externen Anspruchsanbietern verbraucht.
Die Bereitstellung von AD FS-Servern in verschiedenen Rechenzentren für das Failover oder den geografischen Lastenausgleich wird unterstützt,solange höchstens 30 Server vorhanden sind.
Die folgende Tabelle enthält eine Zusammenfassung der Verwendung einer WID-Farm. Verwenden Sie diese, um Ihre Implementierung zu planen.
| 1–100 Vertrauensstellungen der vertrauenden Seite (RP) | Mehr als 100 Vertrauensstellungen der vertrauenden Seite (RP) |
|---|---|
| 1–30 AD FS-Knoten: Von WID unterstützt | 1–30 AD FS-Knoten: Bei Verwendung von WID nicht unterstützt – SQL erforderlich |
| Mehr als 30 AD FS-Knoten: Bei Verwendung von WID nicht unterstützt – SQL erforderlich | Mehr als 30 AD FS-Knoten: Bei Verwendung von WID nicht unterstützt – SQL erforderlich |
SQL Server
Bei Windows Server 2012 R2 können Sie für AD FS SQL Server 2008 und höher verwenden.
Browseranforderungen
Wenn die AD FS-Authentifizierung über einen Browser oder ein Browsersteuerelement durchgeführt wird, muss der Browser die folgenden Anforderungen erfüllen:
JavaScript muss aktiviert sein
Cookies müssen aktiviert sein.
Die Servernamensanzeige (Server Name Indicator, SNI) muss unterstützt werden.
Für die Benutzerzertifikat- und Gerätezertifikatauthentifizierung (Workplace Join-Funktion) muss der Browser die SSL-Clientzertifikatauthentifizierung unterstützen
Mehrere gängige Browser und Plattformen wurden hinsichtlich des Renderings und der Funktionalität überprüft. Details hierzu sind nachfolgend aufgeführt. Browser und Geräte, die in dieser Tabelle nicht enthalten sind, werden dennoch unterstützt, wenn sie die oben genannten Anforderungen erfüllen:
| Browser | Plattformen |
|---|---|
| IE 10.0 | Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 |
| IE 11.0 | Windows7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 |
| Windows-Webauthentifizierungsbroker | Windows 8.1 |
| Firefox [v21] | Windows 7, Windows 8.1 |
| Safari [v7] | iOS 6, Mac OS-X 10.7 |
| Chrome [v27] | Windows 7, Windows 8.1, Windows Server 2012, Windows Server 2012 R2, Mac OS-X 10.7 |
Wichtig
Bekanntes Problem: Firefox: Die Workplace Join-Funktion, die das Gerät anhand des Gerätezertifikats identifiziert, funktioniert auf Windows-Plattformen nicht. Die SSL-Client-Zertifikatauthentifizierung mit Zertifikaten, die im Benutzerzertifikatspeicher auf Windows-Clients bereitgestellt werden, wird in Firefox aktuell nicht unterstützt.
Cookies
AD FS erstellt sitzungsbasierte und beständige Cookies, die auf Clientcomputern gespeichert werden müssen, um Anmeldung, Abmeldung, einmaliges Anmelden (SSO) und andere Funktionen bereitzustellen. Daher muss der Clientbrowser so konfiguriert sein, dass Cookies akzeptiert werden. Für die Authentifizierung verwendete Cookies sind immer Secure Hypertext Transfer Protocol (HTTPS)-Sitzungscookies, die für den Ursprungsserver geschrieben werden. Wenn die Konfiguration des Clientbrowsers diese Cookies nicht zulässt, kann AD FS nicht ordnungsgemäß funktionieren. Beständige Cookies werden verwendet, um die Benutzerauswahl des Anspruchsanbieters beizubehalten. Sie können diese über eine Konfigurationseinstellung in der Konfigurationsdatei für die AD FS-Anmeldeseiten deaktivieren. Aus Sicherheitsgründen ist eine Unterstützung für TLS/SSL erforderlich.
Extranetanforderungen
Um für den AD FS-Dienst Extranetzugriff bereitzustellen, müssen Sie den Webanwendungsproxy-Rollendienst als extranetseitige Rolle bereitstellen, die Authentifizierungsanforderungen als Proxy sicher für den AD FS-Dienst bereitstellt. Dadurch werden die AD FS-Dienstendpunkte sowie alle Sicherheitsschlüssel (wie Zertifikate für die Tokensignatur) von Anforderungen isoliert, die aus dem Internet stammen. Darüber hinaus erfordern Funktionen wie die sanfte Extranet-Kontosperre die Verwendung des Webanwendungsproxys. Weitere Informationen zum Webanwendungsproxy finden Sie unter Webanwendungsproxy. `
Netzwerkanforderungen
Die korrekte Konfiguration der folgenden Netzwerkdienste ist für die erfolgreiche Bereitstellung von AD FS in Ihrem Unternehmen unabdingbar:
Konfiguration der Unternehmensfirewall
Sowohl die Firewall zwischen dem Webanwendungsproxy und der Verbundserverfarm als auch die Firewall zwischen den Clients und dem Webanwendungsproxy müssen den TCP-Port 443 für eingehende Daten aktiviert haben.
Wenn die Clientbenutzerzertifikat-Authentifizierung (clientTLS-Authentifizierung mit X509-Benutzerzertifikaten) benötigt wird, setzt AD FS unter Windows Server 2012 R2 voraus, dass der TCP-Port 49443 auf der Firewall zwischen den Clients und dem Webanwendungsproxy für eingehende Daten geöffnet ist. Auf der Firewall zwischen dem Webanwendungsproxy und den Verbundservern ist dies nicht erforderlich.
Hinweis
Stellen Sie außerdem sicher, dass der Port 49443 nicht von anderen Diensten auf dem AD FS- und Webanwendungsproxy-Server verwendet wird.
Konfigurieren des DNS
Für den Intranetzugriff müssen alle Clients, die im internen Unternehmensnetzwerk (Intranet) auf den AD FS-Dienst zugreifen, den Namen des AD FS-Dienstes (vom SSL-Zertifikat bereitgestellt) für den Load Balancer für den bzw. die AD FS-Server auflösen können.
Für den Extranetzugriff müssen alle Clients, die von außerhalb des Unternehmensnetzwerks (Extranet/Internet) auf den AD FS-Dienst zugreifen, den Namen des AD FS-Dienstes (vom SSL-Zertifikat bereitgestellt) für den Load Balancer für den bzw. die Webanwendungsproxy-Server auflösen können.
Damit der Extranetzugriff ordnungsgemäß funktioniert, muss jeder Webanwendungsproxy im Umkreisnetzwerk den Namen des AD FS-Dienstes (vom SSL-Zertifikat bereitgestellt) für den Load Balancer für den bzw. die AD FS-Server auflösen können. Sie können zu diesem Zweck einen alternativen DNS-Server im Umkreisnetzwerk verwenden oder die lokale Serverauflösung mit der HOSTS-Datei ändern.
Damit die integrierte Windows-Authentifizierung innerhalb und außerhalb des Netzwerks für einen Teil der Endgeräte funktioniert, die über das Webanwendungsproxy verfügbar gemacht werden, müssen Sie mit einem A-Eintrag (keinem CNAME) auf die Load Balancer verweisen.
Informationen zur Konfiguration des Unternehmens-DNS für den Verbunddienst und den Geräteregistrierungsdienst finden Sie unter Konfigurieren des Unternehmens-DNS für den Verbunddienst und DRS.
Informationen zur Konfiguration des Unternehmens-DNS für Webanwendungsproxys finden Sie im Abschnitt „Konfigurieren des DNS“ unter Schritt 1: Konfigurieren der Infrastruktur für den Webanwendungsproxy.
Informationen zur Konfiguration einer Cluster-IP-Adresse oder eines Cluster-FQDN mit NLB finden Sie unter http://go.microsoft.com/fwlink/?LinkId=75282 im Abschnitt „Angeben der Clusterparameter“.
Anforderungen an den Attributspeicher
AD FS erfordert die Verwendung von mindestens einem Attributspeicher für das Authentifizieren von Benutzern und das Extrahieren von Sicherheitsansprüchen für diese Benutzer. Eine Liste der von AD FS unterstützten Attributspeicher finden Sie unter The Role of Attribut Stores.
Hinweis
AD FS erstellt standardmäßig automatisch einen „Active Directory“-Attributspeicher. Die Anforderungen an den Attributspeicher hängen davon ab, ob Ihre Organisation als Kontopartner (der die Verbundbenutzer hostet) oder als Ressourcenpartner (der die Verbundanwendung hostet) agiert.
LDAP-Attributspeicher
Wenn Sie mit anderen Lightweight Directory Access Protocol (LDAP)-basierten Attributspeichern arbeiten, müssen Sie eine Verbindung zu einem LDAP-Server herstellen, der die integrierte Windows-Authentifizierung unterstützt. Die LDAP-Verbindungszeichenfolge muss außerdem im Format einer LDAP-URL geschrieben sein, wie in RFC 2255 beschrieben.
Außerdem benötigt das Dienstkonto für den AD FS-Dienst die Berechtigung zum Abrufen von Benutzerinformationen aus dem LDAP-Attributspeicher.
SQL Server-Attributspeicher
Damit AD FS unter Windows Server 2012 R2 ordnungsgemäß funktioniert, müssen Computer, die den SQL Server-Attributspeicher hosten, Microsoft SQL Server 2008 oder höher ausführen. Wenn Sie mit SQL-basierten Attributspeichern arbeiten, müssen Sie außerdem eine Verbindungszeichenfolge konfigurieren.
Benutzerdefinierte Attributspeicher
Sie können benutzerdefinierte Attributspeicher entwickeln, um erweiterte Szenarien zu aktivieren.
Die in AD FS integrierte Richtiliniensprache kann auf benutzerdefinierte Attributspeicher verweisen, sodass jedes der folgenden Szenarien verbessert werden kann:
Erstellen von Ansprüchen für einen lokal authentifizierten Benutzer
Ergänzen von Ansprüchen für einen lokal authentifizierten Benutzer
Autorisieren eines Benutzers zum Abrufen eines Token
Autorisieren eines Diensts zum Abrufen eines Token zum Verhalten eines Benutzers
Ausgabe zusätzlicher Daten in Sicherheitstoken, die von AD FS für vertrauende Seiten ausgestellt wurden.
Alle benutzerdefinierten Attributspeicher müssen auf .NET 4.0 oder höher aufsetzen.
Wenn Sie einen benutzerdefinierten Attributspeicher verwenden, müssen Sie möglicherweise auch eine Verbindungszeichenfolge konfigurieren. In diesem Fall können Sie einen beliebigen benutzerdefinierten Code eingeben, der die Verbindung mit Ihrem benutzerdefinierten Attributspeicher ermöglicht. In diesem Fall besteht die Verbindungszeichenfolge aus einem Satz an Name-Wert-Paaren, die vom Entwickler des benutzerdefinierten Attributspeichers als implementiert interpretiert werden. Weitere Informationen zur Entwicklung und Verwendung von benutzerdefinierten Attributspeichern finden Sie unter Übersicht über Attributspeicher.
Anwendungsanforderungen
AD FS unterstützt Ansprüche unterstützenden Anwendungen, die die folgenden Protokolle nutzen:
WS-Federation
WS-Trust
SAML 2.0-Protokoll mit IPDLite, SPLITE und eGov1.5-Profilen.
OAuth 2.0-Profil für die Autorisierungserteilung
AD FS unterstützt außerdem die Authentifizierung und Autorisierung für Anwendungen, die keine Ansprüche unterstützen, die aber vom Webanwendungsproxy unterstützt werden.
Authentifizierungsanforderungen
AD DS-Authentifizierung (primäre Authentifizierung)
Für den Intranetzugriff werden die folgenden standardmäßigen Authentifizierungsmethoden für AD DS unterstützt:
Integrierte Windows-Authentifizierung mit Negotiate für Kerberos und NTLM
Formularauthentifizierung mit Benutzername/Kennwort
Zertifikatauthentifizierung mit Zertifikaten, die Benutzerkonten in AD DS zugeordnet sind
Für den Extranetzugriff werden die folgenden Authentifizierungsmethoden unterstützt:
Formularauthentifizierung mit Benutzername/Kennwort
Zertifikatauthentifizierung mit Zertifikaten, die Benutzerkonten in AD DS zugeordnet sind.
Integrierte Windows-Authentifizierung mit Negotiate (nur NTLM) für WS-Trust-Endgeräte, die die integrierte Windows-Authentifizierung akzeptieren.
Für die Zertifikatauthentifizierung:
Erweitert auf Smartcards, die mit einer PIN geschützt werden können.
Die Benutzeroberfläche, über die Benutzer ihre PIN eingeben können, wird nicht von AD FS bereitgestellt und muss Teil des Client-Betriebssystems sein, das bei der Verwendung von Client-TLS angezeigt wird.
Der Leser und der Kryptografiedienstanbieter (CSP) für die Smartcard müssen auf dem Computer arbeiten, auf dem sich der Browser befindet.
Das Zertifikat der Smartcard muss mit einem vertrauenswürdigen Stamm auf allen AD FS-Servern und Webanwendungsproxy-Servern verkettet sein.
Das Zertifikat muss dem Benutzerkonto in AD DS mit einer der folgenden Methoden zugeordnet sein:
Der Antragstellername des Zertifikats entspricht dem definierten LDAP-Namen eines Benutzerkontos in AD DS.
Die Erweiterung für den Zertifikatantragsteller-AlternatNamen verfügt über den Benutzerprinzipalnamen eines Benutzerkontos AD DS.
Damit die integrierte Windows-Authentifizierung mit Kerberos im Intranet problemlos funktioniert,
muss der Dienstname Teil der vertrauenswürdigen Websites oder der lokalen Intranetwebsites sein.
Zusätzlich muss der SPN HOST/<adfs_service-name> auf das Dienstkonto festgelegt werden, auf dem die AD FS-Farm ausgeführt wird.
Multi-Factor Authentication
AD FS unterstützt die zusätzliche Authentifizierung (neben der primären von AD DS unterstützten Authentifizierung) mit einem Anbietermodell. Hier können Anbieter/Kunden einen eigenen Adapter für die mehrstufige Authentifizierung erstellen, den ein Administrator registrieren und bei der Anmeldung verwenden kann.
Jeder MFA-Adapter muss auf .NET 4.5 aufsetzen.
Weitere Informationen zu MFA finden Sie unter Manage Risk with Additional Multi-Factor Authentication for Sensitive Applications.
Geräteauthentifizierung
AD FS unterstützt die Geräteauthentifizierung mit Zertifikaten, die vom Geräteregistrierungsdienst bereitgestellt werden, wenn das Gerät eines Endbenutzers einem Arbeitsplatz beitritt.
Anforderungen für Workplace Join
Die Geräte von Endbenutzern können mit AD FS dem Arbeitsplatz eines Unternehmens beitreten. Diese Funktion wird vom Geräteregistrierungsdienst von AD FS unterstützt. Endbenutzer profitieren hiermit bei allen Anwendungen, die von AD FS unterstützt werden, zusätzlich von SSO. Darüber hinaus können Administratoren zur Risikominderung den Zugriff auf Anwendungen auf Geräte beschränken, die dem Arbeitsplatz des Unternehmens beigetreten sind. Nachfolgend finden Sie die Voraussetzungen für dieses Szenario.
AD FS unterstützt Workplace Join für Geräte mit Windows 8.1 und iOS 5+.
Damit Sie die Workplace Join-Funktion nutzen können, muss die Gesamtstruktur, der AD FS-Server beigetreten sind, Windows Server 2012 R2 sein.
Der alternative Antragstellername des SSL-Zertifikats für den AD FS-Dienst muss den Wert „enterpriseregistration“ enthalten, gefolgt vom Benutzerprinzipalnamen-Suffix Ihres Unternehmens, z. B. enterpriseregistration.corp.contoso.com.
Kryptografie-Anforderungen
Die folgende Tabelle enthält zusätzliche Informationen zur Kryptografie-Unterstützung bei der AD FS-Funktion für die Tokensignatur und Tokenverschlüsselung/-entschlüsselung:
| Algorithmus | Schlüssellängen | Protokolle/Anwendungen/Kommentare |
|---|---|---|
| TripleDES – Standard 192 (unterstützt 192–256) – http://www.w3.org/2001/04/xmlenc#tripledes-cbc | >= 192 | Unterstützter Algorithmus für die Entschlüsselung des Sicherheitstokens. Die Verschlüsselung des Sicherheitstokens mit diesem Algorithmus wird nicht unterstützt. |
| AES128 – http://www.w3.org/2001/04/xmlenc#aes128-cbc | 128 | Unterstützter Algorithmus für die Entschlüsselung des Sicherheitstokens. Die Verschlüsselung des Sicherheitstokens mit diesem Algorithmus wird nicht unterstützt. |
| AES192 – http://www.w3.org/2001/04/xmlenc#aes192-cbc | 192 | Unterstützter Algorithmus für die Entschlüsselung des Sicherheitstokens. Die Verschlüsselung des Sicherheitstokens mit diesem Algorithmus wird nicht unterstützt. |
| AES256 – http://www.w3.org/2001/04/xmlenc#aes256-cbc | 256 | Default. Unterstützter Algorithmus für die Verschlüsselung des Sicherheitstokens. |
| TripleDESKeyWrap – http://www.w3.org/2001/04/xmlenc#kw-tripledes | Alle von .NET 4.0+ unterstützten Schlüsselgrößen | Unterstützter Algorithmus für die Verschlüsselung des symmetrischen Schlüssels, der ein Sicherheitstoken verschlüsselt. |
| AES128KeyWrap – http://www.w3.org/2001/04/xmlenc#kw-aes128 | 128 | Unterstützter Algorithmus für die Verschlüsselung des symmetrischen Schlüssels, der das Sicherheitstoken verschlüsselt |
| AES192KeyWrap – http://www.w3.org/2001/04/xmlenc#kw-aes192 | 192 | Unterstützter Algorithmus für die Verschlüsselung des symmetrischen Schlüssels, der das Sicherheitstoken verschlüsselt |
| AES256KeyWrap – http://www.w3.org/2001/04/xmlenc#kw-aes256 | 256 | Unterstützter Algorithmus für die Verschlüsselung des symmetrischen Schlüssels, der das Sicherheitstoken verschlüsselt |
| RsaV15KeyWrap – http://www.w3.org/2001/04/xmlenc#rsa-1_5 | 1024 | Unterstützter Algorithmus für die Verschlüsselung des symmetrischen Schlüssels, der das Sicherheitstoken verschlüsselt |
| RsaOaepKeyWrap – http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p | 1024 | Standard. Unterstützter Algorithmus für die Verschlüsselung des symmetrischen Schlüssels, der das Sicherheitstoken verschlüsselt |
| SHA1-http://www.w3.org/PICS/DSig/SHA1_1_0.html | – | Wird vom AD FS-Server bei der SourceId-Artefakterzeugung verwendet: In diesem Szenario erstellt der STS mit SHA1 (gemäß der Empfehlung nach SAML 2.0-Standard) einen kurzen 160-Bit-Wert für die SourceId des Artefakts. Wird auch vom AD FS-Web-Agent (eine ältere Komponenten des WS2003-Zeitrahmens) genutzt, um Änderungen beim Zeitwert „Letzte Aktualisierung“ zu identifizieren und so zu wissen, wann Informationen vom STS aktualisiert werden müssen. |
| SHA1withRSA- | – | Wird verwendet, wenn der AD FS-Server die Signatur der SAML-Authentifizierungsanforderung überprüft, die Artefaktauflösungsanforderung oder -antwort signiert oder das Zertifikat für die Tokensignatur erstellt. In diesen Fällen ist SHA256 der Standard und SHA1 wird nur verwendet, wenn der Partner (vertrauende Seite) SHA256 nicht unterstützen kann und SHA1 verwenden muss. |
Berechtigungsanforderungen
Der Administrator, der die Installation und die Erstkonfiguration von AD FS vornimmt, benötigt Domänen-Administratorrechte in der lokalen Domäne (also der Domäne, der der Verbundserver beigetreten ist).