Може отримати доступ до спільного доступу до Windows за IP-адресою або FQDN-адресою, але не за іменем хоста

Один із лабораторних комп’ютерів у школі, в якій я адмініструю, не має доступу до жодної спільної мережі в каталозі \\ ad \ data $. Я можу отримати доступ до нього з будь-якого іншого комп’ютера в мережі. Якщо я використовую IP \\ 192.168.1.248 \ data $, я можу отримати належний доступ до файлів. Якщо я використовую FQDN: \\ ad.domain.name \ data $, він також працює. Будь-який інший комп’ютер у школі також має змогу належним чином отримати доступ до цієї акції.

Коли я намагаюся отримати доступ до папки з \\ ad \ data $, я отримую повідомлення "Ви не маєте дозволу на доступ \\ ad \ data $. Зверніться до адміністратора, щоб запитувати доступ." Я входив із обліковим записом адміністратора домену.

Будь-яка ідея про те, що могло б змусити одного доменного комп'ютера не отримати доступ до спільної доступу до нього, до якого він повинен мати доступ?

На сервері працює Windows Server 2008, а на комп'ютері працює Windows 7 SP1.

ОНОВЛЕННЯ

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

У мене щойно була подібна проблема.

У нас є домен і AD, і всі домашні папки користувачів налаштовані в AD.

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

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

Спочатку я також думав, що це проблема DNS.

Читаючи далі хтось сказав: "спробуйте видалити кеш CSC", і тоді я майже присягнувся на себе. Знаючи, що цей ноутбук використовувався іншим користувачем, який використовував офлайн-файли (Також їх домашня папка на тому ж сервері). Я знайшов швидкий спосіб видалити кеш CSC на Win 7 (це набагато простіше на XP). Перезавантажили комп’ютер і проблема була вирішена.

Ось посилання, на яких я знайшов інформацію:

http://www.petri.co.il/forums/showthread.php?t=60629

http://support.microsoft.com/kb/942974

Я бачив подібну проблему, і це було викликано тим, що DNS встановив автоматичне додавання доменного імені.

Отже, я би перевірив, що вибрано додавання первинних та специфічних для суфіксів DNS суффіксів та чи позначено додавання батьківських суфіксів основного суфікса DNS .

Це можна дізнатися через

Control Panel\Network and Internet\Network and Sharing Center
Local Area Connection Status
Properties
Internet Protocol Version 4 (TCP/IPv4) and/or Internet Protocol Version 6 (TCP/IPv6) 
Properties
Advanced
DNS

Win7 / server 2008> введіть панель керування в "Менеджер даних" та видаліть збережені облікові дані.

У мене була така ж проблема (траплялася зі мною кілька разів), і я вирішив її, видаливши всі підключені акції та відтворивши їх. Існувало кілька підключень до одних і тих же місць (використовуючи різні URL-адреси), і я підозрюю, що це було причиною проблем.

Використання командного рядка:

1. Щоб побачити підключені поточні акції
   net use
2. Щоб видалити з'єднання для спільного використання Y на xxx.xxx.xxx.xxx
   net use \\xxx.xxx.xxx.xxx\Y /delete
3. Щоб видалити з'єднання, щоб поділитися Y на XXX
   net use \\XXX\Y /delete
4. Щоб видалити картографічний мережевий диск
   net use Y: /delete
5. Щоб підключити повторно підключений мережевий диск
   net use Y: \\xxx.xxx.xxx.xxx\Y /PERSISTENT:YES /USER:XXX\user /SAVECRED

Ще один потенційний підозрюваний - менеджер Samsung PC Share. Після видалення його з хоста проблема зникла.

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

Чи відбувається це в обліковому записі локального адміністратора, наприклад, ім'я машини_ \ адміністратор?

Чи правильно встановлена ​​автентифікація машини на контролері домену?

Переконайтеся, що ви вже не підключаєтесь до \ ad за допомогою різних (або старих) облікових даних. Я бачив подібні проблеми, коли у мене було підключено карту, підключену до папки на сервері за допомогою мого "звичайного" доменного облікового запису, а потім я спробував підключитися до іншої папки на тому ж сервері, використовуючи мій обліковий запис адміністратора домену.

Чи вирішує проблему перезавантаження?

У мене була пов'язана проблема. У мене була машина для домашньої версії XP для доступу до спільних папок та накопичувачів на машині Windows 7. Я бавився з налаштуваннями Workgroup / Homegroup в Windows 7 і змінив опцію "Обмін захищеним паролем". Я міг бачити свої спільні папки на своїй домашній машині XP, але не міг читати чи писати з / до них. Це зводило мене з розуму - адже коли я створив нового користувача на машині XP Home і перейшов до своїх акцій на машині Win 7, проблем не було - я міг читати та писати файли!

Тож я повернувся до свого старого (основного) облікового запису користувача, і я не мав доступу до спільних файлів ...

Я пробував всі види рішень - net use * / del, і я намагався видалити облікові записи користувачів net / user - я намагався позбутися кешованих даних - але нічого не вийшло. Доступ до акцій через IP-адресу DID працює! Арггг !!

Я спробував встановити робочу групу на обох машинах на робочу групу (машина XP HOME була MSHOME)

Врешті-решт, що мені довелося зробити, це змінити КОМП'ЮТЕРНЕ ІМЕ на моїй машині Windows 7, перезавантажити, а потім отримати доступ до моїх спільних папок з машини HOME HOME. Потім він попросив користувача / пароль пароля, який я повторно ввів. Однак у мене були шляхи та речі, які використовували моє старе ім'я комп'ютера, тож я змінив свій комп’ютер Win 7 назад на те, що він був спочатку. Алілуя! Це спрацювало - знову мене запитали користувач / пароль, і я міг отримати доступ до своїх акцій з машини HOME!

Отже, підсумок: існує певна проблема з кешованими обліковими даними та немає очевидного способу їх видалення (нічого не було показано в Менеджері мережевих паролів в обліковому записі користувача). Тому тимчасово змініть ім’я комп'ютера та поверніть його назад, і це може вирішити деякі проблеми.

Я натрапив на кілька подібних питань на таких форумах, але жоден такий, як мій.

У мене виникла ця проблема після оновлення вікна Server 2008 R2 до Server 2012 R2 з оновленням. Для мене, зайшовши в диспетчер сертифікатів і видаливши облікові дані Windows -> Загальні облікові дані вирішили проблему.

В одному з моїх випадків, на моє здивування, виявилося, що мені потрібно очистити кеш DNS на додаток до включення функції підтримки SMB 1.0 у Windows 8.1. Це був комп'ютер з приєднанням домену, який був відключений від домену.

В іншому випадку комп’ютер, що не приєднується до домену, промиває кеш DNS не допомагає. Однак цікаво, що повноцінне ім’я \\Name.працювало тоді, коли \\Nameцього не було (я не намагався цього сина першою машиною). Я не впевнений, у чому тут проблема, але я здогадуюсь, що це пов’язано з відсутністю доменного імені.

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

Використовуване рішення полягало у вимкненні синхронізації в режимі офлайн.

Можуть бути мережеві ACL. В одному середовищі, в якому я працював, вони були змінені, щоб заблокувати порт 445. Отже:

\ ім'я хоста \ поділитися

• Клієнт намагався підключитися через SMB на порту 445 TCP / IP
• Блоковані мережевими ACL
• Клієнт не може підключитися

\ hostname.fqdn \ share

• Клієнт намагався підключитися через SMB через порт 445 TCP.IP
• Блоковані мережевими ACL
• Клієнт підключається через NetBT на порт 139
• Підключення вдало

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

Таким рішенням було розблокування порту 445.