Por qué un recurso compartido de Windows funciona a veces y otras no — Acotar Kerberos, NTLM y las credenciales

«Ayer funcionaba.» «El Explorador de archivos puede abrirlo, pero la aplicación no.» «Reiniciar lo arregló.» Los problemas con recursos compartidos se vuelven más difíciles de investigar cuando los intentos parecen idénticos.

Aunque crea estar abriendo el mismo recurso compartido, Windows puede realizar operaciones distintas si difieren el nombre de destino, la cuenta de ejecución o las conexiones existentes. Encontrar esas diferencias es el punto de partida de la investigación.

Esta guía de diagnóstico reúne los comandos que ejecutar, cómo interpretar sus resultados y dónde investigar después, en lugar de asignar una causa a partir del síntoma por sí solo. Para los protocolos en sí, véase NTLM y Kerberos explicados. Para el diseño de aplicaciones, véase Unidades de red y trampas de las rutas UNC.

1. Empiece aquí: conclusión e índice de síntomas

Investigue en este orden: ¿Es alcanzable? → ¿Qué identidad se conectó? → ¿Qué requisitos de autenticación y protección se aplican? → ¿Puede esa identidad realizar la operación? Registre estas condiciones con el mismo formato para los intentos correctos y los fallidos. Un síntoma es un punto de partida, no una causa confirmada.

flowchart TB
    accTitle: Del síntoma a las pruebas
    accDescr: Seleccione candidatos a partir del síntoma, compare las pruebas de los intentos correctos y fallidos, y elija después una corrección.
    symptom["Seleccionar el síntoma"] --> compare["Comparar éxito y fallo"]
    compare --> evidence["Acotar candidatos con los registros"]
    evidence --> fix["Cambiar una cosa y volver a probar"]

Figura 1: Use los síntomas para iniciar la investigación y elija correcciones solo tras examinar las pruebas.

El ámbito son los recursos compartidos SMB 2/3 en Windows 11 y Windows Server mediante conexiones TCP 445 corrientes. Los ejemplos de PowerShell están dirigidos a Windows PowerShell 5.1. Es una guía de nivel intermedio para administración y desarrollo, pero quien no tenga acceso administrativo al servidor puede empezar igualmente recopilando información del lado del cliente.

Distinga los dominios de AD, los recursos compartidos de Windows en un grupo de trabajo y las cuentas propias de un NAS. Este artículo cubre el Kerberos de AD corriente y las configuraciones tradicionales con cuentas locales; SMB sobre QUIC, la autenticación propia de Azure Files y las configuraciones concretas de IAKerb o LocalKDC quedan fuera. Con DFS, registre también el servidor de destino final. Los ajustes y valores predeterminados se basan en documentación oficial comprobada el 8 de septiembre de 2026; la configuración real prevalece sobre las suposiciones extraídas del nombre del sistema.

Determine primero qué cuentas está configurado el recurso compartido para aceptar. AD gestiona de forma centralizada las cuentas de una organización, mientras que las cuentas locales pertenecen a PC concretos. Un NAS puede usar cuentas propias o unirse a AD. No deduzca Kerberos de una LAN corporativa ni NTLM del hecho de que el servidor sea un NAS; pregunte a la administración por la configuración de autenticación.¹²³

Que el PC pertenezca o no a un dominio y qué credenciales usó esta conexión son también preguntas distintas. En los ejemplos siguientes, CORP\alice es una cuenta de dominio, mientras que FILESRV01\alice es una cuenta local del servidor de archivos. Tener un usuario con el mismo nombre en su propio PC no le otorga necesariamente los mismos permisos en el servidor.⁴⁵

En el diagrama, una línea continua marca una relación que siempre se cumple y una línea discontinua una relación condicional (las condiciones están en la explicación de cada relación en la página de detalle). La lista completa de relaciones (19 en total, con evidencia y grado de certeza) y las definiciones de los conceptos principales están reunidas en la página de detalle del mapa de conocimiento (en japonés). Datos: JSON-LD / Turtle

2. Separe las etapas que se ocultan tras «no se puede conectar»

Abrir un archivo implica establecer la comunicación, negociar los requisitos SMB, autenticar una sesión, conectarse a un recurso compartido y realizar una operación de archivo. Una autenticación correcta no concede acceso al recurso ni al archivo. Un mensaje que dice que no se encontró la ruta de red puede asociarse incluso a un acceso de invitado rechazado. No diagnostique un fallo de DNS a partir de ese mensaje por sí solo.⁶⁷

flowchart TB
    accTitle: Etapas antes de que se abra un archivo compartido
    accDescr: Alcanzabilidad, negociación SMB, autenticación, conexión al recurso compartido y operaciones de archivo pueden fallar por separado.
    net["Resolución de nombres y TCP"] --> negotiation["Negociación de los requisitos SMB"]
    negotiation --> session["SESSION_SETUP: autenticación"]
    session --> tree["TREE_CONNECT: recurso compartido"]
    tree --> file["CREATE y otras operaciones de archivo"]

Figura 2: El éxito en una etapa no demuestra el éxito en la siguiente.

Aquí, éxito significa realizar la operación prevista sobre el archivo previsto. Ver un PC en «Red» del Explorador de archivos, ver una lista de recursos compartidos y leer un archivo concreto no son equivalentes. Registre la ruta UNC y la operación que realmente fallan, no solo si una lista es visible.

3. Recopile pruebas antes de reiniciar o cambiar ajustes

Eliminar conexiones o vales al principio borra el estado que quería comparar. Registre primero la hora, la ruta UNC, el usuario, el sistema operativo y las conexiones existentes en el cliente. Los comandos siguientes leen el estado. Al investigar un fallo en un servicio, no trate los resultados de esta terminal interactiva como resultados del propio servicio.⁴⁸⁹

Get-Date -Format o
whoami /user
whoami /groups
Get-CimInstance Win32_OperatingSystem |
    Select-Object Caption, Version, BuildNumber
net use
cmdkey /list
klist

Recopile además lo siguiente si tiene permiso para consultar las conexiones SMB. Un resultado de acceso denegado significa «no se pudo realizar la consulta», no «no hay conexiones». Etiquete con ese contexto de ejecución cualquier resultado recopilado de nuevo como administrador. Elevar en silencio toda la investigación puede cambiar la sesión de inicio que está comparando.⁴¹⁰

Get-SmbConnection | Format-List *

En Get-SmbConnection, examine Credential además de UserName. La identidad del inicio de sesión local y las credenciales usadas para la conexión al recurso pueden diferir. Comparar ServerName, ShareName, UserName y Credential entre intentos correctos y fallidos ayuda a determinar si está comparando la misma conexión.⁴

flowchart TB
    accTitle: Información guardada frente a estado activo
    accDescr: Examine por separado las credenciales guardadas, las conexiones SMB y los vales de Kerberos.
    snapshot["Capturar en el mismo momento"] --> stored["Credenciales guardadas"]
    snapshot --> connection["Conexiones SMB establecidas"]
    snapshot --> ticket["Caché de vales"]
    stored -.-> verify["Contrastar el uso real con los registros"]
    connection --> verify
    ticket -.-> verify

Figura 3: Distinga lo que está guardado de lo que la conexión investigada usó realmente.

Estas salidas contienen nombres de usuario, nombres de servidores internos, direcciones IP e información similar. Restrinja el acceso a los registros recopilados. Antes de compartirlos fuera, anonimícelos conservando las correspondencias necesarias para la comparación. No hace falta publicar contraseñas, hashes ni los vales en sí.

4. Compruebe primero la resolución de nombres y TCP 445

Lo siguiente es una prueba activa de alcanzabilidad ejecutada en el cliente. Sustituya el nombre del servidor por el nombre de conexión real. Registre por separado la resolución de nombres y la alcanzabilidad TCP.¹¹

$Server = 'filesrv01.corp.example.com'
Resolve-DnsName -Name $Server
Test-NetConnection -ComputerName $Server -Port 445 -InformationLevel Detailed

Si TcpTestSucceeded es False, investigue en ese punto la alcanzabilidad antes de la autenticación. Compruebe la IP de destino, la VPN y el enrutamiento, los cortafuegos de cliente y servidor, y el punto de escucha del servidor. Un ping correcto o fallido no es una conexión TCP 445 correcta o fallida. A la inversa, una alcanzabilidad TCP correcta deja sin verificar el nombre del recurso, la autenticación, la firma y los permisos.¹¹

flowchart TB
    accTitle: Interpretar una prueba de conexión TCP
    accDescr: Una prueba TCP 445 fallida lleva a investigar la alcanzabilidad; una correcta lleva a SMB y a las etapas posteriores.
    tcp["Probar TCP 445"] --> result{"¿Tuvo éxito?"}
    result -->|"No"| route["Comprobar destino, ruta, bloqueo"]
    result -->|"Sí"| smb["Comprobar SMB, autenticación, acceso"]

Figura 4: El éxito de TCP es prueba de que puede pasar a la siguiente etapa, no de que la autenticación haya tenido éxito.

Cuando un nombre y una dirección IP se comportan de forma distinta, compare RemoteAddress y los resultados de la resolución de nombres. Nombre corto, FQDN y alias no llegan necesariamente a la misma IP. Aunque lo hagan, los requisitos de autenticación de la sección siguiente siguen siendo aparte. Si cambiar el nombre parece arreglar el problema, registre qué cambió.

5. Compruebe los requisitos de Kerberos cuando nombre e IP difieren

5.1. La misma IP no implica la misma autenticación

De forma predeterminada, Windows no intenta Kerberos cuando el nombre de destino es una dirección IP. Pueden configurarse excepciones con TryIPSPN y SPN basados en IP, pero el enfoque de referencia de esta guía es establecer el nombre DNS y la identidad de servicio correctos. Que funcione con una dirección IP es una prueba útil para comparar resolución de nombres, autenticación y conexiones existentes; no demuestra una corrección duradera.¹²

flowchart TB
    accTitle: Los requisitos de autenticación dependen del nombre de conexión
    accDescr: Compruebe los requisitos de Kerberos ligados al nombre para destinos por nombre de host y tenga en cuenta el comportamiento predeterminado de no intentar Kerberos para destinos por dirección IP.
    unc["Notación del destino en la ruta UNC"] --> name["Nombre de host o FQDN"]
    unc --> ip["Dirección IP"]
    name --> spn["Comprobar el SPN de ese nombre"]
    ip --> fallback["Sin intento de Kerberos de forma predeterminada"]

Figura 5: Aunque dos nombres identifiquen el mismo dispositivo, cambiar el nombre de conexión cambia las condiciones de autenticación.

Kerberos solicita vales usando un identificador de servicio llamado SPN. Resolver un alias DNS y autenticar correctamente el servicio bajo ese alias son cosas distintas. Además, no todo fallo de Kerberos deriva en un repliegue a NTLM. Use los registros reales para distinguir si es posible un repliegue, si falló la autenticación y si NTLM está restringido.¹³¹

5.2. Separe la obtención del vale de su aceptación por el servidor

En un entorno de AD, la administración debe examinar el registro del SPN para el nombre usado al conectar. Las consultas de solo lectura siguientes son para una máquina de administración capaz de consultar AD. Asegúrese de disponer de las herramientas necesarias y de permisos de lectura del directorio.¹⁴

setspn -Q cifs/filesrv01.corp.example.com
setspn -Q HOST/filesrv01.corp.example.com

La ausencia de un registro explícito cifs/... no demuestra por sí sola que falte un SPN. En las cuentas de equipo, un SPN HOST puede sustituir a clases de servicio como cifs. A la inversa, encontrar un registro no descarta problemas como la pertenencia a una cuenta distinta de la cuenta de servicio real o registros duplicados. Los administradores de AD deberían verificar la pertenencia antes de modificar registros; no añada un SPN mecánicamente solo porque una consulta no devolviera nada.¹⁴

flowchart TB
    accTitle: Qué acreditan las comprobaciones de SPN y vale
    accDescr: La resolución del SPN, la obtención del vale y la aceptación por el servidor de archivos son comprobaciones distintas.
    lookup["Propietario del SPN y sustitución HOST"] --> issue["¿Puede obtenerse un vale?"]
    issue --> accept["¿Se acepta para la autenticación SMB real?"]
    accept --> logs["Contrastar con los registros del lado del servidor"]

Figura 6: Obtener un vale no garantiza que el servidor de archivos vaya a aceptarlo.

Tras conservar el estado original, puede que necesite probar klist get cifs/filesrv01.corp.example.com. Es una prueba activa que solicita un vale y modifica la caché. Si falla, investigue la alcanzabilidad del DC, la sincronización horaria, los nombres y los SPN. Si tiene éxito, el acceso SMB sigue sin estar garantizado. No aplique los resultados de vales de un usuario interactivo a un problema que se produce en un servicio.⁸¹

Para un NAS sin dominio o con autenticación mediante cuentas locales, compruebe primero los métodos de autenticación y la configuración de cuentas que admite el recurso compartido, en lugar de empezar por reparaciones de SPN en AD. Incluso en entornos con funciones de autenticación más recientes, prefiera los registros de conexión a las suposiciones basadas en nombres de producto.

6. El Explorador de archivos funciona, pero la aplicación falla

6.1. Un nombre de usuario coincidente no basta

Compare la cuenta de ejecución, la sesión de inicio, la elevación, la ruta UNC y la operación. Un servicio se ejecuta en una sesión distinta de un inicio interactivo aunque esté configurado con la misma cuenta de usuario. Las asignaciones de letra de unidad también se limitan a las sesiones de inicio, así que distinga primero Z:\data de \\server\share\data. Pasar a una ruta UNC resuelve el problema de la letra de unidad; no concede además autenticación ni permisos.¹⁰

flowchart TB
    accTitle: El Explorador de archivos y un servicio usan contextos distintos
    accDescr: Incluso en el mismo PC, compare los inicios interactivos y de servicio como sesiones distintas con sus propias credenciales.
    pc["Mismo PC"] --> explorer["Inicio interactivo"]
    pc --> service["Inicio de servicio"]
    explorer --> a["Conexiones y acceso en esa sesión"]
    service --> b["Conexiones y acceso en otra sesión"]

Figura 7: El mismo PC y el mismo nombre de usuario no comparten necesariamente el mismo estado de conexión.

Haga que la aplicación que falla registre su identificador de proceso, su identidad de ejecución, su estado de elevación, la ruta real, el nombre de la operación, la excepción original y el código de error. Si usa suplantación, capture también la identidad efectiva del subproceso que realiza la operación. No dé por cerrada una investigación sobre un servicio solo porque una sesión de PowerShell de administrador pudiera abrir el recurso compartido.

6.2. Cuentas de servicio y tipos de inicio de las tareas

Cuando un servicio usa sus credenciales predeterminadas, LocalSystem presenta en la red las credenciales del equipo, mientras que LocalService presenta credenciales anónimas. Para el acceso de LocalSystem a un recurso compartido de dominio, los permisos que cuentan pertenecen a la identidad realmente usada, como la cuenta de equipo, y no al usuario interactivo. Las implementaciones que usan credenciales explícitas o suplantación requieren sus propias comprobaciones.¹⁵¹⁶

flowchart TB
    accTitle: Privilegios locales frente a identidad remota
    accDescr: Con las credenciales de red predeterminadas, LocalSystem y LocalService presentan identidades distintas.
    service["Credenciales predeterminadas del servicio"] --> system["LocalSystem"]
    service --> local["LocalService"]
    system --> machine["Credenciales del equipo"]
    local --> anonymous["Credenciales anónimas"]

Figura 8: Unos privilegios locales amplios no convierten al servicio en el usuario interactivo del recurso compartido remoto.

En el Programador de tareas, examine el tipo de inicio además del nombre de la cuenta. TASK_LOGON_S4U no guarda contraseña y no proporciona acceso a la red ni a archivos cifrados. No suponga que una tarea configurada sin contraseña guardada tiene las mismas condiciones que un inicio interactivo normal. Configure los procesos de negocio con una cuenta de servicio adecuada, un tipo de inicio apropiado y permisos mínimos, en lugar de depender de que alguien abra primero el recurso compartido en el Explorador de archivos.¹⁷

7. Distinga cuatro sentidos de «no hace falta contraseña»

La ausencia de petición no es prueba de acceso no autenticado. Pueden estar en uso las credenciales de la sesión actual, credenciales guardadas o una sesión SMB ya establecida. Una entrada en cmdkey /list no acredita por sí sola que la conexión la usara.⁴⁹

flowchart TB
    accTitle: Qué significa la ausencia de petición de contraseña
    accDescr: No deduzca de la interfaz un acceso no autenticado; distinga credenciales, sesión existente, contraseña en blanco y acceso de invitado.
    prompt["No aparece ninguna petición de contraseña"] --> identity["Comprobar la identidad realmente aceptada"]
    identity --> authenticated["Credenciales o sesión existente"]
    identity --> blank["Cuenta con contraseña en blanco"]
    identity --> guest["Invitado"]

Figura 9: Interfaces de aspecto idéntico pueden ocultar mecanismos de autenticación distintos.

Cuando el servidor de archivos es Windows y está habilitada su directiva que limita las cuentas locales con contraseña en blanco al inicio de sesión en la consola, los inicios de sesión de red corrientes con esas cuentas quedan restringidos. Eso es distinto del ajuste que permite el acceso de invitado. Si alguien dice que un usuario con contraseña en blanco se conectó antes, compruebe primero en el servidor si esa cuenta autenticó realmente la conexión anterior. En lugar de deshabilitar la restricción como primera respuesta, valore una cuenta adecuada con contraseña para el acceso al recurso compartido.²³

Si administra el servidor de archivos Windows, ejecute lo siguiente en una sesión de PowerShell de administrador en ese servidor mientras el acceso funciona. No confunda Get-SmbConnection, que se ejecuta en el cliente, con Get-SmbSession, que se ejecuta en el servidor que acepta la conexión.¹⁸

Get-SmbSession |
    Select-Object SessionId, ClientComputerName, ClientUserName, NumOpens

Use ClientComputerName y la hora del intento para localizar la sesión pertinente, y examine después ClientUserName. Esto describe las sesiones SMB actualmente establecidas; no explica una conexión fallida anterior ni determina si se usó Kerberos o NTLM. Si el mismo cliente tiene varias sesiones, contraste también las horas de las operaciones de la aplicación y los registros propios de SMB. Si la conexión ya se cerró, pase a los registros de la sección 12.¹⁸

8. Error 1219 y fallos al cambiar de usuario

El error 1219 indica un conflicto entre varias conexiones al mismo servidor con nombres de usuario distintos. Las conexiones existentes a ese servidor importan aunque los nombres de los recursos compartidos difieran. Use primero net use y Get-SmbConnection para examinar las conexiones al servidor de destino. Antes de cambiar credenciales, identifique los archivos abiertos y las aplicaciones que usan esas conexiones.¹⁹²⁰

flowchart TB
    accTitle: Las credenciales pueden entrar en conflicto entre recursos distintos
    accDescr: Añadir desde el mismo contexto de conexión una conexión con otro usuario al mismo servidor puede generar conflicto aunque el nombre del recurso sea distinto.
    existing["Ya conectado al servidor como usuario A"] --> new["Conectarse a otro recurso como usuario B"]
    new --> conflict["Conflicto de credenciales: 1219"]
    conflict --> inspect["Examinar las conexiones existentes por servidor"]

Figura 10: Examine juntos el servidor y las credenciales, no solo el nombre del recurso compartido.

Lo siguiente cambia el estado de las conexiones. Solo después de dejar de usar el destino y obtener la aprobación sobre el impacto debería desconectar y volver a conectar la conexión concreta que identificó. Sustituya los nombres de ejemplo de servidor, recurso y cuenta. * solicita una petición de contraseña interactiva; no ponga la contraseña directamente en la línea de comandos.⁵

net use "\\filesrv01.corp.example.com\data" /delete
net use "\\filesrv01.corp.example.com\data" /user:CORP\alice * /persistent:no

Desconectar un recurso puede dejar conexiones a otros recursos o usos en el mismo servidor. Vuelva a examinar la lista y libere solo las conexiones necesarias al servidor de destino. No convierta net use * /delete ni el eludir indefinidamente los conflictos con alias y direcciones IP en la corrección de referencia. Compruebe después que la aplicación real se conecta con las credenciales previstas.

9. Cuando reiniciar lo arregla, pregunte qué cambió

Como un reinicio cambia varias condiciones, una mejora por sí sola no puede identificar una causa única. La tabla siguiente ofrece ejes de comparación, no la garantía de que una acción restablezca exactamente y solo el ámbito indicado.⁴⁸⁹

flowchart TB
    accTitle: Interpretar un apaño por reinicio que funcionó
    accDescr: Un reinicio cambia varias condiciones, de modo que la mejora por sí sola no puede identificar una causa.
    reboot["El reinicio restableció el acceso"] --> app["Estado de la aplicación"]
    reboot --> session["Estado de conexiones e inicios de sesión"]
    reboot --> network["Red y otros estados"]
    app --> evidence["Hacen falta pruebas de antes y después"]
    session --> evidence
    network --> evidence

Figura 11: Un reinicio puede restablecer el servicio sin demostrar la causa.

Considere un ejemplo hipotético en el que el intento correcto reutilizaba una conexión SMB con otra cuenta, mientras que el fallido requería una autenticación nueva. La investigación debería apuntar a las credenciales no previstas y al motivo del fallo de la nueva autenticación, no al reinicio en sí. Alinear marcas de tiempo, nombres de conexión, contextos de ejecución y cuentas aceptadas en ambos desenlaces hace concreto el siguiente paso.

Aunque reiniciar sea urgente para restablecer el servicio, conserve si es posible primero las salidas de la sección 3 y el error original. Tras reiniciar, pruebe la misma operación en la aplicación original antes de abrir el recurso en el Explorador de archivos. Las operaciones intercaladas dificultan distinguir si el reinicio restableció el acceso o si otra operación cambió las condiciones de conexión. No es una prohibición de reiniciar; es un procedimiento de registro que sirve tanto a la recuperación como al diagnóstico.

klist purge cambia el estado eliminando vales. No afecta a una conexión que no use Kerberos y puede repercutir en otros servicios de la misma sesión de inicio. Evite el «lo vacío y ya» antes de haber conservado las pruebas.⁸

10. Fallos tras actualizaciones o solo en algunos PC

10.1. No confunda firma, acceso de invitado y bloqueo de NTLM

La firma SMB protege frente a la manipulación de mensajes; es un ajuste distinto de si la autenticación usa Kerberos o NTLM. La guía específica de Microsoft sobre la firma SMB indica que Windows 11 24H2 Pro, Enterprise y Education exigen de forma predeterminada la firma entrante y saliente, mientras que Windows Server 2025 exige la saliente. Compruebe la edición y la configuración efectiva, no solo el nombre del sistema.⁷

Para Home, esa guía dice que la firma no es obligatoria, mientras que la lista de cambios de Windows 11 24H2 incluye Home entre las ediciones que la exigen de forma predeterminada. Los documentos, por tanto, difieren. En lugar de descartar la firma como irrelevante en Home, examine el equipo en cuestión con los comandos siguientes.⁷²¹

flowchart TB
    accTitle: Requisitos de protección SMB que examinar por separado
    accDescr: Los protocolos de autenticación, la firma SMB y el acceso de invitado son ajustes distintos que hay que comprobar cada uno por su cuenta.
    policy["Examinar la directiva efectiva"] --> auth["Permisos de Kerberos y NTLM"]
    policy --> signing["Requisito de firma SMB"]
    policy --> guest["Permiso de acceso de invitado"]

Figura 12: Comprobar un ajuste no acredita que se cumplan los requisitos restantes.

El acceso de invitado no admite ni la firma SMB corriente ni el cifrado. Por tanto, permitir invitados por sí solo puede no resolver el problema si sigue exigiéndose la firma. Prefiera configurar en el NAS cuentas autenticadas y la firma. No trate deshabilitar la firma o instalar SMB1 como un apaño cómodo.³

10.2. Lea la configuración real, no solo los valores predeterminados

Recopile lo siguiente en una sesión de PowerShell de administrador en el cliente. Esto lee la configuración; distíngalo de capturar el estado de conexión de un usuario interactivo.⁷²²

$config = Get-SmbClientConfiguration
$config | Format-List RequireSecuritySignature, EnableInsecureGuestLogons
if ($config.PSObject.Properties['BlockNTLM']) {
    $config | Format-List BlockNTLM
} else {
    'La propiedad BlockNTLM no está expuesta en este sistema.'
}

RequireSecuritySignature: False significa que la firma no es obligatoria; no demuestra que todas las conexiones vayan sin firmar. Si BlockNTLM no aparece en un sistema más antiguo, eso no demuestra la ausencia de otras directivas de restricción de NTLM. El bloqueo de NTLM del cliente SMB está disponible a partir de Windows 11 24H2 y Windows Server 2025, y también puede especificarse para conexiones a recursos concretos. Examine las opciones de conexión de la aplicación y las directivas de la organización además de los ajustes globales.⁷²²

flowchart TB
    accTitle: Los ajustes globales no determinan toda la conexión
    accDescr: Compruebe las directivas de la organización, las opciones de conexión y los requisitos del servidor además de los valores predeterminados del sistema.
    defaults["Valores predeterminados del sistema y la edición"] --> effective["Requisitos reales de la conexión"]
    organization["Directiva de la organización y opciones de conexión"] --> effective
    server["Capacidades y requisitos del servidor"] --> effective
    effective --> log["Buscar en los registros el motivo del rechazo"]

Figura 13: Que coincida en el tiempo con una actualización es una pista; concluya a partir de los ajustes efectivos y los registros de rechazo.

La retirada de NTLM, la eliminación de NTLMv1 y una directiva que rechaza NTLM no son el mismo asunto. Para la migración de protocolos y la auditoría a escala de organización, véase Auditoría y migración para la retirada de NTLM. Aquí, céntrese en el requisito que rechazó esta conexión.

11. La autenticación funciona, pero abrir o guardar falla

Para un recurso compartido de Windows, compruebe tanto los permisos del recurso como los de las carpetas y archivos subyacentes. Ambos deben permitir la misma operación a la misma identidad. Examine pertenencias a grupos, entradas de denegación y herencia; añadir Todos no significa que todo acceso deba funcionar. Compruebe el acceso efectivo usando la ruta de almacenamiento real en el servidor y la identidad que el servidor aceptó realmente.²³

flowchart TB
    accTitle: La autenticación es distinta de la autorización
    accDescr: Incluso tras una autenticación correcta, los permisos del recurso y del archivo deben permitir ambos la operación solicitada.
    identity["Identidad autenticada"] --> share["Permisos del recurso compartido"]
    share --> file["Permisos del archivo subyacente"]
    file --> operation["Realizar la operación prevista"]

Figura 14: Establecer la identidad y decidir qué puede hacer esa identidad son pasos distintos.

Enumerar una carpeta, leer un archivo, crear, sobrescribir, cambiar el nombre y eliminar son operaciones distintas. Para una aplicación que guarda creando un archivo temporal y sustituyendo el original, una lectura correcta no basta. Más allá de la autenticación y los permisos, investigue con el error original las infracciones de uso compartido, la capacidad, las rutas o los archivos desaparecidos.²⁴

File.Exists de .NET también devuelve false ante condiciones como permisos insuficientes. Compruebe si el mensaje «el archivo no existe» de la aplicación se basa únicamente en ese valor devuelto. El código de diagnóstico debería registrar las excepciones de la operación que realmente necesita realizar.²⁵

$Path = '\\filesrv01.corp.example.com\data\sample.txt'
try {
    Get-Item -LiteralPath $Path -ErrorAction Stop |
        Select-Object FullName, Length, LastWriteTime
} catch {
    $_.Exception.GetType().FullName
    'HRESULT=0x{0:X8}' -f $_.Exception.HResult
    $_.Exception.Message
}

Esto comprueba la obtención de metadatos, no la lectura o escritura correcta del contenido. Para probar la E/S real, reproduzca la operación prevista en un archivo de prueba tras verificar la autorización y el impacto. Conservar los errores en lugar de convertirlos todos en «archivo no encontrado» facilita además la siguiente investigación.

12. Contraste los registros para acotar la causa

12.1. Distinga el cliente, el servidor de archivos y el DC

En el cliente, examine Microsoft-Windows-SMBClient/Connectivity y Microsoft-Windows-SMBClient/Security en el Visor de eventos. En un servidor de archivos Windows, los eventos de seguridad 4624 para inicio correcto y 4625 para inicio fallido ayudan cuando la auditoría está habilitada. Para los inicios de sesión de red SMB, compruebe el tipo de inicio 3. En un NAS, use sus registros de autenticación y de recursos compartidos propios del producto.²⁶²⁷²⁸

El tipo de inicio 3 del evento 4624 no es específico de SMB. Aunque coincidan la hora, el origen y la cuenta, el evento por sí solo no identifica un recurso compartido ni una sesión SMB. Contrástelo con Get-SmbConnection, los registros propios de SMB y, si hace falta, un seguimiento.²⁷⁴²⁶

flowchart TB
    accTitle: Contrastar registros de tres ubicaciones
    accDescr: Contraste los registros del cliente, del servidor de archivos y, si hace falta, del DC usando la hora y la información de conexión.
    client["Cliente: registros de SMBClient"] --> match["Hacer coincidir hora, origen y cuenta"]
    server["Servidor de archivos: registros de autenticación"] --> match
    dc["DC: vales y validación de credenciales"] --> match
    match --> result["Leerlos como prueba del mismo intento"]

Figura 15: Sin coincidencia de ubicación y hora, puede tomar los registros de una conexión ajena por la causa.

Ejecute lo siguiente en el servidor de archivos Windows, con permiso para leer el registro de Seguridad. Anote la hora inmediatamente anterior al intento investigado y pida a la administración que confirme que la auditoría de aciertos y fallos necesaria está habilitada. Este ejemplo extrae los últimos diez minutos y usa nombres de campo XML en lugar de textos de mensaje localizados o posiciones de campo.²⁷²⁸

$Start = (Get-Date).AddMinutes(-10)
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'; Id = 4624, 4625; StartTime = $Start
} -ErrorAction Stop | ForEach-Object {
    $event = $_
    $xml = [xml]$event.ToXml()
    $fields = @{}
    foreach ($item in $xml.Event.EventData.Data) {
        $fields[$item.Name] = [string]$item.'#text'
    }
    if ($fields['LogonType'] -eq '3') {
        [pscustomobject]@{
            Time = $event.TimeCreated
            EventId = $event.Id
            User = $fields['TargetUserName']
            Domain = $fields['TargetDomainName']
            SourceIp = $fields['IpAddress']
            Authentication = $fields['AuthenticationPackageName']
            Status = $fields['Status']
            SubStatus = $fields['SubStatus']
            LogonId = $fields['TargetLogonId']
        }
    }
} | Format-List

En 4624, lea la cuenta de destino del nuevo inicio de sesión, no el Subject que notificó el evento. En 4625, el nombre de usuario de destino es el nombre que se intentó, no una identidad aceptada. Lea Status y SubStatus juntos como motivo del fallo. Si AuthenticationPackageName solo indica Negotiate, eso por sí solo no acredita si se usó Kerberos o NTLM.²⁷²⁸

12.2. Cuando no hay registros, o solo un vale

No encontrar ningún evento no demuestra que no se produjera autenticación. Compruebe la auditoría, los permisos de lectura, las diferencias de reloj, si está examinando el servidor correcto, la reutilización de una sesión existente y un fallo previo a la autenticación. Reutilizar una conexión SMB existente no genera un nuevo 4624 cada vez que se abre un archivo.²⁷⁴

flowchart TB
    accTitle: Interpretar eventos de registro ausentes
    accDescr: Cuando falta un evento, compruebe las condiciones de recogida y las sesiones existentes en lugar de concluir de inmediato que no hubo autenticación.
    absent["Ningún evento coincidente"] --> collection["Auditoría, permisos, hora, destino"]
    absent --> reuse["Reutilización de una sesión existente"]
    absent --> before["Fallo previo a la autenticación"]

Figura 16: Un registro ausente no equivale a una operación que nunca se produjo.

En entornos de AD, el evento 4769 del DC ayuda a identificar las solicitudes de vales de servicio de Kerberos, mientras que 4776 ayuda a identificar la validación de credenciales NTLM. La emisión de un vale por sí sola no demuestra su uso ni su aceptación por el servidor de archivos, y 4776 por sí solo no identifica SMB como servicio de destino. Combine hora, origen, cuenta de destino y registros del lado del servidor. Si queda ambigüedad, haga que un administrador recoja un seguimiento de alcance reducido.²⁹³⁰

13. Verifique el funcionamiento fiable tras la corrección

Aplique una corrección cada vez y conserve el motivo y las pruebas de antes y después. Si el nombre era incorrecto, corrija el nombre y el destino. Si las credenciales diferían, unifique en la cuenta prevista. Si la firma no estaba admitida, aborde su compatibilidad en el servidor. Deshabilitar a la vez funciones de protección sin entender la causa no es un diseño para un funcionamiento fiable.

flowchart TB
    accTitle: De un intento correcto a la prueba de recurrencia
    accDescr: Tras realizar un cambio, vuelva a probar las condiciones de fallo originales y las condiciones de reconexión.
    evidence["Pruebas que identifican la causa"] --> change["Una corrección dirigida"]
    change --> original["Probar la aplicación y la operación originales"]
    original --> reconnect["Volver a probar tras reconectar o reiniciar"]
    reconnect --> record["Registrar diferencias y resultados"]

Figura 17: Verifique el éxito en las condiciones de fallo originales, no solo un intento correcto en el Explorador de archivos.

Este artículo no puede identificar de forma unívoca la causa en toda implementación y configuración de red. Aun así, saber qué etapa falló, qué condiciones diferían del éxito y qué queda sin verificar hace concreta la siguiente investigación. No se quede en «reiniciar lo arregla». Verifique que la identidad prevista se conecta por la ruta prevista.

Enlaces de referencia

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

Si reiniciar restablece el acceso a un recurso compartido, ¿demuestra eso que la causa fue una caché?

No. Un reinicio cambia a la vez la aplicación, las sesiones de inicio, las conexiones SMB, el estado de la red y otras condiciones. Antes de reiniciar, registre el destino, la identidad de ejecución, las conexiones existentes, los vales y los errores, y compárelos después con un intento correcto. Las credenciales guardadas y las conexiones SMB establecidas son cosas distintas.

¿Por qué puedo abrir un recurso compartido por dirección IP pero no por nombre de servidor?

Compruebe primero si ambas formas llegan a la misma dirección IP de destino. Aun así, sus condiciones de autenticación difieren: Windows no intenta Kerberos de forma predeterminada para un destino expresado como dirección IP. Investigue la resolución de nombres por separado de los SPN y la autenticación. Que funcione con una dirección IP no es por sí solo una corrección duradera.

¿Por qué el Explorador de archivos accede a un recurso al que mi aplicación no llega?

La cuenta de ejecución, la sesión de inicio, la elevación, las credenciales o la operación solicitada pueden diferir. Un servicio se ejecuta en una sesión distinta de un inicio interactivo. Que los nombres de usuario coincidan no acredita condiciones equivalentes: examine el propio proceso que falla y los registros de autenticación del lado del servidor.

¿Conectarse sin que se pida contraseña significa que la conexión usa acceso de invitado?

La ausencia de petición no basta para saberlo. La conexión puede usar las credenciales de la sesión actual, credenciales guardadas o una conexión SMB existente. Una cuenta local con contraseña en blanco y una conexión de invitado también son cosas distintas. Compruebe qué cuenta aceptó realmente el servidor.

Si klist muestra un vale cifs, ¿está SMB conectado mediante Kerberos?

Tener un vale y usarlo para la conexión SMB que se investiga son hechos distintos. Contraste los registros del lado del servidor con la hora de conexión, el origen y la cuenta. klist get solicita un vale; no es una observación pasiva del estado original.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.