Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Comme le client, le serveur acquiert également une informations d’identification handle 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 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, appelez 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 acquiert un handle d’informations d’identification entrantes. Pour plus d’informations sur les fonctions d’informations d’identification, consultez Gestion des informations d’identification.
Lorsque 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 de acceptSecurityContext (général). Le serveur utilise ce contexte de sécurité local pour effectuer des requêtes futures par le même client. Pour plus d’informations sur les fonctions de contexte, consultez de gestion du contexte.
Le serveur vérifie l’état 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ée par AcceptSecurityContext (Général), elle regroupe cette mémoire tampon dans un message de réponse au client.
Toute mémoire tampon de sortie de AcceptSecurityContext (Général) doit être renvoyée au client. En outre, si l’état de retour nécessite que le protocole continue (SEC_I_CONTINUE_NEEDED ou SEC_I_COMPLETE_AND_CONTINUE), un autre échange de messages avec le client est requis.
Pour des jambes 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 jamais volontairement, provoquant un thread de serveur et bientôt, tous les threads de serveur, pour cesser de répondre.