Compartición de impresoras rota tras una actualización: explicación del endurecimiento de SMB

febrero 16, 2026 • febrero 16, 2026 • Lectura: 29 min • Views: 0

¿Te fue útil?

Tus usuarios no cambiaron nada. Lo aseguran. Sin embargo, en el momento en que llegó una actualización, todas las conexiones “\\PRINT01\HP-Laser” empezaron a fallar con Acceso denegado, 0x0000011b, o el clásico eterno: “Windows no puede conectarse a la impresora.” Mientras tanto la impresora USB local imprime bien, porque claro que lo hace.

Así es como se ve el endurecimiento de seguridad en la vida real: flujos de trabajo legítimos que dependen de comportamientos antiguos de SMB y de impresión se ven expulsados de la carretera. La solución raramente es “revertir la actualización”. La solución es entender qué cambió, demostrar dónde ocurre la falla y ajustar la configuración para conservar las mejoras de seguridad sin sacrificar la impresión como especie.

Qué cambió: las medidas de endurecimiento que rompen la compartición de impresoras

“Compartir impresoras” suena como una función amistosa de oficina. En la práctica es una cadena de protocolos y suposiciones de confianza:

Los clientes descubren una impresora compartida vía ruta SMB/UNC o mediante despliegue en directorio/GPO.
El cliente habla con el spooler del servidor de impresión (RPC) para enumerar impresoras, drivers y ajustes.
Si no está instalado un controlador, el cliente puede descargarlo desde el servidor (Point and Print) o requerir paquetes aprobados por admin.
El trabajo de impresión en sí puede fluir por RPC, SMB o por un port monitor hacia la impresora real.

Las actualizaciones endurecen los bordes de esa cadena, a menudo de formas que son correctas desde el punto de vista de seguridad y desastrosas desde el punto de vista “por qué no imprime”. La rotura típica tras una actualización se concentra alrededor de estos cambios:

1) Endurecimiento del Print Spooler: restricciones de Point and Print, instalación de drivers y avisos de elevación

Muchos entornos históricamente confiaron en que los usuarios pudieran conectarse a una impresora compartida y que el driver apareciera como por arte de magia. Esa “magia” era una acción privilegiada con una larga historia de abuso. Endurecer suele significar:

Los clientes se niegan a instalar o actualizar drivers de impresora desde un servidor a menos que ese servidor sea explícitamente confiable.
Los clientes requieren elevación para instalar drivers, incluso para drivers “empaquetados”, según la política y el nivel de parche.
Los usuarios no administradores ven avisos que no pueden aprobar, lo que parece una compartición de impresora rota.

Traducción: tu impresión dependía de la instalación silenciosa de drivers. El endurecimiento quita lo “silencioso”.

2) Endurecimiento de SMB: firma, cifrado, acceso invitado y dialectos antiguos

SMB no es solo para compartir archivos. Los recursos compartidos de impresoras frecuentemente se exponen vía SMB, y el subsistema de impresión puede obtener drivers y ajustes a través de recursos SMB en el servidor de impresión.

El endurecimiento común incluye:

Firma SMB requerida en servidores o clientes. Si la otra parte no puede o no quiere firmar, la autenticación puede funcionar pero la sesión falla—o ni siquiera se inicia.
Acceso invitado de SMB deshabilitado. Las antiguas comparticiones de impresoras a veces dependen de permisos “Everyone” más fallback a invitado, especialmente en entornos mixtos o en grupos de trabajo.
SMB1 deshabilitado. Sigue ocurriendo. Algunos dispositivos de impresión antiguos y “servidores de impresión” basados en NAS solo hablan SMB1 para el recurso de drivers o para atajos de resolución de nombres.
Restricciones NTLM. Kerberos es preferido, y en algunas organizaciones NTLM está bloqueado o fuertemente auditado. Imprimir por RPC tiene muchas formas de retroceder a NTLM si los SPN, DNS o la sincronización de tiempo no están perfectos.

3) Endurecimiento de RPC: autenticación más estricta y requisitos de “privacidad”

La impresión en Windows usa RPC. El endurecimiento puede exigir autenticación más fuerte en las llamadas RPC al spooler y rechazar conexiones que antes funcionaban con clientes antiguos, servidores legacy o políticas mal configuradas. Algunos de los famosos errores de “se rompió la impresión” aparecen precisamente porque la negociación RPC cambió.

4) Desajuste de tipo de driver: comprobaciones de realidad Type 3 vs Type 4

Los drivers Type 4 iban a facilitar la vida. En la práctica, muchas flotas son un museo de drivers Type 3, paquetes de proveedores y archivos INF de “funciona en mi máquina”. El endurecimiento más la inconsistencia de drivers pueden provocar que los clientes rechacen el driver, bloqueen la descarga o instalen algo incorrecto.

Consejo con criterio: deja de tratar la compartición de impresoras como una sola configuración. Es un sistema distribuido con autenticación, autorización y distribución de software. Si no lo gestionas como tal, la próxima ronda de endurecimiento te gestionará a ti.

Datos interesantes e historia breve: por qué la impresión siempre está en la zona afectada

Hecho 1: SMB nació en los años 80 (raíces IBM) y evolucionó a CIFS/SMB a medida que el networking de Windows se convirtió en la plomería de oficina. La impresión viajó junto porque “un recurso compartido es un recurso compartido”.
Hecho 2: El Print Spooler de Windows tiene décadas; es lo suficientemente antiguo como para mantener supuestos de diseño de una era en la que las LAN eran “confiables”.
Hecho 3: “Point and Print” se diseñó para reducir la sobrecarga de administración de escritorios. También creó un canal de distribución de software—exactamente lo que a los atacantes les encanta.
Hecho 4: La firma SMB existe desde hace mucho, pero “requerida” es distinto a “soportada”. Requerirla expone cada dispositivo olvidado y cliente mal configurado.
Hecho 5: SMB1 no es solo “antiguo”. Es estructuralmente débil (muy conversador, defaults pobres de seguridad). Deshabilitarlo es buena higiene, pero rompe cosas que nunca fueron actualizadas.
Hecho 6: Muchos “servidores de impresión” de impresoras son solo pilas SMB/RPC pequeñas con una interfaz web. A menudo van rezagadas respecto a las líneas de tiempo de endurecimiento de Windows.
Hecho 7: El spooler ha tenido múltiples vulnerabilidades de alto impacto en años recientes, y la respuesta de la industria ha sido: “endurecer valores por defecto, reducir la confianza implícita”. Por eso las actualizaciones son disruptivas.
Hecho 8: Las empresas solían estandarizar en un puñado de drivers universales. Luego llegaron los paquetes “valor añadido” de los proveedores y drivers por modelo, lo que multiplicó los dolores de compatibilidad.

Primera broma (corta, relevante): Los drivers de impresora son el único software que puede ser a la vez “crítico para la misión” y “descargado desde un servidor que nadie recuerda tener”.

Los principales modos de falla (y los síntomas que realmente ves)

Modo de falla A: el cliente no puede autenticarse correctamente con el servidor de impresión

Síntomas típicos: Acceso denegado al conectar a la impresora compartida, solicitudes de credenciales repetidas, o funciona para administradores pero no para usuarios estándar.

Causas comunes: NTLM bloqueado, Kerberos fallando por problemas DNS/SPN, incompatibilidad de firma SMB, fallback de invitado eliminado, o autenticación RPC más estricta.

Modo de falla B: el cliente puede autenticarse pero no puede instalar el driver

Síntomas típicos: Avisos “¿Confía en esta impresora?”, avisos que requieren admin, o fallos silenciosos con un código de error críptico. A veces se conecta pero no imprime nada.

Causas comunes: Restricciones de Point and Print, driver no empaquetado/firmado como se espera, o políticas que exigen aprobación administrativa para la instalación de drivers.

Modo de falla C: el servidor no puede comunicarse con el dispositivo (la impresión falla, la compartición parece culpable)

Síntomas típicos: Los clientes se conectan bien pero los trabajos quedan atascados en la cola. La cola del servidor muestra “Error” u “Offline”. Los usuarios culpan a la actualización porque fue cuando lo notaron.

Causas comunes: firmware/SMB del dispositivo, cambios TLS para IPP/HTTPS, cambios de firewall, o puertos/monitores obsoletos.

Modo de falla D: colapsan las suposiciones de resolución de nombres y descubrimiento

Síntomas típicos: Rutas UNC que antes funcionaban ya no resuelven, o solo funcionan con FQDN/IP. Impresoras desplegadas por GPO fallan de manera esporádica.

Causas comunes: Problemas de DNS, dependencia deshabilitada de NetBIOS/WINS, o segmentación de red más estricta.

Modo de falla E: desajuste de dialecto SMB (SMB1 desapareció, y algo llora)

Síntomas típicos: Un appliance de impresión legacy desaparece, recurso de drivers inaccesible, o la conexión al recurso falla por completo.

Causas comunes: SMB1 deshabilitado en cliente o servidor; dispositivos legacy no actualizados.

Hay un modelo mental claro: la impresión falla o bien en conexión (auth/SMB/RPC), en instalación (política de drivers), o en entrega (ruta servidor→impresora). Tu trabajo es identificar qué capa te está engañando.

Guion de diagnóstico rápido (primero/segundo/tercero)

Este es el camino “obtener señal en cinco minutos”. No empieces reinstalando drivers en 300 portátiles. No empieces deshabilitando seguridad. Comienza demostrando el límite de falla.

Primero: ¿es conexión/instalación, o es entrega del trabajo?

Desde un cliente afectado: ¿puedes abrir \\PRINT01 en el Explorador? Si no, es SMB/auth/resolución de nombres.
¿Puedes añadir la impresora pero los trabajos se estancan? Es la tubería servidor→dispositivo o spooler.
¿Funciona para admin local pero no para usuarios? Es Point and Print / instalación de drivers / privilegios.

Segundo: valida la negociación SMB y el método de autenticación

Verifica si la firma SMB es requerida en un lado y no está soportada/activa en el otro.
Comprueba si se usa Kerberos (bueno) o si cae a NTLM (puede ahora estar bloqueado).
Revisa si se está intentando acceso invitado (ahora a menudo bloqueado).

Tercero: inspecciona los logs del spooler y del servicio de impresión para el código de error real

En el cliente: registros PrintService y registros del Sistema para eventos de conexión e instalación de drivers.
En el servidor: registros PrintService Admin y Operational, además del registro de Seguridad para fallos de autenticación.

Si solo memorizas una cosa: encuentra el primer error en la cadena. Los errores de impresión se encadenan; el último error suele ser solo la queja final, no la causa.

Tareas prácticas: comandos, salida esperada y qué significa la salida

Estas tareas están escritas como si estuvieras de guardia intentando terminar el incidente sin convertir tu red en 2009 otra vez. Cada tarea incluye: comando, salida de ejemplo, qué significa y la decisión que tomas.

Task 1: Confirmar conectividad SMB al servidor de impresión (lado cliente)

cr0x@server:~$ smbclient -L //PRINT01 -U 'CORP\alice'
Password for [CORP\alice]:
	Sharename       Type      Comment
	---------       ----      -------
	IPC$            IPC       Remote IPC
	PRINT$          Disk      Printer Drivers
	HP-Laser        Printer   4th Floor Laser
SMB1 disabled -- no workgroup available

Qué significa: Puedes autenticarte y listar recursos. La presencia de PRINT$ es una buena señal (existe el recurso de drivers). La línea “SMB1 disabled” es informativa de smbclient; no es un error aquí.

Decisión: Si el listado funciona, la ruta de red y la autenticación básica están bien. Pasa a la política de instalación de drivers y a los logs del spooler. Si el listado falla con NT_STATUS_ACCESS_DENIED o fallo de inicio de sesión, enfócate en autenticación/endurecimiento.

Task 2: Validar que la resolución de nombres no es el asesino silencioso

cr0x@server:~$ getent hosts PRINT01
10.40.12.25     PRINT01.corp.example PRINT01

Qué significa: La resolución DNS funciona en esta máquina. Si tus clientes Windows no pueden resolver, tienes un DNS de horizonte dividido, lista de sufijos de búsqueda o un problema de segmentación.

Decisión: Si la resolución falla, deja de culpar al endurecimiento SMB. Arregla DNS primero o usa FQDN en despliegues.

Task 3: Comprobar qué dialecto SMB y características de seguridad se negocian (punto de vista Linux)

cr0x@server:~$ smbclient //PRINT01/PRINT$ -U 'CORP\alice' -m SMB3 -c 'ls'
Password for [CORP\alice]:
  .                                   D        0  Mon Feb  5 10:11:02 2026
  ..                                  D        0  Mon Feb  5 10:11:02 2026
  x64                                 D        0  Mon Feb  5 10:10:55 2026
  W32X86                              D        0  Mon Feb  5 10:10:55 2026

Qué significa: SMB3 funciona hacia el recurso de drivers. Si forzar SMB3 falla pero el predeterminado funciona, puedes tener problemas de degradación/compatibilidad. Si SMB3 funciona pero los clientes Windows fallan, probablemente sea política/driver/ruta RPC, no el transporte SMB en sí.

Decisión: Mantén SMB3; no vuelvas a habilitar SMB1 para “hacer que funcione”. Si SMB3 falla, inspecciona la configuración SMB del servidor y el nivel de parche.

Task 4: Confirmar que el servidor de impresión realmente está compartiendo impresoras (comprobación en servidor Windows vía PowerShell sobre WinRM, ejecutado desde un jump box que tiene pwsh)

cr0x@server:~$ pwsh -Command "Invoke-Command -ComputerName PRINT01 -ScriptBlock { Get-Printer | Select-Object Name,Shared,ShareName,DriverName | Format-Table -Auto }"
Name               Shared ShareName DriverName
----               ------ --------- ----------
HP Laser 4F        True   HP-Laser  HP Universal Printing PCL 6
Canon Color 3F     True   CANON-3F  Canon Generic Plus UFR II

Qué significa: Las impresoras están compartidas y tienen bindings de driver.

Decisión: Si Shared es false o ShareName está en blanco, la “compartición está rota” pero es configuración administrativa, no endurecimiento SMB. Arregla los ajustes de compartición y permisos.

Task 5: Comprobar si el servicio Print Spooler de Windows está en ejecución (lado servidor)

cr0x@server:~$ pwsh -Command "Invoke-Command -ComputerName PRINT01 -ScriptBlock { Get-Service Spooler | Format-List Status,StartType,Name }"
Status    : Running
StartType : Automatic
Name      : Spooler

Qué significa: El spooler está activo. Si está detenido, nada más importa.

Decisión: Si está detenido, comprueba por qué (crash, política, endurecimiento que lo deshabilitó en servidores que no deberían tenerlo parado). Inícialo solo en servidores que deben imprimir; de lo contrario déjalo deshabilitado por seguridad.

Task 6: Extraer eventos Admin de PrintService alrededor del momento de la falla (lado servidor)

cr0x@server:~$ pwsh -Command "Invoke-Command -ComputerName PRINT01 -ScriptBlock { Get-WinEvent -LogName 'Microsoft-Windows-PrintService/Admin' -MaxEvents 10 | Select-Object TimeCreated,Id,LevelDisplayName,Message | Format-List }"
TimeCreated : 02/05/2026 10:22:11
Id          : 808
LevelDisplayName : Error
Message     : The print spooler failed to share printer HP Laser 4F. Error 0x00000005 (Access is denied.)

Qué significa: Esto es un problema de permisos/autenticación en la compartición o llamadas RPC. El Error 0x5 es el clásico acceso denegado.

Decisión: Revisa permisos de compartición, descriptores de seguridad y cualquier política nueva que restrinja operaciones de drivers de impresora o administración remota.

Task 7: Comprobar eventos Operational de PrintService en el cliente (lado cliente vía PowerShell remoto)

cr0x@server:~$ pwsh -Command "Invoke-Command -ComputerName WS1234 -ScriptBlock { Get-WinEvent -LogName 'Microsoft-Windows-PrintService/Operational' -MaxEvents 15 | Select-Object TimeCreated,Id,Message | Format-List }"
TimeCreated : 02/05/2026 10:19:03
Id          : 316
Message     : The print spooler failed to add printer connection \\PRINT01\HP-Laser. Error code 0x0000011b.

Qué significa: El cliente intentó conectarse pero encontró una clase conocida de fallos de endurecimiento RPC/impresión que a menudo aparecen como 0x0000011b.

Decisión: No copies una solución de registro sin entenderla. Confirma desajuste de parches entre servidor/cliente, ajustes de privacidad/autenticación RPC y si el entorno depende de comportamiento legacy. Arregla alineando niveles de parche y ajustando política de forma controlada.

Task 8: Verificar si el servidor requiere firma SMB (servidor Windows)

cr0x@server:~$ pwsh -Command "Invoke-Command -ComputerName PRINT01 -ScriptBlock { Get-SmbServerConfiguration | Select-Object RequireSecuritySignature,EnableSecuritySignature,EncryptData | Format-List }"
RequireSecuritySignature : True
EnableSecuritySignature  : True
EncryptData              : False

Qué significa: El servidor requiere firma SMB. Los clientes antiguos o appliances pueden fallar. Los clientes Windows modernos deberían manejarlo, pero aparecen problemas de rendimiento o casos límite si hay un middlebox o componente legacy.

Decisión: Mantén la firma requerida a menos que tengas un problema de compatibilidad verificado. Si algo no puede firmar, reemplázalo o aíslalo; no debilites el servidor de impresión por un dispositivo obstinado.

Task 9: Confirmar ajustes de firma SMB en el cliente (cliente Windows)

cr0x@server:~$ pwsh -Command "Invoke-Command -ComputerName WS1234 -ScriptBlock { Get-SmbClientConfiguration | Select-Object RequireSecuritySignature,EnableSecuritySignature | Format-List }"
RequireSecuritySignature : False
EnableSecuritySignature  : True

Qué significa: El cliente soporta firma y la usará si el servidor la requiere. Esto debería estar bien.

Decisión: Si EnableSecuritySignature es false, eso es una señal roja. Arréglalo vía política; de lo contrario las sesiones SMB a servidores endurecidos pueden fallar.

Task 10: Comprobar si NTLM está siendo bloqueado (pistas de política en cliente Windows)

cr0x@server:~$ pwsh -Command "Invoke-Command -ComputerName WS1234 -ScriptBlock { reg query 'HKLM\SYSTEM\CurrentControlSet\Control\Lsa' /v LmCompatibilityLevel }"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
    LmCompatibilityLevel    REG_DWORD    0x5

Qué significa: Este valor empuja hacia NTLMv2 únicamente (bueno), pero no prueba por sí solo que NTLM esté bloqueado. Aun así, te indica que el endpoint no está en modo “todo vale”.

Decisión: Si la impresión depende de fallback a NTLM porque Kerberos está roto, puede ahora fallar. Arregla Kerberos (DNS, SPNs, tiempo) en lugar de aflojar controles NTLM.

Task 11: Confirmar que Kerberos funciona para el servidor de impresión (contexto de cliente de dominio)

cr0x@server:~$ pwsh -Command "Invoke-Command -ComputerName WS1234 -ScriptBlock { klist }"
Current LogonId is 0:0x3f2a7
Cached Tickets: (3)

#0>     Client: alice @ CORP.EXAMPLE
        Server: cifs/PRINT01.corp.example @ CORP.EXAMPLE
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Qué significa: El cliente tiene un ticket Kerberos para CIFS al servidor de impresión. Es una fuerte evidencia de que la parte SMB puede autenticarse con Kerberos.

Decisión: Si no ves un ticket CIFS y lo esperas, arregla DNS/SPNs y sincronización de tiempo. Una cantidad sorprendente de “la impresión se rompió tras la actualización” es en realidad “Kerberos funcionaba con holgura y la actualización dejó de tolerarlo”.

Task 12: Verificar permisos y contenido del recurso de drivers (lado servidor)

cr0x@server:~$ pwsh -Command "Invoke-Command -ComputerName PRINT01 -ScriptBlock { Get-SmbShare -Name 'PRINT$' | Select-Object Name,Path,FolderEnumerationMode,CachingMode | Format-List }"
Name                   : PRINT$
Path                   : C:\Windows\System32\spool\drivers
FolderEnumerationMode  : Unrestricted
CachingMode            : None

Qué significa: PRINT$ apunta al directorio esperado de drivers del spooler. Si alguien lo “optimizó” a una ruta diferente o cambió permisos, los clientes pueden fallar al obtener drivers.

Decisión: Si PRINT$ falta o fue reubicado, restáuralo salvo que tengas una alternativa disciplinada. La impresión no es lugar para experimentos bonitos con el sistema de archivos.

Task 13: Probar añadir una conexión de impresora de forma no interactiva (lado cliente)

cr0x@server:~$ pwsh -Command "Invoke-Command -ComputerName WS1234 -ScriptBlock { Add-Printer -ConnectionName '\\\\PRINT01\\HP-Laser' }"
Add-Printer : The specified server does not have a printer driver installed.
At line:1 char:1
+ Add-Printer -ConnectionName '\\PRINT01\HP-Laser'
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (MSFT_Printer:ROOT/StandardCimv2/MSFT_Printer) [Add-Printer], CimException
    + FullyQualifiedErrorId : HRESULT 0x80070705,Add-Printer

Qué significa: Esto apunta a un desajuste de disponibilidad de drivers en el servidor. O el driver no está presente en el servidor, o no es compatible con la arquitectura/tipo del cliente.

Decisión: Arregla el almacén de drivers del servidor y la estrategia de empaquetado. No “arregles” permitiendo que los clientes obtengan drivers aleatorios del internet del proveedor.

Task 14: Comprobar qué drivers están instalados en el servidor de impresión (lado servidor)

cr0x@server:~$ pwsh -Command "Invoke-Command -ComputerName PRINT01 -ScriptBlock { Get-PrinterDriver | Select-Object Name,Manufacturer,DriverVersion,MajorVersion | Sort-Object Name | Select-Object -First 8 | Format-Table -Auto }"
Name                             Manufacturer         DriverVersion  MajorVersion
----                             ------------         -------------  ------------
HP Universal Printing PCL 6      HP                   7.1.0.0        3
Microsoft enhanced Point and Print Microsoft          10.0.0.0       4
Canon Generic Plus UFR II        Canon                3.90.0.0       3

Qué significa: Puedes ver la mezcla de tipos y versiones de drivers. Entornos con muchos drivers Type 3 del proveedor suelen sufrir más cuando las políticas se endurecen.

Decisión: Estandariza drivers cuando sea posible. Prefiere drivers firmados y empaquetados. Reduce la proliferación de drivers como reduces imágenes base de contenedores: menos, conocidas y parcheadas.

Task 15: Confirmar el puerto de la impresora y su alcanzabilidad desde el servidor (sanidad de red del servidor)

cr0x@server:~$ pwsh -Command "Invoke-Command -ComputerName PRINT01 -ScriptBlock { Test-NetConnection -ComputerName 10.40.50.88 -Port 9100 }"
ComputerName     : 10.40.50.88
RemoteAddress    : 10.40.50.88
RemotePort       : 9100
InterfaceAlias   : Ethernet
SourceAddress    : 10.40.12.25
TcpTestSucceeded : True

Qué significa: El servidor puede alcanzar la impresora en JetDirect/9100. Si esto falla, tu incidente “tras la actualización” puede ser en realidad un cambio de firewall o endurecimiento de segmentación de red que coincidió con el parcheo.

Decisión: Si la alcanzabilidad falla, arregla enrutamiento/firewall/ACls de VLAN. Ajustes de driver y SMB no ayudarán a un puerto bloqueado.

Task 16: Comprobar si el spooler está bloqueado por reglas de firewall (lado servidor)

cr0x@server:~$ pwsh -Command "Invoke-Command -ComputerName PRINT01 -ScriptBlock { Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Select-Object DisplayName,Enabled,Profile,Action | Select-Object -First 6 | Format-Table -Auto }"
DisplayName                                      Enabled Profile  Action
-----------                                      ------- -------  ------
File and Printer Sharing (SMB-In)                True    Domain   Allow
File and Printer Sharing (Spooler Service - RPC) True    Domain   Allow
File and Printer Sharing (Spooler Service - RPC-EPMAP) True Domain Allow

Qué significa: Las reglas básicas entrantes están habilitadas para el perfil Domain. Si tu servidor está en perfil Public por confusión de NLA, estas reglas pueden no aplicarse.

Decisión: Si las reglas están deshabilitadas o hay desajuste de perfil, arregla el perfil de red y la política de firewall en lugar de abrir puertos al azar.

Tres micro-historias corporativas desde las trincheras de la impresión

Micro-historia 1: El incidente causado por una suposición equivocada (“Es solo un recurso compartido de impresora”)

Tenían un entorno ordenado sobre el papel: un servidor de impresión Windows, un puñado de colas compartidas y una GPO que mapeaba impresoras según OU. Las actualizaciones se programaban mensualmente. El primer lunes después de la noche de parches, el service desk se vio inundado: los portátiles nuevos no podían añadir impresoras. Los existentes en su mayoría funcionaban, lo que hizo que todo pareciera intermitente y por tanto “misterioso”.

La suposición equivocada fue simple: asumieron que el problema eran los objetos de impresora. Reiniciaron spooler, volvieron a compartir impresoras, reinstalaron drivers e incluso cambiaron una impresora. No cambió nada. Los usuarios con un driver en caché antiguo seguían imprimiendo, dando la ilusión de que el sistema estaba bien y solo los “nuevos dispositivos” estaban rotos.

El límite real de falla fue la instalación de drivers. El endurecimiento cambió cómo se comportaba Point and Print para usuarios no admins. El entorno había dependido silenciosamente de que los usuarios obtuvieran drivers del servidor sin elevación. El parche no rompió la impresión; rompió “la distribución silenciosa de software a través del servidor de impresión”.

Una vez que lo trataron como un problema de despliegue de software, la solución fue obvia: empaquetar y aprobar drivers correctamente, definir servidores de impresión confiables vía política y dejar de permitir que colas aleatorias se conviertan en puntos de distribución de drivers. Después de eso, las impresoras se mapearon con normalidad de nuevo.

Conclusión: si la impresión funciona en máquinas que ya tenían el driver, no toques la impresora. Toca la política de drivers y el modelo de confianza.

Micro-historia 2: La optimización que salió mal (mover PRINT$ a “almacenamiento más rápido”)

Otra compañía tenía un servidor de impresión que también actuaba como servidor de archivos (sí, me retorcí). Alguien notó que el disco del sistema estaba bajo presión y decidió “optimizar” relocando las carpetas de spool y drivers a un volumen dedicado. El cambio se implementó con cuidado, con ventana de mantenimiento, y mejoró las métricas de disco.

Luego llegó la actualización de endurecimiento. De repente, algunos clientes se negaron a obtener drivers y otros recibieron instalaciones de drivers corruptas. El equipo inicialmente culpó al parche, pero el parche fue solo el evento que hizo que el sistema dejara de tolerar su creativa disposición del sistema de archivos.

Las rutas reubicadas tenían una herencia de ACL diferente a los defaults de Windows. Bajo el comportamiento antiguo, los clientes aún conseguían lo que necesitaban. Bajo el comportamiento nuevo—chequeos más estrictos, patrones de acceso más explícitos—esas peculiaridades de ACL se volvieron fatales. Las descargas de drivers fallaban. Las impresoras aparecían pero imprimían basura o nada.

Revirtieron la reubicación y estandarizaron las rutas de spool/drivers por defecto con permisos controlados. La presión en disco volvió, pero la impresión se estabilizó. Más tarde resolvieron el almacenamiento separando roles y ajustando el dimensionamiento correctamente, no operando sobre los entrañas de la impresión de Windows.

Conclusión: la impresión tolera defaults aburridos mejor que tolera ingenios. Optimiza después de poder probar las invariantes de las que dependes.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día (anillos de parche y un piso sacrificial)

Una empresa mediana hizo algo profundamente poco a la moda: tenían anillos de parches para endpoints y servidores, e incluían la impresión en la validación pre-producción. No “abrimos Word una vez”. Tenían una prueba de humo automatizada: añadir una impresora desde el servidor, imprimir una página de prueba, verificar que salió de la cola y confirmar que el registro de trabajos en la UI web de la impresora se actualizó.

Cuando llegó la actualización de endurecimiento, su anillo piloto vio inmediatamente una falla: los usuarios estándar ya no podían añadir cierta cola de un proveedor. Los logs mostraron un aviso de instalación de driver que no podía completarse. Pausaron el despliegue amplio, pero no revirtieron nada.

En su lugar, usaron el tiempo para cambiar esa cola a un driver universal empaquetado y firmado ya aprobado, y endurecieron la política de “servidores de impresión confiables” para su clúster de impresión. Para cuando la actualización llegó al resto de la flota, el problema ya estaba solucionado.

Lo más importante: documentaron la decisión: no “arreglarían” debilitando la firma SMB o re-habilitando el acceso invitado. Arreglarían haciendo la impresión compatible con autenticación moderna y gobernanza de drivers.

Conclusión: un pequeño anillo de parches más una prueba real de impresión convierte un posible outage en un hilo de correo.

Errores comunes: síntoma → causa raíz → solución

Síntoma: Los usuarios reciben “Windows no puede conectarse a la impresora” de inmediato.
Causa raíz: SMB/RPC bloqueado por desajuste de perfil de firewall (Domain vs Public) o reglas “File and Printer Sharing” faltantes.
Solución: Corrige el perfil de red/NLA, habilita el grupo de reglas de firewall apropiado para Domain, verifica que los endpoints RPC sean accesibles.
Síntoma: Error 0x0000011b al añadir impresoras compartidas tras parchear.
Causa raíz: Endurecimiento RPC/spooler expone incompatibilidad o desajuste de parches entre clientes y servidor.
Solución: Alinea niveles de parche, valida políticas del spooler, evita hacks de registro improvisados; remedia la estrategia de drivers/paquetes.
Síntoma: Funciona para admins, falla para usuarios estándar con avisos que no pueden aprobar.
Causa raíz: Restricciones Point and Print ahora requieren elevación o lista de servidores de confianza para instalación de drivers.
Solución: Configura servidores de impresión confiables vía política, precarga drivers, usa drivers empaquetados/firmados; despliega con herramientas gestionadas.
Síntoma: Solo algunos modelos fallan; otros funcionan bien.
Causa raíz: El paquete de driver del proveedor es Type 3 legacy, no firmado o incompatible; desajuste de tipo entre arquitecturas.
Solución: Reemplaza por un driver universal conocido; estandariza; elimina drivers abandonados del servidor.
Síntoma: Los usuarios pueden explorar \\PRINT01 pero no ven impresoras o no pueden conectar.
Causa raíz: RPC al spooler bloqueado/denegado mientras SMB está bien; permisos en objetos de spooler/impresora apretados.
Solución: Verifica reglas de firewall RPC del spooler, revisa logs de PrintService, confirma ACLs de impresora y delegación.
Síntoma: La impresión funciona vía IP directa, pero no vía la cola compartida.
Causa raíz: La ruta de la cola compartida falla en distribución de drivers o autenticación del spooler; el dispositivo en sí está bien.
Solución: Arregla la ruta del servidor de impresión; no “soluciones” convirtiendo a todos a impresión IP no gestionada salvo que disfrutes el caos.
Síntoma: La conexión funciona solo si usas la IP del servidor, no el nombre.
Causa raíz: Desajuste DNS/SPN provocando fallo Kerberos, lo que desencadena fallback a NTLM que está bloqueado.
Solución: Arregla registros DNS, asegura SPNs correctos, usa FQDN en shares y GPO, confirma sincronización de tiempo.
Síntoma: Un appliance de impresión legacy desapareció tras la actualización.
Causa raíz: SMB1 deshabilitado o acceso invitado removido; el appliance depende de comportamiento SMB antiguo.
Solución: Reemplaza/actualiza el appliance; aíslalo temporalmente si es crítico para el negocio, pero no re-habilites SMB1 a nivel de flota.

Segunda broma (corta, relevante): Si re-habilitas SMB1 para que una impresora funcione, la impresora imprimirá—mayormente tickets de incidentes.

Listas de verificación / plan paso a paso

Plan paso a paso para entornos de producción (haz esto, no vibras)

Reproduce en un cliente y una cola de impresora. Elige una máquina limpia que no haya impreso antes (sin driver en caché). Documenta el código de error exacto y la marca temporal.
Decide dónde está la falla: conexión/auth (SMB/RPC), instalación de driver (Point and Print) o entrega de trabajo (servidor→impresora).
Revisa la salud del servidor primero: spooler en ejecución, comparticiones de impresora presentes, PRINT$ accesible, sin errores obvios en PrintService.
Comprueba el método de autenticación del cliente: valida tickets Kerberos para CIFS y que la resolución de nombres sea correcta.
Alinea niveles de parche: asegúrate de que el servidor de impresión y los clientes estén en una postura de parches coherente y soportada. El desajuste de parches es un patrón clásico de “la mitad de la flota se rompió”.
Arregla la estrategia de drivers: reduce a un conjunto curado de drivers firmados y empaquetados. Elimina drivers abandonados que ya no instalan limpiamente bajo endurecimiento.
Configura “servidores de impresión confiables” vía política: lista explícitamente tus servidores de impresión. Mantén la lista corta. Si tienes 40, no tienes servidores de impresión; tienes impresoras haciendo de infraestructura.
Restringe quién puede instalar drivers en servidores: la impresión no es una democracia. Limita la instalación de drivers de impresora a admins/procesos gestionados de cambios.
Vuelve a probar con un usuario estándar: añadir la impresora debe tener éxito sin admin local. Si requiere admin, no has solucionado el problema empresarial, solo el de tu portátil.
Despliega por anillos: grupo piloto, luego piso por piso u OU por OU. La impresión es candidata ideal para despliegue progresivo porque el impacto de usuario es inmediato y medible.
Monitorea logs: registros PrintService, registro de Seguridad para fallos de autenticación y patrones de tickets de helpdesk. Las tendencias importan.
Escribe la invariante: “Requerimos firma SMB, SMB1 deshabilitado, invitado deshabilitado; la impresión debe funcionar dentro de estas restricciones.” Hazlo política, no memoria.

Lista de postura de seguridad (mantén las ganancias)

SMB1 deshabilitado en clientes y servidores salvo excepciones aisladas con fecha de retiro.
Firma SMB requerida en servidores que proveen recursos (incluyendo PRINT$).
Acceso invitado deshabilitado; usa autenticación real (Kerberos/NTLMv2) y permisos adecuados.
Limita quién puede administrar servidores de impresión; trátalos como servidores de aplicación.
Estandariza drivers; prefiere firmados y empaquetados.

Lista operativa (reducir recurrencia)

Anillos de parches que incluyan al menos un servidor de impresión y un puñado de clientes diversos.
Una prueba de humo de impresión scriptada que cubra: añadir impresora, imprimir página de prueba, confirmar vaciado de cola.
Control de deriva de configuración: baseline para ajustes SMB y configuración de PRINT$.
Inventario de modelos de impresora y versiones de driver en uso.

Preguntas frecuentes

1) ¿Por qué se rompió justo después de una actualización si nada cambió en la configuración del servidor de impresión?

Porque la actualización cambió las reglas de juego: requisitos de autenticación, comportamiento RPC y políticas de instalación de drivers. Tu configuración antigua puede haber “funcionado” apoyándose en valores por defecto permisivos.

2) ¿Debo simplemente revertir la actualización?

Sólo como medida para ganar tiempo, y solo si tienes un plan claro para volver a aplicar los parches de forma segura. Revertir no es una solución; es un préstamo con interés, y la tasa de interés es “severidad de incidentes futuros”.

3) ¿SMB está realmente involucrado? Pensé que la impresión era RPC.

Ambos aparecen. RPC se usa para operaciones del spooler, pero SMB a menudo soporta la distribución de drivers (PRINT$) y el acceso a recursos. Endurecer cualquiera de las capas puede parecer “el recurso compartido de impresora está roto”.

4) ¿Por qué funciona para algunos usuarios/máquinas y no para otros?

Por caché y privilegios. Máquinas que ya tenían el driver instalado pueden seguir imprimiendo aunque nuevas instalaciones estén bloqueadas. Los admins pueden aprobar avisos que los usuarios estándar no pueden. El desajuste de parches entre clientes también puede hacer que el comportamiento sea inconsistente.

5) ¿Cuál es el camino más seguro para restaurar la impresión sin debilitar la seguridad?

Alinea parches, arregla Kerberos/resolución de nombres, estandariza drivers firmados y empaquetados, y configura explícitamente servidores de impresión confiables. Mantén la firma SMB activada; mantén SMB1 apagado; mantén el acceso invitado deshabilitado.

6) ¿Pueden los servidores Samba (Linux) verse afectados por esto también?

Sí. Si los clientes Windows endurecen requisitos (firma, autenticación, reglas de drivers), servidores Samba configurados permisivamente pueden dejar de cumplir expectativas. Además, el “compartir impresora” de Samba a menudo depende de cómo se manejan los drivers—muchas organizaciones evitan Point and Print por completo y gestionan drivers vía herramientas de endpoint.

7) ¿Qué código de error debo buscar primero?

Busca el primer evento de fallo cerca del tiempo de conexión intentada en los logs de PrintService (cliente y servidor). Códigos como 0x0000011b y 0x00000005 reducen el campo rápidamente, pero no te detengas solo en el código—correlaciona con logs de autenticación.

8) ¿Es la impresión por IP directa una buena solución temporal?

Como solución temporal para un pequeño número de usuarios VIP, quizá. Como estrategia de flota, suele salir mal: reaparece la proliferación de drivers, la configuración se desvía y pierdes auditoría centralizada y control de colas. Arregla la infraestructura de impresión a menos que estés retirándola intencionadamente.

9) ¿Cómo pruebo que es Kerberos/NTLM relacionado?

Comprueba tickets Kerberos CIFS hacia el servidor de impresión, inspecciona registros de Seguridad para uso o fallos de NTLM y confirma DNS/SPNs. Si el acceso por nombre falla pero por IP funciona, Kerberos suele estar implicado.

10) ¿Cuál es un enfoque sensato a largo plazo si seguimos siendo afectados por cambios en impresión?

Trata la impresión como una plataforma de aplicaciones: servidores de confianza mínimos, drivers curados, despliegue automatizado, anillos de parche y observabilidad. Si eso suena mucho trabajo, ya estás pagando ese coste—solo que en forma de outages.

Conclusión: próximos pasos prácticos

La compartición de impresoras no “se rompió aleatoriamente”. Tu entorno llegó al borde donde las suposiciones legacy sobre impresión se encontraron con la seguridad moderna. Las actualizaciones no crearon la complejidad; la revelaron.

Haz esto a continuación, en orden:

Ejecuta el guion de diagnóstico rápido: determina si fallas en conexión/auth, instalación de driver o entrega de trabajo.
Recopila los primeros eventos relevantes de PrintService en cliente y servidor y un punto de datos de Seguridad/auth (ticket Kerberos o fallo NTLM).
Alinea niveles de parche entre servidor de impresión y clientes. El desajuste de parches es el multiplicador sigiloso de outages.
Arregla la gobernanza de drivers: menos drivers, firmados/empaquetados, precargados cuando sea posible.
Configura servidores de impresión confiables de forma explícita. Deja de permitir que “cualquier servidor con un share” se convierta en un sistema de distribución de drivers.
Mantén firma SMB requerida, SMB1 deshabilitado y acceso invitado deshabilitado. Si algo no puede convivir con eso, no es “legacy”, es “candidato a reemplazo”.

Una idea parafraseada de Werner Vogels (CTO de Amazon): Todo falla; la resiliencia viene de diseñar para esa realidad, no de esperar que los componentes se comporten.