Основы работы в сети: Часть 10 – Выдающиеся названия

Published on Февраль 18, 2009 by   ·   Комментариев нет

Если вы хотите ознакомиться с остальными частями этой статьи, пожалуйста, прочитайте:

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

Для начала

Для начала я хочу напомнить вам, выдающиеся названия (distinguished name) не являются уникальными в Active Directory. Компания Microsoft сформировала Active Directory таким образом, чтобы она обладала преимуществами над промышленными стандартами, которые используются другими компаниями, такими как Novell и IBM. Благодаря изучению работы выдающихся названий вы сможете не только лучше подготовиться к управлению окружением Active Directory, вы сможете также без проблем разобраться с сетевыми операционными системами, которые выпускаются другими компаниями.

Основные правила наименования (Basic Naming Rules)

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

CN=User1, CN=Users, DC=Contoso, DC=com

В этом примере выдающееся название состоит из четырех различных пар атрибут/значение, каждая пара отделена от другой пары запятой. Первая пара атрибут/значение — CN=USER1. В этой паре атрибут/значение CN (что является сокращением от Common Name или общее название) – это атрибут, а User1 — значение. Атрибуты и значения всегда отделяются друг от друга символом равенства, а пары атрибут/значение отделяются друг от друга запятыми.

Относительные выдающиеся имена

Если вы посмотрите на выдающееся название, такое как CN=User1, CN=Users, DC=Contoso, DC=com, становится очевидным то факт, что выдающиеся названия могут быть очень длинными. Если вы внимательней посмотрите на это выдающееся название, то заметите, что он иерархическое. В этом конкретном случае, DC=com представляет самый высокий уровень иерархии. DC=Contoso представляет второй уровень иерархии. Вы можете с уверенностью сказать, что COM и Contoso оба являются доменами, благодаря атрибуту DC. Иерархия доменов отражает иерархию доменов, которая используется серверами DNS (я рассказывал о иерархии DNS ранее в этой статье).

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

Для того, чтобы лучше понять, о чем я говорю, давайте посмотрим на другой пример выдающегося названия: CN=User1, CN=Users, DC=Contoso, DC=com. Это выдающееся название просто ссылается на учетную запись пользователя (user account, а если говорить более точно на пользовательский объект) под названием User1. Вся остальная информация в названии просто говорит нам о положении объекта внутри иерархии директорий (directory hierarchy).

Если вы попытаетесь рассказать другому человеку об этом объекте, то вы, вероятно, просто сошлетесь на него, как на User1. Иногда LDAP делает нечто подобное. Это возможно благодаря тому, что не обязательно указывать информацию о расположении объекта внутри иерархии, если это расположение уже известно.

Например, если мы выполняем некоторую операцию над объектами пользователя, расположенными в контейнере Users (пользователи) в домене под названием Contoso.com, то зачем тогда обязательно указывать, что каждый отдельный объект расположен в домене Contoso.com в контейнере Users?

В подобных ситуациях выдающееся название часто заменяют относительным отображаемым названием (Relative Display Name или сокращенно RDN). В случае для названия CN=User1, CN=Users, DC=Contoso, DC=com, относительное название RDN будет CN=User1. RDN всегда состоит за самого важного идентификатора. Это будет самая левая пара атрибут/значение в выдающемся названии. Остальная часть выдающегося названия известно, как родительское выдающееся название. В этом конкретном случае, родительское выдающееся название (parent distinguished name) будет CN=Users, DC=Contoso, DC=com.

Перед тем, как я продолжу, я хочу упомянуть, что компания Microsoft имеет тенденцию к использованию немного другого формата выдающихся названий, чем другие производители операционных систем. Как вы уже видели, выдающееся название компании Microsoft основывается на контейнерах и доменах. Нет ничего плохого в этом формате, т.к. он удовлетворяет требованиям стандарта RFC 2253, который задает правила для выдающихся названий.

Некоторые другие сетевые операционные системы используют в основе своих иерархий выдающихся названий не контейнеры и домена, а компании и страны. В выдающихся названиях такого типа, атрибут O описывает название организации (компании), а буква C используется для указания названия страны. Используя такое соглашения по наименованию, выдающееся название CN=User1, CN=Users, DC=Contoso, DC=com будет выглядеть что-то вроде этого:

CN=User1, O=Contoso, C=US

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

Специальные символы в выдающихся названиях

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

Однако, я хочу рассказать о символе обратный слеш (back slash). Обратный слеш позволяет вам сообщить предложению LDAP игнорировать символ, стоящий следом. Это позволяет вам хранить запрещенные символы в вашей директории.

Чтобы увидеть это в действии, давайте рассмотрим, что полные имена часто выражаются в виде имени и фамилии через запятую. Но несмотря на это, LDAP не позволит вам использовать такое предложение CN=Smith, John, т.к. запятая используется в LDAP для разделения пар атрибут/значение LDAP. Если вы хотите хранить значение Smith, John в директории, то вы можете это сделать с помощью обратного слеша, как показано на рисунке:

CN=Smith\, John

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

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

Заключение

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

www.windowsnetworking.com


Смотрите также:

Tags: , ,

Readers Comments (Комментариев нет)




Да человек я, человек! =)




Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]