Расширение схемы active directory. Schema master — Хозяин схемы Active Directory. Получение и использование идентификаторов

Post Office Protocol (POP) - протокол доставки почты пользователю из почтового ящика почтового сервера РОР. Многие концепции, принципы и понятия протокола POP выглядят и функционируют подобно SMTP. Команды POP практически идентичны командам SMTP, отличаясь в некоторых деталях. На рисунке изображена модель клиент-сервер по протоколу POP. Сервер POP находится между агентом пользователя и почтовыми ящиками.

В настоящее время существуют две версии протокола POP - РОР2 и РОРЗ, обладающими примерно одинаковыми возможностями, однако несовместимыми друг с другом. Дело в том, что у РОР2 и РОРЗ разные номера портов протокола. Между ними отсутствует связь, аналогичная связи между SMTP и ESMTP. Протокол РОРЗ не является расширением или модификацией РОР2 - это совершенно другой протокол. РОР2 определен в документе RFC 937 (Post Office Protocol-Version 2, Butler, et al, 1985), a РОРЗ - в RFC 1225 (Post Office Protocol-Version 3, Rose, 1991). Далее кратко рассмотрим POP вообще и более подробно - РОРЗ. PОРЗ разработан с учетом специфики доставки почты на персональные компьютеры и имеет соответствующие операции для этого.

Назначение протокола РОРЗ

Ранее почтовые сообщения большинства сетей доставлялись непосредственно от одного компьютера к другому. И если пользователь часто менял рабочие компьютеры или один компьютер принадлежал нескольким пользователям, существовали определенные проблемы. В наши дни общепринята доставка сообщения не на компьютеры пользователя, а в специальные почтовые ящики почтового сервера организации, который круглосуточно работает (включен).

Описание протокола РОРЗ

Конструкция протокола РОРЗ обеспечивает возможность пользователю обратиться к своему почтовому серверу и изъять накопившуюся для него почту. Пользователь может получить доступ к РОР-серверу из любой точки доступа к Интернет. При этом он должен запустить специальный почтовый агент (UA), работающий по протоколу РОРЗ, и настроить его для работы со своим почтовым сервером. Итак, во главе модели POP находится отдельный персональный компьютер, работающий исключительно в качестве клиента почтовой системы (сервера). Подчеркнем также, что сообщения доставляются клиенту по протоколу POP, а посылаются по-прежнему при помощи SMTP. То есть на компьютере пользователя существуют два отдельных агента-интерфейса к почтовой системе - доставки (POP) и отправки (SMTP). Разработчики протокола РОРЗ называет такую ситуацию "раздельные агенты" (split UA). Концепция раздельных агентов кратко обсуждается в спецификации РОРЗ.

В протоколе РОРЗ оговорены три стадии процесса получения почты: авторизация, транзакция и обновление. После того как сервер и клиент РОРЗ установили соединение, начинается стадия авторизации. На стадии авторизации клиент идентифицирует себя для сервера. Если авторизация прошла успешно, сервер открывает почтовый ящик клиента и начинается стадия транзакции. В ней клиент либо запрашивает у сервера информацию (например, список почтовых сообщений), либо просит его совершить определенное действие (например, выдать почтовое сообщение). Наконец, на стадии обновления сеанс связи заканчивается. В табл.7 перечислены команды протокола РОРЗ, обязательные для работающей в Интернет реализации минимальной конфигурации.

Таблица 5. Команды протокола POP версии 3 (для минимальной конфигурации)

Команда
Описание

USER Идентифицирует пользователя с указанным именем

PASS
Указывает пароль для пары клиент-сервер
QUIT
Закрывает TCP-соединение

STAT
Сервер возвращает количество сообщений в почтовом ящике плюс размер почтового ящика

LIST
Сервер возвращает идентификаторы сообщений вместе с размерами сообщений (параметром команды может быть идентификатор сообщения)

RETR
Извлекает сообщение из почтового ящика (требуется указывать аргумент-идентификатор сообщения)

DELE
Отмечает сообщение для удаления (требуется указывать аргумент - идентификатор сообщения)

NOOP
Сервер возвращает положительный ответ, но не совершает никаких действий

LAST
Сервер возвращает наибольший номер сообщения из тех, к которым ранее уже обращались

RSET
Отменяет удаление сообщения, отмеченного ранее командой DELE

В протоколе РОРЗ определено несколько команд, но на них дается только два ответа: +ОК (позитивный, аналогичен сообщению-подтверждению АСK) и -ERR (негативный, аналогичен сообщению "не подтверждено" NAK). Оба ответа подтверждают, что обращение к серверу произошло и что он вообще отвечает на команды. Как правило, за каждым ответом следует его содержательное словесное описание. В RFC 1225 есть образцы нескольких типичных сеансов РОРЗ. Сейчас мы рассмотрим несколько из них, что даст возможность уловить последовательность команд в обмене между сервером и клиентом.

После того как программа установила TCP-соединение с портом протокола РОРЗ (официальный номер 110), необходимо послать команду USER с именем пользователя в качестве параметра. Если ответ сервера будет +ОК, нужно послать команду PASS с паролем этого пользователя:

CLIENT: USER kcope
ERVER: +ОК
CLIENT: PASS secret
SERVER: +ОК kcope"s maildrop has 2 messages (320 octets)
(В почтовом ящике kcope есть 2 сообщения (320 байтов) ...)

Транзакции РОРЗ

Команда STAT возвращает количество сообщений и количество байтов в сообщениях:

CLIENT: STAT
SERVER: +ОК 2 320

Команда LIST (без параметра) возвращает список сообщений в почтовом ящике и их размеры:

CLIENT: LIST
SERVER: +ОК 2 messages (320 octets)
SERVER: 1 120
SERVER: 2 200
SERVER: . ...

Команда LIST с параметром возвращает информацию о заданном сообщении:

CLIENT: LIST 2
SERVER: +ОК 2 200 ...
CLIENT: LIST 3
SERVER: -ERR no such message, only 2 messages in maildrop

Команда TOP возвращает заголовок, пустую строку и первые десять строк тела сообщения:

CLIENT: TOP 10
SERVER: +ОК
SERVER:
(сервер POP высылает заголовки сообщений, пустую строку и первые десять строк тела сообщения)
SERVER: . ...
CLIENT: TOP 100
SERVER: -ERR no such message
Команда NOOP не возвращает никакой полезной информации, за исключением позитивного ответа сервера. Однако позитивный ответ означает, что сервер находится в соединении с клиентом и ждет запросов:

CLIENT: NOOP
SERVER: +ОК

Следующие примеры показывают, как сервер POP3 выполняет действия. Например, команда RETR извлекает сообщение с указанным номером и помещает его в буфер местного UA:

CLIENT: RETR 1
SERVER: +OK 120 octets
SERVER:
(РОРЗ-сервер высылает сообщение целиком)
SERVER: . . . . . .

Команда DELE отмечает сообщение, которое нужно удалить:

CLIENT: DELE 1
SERVER: +OK message 1 deleted ...
(сообщение 1 удалено)
CLIENT: DELE 2
SERVER: -ERR message 2 already deleted
сообщение 2 уже удалено)
Команда RSET снимает метки удаления со всех отмеченных ранее сообщений:

CLIENT: RSET
SERVER: +OK maildrop has 2 messages (320 octets)
(в почтовом ящике 2 сообщения (320 байтов))

Как и следовало ожидать, команда QUIT закрывает соединение с сервером:

CLIENT: QUIT
SERVER: +OK dewey POP3 server signing off
CLIENT: QUIT
SERVER: +OK dewey POP3 server signing off (maildrop empty)
CLIENT: QUIT
SERVER: +OK dewey POP3 server signing off (2 messages left)

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

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

Протокол POP3 (Post Office Protocol — version 3, третья версия протокола почтового отделения) является наиболее распространенным протоколом получения электронной почты с почтового сервера. Для этих целей также используется IMAP. В IMAP предусмотрено больше возможностей, чем в POP3, но зато POP3 намного проще. Для сравнения — POP3 описан в RFC1939 , занимающем всего 20 страниц, а RFC3501 , описывающий IMAP, состоит из целых 108 страниц. В этом посте речь пойдет о протоколе POP3.

Как всегда, начнем с запуска утилиты telnet и живого примера:

telnet mail.nic.ru 110
Trying 194.85.88.226...
Connected to mail.nic.ru.
Escape character is "^]".
+OK POP3 Server ready <[email protected]>
APOP [email protected]

Здесь мы соединяемся с pop3-сервером, работающим обычно на 110-м порту и проходим аутентификацию (не путать с авторизацией). Если в приветствии сервера присутствует похожая на e-mail строка в треугольных скобках (timestamp), значит сервер поддерживает команду APOP, позволяющую передавать пароль в зашифрованном (точнее — хэшированном) виде. В этом примере хэш вычислен следующим образом:

echo -n "<[email protected]>qwerty" | md5

То есть происходит конкатенация timestamp с паролем, а от результата вычисляется MD5. Преимущество этого метода в том, что даже при использовании незащищенного соединения злоумышленник не сможет перехватить пароль. Он увидит только хэш, который будет совершенно бесполезен, поскольку для каждого нового соединения сервер использует уникальный timestamp. Чтобы узнать пароль необходимо взломать хэш c помощью перебора, что практически бесполезно для достаточно сильных паролей, которые к тому же меняются хотя бы раз в пол года.

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

Потому большинством почтовых сервером (я лично проверил pop3.mail.ru:110 и pop.gmail.com:995/ssl/) команда APOP не поддерживается и проходить аутентификацию приходится с помощью стандартной пары логин:пароль.

USER [email protected]
+OK please send the PASS
PASS qwerty
+OK 5 messages (868540 bytes) (proxing)

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

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

HELP
+OK Valid commands: QUIT, NOOP, STAT, LIST, UIDL, DELE, RSET, RETR, ...
NOOP
+OK cool
LAST
+OK 5 is last seen

Команда HELP позволяет получить список поддерживаемых сервером команд. В этом примере команды UIDL, XTND и XMIT являются расширениями протокола POP3 и сервер не обязан их поддерживать. Команда UIDL позволяет получить уникальные идентификаторы сообщений (см описание команды LIST ниже):

UIDL
+OK 6 messages
1 3876
2 3877
3 3878
4 3879
5 3880
6 3881
.
UIDL 2
+OK 2 3877

Для чего нужны XTND и XMIT не знаю и разбираться лениво:) Желающие могут поискать ответ в Google.

Команда NOOP означает «ничего не делать». На ум приходит только одно ее применение — выполнять команду раз в 15 секунд, чтобы дать понять серверу, что клиент не повис.

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

Теперь перейдем к более полезным командам:

STAT
+OK 5 868540
LIST
+OK 5 messages
1 275368
2 11196
3 153304
4 275367
5 153305
.
LIST 2
+OK 2 11196
TOP 2 0
+OK message follows
Return-Path:
X-Blacklisted-By: cbl.abuseat.org
From: "=?koi8-r?B?48XO1NIg7cnH0sHDyck=?="
To: [email protected]
Subject: =?koi8-r?B?SGVsbG8=?=
Date: Thu, 17 Dec 2009 18:18:12 +0300
MIME-Version: 1.0
Content-Type: multipart/related;
type="multipart/alternative";
boundary="----=_NextPart_000_003C_01CA7F45.01CA7F45"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.3959
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325
Received-SPF: none
X-Spam-Rating: 83.69

.
DELE 2
+OK marked deleted

Команда STAT позволяет определить количество сообщений в почтовом ящике (5) и их суммарный размер (868 540 байт).

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

Команда TOP позволяет получить заголовок сообщения (первый аргумент команды — id сообщения) и первые N строк тела сообщения (второй аргумент команды). В этом примере я указал N=0, потому что хотел посмотреть только заголовок сообщения. С тем же успехом можно было просто указать только один аргумент. Заканчивается ответ сервера также точкой. Команда TOP часто используется почтовыми клиентами для того, чтобы определить отправителя и тему сообщения без необходимости скачивать письмо целиком. Это экономит время и трафик пользователя.

Очевидно, тут мы имеем дело со спамом (см e-mail отправителя, X-Blacklisted-By и X-Spam-Rating), так что можно смело удалить сообщение, даже не скачивая его целиком. Для этого используется команда DELE. Сообщение будет помечено на удаление, но стерто только после того, как мы закроем соединение.

Отменить удаление всех помеченных нами сообщений можно командой RSET . Получить сообщение целиком можно с помощью команды RETR . Как и в случае с TOP, конец сообщения обозначается точкой. Не буду приводить примеры этих команд, так как тут все довольно очевидно.

По завершению работы можно попрощаться с сервером и закрыть соединение:

QUIT
+OK CommuniGate Pro POP3 Server connection closed

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

Post Office Protocol (POP) - протокол доставки почты пользователю из почтового ящика почтового сервера РОР . Многие концепции, принципы и понятия протокола POP выглядят и функционируют подобно SMTP. Команды POP практически идентичны командам SMTP, отличаясь в некоторых деталях. На рис.7 изображена модель клиент-сервер по протоколу POP. Сервер POP находится между агентом пользователя и почтовыми ящиками.

В настоящее время существуют две версии протокола POP - РОР2 и РОРЗ, обладающими примерно одинаковыми возможностями, однако несовместимыми друг с другом. Дело в том, что у РОР2 и РОРЗ разные номера портов протокола. Между ними отсутствует связь, аналогичная связи между SMTP и ESMTP. Протокол РОРЗ не является расширением или модификацией РОР2 - это совершенно другой протокол. РОР2 определен в документе RFC 937 (Post Office Protocol-Version 2, Butler, et al, 1985), a РОРЗ - в RFC 1225 (Post Office Protocol-Version 3, Rose, 1991). Далее кратко рассмотрим POP вообще и более подробно - РОРЗ. PОРЗ разработан с учетом специфики доставки почты на персональные компьютеры и имеет соответствующие операции для этого.

Назначение протокола РОРЗ

Ранее почтовые сообщения большинства сетей доставлялись непосредственно от одного компьютера к другому. И если пользователь часто менял рабочие компьютеры или один компьютер принадлежал нескольким пользователям, существовали определенные проблемы. В наши дни общепринята доставка сообщения не на компьютеры пользователя, а в специальные почтовые ящики почтового сервера организации, который круглосуточно работает (включен).

Описание протокола РОРЗ

Конструкция протокола РОРЗ обеспечивает возможность пользователю обратиться к своему почтовому серверу и изъять накопившуюся для него почту. Пользователь может получить доступ к РОР-серверу из любой точки доступа к Интернет. При этом он должен запустить специальный почтовый агент (UA), работающий по протоколу РОРЗ, и настроить его для работы со своим почтовым сервером. Итак, во главе модели POP находится отдельный персональный компьютер, работающий исключительно в качестве клиента почтовой системы (сервера). Подчеркнем также, что сообщения доставляются клиенту по протоколу POP, а посылаются по-прежнему при помощи SMTP. То есть на компьютере пользователя существуют два отдельных агента-интерфейса к почтовой системе - доставки (POP) и отправки (SMTP). Разработчики протокола РОРЗ называет такую ситуацию "раздельные агенты" (split UA). Концепция раздельных агентов кратко обсуждается в спецификации РОРЗ.

В протоколе РОРЗ оговорены три стадии процесса получения почты: авторизация, транзакция и обновление. После того как сервер и клиент РОРЗ установили соединение, начинается стадия авторизации. На стадии авторизации клиент идентифицирует себя для сервера. Если авторизация прошла успешно, сервер открывает почтовый ящик клиента и начинается стадия транзакции. В ней клиент либо запрашивает у сервера информацию (например, список почтовых сообщений), либо просит его совершить определенное действие (например, выдать почтовое сообщение). Наконец, на стадии обновления сеанс связи заканчивается. В табл.7 перечислены команды протокола РОРЗ, обязательные для работающей в Интернет реализации минимальной конфигурации.

Таблица 5. Команды протокола POP версии 3 (для минимальной конфигурации)

Описание

USER

Идентифицирует пользователя с указанным именем

Указывает пароль для пары клиент-сервер

Закрывает TCP-соединение

Сервер возвращает количество сообщений в почтовом ящике плюс размер почтового ящика

Сервер возвращает идентификаторы сообщений вместе с размерами сообщений (параметром команды может быть идентификатор сообщения)

Извлекает сообщение из почтового ящика (требуется указывать аргумент-идентификатор сообщения)

Отмечает сообщение для удаления (требуется указывать аргумент - идентификатор сообщения)

Сервер возвращает положительный ответ, но не совершает никаких действий

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

Отменяет удаление сообщения, отмеченного ранее командой DELE

В протоколе РОРЗ определено несколько команд, но на них дается только два ответа: +ОК (позитивный, аналогичен сообщению-подтверждению АСK) и -ERR (негативный, аналогичен сообщению "не подтверждено" NAK). Оба ответа подтверждают, что обращение к серверу произошло и что он вообще отвечает на команды. Как правило, за каждым ответом следует его содержательное словесное описание. В RFC 1225 есть образцы нескольких типичных сеансов РОРЗ. Сейчас мы рассмотрим несколько из них, что даст возможность уловить последовательность команд в обмене между сервером и клиентом.

Авторизация пользователя

После того как программа установила TCP-соединение с портом протокола РОРЗ (официальный номер 110), необходимо послать команду USER с именем пользователя в качестве параметра. Если ответ сервера будет +ОК, нужно послать команду PASS с паролем этого пользователя:

CLIENT: USER kcope ERVER: +ОК CLIENT: PASS secret SERVER: +ОК kcope"s maildrop has 2 messages (320 octets) (В почтовом ящике kcope есть 2 сообщения (320 байтов) ...)

Транзакции РОРЗ

Команда STAT возвращает количество сообщений и количество байтов в сообщениях:

CLIENT: STAT
SERVER: +ОК 2 320

Команда LIST (без параметра) возвращает список сообщений в почтовом ящике и их размеры:

CLIENT: LIST SERVER: +ОК 2 messages (320 octets) SERVER: 1 120 SERVER: 2 200 SERVER: . ...

Команда LIST с параметром возвращает информацию о заданном сообщении:

CLIENT: LIST 2 SERVER: +ОК 2 200 ... CLIENT: LIST 3 SERVER: -ERR no such message, only 2 messages in maildrop

Команда TOP возвращает заголовок, пустую строку и первые десять строк тела сообщения:

CLIENT: TOP 10 SERVER: +ОК SERVER: (сервер POP высылает заголовки сообщений, пустую строку и первые десять строк тела сообщения) SERVER: . ... CLIENT: TOP 100 SERVER: -ERR no such message

Команда NOOP не возвращает никакой полезной информации, за исключением позитивного ответа сервера. Однако позитивный ответ означает, что сервер находится в соединении с клиентом и ждет запросов:

CLIENT: NOOP
SERVER: +ОК

Следующие примеры показывают, как сервер POP3 выполняет действия. Например, команда RETR извлекает сообщение с указанным номером и помещает его в буфер местного UA:

CLIENT: RETR 1 SERVER: +OK 120 octets SERVER: (РОРЗ-сервер высылает сообщение целиком) SERVER: . . . . . .

Команда DELE отмечает сообщение, которое нужно удалить:

SERVER: +OK message 1 deleted ... (сообщение 1 удалено) CLIENT: DELE 2 SERVER: -ERR message 2 already deleted сообщение 2 уже удалено)

Команда RSET снимает метки удаления со всех отмеченных ранее сообщений:

CLIENT: RSET
SERVER: +OK maildrop has 2 messages (320 octets)
(в почтовом ящике 2 сообщения (320 байтов))

Как и следовало ожидать, команда QUIT закрывает соединение с сервером:

CLIENT: QUIT SERVER: +OK dewey POP3 server signing off CLIENT: QUIT SERVER: +OK dewey POP3 server signing off (maildrop empty) CLIENT: QUIT SERVER: +OK dewey POP3 server signing off (2 messages left)

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

FSMO-роль хозяин схемы (Schema master) является одной из двух ролей, функционирующих на уровне леса Active Directory. То есть во всем лесе AD необходимо иметь лишь одного хозяина схемы.

Основная статья по Active Directory — . Читайте также другие статьи по ролям хозяев операций — .

Если вам интересна тематика Windows Server, рекомендую обратиться к рубрике на моем блоге.

Schema master — Хозяин схемы Active Directory

А вы знали, что при повреждении схемы AD придется восстанавливать все КД во всем лесу? А ведь это действительно так, вот почему будьте очень аккуратны при внесении изменений в схему. А пока немного теории.

Теория

Поскольку хозяин схемы — роль уровня леса, то в каждом конкретном лесе AD она существует всегда в единственном экземпляре . Другими словами существует только один контроллер домена, который имеет право вносить изменения/обновления в схему, тем не менее реплика схемы присутствует на каждом контроллере домена и при необходимости роль может быть захвачена принудительно любым DC, но об этом позже. На практике изменения схемы происходят крайне редко, например при установке сервера Exchange или других приложений, которые хранят некоторые свои данные (например объекты конфигурации) в AD.

Все-таки что такое схема AD ? Это прежде всего набор объектов и их атрибутов, которые используются для хранения данных. Мало кому это определение что-то объясняет, попробую рассказать более детально на примере. Что такое объект? Например объектами являются учетные записи пользователей или компьютеров. В данном случае в схеме AD находится класс user , который определяет все атрибуты объекта учетной записи пользователя:

Каждая учетная запись пользователя в домене будет иметь все эти атрибуты. Но значения атрибутов могут быть и не заданы. Можно проверить какие атрибуты и их значения имеет моя недавно созданная учетная запись администратора домена. Чтобы это сделать, необходимо зайти в консоль adsiedit.msc и открыть контекст именования по умолчанию. В иерархии находим объект пользователя и открываем его свойства:

Вы можете увидеть, что объект имеет все атрибуты, которые определены в классе user . Если вы сами решили убедиться в сказанном мной и информация у вас различается, то обратите внимание на кнопку Фильтр , возможно у вас показываются не все атрибуты. Например можно сделать так, чтобы отображались атрибуты только имеющие значения. Администрировать объекты через adsiedit.msc не лучшая затея, делайте это через соответствующие оснастки.

Для интереса можно посмотреть атрибуты объекта сервера Exchange 2013, ведь Exchange вносит множество новых классов в схему:

В большинстве случаев вопросы касательно мастера схемы обходят стороной и достаточно лишь знать, что эта роль отвечает за внесение изменений в схему AD. Тем не менее схема изначально создавалась таким образом, чтобы в неё мог вносить изменения кто угодно. То есть сторонние компании могут разрабатывать свои приложения таким образом, чтобы они хранили свои данные в AD. Для этого на официальных источниках есть множество объемных гайдов, некоторые из них доступны и на русском языке.

Лучшие практики

Схема AD имеет принципиально важное значение для работоспособности Active Directory, а потому нуждается в соответствующем администрировании, хоть и о ней в большинстве случаев просто забывают. Ниже сформулированы лучшие практики администрирования схемы.

1) Перед изменением схемы всегда делайте резервное копирование . Перед процессом изменения схемы вы можете отключать все контроллеры домена, разумеется кроме одного, который является хозяином этой роли. После этого делаете резервную копию контроллера домена, выполняете все необходимы изменения и если все прошло удачно, то просто включаете заглушенные ранее DC. Если же что-то пошло не так, просто поднимаете единственный работающий на это время контроллер из резервной копии, включаете остальные и далее исследуете проблему;

На уровне леса роли хозяина схемы и хозяина именования доменов необходимо расположить на одном контроллере домена (они редко используются и должны жестко контролироваться). Кроме того, контроллер, которому присвоена роль хозяина именования доменов, должен одновременно являться сервером глобального каталога. В противном случае некоторые операции, использующие хозяин именования доменов (например создание внучатых доменов), могут завершаться неудачно.

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

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

4) Без крайней на то необходимости не выполняйте изменения схемы вручную . Если это все же нужно сделать в любом случае, см. пункт 1.

От теории плавно переходим к практике.

Администрирование схемы

Прежде всего стоит сказать, что для управления схемой необходимо иметь как минимум права Администратора Схемы (Schema Admin) . Все остальные авторизованные пользователи имеют права только на чтение, хотя в принципе разрешения можно и изменить. Большинство задач администрирования выполняются в оснастке для управления схемой Active Directory, которая недоступная по умолчанию и чтобы её активировать, необходимо зарегистрировать библиотеку schmmgmt.dll . Для этого запускаем командную строку с правами администратора и выполняем:

Visual Basic

regsvr32 schmmgmt.dll

regsvr32 schmmgmt . dll

Получаем оповещение:

После этого в консоли MMC вы сможете найти оснастку Схема Active Directory . Выполнять команду необходимо на каждом контроллере домена, на котором планируется заниматься администрированием схемы.

Допустим у вас два контроллера домена и вы хотите перенести роль хозяина схемы с DC01 на DC02:

  1. Открываем оснастку на DC01, правой кнопкой нажимаем на Схема Active Directory и выбираем Сменить контроллер домена Active Directory;
  2. Далее выбираем контроллер домена, на который мы хотим перенести роль (у меня это DC02, по умолчанию всегда выбирается сервер-владелец роли). Подтверждаем предупреждение;
  3. Снова правой кнопкой на Схема Active Directory, но уже выбираем Хозяин операций… ;
  4. Нажимаем кнопку Сменить.

После этого необходимо подтвердить выбор и получить уведомление об успешном переносе роли.

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

Трудно недооценить важность «Схемы Active Directory» для сетей, построенных на базе доменной среды Active Directory. Это основа технологии «AD» и очень важно правильно понимать принципы ее функционирования. Большинство системных администраторов не уделяют схеме должного внимания по причине того, что иметь дело с ней приходится достаточно редко. В данной статье я расскажу, что такое версия схемы, для чего нам необходимо ее знать и самое главное как посмотреть текущую версию. Прежде всего, пару слов о самой схеме, каждый объект, созданный в Active Directory, будь то пользователь или компьютер, имеет определенные параметры, называемые атрибутами. Самым простым примером может служить атрибут «Фамилия» у объекта пользователь. Схема определяет, какие объекты мы можем создавать в Active Directory, и какие атрибуты они будут иметь.

Active Directory допускает использование в рамках одной организации несколько контроллеров домена, построенных на базе разных версий ОС Windows. А именно – на базе Windows Server 2000, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008. Поскольку данные версии выпускались в разные годы, и каждая новая версия несет больший функционал, чем предыдущая, понимание схемы у каждой операционной системы свое. Поэтому при добавлении нового контроллера на базе Windows Server 2008 в организацию, где существующие контроллеры построены на Windows Server 2003, вам приходилось запускать утилиту «Adprep ». Тем самым вы обновляли схему вашей организации до того уровня, с которым работает Windows Server 2008.

Процесс обновления схемы выполнялся до установки первого контроллера Windows Server 2008 и собственно сама процедура установки нового контроллера, могла и не выполняться. Если вы только начинаете работать с какой-то организацией Active Directory и не знаете, какие действия осуществлялись до вашего прихода, вам для понимания полноты структуры, будет нужно знать, на каком уровне работает Схема текущей организации.

Возможные версии схемы:

13 – Windows 2000 Server
30 – Windows Server 2003 RTM, Windows 2003 With Service Pack 1, Windows 2003 With Service Pack 2
31 – Windows Server 2003 R2
44 – Windows Server 2008 RTM

Даже если все контроллеры в вашей организации работают на Windows Server 2003 R2, а версия схемы показывает «44» не стоит удивляться, это говорит о том, что уже было осуществлено обновление схемы до уровня Windows Server 2008 RTM, но сам контроллер по какой-то причине устанавливать не стали.

Посмотреть версию схемы можно несколькими способами. Самым простым является способ с использованием утилиты «DSQuery». Для этого в командной строке необходимо ввести команду со следующими параметрами:

“dsquery * cn=schema,cn=configuration,dc=domainname,dc=local -scope base -attr objectVersion”

Естественно в части «dc= domainname, dc= local» вы должны подставить имя собственного домена. (Пример: dc= microsoft, dc= com )

Результатом ввода команды является получение атрибута «ObjectVersion », который и будет являться номером версии схемы:

Рис. 1 Получение версии схемы через утилиту «DSQuery».

Второй способ более длинный и подразумевает использование оснастки «ADSIEdit . msc » . Для просмотра версии схемы вам придется подключиться к разделу Active Directory схема.

"CN=Schema,CN=Configuration,DC=domain,DC=local "

И найти значение атрибута "objectVersion ".

Рис.2 Получение версии схемы через оснастку «ADSIEdit . msc ».

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

Следует отметить, что обновления схемы могу производиться программным обеспечением тесно интегрированным с Active Directory. Самый яркий пример Microsoft Exchange Server. И зачастую в организации, планирующей внедрение Exchange Server, необходимо выяснить, была ли осуществлена подготовка схемы? И если была, то какой версией Exchange Server. На текущий момент существуют три версии Exchange, работающие с Active Directory, но вариантов модификации схемы существует шесть.

Понять была ли изме
нена Схема Active Directory Exchange сервером можно по атрибуту «rangeUpper», который принимает следующие значения:

4397 – Exchange Server 2000 RTM
4406 – Exchange Server 2000 With Service Pack 3
6870 – Exchange Server 2003 RTM
6936 – Exchange Server 2003 With Service Pack 3
10628 – Exchange Server 2007
11116 – Exchange 2007 With Service Pack 1

Как можно заметить обновление схемы происходит и при установке набора обновлений SP3 для Exchange Server 2000/2003 и SP1 для Exchange 2007.

Посмотреть значение атрибута «rangeUpper» можно через утилиту DSQuery:

"dsquery * CN=ms-Exch-Schema-Version-Pt, cn=schema, cn=configuration, dc=domainname, dc=local -scope base -attr rangeUpper"

Рис. 3 Получение атрибута «rangeUpper» через утилиту DSQuery.

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

Процесс обновления схемы является очень важным моментом для каждой организации Active Directory, поэтому следует избегать лишних, неоправданных действий. Понимая сути атрибутов «objectVersion » и «rangeUpper» дает специалисту преимущество при работе с Active Directory в незнакомой организации, а также является вспомогательным инструментом при решении проблем.




Top