O: "¿Es esto una cosa? ¿Y cómo comprobaría si lo fuera?"

En un entorno sin un controlador de dominio , cuando accedo a un recurso compartido en un cuadro de Windows Server 2008 R2, desde una computadora remota sin una cuenta de usuario coincidente en el servidor (y conectando escribiendo \\SERVERNAME\ShareNamedesde el menú Inicio) actualmente observo el siguiente comportamiento basado en la configuración "Uso compartido protegido por contraseña" (Configuración de uso compartido avanzado):

Cuando "compartido con protección por contraseña" se convirtió en , todos los intentos de conexión fallan después de un máximo de 30 segundos con:

Error de inicio de sesión: al usuario no se le ha otorgado el tipo de inicio de sesión solicitado en esta computadora.

Con "Compartir con contraseña protegida" desactivado , se permiten conexiones a recursos compartidos accesibles anónimamente, mientras que los recursos compartidos restringidos con permiso fallan con:

No tiene permiso para acceder a \ SERVERNAME \ ShareName. Póngase en contacto con su administrador de red para solicitar acceso.

Este parece ser el comportamiento esperado. Necesito tener ciertos recursos compartidos accesibles mediante inicios de sesión anónimos, por lo que tuve que cambiar esta configuración de la predeterminada a desactivada .

SIN EMBARGO, hay un tercer caso aquí. ( whaaaaat? )

Si intenta conectarse a un recurso compartido sin haber modificado este ajuste (es decir, que se establece en el pero nunca se ha hecho clic ella), la conexión se comporta similar a la de caso anterior en que se tarda hasta 30 segundos para mostrar una respuesta, pero luego muestra un diálogo de autenticación :

Tuve este presentimiento después de golpearme la cabeza contra la pared durante unos días, y solo lo repliqué en un servidor sin recursos compartidos existentes: cree un recurso compartido que no sea de lectura, intente conectarse y obtener un diálogo, cambie la configuración, conéctese con éxito, cambie la configuración atrás , y recibe un mensaje de error diferente. (Probé todo esto en sistemas de clientes nuevos para que no hubiera riesgo de almacenamiento en caché).

Para reiterar: he controlado para los sistemas del cliente. Esto parece estar completamente relacionado con el servidor.

Entonces, es claro para mí que cambiar la configuración de "Uso compartido protegido por contraseña" está cambiando más de una cosa (¿clave de registro? Soy nativo de Mac) detrás de escena, y que la configuración predeterminada con la que se entrega el sistema NO coincide. con la configuración reflejada en el panel de control (o el panel de control en sí está roto y debería estar cambiando más cosas).

Entonces la pregunta es: ¿es esto por diseño, o es un error? Y en cualquier caso, ¿cuál es la "configuración oculta" que se cambia o se deja sin cambios? ¿Cómo rastrearía eso? Me estoy quedando sin servidores nuevos para probar. :-(

Esto realmente despertó mi interés. Pude replicar sus hallazgos en mi laboratorio con el mismo patrón de resultados que usted describe. Utilicé Procmon para intentar ver qué cambios se realizan y casi me di por vencido hasta que vi lo siguiente:

Eso muestra que lsass.exe (Autoridad de seguridad local) escribe en el SAM local y realiza cambios en la cuenta de invitado integrada (conocido RID 501). Efectivamente, cuando volví a probar tu escenario mientras miraba el estado de la cuenta de invitado, lo veo habilitado cuando "Compartir con contraseña protegida" está deshabilitado. Sin embargo, cuando se vuelve a habilitar "Compartir con contraseña protegida", la cuenta de invitado no se vuelve a deshabilitar. Deshabilitar manualmente la cuenta de invitado restaura la funcionalidad original: se me solicitan las credenciales (es decir, su tercer caso).

No estoy seguro de por qué esto se comporta así. Para ser honesto, nunca antes había activado la configuración de "uso compartido protegido por contraseña" antes (ni siquiera me di cuenta, de hecho). Espero que esto ayude con tu proyecto. Si alguien más está interesado en investigar más, sería interesante saber si este comportamiento todavía está presente en el Servidor 2012/2012 R2 ...

Ah, y a sus preguntas originales (¿Es esto por diseño o es un error?), No tengo la menor idea ...

Si he entendido su pregunta correctamente, las credenciales de los recursos compartidos se guardan en el Administrador de credenciales en el panel de control.

Para abrir el cuadro de diálogo de autenticación, simplemente elimine la credencial relacionada con ese recurso compartido en el Administrador de credenciales.

Cuando marca la casilla 'Recordar mis credenciales', esto generalmente se guarda en el Administrador de credenciales y si esta contraseña es incorrecta, verá el error de falla de inicio de sesión.

Es posible que no lo ayude, pero en caso de que lo haga, a menudo recibo llamadas para que mis usuarios no puedan acceder a un recurso compartido (Windows almacena en caché su contraseña anterior) y les pido que hagan esto:

uso neto * / D