Accès anonyme au partage SMB hébergé sur Server 2008 R2 Enterprise


13

Tout d'abord, j'ai lu ce post et toute une série de messages non SF qui semblent résoudre le même problème ou un problème similaire, mais je n'ai toujours pas pu résoudre mon problème.

J'ai trois machines dans cette situation:

  • un serveur joint à un domaine qui exécute Server 2008 R2 Enterprise («serveur de partage»)
  • un serveur de test non joint au domaine exécutant Server 2003 R2 SP2 ("serveur de test")
  • un poste de travail joint à un domaine exécutant XP Pro SP3 ("poste de travail")

Le serveur de partage expose un partage sur le réseau auquel le serveur de test doit accéder - c'est un partage Source / Symbol Server à des fins de débogage. Je pense que Visual Studio accède simplement au partage avec ses propres informations d'identification dans ce cas, ce qui signifie que le partage doit être accessible de manière anonyme car le serveur de test n'est pas joint au domaine et il n'y a aucune possibilité de fournir une authentification de domaine.

J'ai essayé beaucoup de choses pour éviter la fenêtre d'authentification lors de l'accès au partage:

  • J'ai activé le compte Invité sur le serveur de partage et donné des autorisations de partage complet / NTFS Invité pour le partage.
  • J'ai accordé à ANONYMOUS LOGON des autorisations de partage / NTFS complet pour le partage.
  • J'ai ajouté mon partage à «Accès réseau: partages accessibles de manière anonyme» dans LSP.
  • J'ai désactivé «Accès réseau: restreindre l'accès anonyme aux canaux et partages nommés» dans LSP.
  • J'ai activé «Accès réseau: laissez les autorisations de tout le monde s'appliquer aux utilisateurs anonymes» dans LSP.
  • LOGON ANONYME ajouté pour "Accéder à cet ordinateur depuis le réseau" dans LSP.
  • Ajout du compte Invité pour «Accéder à cet ordinateur depuis le réseau» dans LSP.
  • Vous avez tenté de provisionner le partage à l'aide du composant logiciel enfichable MMC de gestion du partage et du stockage.

Malheureusement, lorsque j'essaie d'accéder au partage à partir du serveur de test, je vois toujours l'invite et je suis obligé d'entrer manuellement "Invité".

J'ai également essayé ce flux de travail en utilisant le compte d'administrateur local sur un poste de travail, et la même chose se produit avec et sans le partage de fichiers simple XP activé.

Une idée pourquoi j'obtiens ces résultats, ou ce que j'aurais dû faire différemment?


Je pense que vous avez changé de "serveur de test" et de "poste de travail" dans la liste des machines, ou ne suis-je simplement pas en train de suivre cela?
charlesbridge

J'ai effectué ce type de procédure plusieurs fois. Je n'ai pas certaines de tes étapes. La seule chose que je peux penser de manquer est de donner à tout le monde l'accès au système de partage et de fichiers. Est ce que ça aide?
Jeremy

juste par curiosité, l'utilisation d'un système d'exploitation plus récent (par exemple Windows 7 ou Windows Server 2008) change-t-elle quoi que ce soit dans ce scénario de partage de groupe de travail par opposition à partage de domaine? Il me semble que le serveur Win2k3 est sacrément vieux et que c'est peut-être un problème de prise de contact.
Jeff Atwood

Vous devrez peut-être rétrograder les paramètres NTLMv3 / Kerberos à LM .. Je ne me souviens pas et je n'en ai pas sous la main.
Grizly

Avez-vous été invité à vous connecter au lecteur de partage caché C $?
danno

Réponses:


4

Vous avez tout fait correctement, à l'exception du compte local qui ne peut pas accéder au partage sur les deux systèmes. Essentiellement, si le compte hors domaine exécutant votre application est appelé "administrateur", vous ne devez pas avoir de compte local sur le serveur de domaine nommé "administrateur".


2

Si le nom d'utilisateur avec lequel vous vous connectez existe sur le serveur mais a un mot de passe différent, il vous demandera toujours le mot de passe, quels que soient les paramètres d'invité et anonymes que vous avez créés.

Essayez de vous connecter avec un nom d'utilisateur qui n'existe nulle part sur le serveur ou son domaine.

L'autre option est de rendre le mot de passe sur le serveur autonome exactement le même que sur l'utilisateur nommé identique sur le domaine.


1
C'est un bon point en fait. Les informations d'identification de l'invité (et non le mot de passe en tant que tel) existeront sur le serveur de test et seront transmises au serveur de partage, qui échouera comme étant faux, c'est l'inverse.
Grizly

1

Que diriez-vous de mapper un lecteur réseau et d'utiliser une syntaxe de connexion persistante serait quelque chose comme ça.

net use H: \ path \ to \ server \ PASSWORD_CLEAR_TXT / user: domain \ user / persistent: oui

si à tout moment vous voulez le supprimer, utilisez net h: / delete


Cela nécessite un utilisateur connecté qui n'est pas toujours disponible.
NotMe

Non, il nécessite un script et une entrée de registre dans \ HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ Run ou RunOnce
Grizly

1

Solution de contournement temporaire possible. Vous pouvez créer un compte d'utilisateur local (une autorisation de partage \ ntfs) sur le "serveur de partage" avec le même nom et mot de passe que le compte utilisé sur votre "serveur de test" pour exécuter l'application accédant aux partages.


0

Je ne vois pas que vous avez ajouté TOUT LE MONDE aux autorisations de partage / sécurité réseau, l'invité (une fois activé) devrait être inclus dans ce groupe. Comme décrit ici .

Aussi quelques bonnes réponses ici , relatives à des questions similaires (2003).


3
Si je comprends bien, le groupe Tout le monde ne s'applique pas à ce scénario car la signification de Tout le monde est "tout utilisateur authentifié", c'est-à-dire que Tout le monde exclut explicitement la CONNEXION ANONYME par défaut. Même pour des raisons de sécurité, j'ai activé le paramètre "Autoriser tout le monde à s'appliquer aux utilisateurs anonymes".
bwerks


0

Avez-vous essayé d'ajouter explicitement le compte d'ordinateur, c.-à-d. Nomordinateur $ pour avoir des autorisations sur le partage et via NTFS? De toute évidence, cela ne fonctionnerait pas avec des machines non liées à un domaine.


0

Cela va toujours vous inviter jusqu'à ce que vous fassiez l'une des deux choses. Les deux accomplissent la même tâche de mise en cache des informations d'identification (qui, ironiquement, dans ce cas n'ont pas d'importance mais doivent encore être présentes).

L'une consiste à mapper le lecteur et à rendre le mappage persistant. L'autre consiste à ouvrir directement le gestionnaire d'informations d'identification et à ajouter une connexion (toute connexion) au serveur auquel vous vous connectez. Credential Manager est accessible à partir de l'élément du panneau de configuration des utilisateurs ou directement dans "Panneau de configuration \ Tous les éléments du panneau de configuration \ Credential Manager".

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.