Configuration requise pour AD FS dans Windows Server
Voici les différentes exigences auxquelles vous devez vous conformer lors du déploiement d’AD FS :
Configuration requise des certificats
Les certificats jouent le rôle le plus important dans la sécurisation des communications entre les serveurs de fédération, les proxys d’application web, les applications prenant en charge les revendications et les clients web. La configuration requise pour les certificats varie selon que vous configurez un serveur de fédération ou un ordinateur proxy, comme décrit dans cette section.
Certificats des serveurs de fédération
| Type de certificat | Conditions requises, support et informations à savoir |
|---|---|
| Certificat SSL (Secure Sockets Layer) : Un certificat SSL (Secure Sockets Layer) standard qui permet de sécuriser les communications entre les serveurs de fédération et les clients. | - Le certificat doit être un certificat X509 v3 approuvé* publiquement. - Tous les clients qui accèdent à un point de terminaison AD FS doivent approuver ce certificat. Il est fortement recommandé d’utiliser des certificats émis par une autorité de certification publique (tierce). Vous pouvez utiliser un certificat SSL auto-signé avec succès sur les serveurs de fédération dans un environnement de laboratoire de test. Toutefois, pour un environnement de production, nous vous recommandons d'obtenir le certificat auprès d'une autorité de certification publique. - Prise en charge de toutes les tailles de clé prises en charge par Windows Server 2012 R2 pour les certificats SSL. - Ne prend pas en charge des certificats qui utilisent des clés CNG. - Lorsqu’il est utilisé conjointement avec le service de jonction d’espace de travail/d’inscription d’appareil, l’autre nom d’objet du certificat SSL pour le service AD FS doit contenir la valeur inscriptionentreprise qui est suivie du suffixe Nom d’utilisateur principal (UPN) de votre organisation, par exemple, inscriptionentreprise.contoso.com. - Les certificats utilisant des caractères génériques sont pris en charge. Lorsque vous créez votre batterie de serveurs AD FS, vous êtes invité à fournir le nom du service AD FS (par exemple, adfs.contoso.com. - Il est fortement recommandé d’utiliser le même certificat SSL pour le Proxy d’application Web. Toutefois, il doit être identique lors de la prise en charge des points de terminaison d’authentification intégrée Windows via le Proxy d’application web et lorsque l’authentification de protection étendue est activée (paramètre par défaut). - Le nom de sujet de ce certificat permet de représenter le nom du service de fédération pour chaque instance d’AD FS que vous déployez. Vous pouvez donc choisir pour tout nouveau certificat émis par une autorité de certification un nom de sujet qui reflète le nom de votre entreprise ou organisation auprès des partenaires. L’identité du certificat doit correspondre au nom du service de fédération (par exemple, fs.contoso.com). L’identité est soit une extension de nom de remplacement de l’objet de type DnsName, soit, s’il n’existe aucune entrée de nom de l’objet, le nom de l’objet spécifié comme nom commun. Le certificat peut contenir plusieurs entrées d’autre nom de l’objet, pour autant que l’une d’elles corresponde au nom des services de fédération. - Important : il est fortement recommandé d’utiliser le même certificat SSL sur tous les nœuds de votre batterie de serveurs AD FS, ainsi que sur tous les proxys d’application de votre batterie AD FS. |
| Certificat de communication du service : Ce certificat active la sécurité de message WCF pour sécuriser les communications entre les serveurs de fédération. | - Par défaut, le certificat SSL est utilisé en tant que certificat de communication du service. Mais vous avez également la possibilité de configurer un autre certificat en tant que certificat de communication de service. - Important : si vous utilisez le certificat SSL comme certificat de communication de service, lorsque le certificat SSL expire, veillez à configurer le certificat SSL renouvelé en tant que certificat de communication de service. Cela ne se produit pas automatiquement. - Ce certificat doit être approuvé par les clients d’AD FS qui utilisent WCF Message Security. - Nous vous recommandons d’utiliser un certificat d’authentification de serveur émis par une autorité de certification publique (tierce). - Le certificat de communication de service ne peut pas être un certificat qui utilise des clés CNG. - Vous pouvez gérer ce certificat à l’aide de la console Gestion AD FS. |
| Certificat de signature de jetons : Certificat X509 standard qui permet de signer de manière sécurisée tous les jetons émis par le serveur de fédération. | - Par défaut, AD FS crée un certificat auto-signé avec des clés de 2 048 bits. - Les certificats émis par l’autorité de certification sont également pris en charge et peuvent être modifiés à l’aide du composant logiciel enfichable Gestion AD FS - Les certificats émis par l’autorité de certification doivent être stockés et récupérés via un fournisseur de chiffrement CSP. - Le certificat de signature de jetons ne peut pas être un certificat qui utilise des clés CNG. - AD FS ne nécessite pas de certificats inscrits en externe pour la signature de jetons. AD FS renouvelle automatiquement ces certificats auto-signés avant leur expiration, en configurant d’abord les nouveaux certificats en tant que certificats secondaires pour permettre aux partenaires de les utiliser, puis en retournant vers le principal lors d’un processus appelé substitution automatique de certificats. Nous vous recommandons d’utiliser les certificats générés automatiquement par défaut pour la signature de jeton. Si votre organisation a des stratégies qui nécessitent la configuration de différents certificats pour la signature de jetons, vous pouvez spécifier les certificats au moment de l’installation à l’aide de PowerShell (utilisez le paramètre –SigningCertificateThumbprint du cmdlet Install-AdfsFarm). Après l’installation, vous pouvez afficher et gérer les certificats de signature de jetons à l’aide de la console de gestion AD FS ou des cmdlets PowerShell Set-AdfsCertificate et Get-AdfsCertificate. Lorsque des certificats inscrits en externe sont utilisés pour la signature de jetons, AD FS n’effectue pas de renouvellement ou de substitution automatique des certificats. Ce processus doit être effectué par un administrateur. Pour autoriser la substitution de certificat lorsqu’un certificat est sur le point d’expirer, un certificat de signature de jeton secondaire peut être configuré dans AD FS. Par défaut, tous les certificats de signature de jetons sont publiés dans les services de fédération, mais seul le certificat de signature de jetons principal est utilisé par AD FS pour la signature des jetons. |
| Certificat de chiffrement/déchiffrement de jeton : Il s’agit d’un certificat X509 standard utilisé pour déchiffrer/chiffrer tous les jetons entrants. Il est également publié dans les métadonnées de fédération. | - Par défaut, AD FS crée un certificat auto-signé avec des clés de 2 048 bits. - Les certificats émis par l’autorité de certification sont également pris en charge et peuvent être modifiés à l’aide du composant logiciel enfichable Gestion AD FS - Les certificats émis par l’autorité de certification doivent être stockés et récupérés via un fournisseur de chiffrement CSP. - Le certificat de chiffrement/déchiffrement de jetons ne peut pas être un certificat qui utilise des clés CNG. - Par défaut, AD FS génère et utilise ses propres certificats, générés en interne et auto-signés pour le déchiffrement des jetons. AD FS ne nécessite pas de certificats inscrits en externe à cet effet. En outre, AD FS renouvelle automatiquement ces certificats auto-signés avant leur expiration. Nous vous recommandons d’utiliser les certificats générés automatiquement par défaut pour le déchiffrement de jeton. Si votre organisation a des stratégies qui nécessitent la configuration de différents certificats pour le déchiffrement de jetons, vous pouvez spécifier les certificats au moment de l’installation à l’aide de PowerShell (utilisez le paramètre –DecryptionCertificateThumbprint du cmdlet Install-AdfsFarm). Après l’installation, vous pouvez afficher et gérer les certificats de déchiffrement de jetons à l’aide de la console de gestion AD FS ou des cmdlets PowerShell Set-AdfsCertificate et Get-AdfsCertificate. Lorsque des certificats inscrits en externe sont utilisés pour le déchiffrement de jetons, AD FS n’effectue pas de renouvellement automatique des certificats. Ce processus doit être effectué par un administrateur.. - Le compte de service AD FS doit avoir accès à la clé privée du certificat de signature de jeton dans le magasin personnel de l’ordinateur local. Cette opération est prise en charge par l’installation. Vous pouvez également utiliser le composant logiciel enfichable Gestion d’AD FS pour garantir cet accès si vous modifiez par la suite le certificat de signature de jeton. |
Attention
Les certificats utilisés pour la signature de jeton et pour le déchiffrement/chiffrement de jeton sont essentiels pour la stabilité du service de fédération. Les clients qui gèrent leurs propres certificats de chiffrement et déchiffrement de jeton et certificats de signature de jeton doivent s’assurer que ces certificats sont sauvegardés et disponibles indépendamment pendant un événement de récupération.
Remarque
Dans AD FS, vous pouvez modifier le niveau de l’algorithme de hachage sécurisé utilisé pour les signatures numériques sur SHA-1 ou SHA-256 (plus sécurisé). AD FS ne prend pas en charge l’utilisation de certificats avec d’autres méthodes de hachage, telles que MD5 (algorithme de hachage par défaut utilisé avec l’outil en ligne de commande Makecert.exe). En guise de meilleure pratique pour la sécurité, nous vous recommandons d'utiliser SHA-256 (défini par défaut) pour toutes les signatures. Le niveau SHA-1 n’est recommandé que dans les scénarios où vous devez interagir avec un produit qui ne prend pas en charge les communications utilisant SHA-256, comme un produit non Microsoft ou les versions héritées d’AD FS.
Notes
Après avoir reçu un certificat d'une autorité de certification, assurez-vous que tous les certificats sont importés dans le magasin de certificats personnels de l'ordinateur local. Vous pouvez importer des certificats dans le magasin personnel à l'aide du composant logiciel enfichable Certificats de la console MMC.
Configuration matérielle requise
La configuration matérielle minimale et recommandée suivante s’applique aux serveurs de fédération AD FS dans Windows Server 2012 R2 :
| Configuration matérielle requise | Configuration minimale requise | Configuration recommandée |
|---|---|---|
| Vitesse du processeur | Processeur 1,4 GHz 64 bits | quadruple cœur, 2 GHz |
| Mémoire vive (RAM) | 512 Mo | 4 Go |
| Espace disque | 32 Go | 100 Go |
Configuration logicielle requise
Les exigences AD FS suivantes concernent les fonctionnalités de serveur intégrées au système d’exploitation Windows Server® 2012 R2 :
Pour l’accès extranet, vous devez déployer le service de rôle Proxy d’application web, qui fait partie du rôle serveur Accès à distance Windows Server® 2012 R2. Les versions antérieures d’un proxy de serveur de fédération ne sont pas prises en charge avec AD FS dans Windows Server® 2012 R2.
Un serveur de fédération et le service de rôle Proxy d’application Web ne peuvent pas être installés sur le même ordinateur.
Configuration requise par les services de domaine Active Directory
Conditions requises pour les contrôleurs de domaine
Les contrôleurs de domaine dans tous les domaines utilisateur et le domaine auquel les serveurs AD FS sont joints doivent exécuter Windows Server 2008 ou une version ultérieure.
Remarque
Toute prise en charge des environnements avec des contrôleurs de domaine Windows Server 2003 prendra fin après la date de fin du support étendu pour Windows Server 2003. Il est vivement recommandé aux clients de mettre à niveau leurs contrôleurs de domaine dès que possible. Pour plus d’informations sur le cycle de vie Support Microsoft, consultez cette page. Pour les problèmes détectés qui sont spécifiques aux environnements de contrôleur de domaine Windows Server 2003, les correctifs seront émis uniquement pour les problèmes de sécurité et si un correctif peut être émis avant l’expiration du support étendu pour Windows Server 2003.
Remarque
AD FS nécessite un contrôleur de domaine accessible en écriture complète pour fonctionner par opposition à un contrôleur de domaine en lecture seule. Si une topologie planifiée inclut un contrôleur de domaine en lecture seule, le contrôleur de domaine en lecture seule peut être utilisé pour l’authentification, mais le traitement des revendications LDAP nécessite une connexion au contrôleur de domaine accessible en écriture.
Configuration requise pour le niveau fonctionnel du domaine
Tous les domaines de comptes d’utilisateur et le domaine auquel les serveurs AD FS sont joints doivent opérer au niveau fonctionnel du domaine Windows Server 2003 ou supérieur.
La plupart des fonctionnalités d'AD FS ne nécessitent aucune modification du niveau fonctionnel dans AD DS. Toutefois, le niveau fonctionnel de domaine Windows Server 2008 ou supérieur est nécessaire au bon fonctionnement de l'authentification de certificat client si le certificat est mappé explicitement sur le compte d'un utilisateur dans AD DS.
Exigences relatives au schéma
AD FS n’impose aucune modification de schéma ou du niveau fonctionnel dans les services AD DS.
Pour utiliser la fonctionnalité de jointure d’espace de travail, le schéma de la forêt à laquelle les serveurs AD FS sont joints doit être défini sur Windows Server 2012 R2.
Exigences relatives au compte de service
N’importe quel compte de service standard peut être utilisé comme compte de service pour AD FS. Les comptes de service administrés de groupe sont également pris en charge. Cela nécessite au moins un contrôleur de domaine (il est recommandé d’en déployer deux ou plus) qui exécute Windows Server 2012 ou une version ultérieure.
Pour que l’authentification Kerberos fonctionne entre les clients joints à un domaine et AD FS, « HOST/<nom_service_adfs> » doit être inscrit en tant que SPN sur le compte de service. Par défaut, AD FS le configure lors de la création d’une batterie de serveurs AD FS s’il dispose des autorisations suffisantes pour effectuer cette opération.
Le compte de service AD FS doit avoir la confiance dans chaque domaine qui contient des utilisateurs s’authentifiant auprès du service AD FS.
Exigences relatives au domaine
Tous les serveurs AD FS doivent être joints à un domaine AD DS.
Tous les serveurs AD FS au sein d’une batterie de serveurs doivent être déployés dans un même domaine.
Le domaine auquel les serveurs AD FS sont joints doit approuver chaque domaine de comptes d’utilisateur qui contient des utilisateurs s’authentifiant auprès du service AD FS.
Exigences relatives aux forêts multiples
Le domaine auquel les serveurs AD FS sont joints doit approuver chaque domaine ou forêt de comptes d’utilisateur qui contient des utilisateurs s’authentifiant auprès du service AD FS.
Le compte de service AD FS doit avoir la confiance dans chaque domaine qui contient des utilisateurs s’authentifiant auprès du service AD FS.
Conditions requises pour la base de données de configuration
Voici les exigences et les restrictions qui s’appliquent en fonction du type de magasin de configuration :
Base de données interne Windows
Une batterie WID est limitée à 30 serveurs de fédération si vous avez 100 approbations de parties de confiance ou moins.
Le profil de résolution d’artefacts dans SAML 2.0 n’est pas pris en charge dans la base de données de configuration WID. La détection de relecture de jetons n’est pas prise en charge dans la base de données de configuration WID. Cette fonctionnalité n’est utilisée que dans les scénarios où AD FS agit en tant que fournisseur de fédération et consomme des jetons de sécurité provenant de fournisseurs de revendications externes.
Le déploiement de serveurs AD FS dans des centres de données distincts pour le basculement ou l’équilibrage de charge géographique est pris en charge tant que le nombre de serveurs ne dépasse pas 30.
Le tableau suivant résume l’utilisation d’une batterie WID. Utilisez-le pour planifier votre implémentation.
| Approbations de partie de confiance 1-100 | Plus de 100 approbations de partie de confiance |
|---|---|
| Nœuds AD FS 1-30 : WID pris en charge | Nœuds AD FS 1-30 : Non pris en charge avec WID - SQL Server requis |
| Plus de 30 nœuds AD FS : Non pris en charge avec WID - SQL Server requis | Plus de 30 nœuds AD FS : Non pris en charge avec WID - SQL Server requis |
SQL Server
Pour AD FS dans Windows Server 2012 R2, vous pouvez utiliser SQL Server 2008 et versions ultérieures
Configuration requise des navigateurs
Quand l’authentification AD FS est effectuée par le biais d’un navigateur ou d’un contrôle de navigateur, votre navigateur doit remplir les conditions suivantes :
JavaScript doit être activé.
Les cookies doivent être activés
L’indication du nom du serveur (SNI) doit être prise en charge.
Pour le certificat utilisateur et l’authentification par certificat d’appareil (fonctionnalité de rattachement à l’espace de travail), le navigateur doit prendre en charge l’authentification par certificat client SSL.
Plusieurs navigateurs et plateformes clés ont été validés pour le rendu et les fonctionnalités ; les détails sont répertoriés ci-dessous. Les navigateurs et les appareils qui ne sont pas couverts dans ce tableau sont tout de même pris en charge s’ils répondent aux exigences répertoriées ci-dessus :
| Navigateurs | Plateformes |
|---|---|
| IE 10,0 | Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 |
| IE 11.0 | Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 |
| Service Broker d’authentification web Windows | 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 |
Important
Problème connu - Firefox : la fonctionnalité Workplace Join qui identifie l’appareil à l’aide du certificat d’appareil n’est pas fonctionnelle sur les plateformes Windows. Firefox ne prend actuellement pas en charge l’authentification par certificat client SSL à l’aide de certificats provisionnés dans le magasin de certificats utilisateur sur les clients Windows.
Cookies
AD FS crée des cookies persistants et de session qui doivent être stockés sur les ordinateurs clients pour fournir des fonctionnalités telles que la connexion, la déconnexion et l'authentification unique. Le navigateur client doit donc être configuré de manière à accepter les cookies. Les cookies utilisés pour l'authentification sont toujours des cookies de session HTTPS (Secure Hypertext Transfer Protocol) écrits pour le serveur d'origine. Si le navigateur client n’est pas configuré de manière à autoriser ces cookies, AD FS ne peut pas fonctionner correctement. Les cookies persistants permettent de conserver le fournisseur de revendications choisi par l'utilisateur. Vous pouvez les désactiver à l'aide d'un paramètre de configuration dans le fichier de configuration des pages de connexion AD FS. Pour des raisons de sécurité, la prise en charge de TLS/SSL est nécessaire.
Exigences d’extranet
Pour fournir un accès extranet au service AD FS, vous devez déployer le service de rôle web Proxy d’application en tant que rôle extranet qui envoie par proxy les demandes d’authentification de manière sécurisée au service AD FS. Cela permet d’isoler les points de terminaison de service AD FS, ainsi que d’isoler toutes les clés de sécurité (comme les certificats de signature de jetons) des requêtes provenant d’Internet. En outre, des fonctionnalités comme le verrouillage de compte extranet logiciel nécessitent l’utilisation du Proxy d’application web. Pour obtenir des informations générales sur le proxy d’application web, consultez Proxy d’application web. `
Configuration requise pour le réseau
La configuration appropriée des services réseau suivants est essentielle au succès du déploiement d’AD FS dans votre organisation :
Configuration du pare-feu d’entreprise
Le pare-feu situé entre le proxy d’application web et la batterie de serveurs de fédération ainsi que le pare-feu situé entre les clients et le proxy d’application web doivent avoir le port TCP 443 activé pour le trafic entrant.
De plus, si l’authentification par certificat utilisateur client authentification clientTLS à l’aide de certificats utilisateur x509 est requise, AD FS dans Windows Server 2012 R2 exige que le port TCP 49 443 soit activé dans le sens entrant sur le pare-feu entre les clients et le proxy d’application web. Cela n’est pas obligatoire sur le pare-feu entre le proxy d’application Web et les serveurs de fédération).
Notes
Assurez-vous également que le port 49443 n’est pas utilisé par d’autres services sur le serveur AD FS et le Proxy d’application Web.
Configuration du système DNS
Pour l’accès intranet, tous les clients qui accèdent au service AD FS au sein du réseau d’entreprise interne intranet doivent être en mesure de résoudre le nom du service AD FS (fourni par le certificat SSL) en équilibreur de charge pour le ou les serveurs AD FS.
Pour l’accès extranet, tous les clients qui accèdent au service AD FS à partir de l’extérieur du réseau d’entreprise extranet/internet doivent être en mesure de résoudre le nom du service AD FS (fourni par le certificat SSL) en équilibreur de charge pour le ou les serveurs Proxy d’application web.
Pour que l’accès extranet fonctionne correctement, chaque serveur Proxy d’application web de la zone DMZ doit être capable de résoudre le nom du service AD FS (fourni par le certificat SSL) en équilibreur de charge pour le ou les serveurs AD FS. Cela peut être accompli en faisant appel à un serveur DNS secondaire dans le réseau DMZ ou en changeant la résolution du serveur local à l’aide du fichier HOSTS.
Pour que l’authentification intégrée Windows fonctionne à l’intérieur du réseau et à l’extérieur du réseau pour un sous-ensemble de points de terminaison exposés via le Proxy d’application web, vous devez utiliser un enregistrement A (et non CNAME) pour pointer vers les équilibreurs de charge.
Pour plus d’informations sur la configuration du DNS d’entreprise pour le service de fédération et le service d’inscription des appareils, consultez Configurer le système DNS d’entreprise pour le service de fédération et DRS.
Pour plus d’informations sur la configuration du DNS d’entreprise pour les proxys d’application web, consultez la section « Configurer DNS » dans Étape 1 : configurer l’infrastructure du proxy d’application Web.
Pour plus d’informations sur la configuration d’un nom de domaine complet de cluster ou d’une adresse IP de cluster à l’aide de l’équilibrage de la charge réseau Microsoft, voir Définition des paramètres de cluster sur http://go.microsoft.com/fwlink/?LinkId=75282.
Configuration requise pour les magasins d'attributs
AD FS nécessite qu’au moins un magasin d’attributs soit utilisé pour l’authentification des utilisateurs et l’extraction des revendications de sécurité pour ces utilisateurs. Pour obtenir une liste des magasins d’attributs pris en charge par les services AD FS, consultez The Role of Attribute Stores.
Notes
Par défaut, AD FS crée automatiquement un magasin d’attributs Active Directory. La configuration requise pour les magasins d'attributs varie selon que votre organisation fait office de partenaire de compte (hébergeant les utilisateurs fédérés) ou de partenaire de ressource (hébergeant l'application fédérée).
Magasins d’attributs LDAP
Quand vous utilisez d'autres magasins d'attributs LDAP (Lightweight Directory Access Protocol), vous devez vous connecter à un serveur LDAP qui prend en charge l'authentification intégrée de Windows. En outre, la chaîne de connexion LDAP doit être écrite sous la forme d'une URL LDAP, comme indiqué dans le document RFC 2255.
Il est également nécessaire que le compte de service pour le service AD FS ait le droit de récupérer les informations utilisateur dans le magasin d’attributs LDAP.
Magasins d’attributs SQL Server
Pour qu’AD FS dans Windows Server 2012 R2 fonctionne correctement, les ordinateurs qui hébergent le magasin d’attributs SQL Server doivent exécuter Microsoft SQL Server 2008 ou une version ultérieure. Quand vous utilisez des magasins d'attributs SQL, vous devez également configurer une chaîne de connexion.
Magasins d’attributs personnalisés
Vous pouvez développer des magasins d'attributs personnalisés dans le cadre de scénarios avancés.
Le langage de stratégie intégré à AD FS peut référencer des magasins d'attributs personnalisés de manière à perfectionner les scénarios suivants :
Créer des revendications pour un utilisateur authentifié localement
Compléter les revendications pour un utilisateur authentifié de manière externe
Autoriser un utilisateur à obtenir un jeton
Autoriser un service à obtenir un jeton au nom d'un utilisateur
Émission de données supplémentaires dans des jetons de sécurité émis par AD FS à des parties de confiance.
Tous les magasins d’attributs personnalisés doivent être créés sur .NET 4.0 ou version ultérieure.
Quand vous utilisez un magasin d’attributs personnalisé, vous pouvez également être amené à configurer une chaîne de connexion. Dans ce cas, vous pouvez entrer un code personnalisé de votre choix qui permet une connexion à votre magasin d’attributs personnalisé. Dans ce cas, la chaîne de connexion est un ensemble de paires nom/valeur qui sont interprétées comme implémentées par le développeur du magasin d’attributs personnalisé. Pour plus d’informations sur le développement et l’utilisation de magasins d’attributs personnalisés, consultez Vue d’ensemble des magasins d’attributs.
Exigences des applications
AD FS prend en charge les applications prenant en charge les revendications qui utilisent les protocoles suivants :
Un certificat de fournisseur d'identité WS-Federation
WS-Trust
Protocole SAML 2.0 utilisant des profils IDPLite et SPLite et eGov1.5.
Profil d’octroi d’autorisation OAuth 2.0
AD FS prend également en charge l’authentification et l’autorisation pour toutes les applications qui ne prennent pas en charge les revendications et qui sont prises en charge par le Proxy d’application web.
Exigences relatives à l’authentification
Authentification AD DS (authentification principale)
Pour l’accès intranet, les mécanismes d’authentification standard suivants pour AD DS sont pris en charge :
Authentification intégrée Windows avec Negotiate pour Kerberos et NTLM
Authentification par formulaire à l’aide d’un nom d’utilisateur/mot de passe
Authentification par certificat avec des certificats mappés à des comptes d’utilisateur dans AD DS
Pour l’accès extranet, les mécanismes d’authentification suivants sont pris en charge :
Authentification par formulaire à l’aide d’un nom d’utilisateur/mot de passe
Authentification par certificat avec des certificats mappés à des comptes d’utilisateur dans AD DS
Authentification intégrée Windows utilisant Negotiate (NTLM uniquement) pour les points de terminaison WS-Trust qui acceptent l’authentification intégrée Windows.
Pour l’authentification par certificat :
S’étend aux cartes à puce qui peuvent être protégées par code confidentiel.
L’interface graphique utilisateur permettant à l’utilisateur d’entrer son code confidentiel n’est pas fournie par AD FS et doit faire partie du système d’exploitation client qui s’affiche lors de l’utilisation du protocole TLS client.
Le lecteur et le fournisseur de services de chiffrement pour la carte à puce doivent fonctionner sur l'ordinateur où se trouve le navigateur.
Le certificat de carte à puce doit être chaîné à une racine approuvée sur tous les serveurs AD FS et serveurs de Proxy d’application web.
Le certificat doit être mappé au compte d'utilisateur dans AD DS à l'aide de l'une des méthodes suivantes :
Le nom du sujet du certificat correspond au nom unique LDAP d'un compte d'utilisateur dans AD DS.
L'extension de l'autre nom de l'objet du certificat possède le nom d'utilisateur principal d'un compte d'utilisateur dans AD DS.
Pour une authentification intégrée Windows transparente à l’aide de Kerberos dans l’intranet,
Le nom du service doit faire partie des sites de confiance ou des sites intranet locaux.
En outre, le SPN HOST/<nom_service_adfs> doit être défini sur le compte de service sur lequel la batterie de serveurs AD FS s’exécute.
Azure Multi-Factor Authentication
AD FS prend en charge une authentification supplémentaire (au-delà de l’authentification principale prise en charge par AD DS) à l’aide d’un modèle de fournisseur dans lequel les fournisseurs/clients peuvent créer leur propre adaptateur d’authentification multifacteur qu’un administrateur peut inscrire et utiliser lors de la connexion.
Chaque adaptateur MFA doit être généré sur .NET 4.5.
Pour plus d’informations sur l’authentification multifacteur, voir Gérer les risques avec une authentification multifacteur supplémentaire pour les applications sensibles.
Authentification d’appareil
AD FS prend en charge l’authentification des appareils à l’aide de certificats provisionnés par le service d’inscription d’appareil pendant l’action d’un utilisateur final qui joint son appareil.
Exigences de jointure de l’espace de travail
Les utilisateurs finaux peuvent joindre leurs appareils à une organisation à l’aide d’AD FS. Cela est pris en charge par le service d’inscription des appareils dans AD FS. Par conséquent, les utilisateurs finaux bénéficient de l’avantage supplémentaire de l’authentification unique dans les applications prises en charge par AD FS. En outre, les administrateurs peuvent gérer les risques en limitant l’accès aux applications uniquement aux appareils qui ont été joints à l’organisation. Vous trouverez ci-dessous les conditions requises suivantes pour permettre ce scénario.
AD FS prend en charge la jonction d’espace de travail pour les appareils Windows 8.1 et iOS 5+
Pour utiliser la fonctionnalité de jointure d’espace de travail, le schéma de la forêt à laquelle les serveurs AD FS sont joints doit être défini sur Windows Server 2012 R2.
L’autre nom de l’objet du certificat SSL pour le service AD FS doit contenir la valeur inscriptionentreprise, suivie du suffixe UPN de votre organisation, par exemple inscriptionentreprise.corp.contoso.com.
Exigences en matière de chiffrement
Le tableau suivant fournit des informations supplémentaires sur la prise en charge du chiffrement sur la signature de jeton AD FS et la fonctionnalité de chiffrement/déchiffrement de jeton :
| Algorithme | Longueurs de clé | Protocoles/applications/commentaires |
|---|---|---|
| TripleDES – Par défaut 192 (plage prise en charge : 192 – 256) - http://www.w3.org/2001/04/xmlenc#tripledes-cbc | >= 192 | Algorithme pris en charge pour déchiffrer le jeton de sécurité. Le chiffrement du jeton de sécurité avec cet algorithme n’est pas pris en charge. |
| AES128 - http://www.w3.org/2001/04/xmlenc#aes128-cbc | 128 | Algorithme pris en charge pour déchiffrer le jeton de sécurité. Le chiffrement du jeton de sécurité avec cet algorithme n’est pas pris en charge. |
| AES192 - http://www.w3.org/2001/04/xmlenc#aes192-cbc | 192 | Algorithme pris en charge pour déchiffrer le jeton de sécurité. Le chiffrement du jeton de sécurité avec cet algorithme n’est pas pris en charge. |
| AES256 - http://www.w3.org/2001/04/xmlenc#aes256-cbc | 256 | Par défaut. Algorithme pris en charge pour le chiffrement du jeton de sécurité. |
| TripleDESKeyWrap - http://www.w3.org/2001/04/xmlenc#kw-tripledes | Toutes les tailles de clé prises en charge par .NET 4.0+ | Algorithme pris en charge pour le chiffrement de la clé symétrique qui chiffre un jeton de sécurité. |
| AES128KeyWrap - http://www.w3.org/2001/04/xmlenc#kw-aes128 | 128 | Algorithme pris en charge pour le chiffrement de la clé symétrique qui chiffre le jeton de sécurité. |
| AES192KeyWrap - http://www.w3.org/2001/04/xmlenc#kw-aes192 | 192 | Algorithme pris en charge pour le chiffrement de la clé symétrique qui chiffre le jeton de sécurité. |
| AES256KeyWrap - http://www.w3.org/2001/04/xmlenc#kw-aes256 | 256 | Algorithme pris en charge pour le chiffrement de la clé symétrique qui chiffre le jeton de sécurité. |
| RsaV15KeyWrap - http://www.w3.org/2001/04/xmlenc#rsa-1_5 | 1 024 | Algorithme pris en charge pour le chiffrement de la clé symétrique qui chiffre le jeton de sécurité. |
| RsaOaepKeyWrap - http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p | 1 024 | Par défaut. Algorithme pris en charge pour le chiffrement de la clé symétrique qui chiffre le jeton de sécurité. |
| SHA1-http://www.w3.org/PICS/DSig/SHA1_1_0.html | N/A | Utilisé par le serveur AD FS dans la génération de SourceId d’artefact : dans ce scénario, le STS utilise SHA1 (conformément à la recommandation de la norme SAML 2.0) pour créer une courte valeur de 160 bits pour le SourceId de l’artefact. Également utilisé par l’agent web AD FS (composant hérité de WS2003) pour identifier les modifications apportées à une valeur de temps « dernière mise à jour » afin qu’il sache quand mettre à jour les informations à partir du STS. |
| SHA1withRSA- | N/A | Utilisé dans les cas où le serveur AD FS valide la signature SAML AuthenticationRequest ; signe la demande ou la réponse de résolution d’artefact, crée un certificat de signature de jeton. Dans ce cas, SHA256 est la valeur par défaut et SHA1 est utilisé uniquement si le partenaire (partie de confiance) ne peut pas prendre en charge SHA256 et doit utiliser SHA1. |
Conditions requises pour les autorisations
L’administrateur qui effectue l’installation et la configuration initiale d’AD FS doit disposer des autorisations d’administrateur de domaine dans le domaine local (en d’autres termes, le domaine auquel le serveur de fédération est joint).