Noms principaux
Pour qu’un client crée une session mutuellement authentifiée avec un programme serveur, il doit fournir le nom principal attendu du serveur. Certains protocoles, tels que Kerberos, nécessitent un nom de principal de serveur correct pour toute session authentifiée. Un principal est une entité que le système de sécurité reconnaît. Cela inclut les utilisateurs humains ainsi que les services système. Tous les noms principaux prennent un format similaire pour un fournisseur de support de sécurité (SSP) donné. Un SSP est un module logiciel qui effectue la validation de sécurité. Pour plus d’informations, consultez Vue d’ensemble de l’architecture SSPI. Pour maintenir l’uniformité, un fournisseur de sécurité donne généralement aux services système des noms similaires à ceux des utilisateurs. Sous certains fournisseurs de sécurité, les services système peuvent ne pas avoir de nom principal.
Le serveur enregistre son nom principal pour le fournisseur de sécurité à l’aide de la fonction RpcServerRegisterAuthInfo . Un seul nom de principal de serveur peut être utilisé pour chaque fournisseur de sécurité. Si plusieurs noms sont enregistrés, un nom est choisi et utilisé de manière aléatoire. Le fournisseur de services partagés détermine le format du nom principal. Par exemple, les SSP Kerberos/Negotiate pour un service système ressemblent approximativement à ce qui suit : machine_name$@childdomain.parentdomain1.parentdomain2.COM.
La procédure recommandée pour générer des noms de principaux consiste à utiliser des API documentées (telles que la fonction DsMakeSpn ), plutôt que de regrouper le nom du principal à partir de chaînes. L’utilisation d’API documentées augmente la portabilité entre différents environnements de déploiement et élimine les risques d’erreurs.
La spécification d’un nom de principal incorrect peut empêcher le client et le serveur d’établir une session authentifiée. Le SSP SCHANNEL prend les noms principaux sous l’une des deux formes suivantes :
- Le premier formulaire de nom principal SCHANNEL est le formulaire msstd . Les noms sous forme msstd suivent généralement le modèle msstd:servername@serverdomain.com. Il s’agit d’une propriété de nom d’e-mail. Si le certificat contient une propriété de nom d’e-mail et qu’il contient le signe at (@), le nom principal est msstd:email name. Sinon, il doit contenir la propriété common name. Les barres obliques inverses internes sont doublées, tout comme dans les liaisons de chaîne.
- Le deuxième formulaire de nom principal SCHANNEL est le formulaire complet . Il s’agit d’une série de noms conformes À la norme RFC1779, délimités par des crochets angulaires et séparés par des barres obliques inverses. Il suit généralement le modèle fullsic:\<\Authority\SubAuthority\.....\Person> ou fullsic:\<\Authority\SubAuthority\.....\ServerProgram>.
Si le nom ne correspond pas au certificat, ERROR_ACCESS_DENIED est retourné. Si le format de nom n’est pas valide, SCHANNEL SSP retourne le code ERROR_INVALID_PARAMETER.
Pour rechercher le nom principal du serveur, les applications peuvent appeler RpcMgmtInqServerPrincName. Cela alloue une chaîne terminée par null pour contenir le nom du principal. Avant de s’arrêter, votre application doit appeler RpcStringFree pour libérer la mémoire occupée par cette chaîne.
L’interrogation du nom du serveur de cette manière n’est pas sécurisée et doit être évitée. Pour l’authentification du serveur, le programme client doit savoir à quel serveur il se connecte et doit créer le nom du principal du serveur à partir de zéro.