Partage d’imprimante cassé après mise à jour : conséquences du durcissement SMB

février 16, 2026 • février 16, 2026 • Lecture : 30 min • Views: 0

Cet article vous a aidé ?

Vos utilisateurs n’ont rien changé. Ils jurent que non. Pourtant, au moment où une mise à jour est arrivée, toutes les connexions « \\PRINT01\HP-Laser » ont commencé à échouer avec Accès refusé, 0x0000011b, ou le classique intemporel : « Windows ne peut pas se connecter à l’imprimante. » Pendant ce temps, l’imprimante USB locale imprime parfaitement, parce que naturellement elle le fait.

Ceci est à quoi ressemble le durcissement de la sécurité dans la vraie vie : des flux de travail légitimes qui reposaient sur d’anciens comportements SMB et d’impression se retrouvent mis hors service. La solution n’est que rarement de « revenir en arrière » sur la mise à jour. La solution consiste à comprendre ce qui a changé, prouver où se situe la panne et ajuster la configuration pour conserver les gains de sécurité sans sacrifier l’impression.

Ce qui a changé : les mesures de durcissement qui brisent le partage d’imprimante

« Partage d’imprimante » sonne comme une fonctionnalité conviviale de bureau. En pratique, c’est une chaîne de protocoles et d’hypothèses de confiance :

Les clients découvrent une imprimante partagée via un chemin SMB/UNC ou via un annuaire/déploiement GPO.
Le client parle au spooler du serveur d’impression (RPC) pour énumérer les imprimantes, les pilotes et les paramètres.
Si un pilote n’est pas installé, le client peut le télécharger depuis le serveur (Point and Print) ou exiger des paquets approuvés par un administrateur.
Le travail d’impression lui-même peut transiter via RPC, SMB ou un moniteur de port vers l’imprimante réelle.

Les mises à jour durcissent les bords de cette chaîne, souvent de manières correctes du point de vue sécurité et catastrophiques pour le « pourquoi ça n’imprime pas ». Les cassures typiques après une mise à jour s’agrègent autour de ces changements :

1) Durcissement du Print Spooler : restrictions Point and Print, installation de pilotes et invites administrateur

Beaucoup d’environnements reposaient historiquement sur le fait que les utilisateurs pouvaient se connecter à une imprimante partagée et que le pilote apparaissait comme par magie. Cette « magie » était une action privilégiée avec une longue histoire d’abus. Le durcissement signifie souvent :

Les clients refusent d’installer ou de mettre à jour des pilotes d’imprimante depuis un serveur sauf si ce serveur est explicitement approuvé.
Les clients exigent une élévation pour l’installation de pilotes, même pour des pilotes « paquetés », selon la stratégie et le niveau de correctif.
Les utilisateurs non administrateurs voient des invites qu’ils ne peuvent pas approuver, ce qui ressemble à un partage d’imprimante cassé.

Traduction : votre impression dépendait d’une installation silencieuse du pilote. Le durcissement supprime le « silencieux ».

2) Durcissement SMB : signature, chiffrement, accès invité et anciens dialectes

SMB n’est pas uniquement des partages de fichiers. Les partages d’imprimantes sont souvent exposés via SMB, et le sous-système d’impression peut récupérer des pilotes et paramètres via des partages SMB sur le serveur d’impression.

Le durcissement inclut couramment :

Exigence de signature SMB sur les serveurs ou les clients. Si l’autre côté ne peut pas ou ne veut pas signer, l’authentification peut réussir mais la session échoue — ou ne démarre même pas.
Accès invité SMB désactivé. Les anciens partages d’imprimantes comptaient parfois sur des permissions « Everyone » plus un repli invité, surtout dans des environnements mixtes ou en groupe de travail.
SMB1 désactivé. Cela arrive encore. Certains appareils d’impression anciens et quelques « serveurs d’impression » basés sur NAS n’acceptent que SMB1 pour le partage de pilotes ou pour des raccourcis de résolution de noms.
Restrictions NTLM. Kerberos est préféré, et dans certaines organisations NTLM est bloqué ou fortement audité. L’impression via RPC a de nombreuses façons de retomber sur NTLM si les SPN, DNS ou l’horloge ne sont pas parfaits.

3) Durcissement RPC : authentification plus stricte et exigences de « confidentialité »

L’impression Windows utilise RPC. Le durcissement peut exiger une authentification renforcée sur les appels RPC vers le spooler, et peut rejeter des connexions qui fonctionnaient auparavant avec de vieux clients, des serveurs hérités ou des stratégies mal configurées. Certaines des erreurs célèbres « ça a cassé l’impression » apparaissent précisément parce que la négociation RPC a changé.

4) Incompatibilité de type de pilote : vérifications Type 3 vs Type 4

Les pilotes Type 4 devaient simplifier la vie. En pratique, beaucoup de parcs sont un musée de pilotes Type 3, de paquets fournisseurs et de fichiers INF « ça marche sur ma machine ». Le durcissement plus l’incohérence des pilotes peuvent pousser les clients à refuser le pilote, bloquer le téléchargement ou installer la mauvaise chose.

Conseil argumenté : cessez de considérer le partage d’imprimante comme un simple paramètre. C’est un système distribué avec authentification, autorisation et distribution logicielle. Si vous ne le gérez pas comme tel, la prochaine ronde de durcissement vous gérera.

Faits intéressants et brève histoire : pourquoi l’impression est toujours touchée

Fait 1 : SMB a commencé dans les années 1980 (racines IBM) et est devenu CIFS/SMB à mesure que le réseau Windows est devenu la plomberie bureautique. L’impression y a pris place parce qu’« un partage est un partage ».
Fait 2 : Le Print Spooler Windows remonte à des décennies ; il est assez ancien pour contenir des hypothèses de conception issues d’une époque où les LAN étaient « de confiance ».
Fait 3 : « Point and Print » a été conçu pour réduire la charge d’administration des postes. Il a aussi créé un canal de distribution logicielle — exactement ce que les attaquants adorent.
Fait 4 : La signature SMB existe depuis longtemps, mais « exigée » n’est pas la même chose que « supportée ». L’exiger expose chaque appareil oublié et chaque client mal configuré.
Fait 5 : SMB1 n’est pas juste « ancien ». Il est structurellement faible (trop bavard, mauvais paramètres de sécurité par défaut). Le désactiver est une bonne hygiène, mais cela casse des choses qui n’ont jamais été mises à jour.
Fait 6 : Beaucoup d’appareils « serveurs d’impression » sont juste de petites piles SMB/RPC avec une UI web. Ils prennent souvent du retard par rapport aux calendriers de durcissement Windows.
Fait 7 : Le spooler a eu plusieurs vulnérabilités à fort impact ces dernières années, et la réponse de l’industrie a été : « durcir les valeurs par défaut, réduire la confiance implicite. » C’est pourquoi les mises à jour sont perturbatrices.
Fait 8 : Les entreprises standardisaient autrefois sur quelques pilotes universels. Puis sont arrivés les paquets « valeur ajoutée » des fournisseurs et des pilotes par modèle, ce qui a multiplié les problèmes de compatibilité.

Première blague (courte, pertinente) : Les pilotes d’imprimante sont les seuls logiciels à pouvoir être à la fois « essentiels » et « téléchargés depuis un serveur dont personne ne se souvient ».

Principaux modes de panne (et symptômes que vous voyez réellement)

Mode de panne A : le client ne peut pas s’authentifier correctement auprès du serveur d’impression

Symptômes typiques : Accès refusé lors de la connexion à l’imprimante partagée, invites d’identifiants répétées, ou ça fonctionne pour les admins mais pas pour les utilisateurs standards.

Causes communes : NTLM bloqué, Kerberos échoue à cause de DNS/SPN, décalage de signature SMB, repli invité supprimé ou authentification RPC plus stricte.

Mode de panne B : le client s’authentifie mais ne peut pas installer le pilote

Symptômes typiques : invites « Faites-vous confiance à cette imprimante ? », invites nécessitant les droits administrateur, ou échecs silencieux avec un code d’erreur cryptique. Parfois la connexion se fait mais rien n’imprime.

Causes communes : restrictions Point and Print, pilote non paqueté/signé comme attendu, ou politiques exigeant l’approbation administrateur pour l’installation de pilotes.

Mode de panne C : le serveur ne peut pas parler à l’appareil (l’impression casse, le partage semble en faute)

Symptômes typiques : Les clients se connectent bien mais les travaux restent bloqués dans la file. La file du serveur affiche « Erreur » ou « Hors ligne ». Les utilisateurs blâment la mise à jour parce que c’est à ce moment qu’ils l’ont remarqué.

Causes communes : firmware de l’imprimante/ changements SMB, modifications TLS pour IPP/HTTPS, changements de pare-feu, ou ports/moniteurs obsolètes.

Mode de panne D : les hypothèses de résolution de noms et de découverte s’effondrent

Symptômes typiques : Les chemins UNC qui fonctionnaient ne se résolvent plus, ou ne fonctionnent qu’avec FQDN/IP. Les imprimantes déployées via GPO échouent de façon sporadique.

Causes communes : problèmes DNS, dépendance NetBIOS/WINS désactivée, ou segmentation réseau renforcée.

Mode de panne E : incompatibilité de dialecte SMB (SMB1 est parti, et ça pleure)

Symptômes typiques : L’appliance d’impression héritée disparaît, le partage de pilotes est inaccessible, ou la connexion au partage échoue purement et simplement.

Causes communes : SMB1 désactivé côté client ou serveur ; appareils anciens non mis à jour.

Il y a un modèle mental simple : l’impression échoue soit à l’étape de connexion (auth/SMB/RPC), soit à l’étape d’installation (politique de pilotes), soit à l’étape de livraison (chemin serveur→imprimante). Votre travail est d’identifier quelle couche vous ment.

Playbook de diagnostic rapide (premier/deuxième/troisième)

Voici le chemin « obtenir du signal en cinq minutes ». Ne commencez pas par réinstaller des pilotes sur 300 ordinateurs portables. Ne commencez pas par désactiver la sécurité. Commencez par prouver la frontière de la panne.

Premier : est-ce la connexion/l’installation, ou la livraison du travail ?

Depuis un client affecté : pouvez-vous ouvrir \\PRINT01 dans l’Explorateur ? Si non, c’est SMB/auth/résolution de noms.
Pouvez-vous ajouter l’imprimante mais les travaux stagnent ? C’est le pipeline serveur→appareil ou le spooler.
Ça fonctionne pour un administrateur local mais pas pour les utilisateurs ? C’est Point and Print / installation de pilotes / privilèges.

Second : validez la négociation SMB et la méthode d’authentification

Vérifiez si la signature SMB est requise d’un côté et non supportée/utilisée de l’autre.
Vérifiez si Kerberos est utilisé (bon) ou s’il retombe sur NTLM (qui peut maintenant être bloqué).
Vérifiez si un accès invité est tenté (souvent bloqué désormais).

Troisième : inspectez les logs du spooler et du service d’impression pour le code d’erreur réel

Sur le client : les journaux PrintService et les journaux Système pour les événements de connexion et d’installation de pilotes.
Sur le serveur : les journaux PrintService Admin et Operational, ainsi que le journal Sécurité pour les échecs d’authentification.

Si vous ne retenez qu’une chose : trouvez la première erreur dans la chaîne. Les erreurs d’impression se propagent ; la dernière erreur est souvent la plainte finale, pas la cause.

Tâches pratiques : commandes, sortie attendue, et ce que signifie la sortie

Ces tâches sont écrites comme si vous étiez en astreinte et essayiez de clore l’incident sans transformer votre réseau en 2009. Chaque tâche inclut : commande, sortie d’exemple, ce que cela signifie et la décision à prendre.

Task 1: Confirm SMB connectivity to the print server (client-side)

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

Ce que cela signifie : Vous pouvez vous authentifier et lister les partages. La présence de PRINT$ est un bon signe (le partage de pilotes existe). La ligne « SMB1 disabled » est informative venant de smbclient ; ce n’est pas une erreur ici.

Décision : Si la liste fonctionne, le chemin réseau et l’authentification de base sont OK. Passez à la politique d’installation de pilotes et aux journaux du spooler. Si la liste échoue avec NT_STATUS_ACCESS_DENIED ou échec d’ouverture de session, concentrez-vous sur l’auth/durcissement.

Task 2: Validate name resolution is not the silent killer

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

Ce que cela signifie : La résolution DNS fonctionne sur cette machine. Si vos clients Windows ne peuvent pas résoudre, vous avez un DNS à horizon scindé, une liste de suffixes de recherche ou un problème de segmentation.

Décision : Si la résolution échoue, cessez de blâmer le durcissement SMB. Corrigez d’abord le DNS ou utilisez des FQDN dans les déploiements.

Task 3: Check which SMB dialect and security features are negotiated (Linux vantage point)

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

Ce que cela signifie : SMB3 fonctionne vers le partage de pilotes. Si forcer SMB3 échoue mais que le mode par défaut fonctionne, vous pouvez avoir des problèmes de downgrade/compatibilité. Si SMB3 fonctionne mais que les clients Windows échouent, il s’agit probablement d’une politique/pilote/chemin RPC, pas du transport SMB lui-même.

Décision : Gardez SMB3 ; ne réactivez pas SMB1 pour « faire marcher » les choses. Si SMB3 échoue, inspectez la configuration SMB du serveur et le niveau de correctif.

Task 4: Confirm the print server is actually sharing printers (Windows server check via PowerShell over WinRM, executed from a jump box that has 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

Ce que cela signifie : Les imprimantes sont partagées et ont des liaisons de pilotes.

Décision : Si Shared est false ou ShareName est vide, le « partage est cassé » mais c’est une configuration administrative, pas du durcissement SMB. Corrigez les paramètres de partage et les permissions.

Task 5: Check whether the Windows Print Spooler service is running (server-side)

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

Ce que cela signifie : Le spooler est actif. S’il est arrêté, rien d’autre n’a d’importance.

Décision : S’il est arrêté, vérifiez pourquoi (plantage, politique, durcissement qui l’a désactivé sur des serveurs qui ne devraient pas l’être). Démarrez-le uniquement sur les serveurs qui doivent imprimer ; sinon laissez-le désactivé pour la sécurité.

Task 6: Pull PrintService Admin events around the time of failure (server-side)

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.)

Ce que cela signifie : C’est un problème de permission/auth sur le partage ou les appels RPC. L’erreur 0x5 est un classique accès refusé.

Décision : Vérifiez les permissions de partage, les descripteurs de sécurité et toute nouvelle stratégie restreignant les opérations de pilote d’imprimante ou l’administration à distance.

Task 7: Check client-side PrintService Operational events (client-side via remote PowerShell)

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.

Ce que cela signifie : Le client a tenté de se connecter mais est tombé sur une classe connue d’échecs liés au durcissement RPC/impression qui se manifestent souvent par 0x0000011b.

Décision : Ne reproduisez pas mécaniquement un hack de registre. Confirmez le désalignement de correctifs serveur/client, les paramètres RPC privacy/auth, et si l’environnement dépend d’un comportement hérité. Corrigez en alignant les niveaux de correctifs et en ajustant la politique de manière contrôlée.

Task 8: Verify whether SMB signing is required on the server (Windows server)

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

Ce que cela signifie : Le serveur exige la signature SMB. Les anciens clients ou appliances peuvent échouer. Les clients Windows modernes devraient gérer cela, mais des cas limites apparaissent s’il y a un intermédiaire ou un composant legacy.

Décision : Maintenez l’exigence de signature sauf si vous avez un problème de compatibilité vérifié. Si quelque chose ne peut pas signer, remplacez-le ou isolez-le ; n’affaiblissez pas le serveur d’impression pour un seul appareil récalcitrant.

Task 9: Confirm client SMB signing settings (Windows client)

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

Ce que cela signifie : Le client supporte la signature et l’utilisera si le serveur l’exige. Cela devrait être correct.

Décision : Si EnableSecuritySignature est false, c’est un signal d’alarme. Corrigez via la stratégie ; sinon les sessions SMB vers des serveurs durcis peuvent échouer.

Task 10: Check whether NTLM is being blocked (Windows client policy hints)

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

Ce que cela signifie : Cette valeur pousse vers NTLMv2 uniquement (bien), mais ne prouve pas à elle seule que NTLM est bloqué. Cela vous indique tout de même que le point de terminaison n’est pas en « mode tout est permis ».

Décision : Si l’impression dépend d’un repli NTLM parce que Kerberos est cassé, elle peut maintenant échouer. Réparez Kerberos (DNS, SPN, synchronisation horaire) plutôt que d’assouplir les contrôles NTLM.

Task 11: Confirm Kerberos works for the print server (domain client context)

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

Ce que cela signifie : Le client possède un ticket Kerberos pour CIFS vers le serveur d’impression. C’est une preuve solide que la portion SMB peut s’authentifier avec Kerberos.

Décision : Si vous ne voyez pas de ticket CIFS alors que vous en attendez un, corrigez le DNS/SPN et la synchronisation horaire. Une grande partie des « impression cassée après mise à jour » est en réalité « Kerberos fonctionnait à la marge et la mise à jour a cessé de tolérer ça ».

Task 12: Verify the driver share permissions and content (server-side)

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

Ce que cela signifie : PRINT$ pointe vers le répertoire attendu des pilotes spool. Si quelqu’un l’a « optimisé » vers un autre chemin ou a trafiqué les permissions, les clients peuvent échouer à récupérer les pilotes.

Décision : Si PRINT$ manque ou a été déplacé, remettez-le en place sauf si vous avez une alternative disciplinée. L’impression n’est pas l’endroit pour des expériences système originales.

Task 13: Test adding a printer connection non-interactively (client-side)

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

Ce que cela signifie : Cela pointe vers un décalage de disponibilité des pilotes côté serveur. Soit le pilote n’est pas présent sur le serveur, soit il n’est pas compatible avec l’architecture/type du client.

Décision : Corrigez le magasin de pilotes du serveur et la stratégie de packaging. Ne « corrigez » pas en laissant les clients télécharger des pilotes fournisseurs non contrôlés depuis Internet.

Task 14: Check what drivers are installed on the print server (server-side)

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

Ce que cela signifie : Vous voyez le mélange de types et de versions de pilotes. Les environnements avec beaucoup de pilotes Type 3 fournisseurs ont tendance à souffrir le plus quand les politiques se durcissent.

Décision : Standardisez les pilotes quand c’est possible. Privilégiez des pilotes signés et paquetés. Réduisez la prolifération des pilotes comme vous réduisez les images de base : moins, connus et patchés.

Task 15: Confirm the printer port and reachability from the server (server-side network sanity)

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

Ce que cela signifie : Le serveur peut atteindre l’imprimante sur JetDirect/9100. Si cela échoue, votre panne « après mise à jour » peut en réalité être un changement de pare-feu ou un renforcement de la segmentation réseau qui a coïncidé avec les correctifs.

Décision : Si la connectivité échoue, corrigez le routage/pare-feu/ACL VLAN. Les ajustements de pilotes et SMB n’aideront pas un port bloqué.

Task 16: Check whether spooler is blocked by firewall rules (server-side)

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

Ce que cela signifie : Les règles entrantes de base sont activées pour le profil Domaine. Si votre serveur est en profil Public à cause d’une confusion NLA, ces règles peuvent ne pas s’appliquer.

Décision : Si les règles sont désactivées ou si le profil est incorrect, corrigez le profil réseau et la politique de pare-feu plutôt que d’ouvrir des ports au hasard.

Trois mini-histoires d’entreprise issues des tranchées de l’impression

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse (« C’est juste un partage d’imprimante »)

Ils avaient un environnement propre sur le papier : un serveur d’impression Windows, quelques files partagées et une GPO qui mappait les imprimantes selon l’OU. Les mises à jour étaient planifiées chaque mois. Le premier lundi après la nuit de patch, le service desk a été submergé : les nouveaux portables ne pouvaient pas ajouter d’imprimantes. Les anciens fonctionnaient pour la plupart, ce qui rendait tout intermittent et donc « mystérieux ».

L’hypothèse erronée était simple : ils ont supposé que le problème venait des objets imprimante. Ils ont redémarré le spooler, re-partagé les imprimantes, réinstallé des pilotes et même changé une imprimante. Rien n’a changé. Les utilisateurs avec un pilote mis en cache continuaient d’imprimer, donnant l’illusion que le système était sain et que seuls les « nouveaux appareils » étaient cassés.

La vraie frontière de panne était l’installation des pilotes. Le durcissement a changé le comportement Point and Print pour les utilisateurs non administrateurs. L’environnement dépendait discrètement du téléchargement silencieux de pilotes depuis le serveur sans élévation. Le correctif n’a pas cassé l’impression ; il a cassé la « distribution logicielle silencieuse via le serveur d’impression ».

Une fois qu’ils l’ont traité comme un problème de déploiement logiciel, la solution est devenue évidente : empaqueter et approuver correctement les pilotes, définir des serveurs d’impression approuvés via stratégie et cesser de laisser des files devenir des points de distribution de pilotes. Après cela, les imprimantes se sont mappées proprement à nouveau.

Conclusion : si l’impression fonctionne sur des machines qui avaient déjà le pilote, ne touchez pas à l’imprimante. Touchez à la politique de pilotes et au modèle de confiance.

Mini-histoire 2 : L’optimisation qui a se retournée contre eux (déplacer PRINT$ sur un « stockage plus rapide »)

Une autre entreprise avait un serveur d’impression qui servait aussi de serveur de fichiers (oui, ça fait grimacer). Quelqu’un a remarqué que le disque système était sous pression et a décidé « d’optimiser » en déplaçant les répertoires spool et pilotes vers un volume dédié. Le changement a été réalisé soigneusement, pendant une fenêtre de maintenance, et cela a amélioré les métriques disque.

Puis le durcissement est arrivé. Soudain, certains clients refusaient de récupérer des pilotes et d’autres obtenaient des installations de pilotes corrompues. L’équipe a d’abord blâmé le correctif, mais le correctif n’était que l’événement qui a empêché le système de tolérer leur mise en œuvre créative du système de fichiers.

Les chemins déplacés avaient une héritage d’ACL différent des valeurs par défaut Windows. Avec l’ancien comportement, les clients arrivaient malgré tout à récupérer ce dont ils avaient besoin. Avec le nouveau comportement — contrôles plus stricts, modèles d’accès plus explicites — ces bizarreries d’ACL sont devenues fatales. Les téléchargements de pilotes ont échoué. Les imprimantes apparaissaient mais imprimaient de la casse ou rien.

Ils ont annulé le déplacement et standardisé sur les chemins spool/pilotes par défaut avec des permissions contrôlées. La pression disque est revenue, mais l’impression s’est stabilisée. Plus tard, ils ont résolu le stockage correctement en séparant les rôles et en dimensionnant le système correctement, et non en pratiquant des chirurgies sur les entrailles de l’impression Windows.

Conclusion : l’impression tolère mieux les valeurs par défaut ennuyeuses que l’ingéniosité. Optimisez après avoir prouvé les invariants sur lesquels vous vous appuyez.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation (anneaux de patch et un étage sacrificiel)

Une entreprise de taille moyenne a fait quelque chose profondément démodé : elle avait des anneaux de patch pour postes et serveurs, et incluait l’impression dans la validation pré-production. Pas un « on a ouvert Word une fois ». Ils avaient un test smoke scripté : ajouter une imprimante depuis le serveur, imprimer une page test, vérifier que la file a été vidée et que le journal de tâches de l’UI web de l’imprimante a été mis à jour.

Quand le durcissement est arrivé, leur anneau pilote a immédiatement vu une panne : les utilisateurs standards ne pouvaient plus ajouter une certaine file fournisseur. Les logs montraient une invite d’installation de pilote qui ne pouvait pas être complétée. Ils ont mis en pause le déploiement large, mais n’ont rien restauré en arrière.

Au lieu de ça, ils ont profité du répit pour basculer cette file vers un pilote universel paqueté et signé déjà approuvé, et ont resserré la politique « serveurs d’impression approuvés » pour n’inclure que leur cluster d’impression. Au moment où la mise à jour a atteint le reste du parc, le problème était déjà mort.

Plus important encore, ils ont documenté la décision : ils n’allaient pas « réparer » en affaiblissant la signature SMB ou en réactivant l’accès invité. Ils allaient réparer en rendant l’impression compatible avec l’authentification moderne et la gouvernance des pilotes.

Conclusion : un petit anneau de patch plus un vrai test d’impression transforment une panne potentielle en simple fil de discussion par email.

Erreurs courantes : symptôme → cause racine → correction

Symptôme : Les utilisateurs obtiennent « Windows ne peut pas se connecter à l’imprimante » immédiatement.
Cause racine : SMB/RPC bloqué par un mauvais profil de pare-feu (Domaine vs Public) ou règles « File and Printer Sharing » manquantes.
Correction : Corrigez le profil réseau/NLA, activez le groupe de règles pare-feu approprié pour Domain, vérifiez que les endpoints RPC sont joignables.
Symptôme : Erreur 0x0000011b lors de l’ajout d’imprimantes partagées après patch.
Cause racine : Durcissement RPC/spooler exposant une incompatibilité ou un décalage de correctifs entre clients et serveur.
Correction : Alignez les niveaux de correctifs, validez les politiques du spooler, évitez les downgrades de registre ad-hoc ; remédiez la stratégie de pilotes/paquets.
Symptôme : Ça fonctionne pour les admins, échoue pour les utilisateurs standards avec des invites qu’ils ne peuvent pas approuver.
Cause racine : Les restrictions Point and Print exigent désormais une élévation ou une liste de serveurs approuvés pour l’installation/mise à jour des pilotes.
Correction : Configurez la politique de serveurs d’impression approuvés, pré-installez les pilotes, utilisez des pilotes paquetés/signés ; déployez via des outils gérés.
Symptôme : Seuls certains modèles échouent ; d’autres fonctionnent.
Cause racine : Le paquet du fournisseur est Type 3 legacy, non signé ou incompatible ; mismatch de Type entre architectures.
Correction : Remplacez par un pilote universel connu, standardisez ; retirez les pilotes abandonnés du serveur.
Symptôme : Les utilisateurs peuvent parcourir \\PRINT01 mais ne voient pas les imprimantes ou ne peuvent pas se connecter.
Cause racine : RPC vers le spooler bloqué/deny alors que SMB est OK ; permissions sur les objets spooler/imprimante resserrées.
Correction : Vérifiez les règles pare-feu RPC du spooler, consultez les logs PrintService, confirmez les ACLs imprimante et la délégation.
Symptôme : L’impression fonctionne en IP direct, mais pas via la file partagée.
Cause racine : Le chemin de la file partagée échoue sur la distribution de pilotes ou l’authentification spooler ; l’appareil lui-même est OK.
Correction : Réparez le chemin serveur d’impression ; ne « résolvez » pas en convertissant tout le monde en impression IP non gérée sauf si vous aimez le chaos.
Symptôme : La connexion ne fonctionne que si vous utilisez l’IP du serveur, pas son nom.
Cause racine : Mismatch DNS/SPN causant une défaillance Kerberos, déclenchant un repli NTLM qui est bloqué.
Correction : Corrigez les enregistrements DNS, assurez les SPN corrects, utilisez des FQDN dans les partages et GPO, confirmez la synchronisation horaire.
Symptôme : Une appliance d’impression legacy a disparu après la mise à jour.
Cause racine : SMB1 désactivé ou accès invité retiré ; l’appliance dépend d’un comportement SMB ancien.
Correction : Remplacez/mettre à jour l’appliance ; isolez-la temporairement si c’est critique, mais ne réactivez pas SMB1 à l’échelle du parc.

Deuxième blague (courte, pertinente) : Si vous réactivez SMB1 pour faire marcher une imprimante, l’imprimante fonctionnera — et surtout vous remplirez les tickets d’incident.

Listes de contrôle / plan étape par étape

Plan étape par étape pour environnements de production (faites ceci, pas des impressions)

Reproduisez sur un client et une file d’imprimante. Choisissez une machine propre qui n’a jamais imprimé (pas de pilote en cache). Documentez le code d’erreur exact et l’horodatage.
Décidez où la panne se situe : connexion/auth (SMB/RPC), installation du pilote (Point and Print) ou livraison du travail (serveur→imprimante).
Vérifiez l’état du serveur en premier : spooler en cours, partages d’imprimantes présents, PRINT$ accessible, pas d’erreurs évidentes PrintService.
Vérifiez la méthode d’auth du client : validez les tickets Kerberos pour CIFS et que la résolution de noms est correcte.
Alignez les niveaux de correctifs : assurez-vous que le serveur d’impression et les clients sont dans une posture de correctifs cohérente et supportée. Le décalage de patch est un motif classique de « moitié du parc cassé ».
Corrigez la stratégie de pilotes : réduisez à un ensemble approuvé de pilotes signés et paquetés. Retirez les pilotes abandonnés qui n’installent plus proprement sous durcissement.
Définissez « serveurs d’impression approuvés » via la stratégie : listez explicitement vos serveurs d’impression. Gardez la liste courte. Si vous en avez 40, vous n’avez pas des serveurs d’impression ; vous avez des imprimantes qui se font passer pour de l’infrastructure.
Verrouillez qui peut installer des pilotes sur les serveurs : l’impression n’est pas une démocratie. Limitez l’installation de pilotes aux administrateurs/processus gérés de changement.
Retestez avec un utilisateur standard : l’ajout de l’imprimante doit réussir sans admin local. Si cela exige des droits admin, vous n’avez pas résolu le problème d’entreprise, vous avez résolu le vôtre.
Déployez par anneaux : groupe pilote, puis étage par étage ou OU par OU. L’impression est un bon candidat pour la livraison progressive car l’impact utilisateur est immédiat et mesurable.
Surveillez les journaux : logs PrintService, journaux Sécurité pour échecs d’auth, et modèles de tickets helpdesk. Les tendances comptent.
Écrivez l’invariant : « Nous exigeons la signature SMB, SMB1 désactivé, invité désactivé ; l’impression doit fonctionner dans ces contraintes. » Faites-en une politique, pas juste une mémoire.

Checklist posture sécurité (conserver les acquis)

SMB1 désactivé sur clients et serveurs sauf exception isolée avec date de retrait.
Signature SMB requise sur les serveurs qui fournissent des partages (y compris PRINT$).
Accès invité désactivé ; utilisez une authentification réelle (Kerberos/NTLMv2) et des permissions appropriées.
Limitez qui peut administrer les serveurs d’impression ; traitez-les comme des serveurs d’application.
Standardisez les pilotes ; privilégiez les pilotes signés et paquetés.

Checklist opérationnelle (réduire la récurrence)

Anneaux de patch incluant au moins un serveur d’impression et un petit groupe de clients divers.
Un test smoke scripté couvrant : ajout d’imprimante, impression d’une page test, confirmation de vidage de file.
Contrôle de dérive de configuration : référence pour paramètres SMB et configuration PRINT$.
Inventaire des modèles d’imprimante et versions de pilotes en usage.

FAQ

1) Pourquoi cela a-t-il cassé juste après une mise à jour alors que rien n’a changé sur notre serveur d’impression ?

Parce que la mise à jour a changé les règles du jeu : exigences d’authentification, comportement RPC et politiques d’installation de pilotes. Votre ancienne configuration « fonctionnait » en s’appuyant sur des valeurs permissives par défaut.

2) Dois-je simplement revenir en arrière sur la mise à jour ?

Seulement comme mesure pour gagner du temps, et seulement si vous avez un plan clair pour réappliquer les correctifs de sécurité en toute sécurité. Revenir en arrière n’est pas une solution ; c’est un prêt avec intérêt, et le taux d’intérêt est « la sévérité des incidents futurs ».

3) SMB est-il vraiment impliqué ? Je pensais que l’impression utilisait RPC.

Les deux sont impliqués. RPC est utilisé pour les opérations spooler, mais SMB alimente souvent la distribution des pilotes (PRINT$) et l’accès aux partages. Le durcissement de l’une ou l’autre couche peut ressembler à « le partage d’imprimante est cassé ».

4) Pourquoi cela fonctionne-t-il pour certains utilisateurs/machines mais pas pour d’autres ?

Mise en cache et privilèges. Les machines qui avaient déjà le pilote peuvent continuer à imprimer même si les nouvelles installations sont bloquées. Les admins peuvent approuver des invites que les utilisateurs standards ne peuvent pas. Le décalage de patch entre clients peut aussi rendre le comportement incohérent.

5) Quel est le chemin le plus sûr pour rétablir l’impression sans affaiblir la sécurité ?

Alignez les correctifs, réparez Kerberos/résolution de noms, standardisez sur des pilotes signés et paquetés, et configurez explicitement les serveurs d’impression approuvés. Conservez la signature SMB activée ; gardez SMB1 désactivé ; gardez l’accès invité désactivé.

6) Les serveurs Samba (Linux) peuvent-ils aussi être affectés ?

Oui. Si les clients Windows durcissent les exigences (signature, auth, règles de pilotes), des serveurs Samba configurés permissivement peuvent ne plus satisfaire les attentes. De plus, le « partage d’imprimante » Samba dépend souvent de la façon dont les pilotes sont gérés — beaucoup d’organisations évitent Point and Print et gèrent les pilotes via des outils endpoint.

7) Quel code d’erreur dois-je rechercher en priorité ?

Recherchez le premier événement d’échec proche du moment de la tentative de connexion dans les logs PrintService (client et serveur). Des codes comme 0x0000011b et 0x00000005 réduisent rapidement le champ, mais ne vous arrêtez pas au code — corrélez avec les logs d’authentification.

8) L’impression en IP directe est-elle un bon contournement ?

Comme contournement temporaire pour quelques utilisateurs VIP, peut-être. Comme stratégie pour le parc, cela se retourne généralement contre vous : prolifération des pilotes, dérive de configuration et perte d’audit centralisé et de contrôle des files. Réparez l’infrastructure d’impression à moins que vous ne la retiriez volontairement.

9) Comment prouver que c’est lié à Kerberos/NTLM ?

Vérifiez la présence de tickets Kerberos CIFS vers le serveur d’impression, inspectez les journaux Sécurité pour l’utilisation ou l’échec NTLM, et confirmez DNS/SPN. Si l’accès basé sur le nom échoue mais que l’IP fonctionne, Kerberos est souvent en cause.

10) Quelle est une approche raisonnable à long terme si nous sommes régulièrement touchés par des changements d’impression ?

Traitez l’impression comme une plateforme applicative : serveurs approuvés minimaux, pilotes curatés, déploiement automatisé, anneaux de patch et observabilité. Si cela vous semble trop de travail, vous payez déjà ce coût — mais en indisponibilités.

Conclusion : prochaines étapes pratiques

Le partage d’imprimante ne s’est pas « cassé au hasard ». Votre environnement a atteint le point où les hypothèses d’impression héritées rencontrent la sécurité moderne. Les mises à jour n’ont pas créé la complexité ; elles l’ont révélée.

Faites ceci ensuite, dans l’ordre :

Exécutez le playbook de diagnostic rapide : déterminez si vous échouez à la connexion/auth, à l’installation du pilote ou à la livraison du travail.
Collectez les premiers événements pertinents PrintService client et serveur et un point de donnée Sécurité/auth (ticket Kerberos ou échec NTLM).
Alignez les niveaux de correctifs serveur d’impression et clients. Le décalage de patch est le multiplicateur silencieux d’incidents.
Corrigez la gouvernance des pilotes : moins de pilotes, signés/paquetés, pré-déployés si possible.
Configurez explicitement les serveurs d’impression approuvés. Arrêtez de laisser « n’importe quel serveur avec un partage » devenir un système de distribution de pilotes.
Maintenez la signature SMB requise, gardez SMB1 désactivé, gardez l’accès invité désactivé. Si quelque chose ne peut pas vivre avec cela, ce n’est pas « legacy », c’est « candidat au remplacement ».

Une idée paraphrasée de Werner Vogels (CTO Amazon) : Tout échoue ; la résilience vient de la conception pour cette réalité, pas de l’espoir que les composants se comportent.