Articles Techniques, Déploiement Cloud & Hybrid

Installation Configuration et Concepts d'ADFS

Jun 15 20220 commentaires

Vous êtes intéressé par ADFS ?

Vous avez enfin racké votre serveur dans notre magnifique baie Ekivalan ?

https://fibres-et-cables.com/products/dexlan-baie-serveur-42u-600-x-1000-noir

Tout est enfin cablé avec du CAT8 ?

https://fibres-et-cables.com/products/dexlan-cordon-rj45-cat-8-1-s-ftp-lsoh-gris-10-m

Nous sommes donc prêts pour installer et configurer ADFS ;)

L’objectif de cet article est de consigner la procédure à suivre pour l’installation et la configuration d’un serveur ADFS 2016 / 2019.

Ce document ne vise pas une configuration et configuration « In Deep », mais les étapes de base pour le fonctionnement du service.

Installation & Configuration

Planification & Design

Introduction

ADFS est un « Security Token Service » (STS), un service permettant d’émettre des jetons (SAML) aux clients, utilisés dans le process d’authentification.

Toutes les applications ne profitent pas d’ADFS (ex : applications traditionnelles RDP, SQL, etc.), elles doivent être « Claims Aware », capable de consommer un jeton (ex :SAML/JWT) pour l’authentification. Ces jetons contiennent des « Claims ».

La relation de confiance entre le service ADFS et l’application est bâtie sur la signature numérique du jeton, et la confiance accordée au certificat établissant cette signature

Standards supportés

ADFS 2016 supporte de multiple standard de l’industrie, comme :

- WS-Federation Passive Requestor Profile (PRP, browser)

- SAML 1.0 Tokens

- WS-Federation PRP

- WS-Trust (active applications)

- SAML 1.1 Token

- SAML 2.0 Token

- SAML 2.0 Operational Modes

- OAuth (Multiple profiles)

- OpenID Connect

- JSON (JavaScript Object Notation) Web Token (JWT)

Déploiement d’ADFS

· Le serveur ADFS doit être joint au domaine, c’est un prérequis.

A noter que le serveur ADFS est capable d’authentifier tous les utilisateurs de tous les domaines d’une forêt, mais aussi ceux à travers une relation d’approbation de forêt.

NB : La version ADFS 2016 permet aussi d’authentifier des utilisateurs de n’importe quel annuaire LDAP (ex : ADLDS, OpenLDAP, Forêt non Trusté,…)

· Configuration DNS : une configuration « Split Brain DNS » est un prérequis.

Le nom DNS utilisé par la ferme ADFS doit être le même en interne et en externe, ex : adfs.contoso.com depuis l’intranet et depuis internet.

Exemple dans le cas d’une ferme de serveur ADFS composée de plusieurs serveurs :

>Les clients internes et externes résolvent tous le même nom DNS

>Le record DNS en interne doit être de type A pour faire fonctionner le WIA

Base de données

Deux types de déploiement sont proposés pour la base de données ADFS 2016 ;

- L’utilisation de WID

- L’utilisation de SQL Server

WID

L’utilisation de base WID à l’avantage d’être simple à installer. La haute disponibilité et le load balancing est disponible sans configuration car la base est installée sur chaque serveur ADFS. La réplication entre les bases est faite par défaut sur le port 80.

SQL Server

ADFS supporte le stockage de la base de données sur SQL Server, si l’installation est plus complexe, quelques fonctionnalités supplémentaires sont disponibles.

A noter qu’il est nécessaire de mettre en haute disponibilité la partie SQL Server.

Plus d’info : https://technet.microsoft.com/en-us/library/dn554242.aspx

>Privilégier pour commencer l’utilisation de WID, la migration vers SQL Server est possible ultérieurement.

Certificats

ADFS utilise 3 certificats :

- Un certificat SSL pour la communication Client/Serveur

o S’il est possible d’utiliser un certificat interne, il est recommandé d’utiliser un certificat tiers pour que tous les clients l’approuvent (pas seulement les machines du domaine)

o Le « Subject Name » doit matcher le nom de la ferme ADFS, c’est un prérequis

o Les certificats « Wildcard » sont supportés

o Ce certificat pourra être utilisé sur tous les serveurs ADFS et Proxy ADFS

>NB : Noter que si vous souhaiter faire de l’authentification par certificat sans passer par le port 49443 (défaut) mais par le port 443, il est nécessaire de faire apparaitre en SAN l’entrée suivante : certauth.<nom.de.la.ferme.adfs>

https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/ad-fs-support-for-alternate-hostname-binding-for-certificate-authentication

>NB : Noter que si vous souhaitez utiliser la fonctionnalité « Device Registration Service » il est nécessaire de rajouter ceci en SAN :

EnterpriseRegistration.<users_upn>

- Un certificat « Token Signing »

o Utiliser pour signer les jetons

o Si il est possible d’utiliser un certificat tiers ou d’une PKI interne, il est recommandé de conserver l’utilisation de certificat « SelfSigned » généré lors de l’installation du serveur ADFS, pour profiter du mécanisme de « Auto Certificat RollOver » https://social.technet.microsoft.com/wiki/contents/articles/16156.ad-fs-2-0-understanding-autocertificaterollover-threshold-properties.aspx

o Pas de prérequis concernant le « Subject Name »

- Un certificat « Token Decrypting »

o Celui-ci est optionnel, le cryptage de jeton n’étant pas obligatoire

o Utiliser pour cryptage/décryptage des jetons

o Pas de prérequis concernant le « Subject Name »

Installation du rôle ADFS

L’installation d’ADFS se fait via l’ajout d’un rôle Windows Server

L’installation du rôle est terminée, l’étape suivante est la configuration du rôle ADFS:

Configuration du rôle ADFS

Lancer l’assistant de configuration du rôle ADFS :

Choisir d’installer un nouveau serveur ADFS (donc de créer une nouvelle ferme) ou d’ajouter un serveur ADFS à une ferme existante :

NB : Il est possible d’installer plusieurs fermes ADFS différentes au sein d’une même forêt AD

Utiliser un compte « Domain Admin » pour la configuration du rôle :

NB : Être Domain Admins est nécessaire car la configuration d’ADFS va écrire des informations dans la partition de Domaine Active Directory.

Toutefois, dans le cadre de la séparation des rôles, vous pouvez générer un script à faire exécuter par vos Domain Admins pour la configuration du domaine et ensuite exécuter la configuration du rôle ADFS en tant que simple Local Admin.

Choisir le certificat SSL à utiliser, attention le nom de la ferme ADFS doit matcher le nom Subject Name du certificat SSL. Pas de prérequis concernant le Display Name

Choisir un compte de service (pas de droit particulier)

A noter que les gMSA sont pris en charge par ADFS depuis la version 2012 R2:

http://blogs.technet.com/b/askpfeplat/archive/2012/12/17/windows-server-2012-group-managed-service-accounts.aspx

Choisir le type de base de données pour les données de configuration ADFS

Le serveur ADFS est maintenant installé

Console ADFS

Explorons la console rapidement :

https://technet.microsoft.com/en-us/library/adfs2-help-components(v=ws.10).aspx

(1) Attribute Store

Par défaut l’ « Attributes Store » présent est Active Directory, il est obligatoire, il s’agit du magasin où ADFS va chercher des attributs pour les valeurs des Claims (Ex : nom, prenom, UPN, etc.)

Il est possible d’ajouter d’autres Attributs Store (SQL ou LDAP, ou Custom) pour aller chercher dans un autre magasin d’autres valeurs

Ex : Ajout d’un « Attributes Store LDAP » & SQL

https://technet.microsoft.com/en-us/library/dd807093.aspx

(2) Authentication Methods

Il s’agit ici de définir ici les méthodes d’authentification qu’ADFS peut prendre en charge et offrir aux utilisateurs : que ce soit en Interne, et en Externe (formulaire ? certificat ? WIA ? Windows Hello ?...), puis ensuite en tant que 1er et 2nd facteur d’authentification (OTP ? Azure MFA ?...)

Il faut comprendre qu’un client est considéré venant de l’Extranet lorsqu’il s’authentifie sur le WAP, et qu’un client est considéré comme venant de l’intranet lorsqu’il s’authentifie directement sur le serveur ADFS.

(3) Certificats

Affichent les certificats utilisés par ADFS

(4) Claim Description

Les claims sont des « attributs » ou « statements » sur les utilisateurs. Les Claims seront injectés dans les jetons émis aux utilisateurs.

Vous pouvez ajouter vos propres claims dans la console ADFS, via l’option « Add Claim Description »

(5) Device Registration

Le service Device Registration est optionnel.

Il nécessite une configuration du certificat SSL particulière (voir les prérequis), et permet d’enregistrer les équipements (PC, mobile, …) dans l’AD par ADFS sous forme d’objets de type « Device ». Il est possible ensuite d’utiliser ces informations pour implémenter des règles d’accès conditionnelles.

(6) Endpoints

Les Endpoints fournissent les accès aux fonctionnalités ADFS : Accès aux Metadata, Endpoints pour les applications, etc.

(7) Scope Description

La partie « Scope Description » est désignée pour fonctionner avec les « Applications Group » (voir plus bas).

Basiquement, cela remplace l’implémentation de Claims Rule pour les applications basées sur OAuth (typiquement les applications mobiles).

(8) Web Application Proxy

Cette page affiche simplement l’état du service WAP

(9) Access Control Policies

Les ACP permettent de définir des templates d’autorisation que l’on appliquera ensuite aux différentes Relying Party

(10) Relying Party Trust

Les « relying party » sont les applications déclarés dans la console ADFS.

La gestion de génération du Token pour chaque application se fait via « Claims Rules »,

Un clic droit sur une Replying Party permet de créer ces règles :

De nombreux exemples sur la création de Claims Rules sont disponibles sur le Technet

https://technet.microsoft.com/en-us/library/ee913571.aspx

(11) Claims Provider Trust

Il est possible d’ajouter (en plus de Active Directory) d’autres fournisseurs d’identités (un partenaire par exemple) pour donner accès à vos applications à des utilisateurs hors de votre organisation

A noter qu’il est possible d’ajouter des « Local Claim Provider » (des annuaires LDAP (Oracle, ADLDS, Fôret non Trusté, etc) pour prendre en charge l’authentification non plus seulement d’utilisateurs Active Directory, mais aussi de n’importe quel LDAP.

Les « Local Claims Provider” se paramètrent via Powershell

https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-ad-fs-to-authenticate-users-stored-in-ldap-directories

(12) Applications Group

Depuis ADFS 2016, OpenIDConnect & OAuth 2.0 sont implémentés. La Gestion de l’authentification et des autorisations pour ce type d’applications (ModernApp) se faire via cette interface.

https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/overview/ad-fs-scenarios-for-developers

Customisation des pages web ADFS

Depuis ADFS 2012 R2, IIS n’étant plus installé, la customisation des pages de « SignIn » ADFS est plus simple, et la majorité des modifications directement faisables via Powershell.

Ex : Logo & Illustration, customisation des liens, création de thèmes, customisation des messages d’erreurs

Exemple :

- Changement du logo :

Set-AdfsWebTheme -TargetName default -Logo @{path="c:\Contoso\logo.png"}

- Changement de l’illustration :

Set-AdfsWebTheme -TargetName default -Illustration @{path="c:\Contoso\illustration.png"}

- Changement du Compagny Name :

Set-AdfsGlobalWebContent –CompanyName "Contoso Corp"

- La liste complète des commandes est disponible ici :

https://technet.microsoft.com/en-us/library/dn280950.aspx

Installation du rôle ADFS Proxy

Introduction

Le serveur WAP agit en tant que proxy ADFS pour protéger les serveurs ADFS d’Internet, c’est son but premier, il s’occupe de la pré-authentication ADFS depuis l’externe.

Le serveur WAP peut aussi publier sur Internet des applications OnPremise Claims-Aware qui seraient configurés avec ADFS.

Ensuite le WAP peut publier des applications de type Kerberos sur Internet, en se chargeant de la pré-authentification auprès des contrôleurs de domaine (délégation de l’authentification)

Et enfin, le WAP peut agir en simple Reverse Proxy pour publier n’importe quel type d’application web.

Les WAP peuvent être intégrés au domaine ou non.

L’intégration de WAP au domaine est nécessaire seulement lorsque l’on souhaite déployer des applications web Kerberos.

Plus d’info : https://technet.microsoft.com/en-us/library/dn584113.aspx

Installation

L’installation de la fonctionnalité WAP se fait via le menu d’ajout de rôle Server

Choisir le rôle « Remote Access »

Puis choisir la fonctionnalité « Web Application Proxy »

Lancer l’assistant de configuration du WAP

Renseigner le nom de la ferme ADFS, un compte avec les droits d’administration sur le serveur ADFS

Choisir un certificat SSL avec en « Subject Name » le nom de la ferme ADFS (il est possible d’utiliser le même certificat que celui installé sur le serveur ADFS)

Ne pas oublier d’avoir en SAN certauth.<nom.de.la.ferme.adfs> pour l’utilisation de l’authentification utilisateur par certificat via le port 443 (sinon ca sera via 49443)

Le rôle est maintenant installé.

Configuration du WAP

La configuration du WAP est simple, le bouton Publish permet de publier sur internet des applications renseigné et configuré dans ADFS (Claims Aware, Kerberos) ; ou des applications en PassThrough (Reverse Proxy simple) :

Choisir un type d’application, ADFS (web, mobile, etc) ou directement en Pass-Through (dans ce cas ADFS n’entre pas en jeu, c’est du simple reverse proxy)

Choisir l’application à publier :

Coté ADFS :

Coté WAP on retrouve les applications ADFS :

ll est nécessaire que le WAP ait accès aux applications à publier

Choisir un nom, et les url externe et interne, puis le certificat à utiliser (Wildcard accepté)

Dans la console principale vous trouvez ensuite la liste des applications publiées et sur la gauche la liste des serveurs WAP :

Concepts clé d’ADFS

Il est nécessaire de comprendre le concept générique et les dialogues entre le client, le serveur applicatif, et le serveur ADFS

- Un client se connecte à un serveur ADFS qui l’authentifie et émet un jeton valable pour une application

- Le jeton contient des « Claims » qui possèdent différentes valeurs

- Ce jeton est toujours signé numériquement

Le schéma ci-dessous retrace le flow réseau entrant en jeu lors d’un accès d’un client à une application web :

En fonction du protocole utilisé (WS-FED/SAML/OAuth/OIDC) celui-ci peut différer, mais l’idée générale est celle-ci.

Exploitation

Base de Données

WID

Dans le cas de l’utilisation de base de données WID, un serveur de la ferme est considéré comme primaire, et les autres secondaires.

Si tous les serveurs fournissent le service d’authentification de la même manière, il n’est possible de faire des modifications de configuration que sur le serveur primaire, les autres répliquant les modifications effectuées.

- Si le serveur primaire est « down » :

o Le service continu d’être fourni par les autres serveurs ADFS

o Il n’est plus possible toutefois de faire de modification dans la console ADFS

o Lors de la remise en service du serveur primaire, il sera à nouveau possible de procéder à des modifications de configuration ADFS.

o Si le serveur primaire ne peut pas être remis en service :

§ Il est possible de nommer un nouveau serveur primaire :

· Set-ADFSSyncProperties -role PrimaryComputer

§ Et d’informer les autres secondaires du changement

· Set-ADFSSyncproperties -role SecondaryComputer -PrimaryComputerName <FQDN of new primary>

Attention à ne pas nommer 2 serveurs primaires, des différences de configuations pourraient survenir.

SQL

Dans le cas d’utilisation de SQL Server pour la base de données, celle-ci est partagé par tous les serveurs ADFS, ce qui signifie que si la base de données est indisponible, le service ADFS est HQ pour tous les serveurs ADFS. Il est donc important de mettre en place de la haute disponibilité pour cette base :

- Cluster SQL

- Sync Mirroring

- Always ON

ADFS peut être configuré pour prendre en charge plusieurs « FailOver Partner » SQL, via une configuration dans le fichier de configuration ADFS :

…Data Source=<Principal SQLServer>; Failover Partner=<Mirror SQLServer>…

Haute disponibilité des Serveurs

Comme décrit dans le chapitre « Installation & Design », il est recommandé d’installer au moins 2 serveurs ADFS, et 2 serveurs WAP.

Penser à la mise en haute disponibilité de la base de données en fonction du choix WID ou SQL comme décrit en chapitre « Installation & Design ».

Il n’existe pas de mode dégradé pour ADFS, si le service est indisponible, l’accès aux applications « Claims Aware » est indisponible aussi.

Load Balancing

Les serveurs ADFS et ADFS proxy doivent être considérés comme les autres services Web, un load balancer tiers doit être utilisé pour monitorer et distribuer le traffic http/https.

Si le service intégré Microsoft NLB peut être utilisé, celui-ci n’intègre pas de sonde de santé.

Le monitoring du service ADFS par le load balancer doit se faire sur cette URL :

https://<nom_du_service_adfs>/federationmetadata/2007-06/federationmetadata.xml

- L’affichage de cette page, générée dynamiquement valide que :

o Le service ADFS est fonctionnel sur les serveurs ADFS

o Les services web sont fonctionnels sur les serveurs ADFS

o La base de données est accessible par les serveurs ADFS

o L’affichage de cette page au travers les serveurs WAP valident aussi leurs fonctionnements

Il est nécessaire d’utiliser les « host Header » depuis les load balancer

Il est aussi possible d’utiliser une sonde http pour des raisons de facilité (sans host header) :

http://<adfs_server_name/adfs/probe

- Un retour “HTTP 200” signifie que tous les services sont up

Un Check manuel peut être fait via l’URL suivante :

https://<adfs_server_name/adfs/ls/idpinitiatedsignon

(le bouton « Se connecter » permet de s’assurer que la brique d’authentification fonctionne correctement)

Synchronisation du temps

Si au sein d’un domaine la synchronisation du temps doit respecter le processus NT5DS :

http://blogs.technet.com/b/nepapfe/archive/2013/03/01/it-s-simple-time-configuration-in-active-directory.aspx

Il est fréquent de trouver le WAP en « Workgroup ». Il faut alors s’assurer que la variation de temps entre le WAP et le serveur ADFS ne dépasse pas 5 min.

Il est possible de configurer sur le WAP la même source de temps externe NTP sur le WAP que sur le PDC de la forêt.

Certificats

Vérification du Certificat SSL

- Assurez-vous que le compte de service possède les droits de lecture sur la clé privée du certificat. Si ceci est fait automatiquement lors de l’installation du serveur ADFS, c’est une manipulation manuelle lors du changement du certificat

- Monitorer l’expiration des certificats, un certificat expiré entraine un arrêt de service, une indisponibilité d’accès à une application.

Placer des rappels dans votre calendrier outlook pour l’expiration des certificats
Utiliser le mecanisme de « Auto Certificat RollOver »

- Assurez-vous que la clé privée est présente dans le certificat, le service ADFS ne fonctionne pas sans clé privée.

Changement du Certificat SSL

- Importer le nouveau certificat avec la clé privée dans le store « My Computer » depuis une MMC (certlm.msc)

- Ajouter le droit « READ » sur la clé privée au compte de service ADFS :

(clic droit sur le certificat, « Manage private key »

- Dans la console ADFS, allez chercher le nouveau certificat :

- Enfin pour finir corriger les bindings Powershell avec la commande suivante

Set-AdfsSslCertificate -Thumbprint <Thumbprint du certificat à récupérer dans les détails du certificat>

- Redémarrer le service ADFS

- Sur les WAP, après avoir importé le certificat dans le store My/Computer de la même façon, lancer la commande suivante :

Set-WebApplicationProxySslCertificate -Thumbprint <Thumbprint du certificat à récupérer dans les détails du certificat>

- Redémarrer les services ADFS

Attention, si vous avez désactivé le SNI, il faudra recorriger les bindings pour ipport 0.0.0.0 (voir paramètre sur désactiver le SNI)

Désactivation du SNI ?

SNI est une extension du protocole TLS SSL qui permet au client d’inclure le hostname du service auquel le client tente de se connecter.

ADFS par défaut ne répond que si le client envoie le hostname est envoyé correctement par le client, ce qui pourrait poser problème a des clients legacy ou des équipements réseaux ne supportant pas le SNI.

Notez que Microsoft recommande de garder le SNI actif.

- Désactiver le SNI sur les serveurs ADFS :

netsh http add sslcert ipport=0.0.0.0:443 certhash=<thumbprint du certificate> appid={f955c070-e044-456c-ac00-e9e4275b3f04}

- Désactiver le SNI sur les WAP

netsh http add sslcert ipport=0.0.0.0:443 certhash=<thumbprint du certificate> appid= {f955c070-e044-456c-ac00-e9e4275b3f04}

SPN

L’installation du service ADFS créé un SPN sur le compte de service de type HOST/adfs.contoso.com

Le service ne fonctionne pas en cas d’absence de SPN, ou en cas de « duplicate ».

Vérification de l’unicité via :

Setspn –L <service account name>

Setspn –X –F (pour la forêt)

Backup ADFS / ADFS Rapid Restore Tool

- L’outil Restauration rapide de AD FS peut être utilisé dans les scénarios suivants :

Restaurer rapidement des fonctionnalités AD FS après un problème

Utilisez l’outil pour créer une installation de mise en veille à froid d’AD FS qui peut être déployée rapidement à la place du serveur AD FS en ligne

Déployer des environnements de test et de production identiques

Utilisez l’outil pour créer rapidement une copie exacte de la production AD FS dans un environnement de test, ou pour déployer rapidement une configuration de test validé en production

- Ce qui est sauvegardé ?

Base de données configuration AD FS (SQL ou WID)

Fichier de configuration (situé dans le dossier AD FS)

Les certificats de Signature et d’Encryption

Le certificat SSL si exportable

La liste des fournisseurs d’authentification personnalisés, les magasins d’attributs et fournisseur de revendications local d’approbations qui sont installés.

- Installation :

import-module ADFSRapidRecreationTool.dll

- Création d’un backup

Backup-ADFS -StorageType "FileSystem" -StoragePath "C:\Users\administrator\testExport\" -EncryptionPassword "password" -BackupComment "Clean Install of ADFS (FS)" -BackupDKM

- Restauration d’un backup

Restore-ADFS -StorageType "FileSystem" -StoragePath "C:\uSERS\administrator\testExport\" -DecryptionPassword "password" -RestoreDKM

Smart Extranet Account Lockout

Le WAP fournit de nombreuses fonctionnalités de sécurité pour protéger votre réseau d’entreprise contre les menaces externes. Une de ces fonctionnalités est le « Smart Account Lockout » extranet ADFS.

Dans le cas d’une attaque « brut force », ce paramètre permet de protéger les comptes AD d’un verrouillage (si une policy de lock de compte suite à des tentatives erronées est en place), tout en maintenant une liste blanche des IP d’où est parvenue précédemment une authentification réussie.

Pour configurer le « Smart Extranet Lockout», vous devez définir trois propriétés via « get-adfsproperties / set-adfsproperties :

- EnableExtranetLockout: Valeur booléenne TRUE/FALSE

- ExtranetLockoutThreshold : Entier, qui définit le nombre maximal de tentatives de mot de passe incorrect, il est nécessaire de définir cette valeur à une valeur inférieure à la valeur de seuil de verrouillage dans le domaine AD.

- ExtranetObservationWindow: Définit la période de temps où ADFS ne tentera plus d’authentifier le compte.

Exemple de commande PowerShell :

Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 15 -ExtranetObservationWindow ( new-timespan -Minutes 30).

A noter qu’un paramètre ExtranetLockoutRequirePDC est placé à $True par défaut.

C’est-à-dire que l’on fait seulement confiance au PDC pour la valeur du « badpwdcount ». L’inconvénient étant que si le PDC est hors ligne, plus aucune authentification externe n’est possible.

Il est souvent judicieux de le placer à $False

Journaux

Dans l’Event Viewer, le log « Admin ADFS » vous informera de l’état de santé des services ADFS, des problèmes de configuration de certificats, et de l’état des relations avec les WAP