O: "¿Existe esto? ¿Y cómo comprobaría si lo fuera?"
en un ambientesin controlador de dominio, al acceder a un recurso compartido en un cuadro de Windows Server 2008 R2,desde una computadora remotasin una cuenta de usuario coincidente en el servidor, (y conectándome escribiendo \\SERVERNAME\ShareNamedesde el menú Inicio) Actualmente observo el siguiente comportamiento según la configuración "Compartir protegido con contraseña" (Configuración avanzada de uso compartido):
Cuando se activa "Compartir protegido con contraseña"en, todos los intentos de conexión fallan después de hasta 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 protegido por contraseña" activadoapagado, se permiten conexiones a recursos compartidos accesibles de forma anónima, mientras que los recursos compartidos con permisos restringidos 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 que ciertos recursos compartidos sean accesibles mediante inicios de sesión anónimos, así que tuve que cambiar esta configuración del valor predeterminado aapagado.
SIN EMBARGO,Hay un tercer caso aquí.(¿qué?)
Si intenta conectarse a un recurso compartidosin haber modificado esta configuración(es decir, está configurado enenpero nunca has hecho clic en él), la conexión se comporta de manera similar a laencaso anterior en el que se necesitan hasta 30 segundos para mostrar una respuesta,pero luego muestra un cuadro de diálogo de autenticación:
Tuve esta corazonada después de golpearme la cabeza contra la pared durante unos días, y simplemente lo repliqué en un servidor sin recursos compartidos existentes: crear un recurso compartido sin lectura, intentar conectarme y obtener un diálogo, cambiar la configuración, conectarme correctamente, cambiar la configuración.atrásy recibirá un mensaje de error diferente. (Probé todo esto en sistemas cliente nuevos para que no hubiera riesgo de almacenamiento en caché).
Para reiterar: he controlado los sistemas del cliente. Esto parece estar completamente relacionado con el servidor.
Entonces, para mí está claro que cambiar la configuración "Compartir protegido con contraseña" está cambiando más de una cosa (¿clave de registro? Soy nativo de Mac) detrás de escena, y que las configuraciones predeterminadas con las que se envía el sistema NO coinciden todas. 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 se podría rastrear eso? Me estoy quedando sin servidores nuevos para realizar pruebas. :-(
Respuesta1
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 su escenario mientras observaba el estado de la cuenta de Invitado, lo veo habilitado cuando "Compartir protegido con contraseña" está deshabilitado. Sin embargo, cuando se vuelve a habilitar "Compartir protegido con contraseña", la cuenta de invitado no se vuelve a deshabilitar. Desactivar 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 de hoy había activado la configuración "Compartir protegido con contraseña" (ni siquiera me había dado cuenta). Espero que esto ayude con tu proyecto. Si alguien más está interesado en profundizar más, sería interesante saber si este comportamiento todavía está presente en Server 2012/2012 R2...
Ah, y a tus preguntas originales (¿Es esto por diseño o es un error?), No tengo la menor idea...
Respuesta2
Si entendí su pregunta correctamente, las credenciales de los recursos compartidos se guardan en el Administrador de credenciales en el panel de control.
Para que aparezca el cuadro de diálogo de autenticación, simplemente elimine la credencial relacionada con ese recurso compartido en el Administrador de credenciales.
Cuando marca 'Recordar mis credenciales', esto generalmente se guarda en el Administrador de credenciales y, si esta contraseña era incorrecta, verá el error de falla de inicio de sesión.
Respuesta3
Puede que no le ayude, pero en caso de que lo haga, a menudo recibo llamadas de que mis usuarios no pueden acceder a un recurso compartido (Windows almacena en caché su contraseña anterior) y les pido que hagan esto:
uso neto * /D