SMB 2240 через VPN: перевірте список робочих станцій для входу

Помилка 2240 означає, що обліковий запис може не мати права входити з цієї робочої станції. Прочитайте запис про невдалий вхід і виправте обліковий запис, а не DNS чи тунель.

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

Збережіть номер помилки в заявці. Він звужує розслідування до одного атрибута й однієї події.

Що насправді означає 2240

Список помилок керування мережею визначає 2240 як NERR_InvalidWorkstation, і це ім'я варто читати буквально. Запис обмежений набором дозволених комп'ютерів для входу, і машина, що подає облікові дані, до нього не входить. Нічого в цьому визначенні не згадує тунель, файловий ресурс чи пароль. Атрибут міститься на записі й оцінюється під час спроби входу.

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

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

Два пов'язані факти цього не пояснюють. Пристрій NAT може змінити спостережувану адресу джерела, не чіпаючи атрибут запису, а зміна суфікса DNS може виправити коротке ім'я, залишивши обмеження входу точно там, де воно було. Обидва варто виключити, і жоден не замінює читання атрибута.

Спочатку прочитайте запис про невдалий вхід

Установіть, яку ідентичність автентифікував файловий сервер і яка машина її подала. Обліковий запис домену, локальний запис із схожим коротким ім'ям і окремий запис VPN не взаємозамінні, і помилка набуває сенсу лише тоді, коли відомий точний.

Журнал безпеки записує спробу разом з обліковим записом та іменем робочої станції, що викликає, і саме ця пара перевіряється за обмеженням:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddHours(-2)} |
  Select-Object TimeCreated,Message | Format-List
Get-ADUser -Identity jdoe -Properties LogonWorkstations |
  Select-Object SamAccountName,LogonWorkstations

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

Не додавайте ім'я шлюзу VPN лише тому, що трафік іде через нього. Шлюз не є автентифікованим викликом, і додавання його до списку нічого не змінює, зате ускладнює перевірку запису.

Виправте обмеження в найменшому обсязі

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

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

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

Читайте наступний результат, а не його відсутність

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

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

Немає причин перебудовувати профіль VPN чи скидати пароль, доки Windows повідомляє про обмеження робочої станції. Список мережевих помилок Microsoft варто тримати відкритим саме з цієї причини: код каже, який атрибут перевірити, перш ніж щось чіпати.

Схожі статті