Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Im Folgenden sind die verschiedenen Anforderungen aufgeführt, die Sie beim Bereitstellen von AD FS erfüllen müssen:
Berechtigungsanforderungen
Zertifikatanforderungen
Zertifikate spielen die wichtigste Rolle beim Sichern der Kommunikation zwischen Verbundservern, Webanwendungsproxys, Anspruchsfähigen Anwendungen und Webclients. Die Anforderungen für Zertifikate variieren je nachdem, ob Sie einen Verbundserver oder einen Proxycomputer einrichten, wie in diesem Abschnitt beschrieben.
Verbundserverzertifikate
| Zertifikattyp | Anforderungen, Support & Wissenswertes |
|---|---|
| SSL-Zertifikat (Secure Sockets Layer): Dies ist ein standardmäßiges SSL-Zertifikat, das zum Sichern der Kommunikation zwischen Verbundservern und Clients verwendet wird. | – Dieses Zertifikat muss ein öffentlich vertrauenswürdiges* X509 v3-Zertifikat sein. – Alle Clients, die auf einen AD FS-Endpunkt zugreifen, müssen diesem Zertifikat vertrauen. Es wird dringend empfohlen, Zertifikate zu verwenden, die von einer öffentlichen Zertifizierungsstelle ausgestellt werden. Sie können ein selbstsigniertes SSL-Zertifikat erfolgreich auf Verbundservern in einer Testumgebung verwenden. Für eine Produktionsumgebung empfehlen wir jedoch, das Zertifikat von einer öffentlichen Zertifizierungsstelle zu erhalten. – 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. – Wildcardzertifikate werden unterstützt. Wenn Sie Ihre AD FS-Farm erstellen, werden Sie aufgefordert, den Dienstnamen für den AD FS-Dienst bereitzustellen (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 Betreffname dieses Zertifikats wird verwendet, um den Verbunddienstnamen für jede Instanz von AD FS darzustellen, die Sie bereitstellen. Aus diesem Grund sollten Sie einen Betreffnamen für alle von der Zertifizierungsstelle ausgestellten neuen Zertifikate auswählen, der den Namen Ihres Unternehmens oder Ihrer Organisation am besten für Partner 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 Ihrer AD FS-Farm sowie alle Webanwendungsproxys in Ihrer AD FS-Farm zu verwenden. |
| Dienstkommunikationszertifikat: Dieses Zertifikat ermöglicht wcf-Nachrichtensicherheit zum Sichern der Kommunikation zwischen Verbundservern. | - Standardmäßig wird das SSL-Zertifikat als Dienstkommunikationszertifikat verwendet. Sie haben aber auch die Möglichkeit, ein anderes Zertifikat als Dienstkommunikationszertifikat zu konfigurieren. - Wichtig: Wenn Sie das SSL-Zertifikat als Dienstkommunikationszertifikat verwenden, müssen Sie beim Ablauf des SSL-Zertifikats das erneuerte SSL-Zertifikat als Dienstkommunikationszertifikat konfigurieren. Dies geschieht nicht automatisch. – Dieses Zertifikat muss von Clients von AD FS vertrauenswürdig sein, die WCF-Nachrichtensicherheit verwenden. – Es wird empfohlen, ein Serverauthentifizierungszertifikat zu verwenden, das von einer öffentlichen Zertifizierungsstelle (Drittanbieterzertifizierungsstelle) ausgestellt wird. – Das Dienstkommunikationszertifikat kann kein Zertifikat sein, das CNG-Schlüssel verwendet. – Dieses Zertifikat kann mithilfe der AD FS-Verwaltungskonsole verwaltet werden. |
| Tokensignaturzertifikat: Dies ist ein standardmäßiges X509-Zertifikat, das zum sicheren Signieren aller Token verwendet wird, die der Verbundserver ausgibt. | – Ad FS erstellt standardmäßig ein selbstsigniertes Zertifikat mit 2048-Bitschlüsseln. – Von der Zertifizierungsstelle ausgestellte Zertifikate werden ebenfalls unterstützt und können mithilfe des AD FS-Verwaltungs-Snap-Ins geändert werden. - Von der Zertifizierungsstelle ausgestellte Zertifikate müssen gespeichert werden und über einen CSP Crypto Provider darauf zugegriffen werden. – Das Tokensignaturzertifikat kann kein Zertifikat sein, das CNG-Schlüssel verwendet. – AD FS erfordert keine extern registrierten Zertifikate für die Tokensignierung. AD FS erneuert diese selbstsignierten Zertifikate automatisch, bevor sie ablaufen. Konfigurieren Sie zuerst die neuen Zertifikate als sekundäre Zertifikate, damit Partner sie nutzen können, und wechseln Sie dann in einen Prozess, der als automatisches Zertifikatrollover bezeichnet wird, in den Primären um. Es wird empfohlen, die standardmäßigen, automatisch generierten Zertifikate für die Tokensignierung zu verwenden. Wenn Ihre Organisation Richtlinien enthält, für die unterschiedliche Zertifikate für die Tokensignierung konfiguriert werden müssen, können Sie die Zertifikate zur Installationszeit mithilfe von PowerShell angeben (verwenden Sie den Parameter "–SigningCertificateThumbprint" des Cmdlets Install-AdfsFarm). Nach der Installation können Sie Tokensignaturzertifikate mithilfe der AD FS-Verwaltungskonsole oder PowerShell-Cmdlets Set-AdfsCertificate und Get-AdfsCertificate anzeigen und verwalten. Wenn extern registrierte Zertifikate für die Tokensignierung verwendet werden, führt AD FS keine automatische Zertifikatverlängerung oder einen Rollover durch. Dieser Vorgang muss von einem Administrator ausgeführt werden. Um einen Zertifikatswechsel zu ermöglichen, wenn ein Zertifikat kurz vor dem Ablauf steht, kann ein sekundäres Tokensignaturzertifikat in AD FS konfiguriert werden. Standardmäßig werden alle Tokensignaturzertifikate in Verbundmetadaten veröffentlicht, aber nur das primäre Tokensignaturzertifikat wird von AD FS verwendet, um Token tatsächlich zu signieren. |
| Tokenentschlüsselungs-/Verschlüsselungszertifikat: Dies ist ein standardmäßiges X509-Zertifikat, das zum Entschlüsseln/Verschlüsseln eingehender Token verwendet wird. Sie wird auch in Verbundmetadaten veröffentlicht. | – Ad FS erstellt standardmäßig ein selbstsigniertes Zertifikat mit 2048-Bitschlüsseln. – Von der Zertifizierungsstelle ausgestellte Zertifikate werden ebenfalls unterstützt und können mithilfe des AD FS-Verwaltungs-Snap-Ins geändert werden. - Von der Zertifizierungsstelle ausgestellte Zertifikate müssen gespeichert und über einen CSP-Crypto-Provider abgerufen werden. – Das Tokenentschlüsselungs-/Verschlüsselungszertifikat kann kein Zertifikat sein, das CNG-Schlüssel verwendet. - Standardmäßig generiert und verwendet AD FS eigene, intern generierte und selbstsignierte Zertifikate für die Tokenentschlüsselung. AD FS erfordert für diesen Zweck keine extern registrierten Zertifikate. Darüber hinaus erneuert AD FS diese selbstsignierten Zertifikate automatisch, bevor sie ablaufen. Es wird empfohlen, die standardmäßigen, automatisch generierten Zertifikate für die Tokenentschlüsselung zu verwenden. Wenn Ihre Organisation Richtlinien enthält, für die unterschiedliche Zertifikate für die Tokenentschlüsselung konfiguriert werden müssen, können Sie die Zertifikate zur Installationszeit mithilfe von PowerShell angeben (verwenden Sie den Parameter "–DecryptionCertificateThumbprint" des Cmdlets Install-AdfsFarm). Nach der Installation können Sie Tokenentschlüsselungszertifikate mithilfe der AD FS-Verwaltungskonsole oder PowerShell-Cmdlets Set-AdfsCertificate und Get-AdfsCertificate anzeigen und verwalten. Wenn extern registrierte Zertifikate für die Tokenentschlüsselung verwendet werden, führt AD FS keine automatische Zertifikatverlängerung durch. Dieser Prozess muss von einem Administrator ausgeführt werden.. – Das AD FS-Dienstkonto muss Zugriff auf den privaten Schlüssel des Tokensignaturzertifikats im persönlichen Speicher des lokalen Computers haben. Dies wird von Setup erledigt. Sie können auch das AD FS-Verwaltungs-Snap-In verwenden, um diesen Zugriff sicherzustellen, wenn Sie anschließend das Tokensignaturzertifikat ändern. |
Vorsicht
Zertifikate, die für die Tokensignierung und die Verschlüsselung von Token verwendet werden, sind für die Stabilität des Verbunddiensts von entscheidender Bedeutung. Kunden, die ihre eigenen Zertifikate zur Tokensignierung und Tokenentschlüsselung/-verschlüsselung verwalten, sollten sicherstellen, dass diese Zertifikate gesichert und während eines Wiederherstellungsvorgangs unabhängig verfügbar sind.
Hinweis
In AD FS können Sie die Sha-Ebene (Secure Hash Algorithm) ändern, die für digitale Signaturen verwendet wird, entweder in SHA-1 oder SHA-256 (sicherer). AD FS unterstützt die Verwendung von Zertifikaten mit anderen Hashmethoden wie MD5 nicht (der Standardhashalgorithmus, der mit dem Befehlszeilentool Makecert.exe verwendet wird). Als bewährte Methode für die Sicherheit wird empfohlen, SHA-256 (standardmäßig festgelegt) für alle Signaturen zu verwenden. SHA-1 wird nur für Szenarien empfohlen, in denen Sie mit einem Produkt zusammenarbeiten müssen, das keine Kommunikation mithilfe von SHA-256 unterstützt, z. B. ein Nicht-Microsoft-Produkt oder ältere 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 des lokalen Computers importiert werden. Mit dem MMC-Snap-In "Zertifikate" können Sie Zertifikate in den persönlichen Speicher importieren.
Hardwareanforderungen
Die folgenden Mindest- und empfohlenen Hardwareanforderungen gelten für die AD FS-Verbundserver in Windows Server 2012 R2:
| Hardwareanforderungen | Mindestanforderung | Empfohlene Anforderung |
|---|---|---|
| CPU-Geschwindigkeit | 1,4 GHz 64-Bit-Prozessor | Quad-core, 2 GHz |
| RAM | 512 MB | 4GB |
| 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 müssen Sie den Webanwendungsproxy-Rollendienst bereitstellen – Teil der Windows Server® 2012 R2-Remotezugriffsserverrolle. Frühere Versionen eines Verbundserverproxys werden mit AD FS in Windows Server® 2012 R2 nicht unterstützt.
Ein Verbundserver und der Webanwendungsproxy-Rollendienst können nicht auf demselben Computer installiert werden.
AD DS-Anforderungen
Domänencontrolleranforderungen
Domänencontroller in allen Benutzerdomänen und der Domäne, mit der die AD FS-Server verbunden sind, müssen Windows Server 2008 oder höher ausführen.
Hinweis
Alle Unterstützung für Umgebungen mit Windows Server 2003-Domänencontrollern endet nach dem Enddatum des erweiterten Supports für Windows Server 2003. Kunden werden dringend empfohlen, ihre Domänencontroller so schnell wie möglich zu aktualisieren. Weitere Informationen zum Microsoft Support Lifecycle finden Sie auf dieser Seite . Bei Problemen, die für Windows Server 2003-Domänencontrollerumgebungen spezifisch sind, werden Korrekturen nur für Sicherheitsprobleme ausgegeben, und wenn ein Fix vor Ablauf des erweiterten Supports für Windows Server 2003 ausgestellt werden kann.
Hinweis
AD FS erfordert, dass ein vollständiger schreibbarer Domänencontroller im Gegensatz zu einem Read-Only Domänencontroller funktioniert. Wenn eine geplante Topologie einen Read-Only Domänencontroller enthält, kann der Read-Only Domänencontroller für die Authentifizierung verwendet werden, die LDAP-Anspruchsverarbeitung erfordert jedoch eine Verbindung mit dem schreibbaren Domänencontroller.
Anforderungen auf Domänenfunktionsebene
Alle Benutzerkontodomänen und die Domäne, zu der die AD FS-Server beigetreten sind, müssen auf der Domänenfunktionsebene von Windows Server 2003 oder höher ausgeführt werden.
Die meisten AD FS-Features erfordern keine Änderungen auf AD DS-Funktionsebene, um erfolgreich zu arbeiten. Windows Server 2008-Domänenfunktionsebene oder höher ist jedoch erforderlich, damit die Clientzertifikatauthentifizierung erfolgreich ausgeführt wird, wenn das Zertifikat explizit dem Konto eines Benutzers in AD DS zugeordnet ist.
Schemaanforderungen
AD FS erfordert keine Schemaänderungen oder Änderungen auf funktionaler Ebene 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.
Dienstkontoanforderungen
Jedes Standarddienstkonto kann als Dienstkonto für AD FS verwendet werden. Gruppenverwaltete Dienstkonten werden ebenfalls unterstützt. Dies erfordert mindestens einen Domänencontroller (es wird empfohlen, zwei oder mehr bereitzustellen), die Windows Server 2012 oder höher ausführen.
Damit die Kerberos-Authentifizierung zwischen in die Domäne eingebundenen Clients und AD FS funktioniert, muss der "HOST/<adfs_service_name>" als SPN für das Dienstkonto registriert werden. Standardmäßig konfiguriert AD FS dies beim Erstellen einer neuen AD FS-Farm, wenn sie über ausreichende Berechtigungen zum Ausführen dieses Vorgangs verfügt.
Das AD FS-Dienstkonto muss in jeder Benutzerdomäne vertrauenswürdig sein, die Benutzer enthält, die sich für den AD FS-Dienst authentifizieren.
Domänenanforderungen
Alle AD FS-Server müssen einer AD DS-Domäne beigetreten sein.
Alle AD FS-Server innerhalb einer Farm müssen in einer einzigen Domäne bereitgestellt werden.
Die Domäne, zu der die AD FS-Server beigetreten sind, muss jeder Benutzerkontodomäne vertrauen, die Benutzer enthält, die sich gegenüber dem 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 für den AD FS-Dienst authentifizieren.
Anforderungen an die Konfigurationsdatenbank
Im Folgenden sind die Anforderungen und Einschränkungen aufgeführt, die basierend auf dem Konfigurationsspeichertyp gelten:
WID
Eine WID-Farm hat einen Grenzwert von 30 Verbundservern, wenn Sie 100 oder weniger Vertrauensebenen haben.
Das Artefaktauflösungsprofil in SAML 2.0 wird in der WID-Konfigurationsdatenbank nicht unterstützt. Die Erkennung von Token replay 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 verwendet.
Die Bereitstellung von AD FS-Servern in unterschiedlichen Rechenzentren für Failover oder geografischen Lastenausgleich wird unterstützt, solange die Anzahl der Server 30 nicht überschreitet.
Die folgende Tabelle enthält eine Zusammenfassung für die Verwendung einer WID-Farm. Verwenden Sie sie, um Ihre Implementierung zu planen.
| 1–100 Vertrauensstellungen der vertrauenden Seite (RP) | Mehr als 100 RP-Stiftungen |
|---|---|
| 1–30 AD FS-Knoten: Von WID unterstützt | 1-30 AD FS-Knoten: Nicht unterstützt bei Verwendung von WID – 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
Für AD FS in Windows Server 2012 R2 können Sie SQL Server 2008 und höher verwenden.
Browseranforderungen
Wenn die AD FS-Authentifizierung über ein Browser- oder Browsersteuerelement ausgeführt wird, muss Ihr Browser die folgenden Anforderungen erfüllen:
JavaScript muss aktiviert sein
Cookies müssen aktiviert sein
Servernamensanzeige (Server Name Indication, SNI) muss unterstützt werden
Für die Benutzerzertifikat- und Gerätezertifikatauthentifizierung (Arbeitsplatzbeitrittsfunktion) muss der Browser die SSL-Clientzertifikatauthentifizierung unterstützen.
Mehrere wichtige Browser und Plattformen haben eine Überprüfung für rendering und Funktionalität durchlaufen, deren Details unten aufgeführt sind. Browser und Geräte, die in dieser Tabelle nicht behandelt werden, werden weiterhin unterstützt, wenn sie die oben aufgeführten 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 Web Authentication Broker | 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: Workplace Join-Funktion, die das Gerät mithilfe des Gerätezertifikats identifiziert, ist auf Windows-Plattformen nicht funktionsfähig. Firefox unterstützt derzeit nicht die Durchführung der SSL-Clientzertifikatauthentifizierung mithilfe von Zertifikaten, die für den Benutzerzertifikatspeicher auf Windows-Clients bereitgestellt werden.
Cookies
AD FS erstellt sitzungsbasierte und persistente Cookies, die auf Clientcomputern gespeichert werden müssen, um Anmeldung, Abmelden, Einmaliges Anmelden (Single Sign-On, SSO) und andere Funktionen bereitzustellen. Daher muss der Clientbrowser so konfiguriert werden, dass Cookies akzeptiert werden. Cookies, die für die Authentifizierung verwendet werden, sind immer HTTPS-Sitzungscookies (Secure Hypertext Transfer Protocol), die für den ursprünglichen Server geschrieben sind. Wenn der Clientbrowser nicht so konfiguriert ist, dass diese Cookies zugelassen werden, kann AD FS nicht ordnungsgemäß funktionieren. Persistente Cookies werden verwendet, um die Benutzerauswahl des Anspruchsanbieters beizubehalten. Sie können sie mithilfe einer Konfigurationseinstellung in der Konfigurationsdatei für die AD FS-Anmeldeseiten deaktivieren. Die Unterstützung für TLS/SSL ist aus Sicherheitsgründen erforderlich.
Extranetanforderungen
Um Extranetzugriff auf den AD FS-Dienst bereitzustellen, müssen Sie den Webanwendungsproxy-Rolldienst als extranetseitige Rolle bereitstellen, die Authentifizierungsanforderungen auf sichere Weise an den AD FS-Dienst weiterleitet. Dadurch werden die AD FS-Dienstendpunkte sowie alle Sicherheitsschlüssel (z. B. Tokensignaturzertifikate) von Anforderungen isoliert, die aus dem Internet stammen. Darüber hinaus erfordern Features wie die Sperrung von Soft Extranet-Konten die Verwendung des Webanwendungsproxys. Weitere Informationen zum Webanwendungsproxy finden Sie unter Webanwendungsproxy. `
Netzwerkanforderungen
Die geeignete Konfiguration der folgenden Netzwerkdienste ist für die erfolgreiche Bereitstellung von AD FS in Ihrer Organisation von entscheidender Bedeutung:
Konfigurieren 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 eingehend aktiviert haben.
Zusätzlich muss, wenn die Clientbenutzerzertifikatauthentifizierung (ClientTLS-Authentifizierung mit X509-Benutzerzertifikaten) erforderlich ist, in AD FS auf Windows Server 2012 R2 der TCP-Port 49443 eingehend auf der Firewall zwischen den Clients und dem Webanwendungsproxy aktiviert werden. Dies ist für die Firewall zwischen dem Webanwendungsproxy und den Verbundservern nicht erforderlich.
Hinweis
Stellen Sie außerdem sicher, dass Port 49443 nicht von anderen Diensten auf dem AD FS- und Webanwendungsproxyserver verwendet wird.
Konfigurieren von DNS
Für den Zugriff auf das Intranet müssen alle Clients im internen Unternehmensnetzwerk (Intranet), die den AD FS-Dienst nutzen, in der Lage sein, den AD FS-Dienstnamen (wie im SSL-Zertifikat angegeben) auf den Load Balancer für die AD FS-Server oder direkt auf den AD FS-Server aufzulösen.
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. Dies kann mithilfe eines alternativen DNS-Servers im DMZ-Netzwerk oder durch Ändern der lokalen Serverauflösung mithilfe der HOSTS-Datei erreicht werden.
Damit die integrierte Windows-Authentifizierung innerhalb des Netzwerks und außerhalb des Netzwerks für eine Teilmenge von Endpunkten funktioniert, die über den Webanwendungsproxy verfügbar gemacht werden, müssen Sie einen A-Eintrag (nicht CNAME) verwenden, um auf die Lastenausgleichsgeräte zu verweisen.
Informationen zum Konfigurieren des Unternehmens-DNS für den Verbunddienst und den Geräteregistrierungsdienst finden Sie unter Configure Corporate DNS for the Federation Service and DRS.
Informationen zum Konfigurieren von Unternehmens-DNS für Webanwendungsproxys finden Sie im Abschnitt "Konfigurieren von DNS" in Schritt 1: Konfigurieren der Webanwendungsproxyinfrastruktur.
Informationen zum Konfigurieren einer Cluster-IP-Adresse oder eines Cluster-FQDN mithilfe von NLB finden Sie unter Angeben der Clusterparameter unter http://go.microsoft.com/fwlink/?LinkId=75282.
Attributspeicheranforderungen
AD FS erfordert mindestens einen Attributspeicher für die Authentifizierung von Benutzern und das Extrahieren von Sicherheitsansprüchen für diese Benutzer. Eine Liste von Attributspeichern, die AD FS unterstützt, finden Sie unter "Rolle von Attributspeichern".
Hinweis
AD FS erstellt standardmäßig automatisch einen "Active Directory"-Attributspeicher. Die Anforderungen des Attributspeichers hängen davon ab, ob Ihre Organisation als Kontopartner (hostet die Partnerbenutzer) oder den Ressourcenpartner (hostet die Verbundanwendung) fungiert.
LDAP-Attributspeicher
Wenn Sie mit anderen LDAP-basierten Attributspeichern (Lightweight Directory Access Protocol) arbeiten, müssen Sie eine Verbindung mit einem LDAP-Server herstellen, der die integrierte Windows-Authentifizierung unterstützt. Die LDAP-Verbindungszeichenfolge muss auch im Format einer LDAP-URL geschrieben werden, wie in RFC 2255 beschrieben.
Es ist auch erforderlich, dass das Dienstkonto für den AD FS-Dienst das Recht hat, Benutzerinformationen im LDAP-Attributspeicher abzurufen.
SQL Server-Attributspeicher
Damit AD FS in Windows Server 2012 R2 erfolgreich ausgeführt werden kann, müssen Computer, die den SQL Server-Attributspeicher hosten, entweder Microsoft SQL Server 2008 oder höher ausführen. Wenn Sie mit SQL-basierten Attributspeichern arbeiten, müssen Sie auch eine Verbindungszeichenfolge konfigurieren.
Benutzerdefinierte Attributspeicher
Sie können benutzerdefinierte Attributspeicher entwickeln, um erweiterte Szenarien zu ermöglichen.
Die in AD FS integrierte Richtliniensprache kann auf benutzerdefinierte Attributspeicher verweisen, damit eines 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 Tokens
Autorisieren eines Diensts zum Abrufen eines Token zum Verhalten eines Benutzers
Ausstellen zusätzlicher Daten in Sicherheitstoken, die von AD FS an vertrauende Parteien ausgestellt wurden.
Alle benutzerdefinierten Attributspeicher müssen auf .NET 4.0 oder höher basieren.
Wenn Sie mit einem benutzerdefinierten Attributspeicher arbeiten, müssen Sie möglicherweise auch eine Verbindungszeichenfolge konfigurieren. In diesem Fall können Sie einen benutzerdefinierten Code Ihrer Wahl eingeben, der eine Verbindung mit Ihrem benutzerdefinierten Attributspeicher ermöglicht. Die Verbindungszeichenfolge in dieser Situation ist eine Reihe von Namen-Wert-Paaren, die vom Entwickler des benutzerdefinierten Attributspeichers interpretiert werden. Weitere Informationen zum Entwickeln und Verwenden von benutzerdefinierten Attributspeichern finden Sie unter "Übersicht über den 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 IDPLite-, SPLite & eGov1.5-Profilen.
OAuth 2.0-Autorisierungserteilungsprofil
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 Standardauthentifizierungsmechanismen für AD DS unterstützt:
Integrierte Windows-Authentifizierung mit Negotiate für Kerberos für Kerberos und NTLM
Formularauthentifizierung mit Benutzername/Kennwörtern
Zertifikatauthentifizierung mithilfe von Zertifikaten, die Benutzerkonten in AD DS zugeordnet sind
Für den Extranetzugriff werden die folgenden Authentifizierungsmechanismen unterstützt:
Formularauthentifizierung mit Benutzername/Kennwörtern
Zertifikatauthentifizierung mithilfe von Zertifikaten, die Benutzerkonten in AD DS zugeordnet sind
Integrierte Windows-Authentifizierung mit Negotiate (nur NTLM) für WS-Trust-Endpunkte, die eine integrierte Windows-Authentifizierung akzeptieren.
Für die Zertifikatauthentifizierung:
Erweitert sich auf Smartcards, die mit einer PIN geschützt werden können.
Die GUI für den Benutzer, um seinen Pin einzugeben, wird von AD FS nicht bereitgestellt und muss Teil des Clientbetriebssystems sein, das bei Verwendung von Client-TLS angezeigt wird.
Der Reader und der kryptografische Dienstanbieter (CSP) für die Smartcard müssen auf dem Computer funktionieren, 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 werden:
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.
Für eine nahtlose integrierte Windows-Authentifizierung mit Kerberos im Intranet
Es ist erforderlich, dass der Dienstname Teil der vertrauenswürdigen Websites oder der lokalen Intranetwebsites sein soll.
Darüber hinaus muss der HOST/<adfs_service_name> SPN für das Dienstkonto festgelegt werden, auf dem die AD FS-Farm ausgeführt wird.
Mehrfaktor-Authentifizierung
AD FS unterstützt zusätzliche Authentifizierung (über die primäre Authentifizierung hinaus, die von AD DS unterstützt wird) mithilfe eines Anbietermodells, bei dem Anbieter/Kunden ihren eigenen mehrstufigen Authentifizierungsadapter erstellen können, den ein Administrator während der Anmeldung registrieren und verwenden kann.
Jeder MFA-Adapter muss auf .NET 4.5 basieren.
Weitere Informationen zu MFA finden Sie unter "Verwalten von Risiken mit zusätzlicher mehrstufiger Authentifizierung für vertrauliche Anwendungen".
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. Dies wird vom Geräteregistrierungsdienst in AD FS unterstützt. Daher erhalten Endbenutzer den zusätzlichen Vorteil von SSO in allen Anwendungen, die von AD FS unterstützt werden. 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 sind die folgenden Anforderungen aufgeführt, um dieses Szenario zu aktivieren.
AD FS unterstützt Workplace-Join für Windows 8.1- und iOS 5 oder höher-Geräte.
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.
Kryptografieanforderungen
Die folgende Tabelle enthält zusätzliche Kryptografieunterstützungsinformationen zur AD FS-Tokensignierung, Tokenverschlüsselungs-/Entschlüsselungsfunktion:
| 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 zum Entschlüsseln des Sicherheitstokens. Das Verschlüsseln des Sicherheitstokens mit diesem Algorithmus wird nicht unterstützt. |
| AES128 - http://www.w3.org/2001/04/xmlenc#aes128-cbc | 128 | Unterstützter Algorithmus zum Entschlüsseln des Sicherheitstokens. Das Verschlüsseln des Sicherheitstokens mit diesem Algorithmus wird nicht unterstützt. |
| AES192 - http://www.w3.org/2001/04/xmlenc#aes192-cbc | 192 | Unterstützter Algorithmus zum Entschlüsseln des Sicherheitstokens. Das Verschlüsseln des Sicherheitstokens mit diesem Algorithmus wird nicht unterstützt. |
| AES256 - http://www.w3.org/2001/04/xmlenc#aes256-cbc | 256 | Standard. Unterstützter Algorithmus zum Verschlüsseln 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 zum Verschlüsseln des symmetrischen Schlüssels, der ein Sicherheitstoken verschlüsselt. |
| AES128KeyWrap – http://www.w3.org/2001/04/xmlenc#kw-aes128 | 128 | Unterstützter Algorithmus zum Verschlüsseln des symmetrischen Schlüssels, der das Sicherheitstoken verschlüsselt. |
| AES192KeyWrap – http://www.w3.org/2001/04/xmlenc#kw-aes192 | 192 | Unterstützter Algorithmus zum Verschlüsseln des symmetrischen Schlüssels, der das Sicherheitstoken verschlüsselt. |
| AES256KeyWrap – http://www.w3.org/2001/04/xmlenc#kw-aes256 | 256 | Unterstützter Algorithmus zum Verschlüsseln des symmetrischen Schlüssels, der das Sicherheitstoken verschlüsselt. |
| RsaV15KeyWrap – http://www.w3.org/2001/04/xmlenc#rsa-1_5 | 1024 | Unterstützter Algorithmus zum Verschlüsseln 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 zum Verschlüsseln des symmetrischen Schlüssels, der das Sicherheitstoken verschlüsselt. |
| SHA1-http://www.w3.org/PICS/DSig/SHA1_1_0.html | Nicht verfügbar | Wird vom AD FS-Server bei der Artefaktquell-ID-Erstellung verwendet: In diesem Szenario verwendet der STS SHA1 (gemäß der Empfehlung im SAML 2.0-Standard), um einen kurzen 160-Bit-Wert für die Artefaktquell-ID zu erstellen. Wird auch vom AD FS-Web-Agent (Legacykomponente aus WS2003-Zeitrahmen) verwendet, um Änderungen in einem "letzten aktualisierten" Zeitwert zu identifizieren, damit er weiß, wann Informationen aus dem STS aktualisiert werden sollen. |
| SHA1withRSA- | Nicht verfügbar | Wird in Fällen verwendet, in denen AD FS-Server die Signatur von SAML AuthenticationRequest überprüft, die Artefaktauflösungsanforderung oder -antwort signiert, Tokensignaturzertifikate erstellen. In diesen Fällen ist SHA256 der Standardwert, 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 durchführt, und die anfängliche Konfiguration von AD FS muss über Domänenadministratorberechtigungen in der lokalen Domäne verfügen (d. h. die Domäne, zu der der Verbundserver verbunden ist.)