Использование пространств имен dfs с файлами azure

Назначение и возможности DFS

Распределенная файловая система DFS (Distributed File System) появилась как
стандартный компонент еще в Win2k. Ее задача — облегчить управление, доступ и
поиск данных в сети. Для этого файловые ресурсы, находящиеся на разных
компьютерах, объединяются в единое логическое пространство имен. Пользователь,
вместо того чтобы запоминать имена всех общих сетевых ресурсов (Universal Naming
Convention, UNC), вроде \\Server\Folder, будет обращаться к единому пространству
UNC-имен, в котором объединены все серверы и общие ресурсы сети. А на каком
конкретно компьютере находится запрашиваемый файл, уже забота DFS, пользователю
не нужно беспокоиться о реальном расположении файла. При обращении клиента он
просто перебрасывается на нужный ему каталог. На месте источника, на который
указывает ссылка, может быть любая операционная система, к ресурсам которой
можно обратиться, используя UNC (Windows, Linux, xBSD, NetWare). Физические
объекты, связанные ссылками с DFS, называются целевыми объектами (targets) илирепликами (replics).

Но удобство для пользователей и администраторов — далеко не самое важное из
основных преимуществ DFS. Дело в том, что с одним логическим именем может быть
связано несколько общих ресурсов, в которых хранится идентичная информация.
Такой набор альтернативных общих ресурсов, связанных с одним логическим именемDFS, называется набором реплик

И если общие ресурсы находятся в одном
пространстве доменного корня DFS и располагаются на серверах Win2k или Win2k3,
есть возможность настроить автоматическую синхронизацию информации между ними.
Пользователь, обратившийся к DFS, обычно перенаправляется к ближайшей реплике, и
если она не доступна, он будет перенаправлен к альтернативному ресурсу. Для
уменьшения нагрузки на сервер DFS на стороне клиента данные кэшируются, поэтому
при частом обращении к одному и тому же ресурсу каждый запрос к DFS не
производится. Таким образом, автоматическое резервирование важной информации,
реализованное в DFS, еще и повышает отказоустойчивость всей системы (выход
одного сервера или дискового устройства не повлияет на работу пользователей).
Хотя следует помнить, что DFS не создавалась для работы часто с обновляющимися
данными, и особенно для тех случаев, когда файл одновременно может обновляться в
нескольких местах (в DFS остается та версия файла, где были внесены последние
изменения).

В реализации DFS в Win2k можно было разместить только одно пространство имен,
в Win2k3 их может быть уже несколько. В Win2k3 R2 появилась новая версия этой
системы — DFS Namespaces, в которой многие вопросы уже решены. За репликацию
данных в Win2k3 SP1 и SP2 отвечает FRS (File Replication Server), в Win2k3 R2 -DFS Replication. Главным их отличием является то, что в FRS самым маленьким
объектом, подлежащим репликации, является файл, в DFS Replication используется
более развитая технология RDC (Remote Differential Compression), которая умеет
копировать только изменившиеся части файла, а функция cross-file RDC меньше
нагружает канал при копировании новых файлов. Таким образом, использование DFS
еще и уменьшает нагрузку на сеть, что особенно актуально для удаленных офисов с
недостаточной пропускной способностью. В службе DFS не используется никаких
дополнительных средств обеспечения безопасности. При обращении к targets
проверяются только права доступа файловой системы и установленные для этих
объектов разрешения в каталоге Active Directory.

Имена сайтов

При создании имени нового сайта рекомендуем использовать допустимое DNS-имя. В противном случае сайт будет доступен только там, где используется DNS-сервер Майкрософт. Дополнительные сведения о допустимых DNS-именах см. в разделе .

• Допустимые символы

  DNS-имена могут содержать только буквы (A–Z), цифры (0–9), знак »минус» (-) и точку (.). Точки разрешено использовать только для разделения компонентов имен, заданных в формате доменных.

  В службе доменных имен (DNS) Windows 2000 и Windows Server 2003 поддерживается использование символов Юникода. В других реализациях службы DNS символы Юникода не поддерживаются. Не следует использовать знаки Юникода, если запросы будут передаваться на серверы с реализациями DNS, разработанными не корпорацией Майкрософт.

  Для получения дополнительных сведений посетите указанные ниже веб-сайты:

  • rfc952
  • rfc1123

• Запрещенные символы

  DNS-имена не могут содержать следующие символы:

  • Запятая (,)

  • Тильда (~)

  • Двоеточие (:)

  • Восклицательный знак (!)

  • Знак «@»

  • Символ решетки (#)

  • Знак доллара ($)

  • Знак процента (%)

  • Крышка (^)

  • амперсанд (&)

  • Апостроф (‘)

  • Точка (.)

  • Круглые скобки (())

  • фигурные скобки ({})

  • подчеркивание (_);

  • Пробел ( )

    Символ подчеркивания играет особую роль. Его разрешается использовать для первого символа в записях SRV по определению RFC. Но более новые DNS-серверы также могут разрешать его использовать в любом месте в имени. Дополнительные сведения см. в разделе Соблюдение ограничений имен для узлов и доменов.

    Другие правила:

  • Все символы, кроме ASCII, сохраняют регистр.

  • Первый символ должен быть буквой или цифрой.

  • Последним символом не может быть знак «минус» или точка.

• Минимальная длина имени: 1 символ

• Максимальная длина имени: 63 символа

  Максимальная длина DNS-имени составляет 63 байта на метку.

  В Windows 2000 и Windows Server 2003 для максимальной длины имени узла и полного доменного имени применяются упомянутые выше стандартные ограничения с добавлением поддержки UTF-8 (Юникода). Так как длина некоторых символов UTF-8 превышает один октет, определить размер подсчетом символов невозможно.

Этап 3. Настройка сервера DFSN для реагирования с помощью рефералов полного доменного имени для корневых целевых объектов

Примечание.

Прежде чем продолжить выполнение следующих действий для этапа 3, рекомендуется создать резервную копию метаданных пространства имен, чтобы защититься от непредвиденных сбоев или случайности. Действия резервного копирования вместе с другими шагами восстановления, если они вам когда-либо потребуются, описаны в шагах A и C раздела «Шаги для «.

Примечание.

Командлеты DFSN Windows PowerShell, упомянутые в этом разделе, доступны только с Windows Server 2012 или Windows 8.

1. Получите список доменных пространств имен, размещенных на сервере. Для этого используйте один из следующих методов:

   Примечание.

   Если на этом сервере пространств имен нет доменных пространств имен, вам не нужно будет выполнить некоторые действия, описанные в этой статье.

2. Примечание.

   Следующий шаг можно пропустить для серверов пространств имен, на которых размещены только автономные пространства имен.

   Как правило, доменные пространства имен размещаются на нескольких серверах пространств имен. Поэтому при удалении пространства имен с одного сервера пространства имен, как это происходит на этом шаге, доступность пространства имен не затрагивается. Однако следует убедиться, что на самом деле существует несколько серверов пространств имен, на которых размещено ваше пространство имен. Для этого используйте один из следующих методов:

   

   

   

   

   

   

   

   

   

   

   Например, заполнитель может представлять следующее: Если вы подтверждаете наличие нескольких серверов пространства имен, на которых размещено пространство имен, можно пропустить следующий шаг C.

3. Примечание.

   Следующий шаг можно пропустить для серверов пространств имен, на которых размещены только автономные пространства имен. Этот шаг также можно пропустить, если вы подтверждаете наличие нескольких серверов пространства имен, на которых размещено ваше пространство имен.

   Если для пространства имен есть только один сервер пространства имен, необходимо временно добавить новый сервер пространства имен перед удалением существующего сервера. (См . раздел «Добавление серверов пространства имен в пространство имен DFS на основе домена» или командлет New-DfsnRootTarget.) Или необходимо сохранить метаданные пространства имен для повторного создания позже. (Для этого см. шаги А и C раздела «.) Однако следует помнить, что второй подход приведет к временному простою пространства имен.

4. Примечание.

   Следующий шаг можно пропустить для серверов пространств имен, на которых размещены только автономные пространства имен.

   Удалите с сервера каждое размещенное доменное пространство имен. Для этого используйте один из следующих методов:

   Например, заполнитель может представлять следующее:

5. Включите поведение корневой реферальной рекомендации DFSN FQDN. Для этого используйте один из следующих методов:

6. Перезапустите службу DFSN. Для этого используйте один из следующих методов:

7. Примечание.

   Следующий шаг можно пропустить для серверов пространств имен, на которых размещены только автономные пространства имен.

   Восстановите каждое пространство имен, ранее удаленное с этого сервера пространства имен. Для этого используйте один из следующих методов:

8. В зависимости от того, что вы сделали на шаге Б, выполните следующие необязательные действия.

   1. Если вы создали резервную копию метаданных пространства имен на шаге Б, вы можете импортировать метаданные в только что созданное пространство имен. Перед импортом метаданных можно также внести необходимые изменения в рамках того же шага. (См. «.)
   2. Если вы временно добавили сервер пространства имен на шаге Б, его можно удалить.

Файл LMHOSTS

Файл LMHOSTS (LAN Manager Hosts) используется для разрешения (преобразования) доменных имён в Windows, когда другие методы, такие как WINS, не работают. Используется совместно с рабочими группами и доменами. Если вы ищете простой, общий механизм для локальной спецификации IP-адресов для определённых имён хостов (имён серверов), используйте файл HOSTS, а не файл LMHOSTS.

Файл, если он существует, читается как файл настроек LMHOSTS. Пример файла (lmhosts.sam) предоставляется. Он содержит документацию для ручной настройки файла.

В Windows NT 4.0, Windows 2000, Windows XP, Vista, 7, 8, 10, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2016+ файл находится в %windir%\system32\drivers\etc\, и там же размещён пример файла (lmhosts.sam)

Обратите внимание, что %windir% является переменной окружения, указывающей на папку, куда установлена Windows, обычно это C:\Windows.. Синтаксис файла LMHOSTS такой же, как и у HOSTS, то есть:

Синтаксис файла LMHOSTS такой же, как и у HOSTS, то есть:

IP_АДРЕС	ИМЯ_ХОСТА

Эти разные корни

Начальной точкой для всех имен дерева DFS служит корень распределенной
файловой системы. Фактически корень — это некоторый общий ресурс, находящийся на
сервере, все остальные логические имена системы DFS будут подключаться как
следующий иерархический уровень. Корни в DFS могут быть двух видов, каждый
отличается способами хранения данных и возможностями. Изолированный (автономный)
корень (Standalone DFS) не связан с Active Directory, и все ссылки на сетевые
ресурсы хранятся в реестре самого сервера DFS. Такой корень не используетDFS
Replication, то есть не предполагает дублирование информации на другие ресурсы,
и поэтому не обеспечивает отказоустойчивость. При выходе из строя сервера DFS
вся иерархия становится не доступной, хотя пользователи могут обращаться к
ресурсам напрямую. К слову, несколько Standalone DFS серверов способны работать
в кластере, поэтому эта проблема может быть решена. Если сервер DFS является
членом домена, используется доменный корень (Domain-based DFS). При таком
варианте можно подключать несколько реплик и использовать DFS Replication для
репликации как самого корня, так и ссылок DFS. Если в Domain-based DFS корни
находятся на компьютерах под управлением Win2k и Win2k3, то такой корень
называется «Mixed mode domain DFS».

Причины ошибки «Не удалось изменить DNS-имя основного контроллера домена»

Рассмотрим причины, по которым ваш компьютер не может пройти аутентификацию на DC и не содержится в его базе.

• Остались хвосты от предыдущей учетной записи с тем же именем
• Проблема в отключенном  NetBIOS в TCP/IP
• Режет пакеты Firewall
• На контроллере закрыт UDP-порт 137
• Отсутствует PTR запись на dns имя этой учетной записи компьютера

Чистим старые хвосты в Active Directory

Сразу хочу отметить, что данный способ у меня отработал сразу. Я полностью удалил учетную запись компьютера, с которым были проблемы. После чего снова добавил нужный сервер в домен, и он уже не выдавал ошибку «Не удалось изменить DNS-имя основного контроллера домена на «» для этого компьютера». Учетная запись появилась в привычном контейнере «Computers»

Убедитесь, что включен NetBIOS через TCP/IP

Нажмите WIN+R и введите ncpa.cpl, у вас откроется окно «Панель управления\Все элементы панели управления\Сетевые подключения». Выберите ваш сетевой интерфейс, который смотрит в туже сеть, что и DC его аутентифицирующий. Перейдите в свойства сетевого интерфейса, выберите «Протокол Интернета версии 4 (TCP/IPv4)», далее кнопка «Дополнительно». На вкладке WINS, вам необходимо выбрать пункт «Включить NetBIOS» через TCP/IPv4 и сохранить настройки.

Так же на вкладке DNS, вы можете прописать дополнительные DNS суффиксы (полное имя домена), нажмите ок.

В принципе этого достаточно, чтобы избавится от ошибки «»Не удалось изменить DNS-имя основного контроллера домена на «» для этого компьютера. Будет использоваться прежнее имя: contoso.com. Убедитесь, что имя «» является допустимым для текущего домена. Ошибка: При изменении имени узла DNS для объекта невозможно синхронизировать значения имени субъекта службы»»

Если вам не помогли манипуляции, то ставьте варшарк и смотрите трафик и доступность портов, не блокирует ли у вас то-то.

Как обнаружить NetBIOS

Можно запустить обычное сканирование TCP портов в локальной сети с помощью nmap:

sudo nmap _gateway/24

И среди результатов можно обнаружить открытый TCP порт 139:

139/tcp  open  netbios-ssn

Если нас интересует только службы NetBIOS, то достаточно искать UDP порты 137 и 138 и TCP порты 137 и 139, воспользуемся и составим такую команду:

sudo nmap -p U:137,138,T:137,139 -sU -sS _gateway/24

Плюс такого подхода в том, что сканирование происходит намного быстрее и дополнительно найдены открытые порты UDP.

Можно воспользоваться ещё одним рецептом , для этого добавим опции -sV —script=banner:

sudo nmap -p U:137,138,T:137,139 -sU -sS -sV --script=banner _gateway/24

Благодаря последней команде мы дополнительно узнали:

• используемую рабочую группу (WORKGROUP)
• операционную систему для некоторых устройств (Windows 10)
• некоторые открытые порты связаны с Samba smbd 3.X — 4.X

Дополнительно можно воспользоваться скриптами Nmap (NSE) — я нашёл 4 скрипта, которые связаны с NetBIOS:

nbd-info

Отображает информацию о протоколах и блочных устройствах с серверов NBD.

nbstat

Пытается получить имена NetBIOS и MAC-адрес цели.

broadcast-netbios-master-browser

Пытается обнаружить главные браузеры и домены, которыми они управляют.

nbns-interfaces

Получает IP-адреса целевых сетевых интерфейсов через NetBIOS NS. Дополнительные сетевые интерфейсы могут раскрывать больше информации о цели, включая поиск путей к скрытым немаршрутизируемым сетям через многосетевые системы.

Для их использования во время сканирования команда примерно следующая:

sudo nmap -p U:137,138,T:137,139 -sU -sS --script nbstat,nbd-info,broadcast-netbios-master-browser,nbns-interfaces _gateway/24

Результаты:

Применение исправлений (сервер и клиент)

Для Windows 7 и Windows Server 2008 R2 примените следующий Windows 7 Корпоративная исправлений:

Кроме того, примените следующие исправления:

• Сообщение об ошибке «Сбой отложенной записи», когда PST-файлы хранятся на сетевом файловом сервере под управлением Windows Server 2008 R2
• При попытке входа на клиентский компьютер под управлением Windows 7 или Windows Server 2008 R2, использующий перемещаемые профили, происходит длительное время входа.
• OpsMgr 2012 или OpsMgr 2007 R2 создает сообщение «Heartbeat Failure» (Сбой пульса), а затем переходит в состояние «серый» в Windows Server 2008 R2 с пакетом обновления 1 (SP1)

nbtstat

Программа nbtstat предназначена для отображения статистики протокола NetBIOS и текущих подключений TCP/IP с помощью NBT (NetBIOS через TCP/IP). Программа nbtstat предустановлена в Windows, то есть её не нужно скачивать и устанавливать, но нужно запускать в командной строке. Смотрите «Настройка рабочего окружения PowerShell в Windows и Linux».

Использование:

NBTSTAT    
              ]

Опции:

  -a  (adapter status) Вывод таблицы имён узла, указанного по имени.
  -A  (Adapter status) Вывод таблицы имён узла, указанного по IP-адресу.
  -c  (cache)          Вывод буфера имён удалённых узлов, включая адреса IP.
  -n  (names)          Вывод локальных имён NetBIOS.
  -r  (resolved)       Вывод имён, определённых с помощью рассылки и WINS.
  -R  (Reload)         Очистка и перезагрузка таблицы удалённого буфера имён.
  -S  (Sessions)       Вывод таблицы сеансов с IP-адресами.
  -s  (sessions)       Вывод таблицы сеансов с преобразованием IP-адресов
                       в имена NETBIOS.
  -RR (ReleaseRefresh) Отсылка пакетов освобождения имени (Name Release)на
                       WINS-сервер, а затем запуск обновления (Refresh)


  Узел         Имя удалённого компьютера.
  IP-адрес     IP-адрес удалённого компьютера.
  интервал     Повторный вывод статистических данных через указанный
               интервал в секундах. Для прекращения вывода нажмите
               клавиши <CTRL>+<C>.

Рассмотрим примеры использования nbtstat.

Чтобы по IP адресу узнать имя хоста используйте опцию -A:

nbtstat -A 192.168.0.53

Чтобы просмотреть имена компьютеров и их IP, сохранённые в кэше укажите опцию -c:

nbtstat -c

Чтобы узнать имя текущего компьютера используйте nbtstat с опцией -n:

nbtstat -n

Для вывода имён, определённых с помощью рассылки и WINS запустите такую команду:

nbtstat -r

Аннотация

По умолчанию ответ корневого реферала пространства имен распределенной файловой системы Майкрософт (DFSN) на запрос корневой реферальной ссылки DFS имеет формат netBIOS (). Это необходимо в определенных средах, которые используют NetBIOS и делают возможным для клиентов, поддерживающих разрешение имен netBIOS только для поиска и подключения к целевым объектам в пространстве имен DFS. По умолчанию клиенты Windows работают с ним нормально.

Однако некоторые клиенты не используют NetBIOS. Два примера — это клиенты, которые не работают под управлением Windows, и клиенты, работающие в среде без WINS или использующие DNS-суффиксы имен. Эти клиенты несовместимы с поведением DFSN по умолчанию.

В таких случаях клиенту может быть не удается разрешить имя сервера, возвращаемое из корневого запроса рефералов. Однако эту проблему можно легко решить, так как DFSN можно настроить для работы в среде, доступной только для DNS.

Примечание.

Для серверов пространств имен, на которых размещены только автономные пространства имен, некоторые действия, описанные в этой статье, не нужны. (Такие серверы пространств имен включают кластеризованные пространства имен.) По умолчанию клиенты DFSN могут получить доступ к таким автономным пространствам имен через пути к пространству имен. Однако для автономных пространств имен по-прежнему требуется настройка сервера пространства имен для предоставления правильных ссылок.

Действия, описанные в этой статье, применяются ко всем серверам пространства имен DFS, независимо от того, действуют ли такие серверы пространства имен в качестве контроллеров домена Active Directory.

Симптомы

Компьютер под управлением Microsoft Windows 2000 Server или Microsoft Windows Server 2003 может вызывать проблемы с подключением, если сервер настроен следующим образом:

• Служба маршрутизации и удаленного доступа настроена для разрешения входящих подключений.
• Служба доменных имен (DNS) или windows Internet Name Server (WINS) устанавливается и настраивается на сервере, на котором выполняется маршрутизация и удаленный доступ.

После подключения удаленного компьютера к серверу маршрутизации и удаленного доступа с помощью коммутируемого или VPN-подключения может возникать один или несколько из следующих симптомов:

• Если на сервере маршрутизации и удаленного доступа также запущен сервер Microsoft Internet Security and Acceleration (ISA) Server 2000, вы не сможете просматривать Интернет с клиентских компьютеров в локальной сети независимо от того, настроены ли компьютеры для использования веб-прокси или клиент межсетевого экрана (Майкрософт). Например, в веб-браузере может появиться сообщение об ошибке «Не удается найти сервер или DNS».

• Если сервер маршрутизации и удаленного доступа работает под управлением ISA Server 2000, а пользователь на клиентском компьютере выбирает «Обновить сейчас» в диалоговом окне «Параметры клиента брандмауэра», пользователь получает следующее сообщение об ошибке:

• При попытке проверить связь с сервером маршрутизации и удаленного доступа с локального компьютера с помощью netBIOS-имени сервера или полного доменного имени (FQDN) компьютер пытается проверить связь с неправильным IP-адресом.

• Если сервер маршрутизации и удаленного доступа является главным браузером для сети, вы не сможете просмотреть список компьютеров в сетевом окружении или в разделе «Мои сетевые расположения».

• Невозможно подключиться к http:// server_name/myconsole
  сайт на компьютере Small Business Server 2000.

• На сервере маршрутизации и удаленного доступа вы получаете сообщение о событии, похожее на следующее:

• При попытке открыть общие папки или сопоставить сетевые диски с сервером маршрутизации и удаленного доступа вы получите сообщения об ошибках.

• Если сервер маршрутизации и удаленного доступа также является контроллером домена, при попытке входа в сеть вы получаете сообщения об ошибках.

• Если сервер маршрутизации и удаленного доступа является контроллером домена, при попытке открыть общие файловые ресурсы или сопоставить сетевые диски с любым общим ресурсом в сети вы получите сообщения об ошибках. Например, компьютеры под управлением Microsoft Windows 2000 Профессиональный или Microsoft Windows XP Professional получают сообщение об ошибке, похожее на следующее:

Эта проблема обычно затрагивает компьютеры под управлением Small Business Server, так как эта версия Windows Server часто является единственным сервером в сети. Однако эта проблема может повлиять на любой сервер под управлением Windows 2000 или любой сервер маршрутизации и удаленного доступа windows Server 2003, на котором запущена служба DNS или WINS.

Решение

Чтобы устранить эту проблему на файловом сервере, на котором запущен протокол SMB версии 1, добавьте значение в реестр:

Важно!

Не используйте DNS CNAMEs в будущем для файловых серверов. Если вы хотите по-прежнему присваивать альтернативные имена серверам, это можно сделать с помощью следующей команды:
NETDOM COMPUTERNAME/ADD

Эта команда автоматически регистрирует имена субъектов-служб для альтернативных имен.

Не рекомендуется устранять эту проблему для файлового сервера, который не основан на Windows, введя следующие команды в окне командной строки с повышенными привилегиями на компьютере под управлением Windows. Вам придется войти в систему с учетными данными администратора домена. Затем нажмите клавишу ВВОД в командной строке, чтобы зарегистрировать имя субъекта-службы для CNAME устройства хранения файлового сервера, отличного от Windows:

Примечание.

• Если используется кластеризация Windows 2012, установите исправление для клиентов более высокого уровня, к которым компьютеры Windows XP или Windows Server 2003 не могут подключиться: не удается получить доступ к ресурсу, размещенного в отказоустойчивом кластере на основе Windows Server 2012.
• При создании CNAME для кластеризованного имени, к котором подключаются клиенты, необходимо настроить свойства этого кластеризованного имени таким образом, чтобы оно отвечало на CNAME: настройка псевдонима для кластеризованной общей папки SMB с помощью Windows Server 2012.

Как соотносится Имя NetBIOS с именем хоста в Интернете

Когда NetBIOS работает в сочетании с интернет-протоколами (например, NBT), каждый компьютер может иметь несколько имён: одно или несколько имён службы имен NetBIOS и одно или несколько имён хостов Интернета.

Имя NetBIOS

Имя NetBIOS состоит из 16 символов ASCII, однако Microsoft ограничивает имя хоста 15 символами и резервирует 16-й символ как суффикс NetBIOS. Этот суффикс описывает тип записи службы или имени, такой как запись узла, основная запись браузера или запись контроллера домена или другие службы. Имя хоста (или короткое имя хоста) указывается при установке/настройке сети Windows, зарегистрированные суффиксы определяются отдельными сервисами, предоставляемыми хостом. Чтобы подключиться к компьютеру под управлением TCP/IP через его имя NetBIOS, имя должно быть преобразовано в сетевой адрес. Сегодня это обычно IP-адрес (преобразование имени NetBIOS в IP-адрес часто выполняется с помощью широковещательной рассылки или сервера WINS — сервера имён NetBIOS). NetBIOS-имя компьютера часто совпадает с именем хоста этого компьютера, хотя оно усекается до 15 символов, но оно также может быть и совершенно другим.

Имена NetBIOS представляют собой последовательность буквенно-цифровых символов. Следующие символы явно недопустимы: \/:*?»<>|. Начиная с Windows 2000, имена NetBIOS также должны соответствовать ограничениям на DNS-имена: они не могут состоять исключительно из цифр и дефиса («-«), а символ точка («.») не могут отображаться в качестве первого или последнего символа. Начиная с Windows 2000, Microsoft не рекомендует включать любые символы точка («.») в имена NetBIOS, так что приложения могут использовать присутствие точки, чтобы отличить доменные имена от имён NetBIOS.

Файл Windows LMHOSTS предоставляет метод разрешения имён NetBIOS, который можно использовать в небольших сетях, в которых не используется сервер WINS. О файле LMHOSTS далее.

Интернет имя хоста

NetBIOS-имя Windows-машины не следует путать с именем хоста компьютера в Интернете (при условии, что компьютер также является хостом Интернета, а не узлом NetBIOS, что не обязательно должно иметь место). Как правило, компьютер, на котором запущены интернет-протоколы (будь то компьютер с Windows или нет), обычно имеет имя хоста (также иногда называемое именем компьютера). Первоначально эти имена хранились в файле hosts и предоставлялись им, но сегодня большинство таких имён являются частью иерархической системы доменных имен (DNS) (смотрите Введение в DNS терминологию, компоненты и концепции).

Обычно имя хоста компьютера Windows основывается на имени NetBIOS плюс первичный DNS-суффикс, которые оба задаются в диалоговом окне «Свойства системы». Также могут существовать суффиксы для конкретного соединения, которые можно просмотреть или изменить на вкладке DNS в Панели управления → Сеть → TCP / IP → Дополнительные свойства. Имена хостов используются такими приложениями, как telnet, ftp, веб-браузеры и т. д. Чтобы подключиться к компьютеру, использующему протокол TCP/IP, используя его имя, имя хоста должно быть преобразовано в IP-адрес, обычно DNS-сервером. (Также возможно работать со многими приложениями на основе TCP/IP, включая три, перечисленные выше, используя только IP-адреса, но это не норма.)

Причина

• Если для проверки сетевой трассировки при успешной настройке сеанса SMB используется сетевой монитор, Wire Exchange или Анализатор сообщений Майкрософт, сеанс переходит к tree Connect.

  Однако при проверке трассировки сети при неудачной установке сеанса SMB сеанс завершается сбоем с ошибкой Kerberos KRB_AP_ERR_MODIFIED. Ниже приведен пример неудачного запроса на настройку сеанса SMB в трассировке сети:

  В неудачном запросе на установку сеанса SMB клиент пересылает неправильное имя субъекта-службы CNAME. Имя субъекта-службы может быть неверным, так как оно зарегистрировано для старого сервера. Однако в успешном запросе на установку сеанса SMB, например в клиентском случае Windows Server 2008 R2, клиент пересылает имя субъекта-службы для фактического имени сервера.

• Если имя файлового сервера было разрешено через DNS, клиент SMB добавляет DNS-суффикс к предоставленному пользователем имени. То есть первым компонентом имени субъекта-службы всегда будет предоставленное пользователем имя, как показано в следующем примере:

  Примечание.

  Эта попытка завершится сбоем в более старых реализациях SMB (например, AIX Samba 3.5.8), которые не могут быть настроены для проверки подлинности Kerberos и не прослушивают порт 445 прямого узла SMB, но только через порт NetBIOS 139.

• Если имя файлового сервера было разрешено с помощью другого механизма, например

  • Netbios
  • Link-Local Multicast Name Resolution (LLMNR)
  • Процессы протокола PNRP

  клиент SMB использует указанное пользователем имя, например следующее:

Методы разрешения имени NetBIOS

Очевидно, что тут мы будем говорить о том, какими средствами NetBIOS удается найти соответствие имени и IP-адреса ресурса? Какие же методы определения имен доступны интерфейсу NetBIOS? Сразу обращу ваше внимание на то, что не все из перечисленных методов относятся непосредственно к стандарту NetBIOS. Я считаю, что к NetBIOS относятся только лишь: LMHOSTS, WINS, кеш имен NetBIOS, широковещательный запрос в подсети

Такие же понятия как HOSTS и DNS относятся уже к TCP/IP Direct Hosting. Но поскольку понятия «NetBIOS имя станции» и «имя хоста» довольно тесно взаимосвязаны в современных ОС Windows, то resolver (модуль, разрешающий имена) использует все доступные методы для нахождения соответствия, умело комбинируя разнородные методы определения имен.

• NetBIOS name cache (локальный кеш NetBIOS) — специальная структура в памяти процесса для записи результатов разрешения имен. Время жизни записей — 10 минут. Приложение смотрит в локальном кэше, нет ли там искомого имени. И правда, зачем нам тратить время на другие методы, если может статься, что мы недавно уже обращались к станции, и имя её содержится в локальном кеше. Локальный кеш NetBIOS можно посмотреть командой «nbtstat -r». Некоторые параметры, которые влияют на функционал NetBIOS name cache можно найти в ветке реестра .
• NetBIOS name server (WINS, NBNS). Если сказать иначе, WINS это DNS от Microsoft для NetBIOS. Станции с определенными типами узлов обращаются к WINS-серверу за разрешением имени.
• IP subnet broadcast — широковещательное сообщение в IP-подсети. Станции с определенными типами узлов формируют широковещательный запрос для разрешения имени.
• Локальный LMHOSTS файл. Аналог файла для NetBIOS. Файл, в котором, в специальном формате, хранится таблица соответствия имен NetBIOS IP-адресам. Размещается в директории .
• Локальный HOSTS файл. Файл, в котором, в специальном формате, хранится таблица соответствия имен хостов (TCP/IP hostname) IP-адресам. Располагается в директории . Этот метод непосредственно не относится к NetBIOS через TCP/IP, а относится уже к TCP/IP Direct Hosting. Если NetBIOS имя найти не удалось, то имя считается как TCP/IP hostname и разрешается уже методами HOSTS+DNS.
• DNS-сервер. Запрос к DNS-серверу. DNS-сервер возвращает запись о соответствии имени хоста IP-адресу.

Оглавление

У каждого компьютера Windows есть Имя компьютера. Если даже вы его не устанавливали, то значит там записано сгенерированное при установке операционной системы имя.

Это имя компьютера в локальной сети можно использовать как полную альтернативу локальному IP адресу:

• обращаться к совместным ресурсам (сетевые папки и принтеры)
• обращаться к запущенным сетевым службам (веб-сервер, FTP и др.)

Больше подробностей смотрите в статье «Имя компьютера Windows: как изменить и использовать».

При этом не требуется какая-либо настройка DNS или файла hosts, поскольку такое распознавание имён обеспечивается NetBIOS. Мы уже сталкивались с NetBIOS, а точнее с одной из трёх его служб — NBT-NS — в статье «Взлом сетевой аутентификации Windows». Это одна из служб, которая эксплуатировалась для выполнения атаки.

То есть, NetBIOS имеет важное значение для Windows, а также для изучения устройства Windows, анализа сетевой активности Windows и в вопросах безопасности локальных сетей и компьютеров с Windows.

Естественно, в лучших в традициях HackWare.ru, в статье будет только необходимая теория и максимум практики — мы будем «щупать» протокол NetBIOS в Wireshark, встроенной утилите Windows и в специализированных инструментах для аудита безопасности. Но начнём всё-таки с теории.