![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(80, 34%, 17%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EFJ%3C/text%3E%3C/svg%3E)
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(284.8, 33%, 37%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDV%3C/text%3E%3C/svg%3E)
Buenas tardes,
El error 86 en Windows al acceder a recursos compartidos con credenciales locales suele indicar un fallo en el subsistema de autenticación NTLM, más que un problema con la contraseña en sí. Dado que has confirmado que las credenciales son correctas y funcionan desde otros clientes, el origen está en la pila de autenticación del cliente afectado.
Lo primero que recomiendo es verificar si el cliente está intentando forzar Kerberos en lugar de NTLM. Como el servidor de ficheros no está unido al dominio, el acceso debe resolverse con NTLM. En algunos equipos, políticas locales o de dominio pueden haber modificado el parámetro Network security: LAN Manager authentication level en secpol.msc (Ruta: Configuración de seguridad > Políticas locales > Opciones de seguridad). Si está configurado en “Enviar solo NTLMv2 respuesta” y el servidor no lo soporta correctamente, se produce el error 86. Ajustarlo a “Enviar LM y NTLM – usar NTLMv2 si es negociado” suele resolverlo.
Otra comprobación crítica es el almacenamiento de credenciales en el cliente. Aunque hayas eliminado entradas en el Administrador de credenciales, conviene revisar directamente el registro en HKCU\Software\Microsoft\Windows\CurrentVersion\Credentials y en HKLM\Security\Cache. Entradas corruptas pueden provocar rechazos sistemáticos.
Si el problema persiste, puedes forzar el cliente a usar NTLM limpiando la caché de autenticación y reiniciando el subsistema. Ejecuta en el cliente: klist purge para limpiar tickets Kerberos (aunque no debería aplicarse en este escenario, evita intentos fallidos). Después reinicia el servicio Workstation (LanmanWorkstation) con net stop workstation && net start workstation. Esto reinicia el proveedor de autenticación de red sin necesidad de reiniciar el equipo.
Para diagnóstico más detallado, habilita auditoría de inicio de sesión en el cliente: en secpol.msc activa “Auditar eventos de inicio de sesión” en éxito y error. Luego revisa el visor de eventos en Seguridad (Event ID 4625) para ver el motivo exacto del rechazo. El campo “Failure Information” te dirá si se trata de un problema de tipo de autenticación, formato de usuario (ej. SERVER\usuario vs usuario@SERVER), o si el subsistema está rechazando por política.
En resumen, el procedimiento recomendado para “resetear” el subsistema de autenticación es limpiar credenciales, purgar tickets, reiniciar el servicio Workstation y revisar la política de LAN Manager. Si tras esto el error persiste, el visor de eventos te dará la pista exacta de por qué ese cliente rechaza credenciales válidas mientras otros no.
Espero que hayas encontrado algo útil aquí. Si te ayuda a comprender mejor el problema, te agradecería que aceptaras la respuesta. Si tienes más preguntas, no dudes en dejar un mensaje. ¡Que tengas un buen día!
Domic Vo.