¿Por qué SÓLO mi cuenta de usuario no se conecta libremente a recursos compartidos de lectura anónima?

¿Por qué SÓLO mi cuenta de usuario no se conecta libremente a recursos compartidos de lectura anónima?

Mi administrador de red y yo nos estamos volviendo locos por algunas rarezas de autenticación de Windows; ambos tenemos más experiencia en Linux, por lo que me disculpo de antemano por cualquier ignorancia en lo siguiente.

Hemos configurado recursos compartidos de archivos en Windows Server 2008 R2 con solo lectura para acceso anónimo. HacemosNOTenemos un controlador de dominio de Windows en nuestra red, por lo que estos recursos compartidos están disponibles para cualquier computadora en la red.

Tengo una cuenta en este servidor para iniciar sesión en RDP y esa cuenta tiene acceso de escritura al recurso compartido.

En otros servidores, tengo el mismo nombre de usuario (configurado localmente, ya que no tenemos un controlador de dominio). Al intentar conectarme al recurso compartido desde este servidor, se me solicita que proporcione un inicio de sesión, aunque se supone que el recurso compartido se puede leer sin iniciar sesión.

Lo que es más confuso, otra cuenta en este segundo servidor.configurado exactamente igual que el mío con la excepción del nombre de usuarioes capaz de conectarse sin problemas.

La diferencia sustancial en el comportamiento que puedo ver entre mi cuenta de usuario y otras es que cuando intento conectarme al recurso compartido (desde el menú de inicio, escribiendo \\servername\), en mi cuenta no veo los recursos compartidos disponibles "autocompletar" en la lista. , mientras que en una cuenta idéntica con un nombre diferente, sí lo hacen. Cuando escribo manualmente el nombre completo del recurso compartido e intento conectarme, aparece un cuadro de diálogo de autenticación: Ingrese la contraseña de red (para conectarse a [nombre del servidor]) con el "Dominio" de la máquina local que aparece debajo del campo de contraseña.

Para aumentar mi confusión y frustración, teníamos dos recursos compartidos como este en servidores diferentes (llámelos A y B). Estaba teniendo problemas para conectarme a B y no a A. Luego, después de eliminar mi cuenta del servidor B de haber leído/ acceso de escritura al recurso compartido B (de modo que solo quedó "lectura para todos"), pude conectarme a B exitosamente, pero luego A dejó de funcionar.

EDITAR, más información:
Hubo un punto en el que se nos solicitó activar el "descubrimiento de red" mientras trabajábamos con la configuración de recursos compartidos, pero parecía que tendría un impacto no solo en los recursos compartidos. No queremos "publicitarlos" en todos los sistemas cliente de Windows, sólo tenerlos accesibles cuando se solicite. Y después de todo, cualquier sistema antiguo normal de la red podía acceder a él sin ninguna credencial, por lo que no supongo que esto hubiera tenido un impacto favorable (si es que lo hubiera tenido).


¿Alguien ha visto alguna vez algo como esto? Lo mejor que puedo suponer es que esto sería mucho más sencillo si tuviéramos un servidor de dominio, y que esto tiene algo que ver con tener cuentas de usuario con nombres idénticos en cada servidor, bajo el propio dominio de ese servidor. Mis colegas tienen el mismo tipo de cuentas y no tienen este problema, por lo que solo puedo asumir que me falta alguna configuración de permiso/seguridad en el servidor compartido de archivos.

Respuesta1

Cuando se ejecuta como usuario local, Windows siempre intentará autenticarse en el recurso compartido remoto utilizando el nombre de usuario y la contraseña registrados, por lo que si su nombre de usuario local y su contraseña local coinciden en todos los sistemas, se le autenticará automáticamente.

Esto parece estar causando un problema en este caso, ya que su sistema intenta autenticarse utilizando el usuario y la contraseña que iniciaron sesión y obtiene un error de credencial. No estoy muy seguro de por qué esto hace que no vuelva a iniciar sesión de forma anónima, pero es casi seguro que los nombres de usuario locales coincidentes son la causa de esta extrañeza.

Y sí, esta situación sería mucho más sencilla si estuviera utilizando Active Directory.

información relacionada