SMB-ресурс «Доступ заборонено»: один дозвіл, який усі пропускають

Права, які всі пропускають: права на рівні ресурсу

Доступ по SMB — це перетин кількох воріт. Ви не «маєте доступу», бо один ACL каже, що маєте; ви маєте доступ лише якщо кожен воріт дозволяє це.

Windows: права ресурсу + NTFS-права

На Windows-файлових серверах за доступ по шару відповідають дві окремі системи прав:

• Права ресурсу (об’єкт шару). Історично налаштовуються як Read/Change/Full Control на шарі.
• NTFS-права (ACL файлової системи) на підлеглому дереві папок.

Ефективний доступ — це найсуворіша комбінація. Якщо NTFS дає Modify, але шар дає тільки Read, ви отримаєте Read. Якщо шар відхиляє групу, вам буде відмовлено, навіть якщо NTFS відкритий.

Samba: обмеження визначення шару + файлові права

У Samba ідея та ж, хоч регулятори виглядають інакше. Ваш доступ обмежується:

• Контролями на рівні шару Samba: valid users, write list, read list, hosts allow, veto files, force user, guest ok та інші.
• Файловими правами: POSIX-біти режиму, ACL (NFSv4 ACL на ZFS, POSIX ACL на ext4/xfs), плюс будь-який MAC-рівень (SELinux/AppArmor).
• Картографування ідентичностей: якщо Samba вважає вас іншим UID/GID, ніж файлова система очікує, це відмова за арифметикою.

Якщо хочете однорядкову операційну істину: SMB ніколи не «тільки права». Це права плюс трансляція.

Жарт №1: Права SMB — як аеропортна безпека: вас можуть допустити до гейту, але все одно зупинити, бо ви несете пляшку з водою на ім’я «Deny ACE».

Ментальна модель, яка припиняє перескакування відповідальності

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

Думайте у термінах воріт, а не списків

Для доступу по SMB проходьте ворота в такому порядку:

1. Розв’язання імен і доступність: ви підключаєтесь до того сервера, за яким вважаєте?
2. Аутентифікація: ви увійшли під тим ідентичністю, яку думаєте?
3. Авторизація на шарі: об’єкт шару дозволяє вам?
4. Авторизація на файловій системі: ACL каталогу дозволяє вам (та чи є права на проходження по шляху)?
5. Шари політик: вимоги шифрування/підпису, невідповідність діалекту SMB, «Network access: Sharing and security model», Samba «map to guest» тощо.
6. Кешування токенів/облікових даних: Windows агресивно кешує SMB-дані. Люди теж.

Чому права ресурсу важать більше, ніж «повинні»

У багатьох зрілих Windows-середовищах адміністратори виставляють права ресурсу на «Everyone: Full Control» і покладаються на NTFS ACL. Це обґрунтована практика: одна площина контролю (NTFS), менше розбіжностей, менше плутанини. Але щойно хтось відхиляється — часто під час «швидкого підсилення безпеки» або «тимчасового обмеження» — з’являється друга площина контролю і починається дрейф.

В Samba середовищах ворота на рівні шару незаперечні: valid users та інші — це модель прав шару. Якщо визначення шару обмежує доступ, ви можете chmod 777 скільки завгодно — це не допоможе.

Права, яку всі пропускають, чітко

Повторюваний сценарій відмови такий:

• Windows: на вкладці Security/Permissions шару немає групи користувача, або вона є з Read, тоді як NTFS очікує Write, або містить явний Deny.
• Samba: шар має valid users = @somegroup, але користувача фактично немає в цій групі з погляду Samba (idmap mismatch), або шар має read only = yes, або write list його виключає.

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

Це рутина «припиніть суперечки і знайдіть вузьке місце». Використовуйте її, коли один користувач падає, один проходить, а всі мають теорії.

По-перше: доведіть, до якого сервера і під якими обліковими даними

• Підтвердіть, що клієнт підключається до правильного хоста (DFS може переадресувати вас; DNS може брехати; старі IP-адреси лишаються).
• Підтвердіть, яке ім’я користувача використовується (Credential Manager, кешовані сесії, неявний домен).
• Підтвердіть, що SMB-сеанс встановлено (або що він падає на етапі аутентифікації).

По-друге: перевірте доступ на рівні шару (забутий ворот)

• Windows: Get-SmbShareAccess на сервері для цього шару.
• Samba: перегляньте smb.conf і runtime-вид (testparm -s), перевірте valid users, write list, read list, hosts allow.

По-третє: перевірте файловий рівень доступу та проходження

• Windows: NTFS ACL та проходження шляхом шару. Використовуйте icacls та інструменти перевірки ефективного доступу.
• Linux: POSIX-біти режиму, ACL (getfacl), плюс відмови SELinux (ausearch).

Умова зупинки

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

Цікаві факти та історія (чому це стало заплутаним)

1. SMB починався в IBM у 1980-х, потім Microsoft прийняла і розширила його. Це пояснює, чому ви досі знаходите старі концепції в сучасній поведінці шарів Windows.
2. Права на рівні ресурсу передували NTFS ACL у розумінні, яке має більшість людей сьогодні. Контролі шару були раннім мережеобмеженням; NTFS еволюціонував у більш детальну локальну модель безпеки.
3. «Everyone» змінювалося в часі. В старих Windows «Everyone» міг включати анонімних користувачів; пізніше жорсткіша конфігурація розділила «Everyone» та «Anonymous Logon», але старі припущення лишилися в скриптах і знанні команд.
4. Довга археологія deprecation SMB1 породила звички «совісного» сумісництва: адміністратори переключали налаштування, щоб підтримати старі пристрої, іноді випадково ламали сучасну автентифікацію або непередбачувано посилювали доступ.
5. DFS може маскувати реальну ціль. Користувачі кажуть «шар не працює», але вони потрапляють на референт до іншого сервера з іншими правами шару.
6. idmap Samba — це світ болю, бо він зіставляє Windows SID з Unix UID/GID. Ідеальна група AD може стати марною, якщо бекенд картографування змінюється або діапазони перекриваються.
7. Токени доступу Windows — це знімки. Зміни членства в групі не завжди застосовуються до нового токена без нового входу в систему, що робить фразу «я щойно додав їх у групу» пасткою.
8. Явні Deny ACE перемагають (зазвичай). Вони існують не просто так, але це найшвидший спосіб створити загадку «для адміністраторів працює, а для фінансів — ні».
9. Підписування/шифрування SMB може виглядати як відмова. Деякі клієнти повертають невлучні помилки, коли політика блокує з’єднання до того, як відбувається авторизація.

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

Це реальні операційні кроки. Виконуйте їх з правильного місця (клієнт проти сервера) і читайте вивід, ніби це розповідь. Бо так воно і є.

Завдання 1 (Windows-клієнт): перелічити поточні SMB-з’єднання

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbConnection | Format-Table -AutoSize"
ServerName ShareName UserName Credential Dialect NumOpens
---------- --------- -------- ----------- ------- --------
FS01       Finance$  CONTOSO\jdoe          3.1.1   4

Що це означає: Ви вже підключені до FS01 як CONTOSO\jdoe до шару Finance$. Якщо користувач «перевіряв» з іншими обліковими даними, він може ненавмисно помилятись.

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

Завдання 2 (Windows-клієнт): очистити кешований SMB-сеанс до сервера

cr0x@server:~$ powershell -NoProfile -Command "net use \\FS01\Finance$ /delete"
\\FS01\Finance$ was deleted successfully.

Що це означає: Той SMB-сеанс видалено. Наступна спроба доступу вимагатиме/переговорюватиме облікові дані знову.

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

Завдання 3 (Windows-клієнт): підтвердити, що DNS вкаже на очікуваний хост

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName FS01 | Select-Object -First 3 | Format-Table -AutoSize"
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
FS01  A   60  Answer  10.10.5.21

Що це означає: Клієнт розв’язує FS01 в 10.10.5.21.

Рішення: Якщо ця IP-адреса не та, яку ви очікували (поширено під час міграцій), ви дебагуєте не ту машину. Виправте DNS/DFS перед тим, як лізти в ACL.

Завдання 4 (Windows-сервер): переглянути права на рівні шару (забутий ворот)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbShareAccess -Name Finance$ | Format-Table -AutoSize"
Name     ScopeName AccountName        AccessControlType AccessRight
----     --------- -----------        ----------------- -----------
Finance$ *         BUILTIN\Administrators Allow          Full
Finance$ *         CONTOSO\FinanceRW      Allow          Change
Finance$ *         CONTOSO\FinanceRO      Allow          Read
Finance$ *         CONTOSO\Interns        Deny           Full

Що це означає: Є явний Deny для CONTOSO\Interns. Якщо ваш користувач у цій групі (прямо або через вкладення), він програє, незалежно від NTFS.

Рішення: Підтвердіть членство в групі і приберіть/замініть Deny на чистішу модель. Deny має бути останнім засобом, а не першим поривом.

Завдання 5 (Windows-сервер): показати фізичний шлях, на який вказує шар

cr0x@server:~$ powershell -NoProfile -Command "(Get-SmbShare -Name Finance$).Path"
D:\Shares\Finance

Що це означає: Шар вказує на D:\Shares\Finance.

Рішення: Тепер ви точно знаєте, який ACL каталогу перевіряти. Ніяких здогадок.

Завдання 6 (Windows-сервер): швидко переглянути NTFS-ACL

cr0x@server:~$ powershell -NoProfile -Command "icacls D:\Shares\Finance"
D:\Shares\Finance CONTOSO\FinanceRW:(OI)(CI)(M)
                 CONTOSO\FinanceRO:(OI)(CI)(RX)
                 BUILTIN\Administrators:(OI)(CI)(F)
                 NT AUTHORITY\SYSTEM:(OI)(CI)(F)
                 Successfully processed 1 files; Failed processing 0 files

Що це означає: На файловому шарі модель виглядає логічною: RW має Modify, RO має Read/Execute.

Рішення: Якщо користувач у FinanceRW і все одно відкидається — ворота шару (Завдання 4) або проблеми ідентичності/токена більш імовірні, ніж NTFS.

Завдання 7 (Windows-сервер): перевірити ACEs для виявлення вкладених груп

cr0x@server:~$ powershell -NoProfile -Command "Get-Acl D:\Shares\Finance | Select-Object -ExpandProperty Access | Select-Object -First 6 | Format-Table -AutoSize"
FileSystemRights AccessControlType IdentityReference          IsInherited InheritanceFlags PropagationFlags
---------------- ----------------- -----------------          ----------- ---------------- ---------------
Modify           Allow             CONTOSO\FinanceRW          False       ContainerInherit ObjectInherit None
ReadAndExecute   Allow             CONTOSO\FinanceRO          False       ContainerInherit ObjectInherit None
FullControl      Allow             BUILTIN\Administrators     False       ContainerInherit ObjectInherit None
FullControl      Allow             NT AUTHORITY\SYSTEM        False       ContainerInherit ObjectInherit None

Що це означає: Ви дивитесь сирі ACE. Це не порахує «ефективний» для конкретного користувача, але покаже, чи є явний Deny або порушене наслідування.

Рішення: Якщо бачите несподівані явні записи або зламане наслідування — виправте це перш ніж чіпати права шару.

Завдання 8 (Windows-сервер): підтвердити членство користувача з погляду сервера

cr0x@server:~$ powershell -NoProfile -Command "whoami /groups | Select-String -Pattern 'Finance|Interns' -CaseSensitive"
BUILTIN\Administrators                                 Alias            S-1-5-32-544  Enabled
CONTOSO\FinanceRW                                      Group            S-1-5-21-...   Enabled
CONTOSO\Interns                                        Group            S-1-5-21-...   Enabled

Що це означає: Токен доступу включає і FinanceRW, і Interns. Якщо шар відкидає Interns, то Deny перемагає.

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

Завдання 9 (Windows-сервер): перевірити, чи конфіг серверу не блокує автентифікацію

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbServerConfiguration | Select-Object RejectUnencryptedAccess,RequireSecuritySignature,EnableSMB1Protocol | Format-List"
RejectUnencryptedAccess : True
RequireSecuritySignature : True
EnableSMB1Protocol : False

Що це означає: Сервер вимагає підписування і відкидає незашифрований доступ (залежно від переговорів клієнта). Деякі старі клієнти або пристрої можуть не підтримувати це і повідомляти некоректні помилки.

Рішення: Якщо клієнт старий або не Windows, перевірте підтримку діалекту/підписування/шифрування перед тим, як ганятися за правами.

Завдання 10 (Linux-клієнт): протестувати перелік шарів з явними обліковими даними

cr0x@server:~$ smbclient -L //fs01 -U 'CONTOSO\jdoe'
Password for [CONTOSO\jdoe]:
        Sharename       Type      Comment
        ---------       ----      -------
        Finance$        Disk      Finance data
        IPC$            IPC       Remote IPC
SMB1 disabled -- no workgroup available

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

Рішення: Якщо перелік падає з NT_STATUS_LOGON_FAILURE, ви ще не дійшли до стадії прав. Виправляйте автентифікацію або формат області.

Завдання 11 (Linux-клієнт): спробувати доступ до шару та спостерігати точну помилку

cr0x@server:~$ smbclient //fs01/Finance$ -U 'CONTOSO\jdoe' -c 'ls'
Password for [CONTOSO\jdoe]:
NT_STATUS_ACCESS_DENIED listing \*

Що це означає: Аутентифікація пройшла, але авторизація не вдалась. Це вказує на права шару, файлові ACL або шар політики (рідше).

Рішення: Перейдіть до перевірок на сервері: ACL шару (Windows) або valid users/write list (Samba), потім правил файлової системи.

Завдання 12 (Linux-сервер із Samba): вивести ефективну конфігурацію Samba для шару

cr0x@server:~$ testparm -s
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Server role: ROLE_ACTIVE_DIRECTORY_MEMBER

[Finance$]
	path = /srv/shares/finance
	read only = no
	valid users = @FINANCE_RW @FINANCE_RO
	write list = @FINANCE_RW

Що це означає: Доступ мають лише члени FINANCE_RW або FINANCE_RO. Записи на запис обмежені FINANCE_RW.

Рішення: Якщо користувач є в AD, але Samba не бачить його в цих групах, перевірте idmap та розв’язування груп через NSS.

Завдання 13 (Linux-сервер): підтвердити ідентичність користувача та картографування груп

cr0x@server:~$ id 'jdoe'
uid=123450110(jdoe) gid=123450513(domain users) groups=123450513(domain users),123450988(finance_ro),123450999(interns)

Що це означає: З погляду Unix, jdoe в finance_ro і interns. Якщо шар очікує finance_rw, він не отримає запису. Якщо шар блокує interns через invalid users або подібне, йому може бути відмовлено повністю.

Рішення: Узгодьте імена груп у конфігурації Samba з тим, що система фактично розв’язує, і уникайте неоднозначності неймінгу груп між доменами.

Завдання 14 (Linux-сервер): перевірити ACL файлової системи на шляху шару

cr0x@server:~$ getfacl -p /srv/shares/finance | sed -n '1,25p'
# file: /srv/shares/finance
# owner: root
# group: finance_rw
user::rwx
group::rwx
group:finance_ro:r-x
mask::rwx
other::---

Що це означає: Файлова система дозволяє finance_ro читати, finance_rw записувати, іншим — нічого.

Рішення: Якщо Samba дозволяє, а файловий рівень не дає — виправте ACL (або використайте force group/create mask). Якщо файловий рівень дозволяє, а Samba відкидає — виправте конфіг шару.

Завдання 15 (Linux-сервер із SELinux): перевірити відмови SELinux, що впливають на Samba

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

Що це означає: SELinux заборонив smbd читати директорію з міткою default_t.

Рішення: Позначте директорію правильно для Samba (або налаштуйте логічні boolean/policy). Не вирішуйте це через chmod.

Завдання 16 (Windows-сервер): перевірити, чи права шару не відійшли від стандарту

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbShare | Where-Object Name -like '*$' | Select-Object Name,Path | Sort-Object Name | Format-Table -AutoSize"
Name      Path
----      ----
Finance$  D:\Shares\Finance
HR$       D:\Shares\HR
Legal$    D:\Shares\Legal

Що це означає: У вас кілька прихованих адміністративних шарів. Дрейф відбувається помітно по шарах, а не по всьому серверу.

Рішення: Порівняйте ACL шарів між собою. Якщо Finance$ — єдиний з Deny або кастомним ACL, ви, ймовірно, знайшли винуватця.

Три міні-історії з корпоративного життя

1) Інцидент через неправильне припущення: «NTFS — це все, що має значення»

Компанія мала впорядкований патерн файлового сервера: права шару були «Everyone: Full Control», а NTFS відповідав за реальні обмеження. Це поширена практика. Вона зменшує кількість рухомих частин і спрощує аудити, бо одна система авторитетна.

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

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

Дежурний SRE перевірив здоров’я сховища. Нормально. Мережу — нормально. NTFS ACL — нормально. Аналітик був у потрібній FinanceRW групі. Всі заспокоїлися — поки хтось не подивився на Get-SmbShareAccess і не помітив Deny на вкладеній групі, яка включала аналітика через старий пакет онбордінгу.

Виправлення було простим: прибрати Deny і перейти на allow-list модель на NTFS. Урок — не простий. Постмортем вказав справжню причину: організаційне припущення «права шару неважливі» зіткнулось з одноразовою зміною, яку ніхто не перевірив, бо вона здавалася «дрібницею».

2) Оптимізація, що обернулась проблемою: «Давайте прискоримо через DFS та консолідацію»

Інша компанія, інший вид болю. Вони консолідували файлові сервери і ввели DFS-namespace, щоб користувачі могли продовжувати використовувати \\corp\files\..., поки сховище змінювалося під ними. Це нормальна модернізація. Це також чудовий спосіб випадково тягати дебаг на іншу систему кілька днів.

Щоб «оптимізувати», вони перенаправили завантажений шар на новий бекенд з швидшими дисками. Для більшості користувачів працювало. Для невеликої підгрупи доступ почав періодично відмовлятися з «Access Denied». Періодичність — це сильне слово; воно означає «нікому не повірили, поки не показали в екрані».

Виявилось, що DFS-referrals відправляли деяких клієнтів на новий таргет, а деяких — на старий на основі site costing і кешованих referral. Два таргети мали трохи різні права шару. NTFS був дзеркалений. Share ACL — ні. Отже той самий шлях проходив або ні залежно тільки від того, на який сервер ви потрапили.

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

3) Нудна, але правильна практика, що врятувала день: «Одна площина контролю і тест з клієнта»

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

Одного дня клінічний додаток почав не записувати звіти на шар. Команда додатку сказала «сховище повне» (не було). Мережа сказала «SMB впав» (не правда). Команда файлових сервісів попросила шаблон тикету: ім’я шару, шлях, користувач, хост клієнта, точна помилка і тест під сервісним обліковим записом.

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

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

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

1) «Я можу доступитись локально, але не через \\server\share» → відмова через права шару

Симптом: Користувач може відкрити папку при вході на сервер (RDP/консоль), але отримує «Access Denied» через SMB.

Корінна причина: Локальний доступ використовує NTFS; SMB доступ використовує права шару + NTFS. Ворот шару блокує їх.

Виправлення: На Windows запустіть Get-SmbShareAccess і виправте ACL шару. У Samba перевірте valid users/write list.

2) «Тільки цей один користувач відкидається» → він в групі з Deny (часто вкладеній)

Симптом: Те ж роль, та сама команда, один користувач падає. Усі звинувачують «корумпований профіль» або «Windows як Windows».

Корінна причина: Явний Deny застосовується через вкладене членство в групах, або їх токен містить застарілу групу.

Виправлення: Перевірте whoami /groups (Windows) або id (Linux). Видаліть користувача з групи з Deny або усуньте Deny, переробивши модель дозволів.

3) «Після перезавантаження/виходу працює» → застарілий токен або кешовані облікові дані

Симптом: Ви додали користувача в групу, нічого не змінилося, потім раптом все запрацювало.

Корінна причина: Токени Windows створюються при вході; зміни членства в групі не відображаються доти, поки не з’явиться новий токен. SMB-сеанси також кешують облікові дані за сервером.

Виправлення: Вийдіть/увійдіть (або перезапустіть сесію/сервіс для сервісних акаунтів). Очистіть SMB-сеанси через net use ... /delete і пробуйте з явними обліковими даними.

4) «Читання працює, запис заборонено» → шар встановлено в Read або Samba write list виключає

Симптом: Користувач може переглядати й відкривати файли, але не створювати/перейменовувати/видаляти.

Корінна причина: Права шару встановлено на Read-only, або Samba write list не включає користувача, або NTFS дає лише RX.

Виправлення: Порівняйте права шару (Read/Change) з NTFS Modify. У Samba переконайтесь, що read only = no і write list відповідає потрібній групі.

5) «Періодична відмова доступу» → DFS-referrals або кілька таргетів з різними ACL шарів

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

Корінна причина: DFS відправляє клієнтів на різні сервери; права шару відрізняються між ними.

Виправлення: Уніфікуйте права шару на всіх таргетах. Перед дебагом перевіряйте, до якого сервера підключений клієнт.

6) «Samba відкидає, але файловий шар відкритий» → SELinux/AppArmor блокує

Симптом: Біти режиму/ACL показують дозвіл, але SMB все одно повертає Access Denied.

Корінна причина: Обов’язковий контроль доступу блокує smbd.

Виправлення: Перевірте AVC denials і позначте шляхи коректно; не дійте так, ніби SELinux — це чутка.

7) «Усі мають доступ, крім не-доменних машин» → невідповідність моделі автентифікації

Симптом: Машини, приєднані до домену, працюють; клієнти без домену падають з заплутаними помилками «заборонено».

Корінна причина: Сервер вимагає Kerberos, підписування або специфічної політики автентифікації; або Samba відображає невідомих користувачів у guest, і guest заблокований.

Виправлення: Підтвердіть метод автентифікації; для Samba перевірте map to guest і права гостя; на Windows перевірте політики SMB-сервера.

Контрольні списки / покроковий план

Покроково: діагностика одного користувача, який не має доступу до одного шару

1. Визначте точний UNC-шлях, який використовує користувач. Якщо це DFS-namespace, зафіксуйте його.
2. З клієнта перелікуйте активні SMB-з’єднання (Завдання 1). Підтвердіть ім’я користувача.
3. Очистіть застарілі сесії до цільового сервера (Завдання 2). Підключіться з явними обліковими даними.
4. Перевірте розв’язання імен (Завдання 3). Підтвердіть, що ви потрапляєте на правильний сервер/IP.
5. Розділіть автентифікацію і авторизацію за допомогою smbclient (Завдання 10–11) або спроб мапінгу у Windows. Якщо автентифікація не вдається — зупиніться і виправляйте auth.
6. На сервері виведіть права шару (Завдання 4). Шукайте відсутні дозволи і явні Deny.
7. Підтвердіть шлях шару (Завдання 5). Переконайтесь, що перевіряєте потрібну папку.
8. Перевірте файлові ACL (Завдання 6). Переконайтесь, що група має Modify/Write і наслідування налаштоване.
9. Перевірте токен/членство в групах (Завдання 8 / Завдання 13). Дивіться на погляд сервера, а не HR-системи.
10. Якщо Samba — підтвердіть runtime-config (Завдання 12) і розв’язування idmap/grups (Завдання 13).
11. Якщо Linux — перевірте MAC-рівень (Завдання 15), якщо права виглядають коректно, але доступ і далі відкидається.
12. Змініть лише одну річ, відразу повторно протестуйте, а потім зафіксуйте, який ворот відмовляв і чому.

Безпечний стандарт, що запобігає більшості інцидентів з правами SMB

• Windows: Виставляйте права шару широко (часто «Authenticated Users: Full» або політично погоджений еквівалент), а доступ контролюйте NTFS-групами. Зберігайте Deny рідкісним і підглядженим.
• Samba: Будьте явними й послідовними: визначайте valid users і write list за передбачуваною схемою імен груп. Уникайте творчих виключень по шарах, якщо не любите Pager-фадіг.
• Усюди: Розглядайте картографування ідентичності як інфраструктуру. Якщо ви змінюєте idmap-бекенд або діапазони — ви змінюєте «хто є хто» на диску.

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

• Запишіть поточні ACL шару та файлові ACL перед змінами (скріншоти не є системою контролю).
• Тестуйте з реальним неадмінським користувачем плюс сервісним акаунтом, що використовують додатки/автоматизація.
• Для DFS: тестуйте кожний таргет напряму (\\server\share) і через namespace.
• Після змін членства в групі: переконайтесь, що користувачі оновили токени (вихід/вхід) для валідації.
• Запишіть передбачувану модель дозволів: «шар дозволяючий, файловий обмежуючий» або «шар обмежуючий, файл вирівняний». Не робіть це випадково.

Жарт №2: «Тимчасовий» Deny ACE має той самий життєвий цикл, що і staging database: він назавжди, тільки з гіршою документацією.

Поширені запитання

1) Що таке «один дозвіл, який всі пропускають»?

Гейт на рівні шару: Windows-Share Permissions або обмеження в визначенні шару Samba. Люди зациклюються на NTFS/POSIX ACL і забувають, що шар може спочатку блокувати доступ.

2) На Windows, чи варто встановлювати права шару Everyone: Full Control?

У багатьох підприємствах сучасніший варіант — «Authenticated Users» (залежить від політики) з Full Control на шарі, а реальний доступ контролювати NTFS-групами. Ключ — послідовність: одне авторитетне місце для обмежень.

3) Чому Deny викликає так багато дивних багів?

Бо це тупо і воно перемагає. Користувачі накопичують членство в групах (проєктні групи, пакети онбордінгу, вкладені групи). Один Deny може перекрити багато Allow-ів у способи, що неочевидні при швидкому огляді.

4) Я додав користувача в потрібну AD-групу. Чому йому досі відмовляють?

Вони можуть використовувати кешовані SMB-облікові дані, або їх токен не містить нової групи. Очистіть SMB-сеанси і попросіть їх вийти/увійти (або перезапустіть сесію сервісного акаунта).

5) Чому адміністратор має доступ, а користувач — ні?

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

6) Як відрізнити, чи це помилка автентифікації чи авторизації?

Якщо ви можете перелічити шари, але не можете перелічити директорії всередині шару — автентифікація пройшла, а авторизація не вдалася. Інструменти типу smbclient роблять це очевидним: NT_STATUS_LOGON_FAILURE проти NT_STATUS_ACCESS_DENIED.

7) Чи можуть політики підписування/шифрування SMB виглядати як «Access Denied»?

Так. Залежно від клієнта і обробки помилок, виконання політики може виявитись загальною помилкою доступу. Перевірте конфігурацію сервера (і можливості клієнта) перш ніж правити ACL.

8) На Samba я налаштував файлові права правильно. Чому Samba все одно відкидає?

Бо Samba може обмежувати шар через valid users, read list, write list або обмеження по хосту, або відображати користувача на невірний UID/GID. Перегляньте testparm -s і перевірте вивід id для користувача.

9) Яка найшвидша команда на сервері Windows для проблем з правами шару?

Get-SmbShareAccess -Name <share>. Якщо потрібна група відсутня або є Deny — ви, ймовірно, знайшли проблему.

10) Яка цитата найкраще описує цю плутанину?

Парафраз ідеї Werner Vogels: все рано чи пізно ламається, тож проектуйте й оперуйте, припускаючи відмову — і робіть діагностику швидкою.

Висновок: подальші кроки, які дійсно працюють

Коли SMB каже «Access Denied», не починайте з переписування NTFS-ACL немов вигнання бісів. Дійте по факту: підтвердіть основи — правильний сервер, правильна ідентичність, автентифікація проти авторизації. Потім перевірте ворот на рівні шару — бо саме його всі забувають.

Зробіть наступне:

1. Стандартизуйте модель: або «шар дозволяючий, файловий обмежуючий» (поширено у Windows), або явний allow-list Samba з послідовним картографуванням ідентичностей.
2. Забороніть випадкові Deny: вимагайте peer review і документовану причину. Deny — скальпель, а люди ним працюють як лопатою.
3. Відпрацюйте план діагностики у м’язах: перевірка сесії клієнта, права шару, файлові ACL, картографування ідентичностей/оновлення токенів, шари політик.
4. Автоматизуйте виявлення дрейфу: якщо у вас багато файлових серверів або DFS-таргетів, забезпечте консистентність прав шару і аудит.

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