Спільний доступ до принтерів зламався після оновлення: пояснення наслідків посилення SMB

February 16, 2026 • February 16, 2026 • Читання: 5 хв • Views: 0

Було корисно?

Користувачі нічого не змінювали. Вони клянуться. Але щойно з’явилося оновлення, кожне підключення «\\PRINT01\HP-Laser» почало падати з Access Denied, 0x0000011b або з вічною класикою: «Windows не може підключитися до принтера». Місцевий USB-принтер друкує нормально — бо звісно, він друкує.

Ось як у реальному житті виглядає посилення безпеки: легітимні робочі процеси, які покладалися на старі поведінки SMB і друку, опиняються в біді. Виправлення рідко означає «відкотити оновлення». Потрібно зрозуміти, що змінилося, довести, де саме відбувається відмова, і налаштувати конфігурацію так, щоб зберегти переваги безпеки, не втративши можливість друкувати.

Що змінилося: жорсткі налаштування, які ламають спільний доступ до принтерів

«Спільний доступ до принтера» звучить як дружня функція офісу. Насправді це ланцюг протоколів і припущень про довіру:

Клієнти виявляють спільний принтер через шлях SMB/UNC або через каталог/GPO-розгортання.
Клієнт спілкується зі спулерним сервісом (RPC) на сервері друку, щоб перелічити принтери, драйвери та налаштування.
Якщо драйвер не встановлений, клієнт може завантажити його з сервера (Point and Print) або вимагати пакет, затверджений адміністратором.
Саме завдання на друк може йти через RPC, SMB або монітор порту до фізичного пристрою.

Оновлення жорсткіше налаштовують краї цього ланцюга, часто правильно з точки зору безпеки, але катастрофічно з погляду «чому ж він не друкує». Типові злами після оновлення зосереджені навколо таких змін:

1) Посилення Print Spooler: обмеження Point and Print, встановлення драйверів і підказки для адміністрування

Багато середовищ історично покладалися на те, що користувачі можуть підключитися до спільного принтера, і драйвер з’явиться немов магія. Така «магія» — привілейована дія з довгою історією зловживань. Посилення часто означає:

Клієнти відмовляються встановлювати або оновлювати драйвери принтера з сервера, якщо цей сервер явно не позначений як довірений.
Клієнтам потрібне підвищення привілеїв для встановлення драйверів, навіть для «упакованих» драйверів, залежно від політики й рівня патчів.
Користувачі без прав адміністратора бачать підказки, які не можуть підтвердити, що виглядає як злам спільного доступу до принтера.

Переклад: ваш друк залежав від безшумного встановлення драйверів. Посилення прибирає «безшумність».

2) Посилення SMB: підписування, шифрування, гостьовий доступ і старі діалекти

SMB — це не лише файлові шари. Принтерні шари часто експонуються через SMB, і підсистема друку може отримувати драйвери та налаштування через SMB-шари на сервері друку.

Посилення зазвичай включає:

Вимога SMB-підписування на серверах або клієнтах. Якщо інша сторона не може підписати або не хоче — автентифікація може пройти, але сесія впаде або навіть не запуститься.
Відключення гостьового доступу. Старі принтерні шари іноді полагалися на дозволи «Everyone» плюс гостьовий фолбек, особливо в змішаних середовищах або робочих групах.
Вимкнення SMB1. І досі трапляється. Деякі старі апарати друку та NAS-пристрої «сервери друку» розмовляють лише SMB1 щодо шару драйверів або для спрощення імен.
Обмеження NTLM. Віддають перевагу Kerberos, і в деяких організаціях NTLM блокується або суворо аудититься. Друк через RPC має багато шляхів повернення до NTLM, якщо SPN, DNS або синхронізація часу неідеальні.

3) Посилення RPC: жорсткіші вимоги до автентифікації та «конфіденційності»

Windows-друк використовує RPC. Посилення може вимагати сильнішої автентифікації для RPC-викликів до спулера і відкидати з’єднання, які раніше працювали з старими клієнтами, застарілими серверами або неправильно налаштованими політиками. Саме через зміну переговорів RPC з’являються відомі помилки друку.

4) Невідповідність типів драйверів: перевірка Type 3 vs Type 4

Type 4 драйвери мали полегшити життя. На практиці багато парків — це музей Type 3 драйверів, пакунків вендорів та INF-файлів «працює у мене». Посилення разом з невідповідністю драйверів може призвести до того, що клієнти відмовляються від драйвера, блокують завантаження або встановлюють неправильний пакет.

Думка: припиніть ставитися до спільного доступу до принтерів як до одного перемикача. Це розподілена система з автентифікацією, авторизацією та розповсюдженням програмного забезпечення. Якщо ви її так не управляєте — наступний раунд посилення її «виправить» за вас.

Цікаві факти та коротка історія: чому друк завжди в зоні ураження

Факт 1: SMB виник у 1980-х (корені IBM) і виріс у CIFS/SMB, коли мережева комунікація Windows стала офісною інфраструктурою. Друк підхопився, бо «share — це share».
Факт 2: Windows Print Spooler старий десятиліттями; він створювався в еру, коли LAN вважали довіреними.
Факт 3: «Point and Print» розроблявся, щоб зменшити адміністративні зусилля на десктопах. Він також створив канал розповсюдження ПЗ — те, що атакувальники полюбляють.
Факт 4: SMB-підписування існує давно, але «вимагати» відрізняється від «підтримувати». Вимога підписування виявляє кожен забутий пристрій і неправильно налаштований клієнт.
Факт 5: SMB1 — це не просто «старезний». Він структурно слабкий (резонний, погані налаштування безпеки). Вимкнення — хороша гігієна, але ламає те, що ніколи не оновлювали.
Факт 6: Багато апаратів «сервер друку» — це маленькі стеки SMB/RPC з веб-інтерфейсом. Вони часто відстають від графіків посилення Windows.
Факт 7: Спулер мав кілька вразливостей великого впливу за останні роки, і відповідь індустрії була: «затягнути налаштування за замовчуванням, зменшити неявну довіру». Ось чому оновлення руйнівні.
Факт 8: Підприємства звикли стандартизуватися на кількох універсальних драйверах. Потім з’явилися вендорські пакети та драйвери для кожної моделі, що ускладнило сумісність.

Перший жарт (короткий, по темі): драйвери принтера — єдине програмне забезпечення, яке може бути одночасно «критичним для місії» і «завантаженим з сервера, якого ніхто не пам’ятає».

Основні режими відмов (і симптоми, які ви фактично бачите)

Режим відмов A: клієнт не може правильно автентифікуватися на сервері друку

Типові симптоми: Access Denied при підключенні до спільного принтера, повторні запити вводу облікових даних або працює для адміністраторів, але не для звичайних користувачів.

Поширені причини: NTLM заблоковано, Kerberos не працює через проблеми DNS/SPN, несумісність SMB-підписування, відсутній гостьовий фолбек або жорсткіші вимоги RPC.

Режим відмов B: клієнт може автентифікуватися, але не може встановити драйвер

Типові симптоми: підказки «Довіряєте цьому принтеру?», підказки, які потребують прав адміністратора, або тихі збої з криптичним кодом помилки. Іноді підключення відбувається, але друку немає.

Поширені причини: обмеження Point and Print, драйвер не упакований/не підписаний як очікувалося, або політики вимагають погодження адміністратора для встановлення драйверів.

Режим відмов C: сервер не може зв’язатися з пристроєм (друк ламається, а шаринг виглядає підозрілим)

Типові симптоми: клієнти підключаються нормально, але завдання застрягають у черзі. Черга сервера показує «Помилка» або «Офлайн». Користувачі звинувачують оновлення, бо помітили проблему після нього.

Поширені причини: зміни в прошивці принтера/SMB, зміни TLS для IPP/HTTPS, зміни у фаєрволі або застарілі порти/монітори.

Режим відмов D: припущення щодо розв’язування імен та виявлення руйнуються

Типові симптоми: UNC-шляхи, що раніше працювали, більше не розв’язуються або працюють лише з FQDN/IP. GPO-розгорнуті принтери підвисають випадково.

Поширені причини: проблеми DNS, вимкнена залежність від NetBIOS/WINS або посилена сегментація мережі.

Режим відмов E: несумісність діалектів SMB (SMB1 вимкнено, і щось плаче)

Типові симптоми: старий апаратний сервер друку зникає, шар драйверів недоступний або підключення до шару взагалі не вдається.

Поширені причини: SMB1 вимкнено на клієнті чи сервері; застарілі пристрої не оновлені.

Є зрозуміла ментальна модель: друк ламається або на рівні підключення (auth/SMB/RPC), або на рівні встановлення (політика драйверів), або на рівні доставки (шлях сервер→принтер). Ваше завдання — ідентифікувати, який шар вас підводить.

Швидка діагностика: перший/другий/третій

Це шлях «отримати сигнал за п’ять хвилин». Не починайте з перевстановлення драйверів на 300 ноутбуках. Не починайте з відключення безпеки. Почніть з доведення межі відмови.

Перший: де відмова — підключення/встановлення чи доставка завдань?

З ураженого клієнта: чи можете відкрити \\PRINT01 в Explorer? Якщо ні — це SMB/auth/розв’язування імен.
Чи можете додати принтер, але завдання зависають? Це шлях сервер→пристрій або pipeline спулера.
Працює для локального адміністратора, але не для користувачів? Це Point and Print / встановлення драйвера / привілеї.

Другий: перевірте переговори SMB і метод автентифікації

Перевірте, чи вимагається SMB-підписування на одній стороні, а інша не підтримує/не використовує його.
Перевірте, чи використовується Kerberos (добре) або відбувається відкат до NTLM (який тепер може бути заблокований).
Перевірте, чи намагається застосуватися гостьовий доступ (тепер часто заблокований).

Третій: перегляньте журнали спулера і сервісу друку для фактичного коду помилки

На клієнті: журнали PrintService і System для подій підключення та подій драйверів.
На сервері: журнали PrintService Admin і Operational, а також журнал Security для помилок автентифікації.

Якщо запам’ятати лише одне: знайдіть першу помилку в ланцюгу. Помилки друку каскадують; остання помилка часто — лише фінальна скарга, а не причина.

Практичні завдання: команди, очікуваний вивід, і що означає вивід

Ці завдання написані так, ніби ви на виклику і намагаєтеся завершити інцидент, не повертаючи мережу у 2009 рік. Кожне завдання включає: команду, приклад виводу, що це означає і рішення, яке потрібно ухвалити.

Завдання 1: Підтвердити SMB-зв’язок із сервером друку (з боку клієнта)

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

Що це означає: Ви можете автентифікуватися та перелічити шари. Наявність PRINT$ — хороший знак (шар драйверів існує). Рядок «SMB1 disabled» — інформаційне повідомлення від smbclient; тут це не помилка.

Рішення: Якщо перелік працює, мережевий шлях і базова автентифікація в порядку. Перейдіть до політик встановлення драйверів і журналів спулера. Якщо перелік не вдається з NT_STATUS_ACCESS_DENIED або логон-фейлом — зосередьтеся на автентифікації/жорсткій політиці.

Завдання 2: Перевірити, що розв’язування імен не є мовчазним вбивцею

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

Що це означає: DNS-розв’язування працює на цій машині. Якщо ваші Windows-клієнти не можуть розв’язати — у вас split-horizon DNS, список суфіксів пошуку або проблема сегментації.

Рішення: Якщо розв’язування не працює, припиніть звинувачувати жорсткість SMB. Виправте DNS спочатку або використовуйте FQDN у розгортаннях.

Завдання 3: Перевірити, який діалект SMB та функції безпеки узгоджуються (точка зору 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

Що це означає: SMB3 працює до шару драйверів. Якщо примусове SMB3 не вдається, але за замовчуванням працює — у вас може бути проблема з даунгрейдом/сумісністю. Якщо SMB3 працює, але Windows-клієнти падають — ймовірно політика/драйвер/RPC-шлях, а не транспорт SMB.

Рішення: Залишайте SMB3; не вмикайте SMB1, щоб «запрацювало». Якщо SMB3 не працює — перевірте конфігурацію SMB на сервері і рівень патчів.

Завдання 4: Підтвердити, що сервер друку фактично шарить принтери (перевірка Windows server через PowerShell по WinRM з jump box із 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

Що це означає: Принтери шаряться і мають прив’язки драйверів.

Рішення: Якщо Shared false або ShareName порожнє — «шеринг зламаний», але це адміністраторська конфігурація, а не жорсткість SMB. Виправте налаштування шарингу і дозволи.

Завдання 5: Перевірити, чи служба Print Spooler працює (на сервері)

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

Що це означає: Спулер запущено. Якщо він зупинений, інше не має значення.

Рішення: Якщо він зупинений — перевірте чому (краш, політика, жорсткість безпеки, що вимкнула його на серверах, які не повинні спулити). Запускайте його лише на серверах, які мають друкувати; в інших випадках залишайте вимкненим з міркувань безпеки.

Завдання 6: Забрати події PrintService Admin навколо часу відмови (на сервері)

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

Що це означає: Це питання дозволів/автентифікації на шарингу або RPC-викликах. Помилка 0x5 — класичний access denied.

Рішення: Перевірте дозволи шарингу, дескриптори безпеки та будь-які нові політики, що обмежують операції з драйверами принтерів або віддалене адміністрування.

Завдання 7: Перевірити клієнтські події PrintService Operational (з боку клієнта через віддалений 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.

Що це означає: Клієнт намагався підключитися, але зіштовхнувся з відомим класом помилок жорсткості RPC/друку, які часто проявляються як 0x0000011b.

Рішення: Не повторюйте механічно реєстровий хак. Підтвердіть несумісність патчів сервера/клієнта, налаштування приватності/автентифікації RPC і чи середовище залежить від застарілої поведінки. Виправляйте, вирівнюючи рівні патчів і коригуючи політику контрольовано.

Завдання 8: Підтвердити, чи сервер вимагає SMB-підписування (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

Що це означає: Сервер вимагає SMB-підписування. Старі клієнти або апарати можуть не працювати. Сучасні Windows-клієнти мають впоратися, але з’являються крайові випадки, якщо є проміжні пристрої або застарілі компоненти.

Рішення: Тримайте вимогу підписування, якщо немає перевіреної сумісної проблеми. Якщо щось не може підписуватися — замініть або ізолюйте; не послаблюйте сервер друку для одного впертого пристрою.

Завдання 9: Підтвердити налаштування SMB-підписування на клієнті (Windows)

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

Що це означає: Клієнт підтримує підписування і використовуватиме його, якщо сервер вимагатиме. Це має бути нормально.

Рішення: Якщо EnableSecuritySignature false — це червоний прапор. Виправте через політику; інакше SMB-сеанси до загартованих серверів можуть не встановлюватися.

Завдання 10: Перевірити, чи NTLM блокується (підказки політики 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

Що це означає: Це значення штовхає до NTLMv2 лише (добре), але само по собі не доводить, що NTLM блокується. Проте це говорить, що кінцева точка не в режимі «все дозволено».

Рішення: Якщо друк залежить від відкату до NTLM через поломаний Kerberos — тепер він може впасти. Виправте Kerberos (DNS, SPN, час), а не послаблюйте NTLM-контролі.

Завдання 11: Підтвердити, що Kerberos працює для сервера друку (у контексті доменного клієнта)

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

Що це означає: Клієнт має Kerberos-токен для CIFS до сервера друку. Це сильний доказ того, що SMB-частина може автентифікуватися за Kerberos.

Рішення: Якщо ви не бачите CIFS-токена, а очікували — виправте DNS/SPN і синхронізацію часу. Дивно багато «друк зламався після оновлення» — насправді «Kerberos ледве працював, а оновлення перестало це терпіти».

Завдання 12: Перевірити дозволи та вміст шару драйверів (на сервері)

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

Що це означає: PRINT$ вказує на очікувану директорію драйверів. Якщо хтось «оптимізував» її на інший шлях або попсував дозволи — клієнти можуть не завантажувати драйвери.

Рішення: Якщо PRINT$ відсутній або переміщений — поверніть його, якщо немає дисциплінованої альтернативи. Друк — не місце для креативних файлових експериментів.

Завдання 13: Спробувати додати підключення принтера без інтерактиву (на клієнті)

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

Що це означає: Це вказує на невідповідність на сервері щодо доступності драйвера. Або драйвер відсутній на сервері, або він не сумісний з архітектурою/типом клієнта.

Рішення: Виправте сховище драйверів сервера і стратегію пакування. Не «виправляйте», дозволяючи клієнтам тягнути випадкові драйвери від виробника з інтернету.

Завдання 14: Перевірити, які драйвери встановлені на сервері друку (на сервері)

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

Що це означає: Ви бачите суміш типів драйверів і версій. Середовища з великою кількістю вендорських Type 3 драйверів найчастіше страждають при посиленні політик.

Рішення: Стандартизуйте драйвери де можливо. Надавайте перевагу підписаним, упакованим драйверам. Скорочуйте «сплеск» драйверів як зменшуєте образи контейнерів: менше, відомих і патчених.

Завдання 15: Підтвердити порт і доступність пристрою з сервера (мережева санітарка на сервері)

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

Що це означає: Сервер може дістатися до принтера на JetDirect/9100. Якщо це не так — ваше «після оновлення» відключення може бути фактично зміною фаєрволу або посиленою сегментацією мережі, що збіглася з патчингом.

Рішення: Якщо доступність порту не працює — виправте маршрутизацію/фаєрвол/VLAN ACL. Налаштування драйверів і SMB не допоможуть при заблокованому порті.

Завдання 16: Перевірити, чи спулер блокується правилами фаєрволу (на сервері)

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

Що це означає: Базові вхідні правила увімкнені для профілю Domain. Якщо ваш сервер у профілі Public через плутанину NLA, ці правила можуть не застосовуватися.

Рішення: Якщо правила вимкнені або є невідповідність профілю — виправте мережевий профіль і політику фаєрволу, а не відкривайте довільні порти.

Три корпоративні короткі історії з фронту друку

Коротка історія 1: Інцидент через хибне припущення («Це просто принтерний шар»)

На папері у них було акуратно: сервер друку Windows, кілька спільних черг принтерів і GPO, що призначає принтери за OU. Оновлення планували щомісяця. Першого понеділка після патч-нічки служба підтримки отримала шквал звернень: нові ноутбуки не могли додати принтери. Існуючі в основному працювали, що робило проблему періодичною і тому «таємничою».

Хибне припущення було простим: вони думали, що проблема в об’єктах принтерів. Перезапустили спулер, знову пошарили принтери, перевстановили драйвери і навіть поміняли принтер. Нічого не допомогло. Користувачі зі старим кешованим драйвером продовжували друкувати, створюючи ілюзію, що система в порядку, а «нові пристрої» просто ламались.

Справжня межа відмови була у встановленні драйверів. Посилення змінило поведінку Point and Print для звичайних користувачів. Середовище тихо залежало від того, що користувачі тягнули драйвери із сервера без підвищення привілеїв. Патч не «зламав друк»; він зламав «мовчазне розповсюдження ПЗ через сервер друку».

Коли вони поставили це як проблему розгортання ПЗ, рішення стало очевидним: упакувати і затвердити драйвери правильно, визначити довірені сервери друку через політику і припинити допустити випадкові черги як точки розповсюдження драйверів. Після цього принтери знову правильно мапилися.

Висновок: якщо друк працює на машинах, що вже мають драйвер, не чіпайте принтер. Чіпайте політику драйверів і модель довіри.

Коротка історія 2: Оптимізація, яка відштовхнулася назад (переміщення PRINT$ на «швидше сховище»)

Ще одна компанія мала сервер друку, який також виконував роль файлового сервера (так, я зітхнув). Хтось помітив, що системний диск перевантажений, і вирішив «оптимізувати», перемістивши каталоги спулера і драйверів на окремий том. Зміна була виконана обережно у вікні технічних робіт і дійсно покращила метрики диска.

Потім прийшло оновлення жорсткості. Раптом деякі клієнти відмовлялися завантажувати драйвери, а інші отримували пошкоджені інсталяції драйверів. Команда спочатку звинуватила патч, але патч був лише подією, яка зробила систему менш терпимою до їх креативного розміщення файлів.

Переміщені шляхи мали іншу наслідуваність ACL, ніж дефолтні Windows-параметри. За старої поведінки клієнти все ще могли дістати потрібне. За нової — суворіші перевірки та явніші шаблони доступу — ті особливості ACL стали фатальними. Завантаження драйверів падало. Принтери з’являлися, але друкували брак або нічого.

Вони відкотили релокацію і стандартизували дефолтні шляхи спулера/драйверів з контрольованими дозволами. Тиск диска повернувся, але друк стабілізувався. Пізніше вони вирішили проблему зберігання, розділивши ролі і правильно підібравши розміри, а не виконуючи хірургію в нутрощах Windows-друку.

Висновок: друк краще витримує нудні дефолти, ніж креативну оптимізацію. Оптимізуйте після того, як зможете довести інваріанти, на які ви покладаєтесь.

Коротка історія 3: Нудна, але правильна практика, що врятувала ситуацію (кільця патчів і одна «жертвенна» поверхня)

Середнє підприємство зробило дещо глибоко немодне: вони мали кільця патчів для кінцевих точок і серверів і включали друк у пре-прод валідацію. Не «відкрили Word раз». Вони мали скриптований smoke-test: додати принтер із сервера, роздрукувати односторінковий тест, перевірити, що він пішов із черги, і впевнитися, що журнал завдань у web-UI принтера оновився.

Коли з’явилося посилення, їх пілотне кільце одразу виявило помилку: звичайні користувачі не могли додати певну чергу вендора. Журнали показували запит на встановлення драйвера, який не можна завершити. Вони призупинили широке розгортання, але нічого не відкотили.

Замість цього вони використали час, щоб переключити ту чергу на упакований, підписаний універсальний драйвер, вже затверджений, і звузили політику «довірених серверів друку» до свого кластера друку. Коли оновлення дійшло до решти фліту, проблема вже була в минулому.

Найважливіше: вони задокументували рішення: вони не «виправлятимуть», послаблюючи SMB-підписування або знову вмикаючи гостьовий доступ. Вони виправляли, зробивши друк сумісним із сучасною автентифікацією і управлінням драйверами.

Висновок: невелике кільце патчів плюс реальний тест друку перетворює потенційний інцидент в простий лист у пошті.

Поширені помилки: симптом → корінь → виправлення

Симптом: Користувачі отримують «Windows не може підключитися до принтера» одразу.
Корінь: SMB/RPC заблоковано через невідповідність профілю фаєрвола (Domain vs Public) або відсутні правила «File and Printer Sharing».
Виправлення: Виправте мережевий профіль/NLA, увімкніть відповідні групові правила фаєрволу для Domain, підтвердіть доступність RPC-ендпойнтів.
Симптом: Помилка 0x0000011b при додаванні спільних принтерів після патчу.
Корінь: Посилення RPC/spooler виявило несумісність або розбіжність патчів між клієнтами і сервером.
Виправлення: Вирівняйте рівні патчів, перевірте політики спулера, уникайте механічних реєстрових понижень; виправте стратегію драйверів/пакетів.
Симптом: Працює для адміністраторів, не працює для звичайних користувачів — підказки, які ті не можуть підтвердити.
Корінь: Обмеження Point and Print тепер вимагають підвищення або списку довірених серверів для встановлення/оновлення драйверів.
Виправлення: Налаштуйте політику довірених серверів друку, попередньо розгорніть драйвери, використовуйте підписані/упаковані драйвери; розгорніть через керовані інструменти.
Симптом: Тільки деякі моделі відмовляються; інші — в порядку.
Корінь: Пакет вендора — legacy Type 3, непідписаний або несумісний; невідповідність типів архітектур.
Виправлення: Замініть на відомий універсальний драйвер; стандартизуйте; видаліть покинуті драйвери із сервера.
Симптом: Можна переглядати \\PRINT01, але не видно принтерів або не вдається підключитися.
Корінь: RPC до спулера заблокований/відмовлено, тоді як SMB працює; tightened permissions на спулері/об’єктах принтерів.
Виправлення: Перевірте правила фаєрволу RPC для спулера, перевірте журнали PrintService, підтвердіть ACL принтерів і делегування.
Симптом: Друкування працює через прямий IP, але не через спільну чергу.
Корінь: Шлях спільної черги падає на розповсюдженні драйверів або автентифікації спулера; сам пристрій в порядку.
Виправлення: Виправте шлях сервера друку; не «вирішуйте» перетворенням усіх на прямий IP-друк, якщо вам не подобається хаос.
Симптом: Підключення працює тільки по IP сервера, але не по імені.
Корінь: Невідповідність DNS/SPN спричиняє помилку Kerberos, що викликає відкат до NTLM, який блокується.
Виправлення: Виправте DNS-записи, забезпечте правильні SPN, використовуйте FQDN у шарах та GPO, підтвердіть синхронізацію часу.
Симптом: Старий апаратний сервер друку зник після оновлення.
Корінь: SMB1 вимкнено або гостьовий доступ видалено; апарат залежить від старої поведінки SMB.
Виправлення: Замініть/оновіть апарат; тимчасово ізолюйте його, якщо критичний, але не вмикайте SMB1 по всьому парку.

Другий жарт (короткий, по темі): Якщо ви знову ввімкнете SMB1, щоб принтер почав працювати, принтер друкуватиме — і тікети інцидентів теж.

Чеклісти / покроковий план

Покроковий план для продакшн-середовищ (робіть це, а не настрій)

Повторіть помилку на одному клієнті і одній черзі принтера. Виберіть чисту машину, що ніколи не друкувала (без кешованого драйвера). Задокументуйте точний код помилки та часову мітку.
Визначте, де збій: підключення/автентифікація (SMB/RPC), встановлення драйвера (Point and Print) або доставка завдання (сервер→принтер).
Перевірте здоров’я сервера в першу чергу: спулер запущений, принтерні шари присутні, PRINT$ доступний, очевидних помилок PrintService немає.
Перевірте метод автентифікації на клієнті: перевірте Kerberos-токени для CIFS і коректність розв’язування імен.
Вирівняйте рівні патчів: переконайтеся, що сервер друку і клієнти знаходяться в підтримуваному, узгодженому стані патчів. Розбіжність патчів — класичний патерн «половина парку зламалася».
Відпрацюйте стратегію драйверів: зведіть до кураторського набору підписаних, упакованих драйверів. Видаліть покинуті вендорські драйвери, що вже не встановлюються в умовах посилення.
Налаштуйте «довірені сервери друку» через політику: явно перелічіть ваші сервери друку. Тримайте список коротким. Якщо у вас 40 — це не сервери друку; це принтери, які прикидаються інфраструктурою.
Обмежте, хто може встановлювати драйвери на серверах: друк — не демократія. Обмежте інсталяцію драйверів для адміністраторів/керованих процесів зміни.
Повторно протестуйте зі стандартним користувачем: додавання принтера має вдаватися без локальних прав адміністратора. Якщо потрібно адміністраторське, ви не вирішили проблему для організації.
Розгортайте по кільцях: пілотна група, потім поверх за поверхом або OU за OU. Друк добре підходить для поступового розгортання, бо вплив користувача одразу помітний.
Моніторте журнали: журнали PrintService, журнал Security для помилок автентифікації і шаблони тікетів служби. Тренди мають значення.
Запишіть інваріант: «Ми вимагаємо SMB-підписування, SMB1 відключено, гостьовий доступ відключено; друк має працювати в цих межах.» Зробіть це політикою, а не пам’яттю.

Чекліст безпекової позиції (зберегти досягнення)

SMB1 відключено на клієнтах і серверах, якщо немає ізольованого винятку з датою виведення з експлуатації.
SMB-підписування обов’язкове на серверах, що надають шари (включно з PRINT$).
Гостьовий доступ вимкнено; використовуйте реальну автентифікацію (Kerberos/NTLMv2) і коректні дозволи.
Обмежте, хто може адмініструвати сервери друку; ставтеся до них як до серверів застосунків.
Стандартизуйте драйвери; надавайте перевагу підписаним і упакованим.

Операційний чекліст (зменшити повторення)

Кільця патчів, що включають принаймні один сервер друку і кілька різних клієнтів.
Скриптований smoke-test друку, що покриває: додати принтер, роздрукувати тестову сторінку, підтвердити відвантаження черги.
Контроль конфігураційних відхилень: базова конфігурація SMB і налаштування PRINT$.
Інвентар моделей принтерів і версій драйверів у використанні.

Питання та відповіді (FAQ)

1) Чому це зламалося одразу після оновлення, якщо нічого не змінювали на сервері друку?

Тому що оновлення змінило правила взаємодії: вимоги автентифікації, поведінку RPC і політики встановлення драйверів. Ваша стара конфігурація могла «працювати», покладаючись на ліберальні значення за замовчуванням.

2) Чи варто просто відкотити оновлення?

Тільки як тимчасовий захід, і тільки якщо у вас є чіткий план безпечного повторного застосування фіксів. Відкат — не вирішення; це позику з відсотками, і відсотки — «серйозність майбутніх інцидентів».

3) Чи дійсно SMB тут задіяний? Я думав, друк — це RPC.

Появляються обидва. RPC використовується для операцій спулера, але SMB часто забезпечує розповсюдження драйверів (PRINT$) і доступ до шарів. Жорсткість будь-якого з шарів може виглядати як «зламаний шар принтера».

4) Чому це працює для деяких користувачів/машин, але не для інших?

Через кешування і привілеї. Машини, що вже мали встановлений драйвер, можуть продовжувати друкувати, навіть якщо нові інсталяції драйверів заблоковані. Адміністратори можуть підтвердити підказки, які звичайні користувачі не можуть. Розбіжність у патчах між клієнтами також може робити поведінку непослідовною.

5) Який найбезпечніший шлях відновити друк без послаблення безпеки?

Вирівняйте патчі, виправте Kerberos/розв’язування імен, стандартизуйте підписані упаковані драйвери і явно налаштуйте довірені сервери друку. Тримайте SMB-підписування увімкненим; SMB1 — вимкненим; гостьовий доступ — вимкненим.

6) Чи можуть Samba (Linux) сервери друку також постраждати?

Так. Якщо Windows-клієнти посилюють вимоги (підписування, автентифікація, правила драйверів), Samba-сервери, налаштовані ліберально, можуть більше не відповідати очікуванням. Також, у Samba «шеринг принтера» часто залежить від того, як обробляються драйвери — багато організацій взагалі уникають Point and Print і керують драйверами через інструменти для кінцевих точок.

7) Який код помилки шукати насамперед?

Шукайте першу подію помилки поруч із часом спроби підключення в журналах PrintService (клієнта і сервера). Коди на кшталт 0x0000011b і 0x00000005 швидко звужують поле, але не зупиняйтеся на коді — корелюйте з журналами автентифікації.

8) Чи є прямий IP-друк хорошим обходом?

Як тимчасовий обхід для невеликої кількості важливих користувачів — можливо. Як стратегія для всього фліту — зазвичай провалюється: повертається сплеск драйверів, конфігурації дрейфують, і ви втрачаєте централізований аудит і контроль черг. Виправляйте інфраструктуру друку, якщо ви не плануєте її виводити з експлуатації.

9) Як довести, що проблема пов’язана з Kerberos/NTLM?

Перевірте наявність Kerberos-токенів CIFS до сервера друку, перегляньте журнали Security на предмет використання або відмов NTLM, і підтвердіть DNS/SPN. Якщо доступ по імені не працює, але по IP працює — часто замішаний Kerberos.

10) Який розумний довгостроковий підхід, якщо нас постійно б’ють зміни в друку?

Трактуйте друк як платформу застосунків: мінімум довірених серверів, кураторські драйвери, автоматизоване розгортання, кільця патчів і спостережуваність. Якщо це звучить як забагато роботи — ви вже платите цю ціну, просто у вигляді простоїв.

Висновок: практичні подальші кроки

Спільний доступ до принтерів не «випав просто так». Ваше середовище досягло межі, де застарілі припущення про друк зустрілися з сучасною безпекою. Оновлення не створили складність; вони її виявили.

Зробіть наступне, у порядку пріоритету:

Пройдіть швидку діагностику: визначте, чи відмова на рівні підключення/автентифікації, встановлення драйвера чи доставки завдання.
Зберіть перші релевантні події PrintService з клієнта та сервера і одну точку даних з Security/автентифікації (Kerberos-токен або відмова NTLM).
Вирівняйте рівні патчів сервера друку і клієнтів. Розбіжність патчів — прихований множник відмов.
Виправте управління драйверами: менше драйверів, підписані/упаковані, попередньо розгорнуті де можливо.
Явно налаштуйте довірені сервери друку. Припиніть дозволяти «будь-якому серверу з шаром» ставати точкою розповсюдження драйверів.
Тримайте SMB-підписування обов’язковим, SMB1 відключеним, гостьовий доступ вимкненим. Якщо щось не може з цим жити — це не «legacy», це «кандидат на заміну».

Парафраз ідеї від Werner Vogels (CTO Amazon): Усе ламається; стійкість походить від проєктування під цю реальність, а не від надії, що компоненти працюватимуть.

Схожі статті

Пекло принтерів: індустрія, яку всі однаково ненавидять Чому драйвери принтерів стали великими: зайвий блоат, якого ніхто не просив