Initialisation du contexte du serveur
Comme le client, le serveur acquiert également un handle d’informations d’identification pour être prêt à répondre à une demande d’authentification entrante du client. Les informations d’identification du serveur sont utilisées pour authentifier le serveur auprès du client dans des protocoles de sécurité qui prennent en charge l’authentification du serveur ou l’authentification mutuelle. Le serveur obtient un handle pour ses informations d’identification définies par le compte de service utilisé pour démarrer le serveur. Pour ce faire, il appelle AcquireCredentialsHandle.
Le serveur peut acquérir son handle d’informations d’identification, puis passer à un état d’écoute, ou attendre dans un état d’écoute jusqu’à ce qu’une demande de connexion arrive, puis acquérir un handle d’informations d’identification entrantes. Pour plus d’informations sur les fonctions d’informations d’identification, consultez Gestion des informations d’identification.
Quand le serveur reçoit un message de demande de connexion d’un client, il crée un contexte de sécurité local pour le client à l’aide d’AcceptSecurityContext (Général). Le serveur utilise ce contexte de sécurité local pour effectuer les demandes futures du même client. Pour plus d’informations sur les fonctions de contexte, consultez Gestion du contexte.
Le serveur vérifie la status de retour et le descripteur de mémoire tampon de sortie pour s’assurer qu’il n’y a pas d’erreurs jusqu’à présent et peut rejeter la demande de connexion en cas d’erreurs. S’il existe des informations dans la mémoire tampon de sortie retournées par AcceptSecurityContext (Général), il regroupe cette mémoire tampon dans un message de réponse au client.
Toute mémoire tampon de sortie d’AcceptSecurityContext (Général) doit être renvoyée au client. En outre, si le status de retour nécessite la poursuite du protocole (SEC_I_CONTINUE_NEEDED ou SEC_I_COMPLETE_AND_CONTINUE), un autre échange de messages avec le client est requis.
Pour les étapes supplémentaires, le serveur attend que le client réponde avec un autre message. Cette attente peut être expirée afin d’éviter une attaque par déni de service où un client ne répond pas volontairement, ce qui entraîne l’arrêt d’un thread serveur et bientôt de tous les threads de serveur.