Домена имя netbios – Иллюстрированный самоучитель по Microsoft Windows 2003 › Основные концепции Active Directory › Глобально уникальные идентификаторы. Имена NetBIOS. Унифицированный указатель ресурсов LDAP. Канонические имена. [страница — 613] | Самоучители по операционным системам

Каждый компьютер, доступный из Интернета, имеет DNS-имя. Это имя также называется именем компьютера или именем узла. Кроме того, каждый компьютер с операционной системой Microsoft Windows, поддерживающий работу в сети, имеет NetBIOS-имя.

Компьютер под управлением Windows в домене службы каталогов Active Directory имеет как DNS-имя домена, так и NetBIOS-имя домена. DNS-имя домена состоит из одного или нескольких дочерних доменов, разделенных точкой (.), и оканчивается именем домена верхнего уровня. Например, в DNS-имени домена corp.contoso.com дочерними доменами являются corp и contoso, а имя домена верхнего уровня — com. Обычно NetBIOS-имя домена является дочерним для DNS-имени домена. Например, DNS-имя домена — contoso.com, а NetBIOS-имя домена — contoso. Если DNS-имя домена — corp.contoso.com, то NetBIOS-имя домена — corp.

Компьютеры в домене Active Directory также имеет основной DNS-суффикс и (в некоторых случаях) дополнительные DNS-суффиксы. По умолчанию основной DNS-суффикс совпадает с DNS-именем домена. Дополнительные сведения об изменении основного DNS-суффикса см. в описании процедур ниже в этом разделе.

DNS-имя домена и NetBIOS-имя домена Active Directory определяются при настройке первого контроллера домена в домене. Дополнительные сведения о настройке контроллеров домена см. в разделе Роль контроллера домена: настройка контроллера домена (на английском языке).

На рисунке ниже показана страница мастера установки Windows Server 2003 Active Directory, на которой определяется DNS-имя домена Active Directory.

На рисунке ниже показана страница мастера установки Windows Server 2003 Active Directory, на которой определяется NetBIOS-имя домена Active Directory.

В процедурах этого раздела описано, как просмотреть следующие элементы на компьютере под управлением Windows Server 2008 или Windows Server 2003:

• DNS-имя узла
• основной DNS-суффикс
• DNS-имя домена
• NetBIOS-имя
• NetBIOS-имя домена

1. Нажмите кнопку Пуск, щелкните правой кнопкой мыши пункт Компьютер и выберите команду Свойства.

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

3. Нажмите кнопку Изменить параметры.

4. В окне Свойства системы на вкладке Имя компьютера нажмите кнопку Изменить.

5. На странице Изменение имени компьютера или домена нажмите кнопку

   Дополнительно. Основной DNS-суффикс выводится в поле Основной DNS-суффикс этого компьютера. NetBIOS-имя компьютера выводится в поле NetBIOS-имя компьютера.

   Чтобы изменить основной DNS-суффикс, введите новое значение в поле Основной DNS-суффикс этого компьютера и нажмите кнопку ОК.

6. В окне командной строки введите set. Переменная USERDNSDOMAIN выводит DNS-имя домена. Переменная USERDOMAIN выводит NetBIOS-имя домена.

1. Нажмите кнопку Пуск, щелкните правой кнопкой мыши пункт Мой компьютер и выберите команду Свойства.

2. В окне Свойства системы откройте вкладку Имя компьютера. DNS-имя узла и основной DNS-суффикс выводятся в разделе Полное имя компьютера

   . DNS-имя домена выводится рядом с надписью Домен.

3. На вкладке Имя компьютера нажмите кнопку Изменить.

4. На странице Изменение имени компьютера нажмите кнопку Дополнительно. Основной DNS-суффикс выводится в поле Основной DNS-суффикс этого компьютера. NetBIOS-имя компьютера выводится в поле NetBIOS-имя компьютера.

   Чтобы изменить основной DNS-суффикс, введите новое значение в поле Основной DNS-суффикс этого компьютера и нажмите кнопку ОК.

5. В окне командной строки введите set. Переменная USERDNSDOMAIN выводит DNS-имя домена. Переменная USERDOMAIN выводит NetBIOS-имя домена.

В большинстве топологий домена основной DNS-суффикс компьютеров в домене совпадает с DNS-именем домена. На рисунке ниже показан обычный сценарий пространства имен, в котором совпадают основной DNS-суффикс, DNS-имя домена и NetBIOS-имя домена.

В некоторых случаях может потребоваться, чтобы эти пространства имен различались. Такие пространства имен называются несвязанными. Например, топология с несвязанным пространством имен может возникнуть в результате слияния или поглощения компаний. Кроме того, если управлением DNS в компании занимаются как администраторы Active Directory, так и администраторы сетей, может потребоваться топология с несвязанным пространством имен.

Несвязанное пространство имен возникает в случае, если основной DNS-суффикс компьютера не соответствует DNS-имени домена, в котором находится компьютер. Компьютер с несоответствующим основным DNS-суффиксом называется несвязанным. Кроме того, несвязанное пространство имен возникает в случае, если NetBIOS-имя домена контроллера домена не соответствует DNS-имени домена.

В Microsoft Exchange Server 2007 поддерживаются три сценария развертывания Exchange в домене с несвязанным пространством имен. Эти сценарии описаны ниже.

• Сценарий 1. Основной DNS-суффикс контроллера домена не совпадает с DNS-именем домена. Компьютеры, которые являются членами домена, могут быть связанными или несвязанными.
• Сценарий 2. Рядовой компьютер в домене Active Directory является несвязанным, хотя домен не является таковым.
• Сценарий 3. NetBIOS-имя домена контроллера домена не совпадает с соответствующим дочерним доменом DNS-имени домена.

Эти сценарии подробно описаны ниже.

Сценарий 1

Чтобы серверы Exchange 2007 могли получать доступ к несвязанным контроллерам домена, необходимо изменить атрибут msDS-AllowedDNSSuffixes Active Directory контейнера объекта домена. Необходимо добавить к атрибуту оба DNS-суффикса. Дополнительные сведения об изменении атрибута см. в разделе Основный DNS-суффикс компьютера не совпадает с полным доменным именем домена, в котором он расположен (на английском языке).

Кроме того, чтобы убедиться, что список поиска DNS-суффиксов содержит все пространства имен DNS, развернутые в организации, необходимо настроить список поиска для каждого несвязанного компьютера в домене. Список пространств имен должен включать не только основной DNS-суффикс контроллера домена и DNS-имя домена, но и дополнительные пространства имен других серверов, с которыми может взаимодействовать Exchange, таких как серверы наблюдения или серверы для приложений сторонних разработчиков.  Для этого можно использовать групповую политику на уровне домена. Дополнительные сведения о групповой политике см. в следующих разделах:

Дополнительные сведения о настройке групповой политики списка поиска DNS-суффиксов см. в разделе Настройка списка поиска DNS-суффиксов для несвязанного пространства имен.

Сценарий 2

В этом сценарии основной DNS-суффикс рядового компьютера с Exchange 2007  не совпадает с DNS-именем домена, хотя основой DNS-суффикс контроллера домена совпадает с DNS-именем домена. В этом сценарии существует контроллер домена, который не является несвязанным, и рядовой компьютер, который является несвязанным. Рядовые компьютеры с Outlook могут иметь основной DNS-суффикс, который соответствует либо основному DNS-суффиксу несвязанного сервера Exchange, либо DNS-имени домена.

Чтобы несвязанные серверы Exchange 2007 могли получать доступ к контроллерам домена, необходимо изменить атрибут msDS-AllowedDNSSuffixes Active Directory контейнера объекта домена. Необходимо добавить к атрибуту оба DNS-суффикса. Дополнительные сведения об изменении атрибута см. в разделе Основный DNS-суффикс компьютера не совпадает с полным доменным именем домена, в котором он расположен (на английском языке).

Кроме того, чтобы убедиться, что список поиска DNS-суффиксов содержит все пространства имен DNS, развернутые в организации, необходимо настроить список поиска для каждого несвязанного компьютера в домене. Список пространств имен должен включать не только основной DNS-суффикс несвязанного рядового компьютера и DNS-имя домена, но и дополнительные пространства имен других серверов, с которыми может взаимодействовать Exchange, таких как серверы наблюдения или серверы для приложений сторонних разработчиков. Для этого можно использовать групповую политику на уровне домена. Дополнительные сведения о групповой политике см. в следующих разделах:

Дополнительные сведения о настройке групповой политики списка поиска DNS-суффиксов см. в разделе Настройка списка поиска DNS-суффиксов для несвязанного пространства имен.

Сценарий 3

В этом сценарии NetBIOS-имя домена контроллера домена не совпадает с DNS-именем домена того же контроллера домена.

Exchange 2007 можно выполнять во всех сценариях несвязанных пространств имен, описанных в этом разделе. Если сценарий несвязанных пространств имен не соответствует представленным в этом разделе, при развертывании Exchange 2007 необходимо обращаться в службу технической поддержки корпорации Майкрософт. Дополнительные сведения см. на странице Служба технической поддержки корпорации Майкрософт (на английском языке).

unifiedpeople.ru

Описание имен NetBIOS и FQDN

Еще одним из аспектов работы с протоколом TCP/IP является понимание концепции имен NetBIOS и полностью определенных доменных имен (FQDN). Когда компьютеры используют протокол TCP/IP намного проще запомнить дружественное имя, а не простой адрес IP.

Имена NetBIOS и имена FQDN предоставляют возможность связать дружественное имя с сетевым объектом, но основной разницей между этими двумя именами является их отображение. Имя FQDN обычно имеет вид <имя компьютера>.<имя домена>.<расширение домена>, например, www.microsoft.com. Имя NetBIOS является простым именем, которое используется для представления системы, но оно ограничено размером в 15 символов.

Эквивалентом имени FQDN www.microsoft.com в системе именования NetBIOS будет www.

А теперь представьте себе, сколько компьютеров с именем www находится в данный момент в сети. Если использовать систему именования NetBIOS в Интернет, не будет возможности отличить один компьютер от другого, именно поэтому система именования для распределенной сетевой среды использует полностью определенные доменные имена.

Теперь, когда мы разобрались с фундаментальной разницей между именованием NetBIOS и FQDN, рассмотрим правила именования, связанные с каждой системой.

Вот правила для системы именования NetBIOS:

• Имена не могут начинаться с цифры.
• Имена не могут быть длиннее 15 символов.
• Имена могут использоваться символы A-Z,a-z,0-9 и дефисы. Имена не чувствительны к регистру.
• Имена могут иметь пробелы (пробел считается одним из символов).

Теперь давайте посмотрим на правила для FQDN:

• Имена могут начинаться с цифры.
• Имена не могут быть длиннее 255 символов (имена контроллеров доменов не могут быть длиннее 155 символов).
• Имена могут использоваться символы A-Z,a-z,0-9 и дефисы. Имена не чувствительны к регистру.
• Имена не могут содержать пробелы.
• Части имени разделяются точкой (www.windata.ru).

windata.ru

смешивать, но не взбалтывать / Блог компании Сервер Молл / Хабр

В очередном «конспекте админа» остановимся на еще одной фундаментальной вещи – механизме разрешения имен в IP-сетях. Кстати, знаете почему в доменной сети nslookup на все запросы может отвечать одним адресом? И это при том, что сайты исправно открываются. Если задумались – добро пожаловать под кат..

Для преобразования имени в IP-адрес в операционных системах Windows традиционно используются две технологии – NetBIOS и более известная DNS.

NetBIOS (Network Basic Input/Output System) – технология, пришедшая к нам в 1983 году. Она обеспечивает такие возможности как:

• регистрация и проверка сетевых имен;

  
  

• установление и разрыв соединений;

  
  

• связь с гарантированной доставкой информации;

  
  

• связь с негарантированной доставкой информации;

  
  
• поддержка управления и мониторинга драйвера и сетевой карты.

В рамках этого материала нас интересует только первый пункт. При использовании NetBIOS имя ограниченно 16 байтами – 15 символов и спец-символ, обозначающий тип узла. Процедура преобразования имени в адрес реализована широковещательными запросами.

Широковещательным называют такой запрос, который предназначен для получения всеми компьютерами сети. Для этого запрос посылается на специальный IP или MAC-адрес для работы на третьем или втором уровне модели OSI.

Для работы на втором уровне используется MAC-адрес FF:FF:FF:FF:FF:FF, для третьего уровня в IP-сетях адрес, являющимся последним адресом в подсети. Например, в подсети 192.168.0.0/24 этим адресом будет 192.168.0.255

Интересная особенность в том, что можно привязывать имя не к хосту, а к сервису. Например, к имени пользователя для отправки сообщений через net send.

Естественно, постоянно рассылать широковещательные запросы не эффективно, поэтому существует кэш NetBIOS – временная таблица соответствий имен и IP-адреса. Таблица находится в оперативной памяти, по умолчанию количество записей ограничено шестнадцатью, а срок жизни каждой – десять минут. Посмотреть его содержимое можно с помощью команды nbtstat -c, а очистить – nbtstat -R.

Пример работы кэша для разрешения имени узла «хр».

Что происходило при этом с точки зрения сниффера.

В крупных сетях из-за ограничения на количество записей и срока их жизни кэш уже не спасает. Да и большое количество широковещательных запросов запросто может замедлить быстродействие сети. Для того чтобы этого избежать, используется сервер WINS (Windows Internet Name Service). Адрес сервера администратор может прописать сам либо его назначит DHCP сервер. Компьютеры при включении регистрируют NetBIOS имена на сервере, к нему же обращаются и для разрешения имен.

В сетях с *nix серверами можно использовать пакет программ Samba в качестве замены WINS. Для этого достаточно добавить в конфигурационный файл строку «wins support = yes». Подробнее – в документации.

В отсутствие службы WINS можно использовать файл lmhosts, в который система будет «заглядывать» при невозможности разрешить имя другими способами. В современных системах по умолчанию он отсутствует. Есть только файл-пример-документация по адресу %systemroot%\System32\drivers\etc\lmhost.sam. Если lmhosts понадобится, его можно создать рядом с lmhosts.sam.

Сейчас технология NetBIOS не на слуху, но по умолчанию она включена. Стоит иметь это ввиду при диагностике проблем.

DNS (Domain Name System) – распределенная иерархическая система для получения информации о доменах. Пожалуй, самая известная из перечисленных. Механизм работы предельно простой, рассмотрим его на примере определения IP адреса хоста www.google.com:

• если в кэше резолвера адреса нет, система запрашивает указанный в сетевых настройках интерфейса сервер DNS;

  
  

• сервер DNS смотрит запись у себя, и если у него нет информации даже о домене google.com – отправляет запрос на вышестоящие сервера DNS, например, провайдерские. Если вышестоящих серверов нет, запрос отправляется сразу на один из 13 (не считая реплик) корневых серверов, на которых есть информация о тех, кто держит верхнюю зону. В нашем случае – com.

  
  

• после этого наш сервер спрашивает об имени www.google.com сервер, который держит зону com;

  
  
• затем сервер, который держит зону google.com уже выдает ответ.

Наглядная схема прохождения запроса DNS.

Разумеется, DNS не ограничивается просто соответствием «имя – адрес»: здесь поддерживаются разные виды записей, описанные стандартами RFC. Оставлю их список соответствующим статьям.

Сам сервис DNS работает на UDP порту 53, в редких случаях используя TCP.

DNS переключается на TCP с тем же 53 портом для переноса DNS-зоны и для запросов размером более 512 байт. Последнее встречается довольно редко, но на собеседованиях потенциальные работодатели любят задавать вопрос про порт DNS с хитрым прищуром.

Также как и у NetBIOS, у DNS существует кэш, чтобы не обращаться к серверу при каждом запросе, и файл, где можно вручную сопоставить адрес и имя – известный многим %Systemroot%\System32\drivers\etc\hosts.

В отличие от кэша NetBIOS в кэш DNS сразу считывается содержимое файла hosts. Помимо этого, интересное отличие заключается в том, что в кэше DNS хранятся не только соответствия доменов и адресов, но и неудачные попытки разрешения имен. Посмотреть содержимое кэша можно в командной строке с помощью команды ipconfig /displaydns, а очистить – ipconfig /flushdns. За работу кэша отвечает служба dnscache.

На скриншоте видно, что сразу после чистки кэша в него добавляется содержимое файла hosts, и иллюстрировано наличие в кэше неудачных попыток распознавания имени.

При попытке разрешения имени обычно используются сервера DNS, настроенные на сетевом адаптере. Но в ряде случаев, например, при подключении к корпоративному VPN, нужно отправлять запросы разрешения определенных имен на другие DNS. Для этого в системах Windows, начиная с 7\2008 R2, появилась таблица политик разрешения имен (Name Resolution Policy Table, NRPT). Настраивается она через реестр, в разделе HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DnsClient\DnsPolicyConfig или групповыми политиками.

Настройка политики разрешения имен через GPO.

При наличии в одной сети нескольких технологий, где еще и каждая – со своим кэшем, важен порядок их использования.

Операционная система Windows пытается разрешить имена в следующем порядке:

• проверяет, не совпадает ли имя с локальным именем хоста;

  
  

• смотрит в кэш DNS распознавателя;

  
  

• если в кэше соответствие не найдено, идет запрос к серверу DNS;

  
  

• если имя хоста «плоское», например, «servername», система обращается к кэшу NetBIOS. Имена более 16 символов или составные, например «servername.domainname.ru» – NetBIOS не используется;

  
  

• если не получилось разрешить имя на этом этапе – происходит запрос на сервер WINS;

  
  

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

  
  
• последняя попытка – система ищет записи в локальном файле lmhosts.

Для удобства проиллюстрирую алгоритм блок-схемой:

Алгоритм разрешения имен в Windows.

То есть, при запуске команды ping server.domain.com NetBIOS и его широковещательные запросы использоваться не будут, отработает только DNS, а вот с коротким именем процедура пойдет по длинному пути. В этом легко убедиться, запустив простейший скрипт:

@echo off
echo %time%
ping hjfskhfjkshjfkshjkhfdsjk.com
echo %time%
ping xyz
echo %time%
pause

Выполнение второго пинга происходит на несколько секунд дольше, а сниффер покажет широковещательные запросы.

Сниффер показывает запросы DNS для длинного имени и широковещательные запросы NetBIOS для короткого.

Отдельного упоминания заслуживают доменные сети – в них запрос с коротким именем отработает чуть по-другому.

Active Directory тесно интегрирована с DNS и не функционирует без него. Каждому компьютеру домена создается запись в DNS, и компьютер получает полное имя (FQDN — fully qualified domain name) вида name.subdomain.domain.com.

Для того чтоб при работе не нужно было вводить FQDN, система автоматически добавляет часть имени домена к хосту при различных операциях – будь то регистрация в DNS или получение IP адреса по имени. Сначала добавляется имя домена целиком, потом следующая часть до точки.

При попытке запуска команды ping servername система проделает следующее:

При этом к составным именам типа www.google.com суффиксы по умолчанию не добавляются. Это поведение настраивается групповыми политиками.

Настройка добавления суффиксов DNS через групповые политики.

Настраивать DNS суффиксы можно также групповыми политиками или на вкладке DNS дополнительных свойств TCP\IP сетевого адаптера. Просмотреть текущие настройки удобно командой ipconfig /all.

Суффиксы DNS и их порядок в выводе ipconfig /all.

Однако утилита nslookup работает немного по-другому: она добавляет суффиксы в том числе и к длинным именам. Посмотреть, что именно происходит внутри nslookup можно, включив диагностический режим директивой debug или расширенный диагностический режим директивой dc2. Для примера приведу вывод команды для разрешения имени ya.ru:

nslookup -dc2 ya.ru

------------
Got answer:
    HEADER:
        opcode = QUERY, id = 1, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:
        4.4.8.8.in-addr.arpa, type = PTR, class = IN

    ANSWERS:
    ->  4.4.8.8.in-addr.arpa
        name = google-public-dns-b.google.com
        ttl = 86399 (23 hours 59 mins 59 secs)

------------
╤хЁтхЁ:  google-public-dns-b.google.com
Address:  8.8.4.4

------------
Got answer:

    HEADER:
        opcode = QUERY, id = 2, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:
        ya.ru.subdomain.domain.com, type = A, class = IN

    ANSWERS:
    ->  ya.ru.subdomain.domain.com
        internet address = 66.96.162.92
        ttl = 599 (9 mins 59 secs)

------------
Не заслуживающий доверия ответ:

------------
Got answer:

    HEADER:
        opcode = QUERY, id = 3, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 0,  authority records = 1,  additional = 0

    QUESTIONS:
        ya.ru.subdomain.domain.com, type = AAAA, class = IN

    AUTHORITY RECORDS:
    ->  domain.com
        ttl = 19 (19 secs)
        primary name server = ns-2022.awsdns-60.co.uk
        responsible mail addr = awsdns-hostmaster.amazon.com
        serial  = 1
        refresh = 7200 (2 hours)
        retry   = 900 (15 mins)
        expire  = 1209600 (14 days)
        default TTL = 86400 (1 day)

------------
╚ь :     ya.ru.subdomain.domain.com
Address:  66.96.162.92

Из-за суффиксов утилита nslookup выдала совсем не тот результат, который выдаст например пинг:

ping ya.ru -n 1
Обмен пакетами с ya.ru [87.250.250.242] с 32 байтами данных:
Ответ от 87.250.250.242: число байт=32 время=170мс TTL=52

Это поведение иногда приводит в замешательство начинающих системных администраторов.

Лично сталкивался с такой проблемой: в домене nslookup выдавал всегда один и тот же адрес в ответ на любой запрос. Как оказалось, при создании домена кто-то выбрал имя domain.com.ru, не принадлежащее организации в «большом интернете». Nslookup добавляла ко всем запросам имя домена, затем родительский суффикс – com.ru. Домен com.ru в интернете имеет wildcard запись, то есть любой запрос вида XXX.com.ru будет успешно разрешен. Поэтому nslookup и выдавал на все вопросы один ответ. Чтобы избежать подобных проблем, не рекомендуется использовать для именования не принадлежащие вам домены.

При диагностике стоит помнить, что утилита nslookup работает напрямую с сервером DNS, в отличие от обычного распознавателя имен. Если вывести компьютер из домена и расположить его в другой подсети, nslookup будет показывать, что всё в порядке, но без настройки суффиксов DNS система не сможет обращаться к серверам по коротким именам.

Отсюда частые вопросы – почему ping не работает, а nslookup работает.

В плане поиска и устранения ошибок разрешения имен могу порекомендовать не бояться использовать инструмент для анализа трафика – сниффер. С ним весь трафик как на ладони, и если добавляются лишние суффиксы, то это отразится в запросах DNS. Если запросов DNS и NetBIOS нет, некорректный ответ берется из кэша.

Если же нет возможности запустить сниффер, рекомендую сравнить вывод ping и nslookup, очистить кэши, проверить работу с другим сервером DNS.

Кстати, если вспомните любопытные DNS-курьезы из собственной практики – поделитесь в комментариях.

habr.com

WINS и расширение имен NetBIOS. Методы регистрации имен

WINS и расширение имен NetBIOS.

WindowsInternetNamingService (WINS, служба имен Интернета для Windows) представляет собой NetBIOS Name Server (NBNS, сервер имен NetBIOS), определенный стандартами, опубликованными IETF в документах RFC 1001 и RFC 1002. Эти стандарты описывают использование сетей типа TCP/IP поверх NetBIOS, называемых для краткости NetBT.

Имена NetBIOS

Сети Windows используют имена компьютеров (имена NetBIOS) для уникальной идентификации каждой машины в сети. При просмотре Сетевого окружения в Windows-системе имена доменов, рабочих групп или компьютеров представляют собой фактически именно имена NetBIOS. Пространство имен NetBIOS является плоским (не иерархическим), а это означает, что каждое имя может использоваться в сети только один раз. Пространство: имен NetBIOS также допускает только имена длиной до 16 символов, по­следний из которых Windows-системы применяют для формирования иден­тификатора ресурса, описывающего функцию системы, практически оставляя только 15 символов на имя, назначаемое во время установки.

Например, когда система использует диск или каталог совместно с другим компьютером сети, его имя NetBIOS состоит из имени компьютера, назна­ченного в процессе установки операционной системы, плюс необходимое количество пробелов для доведения длины имени до 15 символов (если требуется), за которыми следует идентификатор ресурса.  В данном случае, идентификатор ресурса имеет шестнадцатеричное значение 20, свидетельствуя о том, что система функционирует в качестве файлового сервера.

Когда Windows-системы общаются между собой с использованием протоко­ла NetBEUI на Сетевом и Транспортном уровнях, они используют именно имена NetBIOS для определения аппаратного адреса, по которому следует направлять пакеты. Однако для обмена сообщениями по протоколу TCP/IP системе необходимо знать IP-адрес предполагаемого места назначения.

Процесс превращения имени в соответствующий адрес известен как разре­шение имени (nameresolution).

Имена NetBIOS должны быть уникальными в пределах сети, чтобы трафик каждый раз отправлялся нужной машине. Чтобы убедиться, что никакие два компьютера сети не имеют одинаковых имен NetBIOS, системы на базе Windows используют механизм регистрации имен для выявления по­вторяющихся имен NetBIOS при каждом подключении к сети. Механизм регистрации имен (nameregistrationmechanism)— это способ, с помощью которого система составляет поисковую таблицу, используемую ей для разрешения имен.

Системы на базе операционных систем Windows могут использовать три различных механизма как при регистрации имен, так и в процессе их раз­решения. Эти механизмы перечислены ниже.

□  LMHOSTS. Создаваемый вручную текстовый файл, содержащий имена NetBIOS и соответствующие им IP-адреса.

□  Широковещательные сообщения. Процесс, в ходе которого системы рас­сылают широковещательные сообщения всему сетевому сегменту с расчетом на ответы от других систем с информацией об именах NetBIOS.

□  WINS. Сервис, работающий на сервере Windows NT, обслуживающий
динамическую базу данных об именах NetBIOS и IP-адресах.

Методы регистрации имен

Регистрация имен LMHOSTS

LMHOSTSпредставляет собой обычный текстовый файл, содержащий имена NetBIOS систем сети и их IP-адреса, точно так же, как файл HOSTS

vunivere.ru

Иллюстрированный самоучитель по Microsoft Windows 2003 › Основные концепции Active Directory › Глобально уникальные идентификаторы. Имена NetBIOS. Унифицированный указатель ресурсов LDAP. Канонические имена. [страница — 613] | Самоучители по операционным системам

Глобально уникальные идентификаторы. Имена NetBIOS. Унифицированный указатель ресурсов LDAP. Канонические имена.

Отличительное имя однозначно определяет объект в каталоге. Однако перемещение объекта или его переименование (равно как и переименование любого из контейнеров, внутри которых данный объект содержится) приводит к изменению его отличительного имени. Это может привести к неправильной работе приложений, использующих отличительные имена для уникальной идентификации объектов. Задача уникальной и однозначной идентификации объекта может быть решена посредством введения специального атрибута, значение которого не менялось бы при переименовании или перемещении объекта. В службе каталога Active Directory обеспечение уникальности объектов достигается посредством глобально уникального идентификатора (Global Unique Identifier, GLJID), представляющего собой 128-разрядное число.

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

Имена NetBIOS

До появления службы каталога Active Directory в качестве основного способа именования объектов в операционных системах Windows применялись имена NetBIOS. В частности этот способ именования используется в операционных системах Windows 95/98/NT. Имена пользователей, компьютеров и доменов в среде Windows NT представляют собой имена NetBIOS. Архитектура этих операционных систем и, в частности, сетевых компонентов строится на основе имен NetBIOS. Большинство приложений, разработанных для этого семейства операционных систем, предполагают использование только этой схемы именования. Данная схема именования была реализована в Active Directory с целью сохранения обратной совместимости со старыми операционными системами и разработанными для них приложениями.

Имя NetBIOS должно быть уникально в пределах домена и его длина не должна превышать 15 символов.

Унифицированный указатель ресурсов LDAP

Протокол LDAP является одним из стандартных методов доступа к каталогу Active Directory. Любое LDAP-совместимое приложение может обратиться к объектам каталога посредством запроса, записанного в формате унифицированного указателя ресурсов LDAP (LDAP Uniform Resource Locator, LDAP URL). Унифицированный указатель ресурсов LDAP начинается с ключевого слова LDAP, затем следует имя сервера, содержащего копию каталога, и отличительное имя ресурса. Ниже приводится пример записи унифицированного указателя ресурсов LDAP:

//root .khsu .ru/cn=tasha, cn=user, cu=r.d, clc=khsu, dc=ru

Канонические имена

Вместо отличительного имени для определения положения объекта в дереве каталога можно использовать так называемое каноническое имя (canonical name). Принцип построения канонического имени аналогичен принципу формирования отличительных имен, за исключением того, что при записи канонического имени опускаются спецификаторы, обозначающие тип объекта или контейнера. Для указания домена в каноническом имени используется соглашение о доменных именах. Ниже приводится пример канонического имени:

khsu.ru/cit/nd/tasha

samoychiteli.ru