Choisir l’authentification d’un SharePoint Server demande de distinguer plusieurs besoins : la connexion des utilisateurs, l’administration de la ferme, l’indexation et les échanges applicatifs. Un protocole adapté au navigateur ne couvre pas automatiquement tous ces usages. Ce guide fournit une grille de lecture pour préparer un audit et un choix d’architecture. Les procédures exactes dépendent de la version, du niveau de correctifs, des clients et du fournisseur d’identité.
Commencer par la version et le scénario
Dressez la liste des publics : collaborateurs sur le réseau local, personnel à distance, partenaires et applications. Ajoutez les clients utilisés : navigateur, Office, synchronisation, scripts et outils métier. Une même personne peut utiliser plusieurs de ces chemins. Documentez ensuite la version complète de la ferme. En novembre 2026, SharePoint Server 2016 et 2019 sont hors support depuis juillet 2026 ; leur évolution est un sujet prioritaire du cadrage. Subscription Edition prend en charge OpenID Connect, alors que ce mode ne doit pas être présenté comme une option native de 2016 ou 2019. La disponibilité d’un mécanisme n’indique pas, à elle seule, qu’il convient à votre parc.
Claims et authentification : deux notions à séparer
Dans une application web fondée sur les revendications, SharePoint reçoit une identité et des attributs qui servent ensuite à déterminer les droits. « Claims » décrit ce modèle ; ce terme ne remplace pas le nom du protocole utilisé pour établir la connexion. Une connexion Windows peut ainsi alimenter une identité à revendications. L’ancien mode Windows classique appartient au patrimoine des versions historiques et ne constitue pas le modèle à proposer pour une nouvelle architecture. Lors d’une migration, vérifiez la représentation des identités dans les groupes, les règles de partage et les personnalisations : changer de fournisseur peut modifier l’identifiant sous lequel SharePoint connaît une personne.
Vue d’ensemble des familles et des limites
Cette grille sert à identifier les sujets à tester. Elle ne constitue pas une recette de déploiement interchangeable entre versions.
| Mécanisme | Usage à examiner | Point de vigilance |
|---|---|---|
| Windows NTLM | Authentification Windows dans les applications web à revendications | Contraintes des clients, sécurité et accès requis par l’exploration |
| Windows Kerberos | Connexion intégrée avec Active Directory | SPN, comptes de service, DNS et délégation selon le flux |
| Windows Basic / Digest | Compatibilités historiques mentionnées dans la documentation | Ne pas les retenir comme cible moderne sans besoin justifié et vérification du support |
| Formulaire (FBA) | Identités validées par un fournisseur ASP.NET Membership | Gestion du fournisseur, des comptes et du chiffrement du parcours |
| Jetons SAML / fédération WS-Fed | Fournisseur d’identité approuvé | Compatibilité exacte du protocole, claims, certificat et résolution des personnes |
| OpenID Connect 1.0 | Fédération dans Subscription Edition | Version, configuration du certificat nonce, fournisseur et clients |
| Anonyme | Contenus explicitement autorisés sans connexion | Ce n’est pas une authentification et cela ne doit pas ouvrir des documents internes |
| OAuth applicatif / serveur à serveur | Accès d’intégrations et relations de confiance | Ne remplace pas le mode de connexion interactif des utilisateurs |
Windows NTLM et Kerberos
Ces deux mécanismes s’appuient sur l’environnement Windows et Active Directory, mais leur préparation diffère. Pour Kerberos, examinez les noms utilisés par les clients, les comptes de service, les SPN et les éventuels sauts vers un service de données. La délégation se conçoit pour un flux précis et ne doit pas être activée largement pour contourner une erreur. Testez le résultat réel plutôt que de déduire le protocole de la seule option « Negotiate ». Pour NTLM, l’audit porte sur les usages qui le nécessitent encore et sur les protections de l’environnement. Aucun de ces protocoles ne fournit, à lui seul, une étape MFA. Les contraintes d’un poste joint au domaine et celles d’un partenaire externe doivent être examinées séparément.
Basic et Digest : traiter les compatibilités anciennes
La documentation de planification Windows mentionne aussi Basic et Digest. Leur présence dans une liste historique ne suffit pas à justifier un nouveau déploiement. Lorsqu’un outil ancien les impose, documentez sa version, son besoin et les alternatives possibles. Vérifiez le support de la configuration complète et les protections du transport ; Basic ne doit pas être utilisé sans HTTPS. Ne transposez pas les options visibles dans IIS à une ferme SharePoint sans procédure prise en charge. Les dépendances aux clients, au fournisseur et au système peuvent rendre une ancienne combinaison impropre au nouvel environnement. Le livrable attendu est une décision justifiée et, si nécessaire, un plan de remplacement du client concerné.
Authentification par formulaire et fournisseurs ASP.NET
Le mode FBA valide une identité à travers un fournisseur d’appartenance ASP.NET et peut utiliser un fournisseur de rôles. Le magasin d’identités peut être une base ou un annuaire compatible avec le fournisseur choisi. Dire « LDAP » ou « SQL » ne décrit donc pas, à soi seul, une nouvelle famille d’authentification SharePoint. Le parcours de saisie des identifiants doit être protégé par HTTPS. La procédure couvre le stockage des comptes, la politique de mot de passe, les accès du fournisseur et la résolution des utilisateurs. Une base SQL utilisée par un fournisseur FBA ne doit pas être confondue avec l’accès technique de SharePoint à ses bases de contenu. Préparez aussi la création, la désactivation et l’assistance de ces comptes pour éviter un annuaire parallèle sans responsable.
Fédération à jetons SAML et fournisseur approuvé
Un fournisseur approuvé peut établir l’identité et transmettre des revendications à SharePoint. La terminologie « SAML » demande de la précision : le scénario historique SharePoint à jetons SAML utilise notamment WS-Federation et ne signifie pas qu’un connecteur SAML 2.0 quelconque pourra être raccordé directement. Vérifiez la documentation du fournisseur et la procédure correspondant à votre version. Le projet doit définir l’identifiant stable de la personne, les attributs utiles et le renouvellement du certificat de signature. Le People Picker et les contrôles de résolution méritent un test explicite : la possibilité de saisir une valeur ne démontre pas qu’elle correspond à une personne valide dans l’annuaire attendu.
OpenID Connect dans Subscription Edition
OpenID Connect 1.0 est disponible dans SharePoint Server Subscription Edition dès sa version initiale. Ce point est distinct des améliorations apportées ensuite à son administration. Le certificat utilisé pour le cookie nonce se gère manuellement dans les versions anciennes ; son intégration à la gestion des certificats SharePoint apparaît en 24H1 avec Early Release puis devient disponible dans le canal Standard à partir de 24H2. La version 24H2 apporte également des améliorations de configuration OIDC, dont les clés publiques RSA. Avant une intervention, relevez le build et les fonctions réellement activées. Contrôlez l’URL HTTPS, la relation de confiance, les identifiants clients, les claims et la rotation des certificats. Les utilisateurs doivent retrouver leurs autorisations et leurs documents après la connexion.
MFA et accès conditionnel : définir la chaîne complète
Dans un scénario fédéré, le fournisseur d’identité peut appliquer des exigences telles que le MFA ou des politiques d’accès conditionnel, selon ses fonctions et les licences détenues. Le parcours réel doit toutefois être testé : un autre accès encore autorisé peut suivre une politique différente. Un reverse proxy de préauthentification constitue également une couche d’architecture, pas un nouveau protocole natif de connexion SharePoint. Documentez ce qui se passe hors du réseau, avec un ancien client et en cas d’indisponibilité du fournisseur. Prévoyez les accès d’administration de secours et leur protection. L’objectif est une chaîne d’accès cohérente plutôt que l’ajout d’une seule case dans un écran de configuration.
Zones, recherche et Administration centrale
Les zones donnent plusieurs chemins logiques vers une application web. Leur nombre et leurs URL doivent répondre à un besoin précis, en tenant compte des accès alternatifs et des certificats. Les consignes de recherche exigent de lire le guide du scénario retenu : la documentation générale évoque NTLM dans au moins une zone, tandis que la procédure Entra OIDC de Subscription Edition demande Windows activé sur la zone par défaut. Cette différence interdit une règle simplifiée appliquée à toute ferme. Vérifiez le crawl, la fraîcheur et la sécurité des résultats. L’Administration centrale conserve son propre accès Windows NTLM ou Kerberos ; la fédération d’un site de contenu ne la transforme pas automatiquement en portail Entra.
Accès anonymes, OAuth et connexions applicatives
L’accès anonyme autorise un contenu sans identité validée et doit rester explicitement limité au besoin. La configuration IIS liée au fonctionnement des revendications ne permet pas de conclure, à elle seule, que les documents sont publics ; ne désactivez pas arbitrairement ses composants. Pour les intégrations, distinguez ensuite la connexion d’un utilisateur, un compte technique et une relation OAuth de serveur à serveur. Le protocole OAuth de serveur à serveur documenté pour SharePoint concerne des échanges approuvés et des permissions ; il ne constitue pas un choix supplémentaire dans le menu de connexion des utilisateurs. Inventoriez les dépendances des applications et vérifiez leur modèle pris en charge avant de moderniser une ferme.
Construire un plan de validation
Retenez des comptes de test représentatifs, avec un propriétaire et un périmètre autorisé. Essayez la connexion interne et externe, les refus attendus, l’expiration de session, l’ouverture des documents dans Office et la recherche. Vérifiez les journaux utiles sans y diffuser de jetons ni de secrets. Prévoyez le renouvellement des certificats et la désactivation d’une personne ou d’un partenaire. Pour un changement de fournisseur, ajoutez le contrôle des groupes, des permissions et des identités existantes. Un dossier court réunissant schéma des flux, version, décisions, essais et procédure de reprise permettra ensuite de maintenir la solution et d’expliquer une anomalie sans reconstruire toute son histoire.
TheWayITis peut vous accompagner pour établir cette cartographie, examiner les authentifications existantes et préparer une évolution testée de votre ferme SharePoint Server.
Sources et repères
Microsoft — Planifier les méthodes d’authentification SharePoint ServerMicrosoft — OpenID Connect dans SharePoint ServerMicrosoft — Configurer OIDC avec Microsoft Entra IDMicrosoft — Améliorations OIDC de Subscription Edition 24H2Microsoft — Authentification SharePoint de serveur à serveurMicrosoft — Authentification de l’Administration centraleMicrosoft — Comptes d’administration et de service SharePointMicrosoft — Produits arrivés en fin de support en 2026Passer du conseil à votre situation
Votre SharePoint Server dépend de bien plus que ses bibliothèques de documents. TheWayITis vous accompagne sur l’architecture de ferme, les identités, SQL Server, la recherche et les procédures d’exploitation de votre environnement sur site.
SharePoint Server et infrastructure sur site