Укріплення SMB: виправити «Доступ заборонено» без повторного ввімкнення SMB1

Що насправді означає «Доступ заборонено» (це не одна проблема)

SMB — це стек рішень. «Доступ заборонено» — це користувацьке узагальнення, коли будь-яке з наведених рішень працює проти вас:

• Узгодження протоколу: клієнт і сервер домовляються про діалекти SMB (SMB2/SMB3) і можливості (підписування, шифрування, multichannel). Якщо узгодження не відбувається, ви можете побачити «Доступ заборонено», «The specified network name is no longer available» або мовчанку/падіння сумісності залежно від клієнта.
• Автентифікація: клієнт доводить особу за допомогою Kerberos, NTLMv2 або локальних облікових записів. Збої тут можуть проявлятися як відмова в доступі, запити на неправильний пароль або «Logon failure».
• Авторизація: після автентифікації токен перевіряється проти дозволів шару шеру і файлових ACL. Це класичний випадок «ви — це ви, але вам усе одно заборонено».
• Політика та налаштування жорсткості: сервер вимагає підписування SMB; клієнт цього не робить. Сервер вимагає шифрування; шар не налаштований; клієнт застарілий. Доменна політика забороняє NTLM. Такі випадки виглядають як відмова у доступі, бо сервер відмовляється продовжувати.
• Розв’язання імен / спрямування SPN: Kerberos чутливий до хостнеймів. Неправильне ім’я хоста, псевдонім без SPN або зсув часу можуть призвести до падіння автентифікації або прямої відмови.

Операційно корисний підхід: «Доступ заборонено» — це задача класифікації. Ви не «ремонтуєте SMB». Ви знаходите, які ворота зачинені.

Цікаві факти та історичний контекст (коротко, корисно)

1. SMB починався як протокол обміну файлами епохи DOS і пізніше став «CIFS» в епоху Windows NT/2000 — та сама родина, різні бренди та набори можливостей.
2. SMB2 (Vista/Server 2008) був суттєво переписаний, щоб зменшити «балакучість» і підвищити продуктивність по мережах з великою затримкою.
3. SMB3 (Windows 8/Server 2012) додав шифрування на рівні протоколу — VPN не потрібен для конфіденційності на каналі.
4. Підписування SMB існувало задовго до масового використання в організаціях; це забезпечує цілісність, не шифрування, і часто примусово встановлюється доменною політикою з поважних причин.
5. Рух проти SMB1 прискорився після великих черв’яків, які експлуатували слабкості SMB1 і недбале патчування. Команди безпеки пам’ятають і довго не забувають.
6. Роль Samba — переклад: Unix-права, Windows ACL, відображення ідентичностей і мережна автентифікація сходяться в одному демоні. Саме переклад — місце для помилок і неправильних налаштувань.
7. «Доступ заборонено» може бути свідомою політикою безпеки: сучасне укріплення надає перевагу «закритому відмовленню» при невідповідності політик (наприклад, відмова NTLM), ніж тихому пониженню.
8. Kerberos чутливий до часу за визначенням; кілька хвилин зсуву годинника можуть перетворити робочий шер на фабрику «Доступ заборонено».

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

Перший: це автентифікація, авторизація чи узгодження протоколу?

• Спробуйте перелік шарів анонімно й під обліковим записом: якщо анонімний доступ не працює, але автентифікація працює, у вас змінилася політика гостя (це добре). Якщо автентифікація не працює — проблема в ідентичності або політиці. Якщо перелік працює, а відкриття папки ні — це авторизація (дозволи шару шер проти файлових ACL).
• Перевірте діалект і стан підписування: якщо клієнт пророблює переговори SMB1 або не може узгодити SMB2/3, це проблема сумісності/політики, а не просто «права».

Другий: перевірте відображення ідентичностей та членство в групах

• На AD/Samba членах сервера: якщо користувач мапиться на «nobody» або несподіваний UID/GID, файлові перевірки відмовлять, навіть якщо права шару шер виглядають правильними.
• На Windows-клієнтах: кешовані облікові дані й «неправильні користувацькі» сесії поширені. Одна застаріла сесія може отруїти всі спроби до того самого імені сервера.

Третій: перевірте невідповідності політик (обмеження NTLM, підписування, шифрування)

• Домен забороняє NTLM: Linux-клієнт, що використовує NTLM, отримає відмову, поки ви не перемкнете його на Kerberos (або не зміните політику, чого робити не варто).
• Підписування обов’язкове: старі клієнти або неправильно змонтовані шари не впораються.
• Шифрування обов’язкове: клієнт має підтримувати шифрування SMB3 і погодити його.

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

Практичні завдання: команди, виводи та рішення (12+)

Це перевірки, які я запускаю, коли хтось пише «SMB access denied» й чекає дива. Кожне завдання включає: команду, приклад виводу і рішення, яке вона впливає.

Завдання 1: Підтвердити, що сервер справді слухає порт 445

cr0x@server:~$ sudo ss -lntp | egrep ':445|:139'
LISTEN 0      128          0.0.0.0:445        0.0.0.0:*    users:(("smbd",pid=1223,fd=52))
LISTEN 0      128             [::]:445           [::]:*    users:(("smbd",pid=1223,fd=54))

Що це означає: SMB доступний на TCP-рівні. Якщо 445 не слухає — це ще не проблема з дозволами.

Рішення: Якщо 445 не слухає, виправте сервіс (smbd не запущено, прив’язано до неправильного інтерфейсу, проблеми з контейнерною мережею) перш ніж торкатися ACL.

Завдання 2: Перевірити правила фаєрволу для 445/tcp

cr0x@server:~$ sudo nft list ruleset | sed -n '1,140p'
table inet filter {
  chain input {
    type filter hook input priority 0;
    policy drop;
    ct state established,related accept
    iif "lo" accept
    tcp dport 22 accept
    tcp dport 445 ip saddr 10.20.0.0/16 accept
  }
}

Що це означає: Лише 10.20.0.0/16 може дістатися до SMB. Інші будуть отримувати відмови незрозумілими шляхами.

Рішення: Якщо клієнти поза цим CIDR, виправте мережеву політику. Не налагоджуйте SMB, коли пакети спеціально відкидаються.

Завдання 3: Подивитися, які діалекти SMB Samba погодить

cr0x@server:~$ testparm -sv 2>/dev/null | egrep -i 'server min protocol|server max protocol'
	server min protocol = SMB2_10
	server max protocol = SMB3_11

Що це означає: SMB1 вже вимкнено. Добре. Це також дає очікування для старіших клієнтів.

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

Завдання 4: Перевірити визначення шару і доступність для огляду

cr0x@server:~$ testparm -s 2>/dev/null
Loaded services file OK.
Weak crypto is allowed by GnuTLS (e.g. NTLM as a compatibility fallback)

Server role: ROLE_MEMBER_SERVER

[global]
	workgroup = EXAMPLE
	security = ADS

[finance]
	path = /srv/samba/finance
	read only = No

Що це означає: Шер існує і вказує на реальний шлях (ми перевіримо це далі). «Weak crypto is allowed» — не вирок, але підказка про використовувані режими автентифікації.

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

Завдання 5: Перевірити файловий шлях, власника й біти режиму

cr0x@server:~$ sudo ls -ld /srv/samba/finance
drwxrwx--- 3 root "EXAMPLE\\finance-rw" 4096 Jan 12 09:40 /srv/samba/finance

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

Рішення: Якщо права 700 або власник некоректний, ви отримаєте відмову навіть при правильному «valid users». Виправте POSIX-права або ACL першими.

Завдання 6: Перевірити SELinux/AppArmor, що мовчки блокує

cr0x@server:~$ sudo getenforce
Enforcing

cr0x@server:~$ sudo ausearch -m avc -ts recent | tail -n 5
type=AVC msg=audit(1739201151.441:812): avc:  denied  { read } for  pid=1223 comm="smbd" name="finance" dev="sda2" ino=393220 scontext=system_u:system_r:smbd_t:s0 tcontext=unconfined_u:object_r:default_t:s0 tclass=dir permissive=0

Що це означає: Ядро відмовляє smbd незалежно від конфігурації Samba. Це часто виглядає як «права», але насправді не ними є.

Рішення: Виправте мітки контексту (наприклад, встановіть правильний контекст) замість розширення дозволів шару.

Завдання 7: Довести, що відображення ідентичностей працює (AD user → UID/GID)

cr0x@server:~$ id "EXAMPLE\\alice"
uid=220110(EXAMPLE\alice) gid=220051(EXAMPLE\domain users) groups=220051(EXAMPLE\domain users),220220(EXAMPLE\finance-rw)

Що це означає: Користувач розпізнаний і входить до очікуваної групи.

Рішення: Якщо id не працює або групи відсутні, виправте winbind/sssd/idmap перед тим, як торкатися ACL. Неправильні ID = неправильні рішення доступу.

Завдання 8: Підтвердити, що сервер може спілкуватися з AD і бачить домен

cr0x@server:~$ wbinfo -t
checking the trust secret for domain EXAMPLE via RPC calls succeeded

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

Рішення: Якщо це завершується помилкою, «Доступ заборонено» може бути через те, що сервер не може перевірити облікові дані. Виправте приєднання до домену, DNS, час і keytab-и.

Завдання 9: Перевірити здоров’я Kerberos і час (нудний винуватець)

cr0x@server:~$ timedatectl | sed -n '1,8p'
Local time: Wed 2026-02-05 14:31:10 UTC
Universal time: Wed 2026-02-05 14:31:10 UTC
RTC time: Wed 2026-02-05 14:31:10
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active

cr0x@server:~$ kinit alice@EXAMPLE.COM
Password for alice@EXAMPLE.COM:

cr0x@server:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: alice@EXAMPLE.COM

Valid starting     Expires            Service principal
02/05/26 14:31:25  02/06/26 00:31:25  krbtgt/EXAMPLE.COM@EXAMPLE.COM

Що це означає: Час синхронізовано, Kerberos-квитки працюють. Якщо час збитий, Kerberos падає, а клієнти або відступають на інші методи, або просто отримують відмову залежно від політики.

Рішення: Якщо NTP не активний або kinit не проходить, виправте час/DNS/доступність KDC. Не послабляйте політику NTLM як тимчасове рішення.

Завдання 10: Відтворити з боку сервера за допомогою smbclient (видаляє UX Windows)

cr0x@server:~$ smbclient -m SMB3 -L //files01 -U 'EXAMPLE\alice'
Password for [EXAMPLE\alice]:
	Sharename       Type      Comment
	---------       ----      -------
	finance         Disk
	IPC$            IPC       IPC Service (Samba)
SMB1 disabled -- no workgroup available

Що це означає: Користувач може перерахувати шери по SMB3. Рядок «SMB1 disabled» інформаційний і нормальний.

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

Завдання 11: Спробувати доступ до шару й операцію з файлом

cr0x@server:~$ smbclient -m SMB3 //files01/finance -U 'EXAMPLE\alice' -c 'ls; mkdir _diag_test; rmdir _diag_test'
Password for [EXAMPLE\alice]:
  .                                   D        0  Wed Feb  5 14:22:01 2026
  ..                                  D        0  Wed Feb  5 13:59:11 2026
  budgets                             D        0  Tue Feb  4 18:04:41 2026

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

Рішення: Якщо mkdir завершується ACCESS_DENIED, перевірте «write list» на рівні шару і файлові ACL; якщо ls не працює, перевірте права execute/search на директоріях.

Завдання 12: Проінспектувати журнали Samba за реальною причиною (не діалог Windows)

cr0x@server:~$ sudo tail -n 30 /var/log/samba/log.smbd
[2026/02/05 14:24:33.112233,  1] smbd/service.c:1234(make_connection_snum)
  create_connection_session_info: guest user (from session setup) not permitted to access this share (finance)
[2026/02/05 14:24:33.112544,  1] smbd/service.c:987(make_connection_snum)
  files01 (ipv4:10.20.5.44:51022) connect to service finance initially as user nobody (uid=65534, gid=65534) (pid 1422)

Що це означає: Клієнт підключається як гість/nobody. Ось чому доступ заборонено — навіть якщо «alice» десь вводила пароль.

Рішення: Виправте переговори автентифікації (NTLM/Kerberos), менеджер облікових даних Windows або поведінку Samba «map to guest». Не розширюйте ACL, щоб допустити «nobody».

Завдання 13: Виявити налаштування «map to guest» і доступу гостя

cr0x@server:~$ testparm -sv 2>/dev/null | egrep -i 'map to guest|guest ok|restrict anonymous'
	map to guest = Bad User
	restrict anonymous = 2

Що це означає: Невідомі користувачі мапляться в гостя. У поєднанні з «restrict anonymous» це може породити заплутані відмови.

Рішення: У жорстких налаштуваннях краще відмовляти автентифікації, ніж мапити в гостя. Розгляньте map to guest = Never, якщо у вас немає контрольованого випадку використання гостя.

Завдання 14: Перевірити, чи немає на Windows застарілої сесії до сервера під іншим користувачем

cr0x@server:~$ smbstatus -b
Samba version 4.18.6
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing
--------------------------------------------------------------------------------------------------------------------------------------------
2311    bob          domain users  10.20.5.44 (ipv4:10.20.5.44:51210)        SMB3_11           -                    partial(AES-128-CMAC)

Що це означає: Той клієнт вже має SMB-сесію як bob. Windows відома тим, що повторно використовує сесії за іменем сервера, і тоді «Доступ заборонено» виникає, коли ви очікували alice.

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

Завдання 15: Перевірити правила на рівні шару («valid users», «write list»)

cr0x@server:~$ grep -nE '^\[finance\]|valid users|write list|read only' /etc/samba/smb.conf
42:[finance]
45:	valid users = @EXAMPLE\finance-rw
46:	read only = no

Що це означає: Доступ дозволено тільки членам групи finance-rw. Це розумно. Але розв’язання груп має працювати.

Рішення: Якщо є опечатка в імені групи або префікс домену невірний — виправте. Якщо потрібен доступ лише для читання іншим — створіть окрему групу й вкажіть явне правило; не покладайтеся на членство «Domain Users».

Завдання 16: Перевірити, чи вимагається підписування SMB і що робить сервер

cr0x@server:~$ testparm -sv 2>/dev/null | egrep -i 'server signing|client signing'
	server signing = mandatory
	client signing = mandatory

Що це означає: Сервер вимагає підписування SMB. Деякі клієнти/параметри монтування не впораються, і вони будуть падати так, ніби проблеми з доступом.

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

Короткий жарт №1: SMB1 — як телефон-раскладушка: ностальгічний, дивно надійний, але зовсім не той, кого ви хочете ставити охоронцем зарплатні.

Укріплення, яке не порушує доступ

Припиніть ставитися до SMB1 як до тимчасової сумісності

Повторне ввімкнення SMB1, щоб «полагодити доступ», зазвичай приховує одну з цих проблем:

• Старий пристрій підтримує лише SMB1 (багатофункціональні пристрої — часті винуватці).
• Клієнт неправильно налаштований для SMB2/3 (неправильні параметри монтування, зламаний DNS, неправильне ім’я хоста).
• Невідповідність політик автентифікації (обмеження NTLM, падіння Kerberos через час або SPN).

SMB1 ховає реальну проблему, змінюючи шлях узгодження. Це не рішення; це переадресація сигналу тривоги на інший динамік.

Використовуйте SMB2/3 навмисно: діалекти, підписування, шифрування

Укріплення SMB — це не «увімкнути всі ручки». Це вибір правильних ручок для вашої моделі загроз і бази клієнтів.

• Діалекти: Встановіть server min protocol = SMB2_10 (або вище). SMB2_10 — прагматичний мінімум для сучасних Windows і більшості Linux-клієнтів.
• Підписування: Тримайте server signing = mandatory на членських серверах у доменних середовищах, якщо у вас немає вимірюваної причини щодо продуктивності. Підписування запобігає підмінянню й ускладнює деякі атаки пониження.
• Шифрування: Використовуйте шифрування SMB3 для шарів, що перетинають недовірені мережі або містять чутливі дані. Але розумійте операційні витрати: завантаження CPU, ускладнення налагодження та сумісність клієнтів.

Зробіть авторизацію нудною: ACL шару + файлові ACL + відображення ідентичностей

Найшвидший шлях до реєстрації «Доступ заборонено» — дозволити суперечність між дозволами шару і файловими ACL. Виберіть модель:

• Модель A (рекомендовано): Використовуйте AD-групи як джерело істини. Керуйте доступом до шару за допомогою valid users і застосовуйте дискові ACL. Тримайте POSIX-біти мінімальними, але не вводьте в оману.
• Модель B: Використовуйте локальні POSIX-групи (не AD) і ретельно відображайте їх. Працює, але легко виникає дрейф між серверами.

У Samba шар «перекладу» — це відображення ідентичностей. Якщо idmap нестабільний, користувачі випадково втратять доступ після перезавантажень, оновлень або змін у домені.

Не ламайте Kerberos псевдонімами

Квитки Kerberos виписують для сервісних імен. Якщо користувачі підключаються до \\files-alias\share, а ваші SPN лише для files01, клієнти можуть відступити на NTLM або зовсім впасти, якщо NTLM заблоковано. Це може проявлятися як «Доступ заборонено», хоча пароль правильний.

Тримайте гостьовий доступ явним, а не випадковим

Гостьовий доступ або — свідоме робоче вимога, або — неправильна конфігурація. Посередині мало варіантів. Небезпечний варіант — «це гість, бо щось інше не вдалось». Якщо гостьові шери не потрібні, встановіть map to guest = Never, вимкніть гостьові шери і дозвольте помилкам автентифікації бути голосними.

Три корпоративні міні-історії (що насправді відбувається)

Міні-історія 1: Інцидент, спричинений хибним припущенням

Вони мігрували файловий сервер з застарілої Windows VM на новий Linux-бокс із Samba. План проекту був типовим оптимістичним: «Ті самі імена шерів, ті самі дозволи, перемикання вночі». Команда протестувала одним обліковим записом адміністратора, зайшла, створила папку, оголосила перемогу.

У понеділок вранці фінансовий відділ не міг нічого відкрити. HR міг переглядати, але не зберігати. Інженери були в порядку, бо їхня група мала широкі Unix-права з попередньої ери. Заявки накопичувалися з однаковим скріншотом: «Доступ заборонено». На чергуванні інженер, як це часто буває, шукав найшвидший важіль. Хтось сказав: «Можливо, старий сервер використовував SMB1?»

Ні. Хибне припущення було тонше: вони вважали, що Windows-права шару — це все. На Linux-боці дерево директорій мало POSIX-права, встановлені надто строго на одному батьківському каталозі. Адмінські тести пройшли, бо адміністратори мапилися на привілейовану групу. Звичайні користувачі потрапляли на «no execute/search» на проміжній директорії і отримували відмову. Windows UI повідомляв це так, ніби файл особисто їх не любить.

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

Міні-історія 2: Оптимізація, яка обернулась проти

Інша компанія мала проблеми з продуктивністю на завантаженому шерi. Користувачі скаржилися на повільні переліки й відкриття файлів. Інженер виявив, що підписування SMB додає накладні витрати. Вони змінили конфіг Samba, щоб підписування було «auto», і відсвяткували поліпшення на синтетичних тестах.

Через два тижні служба безпеки розгорнула політику домену, яка вимагала підписування для певних клієнтів і серверів. Раптом підмножина Windows-клієнтів почала падати при доступі до шару. Не завжди. Не голосно. Просто періодичні «Доступ заборонено» і «The request is not supported», залежно від версії клієнта і того, що він погодив.

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

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

Міні-історія 3: Нудна, але правильна практика, що врятувала ситуацію

Глобальна організація запускала Samba-членські сервера в кількох сайтах. Нічого особливого: AD-автентифікація, жорсткі шери, SMB3. Нудна практика: кожна зміна конфігу SMB вимагала канаркового тесту з трьох типів клієнтів (Windows, Linux CIFS mount і сервісний акаунт через smbclient), плюс перегляд журналів для відкатів автентифікації.

Одного кварталу рутинне оновлення ОС підтягнуло Samba з іншими дефолтами навколо NTLM і мапування гостя. Більшість команд би запустили оновлення й чекали скарг як безкоштовне QA. Ця команда запустила канарку. Linux CIFS mount почав падати з «permission denied», тоді як Windows працював.

Канарка вказала прямо на проблему: mount використовував NTLM, тоді як середовище очікувало Kerberos, і нова збірка Samba стала менш прощальною. Вони оновили параметри монтовання на Kerberos і відкоригували підхід для сервісних акаунтів. Користувачі навіть не помітили. Ось у чому суть.

Короткий жарт №2: Найнадійніша система — та, про яку ніхто не говорить на планерці, бо вона відмовилася стати «цікавим навчальним кейсом».

Типові помилки: симптом → корінна причина → виправлення

1) Симптом: Windows постійно просить облікові дані, а потім «Доступ заборонено»

Корінна причина: Використовується невірна ідентичність (кешовані облікові дані) або сервер відкидає метод автентифікації (NTLM вимкнено, Kerberos не працює).

Виправлення: Очистіть існуючі сесії до цього імені сервера, переконайтеся в правильності SPN/імені хоста, перевірте роботу Kerberos (kinit на Linux, правильний вхід у домен на Windows) і подивіться журнали Samba на наявність «mapped to guest» або блокувань NTLM.

2) Симптом: Можна перерахувати шер, але не можна відкрити підпапки

Корінна причина: Відсутня права «execute/search» на одній директорії в шляху або невідповідність успадкування між Windows ACL і POSIX.

Виправлення: Перевірте весь ланцюг директорій і ACL; не дивіться лише на кінцеву папку. У Samba розгляньте узгоджене оброблення ACL (наприклад, відповідні vfs objects) і переконайтеся, що відображення ідентичностей стабільне.

3) Симптом: Linux mount -t cifs повертає «Permission denied», Windows працює

Корінна причина: Linux-монт за замовчуванням використовує NTLM, а сервер очікує Kerberos або відкидає NTLM. Або Linux-клієнт узгоджує старіший діалект.

Виправлення: Монт у з Kerberos (sec=krb5) та вкажіть vers=3.1.1 (або принаймні SMB3). Переконайтеся, що машина має дійсні Kerberos-квитки і DNS правильний.

4) Симптом: Все поламалося після «відключення SMB1»

Корінна причина: Застарілий пристрій (сканер, NAS, вбудована ОС) підтримує тільки SMB1 або покладався на анонімну поведінку/гостьовий режим.

Виправлення: Замініть або оновіть пристрій, або ізолюйте його до виділеного legacy-сервера/VLAN з компенсуючими контролями. Не вмикайте SMB1 на основних файлових серверах.

5) Симптом: Доступ працює через \\server\share, але не через \\alias\share

Корінна причина: Невідповідність SPN Kerberos; псевдонім не зареєстрований, що призводить до NTLM fallback або відмови, коли NTLM заблоковано.

Виправлення: Використовуйте канонічне ім’я, зареєструйте відповідні SPN для псевдоніма або налаштуйте DFS правильно. Розглядайте архітектуру імен як частину дизайну автентифікації, а не косметики.

6) Симптом: Деякі користувачі в потрібній AD-групі все одно отримують відмову

Корінна причина: Членство в групі не видно через проблему з розміром токена, обмеженнями вкладених груп або невідповідностями idmap між серверами.

Виправлення: Зменшіть надмірне вкладення, перевірте відображення ідентичностей і перевірте ефективний список груп на сервері за допомогою id / getent group. Стабілізуйте діапазони idmap і бекенд.

7) Симптом: Журнали Samba показують, що користувач стає «nobody»

Корінна причина: Збої автентифікації мапляться в гостя (map to guest = Bad User) або winbind/sssd не можуть розв’язати ідентичність.

Виправлення: Вимкніть мапування в гостя, якщо воно не потрібне, виправте NSS-розв’язання, відновіть довіру приєднання до домену і підтвердьте wbinfo -t та id DOMAIN\\user.

8) Симптом: «Доступ заборонено» лише для записів, читання працює

Корінна причина: Параметр шару read only або невідповідність write list; файлові ACL забороняють створення/видалення; або антивірус/EDR блокує записи через політику SMB.

Виправлення: Підтвердьте опції шару Samba і протестуйте за допомогою smbclient mkdir/rmdir; потім інспектуйте файлові ACL. Якщо задіяні політики, координуйтеся з командами кінцевої безпеки, надаючи докази.

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

Покроково: виправити «Доступ заборонено» без послаблення SMB

1. Доведіть з’єднання: сервер слухає 445, фаєрвол дозволяє доступ для підмережі клієнта.
2. Підтвердьте політику діалектів: SMB1 вимкнено; SMB2/3 увімкнено. Переконайтеся, що клієнт це підтримує.
3. Відтворіть через smbclient: протестуйте перелік шарів і прості файлові операції з тими самими обліковими даними.
4. Читайте серверні журнали: визначте, чи користувач автентифікований, мапиться в гостя або падає через політику.
5. Перевірте відображення ідентичностей: id DOMAIN\\user і членство в групах відповідають очікуваному доступу.
6. Перевірте правила шару: valid users, read only, write list, force user/force group.
7. Перевірте файлові ACL по всьому шляху: забезпечте права execute/search і правильну поведінку успадкування.
8. Перевірте обов’язкові параметри безпеки: чи вимагається підписування? шифрування? чи обмежений NTLM?
9. Виправте невідповідність, а не симптом: оновіть параметри монтування клієнта, виправте SPN, синхронізацію часу, idmap, налаштуйте ACL.
10. Закріпіть результат: додайте канарковий тест і оповіщення за журналами для мапування в гостя/помилок автентифікації.

Чекліст укріплення, який не повинен спричинити інциденти доступу

• Встановіть SMB1 вимкненим політично (server min protocol на SMB2_10 або вище).
• Вимагайте підписування SMB у доменних середовищах, якщо немає вимірюваних винятків.
• Використовуйте шифрування SMB для чутливих шарів через менш довірені мережі; не вмикайте його повсюдно без бюджету CPU.
• Віддавайте перевагу Kerberos для клієнтів у домені; обмежуйте NTLM обдумано і тестуйте Linux/сервісні клієнти.
• Тримайте синхронізацію часу здоровою на клієнтах і серверах.
• Забезпечте стабільність відображення ідентичностей (однаковий idmap backend і діапазони на всіх серверах).
• Аудитуйте мапування гостя і припиняйте випадковий доступ для гостя.
• Використовуйте явний доступ на основі груп і тримайте ACL узгодженими між шарами.
• Увімкніть логування достатнє для розрізнення відмов через автентифікацію, ACL або політику.

Часті запитання

1) Чому «Доступ заборонено» з’являється одразу після відключення SMB1?

Тому що якийсь клієнт/пристрій тихо покладався на SMB1 або на поведінку гостя з епохи SMB1. Вимкнення SMB1 прибрало шлях відступу й виявило реальну несумісність.

2) Чи те саме підписування SMB і шифрування SMB?

Ні. Підписування захищає цілісність (запобігає підміні). Шифрування захищає конфіденційність (запобігає прослуховуванню). Можна мати підписування без шифрування, і часто так і треба.

3) Якщо Windows має доступ до шару, чому Linux CIFS mount отримує «permission denied»?

У домені Windows часто автоматично використовує Kerberos. Linux-монти можуть за замовчуванням брати NTLM. Якщо сервер або доменна політика блокує NTLM, Linux впаде, а Windows працюватиме.

4) Чи слід встановлювати «map to guest = Bad User»?

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

5) Чи може шифрування SMB спричинити «Доступ заборонено»?

Так, опосередковано. Якщо шифрування обов’язкове, а клієнт не може його узгодити (старі ОС, прошивка NAS, неправильне налаштування), сесія може не встановитись і проявитися як проблеми з доступом.

6) Який найшвидший спосіб визначити, це ACL чи автентифікація?

Якщо smbclient -L падає для користувача — це автентифікація/політика. Якщо перелік працює, а mkdir падає — це авторизація (правила шару або файлові ACL). Журнали підтверджують.

7) Чи потрібно вмикати SMB1 для старих сканерів?

Краще замінити або оновити їх. Якщо неможливо, ізолюйте такі пристрої до виділеного legacy-ендпоінта з суворими мережевими контролями — ніколи на основних файлових серверах.

8) Чому доступ працює через IP сервера, але не через ім’я хоста?

Бо Kerberos залежить від імені хоста (SPN). Використання IP часто примушує NTLM або порушує політику. Виправте DNS/SPN і використовуйте коректні імена.

9) Як уникнути майбутніх «бур доступу» після оновлень?

Запускайте канаркові тести з різних типів клієнтів, моніторьте журнали Samba на предмет fallback/мапування в гостя і тримайте відображення ідентичностей та синхронізацію часу нудно стабільними.

Висновок: наступні кроки, які можна зробити сьогодні

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

Зробіть ось що:

1. Пройдіть швидкий план діагностики: визначте, на якому етапі відмови — узгодження, автентифікація чи авторизація.
2. Використовуйте smbclient і серверні журнали, щоб відтворити й класифікувати помилку — не сперечайтеся з діалогом Windows.
3. Стабілізуйте відображення ідентичностей і розв’язання груп, потім узгодьте правила шарів із файловими ACL.
4. Примусіть підписування, застосуйте шифрування там, де це потрібно, і протестуйте клієнтів перед зміною політик.
5. Додайте канарку і підтримуйте її: один Windows-клієнт, один Linux-монт, один сервісний акаунт для тесту. Нудьга економить вихідні.