|
|
|
от Dan DiNicolo |
|
|
Добро пожаловать в статью 18 моей серии. Статья этой недели посвящена протоколу Kerberos, а также репликации в Active Directory. Мы изучим, как действует протокол Kerberos в среде одного и нескольких доменов и то, как происходит репликация внутри и между сайтами. Статья следующей недели завершает рассмотрение Active Directory и будет содержать углубленный взгляд на поддержку базы данных AD, управление мастерами операций и службу Remote Installation Services (RIS – служба удаленной установки). Еще через неделю начнется цикл из приблизительно восьми статей, посвященным экзамену 70-216 (Networking). В данную статью включены следующие материалы:
Kerberos v.5 Active Directory в Windows 2000 реализована на протоколах аутентификации, отличных от протоколов, используемых в Windows NT. Если NT 4 использует протокол аутентификации NT Lan Manager (NTLM), то Windows 2000 использует протокол Kerberos. Протокол Kerberos разработан в Массачуссетском технологическом институте (США) и назван по аналогии с Cerberus (Цербером), трехголовым огнедышащим псом, охраняющим ворота Царства теней. Зачем я говорю вам все это? Делаю это я для того, чтобы вы запомнили, что Kerberos является «трехголовой» схемой аутентификации. Тремя участниками протокола Kerberos являются: 1. Клиент – система/пользователь, делающий запрос. 2. Сервер – система, которая обеспечивает сервиз для систем, чью подлинность нужно подтвердить. 3. Key Distribution Center (KDC – центр распределения ключей) – сторонний посредник между клиентом и сервером, который ручается за подлинность клиента. В среде Windows 2000 в роли KDC выступает контроллер домена с запущенной Active Directory (это может быть также KDC на UNIX-системе). То, как Kerberos работает, может выглядеть пугающе сложным, если вникать в массу мельчайших подробностей, но я избегал их, чтобы рассказать только об основных принципах работы протокола. Очень важно, чтобы вы поняли сначала сам процесс, а если вы захотите узнать все его скрытые детали – я дам вам соответствующие ссылки в конце этого раздела. В среде Kerberos для входа в систему пользователь должен предоставить свое имя пользователя, пароль и имя домена (часто упоминаемое как Realm (Сфера) в словаре Kerberos), в который он хочет войти. Эта информация посылается KDC, который устанавливает подлинность пользователя. Если пользователь подлинный, ему предоставляется нечто, называемое ticket-granting ticket (TGT – билет на получение билета). Я бы предложил представлять TGT как штамп в паспорте, разрешающий въезд в страну– он подтверждает, что вы уплатили за визу и имеете соответствующее разрешение. TGT очень полезен, так как вам не приходится вновь аутентифицироваться каждый раз, когда вам необходимо получить доступ в систему, теперь вы просто предъявляете ваш «штамп в паспорте». Однако, если вам необходим доступ к конкретному серверу, вам также необходим билет для этого сервера или вы не сможете создать сеанс связи с ним. Думайте об этом билете, как о билете, который вам необходимо купить для похода в кино – хотя вы уже заплатили за визу (что удостоверяется штампом в вашем паспорте – TGT), вам все же необходимо купить и этот билет. Когда вы хотите получить доступ к серверу, вы сначала должны обратиться к KDC, предъявить свой билет TGT, как подтверждение своей подлинности, а затем уже запросить билет сеанса на сервера, с которым вам необходим контакт. Если вы аутентифицированы, вы сможете получить доступ к серверу в соответствии с правами, которыми обладаете. Билет сеанса и TGT, которые вы получаете, имеют ограниченное время действия, которое может настраиваться в групповой политике. Значения по умолчанию составляют для TGT (также упоминаемого как билет пользователя) 7 дней, а для билета сеанса (также упоминаемого как билет службы) – 10 часов. В среде с одним доменом аутентификация Kerberos осуществляется очень просто. Однако в среде со многими доменами, этот процесс происходит в несколько этапов. Причина в том, что когда вы пытаетесь получить билет сессии для сервера, он должен быть получен от KDC того домена, в котором расположен сервер. Поэтому вы должны будете получить несколько билетов сессии, для преодоления доверительных отношений по пути к KDC, к которому вам нужно получить доступ. Пример, приведенный ниже, демонстрирует шаги, необходимые для того, чтобы клиент, расположенный в домене west.win2000trainer.com получил доступ к серверу в домене east.win2000trainer.com. 1. Клиент входит в систему как пользователь в домене west.win2000trainer.com и получает соответствующий TGT. 2. Клиент хочет взаимодействовать с сервером в домене east.win2000trainer.com. Он контактирует с KDC в домене west.win2000trainer.com и запрашивает билет сеанса для KDC в домене win2000trainer.com. 3. После получения этого билета, он контактирует с KDC в домене win2000trainer.com и запрашивает билет сеанса для KDC в домене east.win2000trainer.com. 4. После получения этого билета, он контактирует с KDC в домене east.win2000trainer.com и запрашивает билет для сервера, к которому ему необходим доступ. 5. Получив билет сессии для доступа к серверу, клиент имеет доступ к нему в соответствии с имеющимися у него разрешениями. Это выглядит слишком громоздко, то это на самом деле так. Это одна из причин для применения сокращенных доверительных отношений, как об этом рассказывалось в моей прошлой статье. Если существуют сокращенные доверительные отношения, то для аутентификации выбирается наиболее короткий из возможных путей. Kerberos является замечательным протоколом, делающим сети более безопасными, благодаря необходимости аутентификации между клиентами и серверами, перед установлением соединения между ними. Он работает гораздо быстрее, чем вам может показаться. Для выяснения скорости его работы вы можете провести следующий эксперимент: Вы можете установить Network monitor (монитор сети) в среде с несколькими доменами и затем запустить его во время установления доступа к ресурсам в различных доменах. И хотя содержание пакетов является зашифрованным, они дадут вам замечательную иллюстрацию того, что происходит «за сценой» протокола Kerberos. Есть три утилиты для выявления неисправностей протокола Kerberos это – Netdom (о которой уже упоминалось в предыдущей статье), а также утилиты из resource kit – Kerb Tray.exe и Llist.exe. Для более подробного ознакомления с протоколом Kerberos смотрите здесь. Для ознакомления с Kerberos V5 RFC (Requests for Comments – запросы на комментарии), смотрите здесь. Репликация в Active Directory В среде Windows 2000 репликация отличается от той, что осуществляется в Windows NT. В среде NT репликация осуществляется в режиме single-master (одного главного), что означает, что только на одном контроллере домена допускаются обновления – на PDC (главном контроллере домена). В Widows 2000 действует модель multi-master (нескольких главных), означающая, что на любом контроллере домена можно производить обновления в Active Directory. Эта модель представляется более сложной, если думать об отслеживании изменений в сети и разрешении конфликтов, которые могут возникнуть, о чем я расскажу чуть позднее. Однако, вместе с усложнением репликации в Windows 2000 Active Directory, здесь так же присутствует возможность более простого контроля процесса репликации, через использование сайтов, site links (связей сайтов) и работы по расписанию. Я мог бы спокойно посвятить всю эту статью только репликации, так как здесь присутствует много вещей, которые происходят «за сценой». К счастью, для того, чтобы понимать репликацию, достаточно знать некоторое количество основных концепций (хотя их число не такое уж и маленькое), многие из которых достаточно «прозрачны». Давайте же посмотрим, как работает репликация. В среде Active Directory контроллерам домена нет необходимости связываться с одним главным контроллером домена для получения изменений. Вместо этого, они создают связи друг с другом для отслеживания, какой контроллер домена будет выступать в качестве источника репликации изменений. Эти взаимоотношения называются connection objects (объекты-подключения) и я скоро расскажу, как они создаются и как работают. Так как каждый контроллер домена может вносить изменения, необходимо знать, какой домен это изменение внес. Впервые сделанное на данном контроллере изменение называется исходное обновление. Любое изменение, которое контроллер домена получает в процессе репликации, называется реплицированное обновление. Эта терминология пригодится нам в дальнейшем. Процесс репликации данных от одного контроллера домена на другой отличается в зависимости от того, происходит ли этот процесс внутри или между сайтами. Как уже говорилось раньше, сайт – это набор подсетей IP, связанных между собой высокоскоростными линиями. А вот связь между сайтами осуществляется по более медленным линиям, часто это WAN-линии. Вам необходимо определить подсети в Active Directory, в противном случае, AD сама определяет, что все контроллеры вашего домена являются частью единого сайта, создающегося по умолчанию, дословно называемому Default-First-Site (первый сайт по умолчанию). Репликация внутри сайта происходит через 5-минутный интервал задержки уведомления. При этой установке, после возникновения изменения происходит задержка на 5 минут перед отправкой уведомлений партнерам по репликации (сами сообщения тоже разделены 30-ти секундными интервалами). Это дает контроллеру домена время для накопления серии изменений, вместо того, чтобы реплицировать каждое изменение в отдельности. После уведомления партнеры по репликации обмениваются изменениями. Заметьте, что при репликации данные всегда «вытягиваются» (pull), а не «выталкиваются» (push). Репликация между сайтами требует более подробного обсуждения и будет рассмотрена чуть позднее. Процесс, который создает объекты подключения между контроллерами домена, запускается на всех контроллерах домена автоматически и называется Knowledge Consistence Checker (KCC - дословно: служба проверки непротиворечивости знаний). КСС стартует каждые 15 минут и вносит изменения в топологию объектов-подключения, если это необходимо (например, если какой-либо из контроллеров домена временно недостижим). Так же можно вручную создавать объекты-подключения между контроллерами домена, хотя в этом и нет необходимости. Объекты-подключения перечислены (там же они и создаются) в оснастке Active Directory Sites and Services в узле настройки NTDS (NT Directory Service) для данного сервера. Заметьте, что указанные объекты-подключения – это те, из которых данный контроллер домена будет «вытягивать» изменения в ходе репликации. По умолчанию, КСС создает топологию, используя принцип, согласно которому контроллер домена получает обновления от другого контроллера, который не может находиться дальше, чем в трех переходах от него (three-hop rule – правило трех переходов). В данном случае, переходами называется число контроллеров домена, которые необходимо пройти, чтобы доставить изменения на другой контроллер. Вследствие природы репликации Active Directory возможно возникновение конфликтов, когда, например, два контроллера домена вносят исходное обновление одного и того же объекта (например, пользователя) одновременно. Прежде всего, Active Directory помогает сократить вероятность конфликта, репликацией на уровне атрибутов объекта. Это означает, что если один контроллер внес изменение в пароль пользователя, а другой – изменил его почтовый код, конфликта не будет, несмотря на то, что изменения произведены одновременно и над одним и тем же объектом. Если конфликт все же возникает, он разрешается одним из трех возможных методов (также известным как globally unique stamps – глобальные универсальные штампы), в следующем порядке: 1. Номер версии – все атрибуты создаются с номером версии равным 1. Каждый раз, когда происходит обновление, номер версии увеличивается на единицу, и более высокий номер версии всегда побеждает. Однако возможно, что 2 контроллера домена одновременно могут внести разные изменения в один и тот же объект (или атрибут объекта), а значит обе измененные версии будут иметь один и тот же номер, что означает, что конфликт продолжает существовать. 2. Временной штамп – для событий, чьи номера версий одинаковы, используется временной штамп, который сравнивает время внесения изменений каждым контроллером домена. Самое последнее обновление побеждает (напр.: 2:10 победит 2:07). 3. GUID (глобальный идентификатор) сервера – при неблагоприятном стечении обстоятельств, когда конфликт продолжает существовать, сравниваются глобальные идентификаторы серверов и сервер, с большим значением GUID побеждает. Есть и еще пара ситуаций, которые могут вызывать проблемы. Один из примеров – объект, лишенный контейнера. Например, вы создали пользователя в OU называемой Sales, а через минуту ваш товарищ на другом контроллере домена удаляет OU Sales, до того, как пользователь будет внесен в OU в ходе репликации. В этом случае, родительский объект для пользователя больше не существует, но пользователь все же может быть найдет в специальном контейнере, называемом LostAndFound (потерянные и найденные), как показано ниже:
В случае, если создаются объекты на различных контроллерах доменов с одинаковыми различающимися именами, один из них (с более высоким приоритетом штампа из списка, приведенного выше) унаследует имя, в то время как второй будет иметь имя, образованное из его относительного имени + буквы “CNF” + GUID этого объекта. Другой потенциальной проблемой репликации в модели со многими главными контроллерами является возникновение колец репликации. Представьте себе, что контроллер А говорит контроллерам В и С, что произошло изменение. После получения изменения, В может также попытаться уведомить С, что произошло изменение, хотя С уже тоже получило его. Для разрешения этой проблемы Active Directory использует технологию, называемую propagation dampening (передача успокоения). По этой технологии каждый контроллер домена хранит в памяти таблицу, называемую таблицей обновлений, в которую записываются номера последовательности обновлений (USN – update sequence numbers) для каждого контроллера домена. Когда контроллер домена осуществляет исходное обновление, он обновляет номер USN, и эта информация передается другим контроллерам. Например, если изменение было проведено на контроллере DC1, и USN на DC1 увеличилось до значения 2667, все контроллеры домена получают эту информацию в их таблицы обновлений, и не будут требовать обновления этих данных снова от своих партнеров по репликации, имеющих ту же версию USN. Репликация между сайтами в среде Active Directory отличается от репликации внутри сайта. Как уже упоминалось ранее, сайт – это набор подсетей, связанных друг с другом высокоскоростными соединениями. Для определения сайтов и подсетей, соответствующие объекты должны быть созданы и связаны друг с другом. Проще всего создать сначала объект Сайт и затем связать с ним объект Подсеть. Как показано на рисунке, приведенном ниже, в моей сети создано 3 новых сайта, а с сайтом в Торонто связано 3 подсети:
Для контроля репликации между сайтами необходимо связать сайты вместе, используя, так называемые, site links (связи сайтов). Связь сайтов связывает между собой два сайта в целях создания пути, по которому будет происходить репликация. Если связь сайтов создана, у нее могут быть установлены свойства, такие как cost (стоимость), schedule (расписание) и interval (интервал). Стоимость – это число между 1 и 32767, которое помогает выбрать лучшую связь сайтов в случае нескольких возможных путей репликации. Обычно вы связываете стоимость со скоростью связи – где-то около 50 для линий Т1, 500 для линий 56К и т.д. Расписание определяет, когда репликация должна происходить. По умолчанию выбрано значение always (всегда), но вы можете выбрать, чтобы она происходила, например, только ночью. Интервал контролирует, как часто происходит репликация между сайтами. По умолчанию это значение составляет 180 минут, но вы можете установить большее или меньшее значение. Заметьте, что внутри-сайтовая репликация не использует посылку уведомлений об изменениях. Вместо этого используются расписание и интервал для вычисления, когда репликация будет происходить. Это очень отличается от репликации в среде NT 4, где уведомления об изменениях использовались повсеместно. Если вы думаете, что использование связей сайтов может породить некоторые проблемы, то вы будете правы. Например, представьте, что вы создали учетную запись нового пользователя и это изменение было произведено на контроллере домена в Торонто в 9 утра. Если расписание связи сайтов настроено так, что репликация между Торонто и Ванкувером происходит только в ночное время, то учетная запись пользователя в Ванкувере появиться не раньше наступления ночи, а значит, он не сможет войти в систему в Ванкувере. Заметьте, что эту проблему достаточно легко обойти – просто соединитесь с другим контроллером домена (любым из сайта в Ванкувере) и создайте учетную запись пользователя там. При этом исходное обновление будет иметь место в Ванкувере и тогда пользователь (раз уж он находится в Ванкувере) сможет войти в систему немедленно.
Картина объектов-соединений между контроллерами домена отличаются внутри и вне сайтов. Внутри сайта контроллеры домена имеют множество объектов-соединений с другими контроллерами. А между сайтами репликация происходит между контроллерами домена в каждом сайте, которые назначены bridgeheads (у Microsoft это переводится как сервер-плацдарм). Сервера-плацдармы выбираются автоматически, но вы можете построить список предпочитаемых серверов-плацдармов, как показано на рисунке, расположенном ниже. Процесс, который выбирает сервер-плацдарм, называется Intersite Topology Generator (ISTG – межсайтовый генератор топологии), который запускается автоматически и назначает новый сервер-плацдарм, если текущий в силу какой-либо причины недоступен.
Важно правильно определить протокол, который будет использоваться для связи сайтов. Active Directory поддерживает связь сайтов при помощи протокола RPC (в интерфейсе он указан как протокол IP), а также протокола SMTP. Внутри сайта контроллеры домена используют только RPC, так как SMTP не поддерживает репликацию раздела домен между контроллерами в одном и том же домене (потому, что папка Sysvol реплицируется только при помощи RPC). SMTP, однако, поддерживает репликацию разделов Схема, Конфигурация и Глобальный Каталог. Протокол SMTP также используется для распределенных сред с ненадежными линиями WAN. По умолчанию, все связи сайтов, которые вы создаете, могут образовывать мосты (являются транзитивными). При вычислении лучшего пути для репликации, рассматриваться все существующие связи сайтов.
Например, в диаграмме, показанной выше, репликация между сайтами А и D будет происходить через путь с минимальной ценой, по мосту связи сайтов, который будет автоматически создан – ABD, цена которого будет равна 20. Заметьте, что альтернативный путь AD будет стоить 200, а мост ACD – 110. Рассмотрев все возможные связи сайтов, AB и BD будут связаны в мост для создания моста с наименьшей возможной стоимостью пути. Связи сайтов создаются в оснастке AD Site and Services. Как правило, название для связи сайтов выбирается на основании имен сайтов, которые они связывают.
В некоторых ситуациях, если ваша сеть не является полностью маршрутизируемой, вам может потребоваться создавать мосты связей сайтов вручную для того, чтобы создать путь для репликации. В подобном случае, вам придется отключить автоматическое создание мостов связей сайтов и создать мосты вручную в оснастке AD Sites and Services. Заметьте, что нет нужды создавать мосты связи сайтов в полностью маршрутизируемой среде, так как связи сайтов образуют мосты по умолчанию, помогающие вычислить путь для репликации с наименьшей стоимостью автоматически. Вы должны также знать, что существуют инструменты для выявления неисправностей репликации. Это два главных инструмента – Replication Monitor (Replmon.exe) и Repadmin.exe. Replication Monitor устанавливается вместе с другими дополнительными инструментами из директории Support\Tools на компакт-диске Advanced Server и предоставляет большое количество информации о среде репликации, включая возможность видеть USN, партнеров по репликации, статус репликации на сервере, переключение репликации между партнерами и т.д. Repadmin – полезная утилита командной строки, но предоставляет информацию только об одном контроллере домена одновременно. Вот мы и добрались до конца статьи. На следующей неделе мы закончим рассмотрение материалов, относящихся к Active Directory. Мы рассмотрим базы данных Active Directory, а также Remote Installation Services (RIS). Как всегда, прошу контактировать со мной для вопросов и комментариев, но, пожалуйста, посылайте технические вопросы на доску объявлений. До следующей недели, успехов в учебе.
Дэн
|
