14 votos

¿Cómo he conseguido que este recurso compartido de Windows solicite el inicio de sesión?

O: "¿Esto es una cosa? ¿Y cómo puedo comprobar si lo es?"

En un entorno sin un controlador de dominio Cuando se accede a un recurso compartido en un equipo Windows Server 2008 R2, desde un ordenador remoto sin una cuenta de usuario coincidente en el servidor (y conectarse escribiendo \\SERVERNAME\ShareName desde el menú Inicio) actualmente observo el siguiente comportamiento basado en la configuración de "Compartir con contraseña" (Configuración avanzada de compartir):

Si se activa la opción de compartir con contraseña en Todos los intentos de conexión fallan después de 30 segundos con:

Fallo de inicio de sesión: al usuario no se le ha concedido el tipo de inicio de sesión solicitado en este ordenador.

Con la opción "Compartir con contraseña" activada fuera de Las conexiones a recursos compartidos de acceso anónimo están permitidas, mientras que los recursos con permisos restringidos fallan:

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

Esto parece ser un comportamiento esperado. Necesito que ciertos recursos compartidos sean accesibles por inicios de sesión anónimos, así que tuve que cambiar esta configuración de la predeterminada a fuera de .

SIN EMBARGO, hay un tercer caso aquí. ( ¿Qué? )

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

Share Authentication Dialog

Tuve esta corazonada después de golpearme la cabeza contra la pared durante unos días, y acabo de replicar esto en un servidor sin acciones existentes: Crear un recurso compartido anon-read, intentar conectar y obtener un diálogo, cambiar la configuración, conectar con éxito, cambiar la configuración volver y obtener un mensaje de error diferente. (Probado todo esto en sistemas de clientes frescos, por lo que no había riesgo de caché).

Para reiterar: He controlado los sistemas de los clientes. Esto parece estar totalmente relacionado con el servidor.

Por lo tanto, me queda claro que el cambio de la configuración de "Uso compartido protegido por contraseña" está cambiando más de una cosa (¿clave del registro? Soy Mac-nativo) entre bastidores, y que las configuraciones por defecto con las que viene el sistema NO coinciden con la configuración reflejada en el panel de control (o el propio panel de control está roto y debería estar cambiando más cosas).

Así que 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 está cambiando o dejando sin modificar? ¿Cómo se puede averiguar eso? Me estoy quedando sin servidores nuevos en los que hacer pruebas :-(

0 votos

¿Cuál es la ACL de la carpeta y cuál es el permiso del recurso compartido?

0 votos

Puede utilizar un proyecto llamado regshot para comparar dos instantáneas del registro (una cuando se inicializa el sistema, otra después de establecer la configuración y una tercera después de deshacer la configuración). También eche un vistazo a la configuración de la "política de seguridad/dominio local" y compruebe la configuración de "Acceso a este equipo desde la red" (también conocida como SeNetworkLogonRight ). Aquí está algunas informaciones sobre los cambios y aquí hay algo de información sobre la configuración .

0 votos

@NReilingh: publicaste la recompensa, ¿pudiste resolverla?

11voto

David Puntos 471

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 tratar de ver qué cambios se hacen y casi me di por vencido hasta que vi lo siguiente:

procmon guest account modified

Eso muestra a lsass.exe (Local Security Authority) escribiendo en el SAM local y haciendo un cambio(s) en la cuenta de Invitado incorporada (RID 501 bien conocido). Efectivamente, cuando volví a probar su escenario mientras observaba el estado de la cuenta de Invitado, veo que está habilitada cuando "Uso compartido con protección de contraseña" está deshabilitado. Sin embargo, cuando se vuelve a habilitar el "Uso compartido con protección de contraseña", la cuenta de invitado no se vuelve a deshabilitar. Al desactivar manualmente la cuenta de invitado se restablece la funcionalidad original: Se me piden las credenciales (es decir, su tercer caso).

No sé por qué se comporta así. Para ser honesto, nunca había activado la configuración de "Compartir con contraseña" antes de hoy (o incluso lo había notado). Espero que esto ayude a tu proyecto. Si alguien más está interesado en profundizar, sería interesante saber si este comportamiento sigue presente en Server 2012/2012 R2...

Ah, y en cuanto a tus preguntas originales (¿Esto es por diseño o es un error?), no tengo la menor idea...

0 votos

Puedo confirmar que esto es correcto. Tuve que instalar un servidor W2K8 fresco hoy mismo y pude replicar esto antes de unirlo al dominio. La cuenta de invitado tiene que ser desactivada manualmente. Si se hace eso, el comportamiento es lo que yo consideraría normal: Después de un tiempo de espera se le pide al usuario que proporcione las credenciales correctas (desde la perspectiva del servidor). (PD: Nunca he entendido por qué ese maldito tiempo de espera es tan largo. No es como si las credenciales originales fueran a ser mágicamente válidas durante el periodo de tiempo de espera. Así que, ¿por qué molestarse en esperar?)

2voto

Cold T Puntos 1879

Si he entendido bien tu pregunta, las credenciales de las acciones se guardan en el Gestor de Credenciales del panel de control.

Para que aparezca el cuadro de diálogo de autenticación, basta con eliminar la credencial relativa a ese recurso compartido en el Administrador de credenciales.

Al marcar la opción "Recordar mis credenciales", ésta suele guardarse en el Gestor de credenciales y si esta contraseña fuera incorrecta, vería el error de fallo de inicio de sesión.

0 votos

No es así; he probado los tres casos en un sistema cliente fresco sin credenciales en caché. (Y en este caso, cualquier credencial que hubiera introducido habría permitido el acceso). La única vez que he siempre visto este diálogo de autenticación es cuando no se ha tocado la opción "Compartir con contraseña".

0 votos

Tenía el problema contrario (aquí: serverfault.com/q/619027/175650 ) donde recibía el aviso pero no lo quería. Resultó que tenía una credencial mal guardada, y tu post me indicó la dirección correcta para borrarla y resolver mi problema. Gracias.

0voto

ETL Puntos 3418

Puede que no te ayude, pero en caso de que lo haga - a menudo tengo llamadas en las que mis usuarios no pueden acceder a un recurso compartido (su antigua contraseña está almacenada en la caché de Windows) y les hago hacer esto:

uso neto * /D

0 votos

Como dije en la pregunta, controlé para el cliente. Utilicé un sistema fresco para cada prueba, por lo que no había riesgo de caché de credenciales.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: