Partager via


Vous ne pouvez pas ouvrir des partages de fichiers ou des composants logiciels enfichables de stratégie de groupe sur un contrôleur de domaine

Cet article explique comment résoudre un problème qui se produit lorsque la signature SMB est désactivée pour le service Station de travail ou serveur sur un contrôleur de domaine.

S’applique à : Windows Server 2003
Numéro de base de connaissances d’origine : 839499

Résumé

Vous ne pouvez pas ouvrir de partages de fichiers ou les composants logiciels enfichables de stratégie de groupe sur un contrôleur de domaine Windows Server 2003 ou sur un contrôleur de domaine Windows 2000 Server. Lorsque vous vous connectez au contrôleur de domaine localement, puis essayez d’ouvrir des partages sur le contrôleur de domaine, vous recevez des invites de mot de passe répétées et vous ne pouvez pas ouvrir les partages. Vous pouvez résoudre ce problème en modifiant le Registre.

Avertissement

De graves problèmes peuvent se produire si vous vous trompez en modifiant le Registre à l’aide de l’Éditeur du Registre ou toute autre méthode. Vous risquez même de devoir réinstaller le système d’exploitation. Microsoft ne peut pas garantir que ces problèmes puissent être résolus. Vous modifiez le Registre à vos propres risques.

Symptômes

Scénario 1 : la signature SMB (Server Message Block) est désactivée pour le service Station de travail sur un contrôleur de domaine, mais la signature SMB est requise pour le service serveur sur le même contrôleur de domaine.

Windows Server 2003

Lorsque vous essayez d’ouvrir des composants logiciels enfichables de stratégie de groupe sur le contrôleur de domaine, vous recevez un message d’erreur semblable à ce qui suit :

Vous n’êtes pas autorisé à effectuer cette opération. L’accès est refusé.

Le contrôleur de domaine enregistre les événements suivants dans le journal des événements de l’application toutes les cinq minutes :

Windows 2000 Server

Lorsque vous essayez d’ouvrir des composants logiciels enfichables de stratégie de groupe sur le contrôleur de domaine, vous recevez un message d’erreur semblable à ce qui suit :

Vous n’êtes pas autorisé à effectuer cette opération.

L’accès est refusé. Le contrôleur de domaine enregistre l’événement suivant dans le journal des événements de l’application :

Lorsque vous vous connectez au contrôleur de domaine localement, puis essayez d’ouvrir des partages sur le contrôleur de domaine, vous recevez des invites de mot de passe répétées et vous ne pouvez pas ouvrir les partages.

Scénario 2 : la signature SMB est désactivée pour le service serveur sur un contrôleur de domaine, mais la signature SMB est requise pour le service Station de travail sur le même contrôleur de domaine

Windows Server 2003

Échec de l’ouverture de l’objet de stratégie de groupe. Vous n’avez peut-être pas les droits appropriés.

Le compte n’est pas autorisé à se connecter à partir de cette station.

Dans une trace réseau, si la signature SMB est activée et requise sur le client et est désactivée sur le serveur, la connexion à la session TCP est correctement fermée après la négociation dialecte, et le client reçoit l’erreur suivante :

1240 (ERROR_LOGIN_WKSTA_RESTRICTION)

Le contrôleur de domaine enregistre les événements suivants dans le journal des événements de l’application toutes les cinq minutes : lorsque vous vous connectez au contrôleur de domaine localement, puis essayez d’ouvrir des partages de fichiers sur le contrôleur de domaine, vous recevez un message d’erreur semblable à ce qui suit :

\\\Server_Name Share_Name n’est pas accessible. Vous ne disposez peut-être pas des autorisations nécessaires pour utiliser cette ressource réseau. Contactez l’administrateur de ce serveur pour savoir si vous disposez des autorisations d’accès.

Le compte n’est pas autorisé à se connecter à partir de cette station.

Note

Dans une trace réseau, si la signature SMB est activée et si la signature SMB est requise sur le client et désactivée sur le serveur, la connexion à la session TCP est correctement fermée après la négociation dialectale. En outre, le client reçoit le message d’erreur suivant : 1240 (ERROR_LOGIN_WKSTA_RESTRICTION)

Windows 2000 Server

Lorsque vous essayez d’ouvrir des composants logiciels enfichables de stratégie de groupe sur le contrôleur de domaine, vous recevez un message d’erreur similaire à ce qui suit :

Échec de l’ouverture de l’objet de stratégie de groupe. Vous n’avez peut-être pas les droits appropriés.

Le compte n’est pas autorisé à se connecter à partir de cette station.

Le contrôleur de domaine enregistre l’événement suivant dans le journal des événements de l’application : lorsque vous vous connectez au contrôleur de domaine localement, puis essayez d’ouvrir des partages de fichiers sur le contrôleur de domaine, vous recevez un message d’erreur similaire à ce qui suit :

\\\Server_Name Share_Name n’est pas accessible.

Le compte n’est pas autorisé à se connecter à partir de cette station.

Note

Dans une trace réseau, si la signature SMB est activée et si la signature SMB est requise sur le client et désactivée sur le serveur, la connexion à la session TCP est correctement fermée après la négociation dialectale. En outre, le client reçoit le message d’erreur suivant : 1240 (ERROR_LOGIN_WKSTA_RESTRICTION)

Résolution

Pour résoudre ce comportement, procédez comme suit :

Important

Cette section, méthode ou tâche contient des étapes vous indiquant comment modifier le Registre. Toutefois, des problèmes graves peuvent se produire si vous modifiez le Registre de façon incorrecte. Par conséquent, vérifiez que vous suivez ces étapes attentivement. Pour une protection supplémentaire, sauvegardez le Registre avant de le modifier. Ensuite, vous pouvez restaurer le Registre si un problème se produit. Pour plus d’informations sur la sauvegarde et la restauration du Registre, consultez Comment sauvegarder et restaurer le Registre dans Windows XP.

Étape 1 : modifier le Registre

Modifiez la valeur de l’entrée de Registre enablesecuritysignature. Pour ce faire, procédez comme suit :

  1. Sur le contrôleur de domaine, cliquez sur Démarrer, puis sur Exécuter.

  2. Copiez et collez (ou tapez) la commande regedit dans la zone Ouvrir, puis appuyez sur Entrée.

    Capture d’écran de la fenêtre Exécuter avec regedit tapé dans la zone Ouvrir.

  3. Recherchez la sous-clé de Registre suivante, puis cliquez dessus : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters

  4. Dans le volet droit, double-cliquez sur enablesecuritysignature, tapez 1 dans la zone De données Valeur, puis cliquez sur OK.

  5. Double-cliquez sur requiresecuritysignature, tapez 1 dans la zone De données Valeur, puis cliquez sur OK.

  6. Recherchez la sous-clé de Registre suivante, puis cliquez dessus : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters

  7. Dans le volet droit, double-cliquez sur enablesecuritysignature, tapez 1 dans la zone De données Valeur, puis cliquez sur OK.

  8. Double-cliquez sur requiresecuritysignature, tapez 0 dans la zone de données Valeur, puis cliquez sur OK.

Étape 2 : Redémarrez le service serveur et le service Station de travail après avoir modifié les valeurs du Registre, redémarrez le service serveur et le service Station de travail.

Important

Ne redémarrez pas le contrôleur de domaine, car cette action peut entraîner la modification des valeurs de Registre par les valeurs antérieures.

Pour redémarrer le service serveur et le service Station de travail, procédez comme suit :

  1. Cliquez sur Démarrer, pointez sur Outils d’administration, puis cliquez sur Services.

  2. Cliquez avec le bouton droit sur Serveur, puis cliquez sur Redémarrer.

    Capture d’écran de la fenêtre Services avec Serveur sélectionné et menu avec Redémarrage sélectionné.

  3. Cliquez avec le bouton droit sur Station de travail, puis cliquez sur Redémarrer.

Note

Si vous êtes invité à redémarrer d’autres services, cliquez sur Oui.

Étape 3 - Mettre à jour le partage Sysvol

Mettez à jour le partage Sysvol du contrôleur de domaine. Pour ce faire, procédez comme suit :

  1. Ouvrez le partage Sysvol du contrôleur de domaine. Pour ce faire, cliquez sur Démarrer, cliquez sur Exécuter, tapez \\Server_Name\Sysvol dans la zone Ouvrir, puis appuyez sur Entrée.
  2. Si le partage Sysvol ne s’ouvre pas, répétez l’étape 1 - Modifier le Registre et l’étape 2 - Redémarrer les services serveur et station de travail .
  3. Répétez l’étape 1 : modifiez le Registre et l’étape 2 : redémarrez les services serveur et station de travail sur chaque contrôleur de domaine affecté pour vous assurer que chaque contrôleur de domaine peut accéder à son propre partage Sysvol.

Étape 4 : configurer les paramètres de stratégie SMB

Après vous être connecté au partage Sysvol sur chaque contrôleur de domaine, ouvrez le composant logiciel enfichable Stratégie de sécurité du contrôleur de domaine, puis configurez les paramètres de stratégie de signature SMB. Pour ce faire, procédez comme suit :

  1. Cliquez sur Démarrer, pointez sur Programmes, pointez sur Outils d’administration, puis cliquez sur Stratégie de sécurité du contrôleur de domaine.

  2. Dans le volet gauche, développez Stratégies locales, puis cliquez sur Options de sécurité.

  3. Dans le volet droit, double-cliquez sur Serveur réseau Microsoft : Signer numériquement les communications (toujours).

    Note

    Dans Windows 2000 Server, le paramètre de stratégie équivalent est la communication du serveur de signez numériquement (toujours) .

    Important

    Si vous disposez d’ordinateurs clients sur le réseau qui ne prennent pas en charge la signature SMB, vous ne devez pas activer le serveur réseau Microsoft : signez numériquement les communications (toujours) paramètre de stratégie. Si vous activez ce paramètre, vous devez disposer de la signature SMB pour toutes les communications clientes, et les ordinateurs clients qui ne prennent pas en charge la signature SMB ne pourront pas se connecter à d’autres ordinateurs. Par exemple, les clients exécutant Apple Macintosh OS X ou Microsoft Windows 95 ne prennent pas en charge la signature SMB. Si votre réseau inclut des clients qui ne prennent pas en charge la signature SMB, définissez cette stratégie sur désactivée.

    Capture d’écran de la fenêtre Paramètres de sécurité du contrôleur de domaine par défaut avec options de sécurité sélectionnées.

  4. Cliquez pour activer la case à cocher Définir ce paramètre de stratégie, cliquez sur Activé, puis sur OK.

    Capture d’écran de la fenêtre serveur réseau Microsoft avec le paramètre Définir ce paramètre de stratégie sélectionné et activé.

  5. Double-cliquez sur Serveur réseau Microsoft : signer numériquement les communications (si le client accepte).

    Note

    Pour Windows 2000 Server, le paramètre de stratégie équivalent est la communication de serveur de signez numériquement (le cas échéant) le serveur.

  6. Cliquez pour activer la case à cocher Définir ce paramètre de stratégie, puis sur Activé.

  7. Cliquez sur OK.

  8. Double-cliquez sur Client réseau Microsoft : signer numériquement les communications (toujours).

  9. Cliquez pour décochez la case Définir ce paramètre de stratégie, puis cliquez sur OK.

    Capture d’écran de la fenêtre serveur réseau Microsoft avec la case à cocher Définir ce paramètre de stratégie désactivée.

  10. Double-cliquez sur client réseau Microsoft : signer numériquement les communications (si le serveur accepte).

  11. Cliquez pour décochez la case Définir ce paramètre de stratégie, puis cliquez sur OK.

Étape 5 : Exécuter l’utilitaire de mise à jour de stratégie de groupe

Exécutez l’utilitaire de mise à jour de stratégie de groupe (Gpupdate.exe) avec le commutateur de force. Pour ce faire, procédez comme suit :

  1. Cliquez sur Démarrer, puis sur Exécuter.

  2. Copiez et collez (ou tapez) la commande cmd dans la zone Ouvrir, puis appuyez sur Entrée.

    Capture d’écran de la fenêtre Exécuter avec cmd tapé dans la zone Ouvrir.

  3. À l'invite de commandes, tapez gpupdate /force, puis appuyez sur Entrée.

    Note

    L’utilitaire de mise à jour de stratégie de groupe n’existe pas dans Windows 2000 Server. Dans Windows 2000 Server, la commande équivalente est secedit /refreshpolicy machine_policy /enforce.

Étape 6 : vérifier le journal des événements de l’application

Après avoir exécuté l’utilitaire de mise à jour de stratégie de groupe, vérifiez le journal des événements de l’application pour vous assurer que les paramètres de stratégie de groupe ont été mis à jour correctement. Après une mise à jour de stratégie de groupe réussie, le contrôleur de domaine enregistre l’ID d’événement 1704. Pour ouvrir le journal d’application dans l’Observateur d’événements, procédez comme suit :

  1. Cliquez sur Démarrer, pointez sur Outils d’administration, puis cliquez sur Observateur d’événements.

  2. Dans le volet gauche, cliquez sur Application.

    Capture d’écran de la fenêtre Observateur d’événements avec l’application sélectionnée.

  3. Double-cliquez sur l’ID d’événement 1704 et vérifiez que le paramètre de stratégie de groupe a été appliqué correctement.

    Note

    La source de l’événement est SceCli.

    Capture d’écran de l’Fenêtre Propriétés d’événement pour l’ID d’événement 1704.

Étape 7 : Vérifier les valeurs du Registre

Vérifiez les valeurs de Registre que vous avez modifiées à l’étape 1 : modifiez le Registre pour vous assurer que les valeurs du Registre n’ont pas changé.

Note

Cette étape garantit qu’un paramètre de stratégie en conflit n’est pas appliqué à un autre niveau d’unité d’organisation ou de groupe. Par exemple, si le client réseau Microsoft : la stratégie de signature numérique (si le serveur accepte) est configurée comme « Non définie » dans la stratégie de sécurité du contrôleur de domaine, mais cette même stratégie est configurée comme désactivée dans la stratégie de sécurité de domaine, la signature SMB est désactivée pour le service station de travail.

Étape 8 : Vérifiez les paramètres de stratégie de signature SMB à l’aide du composant logiciel enfichable RSoP (Resultant Set of Policy)

Si les valeurs de Registre ont changé après avoir exécuté l’utilitaire de mise à jour de stratégie de groupe, vérifiez les paramètres de stratégie de signature SMB à l’aide du composant logiciel enfichable RSoP dans Windows Server 2003. Pour ce faire, procédez comme suit :

  1. Cliquez sur Démarrer, sur Exécuter, tapez rsop.msc dans la zone Ouvrir , puis cliquez sur OK.

    Capture d’écran de la fenêtre Exécuter avec rsop.msc tapé dans la zone Ouvrir.

  2. Dans le composant logiciel enfichable RSoP, les paramètres de signature SMB se trouvent dans le chemin suivant : Configuration ordinateur/Paramètres Windows/Paramètres de sécurité/Stratégies locales/Options de sécurité

    Note

    Si vous exécutez Windows 2000 Server, installez l’utilitaire de mise à jour de stratégie de groupe à partir du Kit de ressources Windows 2000 Server, puis tapez ce qui suit à l’invite de commandes : gpresult /scope computer /v

  3. Après avoir exécuté cette commande, la liste Des objets de stratégie de groupe appliqués s’affiche. Cette liste affiche tous les objets de stratégie de groupe appliqués au compte d’ordinateur. Vérifiez les paramètres de stratégie de signature SMB pour tous ces objets de stratégie de groupe.

Ressources supplémentaires

Ce comportement se produit si les paramètres de signature SMB pour le service station de travail et pour le service serveur se contredisent. Lorsque vous configurez le contrôleur de domaine de cette façon, le service Station de travail sur le contrôleur de domaine ne peut pas se connecter au partage Sysvol du contrôleur de domaine. Par conséquent, vous ne pouvez pas démarrer les composants logiciels enfichables de stratégie de groupe. En outre, si les stratégies de signature SMB sont définies par la stratégie de sécurité du contrôleur de domaine par défaut, le problème affecte tous les contrôleurs de domaine sur le réseau. Par conséquent, la réplication de stratégie de groupe dans le service d’annuaire Active Directory échoue et vous ne pourrez pas modifier la stratégie de groupe pour annuler ces paramètres.

Scénario 1 : si vous exécutez l’outil de diagnostic du contrôleur de domaine (DcDiag.exe), vous recevez des erreurs similaires à ce qui suit pour Windows 2000 Server et Pour Windows Server 2003

Test de démarrage : MachineAccount
Impossible d’ouvrir le canal avec [SERVERNAME] :failed with 5 : Access is denied.
Impossible d’obtenir NetBIOSDomainName
Échec du test du nom de principal du service HÔTE
Échec du test du nom de principal du service HÔTE
* SpN manquant :(null)
* SpN manquant :(null)
......................... SERVERNAME a échoué à tester MachineAccount
Test de démarrage : Services
Impossible d’ouvrir l’ipc distant sur [SERVERNAME] :échec avec 5 : l’accès est refusé.
......................... SERVERNAME a échoué, services de test
Test de démarrage : ObjectsReplicated
......................... SERVERNAME a réussi à tester ObjectsReplicated
Test de départ : frssysvol
[SERVERNAME] Une utilisation nette ou une opération LsaPolicy a échoué avec l’erreur 5, Access est refusé..
......................... SERVERNAME a échoué test frssysvol
Test de démarrage : frsevent
......................... SERVERNAME a échoué test frsevent
Test de démarrage : kccevent
Échec de l’énumération des enregistrements du journal des événements, l’accès aux erreurs est refusé.
......................... SERVERNAME a échoué test kccevent
Test de démarrage : systemlog
Échec de l’énumération des enregistrements du journal des événements, l’accès aux erreurs est refusé.
......................... SERVERNAME a échoué dans le journal système de test

Scénario 2 : si vous exécutez l’outil de diagnostic du contrôleur de domaine, vous recevez des erreurs similaires à ce qui suit pour Windows 2000 Server et Pour Windows Server 2003

Serveur de test : Default-First-Site-Name\SERVERNAME
Test de démarrage : réplications
......................... Réplications de test réussies PAR SERVERNAME
Test de départ : NCSecDesc
......................... SERVERNAME a réussi le test NCSecDesc
Test de démarrage : NetLogons
[SERVERNAME] Une opération net use ou LsaPolicy a échoué avec l’erreur 1240, le compte n’est pas autorisé à se connecter à partir de cette station..
......................... SERVERNAME a échoué test NetLogons
Test de démarrage : Publicité
......................... SERVERNAME a réussi à tester la publicité
Test de démarrage : KnowsOfRoleHolders
......................... SERVERNAME a réussi le test KnowsOfRoleHolders
Test de démarrage : RidManager
......................... SERVERNAME a réussi le test RidManager
Test de démarrage : MachineAccount
Impossible d’ouvrir le canal avec [SERVERNAME] :failed with 1240 : le compte n’est pas autorisé à se connecter à partir de cette station.
Impossible d’obtenir NetBIOSDomainName
Échec du test du nom de principal du service HÔTE
Échec du test du nom de principal du service HÔTE
* SpN manquant :(null)
* SpN manquant :(null)
......................... SERVERNAME a échoué à tester MachineAccount
Test de démarrage : Services
Impossible d’ouvrir l’ipc distant sur [SERVERNAME] :échec avec 1240 : le compte n’est pas autorisé à se connecter à partir de cette station.
......................... SERVERNAME a échoué, services de test
Test de démarrage : ObjectsReplicated
......................... SERVERNAME a réussi à tester ObjectsReplicated
Test de départ : frssysvol
[SERVERNAME] Une opération net use ou LsaPolicy a échoué avec l’erreur 1240, le compte n’est pas autorisé à se connecter à partir de cette station..
......................... SERVERNAME a échoué test frssysvol
Test de démarrage : frsevent
......................... SERVERNAME a échoué test frsevent
Test de démarrage : kccevent
Échec de l’énumération des enregistrements du journal des événements, erreur Le compte n’est pas autorisé à se connecter à partir de cette station. ......................... SERVERNAME a échoué test kccevent
Test de démarrage : systemlog
Échec de l’énumération des enregistrements du journal des événements, erreur Le compte n’est pas autorisé à se connecter à partir de cette station. ......................... SERVERNAME a échoué dans le journal système de test