Підключення мережевого диска VPN з обліковим записом Samba, який знає сервер
Вхід у Windows або VPN не створює обліковий запис Samba. Підключіть ресурс з ідентичністю, яку знає файловий сервер, і стежте за конфліктами сеансів.
Підключіть тунель, а спільний ресурс досі запитує пароль, який користувач вважає правильним. В автономному розгортанні Samba вхід VPN і вхід SMB — не пов'язані облікові дані: один авторизує тунель, інший перевіряє файловий сервер. Тому підключення диска з обліковим записом VPN не вдається, навіть коли пароль правильний і мережевий шлях бездоганний. Ця відмінність пояснює більшість збоїв підключення через VPN.
Рішення не в скиданні облікового запису VPN. Потрібно назвати ідентичність, яку сервер Samba справді знає, а потім перевірити, що ця сама ідентичність має права на ресурс і каталог.
Вхід VPN і вхід SMB — різні ідентичності
Обліковий запис VPN оцінює VPN-шлюз за власною політикою. Він відповідає, чи може цей клієнт увійти до приватної мережі. Він нічого не каже про те, який обліковий запис SMB існує на файловому сервері в цій мережі.
Обліковий запис Samba живе в серверній частині автентифікації, зі своєю базою паролів і своїм ім'ям. Дві машини можуть обидві мати користувача з іменем alice, не поділяючи систему ідентичності, пароль чи ідентифікатор користувача. Імена збігаються; облікові записи — ні.
Сервер Samba, інтегрований у домен, змінює картину: ідентичність походить із каталогу та Kerberos, а не з локального списку облікових записів. У цьому разі використовуйте ідентичність із каталогу та підтримувану конфігурацію SMB, а не створюйте локальні дублікати, імітуючи членство в домені. Перевірте, яку модель використовує сервер, перш ніж створювати обліковий запис.
Подивіться, яку ідентичність Windows використовує насправді
Windows кешує підключення для кожного сервера. Якщо наявний сеанс до того самого сервера відкрито під іншим обліковим записом, нове підключення може повторно використати цей сеанс або завершитися помилкою автентифікації із зазначенням неправильного користувача. Так правильний пароль виглядає неправильним. Перегляньте поточні підключення, перш ніж змінювати облікові дані.
net use
cmdkey /list
klist
Перша команда показує підключені диски та відкриті сеанси, друга — збережені облікові дані, які можуть застосовуватися автоматично, а третя — квитки Kerberos, коли використовується домен. Збережені облікові дані можуть мовчки перевизначити обліковий запис, який ви збиралися ввести.
Видаліть лише те підключення або ті облікові дані, що стосуються цієї проблеми. Відключення всіх дисків або заміна імені сервера IP-адресою приховує вибір ідентичності й може порушити підпис або політики на основі імен.
Підключіть ресурс з обліковим записом, який розпізнає сервер
Укажіть обліковий запис у формі, яку очікує сервер, і дозвольте Windows запитати пароль, щоб секрет не потрапив до історії команд чи скрипту:
net use Z: \\files.corp.example\team * /user:FILESERVER\alice /persistent:no
Компонент сервера перед оберненою косою рискою — це контекст ідентичності сервера Samba, а не VPN-шлюз. Зірочка запитує інтерактивне введення пароля, а /persistent:no не дає підключенню потрапити до наступного входу. Виберіть вільну літеру диска.
Якщо сервер інтегровано в домен, компонентом користувача може бути натомість ім'я каталогу або ідентичність із доменним префіксом. Використовуйте форму, задокументовану адміністратором; вигадування локального облікового запису з тим самим іменем створює другу ідентичність і другий пароль для обслуговування.
Дійсність облікового запису, доступ до ресурсу та права файлової системи — три перевірки
Samba перевіряє, чи проходить ідентичність автентифікацію, чи допускає її визначення ресурсу і чи надає файлова система запитану операцію. Проходження першої перевірки не означає проходження двох інших. Ресурс може бути видимим і все одно відмовляти в записі, бо так кажуть права каталогу.
Ресурс, обмежений за допомогою valid users, допускає лише перелічені облікові записи або групи. Обліковий запис може правильно пройти автентифікацію і все одно бути відхиленим цим рядком. Перевірте визначення ресурсу, перш ніж робити висновок, що пароль неправильний.
На боці файлової системи важливі і процес Samba, і підключена ідентичність. Каталог, що належить root із режимом 700, не прийме записів від звичайного облікового запису, навіть якщо визначення ресурсу це дозволяє. Перевірте читанням, а потім записом у каталозі, який обліковий запис має використовувати.
Усуньте конфліктний сеанс, не порушуючи політику
Якщо причина — застарілий сеанс, закрийте саме це підключення і підключіться знову з потрібним обліковим записом. Якщо збережені облікові дані продовжують повертатися, видаліть їх, а не весь список дисків. Потім підтвердьте новий сеанс за допомогою net use.
Зберігайте обов'язковий підпис SMB, шифрування та політику облікових записів. Сервер, який відхиляє сеанс без підпису або шифрування, провадить політику, а не читає пароль неправильно, і ослаблення її заради успішного підключення міняє безпеку на симптом.
Запишіть ім'я сервера, точну форму облікового запису та права на ресурс і каталог, які спрацювали. Інакше наступна людина, що підключатиме диск, спершу спробує вхід VPN, бо саме з цими даними вона потрапила до мережі.