 TechNet Magazine July 2007

TechNet Magazine July 2007

Связь: Защита данных и восстановление после сбоев в среде Exchange Server 2007

В Exchange Server 2007 включен целый ряд возможностей по поддержке высокой доступности и восстановления после сбоев. Исследование альтернативных возможностей Exchange имеет целью предложить и спланировать идеальное решение по восстановлению данных в вашей организации.

Lee Benjamin Связь: Улучшение безопасности при помощи Windows Mobile 6

Хотя смартфоны и карманные компьютеры предоставляют доступ к сети вне офиса, они также могут привести к возникновению в сети новых уязвимостей. В данном руководстве описывается защита мобильных устройств и инфраструктуры компании средствами Windows Mobile 6 и Exchange Server.

Matt Fontaine Связь: Серьезная альтернатива общим папкам

MOSS 2007 предлагает гораздо более серьезное решение для предоставления общего доступа к данным, чем общие папки сервера Exchange, включая улучшенные возможности и более простое администрирование. Посмотрите, как можно использовать SharePoint для предоставления общего доступа к календарям, контактам и документам.

Alan Maddison Связь: Вход в Outlook Web Access при помощи смарт-карт

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

Victor Akinnagbe, Ted Dressel, and Jason Opdycke Администрирование в Windows: Служба установщика ActiveX в Windows Vista

Как вы защищаете настольную систему от вредоносных элементов управления ActiveX, не ограничивая совместимость приложений? Мы рассмотрим службу установщика ActiveX (AxIS) в Windows Vista, которая решает эту проблему с помощью нового способа управления элементами управления ActiveX.

Rob Campbell and Joel Yoker От редактора: Шесть степеней

Joshua Trupin Инструментарий: Новые продукты для специалистов по информационным технологиям

Greg Steen Вопросы и ответы про SQL: Кластеризация изнутри, таинственные зависания, учетная запись SA и прочее

Edited by Nancy Michell Обзор служебных программ: SMSMap

Jeff Tondt Принцип работы: Устранение ошибок удаленного вызова процедур

Zubair Alexander Кабельщик: Трафик IPv6 через подключения VPN

Joseph Davies Windows PowerShell: Пересмотр понятия конвейера

Don Jones Эй, автор сценариев!: В сценариях, как и в жизни, внешний вид очень важен

The Microsoft Scripting Guys Exchange Queue — очередь за ответами: Роли пограничного транспортного сервера и транспортного сервера-концентратора, виртуальные машины и многое другое

KC Lemson and Nino Bilic На страже безопасности: Средства управления списками ACL

Jesper M. Johansson Материалы о рабочей среде: Пакет оптимизации рабочей среды Майкрософт

Wes Miller Конфиденциальная информация Windows: Преимущества безопасного режима

Raymond Chen


 Связь: Защита данных и восстановление после сбоев в среде Exchange Server 2007
Связь Ли Бенджамен (Lee Benjamin)

Защита данных и восстановление после сбоев в среде Exchange Server 2007
Краткий обзор:
  • Базовые архивация и восстановление
  • Непрерывность данных
  • Технологии репликации
  • Альтернативные решения

Среда Microsoft Exchange Server разрабатывалась с учетом необходимости операций архивации. Организациям необходимо архивировать данные обмена сообщениями, а также иметь возможность восстанавливать их. Чтобы удовлетворить эти потребности, в корпорации Майкрософт создан полный спектр возможностей защиты данных, начиная с простых традиционных возможностей
архивации и восстановления, обеспечивающих непрерывность рабочего процесса, вплоть до решений, в полном объеме обеспечивающих непрерывность всей деятельности предприятия и предоставляющих высочайший уровень доступности и восстановления после сбоев. В данной статье будут рассмотрены эти возможности и сделана попытка помочь читателю выбрать способ реализации решения для восстановления, оптимальный для конкретной организации.

УРОВЕНЬ 1: БАЗОВЫЕ АРХИВАЦИЯ И ВОССТАНОВЛЕНИЕ
Файлы Exchange можно архивировать, переведя базы данных в автономный режим, но архивирование можно выполнять также и во время работы базы данных. В действительности, в большинстве случаев для архивирования Exchange предпочтительным является последний вариант. Но Exchange не сводится к набору файлов. Он является хранилищем информации, содержащим большие файлы баз данных и журналы транзакций. Сообщения, передаваемые в Exchange, незамедлительно записываются в журналы транзакций, и при появлении у системы свободного цикла (обычно несколько миллисекунд спустя) сообщения копируются непосредственно в базу данных. Отправляя информацию на диск как можно быстрее, Exchange обеспечивает очень высокий уровень восстанавливаемости. Для Exchange существенно наличие доступа к обоим наборам данных. В случае сбоя системы именно сочетание предшествующего архива со всеми транзакциями, выполненными после этого момента, позволяет восстановить Exchange с наиболее свежими данными. Отметим, что при необходимости Exchange автоматически воспроизводит транзакции на восстановленной базе данных.
Способ, которым программы архивации получают доступ к информации в базах данных Exchange, состоит в использовании интерфейса API архивации ESE (Extensible Storage Engine) или более новых решений VSS, о которых речь пойдет позднее. При каждом запуске архивации ESE временно приостанавливаются все операции Exchange по выполнению записи в базы данных. В это же время ESE временно переводит базу данных в режим только для чтения, что позволяет выполнить полную архивацию базы данных; кроме этого, для поддержки транзакций, возникших во время архивирования, используется временная база данных. По завершении архивирования ESE возвращает базу данных в нормальный режим чтения/записи и применяет транзакции, накапливавшиеся во временной базе данных. В рамках архивации журналы старых транзакций удаляются в конце нормально завершающегося процесса архивирования.
Хотя этот процесс архивирования является простым и понятным даже для пользователей, которые вошли в систему среди ночи, во время выполнения архивирования, механизму ESE может потребоваться значительное время для завершения работы, в особенности потому, что размер баз данных Exchange может колебаться в пределах от нескольких гигабайт до поддающихся управлению 30 – 50 или даже до 100 ГБ, архивирование которых оказывается почти невозможным выполнить в течение ночи с использованием стандартных технологий. Чтобы получить представление о вариантах, доступных при использовании NTBackup.exe, обратимся к рис. 1.
Рис. 1 Использование служебной программы NTBackup
Рис. 1 Использование служебной программы NTBackup

Рекомендации для Exchange
Если требуется обеспечить возможность быстрого восстановления после обычных сбоев оборудования или системных сбоев, необходимо в ночное время запускать операции полной архивации Exchange. Для повышения производительности и восстанавливаемости важно при использовании сервером Exchange локальных дисков всегда использовать для хранения баз данных Exchange и журналов транзакций Exchange отдельные массивы RAID. При таком подходе, сохраняется возможность восстановления, если отказывает контроллер массива RAID, или в массиве возникает сбой нескольких дисков, не позволяющий использовать оставшиеся диски для реконструкции данных с чередующихся томов. В случае утраты журналов транзакций остаются обновленные базы данных Exchange на других дисках, что позволяет продолжать нормальные операции с новыми журналами транзакций. Если утрачены диски с базами данных, стратегия восстановления заключается в возврате к полному архиву баз данных Exchange, полученному накануне ночью, и применению журналов транзакций текущего дня для получения обновленного состояния баз данных.
Важно ограничивать размер баз данных Exchange, чтобы архивирование каждой из них (и, что более существенно, восстановление) можно было выполнить за приемлемое время. Для большинства организаций эта рекомендация подразумевает поддержание размера баз данных в интервале от 30 до 50 ГБ. Когда база данных выходит за эти пределы, рекомендуется разделить ее на несколько баз данных, что добиться управляемости процесса восстановления.

Непрерывный спектр решений для архивации и восстановления
Размещение баз данных и журналов транзакций является крайне важным обстоятельством не только для производительности процесса архивирования, но также для скорости восстановления. В настоящее время все серверы поддерживают разную степень избыточности дисков, известную под названием RAID. В принципе, RAID позволяет сохранить работоспособность системы при выходе диска из строя, хотя производительность системы уменьшается до момента замены или восстановления диска. До этого времени контроллер массива дисков должен «на ходу» реконструировать данные с оставшихся дисков в ответ на все запросы, требующие доступа к этому диску. Для получения дополнительных сведений о конструкции хранилищ для серверов почтовых ящиков ознакомьтесь со статьей Майкрософт IT Showcase под названием Переход на 64-разрядные технологии в Exchange Server 2007".
Основная особенность Exchange определяется проектом баз данных, предусматривающим использование единственного экземпляра. Это означает, что в базе данных Exchange хранится единственная копия конкретного сообщения вместе с единственным вложением (при его наличии). Если сообщение было передано нескольким получателям в одном и том же хранилище данных, создаются дополнительные указатели на объекты (сообщение, вложение), но сами объекты не дублируются. Такой подход не только обеспечивает значительное преимущество с точки зрения эффективности доставки, но и позволяет Exchange экономить пространство как на диске, так и на ленте.
Хотя Exchange хорошо справляется с восстановлением базы данных в целом, для восстановления индивидуальных почтовых ящиков, папок или сообщений требуется сначала восстановить всю ленту. Не удивительно, что пользователям хотелось бы иметь более дифференцированные возможности восстановления. Единственный экземпляр на ленте значительно затрудняет это. Поставщики средств архивации откликнулись на эту проблему созданием «Brick-Level Backup» (Архивация на уровне базовых блоков) (пользоваться которой я не рекомендую). По завершении полной архивации базы данных Exchange с помощью испытанного интерфейса API механизма ESE программные продукты архивации добавляют на архивную ленту все почтовые ящики. Поскольку интерфейс API средств архивации не предоставляет возможности извлекать данные из отдельных почтовых ящиков, используется MAPI. В результате лента с архивом становится значительно длиннее, поскольку дублируются все эти сообщения и вложения.
В корпорации Майкрософт были внесены некоторые улучшения, которые частично устраняют эту проблему. Например, в административной мусорной корзине (или мусорном контейнере) удаленные пользователями элементы хранятся в течение некоторого периода времени на тот случай, если они понадобятся. Кроме этого, больше нет необходимости в наличии резервного сервера в качестве леса восстановления Exchange; группы хранения для восстановления дают администратору возможность частично подключать восстановленные базы данных, перенесенные с ленты, и копировать или объединять данные на уровне почтового ящика.

«Практика — путь к совершенству»
Многие организации знают по собственному горькому опыту, что, несмотря на решение, принятое относительно уровня архивации и восстановления, необходимо регулярно проверять носители архивов и процедуры восстановления. Очень многие администраторы только после сбоя узнают о том, справляются ли со своими функциями технология архивации и процедуры восстановления. Оптимальный момент для проверки — это день после установки и настройки нового сияющего сервера, когда он уже функционирует в качестве компонента организации Exchange, но с ним работают всего несколько пользователей. На этом этапе следует выполнять полную архивацию Exchange, регулярные архивирования дисков, а также собирать данные о состоянии системы, в которые входят важнейшие файлы на системном диске, а также метабаза IIS (содержащая настройку маршрутизации Exchange). Затем спокойно переформатируйте новый сервер и начните сначала, обновляя записи, сделанные при первоначальной установке сервера. Необходимо иметь возможность восстанавливать параметры на основе данных о состоянии системы, но, кроме этого, необходимо иметь соответствующую документацию для повторной установки параметров настройки системы вручную.
Время, затрачиваемое на эту практическую проверку, значительно сократит время, которое потребуется для восстановления в будущем. Периодически повторяйте эту процедуру. Занимаясь этим, засеките время, требуемое для доставки лент извне организации. Те, кто мучился в течение этого кажущегося бесконечным интервала времени, зачастую задумываются более серьезно о том, насколько важным компонентом стратегии архивации и восстановления является архивирование данных с диска на диск — даже если ленточный накопитель вне организации продолжает оставаться последней поддержкой для восстановления после сбоя.

Сложности, связанные с архивированием на ленты
Восстановление с ленты занимает слишком много времени. В настоящее время Exchange играет настолько важную роль в работе организаций, что пользователи и руководство рассчитывают на то, что он будет доступен постоянно. При возникновении серьезной проблемы большинство организаций оказываются захваченными врасплох. Никто не готов к сообщению о том, что для восстановления с ленты базы данных в 75 Гбайт потребуется восемь часов даже без учета времени на доставку лент из находящегося за пределами организации хранилища или переустановки операционной системы.
Более того, существует также проблема извлечения с ленты требуемой базы данных. В течение 10 лет, прошедших с момента первого выпуска Exchange, стоимость дискового хранилища и глобальной сети значительно упала. В результате многие организации могут позволить себе более быстрые методы архивации и восстановления. У этих организаций есть реальная возможность воспользоваться преимуществом технологий, позволяющих добиться непрерывности рабочего процесса и восстановления после сбоев в рамках инфраструктуры Exchange.

УРОВЕНЬ 2: НЕПРЕРЫВНОСТЬ РАБОЧЕГО ПРОЦЕССА
Под непрерывным рабочим процессом понимается набор процедур и технологий, подразумевающих максимально быстрое восстановление и минимизацию непредвиденных простоев. Непрерывность рабочего процесса предлагает улучшенные целевое значение времени восстановления и целевую точку восстановления на ленте для локального восстановления. Прилагаются усилия к тому, чтобы везде, где это возможно, избавиться от затрат времени на доставку лент к месту восстановления. Обратимся к рис. 2, чтобы сравнить архивацию и восстановление по методу непрерывного рабочего процесса и по методу DR.
Рис. 2 Непрерывное множество решений для восстановления
Рис. 2 Непрерывное множество решений для восстановления
На этой схеме иллюстрируется непрерывное множество решений для восстановления и доступности от медленного и дешевого в левой нижней части до быстрого и дорогостоящего в правой верхней части с преднамеренно нечетким переходом между решениями для непрерывного рабочего процесса и для восстановления после сбоя.
Этот график дает представление о компромиссах между ценой, временем восстановления и доступностью в рамках этих подходов. В данной статье целенаправленно подчеркивалось отличие процедур, обеспечивающих локальную непрерывность работы, и решений по восстановлению после сбоя. Решение для восстановления после сбоев всегда рассматривается как удаленное, в котором основной целью является доставка данных за пределы организации. Расстояние вносит дополнительные сложности и обычно сопряжено с гораздо большей стоимостью, но решение для восстановления после сбоев относится к обеспечению функционирования предприятия после катастрофических событий. Более глубоко эта сторона проблемы будет рассмотрена далее.

Немного истории
Чем более жизненно важной частью инфраструктуры становился Exchange и чем больше информации хранилось в его базах данных, тем очевиднее становилось, что необходимо сокращать время архивирования и восстановления. Работая с Майкрософт, некоторые большие организации предложили подход, в котором обеспечивается улучшенный вариант возврата к частичным операциям. Если бы организация могла получать и отправлять сообщения электронной почты во внешний мир, все выглядело бы так, как будто ничего не случилось. В конце концов, важен вид со стороны.
Чтобы реализовать для Exchange этот ускоренный вариант восстановления, на место поврежденной помещалась новая база данных. Затем Exchange и Active Directory® создавали новые почтовые ящики с соответствующими разрешениями, и пользователи могли продолжать отправлять и получать сообщения. После того как лента с архивом доставлялась на место и данные восстанавливались, базу данных можно было подключить в режиме администратора. После этого администратор Exchange объединял восстановленные почтовые ящики с почтовыми ящиками тонального вызова. При необходимости почтовым ящикам можно было назначать приоритеты. Хотя эта процедура обеспечивала улучшение, она была сложной и требовала много времени; сначала в ней использовалась программа EXMERGE, а впоследствии она была приспособлена для групп хранения для восстановления. Тем не менее, следует отметить, что полное восстановление после использования ускоренного восстановления могло оказаться тяжелой и сложной задачей (в особенности с учетом того, что в Exchange 2007 возможно существование до 50 групп хранения). Если вы рассматриваете возможность реализации схемы ускоренного восстановления, необходимо соблюдать осторожность, убеждаясь, что преимущества стоят затраченных усилий.

Службы теневого копирования тома
Чтобы воспользоваться преимуществами дешевизны дисков и избавиться от перегрузки процессора на производственных серверах Exchange, для Microsoft® Windows Server® 2003 и Exchange был разработан новый интерфейс API архивации. Для получения согласованных копий данных на определенный момент времени была создана служба теневого копирования тома VSS. Эти моментальные снимки являются копиями только для чтения данных Exchange, в которые последовательно включаются только измененные данные. Эти копии обычно указывают на другой сервер со свободным дисковым пространством или сеть области хранения SAN. Можно поддерживать несколько снимков, с архивными копиями на ленте. В результате производственный сервер Exchange больше не испытывает влияния на производительность, оказываемого программным обеспечением для архивации и перегрузки, вызываемой копированием ленты.
Существует несколько преимуществ использования VSS для защиты данных Exchange. Во-первых, сервер Exchange можно освободить от нагрузки на производительность со стороны операций архивирования на ленту. Хотя по-прежнему сохраняется необходимость архивирования на ленту, для нее можно использовать копию данных Exchange без последствий для производительности пользователей. Во-вторых, появляется возможность делать снимки чаще, чем один раз за ночь. И, в качестве награды, можно поддерживать несколько снимков на дополнительном сервере или в другом локальном хранилище.
На рынке существует ряд программных продуктов сторонних производителей, которые используют преимущества возможности создания снимков VSS. Некоторые просто сокращают время, требуемое для архивирования и восстановления баз данных Exchange, в то время как другие добавляют такие возможности, как восстановление с большей степенью дифференцированности по сравнению с предоставляемой встроенной в Exchange процедурой, так что восстановление можно выполнять на уровне почтовых ящиков. Хотя никому такие блочные архивации не по душе, всем требуется возможность восстановления конкретных папок или даже отдельных сообщений.

Технологии репликации
Отказоустойчивость Exchange, обеспечиваемая программным способом, является возможностью, предлагаемой некоторыми поставщиками репликаций. При таком методе резервный сервер Exchange переводится в активное состояние, после чего компоненту Active Directory передается информация о том, что все пользовательские почтовые ящики перемещены. Существует два способа достижения этого результата, и для обоих требуются некоторые специальные настройки в среде Exchange и среде Windows. В одном из них играют роль некоторые хитрости, применяемые в DNS, в результате чего резервный сервер получает имя и адрес сервера, на котором возник сбой. Преимущество этого подхода состоит в легкости его применения на клиентских рабочих станциях, поскольку Outlook® считает, что по-прежнему используется прежний сервер.
Во втором подходе используется резервный сервер, на котором выполняется Exchange, поддерживающий копии базы данных, но к которому ничего не подключено. В случае сбоя резервный сервер сообщает компоненту Active Directory, что все пользовательские почтовые ящики были перемещены на него. Затем запускается сценарий или распределяется групповая политика, сообщающая клиентам, что они находятся на другом почтовом сервере. Outlook 2007 поддерживает Active Directory, что облегчает данный процесс, поскольку он сам выполняет автоматическое вычисление этих отображений.

Локальная кластеризация посредством MSCS
Выше в непрерывном множестве решений находятся службы кластеризации Майкрософт MSCS (Microsoft Cluster Services); Exchange является приложением, поддерживающим кластеризацию. При кластеризации информация делится между двумя или несколькими компьютерами, чтобы при сбое одного его функции на себя брали другие. В настоящее время большинство кластеров Exchange состоят из двух или четырех узлов, хотя предусмотрено использование до восьми узлов. Один узел всегда назначается пассивным — работает с выполняющимся на нем Windows Server и установленным Exchange Server, но не имеет активных почтовых ящиков. В Exchange 2003 существовал состоящий из двух узлов активный/активный кластер, но вследствие нагрузки на производительность он в настоящее время отменен и не будет поддерживаться в Exchange 2007.
Как и при организации кластеров в Exchange 2003, кластеры в Exchange 2007, в которые входит пассивный узел, по-прежнему могут использовать отдельный массив для совместного хранения. Хотя массивы хранения кластерного типа обычно имеют ряд функций резервирования, предназначенных для преодоления разных типов сбоев, они по-прежнему обеспечивают только одну копию данных, что оставляет окно для уязвимости. По этой причине такие кластеры называются кластерами одной копии (SCC), чтобы отличать их от следующего рубежа в защите данных, который возникает с появлением кластеров нескольких копий (MCC) в Exchange 2007. Кластеры MCC будут обсуждаться далее при рассмотрении восстановления после сбоя.

Локальная непрерывная репликация
Локальная непрерывная репликация (LCR) является новым компонентом Exchange 2007, обеспечивающим усовершенствованный способ поддержания второй копии баз данных Exchange и журналов транзакций в пределах одного сервера. Этим добавляется слой резервирования к оптимальной практике размещения базы данных Exchange на одном массиве RAID, а журналов транзакций — на другом: LCR предоставляет возможность хранения дополнительной копии журналов на массиве, где хранится основная копия базы данных, и хранения дополнительной копии базы данных на массиве, где хранится основная копия журналов (см. рис. 3). В случае сбоя одного из контроллеров RAID или массива сохраняется доступ к базе данных и журналам транзакций на другом массиве. При этом подходе можно продолжать работу (хотя в несколько нервной обстановке и с некоторым ухудшением производительности) до тех пор, пока не появится возможность восстановления работоспособности массива, на котором возник сбой.
Рис. 3 Настройка LCR
Рис. 3 Настройка LCR
LCR является решением, обеспечивающим непрерывность рабочего процесса в локальной среде, а не решением архивации, поэтому по-прежнему необходимо предусмотреть стратегию полной архивации. Кроме этого, LCR приводит к снижению производительности, поскольку сервер теперь создает две копии базы данных и журналов транзакций. Более того, в реализации Exchange 2007 имеются некоторые ограничения, из-за которых LCR оказывается подходящей только для небольших организаций, поскольку LCR поддерживает только одну базу данных в группе хранения и только одну базу данных общих папок в организации.
Обеспечение отказоустойчивости с помощью восстановления после сбоя, обеспечиваемого LCR, выполняется не мгновенно — знающему специалисту по ИТ придется запустить сценарии для восстановления Exchange. Для этой процедуры требуется выполнение команд командной консоли Exchange, которые запускаются вне консоли управления Exchange.
В то время как Exchange Server 2003 Enterprise Edition позволяет организации поддерживать до 20 работающих баз данных Exchange (четыре группы хранения, в каждой из которых до пяти баз данных), в Exchange 2007 Enterprise Edition предусмотрено поддержание до 50 групп хранения, каждая со своей собственной базой данных. Объем журналов транзакций также был сокращен с файлов по 5 МБ в Exchange 2003 до файлов по 1 МБ в Exchange 2007. Оба эти изменения имеют целью поддержку LCR и, дополнительно, кластерной непрерывной репликации (CCR), которая вскоре потребуется.
В небольших организациях и организациях среднего масштаба LCR будет использоваться для улучшения защиты данных при работе с Exchange. LCR легко внедряется, но все-таки требует выполнения некоторых операций вручную. В качестве решения «тот же сервер/локальный диск» LCR является всего лишь первым шагом на пути повышения непрерывности рабочего процесса. Хотя она предназначена для защиты от сбоев массива RAID и контроллеров RAID, одновременное повреждение нескольких дисков или контроллеров RAID возникает не часто. Большей частью в ситуации сбоя отказывает сервер в целом, что приводит нас к следующему шагу в обеспечении защиты Exchange.

Локальная репликация «вне размещения», созданная сторонними разработчиками
Для развития возможностей восстановления после сбоя Exchange, сторонними поставщиками разработаны программные продукты, использующие преимущество репликации «вне размещения», в которой файлы журналов Exchange используются для поддержания резервной копии базы данных Exchange на другом компьютере. В этом случае решение для защиты данных или архивации выполняет полную архивацию ESE для Exchange на другом компьютере, после чего переносит журналы транзакций по мере того, как Exchange их закрывает. Эти транзакции вставляются в копию соответствующей базы данных Exchange для постоянного поддержания их в обновленном состоянии. Как было отмечено, эти журналы имеют относительно небольшой объем (5 МБ в Exchange 2003 и 1 МБ в Exchange 2007), чтобы по завершении полной архивации на сервере Exchange не возникало перегрузки вследствие копирования файлов журналов на сервер вне узла.

УРОВЕНЬ 3: ВОССТАНОВЛЕНИЕ ПОСЛЕ СБОЯ И ВЫСОКАЯ ДОСТУПНОСТЬ
Решение для восстановления после сбоя обеспечивает возврат базы данных в исходное состояние и ее запуск в случае недоступности основного центра данных. Exchange заслуживает эффективного восстановления после сбоя, поскольку в настоящее время функции электронной почти и календаря являются жизненно необходимыми для многих организаций.
Некоторые компании полагают, что их традиционные архивы на лентах, хранящиеся вне организации, являются формой обеспечения восстановления после сбоя, но если ваш единственный центр данных оказывается разрушенным вследствие пожара или наводнения, в фургоне, доставившем бобины лент, мало пользы. Восстановление после сбоя с необходимостью включает в себя не только перемещение данных в другое место, но также технологию и процедуры, обеспечивающие возврат в исходное состояние и запуск приложений. Для обеспечения эффективности восстановления после сбоя оно опирается на разнесение основной и резервной систем на некоторое расстояние. Насколько далеко должны находиться эти площадки, зависит от размера сбоя, который предстоит преодолевать. Если есть основания опасаться пожара, возможно, другое здание в пределах кампуса находится на достаточном расстоянии. Однако инфраструктурные бедствия, связанные с поездами и самолетами, могут иметь последствия в радиусе мили или более. Многие бедствия имеют региональный масштаб: наводнения, ледяные дожди, землетрясения и даже отключения электроэнергии. Линии связи могут переживать свои собственные катастрофы — все что угодно, начиная от экскаватора, перерезавшего линию связи с вашим поставщиком услуг Интернета, до атак типа отказа в обслуживании и DoS-атак из Интернета, ориентированных на торговые операции в целом.
В качестве практичной меры, если в вашей организации уже есть более одной площадки, на которой работают сотрудники отдела ИТ, одно из этих мест могло бы отвечать критериям удаленного непрерывного рабочего процесса исходя из тех типов сбоев, к борьбе с которыми вы готовитесь. Использование своих собственных средств и персонала обойдется гораздо дешевле, чем заключение договора с поставщиком услуг по восстановлению после сбоя или аренда пространства для хранения в новом месте.
В конечном счете, восстановление после сбоя всегда имеет дело с восприятием: необходимо обеспечить клиентам уверенность в том, что ваш бизнес по-прежнему существует. Люди относятся с пониманием к сбоям, затронувшим город или область, но если ваша компания не возвращается в оперативный режим в течение нескольких дней или недели, есть шанс, что клиенты и поставщики будут предполагать худшее; по этой причине потерпели неудачу многие компании. Для клиента ваша деятельность должна выглядеть как находящаяся в режиме восстановления, чтобы клиенты были уверены в том, что ваше предприятие продолжает работать. У клиентов разные представления о своевременном восстановлении: по понятным причинам они менее терпимо относятся к сбоям в компаниях, предоставляющих им финансовые услуги, чем, скажем, в компаниях, поставляющих офисную мебель.

Требования режима восстановления после сбоя
Способность вернуть Exchange в оперативный режим работы после сбоя требует репликации данных на резервную площадку и использования технологии репликации, подготовленной для представления данных включенному серверу Exchange, готовому для их запуска, и последующего уведомления клиентов Outlook о том, что их почтовые ящики перемещены.
С точки зрения репликации Exchange является требовательным приложением, особенно при преодолении больших расстояний. Для подлинно транзакционной базы данных порядок выполнения каждой операции записи является крайне важным. Задача усложняется тем, что Exchange для обмена данными всех транзакций и системными данными между серверами использует в качестве транспортного протокола SMTP, известный протокол, интенсивно использующий полосу пропускания. Более того, в кластерах Exchange импульс синхронизации должен поддерживаться между системами каждые 500 миллисекунд. Если резервный узел не получает импульс синхронизации, он может запустить начало процедуры перехода на другой ресурс.
Сложности решения таких задач, возможно, являются причиной того, что Майкрософт только сейчас начинает работать с Exchange 2007 в этой области. В отсутствие разработок Майкрософт сторонними разработчиками было создано несколько решений для репликации данных Exchange, в которых используется репликация на основе узла или на основе массива.
Поставщики пришли к мысли о том, что можно расширить кластер посредством разнесения узлов в разные места; такой кластер называется растянутым. В настоящее время наиболее распространенным способом реализации растянутых кластеров является использование программных продуктов для репликации данных, созданных сторонними производителями и имеющих общее назначение, либо предназначенных именно для растягивания узла Exchange. Этого можно достичь с помощью MSCS, но в сети WAN сложно выполнять требования, предъявляемые к подсети. Кластеризация и сложности обеспечения надежной широкополосной связи для удаленных центров данных по понятной причине увеличивают стоимость и требования к персоналу, связанные с созданием, поддержанием и периодическим тестированием систем восстановления после сбоя.

Кластерная непрерывная репликация
Корпорация Майкрософт расширяет поддержку кластеров посредством кластерной непрерывной репликации в Exchange 2007. В CCR расширяется способность LCR поддерживать две копии базы данных и журналы транзакций Exchange, чтобы реализовать эту же идею на двух узлах кластера. В процедуре восстановления после сбоя предполагается географическое разделение основной и резервной систем, и кластеры Майкрософт с несколькими копиями (MCC) будут не в состоянии перекрывать значительные расстояния до тех пор, пока Windows Server 2008, ранее носивший кодовое название «Longhorn», не сделает возможным растягивание кластеров.
Технология, позволяющая узлам MCC иметь отдельные копии данных, называется набором узлов большинства (MNS), что напоминает о процедуре выборов, которая приводит к тому, что два или несколько узлов определяют, на котором будет содержаться активная копия данных. При возникновении сбоя оставшиеся узлы проводят новые выборы для определения, который из них станет новым основным сервером обработки/данных. Поддержку этой технической демократии осуществляет CCR, обеспечивающая на каждом узле обновленное состояние базы данных. Кластеры Exchange 2007, использующие CCR, ограничены только двумя узлами.
В крупных магазинах серверы Exchange обычно настраивают локальный системный диск на самом сервере, а затем подключаются к базе данных Exchange по сети SAN, использующей массивы дисков со связью по SCSI, оптоволокону или iSCSI. В отношении кластера MCC/MNS возникает интересный вопрос о том, не пройдет ли новейшее хранилище Exchange обратное развитие к использованию локальных массивов RAID для каждого узла. Если назначением кластера MNS является обеспечение каждого узла своим собственным отдельным хранилищем, будет ли смысл в указании каждого узла для SAN, основным назначением которого является предоставление общего хранилища?
Вероятным вариантом промежуточного развития кластеров MCC/MNS будет наличие основного узла с хранилищем в сети SAN и резервного узла кластеров либо с локальными дисками, либо с меньшей по стоимости сетью SAN на iSCSI. Этот резервный узел может находиться на определенном расстоянии от основного центра данных, в месте, не имеющем инфраструктуры SAN.
Независимо от того, как происходит реорганизация, использование MNS и CCR кластерами MCC является следующей ступенькой в иерархии резервирования и повышенной доступности, поскольку несколько компьютеров могут переходить на резервный ресурс, и данные реплицируются на отдельных элементах хранения. Тем не менее, до момента появления Windows Server 2008 такой подход по-прежнему полностью заключен в рамки единственного центра данных. В Windows Server 2008 будет встроена поддержка растянутых кластеров, позволяющая географически разносить узлы в кластере MNS на любое требуемое расстояние — при условии, что задержка сети между узлами гарантированно не превышает 500 миллисекунд. До тех пор (и потом) технологии кластеров сторонних производителей могут располагаться поверх Microsoft MNS и CCR и обеспечивать географическое разделение, необходимое для растянутых кластеров, чтобы оставаться эффективным решением для восстановления после сбоя.
Кластеризация находится в высшей точке непрерывного множества решений для восстановления после сбоя, и CCR удачно позиционируется в качестве функции, обеспечивающей в Exchange высокую доступность. Несмотря на то, что это сочетание влечет финансовые и трудовые издержки, оно обещает стать замечательным и самым современным решением для клиентов, которым для работы необходима однородная среда Майкрософт.

Непрерывность рабочего процесса в удаленном режиме, обеспечиваемая сторонними производителями
Нет никаких сомнений в том, что решение Майкрософт, когда оно станет доступным, и расширения, созданные сторонними производителями, займут высшее место в непрерывном множестве решений для восстановления. Автоматический переход на другой ресурс в течение секунд — это самое лучшее, что может быть. Тем не менее, такой уровень доступности и непрерывности рабочего процесса требуется не каждой компании, и точно так же не каждая компания может себе позволить вкладывать сотни тысяч долларов, необходимые для достижения этого уровня. Для многих компаний требуемую непрерывность рабочего процесса обеспечит надежное решение, полностью восстанавливающее Exchange в течение минут.
Приведем в качестве пример компанию Mimosa Systems, расширяющую непрерывность рабочего процесса в пределах единственного центра данных до уровня непрерывности удаленного рабочего процесса. Группа восстановления данных компании Mimosa поддерживает на удаленной площадке копию, обеспечивая актуальность ее состояния посредством доставки журналов транзакций с основного сервера Exchange, и всегда готова перевести эту копию в активное состояние, доступное резервному серверу Exchange. Удаленный сервер Exchange использует стандартное серверное оборудование и, в точности как в реализации с единственным центром данных, поддерживает его включенным и всегда готовым к активированию в случае возникновения сбоя. Если случится сбой, оператор на удаленном узле инициирует переход на другой ресурс и выполнит этот переход, выполняя подключение файлов резервной базы данных, повторное подключение почтовых ящиков и профилей Outlook. Тем не менее, следует отметить, что эти решения сторонних разработчиков зависят от ограниченности поддержки, определенной в статье базы данных «Политика Майкрософт по поддержке программных продуктов сторонних производителей, изменяющих или извлекающих содержимое баз данных Exchange».

Заключение
Защита данных Exchange доступна в виде непрерывного множества технологий и процедур, которые можно сгруппировать на трех уровнях, исходя из их стоимости и возможностей. Обдумывая предъявляемые ими требования, необходимые для обеспечения защиты данных Exchange, следует учитывать время простоя, с которым готовы мириться заинтересованные лица. Высокая производительность и быстрота восстановления требуют больших затрат, и для самых современных вариантов эта стоимость выражается шестизначными числами. При этом же подходе существуют более доступные по стоимости решения, но они не достигают самых высоких уровней обеспечения доступности данных. Выбор варианта защиты должен основываться на реальных потребностях организации.
Пакет обновления 1 (SP1) для Exchange 2007
В настоящее время пакет обновления 1 (SP1) для Exchange 2007 находится в процессе бета-тестирования, и в нем запланирован ряд компонентов, которых недоставало администраторам, включая усовершенствования OWA, дополнительные возможности графического интерфейса пользователя для режима консоли и многое другое.
Особенный интерес для администраторов, планирующих использование решений восстановления, представляет включение в Exchange 2007 пакет обновления 1 (SP1) также и третьего решения по обеспечению доступности, дополняющего LCR и CCR: резервная непрерывная репликация (SCR). Это промежуточный подход, и Майкрософт рассматривает его как наиболее благоприятный вариант развития возможностей восстановления, не сопровождаемый сложностями обеспечения полной "высокой доступности."
SCR обеспечивает репликацию базы данных и журналов транзакций Exchange на другой сервер, отличный от сервера, на котором обычно размещаются почтовые ящики. Целевой сервер SCR может быть локальным или удаленным и может быть резервным сервером или кластером Exchange. Однако SCR не требует наличия кластера ни на какой площадке и отличается от CCR тем, что целевой сервер является резервной средой, а обеспечение отказоустойчивости выполняется вручную. Отметим, что по-прежнему сначала необходимо получить большую копию по проводной связи — фактически полную резервную копию. Время от времени может потребоваться выполнение такой обширной репликации, и следует отдавать себе отчет о ее последствиях для сети, так же, как в случае решений CCR и решений сторонних разработчиков. Я надеюсь на широкое распространение как SCR, так и CCR и дополнительных программных продуктов, предоставляющих аналогичные и иногда более существенные возможности.

Ли Бенджамен (Lee Benjamin) управляет компанией ExchangeGuy, предоставляющей консультативные услуги, где он работает в непосредственном контакте с клиентами, и является консультантом в рамках программы Microsoft Partners. Ли является председателем самой большой в мире группы пользователей Exchange, ExchangeServerBoston, и директором компании BostonUserGroups. Кроме этого, Ли имеет звание MVP по Exchange, является сертифицированным преподавателем Майкрософт и регулярно выступает с докладами на отраслевых конференциях.
© 2007 Корпорация Майкрософт и компания CMP Media, LLC. Все права защищены; полное или частичное воспроизведение без разрешения запрещено.


 Связь: Улучшение безопасности при помощи Windows Mobile 6
Связь Мэт Фонтейн (Matt Fontaine)

Улучшение безопасности при помощи Windows Mobile 6
Краткий обзор:
  • Безопасность на устройстве
  • Безопасность Exchange Server
  • Сетевая безопасность

Мобильные устройства увеличивают производительность работников по всему миру, предоставляя доступ к корпоративной информации и обеспечивая доступ к сети, даже если они не находятся
физически в офисе. Улучшения производительности значительные: просто включите мобильное устройство и приступите к работе.
На другой стороне монеты находится сложная работа специалистов отделов ИТ по поддержанию безопасности и стабильности виртуального офиса. С их точки зрения все мобильные устройства являются потенциальными уязвимостями безопасности сети и потенциальными возможностями кражи данных. Создание более надежного развертывания мобильных устройств является критически важным, но оно должно быть сбалансировано с обеспечением беспрепятственной и интуитивно понятной работы пользователей.
Microsoft® Windows Mobile® 6 и ее предшественник Windows Mobile 5.0 с функциональным пакетом «Messaging and Security Feature Pack» (MSFP) включают множество функций обеспечения безопасности корпоративной инфраструктуры, не предоставляя значительных трудностей и какие-либо неудобств для пользователей. Использование Microsoft Exchange Server в качестве платформы управления сообщениями еще более увеличивает количество доступных возможностей обеспечения безопасности. В данной статье я продемонстрирую использование Windows Mobile, Exchange Server и некоторых методик обеспечения безопасности сети в качестве основы защиты мобильных устройств компании.

Архитектура мобильной связи
При планировании или обновлении развертывания мобильных устройств необходимо принимать во внимание три уровня: устройство, сервер сообщений и сеть (см. рис. 1). На уровне устройства ключевые задачи включают обеспечение только авторизованного доступа к устройству и запрет несанкционированного доступа к нему. Windows Mobile помогает предотвратить несанкционированный доступ к самому устройству с помощью ПИН-кода и пароля, блокировке при тайм-ауте устройства и возможности стирания памяти устройства локально или удаленно в случае потери или кражи устройства. Поддерживается шифрование данных канала связи и удаленного хранилища. Кроме того, важно предотвращение установки несанкционированных приложений, таких как вирусы и шпионские программы, или доступа этих приложений к критических частям устройства. Определение роли управления, уровни доступа к приложению, параметры подписывания кода и сертификаты безопасности осуществляют защиту на уровне устройства.
Рис. 1 Уровни мобильной связи
Рис. 1 Уровни мобильной связи
Следующим уровнем безопасности является сервер управления сообщениями, такой как Exchange Server 2003 с пакетом обновления 2 (SP2) или Exchange Server 2007. Этот уровень включает безопасность сообщений, технологию безопасной передачи сообщений с устройства и на него, а также взаимодействие сервера управления сообщениями и мобильного устройства с помощью Exchange ActiveSync®. Exchange Server не является необходимым условием использования устройств Windows Mobile, но он предоставляет преимущества стоимости, масштабируемости, производительности и администрирования.
Верные методики защиты на уровне устройства и сервера управления сообщениями являются ключевым фактором, но слой сети также является критически важным. Настройка корпоративной сети в соответствии с рекомендациями и реализация протоколов с надежной защитой помогают предотвратить повреждение сети даже при компрометации одного или нескольких устройств.

Политики безопасности на устройстве
Первой линий защиты от нарушений безопасности является само устройство Windows Mobile. Операционная система Windows Mobile предоставляет множество служб обеспечения безопасности на уровне устройства, включая проверку подлинности, шифрование карт памяти, виртуальные частные сети (VPN), шифрование Wi-Fi и службы протокола SSL. Безопасность на уровне устройства включает управление данными устройствами и пользователями, имеющими доступ к нему, управление приложениями, которые могут быть запущены на устройстве, и установление способа передачи данных устройством. Как правило, администраторы обладают достаточной гибкостью в настройке и применении политик безопасности Windows Mobile 5.0 с функциональным пакетом MSFP и Windows Mobile 6.
Управление доступом пользователей осуществляется через проверку подлинности с помощью ПИН-кода или пароля. Может быть установлена автоматическая блокировка устройства после определенного периода бездействия или выключения и необходимость последующего разблокирования устройства пользователем для его использования (см. рис. 2). Особенности управления доступом пользователей устанавливаются политиками безопасности, которые могут быть изменены в зависимости от роли безопасности администратора.
Рис. 2 Установка политик пароля
Рис. 2 Установка политик пароля
Политики безопасности определяет глобальные уровни безопасности для мобильного устройства (см. рис. 3). Роли безопасности определяют пользователей, которые могут устанавливать и изменять политики безопасности. Роль «администратор», обычно зарезервированная для мобильных операторов, предоставляет полное управление параметрами политики безопасности. Роль «предприятие» используется Exchange для управления некоторыми политиками устройств, которые настраиваются администратором Exchange. В зависимости от соглашения с поставщиком устройства может быть возможной настройка политик безопасности для вашей компании.
Figure 3 Политики безопасности для мобильных устройств (Close Figure 3)

Политика Мобильное устройство
Блокирование несанкционированного использования устройства

Windows Mobile 5.0 с пакетом возможностей MSFP

Укажите, что пользователь должен всегда выполнять проверку подлинности на устройстве для его разблокировки, или разрешите пользователю ввести ПИН-код на настольной системе.
Роль по умолчанию: администратор, предприятие.

Windows Mobile 6

Разрешите или запретите разрешение пользователя для изменения параметров шифрования съемных носителей.
Роль по умолчанию: администратор, предприятие.
Укажите необходимость проверки подлинности пользователя при подключении устройства при включенной функции блокировки устройства. Роль по умолчанию: администратор, предприятие.
Защита важных данных в случае потери или кражи устройства

Windows Mobile 5.0 с функциональным пакетом MSFP

Укажите, что пользователь должен всегда выполнять проверку подлинности на устройстве для его разблокировки, или разрешите пользователю ввести ПИН-код на настольной системе.
Роль по умолчанию: администратор, предприятие.

Windows Mobile 5.0 с функциональным пакетом MSFP и Windows Mobile 6

Укажите необходимость установки пароля на устройстве. Настройте параметры удаленного или локального стирания памяти устройства.
Роль по умолчанию: администратор, предприятие.
Настраиваемые способы проверки подлинности, используемые Windows Mobile, управляются локальными подключаемыми модулями проверки подлинности (LAP), которые взаимодействуют с локальной подсистемой проверки подлинности (LASS). Это технология позволяет Exchange Server управлять настройкой устройства на детальном уровне, например, устанавливая требования к длине и надежности пароля или простую проверку подлинности с помощью пароля.
Windows Mobile 6 имеет расширенный набор функций LAP, настраиваемых с помощью Exchange Server 2007. Можно включить распознавание шаблонов ПИН-кода (например, запретить использование простых шаблонов, таких как «1111» или «1234»), настроить сроки действия пароля или ПИН-кода, разрешить пользователям выполнять сброс ПИН-кода на основе определенных условий или сохранять историю ПИН-кода/пароля для запрета использования старых ПИН-кодов или паролей при создании новых.

Защита данных на устройствах
В случае ввода неправильного ПИН-кода или пароля количество раз, превышающее установленный администратором предел, функция локального стирания устройства выполняет аппаратный сброс устройства, удаляя его память, включая учетные данные проверки подлинности пользователя. Ограничение числа попыток ввода пароля является частью политик безопасности Exchange Server. После каждых двух неверных попыток ввода устройство запрашивает ввод структурированной ключевой строки для продолжения (см. рис. 4). Это предотвращает случайное стирание памяти устройства из-за нажатия произвольной последовательности клавиш. При использовании Windows Mobile 6 и Exchange Server 2007 также поддерживается удаленное стирание карт памяти.
Рис. 4 Принудительное использование ПИН-кода и пароля
Рис. 4 Принудительное использование ПИН-кода и пароля
Блокировка устройства не является хорошим решением, если пользователь забывает в такси карту памяти объемом 2 ГБ с важными корпоративными данными. К счастью, для решения это проблемы также можно использовать Windows Mobile 6. Можно зашифровать данные на карте памяти, чтобы их могло прочитать только устройство, выполнившее запись этих данных. Как и многие другие улучшенные функции безопасности Windows Mobile 6, Exchange Server 2007 может использоваться для беспроводного предоставления этой функции безопасности. Шифрование карты памяти почти незаметно для пользователя. Exchange Server 2007 позволяет администратору устанавливать возможность изменения пользователями параметров шифрования карты памяти.
Возможность запуска приложений на устройстве Windows Mobile основана на трех уровнях разрешения: «Privileged» (Привилегированный), «Normal» (Обычный) и «Blocked» (Заблокировано). Приложения привилегированного (подписанные сертификатом хранилища привилегированных сертификатов) могут выполнить запись в реестр и системные файлы, а также могут устанавливать сертификаты. Как и с настольными компьютерами или серверами, чем больше приложений могут изменять среду операционной системы, тем больше вероятность компрометации среды. Обычно рекомендуется уменьшение количества приложений с привилегированным доступом. Большинство приложений должно работать только на обычном уровне (приложения, подписанные сертификатом хранилища сертификатов Unpriv, или неподписанные приложения, запуск которых разрешен пользователем), который позволяет их запуск, но ограничивает доступ к системным файлам. Заблокированные приложения не могут быть выполнены из-за неправильного подписывания или запрещения пользователем.
Устройства могут иметь одно- или двухуровневую настройку безопасного доступа. При одноуровневой настройке доступа неподписанные приложения выполняются с привилегированным доступом или блокируется, и их запуск невозможен. При двухуровневой настройке доступа неподписанные приложения запускаются на обычном уровне при успешной проверке политикой или разрешении запуска приложения пользователем. В зависимости от параметров устройства может появиться запрос на выполнение неподписанного приложения.
Цифровые сертификаты, одна из самых распространенных форм проверки подлинности пользователей, устройств и приложений, являются важной частью безопасности Windows Mobile на уровнях устройства, сервера и сети. Операционная система Windows Mobile сохраняет несколько типов сертификатов в различных хранилищах сертификатов на устройстве. Независимо от приложений сертификаты определяют приложения, установка и запуск которых возможны. Приложение, которое может быть запущено на устройстве Windows Mobile без запроса пользователя, должно быть подписано сертификатом, принятым программой Microsoft Mobile2Mobile. Приложениям предоставляются уровни разрешения на основе сертификатов приложений.
Для проверки подлинности сети все устройства поставляются с рядом доверенных коммерческих корневых сертификатов, выпущенных центром сертификации, как показано на рис. 5. Сервер обмена сообщениями (например, Exchange Server) проверяет подлинность корневого сертификата устройства до установления подключения SSL с этим устройством. При использовании в вашей компании настраиваемых сертификатов их можно установить на приобретенных устройствах Windows Mobile или необходимо создать новые сертификаты. Я рассмотрю это позже в разделе «Сетевая безопасность» данной статьи.
Рис. 5 Управление цифровыми сертификатами
Рис. 5 Управление цифровыми сертификатами
ActiveSync и Internet Explorer® Mobile могут использовать SSL для защиты передачи данных между устройством и корпоративным веб-сервером. Это является верным при наличии подключения для синхронизации данных Microsoft Exchange, настройки устройства или загрузки приложений. SSL выполняет шифрование канала связи с помощью 128-разрядных шифров RC4 или 3DES, чтобы данные не могли быть прочитаны третьими лицами. Windows Mobile также поддерживает VPN, которая использует шифрование пакетов для обеспечения безопасности, сходной с безопасностью выделенной линии при доступе к серверу через Интернет.

Безопасность Exchange Server
Хотя для работы устройств Windows Mobile не требуется Exchange Server, эти две системы предназначены для совместной работы и представляют надежное законченное решение работы и обмена мобильными сообщениями. С выпуском Windows Mobile 5.0 с функциональным пакетом MSFP служба ActiveSync была улучшена и допускает удаленное управление параметрами устройств Windows Mobile. Она предоставляет простые и довольно мощные средства распространения и применения глобальных параметров безопасности на большинстве устройств Windows Mobile.
ActiveSync работает в IIS, компоненте приложения/веб-сервера Microsoft Windows Server 2003. IIS обеспечивает встроенную безопасность, помогающую обеспечить защиту ActiveSync от атак через сеть. Поскольку веб-клиент Microsoft Office Outlook® также основан на IIS, можно использовать одни и те же сертификаты безопасности для ActiveSync и веб-клиента Outlook.
При использовании ActiveSync для распространения политики предприятия эта политика предоставляется устройствам при их следующей синхронизации с Exchange Server. Для возможности подключения к серверу пользователи должны принять изменения. Множество сетей состоят из различного ряда устройств, включая устаревшее оборудование, которое не может принимать сложные политики безопасности. При необходимости можно исключить из требования политики безопасности определенные устройства, например, устаревшее оборудование, для обеспечения возможности их подключения.
Exchange Server 2003 с пакетом обновления 2 (SP2) и Exchange Server 2007 имеет немного другие возможности управления политикой безопасности. Exchange Server 2003 с пакетом обновления 2 (SP2) может использоваться для указания минимальной длины пароля от 4 до 18 символов, необходимости использования в пароле букв и цифр, а также периода бездействия до блокировки устройства. Данная версия Exchange Server также позволяет устанавливать частоту передачи на устройства параметров безопасности, а также разрешает упомянутые выше исключения устаревших устройств.
В выпуске Exchange Server 2007 возможности управления мобильными устройствами ActiveSync были улучшены и включают все возможности Exchange Server 2003 с пакетом обновления 2 (SP2), а также следующие.
  • Разрешение или запрет простых паролей (таких как «1234» или «1111»)
  • Включение или отключение загрузки вложений
  • Необходимость шифрования карты памяти
  • Установка максимального размера вложения
  • Включение восстановления пароля устройства пользователем с помощью OWA
  • Включение доступа к файлам с универсальными именами (UNC) и Microsoft Windows SharePoint® Services (WSS)
При помощи Exchange Server 2007 специалисты отделов ИТ имеют возможность адаптировать политики к каждому пользователю или устройству, управлять политиками для групп пользователей, а также исключать отдельных пользователей из сферы действия политик безопасности вообще.

Стирание при помощи удаленного доступа
Кроме описанного выше локального стирания данных устройства можно стереть память устройства Windows Mobile удаленно с помощью Exchange Server 2003 с пакетом обновления 2 (SP2), Exchange Server 2007 или OWA. Удаленное стирание, выполняющееся при синхронизации, может быть осуществлено, даже если политики безопасности ActiveSync не используются. Удаленный аппаратный сброс со стиранием не может быть остановлен на устройстве. Данные, параметры и ключи безопасности переписываются повторяющимися нулями, что чрезвычайно затрудняет восстановление данных, не являющихся частью основных файлов операционной системы.

Сетевая безопасность
Безопасность сети является настолько же важной для мобильной безопасности, как и компоненты устройства и сервера сообщений. Она также является частью мобильной инфраструктуры, которой вы можете управлять наиболее ясно. Даже при компрометации одного или нескольких мобильных устройств настройка корпоративной сети в соответствие с рекомендациями и внедрение верных протоколов безопасности может предотвратить повреждение сети.
Windows Mobile хорошо работает с различными типами сетей. Используя стандартные брандмауэры и протоколы безопасности Интернета, можно спроектировать решение, соответствующее вашим требованиям к производительности, стабильности и безопасности.
При нахождении серверов сообщений в корпоративной сети они могут быть защищены пограничным брандмауэром, выступающим в качестве буфера между Интернетом и корпоративными серверами. Microsoft Internet Security and Acceleration (ISA) Server 2004 или ISA Server 2006, имеющие функции, предназначенные специально для этого, проверяют все входящие пакеты для определения их идентификационных данных перед их пересылкой серверам Exchange, а затем отправляют исходящую информацию обратно клиентам через Интернет.
Для настройки ISA Server требуется включить шифрование SSL и назначить порт 443 в качестве прослушивающего веб-порта SSL для трафика Exchange Server. Это минимизирует воздействие Интернета, ограничивая его одним портом. Кроме того, перед подключением через ActiveSync все клиенты должны установить подключение SSL.
ISA Server может выполнять предварительную проверку подлинности веб-приложений, таких как OWA, для предотвращения несанкционированного доступа к серверам приложений. В ISA Server 2006 режим моста SSL из ISA Server 2004 улучшен возможностью работы в качестве точки терминации SSL для устройств Windows Mobile. Это позволяет устройствам Windows Mobile выполнять проверку подлинности на сервере Exchange без прямого подключения к нему, вместо этого ISA Server 2006 передает трафик в обоих направлениях. А поскольку рекомендованным расположением ISA Server 2006 является демилитаризованная зона, это допускает дополнительный слой безопасности между общественным Интернетом и клиентским интерфейсом Exchange Server.

Проверка подлинности
Выбор осуществляется из двух основных типов проверки подлинности: обычной и на основе сертификатов. Обычная проверка подлинности – это стандартное подключение на основе SSL с проверкой имени и пароля между клиентом Windows Mobile и сервером клиентского доступа Exchange. Для нее требуется сертификат, поскольку Exchange Server до проверки подлинности выполняет поиск соответствующего корневого сертификата на устройстве. Windows Mobile и IIS позволяют использовать широкий ряд методов шифрования, связанных с SSL.
Проверка подлинности на основе сертификата, доступная в Windows Mobile 5.0 с функциональным пакетом MSFP и Windows Mobile 6, использует протокол TLS, а не обычную проверку подлинности SSL. Кроме корневого сертификата, для TLS требуется, чтобы у каждого пользователя был сертификат с открытым и секретным ключами. Поскольку TLS вместо пароля использует ключ шифрования (до 2 048 бит), данный протокол обеспечивает более надежную проверку подлинности.
При использовании Windows Mobile 6 для регистрации пользовательского сертификата с помощью настольной регистрации необходимо, чтобы устройство было подключено к настольной системе, находящейся в том же домене, что и сервер регистрации сертификатов. Пользователь проверяет подлинности заявки с помощью пароля, смарт-карты или другого способа, а затем подключает устройство к настольному компьютеру. Затем пользователь осуществляет доступ к системе сертификатов с настольной системы, которая в свою очередь устанавливает сертификат на мобильном устройстве. Настольная регистрация служит для различных целей безопасности Windows Mobile, включая обновление сертификатов, а также распространение сертификатов проверки подлинности ActiveSync, сертификатов проверки подлинности SSL/TLS, сертификатов 802.1x Wi-Fi или цифровых подписанных сертификатов S/MIME.
Протоколы безопасности, такие как SSL, защищают данные во время их передачи, но не выполняют их шифрование после передачи на устройство Windows Mobile или сервер Exchange. S/MIME – это безопасная форма известного стандарта электронной почты MIME, который поддерживает подписанную цифровым путем и/или зашифрованную электронную почту. Это обеспечивает дополнительный слой защиты помимо шифрования уровня транспорта SSL.

Краткое заключение
Для создания достаточно безопасной инфраструктуры необходимо уделить внимание каждому из множества слоев, составляющих решение. Windows Mobile, Exchange Server и продукты сетевой безопасности Microsoft, например ISA Server, предназначены для совместного использования для устранения множества трудностей, связанных с управлением мобильной инфраструктурой. Это упрощает работу подразделений ИТ, позволяя им заниматься не проблемами безопасности мобильных устройств, а повышением производительности.

Особую благодарность выражаю Кэти Эссер (Kathy Esser), Катрин Холдсворт (Katharine Holdsworth), Саре Нортон (Sarah Norton) и Чипу Воллерсу (Chip Vollers) за их помощь в создании данной статьи.

Мэт Фонтейн (Matt Fontaine) - разработчик технологической документации компании BuzzBee Company.


 Связь: Серьезная альтернатива общим папкам
Связь Алан Мэдисон (Alan Maddison)

Серьезная альтернатива общим папкам
Краткий обзор:
  • Предоставление общего доступа к календарям и контактам
  • Осуществление связи с блогами и вики-страницами
  • Управление документами и предоставление общего доступа

Общие папки были введены с появлением первой версии Microsoft Exchange с целью предоставления основной платформы для общего доступа к документам, архивации списка рассылки и разработки пользовательских приложений. Почти с самого
начала администраторы испытывали проблемы с управлением и использованием того, что стало частью сред Exchange с постоянно растущим уровнем сложности. Хотя Exchange Server 2007 и внес значительные улучшения в управление общими папками, проблемы остались. Общие папки просто не могут обеспечить надежную совместную работу и платформу для управления документами, которые нужны сегодняшним предприятиям.
Майкрософт заявил, что Exchange Server 2007, возможно, станет последней версией продукта, поддерживающего общие папки. Хотя они все еще полностью поддерживаются и будут продолжать поддерживаться еще 10 лет после запуска Exchange Server 2007, настало подходящее время для поиска альтернативы.
К счастью Майкрософт предложил великолепное решение, выпустив Microsoft® Office SharePoint® Server (MOSS) 2007. MOSS 2007 предлагает администраторам отделов ИТ и предпринимателям платформу, которая заменит общие папки и поможет продвинуться вперед. В этой статье я продемонстрирую мощную и надежную структуру MOSS, предлагающую гораздо больше возможностей, чем общие папки Exchange. В частности, я подробно остановлюсь на использовании SharePoint для тех задач, для которых обычно используются общие папки, – таких как общий доступ к календарям, контактам и документам.
Учтите, что вам понадобятся общие папки до тех пор, пока вы хотя бы не произведете обновление ваших клиентов. Клиенты Microsoft Outlook® от Outlook 97 до Outlook 2003 требуют наличия общих папок по нескольким причинам, включая автономную адресную книгу, библиотеку организационных форм и поиск сведений о доступности. Как только вы перейдете на Outlook 2007 и Exchange Server 2007, вы можете сразу прекратить использование общих папок, как только будете готовы.

Календари SharePoint
Общие календари – это обычное применение для общих папок, а SharePoint облегчит замену календаря общей папки на календарь SharePoint. Хотя при установке по умолчанию SharePoint включает в себя календарь, вам, вероятно, понадобится создать несколько календарей для нужд вашей организации. В целях демонстрации я покажу вам, как создается общий календарь для группы отдела кадров. Первый шаг – выбрать Просмотр всего содержимого узла – обычно это показано в левом верхнем углу веб-узла SharePoint (см. рис. 1).
Рис. 1 Создание нового содержимого веб-узла
Рис. 1 Создание нового содержимого веб-узла
После выбора варианта «Просмотреть все содержимое веб-узла» нажмите кнопку «Создать» (которая также показана на рис. 1). После загрузки страницы создания вы увидите стандартные типы публикации содержимого (как показано на Рисунке 2). Для создания календаря вы должны выбрать «Календарь» в колонке отслеживания. Затем вы должны заполнить поля названия и описания, а также указать, будете ли вы включать календарь в раздел быстрых переходов.
Рис. 2 На странице создания имеется множество стандартных функций.
Рис. 2 На странице создания имеется множество стандартных функций.
Итак, календарь создан. Пользователь может просматривать общий календарь либо при помощи узла SharePoint, либо непосредственно в Outlook. Для второго варианта пользователю необходимо подключиться к календарю при помощи веб-обозревателя, затем открыть меню действий и выбрать пункт «Подключиться к Outlook».
При первом подключении Outlook покажет предупреждение безопасности, чтобы напомнить пользователям о том, что они должны подключаться только к известным и надежным источникам. После выбора «Да» календарь будет подключен к Outlook. НаРисунке 3 показан вид по умолчанию, который располагает календари SharePoint и Outlook рядом друг с другом.
Рис. 3 Отображение календарей SharePoint и Outlook рядом друг с другом
Рис. 3 Отображение календарей SharePoint и Outlook рядом друг с другом
После подключения календаря к Outlook может произойти двухсторонняя синхронизация. Любые события, введенные через Outlook, синхронизируются с SharePoint, и все пользователи, просматривающие календарь, увидят обновленные записи. Кроме того, если вы включили поддержку SMTP в SharePoint, события можно напрямую отправить в календарь по электронной почте, и SharePoint сам добавит эти записи.

Контакты SharePoint
Общие контакты, которые также основаны на общих папках, используются во многих организациях. В этом случае также SharePoint предлагает более надежную альтернативу, упрощая создание и управление списками контактов. Продолжая использовать тот же пример, я покажу, как создать общий список контактов для отдела кадров.
Еще раз выберите «Просмотреть все содержимое веб-узла» и нажмите кнопку «Создать». Теперь выберите «Контакты» в колонке «Связь». На появившемся экране вам необходимо указать имя, описание и настройку быстрого перехода (см. рис. 4). После ввода этой информации просто нажмите кнопку «Создать», и новый список контактов создан.
Рис. 4 Ввод имени, описания и настройки быстрого перехода
Рис. 4 Ввод имени, описания и настройки быстрого перехода

Взаимодействие с пользователями
Вы можете использовать SharePoint для создания доски обсуждений (также известной, как список обсуждений). Как и в случае с календарями и контактами, процесс создания весьма прост – выберите «Просмотреть все содержимое веб-узла», нажмите кнопку «Создать» и выберите «Доска обсуждений» в колонке «Связь». Так же, как и до этого, введите необходимую информацию об имени, описании и настройке быстрого перехода, а затем нажмите кнопку «Создать». НаРисунке 5 показана доска обсуждения с образцами сообщений.
Рис. 5 Пример доски обсуждений с несколькими сообщениями
Рис. 5 Пример доски обсуждений с несколькими сообщениями
Дополнительно к доске обсуждений SharePoint Server теперь поддерживает два очень популярных средства обмена информацией – блоги и вики-страницы. Блоги и вики-страницы, не работающие с общими папками, являются нововведением SharePoint Server 2007 и предоставляют интересные и увлекательные возможности для совместной работы.
Блоки представляют собой интерактивный форум, на котором автор блога может свободно обмениваться мыслями и идеями, публикуя их на веб-узле. Обычно эти сообщения разбиваются на категории, чтобы читателям было легче найти интересующие их сообщения. Тем временем читатели могут оставлять ответы на сообщения автора блога. Например, в компании блог может вестись управляющими старшего звена. Это может быть хорошим средством для общения со служащими, дающим возможность работникам делиться идеями и поддерживать связь на всех уровнях.
Создание блога в SharePoint – это просто. Сначала выберите «Просмотреть все содержимое веб-узла», затем нажмите кнопку «Создать», а потом выберите «Узлы и рабочие области» в колонке веб-страниц. Вы будете перенаправлены на новую страницу узла SharePoint, где необходимо будет ввести имя, название и адрес веб-узла. Затем нужно выбрать шаблон для веб-узла – в этом случае вы выбираете шаблон блога. Последние три пункта настройки включают разрешения, перемещение и список каталогов веб-узла. После заполнения всех необходимых полей нажмите кнопку «Создать». Таким образом, вы создаете дочерний узел в рамках вашего веб-узла, а в рамках дочернего узла будут находиться библиотеки и списки, предоставляющие возможности работы с блогом. После завершения процесса вы перейдете к новому блогу.
Вики-страницы – это еще один отличный инструмент, созданный для еще более расширенной совместной работы. Пользователи могут добавлять, удалять и править содержание этого узла, а также соединять неограниченное количество страниц. Самый простой способ создать вики-страницу – выбрать «Просмотреть все содержимое веб-узла», нажать ссылку «Создать», а затем выбрать «Библиотека вики-страниц», которая есть в списке в колонке «Библиотеки». После того, как вы заполните поля имени, описания и настройки перемещения, нажмите кнопку «Создать», чтобы закончить процесс. Дополнительные сведения об использовании вики-страниц в SharePoint можно найти в статье "Работайте с вики во время работы" в январском выпуске 2007 года журнала TechNet Magazine.

Библиотеки SharePoint
Общие папки стали фактически центральными хранилищами документов, в которые пользователь может войти и получить доступ к общим документам. По многолетним наблюдениям администраторов Exchange, это одно из основных применений, сделавших общие папки такими громоздкими. Оно не только увеличивает количество операций ввода-вывода Exchange для базы данных общих папок, но и отражается на репликации всей инфраструктуры Exchange. Библиотеки SharePoint предлагают великолепную альтернативу, снижая нагрузку на Exchange и его ресурсы.
Библиотека SharePoint – это место в рамках веб-узла SharePoint, которое позволяет вам хранить файлы и управлять ими. Есть несколько типов библиотек, включая изображения, вики-страницы, формы и документы. Если необходимо заменить общие папки, то наилучшим выбором будет являться библиотека документов. Библиотека документов поддерживает хранение, управление и, в некоторых случаях, создание документов в рамках веб-узла SharePoint.
В библиотеке документов можно хранить различные типы файлов, но определенные типы файлов – такие, как исполнимые файлы и сценарии – ограничены для хранения по причинам безопасности. Эти ограничения, тем не менее, можно настраивать в разделе «Выполняемые операции» на центральном административном узле SharePoint.
В состав установки MOSS по умолчанию входит настраиваемая библиотека документов. Большинству организаций будет необходимо создать множество библиотек для поддержания различных направлений деятельности в рамках одной организации. Это легко сделать при помощи средств, предоставляемых SharePoint. Например, для развертывания библиотеки документов для отдела кадров выберите «Просмотреть все содержимое веб-узла», нажмите ссылку «Создать», затем выберите библиотеку документов, которая есть в списке в колонке «Библиотеки». Далее вам необходимо настроить ряд параметров – ввести имя и описание библиотеки, определить необходимость включения библиотеки в раздел быстрых переходов и необходимость включения контроля версий, а также выбрать формат по умолчанию для новых документов, создаваемых непосредственно в библиотеке.
Обратите особое внимание на функцию «Журнал версий документа». По умолчанию эта функция отключена. Однако во многих обстоятельствах контроль версий будет полезен и приемлем. Помимо хранения журнальных копий документов, эта функция позволяет отслеживать, когда и кем были произведены изменения, а также просматривать и восстанавливать более ранние версии.
Нарис. 6 показана новая библиотека документов с несколькими загруженными документами. После создания библиотек документов можно открыть доступ к этим хранилищам через Microsoft Outlook и проводник Windows®. Outlook позволяет вам изучать содержание библиотеки документов в автономном режиме и предоставляет копии «только для чтения» пользователям, у которых нет доступа к сети. При предоставлении доступа через проводник Windows используются преимущества сетевого окружения. Если вы введете адрес библиотеки документов, вы предоставите вашим пользователям доступ. При работе с большими средами вы, возможно, захотите воспользоваться групповой политикой для развертывания сетевого окружения.
Рис. 6 Библиотека документов, содержащая несколько загруженных документов
Рис. 6 Библиотека документов, содержащая несколько загруженных документов

Некоторые особенности
SharePoint предоставляет возможности, которые явно превосходят все, что предлагают общие папки. Помимо предоставления обычных возможностей, которые можно получить при работе с общими папками, SharePoint Server также дает возможности, которые могут значительно расширить известные рамки. В число этих улучшенных возможностей входят следующие:
  • Журнал версии
  • Управление одобрением
  • Процедуры взятия документа для изменения
  • Управление рабочим потоком
  • Политики сохранения документов
  • Аудит
  • RSS
Эти функции необходимы для любой платформы управления информационным содержимым предприятия, и SharePoint предоставляет надежную структуру, которую с легкостью могут использовать администраторы. Эти улучшенные возможности можно задействовать в большинстве функций SharePoint, включая календари, задания, доски обсуждений и библиотеки документов.
Для настройки этих функций выберите меню «Параметры», а затем выберите вариант параметров – например, параметры библиотеки документов, как показано на рис. 7. Вы перейдете на страницу параметров, где сможете просмотреть все доступные варианты настройки и индивидуализации. Проверка версий в колонке общих параметров позволит вам настраивать журнал версий.
Рис. 7 Выбор параметров для настройки усовершенствованных функций
Рис. 7 Выбор параметров для настройки усовершенствованных функций
Как я упоминал ранее, эта функция предоставляет протокол внесенных в документ изменений, в том числе какие изменения были сделаны, кем и когда, а также позволяет пользователю просматривать и при необходимости восстанавливать более ранние версии. Кроме того, можно контролировать количество версий, которые сохраняет SharePoint. При превышении лимита объекты будут удаляться без предварительной отправки в корзину SharePoint.
Раздел управления версиями также позволяет настраивать нужные требования для одобрения содержимого и взятия для изменения. При включении одобрения содержимого любой объект должен быть одобрен прежде, чем он станет доступен другим пользователям. Объекты, не получившие одобрения, остаются в состоянии ожидания. Процесс взятия для изменения обеспечивает контроль содержимого, запрещая нескольким пользователям работать одновременно с одним файлом.
Рабочие потоки – это еще одна из полезных функций SharePoint, недоступных общим папкам. Грубо говоря, рабочие потоки предлагают структурный подход к процессу деятельности, который поможет улучшить работу вашей компании. Встроенные в SharePoint рабочие потоки являются набором заранее определенных заданий, автоматизирующих передвижение документа во время определенного процесса. Процесс может носить итеративный характер, при котором каждый этап должен быть закончен перед переходом к следующему этапу, или параллельный, при котором любые задания могут выполняться одновременно. В число рабочих потоков, поставляемых по умолчанию в комплекте со SharePoint, входят:
  • Одобрение
  • Сбор отзывов
  • Сбор подписей
  • Одобрение расположения
Политики управления информацией используются для обеспечения соответствия нормативным требованиям и требованиям бизнеса. Политика состоит из набора правил, относящихся к управлению документами. SharePoint Server поддерживает пользовательские правила, но также включает некоторые полезные стандартные правила, такие как:
  • Аудит
  • Истечение срока действия
  • Ярлыки
  • Штрих-коды
Аудит дает возможность протоколировать события на основе набора операций, которые вы определяете в числе параметров веб-узла. Можно отслеживать такие операции, как открытие документа, загрузка или просмотр объекта или его свойств, правка документа, взятие документа для изменения или возврат после изменения, перемещение или копирование объектов, а также удаление и восстановление объектов.
Истечение срока действия содержания позволяет вам удалять содержание, чтобы соответствовать политике сохранения данных вашей организации. Истечение срока действия может произойти в определенный день или по истечении определенного периода времени после начала какого-либо события, например, создания документа.
Ярлыки используются в связи с печатью и добавлением текста в цифровые или бумажные копии. На практике у этой политики есть несколько применений. Например, можно сделать запрос на то, чтобы все документы из общей библиотеки документов отдела кадров имели отметку о конфиденциальности для соответствия правилам вашего юридического отдела.
Штрих-коды являются формальным методом отслеживания документов как в электронном, так и в бумажном виде. SharePoint создает уникальный идентификатор для каждого документа, а пользователи затем могут вставить изображение штрих-кода в свой документ.
Еще одним важным улучшением, предлагаемым SharePoint, является интеграция с каналами RSS. Календари, контакты, библиотеки документов и доски обсуждений имеют свои каналы RSS, на которые пользователь может подписаться. Ваши пользователи могут получать автоматические новости, которые помогут им в их повседневной деятельности, и для этого необходима всего лишь программа для чтения RSS, такая как Outlook 2007.

Заключение
Microsoft Office SharePoint Server 2007 предлагает предприятиям набор функций, являющихся серьезной альтернативой общим папкам Exchange. Надежная административная структура облегчает внедрение решений для предоставления общего доступа к календарям, спискам контактов и документам. Кроме того, можно создавать различные виды взаимодействия, включая форумы обсуждения, блоги и вики-страницы.

Алан Мэдисон (Alan Maddison) – старший консультант по технологической практике Майкрософт в корпорации MTI Technology Corporation. Его основной специализацией являются Active Directory, Exchange Server и виртуализация.


 Связь: Вход в Outlook Web Access при помощи смарт-карт
Связь Виктор Акиннагби and Тед Дрессел and Джейсон Опдайк

Вход в Outlook Web Access при помощи смарт-карт
Краткий обзор:
  • Двухфакторная проверка подлинности
  • Ограниченное делегирование Kerberos
  • Настройка ISA Server и Exchange

Мобильные служащие создают для отделов ИТ особенные проблемы в плане безопасности. Удаленным пользователям необходим безопасный доступ к данным и службам, таким как электронная почта. К сожалению, самым
слабым звеном в цепи безопасности являются слабые пароли, вредоносное программное обеспечение (например, программы для кражи паролей) и вирусы, находящиеся на удаленных компьютерах, которые получают доступ к внутренним ресурсам вашей организации.
Одним из путей усиления безопасности в этой мобильной среде является удаление одного из этих слабых звеньев: паролей (хотя идея предоставления доступа без пароля, проверяющего подлинность, может показаться небезопасной). Основной метод для решения этих проблем, связанных с паролями, известен как двухфакторная проверка подлинности (или иногда как многофакторная проверка подлинности). Вместо того чтобы полагаться на единственный метод – пароль – для предоставления доступа, двухфакторная проверка подлинности подключает дополнительные методы проверки подлинности, включающие сочетание имени пользователя/пароля, физического устройства, например, смарт-карты, и биометрического идентификатора, такого как отпечаток пальца.
Если у вас есть удаленные пользователи, то обычно вам нужно чуть снизить уровень защиты вашего брандмауэра, чтобы разрешить удаленный доступ к вашей корпоративной сети. Стандартный брандмауэр предоставляет вам основные режимы снижения рисков при помощи изоляции на сетевом уровне между внутренними и внешними сетями (см. рис. 1). Для обеспечения дополнительной безопасности происходит закрытие портов, а если необходима связь с устройством во внутренней сети, порты переадресовываются в правильное место. Эти методы обеспечивают достаточную защиту на сетевом уровне, но вследствие появления все более изощренных атак сегодня необходимо применять многоуровневые методы сетевой безопасности.
Рис. 1 Стандартный брандмауэр с заблокированными или переадресованными портами
Рис. 1 Стандартный брандмауэр с заблокированными или переадресованными портами
Поскольку наиболее часто используемыми мобильными служащими корпоративными службами являются электронная почта и обмен сообщениями, безопасная настройка вашей инфраструктуры Exchange становится все более важным делом. Предоставление вашим пользователям доступа через Outlook® Web Access (OWA) – это один из способов безопасной работы со службами для ваших мобильных служащих. Еще одним важным шагом является обеспечение двухфакторной проверки подлинности для OWA при помощи смарт-карт. В этой статье мы подробно рассмотрим вопросы настройки и установки, в которых вы должны разбираться при развертывании вашей системы проверки подлинности для OWA при помощи смарт-карт.

Лучше, чем брандмауэр
Использование Microsoft® Internet Security and Acceleration (ISA) Server 2006 в вашей сети может упростить задачу более безопасного открытия вашей сети для удаленных пользователей. ISA Server 2006 обладает функциями, улучшающими безопасность, такими как вход в виртуальные частные сети (VNP) при помощи смарт-карт, проверка подлинности по протоколу LDAP для Active Directory®, а также ограниченное делегирование Kerberos. ISA Server слегка отличается от того, как вы традиционно представляете себе брандмауэр. Он обеспечивает множество уровней безопасности не только потому, что функционирует на сетевом уровне – и может делать это в сочетании со стандартным брандмауэром или вместо него – но и потому, что включает в себя дополнительные функции безопасности, которыми обычно не располагают традиционные брандмауэры, например, фильтры приложений. Не хотите, чтобы кто-либо использовал метод HTTP POST на конкретном размещенном веб-узле? Нужно обеспечить соответствие нормативам RFC всех сообщений SMTP перед тем, как они попадут на ваш сервер Exchange? Хотите просмотреть зашифрованные в протоколе Secure Sockets Layer (SSL) пакеты HTTP до того, как они попадут в сеть? ISA Server может выполнить все эти задачи и сделать так, чтобы только чистый и фильтрованный трафик перенаправлялся в вашу DMZ или внутреннюю сеть.
Для стандартных брандмауэров сеансы SSL всегда являются некоторой проблемой. По мере прохождения пакетов через брандмауэр они остаются зашифрованными (что означает, что SSL работает правильно). Таким образом, если приложение, например, OWA, публикуется через аппаратный или программный брандмауэр при помощи SSL, стандартный брандмауэр не сможет провести практически никакой проверки, кроме проверки с сохранением состояния пакета. Простое открытие и переадресация портов оставляет большую поверхность для атаки. Поскольку на границе сети не проводится тщательной проверки, пакеты без проверки подлинности могут быть направлены в вашу внутреннюю сеть.
ISA Server 2006 может выступать в качестве конечной точки SSL для клиентов HTTP, обеспечивая выход на опубликованный сервер Exchange только для трафика, прошедшего проверку подлинности. ISA Server поддерживает такую полезную функцию, как режим моста SSL. Обычно пакет шифруется клиентом, который связывается с сервером ISA при помощи стандартного сеанса SSL. При помощи моста SSL ISA Server может отменить шифрование SSL на локальном уровне, проверить незашифрованный пакет, определить пользователя для Active Directory (если нужно), вновь зашифровать пакет при помощи SSL и отправить зашифрованный пакет на соответствующий сервер Exchange (см. рис. 2). Используя этот прием, мост SSL защищается от атак, скрытых в сеансе SSL и могущих выглядеть как просто зашифрованные фрагменты данных для брандмауэра, в котором отсутствует защита на уровне приложения.
Рис. 2 ISA Server рассматривает трафик на уровне приложения
Рис. 2 ISA Server рассматривает трафик на уровне приложения
Попадание на сервер трафика, подлинность которого предварительно проверена, – это важный аспект, который необходимо отметить при упоминании ограниченного делегирования Kerberos. В стандартном брандмауэре порты просто переадресовываются на сервер Exchange, а сервер первого уровня сам несет ответственность за проверку подлинности тех, кто может считаться пользователем-злоумышленником. Когда требуется проверка подлинности, ISA Server может напрямую связаться с Active Directory и сделать запрос на учетные данные от лица самого пользователя. Если подлинность пользователя проверена, ISA Server переадресует сообщение на сервер клиентского доступа Exchange. Серверу клиентского доступа больше не нужно устанавливать подлинность случайных запросов неизвестных пользователей, следовательно, его можно использовать только для формирования запросов на серверы, работающие непосредственно с базой данных. Кроме того, ISA Server 2006 может использовать ограниченное делегирование Kerberos для предоставления доступа на основе сертификатов к таким технологиям, как Windows SharePoint Services и Exchange ActiveSync.
Exchange Server 2003 поддерживает проверку подлинности Kerberos между серверами клиентского доступа и баз данных для входов в сеть с помощью OWA. (Вы ведь используете IPsec для защиты клиентского трафика?) Exchange Server также поддерживает проверку подлинности Kerberos для кластеризованных почтовых серверов.

Включение проверки подлинности по смарт-картам
Реализация проверки подлинности для OWA на основе смарт-карт было непростой задачей. Однако решение было найдено на основе функции ограниченного делегирования Kerberos, которая сейчас доступна в ISA Server 2006. Это решение позволяет пользователю передавать учетные данные через сертификат, чтобы успешно пройти проверку на подлинность для OWA. Ограниченное делегирование Kerberos явилось долгожданным улучшением поддержки делегирования Kerberos в Windows® 2000, которая использовала неограниченное делегирование. Ограниченное делегирование Kerberos более безопасно и ограничивает возможный риск изощренных атак, использующих олицетворение.
В ситуации, когда смарт-карты включены, ISA Server 2006 связывается с Active Directory для проверки подлинности пользователя, поскольку у пользователя нет маршрутизируемого доступа к центру распределения ключей (KDC) из внешней сети. ISA Server проводит сопоставление сертифицированного пользователя в Active Directory для проверки его подлинности, а затем принимает соответствующие билеты Kerberos на основе имени пользователя-участника (UPN). В этом случае ISA Server предоставляет функциональность ограниченного делегирования Kerberos серверу клиентского доступа Exchange через фильтрацию на уровне приложения и служб обратных прокси. Если делегирование предпринимается без служб обратных прокси, повышенный риск использования уязвимостей может повлиять на целостность сети или домена Active Directory.
И Exchange Server 2003, и Exchange Server 2007 позволяют проводить и базовую, и объединенную проверки подлинности. Однако вам необходимо установить обновление программного обеспечения для Exchange Server 2003, чтобы вы могли использовать проверку подлинности при помощи смарт-карт для OWA. (Для получения дополнительных сведений см. статью "Описание новой функции Exchange Server 2003, поддерживающей проверку подлинности при помощи смарт-карт для доступа к Outlook Web Access".) У вас должен быть домен в основном функциональном режиме Windows Server® 2003, все задействованные серверы Exchange Server 2003 должны иметь SP2 или более позднюю версию, а также вам понадобится сервер ISA Server 2006 в качестве обратного прокси для узла OWA.
После того, как вы установите программное обновление и произведете настройку ваших серверов ISA и Exchange, пользователи смогут проходить проверку подлинности для сеанса OWA, используя смарт-карты. Нарис. 3 показан поток событий, требуемый для проверки подлинности при помощи смарт-карт. Пользователь начинает процедуру с открытия узла OWA в Internet Explorer® (1). Фактически пользователь подключается к ISA Server, получает запрос на сертификат, а не на имя пользователя и пароль, чтобы начать сеанс OWA. Соответствующий сертификат хранится на смарт-карте, для которой пользователю потребуется ПИН-код.
Рис. 3 Проверка подлинности для OWA при помощи смарт-карты
Рис. 3 Проверка подлинности для OWA при помощи смарт-карты
Подтверждение сертификата (2) обрабатывается по запросу списков отзыва сертификатов (CRL) или интерактивного протокола состояния сертификатов (OCSP) в зависимости от настройки ISA Server и другого установленного программного обеспечения. ISA Server делает запрос на контроллер домена (DC) для проверки учетных данных пользователя. Если во время запроса происходит ошибка, ISA Server показывает пользователю страницу ошибки, а на сервер клиентского доступа Exchange не идет никакого запроса.
После подтверждения учетных данных создается билет Kerberos, а запрос передается на сервер клиентского доступа Exchange, использующий объединенную проверку подлинности (3). Когда сервер Exchange первого уровня получает запрос, он подтверждает билет Kerberos и находит сервер базы данных почтового ящика пользователя (4).
Сервер клиентского доступа требует билет Kerberos для соответствующего сервера базы данных посредством ограниченного делегирования Kerberos и передает почтовый запрос на сервер базы данных, используя объединенную проверку подлинности (5). Запрос обрабатывается сервером базы данных (6), а данные почтового ящика возвращаются на сервер клиентского доступа Exchange (7). Данные формата HTML для страницы OWA передаются на ISA Server (8), который затем возвращает их на клиентскую машину (9).

Настройка среды Exchange
Статья базы знаний, упомянутая ранее, описывает программные обновления для Exchange Server 2003, а также содержит информацию, которая познакомит вас с процессом включения ограниченного делегирования Kerberos при использовании ISA Server 2006 и Exchange Server 2003.
Основная функция, включаемая обновлением программного обеспечения, -- автоматизация процесса ограниченного делегирования Kerberos от сервера клиентского доступа Exchange до соответствующих серверов баз данных. Обновление не будет автоматизировать процесс ограниченного делегирования Kerberos от ISA Server до сервера клиентского доступа, поскольку ISA Server не является частью Exchange. Это делегирование необходимо включать вручную от каждого экземпляра ISA Server до каждого сервера клиентского доступа Exchange.
При обновлении ПО добавляется новая вкладка в диспетчер системы сервера Exchange (ESM), который позволяет вам назначить сервер клиентского доступа Exchange в качестве KCD-FE (см. рис. 4), который, в свою очередь, позволяет выставлять этот сервер во вкладке делегирования соответствующих серверов баз данных Exchange.
Рис. 4 Включение ограниченного делегирования Kerberos
Рис. 4 Включение ограниченного делегирования Kerberos
Новый пользовательский интерфейс также позволяет вам определять в свойствах административной группы, какие учетные данные использовать для заполнения атрибута msDS-AllowedToDelegateTo (A2D2), как показано на рис. 5. Этот атрибут отвечает за ограниченное делегирование Kerberos.
Рис. 5 Настройка учетной записи, контролирующей делегирование
Рис. 5 Настройка учетной записи, контролирующей делегирование
В соответствии с принципом минимальных полномочий можно использовать стандартную учетную запись пользователя и давать ей возможность делегировать пользователей и компьютеры при помощи объекта групповой политики (GPO). После того, как учетной записи вручается это повышенное право, она может использоваться как служебная учетная запись для автоматизации процесса ограниченного делегирования Kerberos для соответствующей административной группы.
Вы должны принять необходимые меры, чтобы убедиться в том, что пользователь-злоумышленник не сможет взломать служебную учетную запись ограниченного делегирования Kerberos. Даже если учетная запись не является записью администратора домена, доступ к ней может привести к изощренным попыткам воспользоваться делегированием Kerberos. Поскольку учетная запись может устанавливать новые ассоциации Kerberos, с ней следует обращаться осторожно. Примите необходимые меры предосторожности для обеспечения безопасности и целостности учетной записи: длинный сложный пароль, повышенный аудит, приемы отключения учетной записи и т.д.
Программное обновление Exchange также вносит значительные изменения в интерфейс ESM в плане объединенной проверки подлинности. Ранее в Exchange Server 2003, когда сервер был назначен сервером клиентского доступа, возможность включения объединенной проверки подлинности Windows для виртуальных каталогов HTTP (под виртуальным сервером HTTP) не была доступна (см. рис. 6).
Рис. 6a Обновление позволяет включать объединенную проверку подлинности
Рис. 6a Обновление позволяет включать объединенную проверку подлинности
Рис. 6b Обновление позволяет включать объединенную проверку подлинности
Рис. 6b Обновление позволяет включать объединенную проверку подлинности
Это происходило потому, что объединенная проверка подлинности не поддерживалась серверами клиентского доступа Exchange по техническим причинам из-за того, что прокси-серверы прерывали сеансы NTLM, пользователям, проходящим проверку подлинности Kerberos, была необходима связь с Active Directory, а пользователи Интернета обычно не были частью домена. Обновление, описанное в вышеупомянутой статье базы знаний, снимает эти ограничения. При установленном обновлении вы можете просто войти в виртуальный каталог и установить флажок для объединенной проверки подлинности Windows в качестве механизма проверки учетных данных пользователя. Если флажок установлен, происходит настройка атрибута под названием msexchAuthenticationFlags на объекте виртуального каталога в Active Directory (вы можете увидеть это, использовав оснастку Adsiedit.msc в консоли управления Майкрософт).
Пользователи, проверяющие почту при помощи OWA, могут знать название своих серверов баз данных Exchange и могут связаться с ними, используя объединенную проверку подлинности, если они находятся в корпоративной интрасети. Разница в поддержке пользователей со объединенной проверкой подлинности состоит в том, что, когда вы входите в сеть, вам предлагают ввести имя пользователя и пароль, потому что Internet Explorer будет производить автоматическую проверку подлинности перед входом на веб-узел. Это очень удобно для пользователей корпоративной сети, но внешние пользователи – а пользователи OWA обычно относятся к внешним – не смогут войти в домен, если они входят из внешней сети на сервер клиентского доступа Exchange. (Этот процесс подробно объясняется в статье в статье базы знаний "Как IIS проверяет подлинность клиентов обозревателя".)
В Exchange Server обновление заносит на вкладку делегирования возможность использования атрибута A2D2, а не атрибута имени участника-службы (SPN) в Active Directory. Если посмотреть на объект компьютера сервера Exchange при помощи Adsiedit.msc, можно увидеть два различных атрибута: атрибут A2D2, являющийся списком ограниченного делегирования Kerberos; и атрибут SPN, который служит в качестве локатора Kerberos и точки спецификации учетной записи. Хотя оба атрибута работают вместе для того, чтобы можно было производить ограниченное делегирование Kerberos, при помощи графического интерфейса нужно изменить только атрибут A2D2.
Windows может использовать встроенный HOST SPN в качестве псевдонима для нахождения других служб. Это означает, что не обязательно использовать setspn.exe, чтобы ограниченное делегирование Kerberos работало для делегирования с сервера клиентского доступа Exchange на сервер базы данных Exchange. (Хотя явное определение HTTP/Servername в списке атрибута SPN подходит для этого метода, оно оставляет больше возможностей для ошибок администратора и не является обязательным для функционирования ограниченного делегирования Kerberos.) Ограниченное делегирование Kerberos ищет атрибут A2D2 в Active Directory. Если этот атрибут не включен (или включен с неправильным значением SPN), ограниченное делегирование Kerberos не будет работать между соответствующими серверами. В кластере Exchange, однако, для нормальной работы необходимо лишь, чтобы атрибут A2D2 от сервера клиентского доступа указывал на учетную запись компьютера узла кластера.
Как отмечалось ранее, домен Windows Server 2003, содержащий серверы Exchange 2003, должен находиться в основном функциональном режиме. Ограниченное делегирование Kerberos нельзя использовать, пока не достигнут этот уровень функциональности домена. Если ваш домен все еще находится в смешанном режиме, а вы установили программное обновление, которое описывалось выше, оно будет работать, но регистрации SPN – не будут. Ограниченное делегирование Kerberos – это тоже функция домена, а не функция уровня леса. Это означает, что на серверах Exchange Server 2003, ISA Server и Exchange серверы клиентского доступа и баз данных должны быть членами одного и того же домена (хотя пользователи из разных доменов могут проходить проверку подлинности при помощи ограниченного делегирования Kerberos). Экземпляр ISA Server, не являющийся членом домена или являющийся членом другого домена, не будет являться частью этого метода.

Настройка узла OWA
IIS Admin не следует использовать ни для каких видов изменений проверки подлинности для OWA. Несмотря на то, что OWA работает под IIS и будет реагировать на изменения в метабазе, как и любой другой веб-узел, сервер Exchange составляет некоторую трудность для процесса службы каталогов в метабазу (DS2MB). Процесс DS2MB скопирует изменения из Active Directory в метабазу IIS в одностороннем порядке с перезаписью любых изменений, сделанных напрямую в IIS. В результате этого процесса, если администратор будет напрямую изменять метабазу IIS (например, настройку объединенной проверки подлинности), то этот метод будет работать, но отключится сразу, как только будет запущен следующий цикл репликации DS2MB.
Функция подключения объединенной проверки подлинности Windows для виртуальных каталогов HTTP была сделана доступной в ESM потому, что ESM производит свои изменения непосредственно в Active Directory, после чего эти изменения реплицируются в метабазу IIS. Учтите, что при остановке службы системного помощника остановится и процесс DS2MB, позволяющий вам вносить изменения в метабазу IIS, которые не будут переписаны, поэтому делать этого не рекомендуется. При следующем запуске системного помощника он запросит изменения из Active Directory, и решение будет отключено автоматически.
Вкладка делегирования показывает следующие варианты: «Использовать только Kerberos» и «Использовать любой протокол проверки подлинности». Простая логика подскажет вам выбрать вариант «Использовать только Kerberos», поскольку решение, которое мы обсуждаем, связано с ограниченным делегированием Kerberos, однако эта одна из многих ситуаций в ИТ, где простая логика не применима. Поэтому вы должны выбрать вариант «Использовать любой протокол проверки подлинности» (как показано на рис. 7), потому что запрос не будет иметь вид запроса Kerberos; он будет приходить как запрос HTTP с соответствующим сертификатом, сопоставленным с учетной записью Active Directory.
Рис. 7 Правильная настройка проверки подлинности для смарт-карт
Рис. 7 Правильная настройка проверки подлинности для смарт-карт
В данном случае ISA Server запрашивает пользовательский сертификат PKI через SSL. Входящий запрос не является билетом Kerberos, поэтому необходимо произвести переход, чтобы ограниченное делегирование Kerberos функционировало правильно. Выбор настройки "Использовать только Kerberos» нарушит цепь связи на ISA Server. Отметим, однако, что вариант «Использовать только Kerberos» будет работать при делегировании с сервера клиентского доступа Exchange на сервер базы данных Exchange, поскольку сервер клиентского доступа будет получать только билеты Kerberos с ISA Server.
Виртуальные каталоги \Exchange и \Public – единственные каталоги, где должна хранится персональная информация пользователей и информация по общим папкам. Настройка SSL в Exchange не является чем-то новым для ограниченного делегирования Kerberos или двухфакторной проверки подлинности, поскольку это перенос из стандартного включения OWA при помощи SSL с базовыми учетными данными проверки подлинности. Необходимо придерживаться указанных способов включения SSL в OWA, поскольку неправильное обращение с SSL может негативно сказаться на OWA, а также на ESM.

Дополнительные подробности настройки
При использовании этого метода гораздо легче вначале развернуть серверы ISA Server и Exchange стандартным образом. Не нужно сразу разворачивать ограниченное делегирование Kerberos со всеми настроенными параметрами (особенно если до этого вы не развернули ISA Server). Это может осложнить процесс исправления ошибок, если возникнут проблемы с каким-либо компонентом или этапом процесса. Гораздо легче вначале развернуть серверы ISA Server и Exchange стандартным образом (с именем пользователя и паролем, но без проверки подлинности на основе форм), убедиться, что все работает правильно, а затем перейти к ограниченному делегированию Kerberos и проверке подлинности на основе сертификатов.
Обычно проверка подлинности на основе форм не может использоваться вместе с проверкой на основе смарт-карт. Проверка подлинности на основе форм показывает, что пользователь должен передать имя пользователя и пароль через стандартную форму Outlook. Однако при двухфакторной проверке подлинности при помощи смарт-карт у пользователя будет только смарт-карта и не будет пароля. Таким образом, проверка подлинности на основе форм не имеет возможностей принять или передать данные только одного сертификата для проверки подлинности. Использование проверки подлинности на основе форм где-либо в цепи (например, на сервере клиентского доступа за ISA Server) нарушит настройку проверки подлинности для OWA при помощи смарт-карт. Если вы включите проверку подлинности на основе форм, виртуальный каталог сервера Exchange будет вынужден перейти на базовую проверку подлинности, и вслед за ним метабаза IIS также будет настроена на базовую проверку подлинности.
Если у вас есть пользователи как с именами пользователей/паролями, так и со смарт-картами, вы можете включить двойную проверку подлинности на веб-слушателе ISA, и когда пользователь нажимает клавишу ESC после запроса ввести учетные данные на основе сертификата, ему будет предложено ввести стандартные имя пользователя и пароль, даже если встроенная проверка подлинности включена за ISA Server на сервере Exchange. Кроме того, ISA Server может отключать сессию SSL вследствие бездействия точно так же, как при проверке подлинности на основе форм.

Заключение
Поддержка смарт-карт для проверки подлинности в OWA – это долгожданное дополнение как к Exchange Server 2003, так и к Exchange Server 2007. Имея возможность входа в OWA, используя сертификат, пользователи могут больше не беспокоиться о запоминании длинных и сложных паролей, а у администраторов появился эффективное средство клавиатурных шпионов и других вредоносных программ, которые могут извлекать учетные записи из зараженной системы. Для получения дополнительных сведений см. панель «Материалы».
Правильная настройка ISA Server для двухфакторной проверки подлинности при помощи смарт-карт еще более улучшит общий уровень безопасности с применением фильтрации на уровне приложения для публикуемых приложений OWA. Кроме того, у ISA Server 2006 имеется встроенная поддержка для публикации как Exchange Server 2003, так и Exchange Server 2007 при помощи простых мастеров публикации, поэтому ISA Server по-прежнему остается удачным приобретением организаций, переходящих на Exchange Server 2007.
Материалы
  • Как предоставлять общий доступ к файлам, которые удалены функцией фильтрации "Безопасный HTML" в Outlook Web Access для Exchange Server 2003
  • Поиск и устранение ошибок при работе с делегированием Kerberos
  • Служба обновления метабазы
  • Проверка подлинности в ISA Server 2006
  • Смена протокола и ограниченное делегирование Kerberos
  • TechNet Webcast: Внедрение многофакторной проверки подлинности при помощи смарт-карт

Виктор Акиннагби занимает должность главного специалиста по эксплуатации в корпорации Майкрософт и работает в Вашингтоне, О.К. Основными направлениями его работы являются безопасность, инфраструктура и обмен сообщениями.
Тед Дрессел занимает должность консультанта в корпорации Майкрософт и работает в Вашингтоне, О.К. Основными направлениями его работы являются безопасность и инфраструктура.
Джейсон Опдайк занимает должность главного специалиста по эксплуатации в корпорации Майкрософт и работает в г.Шарлотт. Основными направлениями его работы являются безопасность и инфраструктура.


 Администрирование в Windows: Служба установщика ActiveX в Windows Vista
Администрирование в Windows Роб Кэмпбелл (Rob Campbell) and Джоэл Йокер (Joel Yoker)

Служба установщика ActiveX в Windows Vista
Краткий обзор:
  • Общие проблемы элементов управления ActiveX
  • Установка элементов управления ActiveX
  • Опасные разрешения
  • Более безопасный процесс в Windows Vista

Это всегда одна и та же история. Для значительного улучшения вашей безопасности необходимо отказаться от некоторой свободы или гибкости. Если ваша среда такая же, как в большинстве организаций, у вас существует потребность в усилении защиты операционных систем настольных станций для обеспечения более безопасной работы
среда для ваших конечных пользователей. Обычный подход администраторов отделов ИТ к задаче обеспечения безопасности рабочей среды заключается в использовании сочетания параметров политике безопасности, разрешений пользователей, списков управления доступом (ACL) к файлам и реестру и ограничений системных служб.
Общей проблемой разработки безопасной рабочей среды является смягчение угроз от вредоносных элементов управления ActiveX® с одновременным обеспечением соответствующего уровня совместимости приложений в среде. Это являлось проблемой настольных операционных систем в течение многих лет. К счастью, новая служба установщика ActiveX (AxIS) в Windows Vista™ решает проблемы управления элементами управления ActiveX в корпоративных средах. AxIS предоставляет простой и управляемый способ установки пользователями элементов управления ActiveX с одобренных веб-узлов, тогда как обычно этим пользователям такая установка не разрешена. Управление AxIS при помощи групповой политики позволяет администраторам отделов ИТ определять, какие элементы управления могут устанавливать пользователи, независимо от их разрешений.
В данной статье мы рассмотрим проблемы администрирования элементов управления ActiveX, решение этих проблем в предыдущих версиях Windows®, а также предоставление в Windows Vista уникального и эффективного способа управления установкой элементов управления ActiveX при помощи AxIS.

Что такое элемент управления ActiveX?
Элемент управления ActiveX – это часть исполняемого кода (обычно в файл OCX, упакованный в файле CAB), устанавливаемая и запускаемая пользователем через обозревателем Internet Explorer®. Веб-разработчики создают элементы управления ActiveX для добавления к веб-приложениям функций, которые невозможно осуществить с помощью стандартного кода HTML или простого сценария.
Главной функцией элементов управления ActiveX является их модель развертывания «загрузить и выполнить». Элементы управления ActiveX устанавливаются и выполняются через тег объекта HTML, который имеет атрибут CODEBASE, сообщающий обозревателю Internet Explorer (с помощью URL-адреса) о местонахождении элемента управления, если он еще не установлен на компьютере пользователя. В этом случае Internet Explorer загружает соответствующий пакет установки, выполняет доверенную проверку объекта и запрашивает разрешение пользователя на установку через панель информации Internet Explorer (показана на рис. 1). Во время установки элемент управления регистрируется и выполняется страницей отображения. После установки элемент управления могут запустить все стандартные пользователи. Этот простой механизм распространения и выполнения предоставляет разработчикам простой способ распространения своих компонентов пользователям их веб-приложений. Проблема этого метода распространения заключается в том, что стандартные пользователи не могут устанавливать элементы управления ActiveX напрямую, поскольку для установки необходимы права администратора.
Рис. 1 Панель информации установки элемента управления ActiveX
Рис. 1 Панель информации установки элемента управления ActiveX
Когда элементы управления ActiveX были впервые представлены в обозревателе Internet Explorer 4.0, Интернет выглядел более дружелюбным местом. Сегодня исполняемый код, распространяемый через Интернет, представляет значительную угрозу, поэтому Windows разрешает установку элементов управления ActiveX только пользователям с правами администраторов при одобрении установки в соответствии с параметрами политики. После установки элемента управления ActiveX администратором его может выполнить любой пользователь системы. Этот процесс упрощается с помощью набора списков ACL для файлов и реестра в Windows. Хотя это препятствует установке элементов управления ActiveX стандартными пользователями, это не снижает риск локальных администраторов и стандартных пользователей (с измененными разрешениями по умолчанию), устанавливающих элементы управления.
Хотя защита в Windows по умолчанию, разрешающая установку только пользователям с правами администраторов, устанавливает управление элементами управления ActiveX на индивидуальном уровне, она не предоставляет способа управления ими в большой организации. Общей проблемой корпоративных сред является разрешение использование элементов управления ActiveX, доверенных ИТ-организацией, с одновременным снижением рисков от внешних недоверенных элементов управления. В конце дня решение установки определенного элемента управления ActiveX, хорошего или плохого, часто оставляется на отдельного пользователя в зависимости от его прав. Для противодействия угрозам некоторые организации блокируют элементы управления ActiveX, тогда как другие позволяют конечным пользователям устанавливать их, но пытаются осуществлять управление установленными вредоносными программами.
Другим способом предотвращения установки вредоносных элементов управления является ограничение прав стандартных пользователей и предварительная установка всех необходимых элементов управления на настольной платформе администратором отдела ИТ. Этот подход является эффективным, если используемые элементы управления ActiveX являются относительно статичными, изменяются с помощью запланированного процесса выпуска в связи с обновлениями рабочей среды или если в организации используется такой механизм распространения программного обеспечения, как Systems Management Server. Однако текущее управление, постоянно меняющиеся потребности разработчиков внутренних приложений и зависимость от внешних элементов управления продолжают являться проблемами этих подходов.
В случаях наличия у пользователей прав администраторов имеется другая проблема; она заключается в том, чтобы пользователи не устанавливали неутвержденные элементы управления. В этих случаях право конечного пользователя на установку элементов управления ActiveX предполагается, поскольку пользователь имеет права администратора. (Имейте в виду, что работа конечных пользователей в качестве локальных администраторов представляет высокую опасность для организации и не рекомендуется для большинства корпоративных сред.)
Одним из решений является использование внутреннего сервера загрузки компонентов Интернета для размещения одобренных элементов управления. Для данного решения требуется изменение строки CodeBaseSearchPath в реестре клиента. Обычно при нахождении на запрашиваемой странице HTML тега объекта с атрибутом CODEBASE клиенты Windows перенаправляются в местоположения, указанные данными CodeBaseSearchPath. По умолчанию данная строка реестра содержит ключевое слово CODEBASE и внутренние URL-адреса Интернета для галереи элементов управления ActiveX. Для реализации сервера загрузки компонентов Интернета необходимо заменить данные по умолчанию в CodeBaseSearchPath URL-адресом внутреннего сервера, на котором размещаются одобренные организацией элементы управления. Как и для предыдущего подхода, для данного решения требуется постоянное управление; оно также приводит к затратам и возникновению сложности размещения внутреннего сервера для элементов управления ActiveX.
Существуют другие решения, например изменение зоны URLActions обозревателя Internet Explorer, указание одобренных администратором элементов управления через групповую политику и блокирование установки всех элементов управления по периметру с помощью правил брандмауэра. Но, как вы видите, все эти подходы имеют собственные проблемы и многие из них в итоге не используются из-за недостаточной гибкости. Что еще хуже, для некоторых из этих решений требуется, чтобы пользователи имели права администраторов. Таким образом, эти изменения решают часть проблемы, например, контроль (или блокирование) источника элементов управления ActiveX, откуда они могут быть выполнены и т.д.; однако эти решения не решают фундаментальную проблему невозможности установки элементов управления ActiveX пользователями без прав администраторов.

Какие возможности предоставляет AxIS?
AxIS в Windows Vista позволяет корпоративным администраторам управлять элементами управления ActiveX, обеспечивая надежную защиту, поскольку пользователи выступают в качестве стандартных пользователей с параметрами файловой системы по умолчанию. AxIS предоставляет групповой политике возможности настройки доверенных источников элементов управления ActiveX и брокерский процесс для установки элементов управления из этих доверенных источников стандартными пользователями. Ключевым преимуществом является возможность сохранения неадминистративной безопасности рабочих станций пользователей с помощью централизованного административного управления. AxIS опирается на определение доверенных источников (обычно URL-адреса из Интернета или интрасети) элементов управления ActiveX администраторами отделов ИТ. Если тег объекта сообщает обозревателю Internet Explorer о необходимости выполнения элемента управления, AxIS выполняет следующие действия.
  1. Проверка установки элемента управления. Если элемент отсутствует, он должен быть установлен для его использования.
  2. Проверка параметров политики AxIS на предмет того, является ли источник элемента управления доверенным. Отдельная проверка устанавливает соответствие имени узла URL-адреса, указанного в атрибуте CODEBASE тега объекта, указанному в политике списку доверенных мест.
  3. Загрузка и установка элемента управления от имени пользователя.
Если имя узла URL-адреса источника отсутствует в параметре политики AxIS, будет выполнен обычный запрос контроля учетных записей, указывающий необходимость прав администратора для выполнения установки. Кроме того, AxIS зарегистрирует в журнале событий приложений событие с идентификатором 4097 от источника AxInstallService с указанием попытки установки элемента управления ActiveX, а также путь загрузки элемента управления. Пример события 4097 показан на рис. 2. Данные этой записи журнала событий могут использоваться корпоративным администратором для изменения групповой политики с целью разрешения установки элемента управления AxIS при последующих посещениях веб-узла.
Рис. 2 Событие AxInstallService 4097
Рис. 2 Событие AxInstallService 4097
AxIS – это дополнительный компонент, входящий в версии (SKU) Business, Enterprise и Ultimate операционной системы Windows Vista, который может быть включен с помощью автоматического параметра или из диалогового окна панели управления (Программы | Программы и компоненты | Включение и отключение компонентов Windows), как показано на рис. 3. После включения AxIS выполняет указанные выше действия при каждом запросе элемента управления обозревателем Internet Explorer.
Рис. 3 Включение AxIS на панели управления
Рис. 3 Включение AxIS на панели управления
Возможность прикрепления заданий к событиям в Windows Vista предоставляет администраторам простой способ получения уведомлений от службы AxIS, например, при блокировании установки элемента управления ActiveX. Важно заметить, что нельзя всегда предполагать, что элемент управления ActiveX будет устанавливаться с этого же имени узла URL-адреса, к которому обращается конечный пользователь с веб-узла. По этой причине информация, предоставленная событием 4097 AxInstallService 4097 (попытка установки), является исключительно полезной для определения узла, с которого выполняется попытка установки элемента управления.
С помощью полученной от события информации можно настроить доверенное местоположение в групповой политике. Параметры AxIS в локальной или групповой политике находятся в параметрах конфигурации компьютера (как показано на рис. 4). Параметр политики «Веб-узлы, разрешенные для установки элементов управления ActiveX» позволяет указывать URL-адреса узла доверенных местоположений (см. рис. 5). Для параметра разрешенного узла необходимы два элемента информации — источник установки элемента управления ActiveX и поведение установки.
Рис. 4 Параметры редактора объектов групповой политики
Рис. 4 Параметры редактора объектов групповой политики
Рис. 5 Одобренные AxIS узлы установки
Рис. 5 Одобренные AxIS узлы установки
Прежде всего, как упоминалось ранее, URL-адрес узла необходим для определения доверенного расположения элемента управления. В отличие от предыдущих решений, для которых необходимо было знать идентификатор CLSID элемента управления (который часто изменяется при изменении элементов управления другими разработчиками), AxIS позволяет установку любых элементов управления из доверенного месторасположения, что уменьшает общую потребность в административной деятельности. Вторым элементом информации является строка из четырех значений, разделенная запятыми, каждое из которых обозначает поведение загрузки элемента управления ActiveX. Значения определяют четыре свойства: TPSSignedControl, SignedControl, UnsignedControl и ServerCertificatePolicy. Первые два свойства (TPSSignedControl и SignedControl) могут иметь одно из трех значений: 0, 1 или 2. Эти значения схожи со значениями параметров URLAction. Значение 0 запрещает установку элемента управления, при установке значения 1 появляется запрос на разрешение пользователя на установку, а при установке значения 2 элемент управления будет автоматически установлен от имени пользователя. Неподписанные элементы управления не могут быть установлены автоматически, поэтому значения свойства UnsignedControl может быть только 0 или 1. Если политика не указана, используются значения по умолчанию 2, 1 и 0.
Последнее свойство определяет поведение установки на основе параметров сертификата элемента управления подписанных параметров. Как и большинство узлов SSL, сертификаты должны пройти ряд тестов безопасности для проверки действительности сертификата. Неверные свойства сертификата иногда являются практикой реализации подписанного элемента управления ActiveX. Благодаря настройке AxIS позволяет администраторам устранить недействительную информацию, которая иногда присутствует в сертификатах на основе «URL-адрес-URL-адрес». Последнее свойство – это сочетание значений с битовой маской, как показано на рис. 6.
Figure 6 ServerCertificatePolicy (Close Figure 6)

Значение | Определение
0x00001000 | Игнорирование неверного канонического имени (CN) в сертификате.
0x00000100 | Игнорирование неизвестных центров сертификации.
0x00002000 | Игнорирование неверной даты сертификата.
0x00000200 | Игнорирование неправильного использования сертификата.
Значение по умолчанию – 0, что означает, что означает, что должны быть выполнены все тесты безопасности до завершения установки AxIS. Сочетание параметра узла и этих четырех значений указаны в параметре политики, как показано на рис. 7.
Рис. 7 Одобренные URL-адреса AxIS
Рис. 7 Одобренные URL-адреса AxIS

Заключение
AxIS позволяет настраивать групповую политику для определения элементов управления ActiveX, которые могут устанавливаться пользователями без полномочий администратора или необходимости сложных настроек. Управление на таком уровне могло быть затруднительным в предыдущих версиях Windows, а ранее доступные решения часто имели серьезные ограничения или значительную необходимость в управлении. AxIS предоставляет организациям другое средство с использованием подхода минимальных полномочий и прав конечных пользователей на настольных системах, что делает возможным реализацию модели стандартных пользователей, где для конечных пользователей не требуются права администраторов. Windows Vista предоставляет администраторам отделов ИТ значительное преимущество, поскольку они они могут выбирать, какие элементы управления ActiveX считаются доверенными в корпоративной среде, что определяется организацией, а не конечным пользователем.

Роб Кэмпбелл (Rob Campbell) – старший технический специалист рабочей группы подразделения Microsoft Federal. Роб занимается разработкой и развертыванием решений в сфере безопасности для органов федеральной власти США.
Джоэл Йокер (Joel Yoker) – старший консультант рабочей группы подразделения Microsoft Federal. Джоэл занимается разработкой и развертыванием решений в сфере безопасности для органов федеральной власти США.


 От редактора: Шесть степеней
От редактора
Шесть степеней
Джошуа Трупин (Joshua Trupin)

Вы когда-нибудь чувствовали себя немного отчужденным? Сидели ли вы когда-нибудь в офисе в одиночестве, уставившись в пустоту и размышляя, существует ли где-нибудь еще разумная жизнь? Существует ли вообще еще хоть кто-то? Возможно нет, если ваш почтовый ящик постоянно забит под завязку, как и мой.
Тем не менее, недавно я все это осознал и решил, что мне необходим контакт с людьми. Я зарегистрировался на одном из узлов деловых сетевых сообществ и начал добавлять людей, всех, с кем я когда-либо работал, от кого получал статьи и с кем общался на конференциях. В течение недели в моем списке было 58 контактов. Великолепно!
Но это был только первый уровень. На втором уровне, знакомые знакомых, у меня было более 3 500 друзей. А поскольку у этих 3 500 контактов были собственные контакты, у меня быстро возникло 277 000 контактов третьей степени. Я быстро подсчитал в таблице Excel: предположим, у всех лиц приблизительно 50 контактов, получается, что я знаю более 34 миллиардов людей как контактов шестой степени. Кевин Бэйкон, подвинься! Я знаю больше людей, чем существует на нашей планете. Неожиданно пустота стала переполняться.
Однако это привело к новой проблеме. Что мне делать со всеми этими знакомыми? Я готов выслушать любые предложения. Пользуетесь ли вы узлом общественной/деловой сети? Как вы сортируете людей, с которыми вы хотите общаться, а с какими нет? Посетите TechNet Magazine блог и поделитесь своими мыслями об этой насущной проблеме.
Если вся сеть веб 2.0 не для вашей скорости, бояться нечего. Выпуск журнала TechNet Magazine в этом месяце посвящен улучшению связи благодаря лучшему использованию Exchange Server. Пять статей посвящены сведениям относительно расширения системы сообщений организаций.
Использование проверки подлинности с помощью смарт-карт для веб-клиента Outlook является одной из тем выпуска за этот месяц. Необходимость физической проверки подлинности для доступа к ресурсам компании является хорошей идеей, смарт-карты делают это возможным везде. Также будет рассмотрено аварийное восстановление с SharePoint в Exchange Server 2007 и улучшение безопасности мобильных устройств с Windows Mobile 6. И, конечно же, «Exchange Queue — очередь за ответами», наверное, ваша любимая колонка, если вы занимаетесь системами сообщений. Ой, в моей сети только что появилось еще три человека. Я лучше подумаю, поздороваться ли с ними или притвориться спящим.
— Джошуа Трупин

Мы хотели бы поблагодарить следующих технических специалистов по продуктам корпорации Майкрософт: Кристиан Андакер, Крис Корио, Джим Харрисон, Чад Джонс, Майкл Ли, Шон Мак-Грат, Майкл Мерголо, Эрик Перлин, Мишель Рутцер, Гавриэлла Шустер и Джим Трухер.


 Инструментарий: Новые продукты для специалистов по информационным технологиям
Инструментарий
Новые продукты для специалистов по информационным технологиям
Грег Стин (Greg Steen)

Удаленные соединения с монитором
RecordTS
www.tsfactory.com
Хотелось ли вам когда-нибудь заглянуть внутрь вашего сервера терминалов или сеансов удаленного рабочего стола? Может быть, вам интересно знать, что происходило перед тем, как сеанс удаленного рабочего стола обрушил ваш веб-узел? Может быть, у вас есть проблема, касающаяся сервера терминалов, который, как вам кажется, не выполняет репликацию. Возможно, вы беспокоитесь о безопасности своей интеллектуальной собственности. Или, может быть, вам необходимо создать быструю запись или презентацию о том, как вы настроили сервер SharePoint® в тестовой среде. Если одна из этих ситуаций вам знакома, вам необходимо познакомиться с приложением RecordTS, разработанным компанией TSFactory. (Компания TSFactory была создана Клаудио Родригесом, Clбudio Rodrigues, самым ценным специалистом корпорации Microsoft, который занимается разработкой служб терминалов.)
Приложение RecordTS выпускается в двух версиях: Для сервера терминала и для удаленного рабочего стола. Выбор версии зависит от того, какой тип соединения вы хотите отслеживать. По уверениям веб-узла, посвященного продукту, приложение RecordTS выполняет функции "камеры безопасности" в сервере терминалов или при сеансах удаленного рабочего стола. Программное обеспечение в основном действует как прокси между службами терминалов и сеансом конечного пользователя, позволяя ему записывать каждое перемещение и действие, предпринятое во время сеанса.
При интуитивной установке используется простой мастер установки, с помощью которого вы помещаете приложение в тот каталог данных, в котором бы хотели хранить сохраненные сеансы. Приложение устанавливает оснастку MMC (которая позволит вам настроить службу), службу RecordTS и служебную программу, воспроизводящую сеансы, для просмотра записанных сеансов. Открыв оснастку MMC правой кнопкой мыши щелкните служебную папку, чтобы развернуть экран свойств, где можно настроить параметры, например, какой порт будет запускать служба. (Конкретно этот параметр используется при перенесении сеансов служб терминалов на нестандартный порт.) Во вкладке Хранилище можно задать папкой для хранения по умолчанию локальную папку или путь UNC.
Также можно настроить структуру каталогов хранимых сеансов. Например, вы можете использовать домен, пользователя, дату и время, чтобы организовать сохраняемые данные. И, возможно, самым важным параметром при хранении сеансов на локальном диске является то, что можно настроить службу на выполнение определенных действий в том случае, если дисковое пространство будет переполнено. Вы даже можете выбрать недопустимость новых соединений и отключение текущих сеансов (для повышения безопасности) или отмену записи сеанса (этот параметр поможет не снизить производительность).
Во вкладке безопасность вы сможете уточнить, хотите ли вы создать цифровую подпись для всех записанных сеансов, выбрав один из существующих сертификатов или создав сертификат с собственной подписью. Это стоит сделать в том случае, если вы планируете использовать средство для аудирования или выполнения обязательств. На вкладке «Пользователи» вы можете определить пользователей, чьи сеансы будут записаны, и тех, чьи сеансы записываться не будут.
В общем, приложение RecordTS может оказаться неоценимым средством безопасности и аудирования, и использоваться может гораздо шире, чем просто для предоставления вам возможности записать свою инструктирующую презентацию. Я знаю, что я нашел удобное дополнение к своему набору инструментов .

Цены: Стоимость приложения RecordTS Remote Desktop Edition - от 495 долларов США. Стоимость приложения RecordTS Terminal Services Edition - от 995 долларов США.

Отслеживание узлов
Расширенный контроль узлов
www.ks-soft.net
Если вы когда-либо предоставляли поддержку критически важной инфраструктуры в процессе эксплуатации, это то, без чего вы не сможете обойтись: качественный и надежный монитор узлов. Даже если у вас сверхнадежное оборудование и стабильный и надежный набор приложений, работающий точно и безошибочно, вам все равно необходим полнофункциональный монитор узлов, который покажет вам, когда эта резервно дублирующаяся система была активизирована.
Расширенный монитор узлов от компании KS-Soft обладает 58 различными методами тестирования и 30 способами предупреждения. Вы сможете проверить такие параметры, как сведения о процессах, сеансы пользователей, превышение нагрузки, память и так далее. Приложение предоставляет тесты, предназначенные для операционных систем Windows® и Linux/UNIX, а также проверки, предназначенные для любых платформ. В отличие от тестов, предназначенных для операционной системы Windows, тесты для Linux/UNIX требуют установки поверх клиента Агента удаленного мониторинга.
Также приложение предлагает мониторинговый тест инструментария управления Windows (WMI). Вы сможете найти верный запрос с помощью встроенного в программу обозревателя WMI, что позволит вам легко выполнять переходы, выбирать соответствующие элементы и осуществлять запросы, чтобы убедиться, что они предоставят вам необходимые данные.
Расширенный монитор узлов также обладает рядом тестов для баз данных, например тест запроса ODBC, который проверяет доступность источника данных ODBC, запускает запрос и сличает результат с известным значением. Также вы можете проверить возможность узла принимать входящие сеансы на серверах баз данных SQL Server™, MySQL, Oracle, Postgres, Sybase и Interbase.
В приложении также присутствует ряд тестов для дисков и файлов, что поможет вам вести счет доступности свободного места, квот, папок и фалов и доступности общих файлов UNC. Также вы получаете и стандартный набор сетевых тестов: общие проверки TCP/UDP, тесты для электронной почты (для протоколов SMTP, POP3 и IMAP), тесты передачи сообщений электронной почты, тесты содержания и синхронизации HTTP и так далее. Вы также можете создать взаимозависимость тестов монитора, чтобы выстроить проверки одну за другой. Также можно настроить регулярное и нерегулярное расписание тестов, что позволит вам детально рассчитать шаблон тестирования.
Некоторое способы предупреждения включают в себя рассылку сообщений посредством SMS, ICQ, электронной почты, журнала событий или с помощью всплывающий окон. Они также могут вызывать другие события, например запуск или остановку служб или выполнение внешней программы.
С обоими версиями Advanced Host Monitor, Professional и Enterprise, вы получаете IP-средства компании KS-Soft - набор из 19 сетевых служебных программ для TCP/IP, включающих сканеры порта/протокола и наблюдатель ловушки SNMP, который позволит вам получать и обрабатывать сообщения ловушки SNMP. Также обе версии предлагают анализатор журнала и компонент отчета, который позволит вам определить тенденции исторического мониторинга данных для ваших отчетов о периодах работоспособного состояния и обзорах анализа производительности.
Сам интерфейс обеспечивает быстрый обзор одновременно ряда тестов. С этим приложением вы сможете легко обнаружить проблемы на отслеживаемых узлах.
Цены: 599 долларов США за версию Enterprise. 275 долларов США за версию Professional.

Очистка диска
WinDirStat
www.windirstat.info
Более чем ваш дом или квартира размещение хранилища файлов имеет тенденцию с течением времени загромождаться данными, которые были нужны когда-то, но сейчас только занимают ценное место. Небольшая весенняя уборка поможет избавиться от лишнего хлама, но, в отличие от вашего дома, древовидная структура каталогов не позволяет сразу же увидеть, откуда начинать приводить хранилище в порядок. К счастью существует отличное средство визуализации, которое сможет помочь вам увидеть, какие файлы занимают место на вашем диске.
Общедоступная программа WinDirStat, сделанная для Windows по образцу Linux KDE kdirstat, покажет вам файлы на выбранном диске в виде разноцветных квадратиков. Размер квадратика соответствует размеру файла, что позволяет легко обнаружить ненужные старые файлы форматов ISO или ZIP.
После выбора локального диска (или нескольких локальных дисков) программа сканирует дерево каталогов, создавая в памяти карту файлов, которая затем отображается на нижней панели графического интерфейса пользователя. При щелчке по цветному квадратику в нижней панели в верхней панели, похожей на проводник Windows, осуществляется переход к месту расположения файла. Верхняя панель предоставляет такую полезную информацию, как размер файла, дата последнего изменения и другие атрибуты. Также вы увидите, сколько процентов поддерева занято этим файлом.
Очень интересный подход, цвета обозначают типы файлов, а при щелчке определенного типа файлов в верхней правой панели в нижней панели будут выделены все файлы этого типа. Это удобно, когда, например, вам необходимо определить все скрытые MP3 файлы, которые ваши пользователи хранят на сервере. Также вы увидите, какой процент этии файлы занимают в разделе.
Цены: Бесплатная загрузка.

Обзор книги
Враг в охладителе воды
syngress.oreilly.com
Почти любой бизнес нуждается в связи с Интернетом, и большинство осознает опасность, которую представляют собой почти постоянные попытки внешнего подключения к точкам доступа, которые разделяют "внешнюю" и "внутреннюю" стороны их информационной инфраструктуры. Однако многие предприятия не обращают внимания на потенциально более серьезную угрозу, которая существует внутри организации. Опасность этих так называемых внутренних угроз великолепно показана в книге Враг в охладителе воды: Истории из реальной жизни о внутренних угрозах и мерах противодействия управлением безопасности предприятия, написанная Брайаном Контосом (Syngress, 2006).
Контос предлагает истории из реальной жизни о произошедших атаках и последствиях, которые они оказали на вовлеченные компании. Он требует, чтобы обеспечение безопасности стало непрерывным процессом, включающим в себя "объединение людей, процесс и технологию." Этой книгой он пытаелся показать потенциальную силу программного решения Управление безопасностью предприятия (ESM) при подавлении внутренних угроз.
Как руководитель отдела безопасности компании ArcSight Контос очень серьезно полагается на программное обеспечение ESM, разработанное его компанией, но это не умаляет основной ценности книги. В книге отсутствуют серьезные технические детали, но вы получите хорошую идею о том, как можно усовершенствовать процесс обеспечения безопасности в вашей организации, узнав о том, в чем и как ошибались другие, и поняв, насколько эффективное применение программных решений ESM может снизить интенсивность воздействия внутренних атак.
В главе, где содержатся общие сведения, "Киберпреступление и киберпреступники 101," Контос предлагает обзор нескольких различных типов злоумышленников, которых стоит опасаться, и их мотивации. В книге есть также краткий обзор некоторых их техник, например, переполнение буфера, упаковка кодов, и Угрозы Warhol.
Следующая глава более подробно рассказывает об особенностях внутренних угроз: способы, которыми внутренний злоумышленник может навредить деловой деятельности, принцип опасности управления и возможности угрозы от технических перспектив. В описании технических перспектив дается краткий обзор минимальных преимуществ, надежной проверки подлинности, контроля доступа, определение происшествия и управления в критических ситуациях. Это подготавливает к разговору о программных решениях ESM. С одной стороны, книга описывает работу только с продуктом ArcSight, но основные черты выхода из строя применимы к любой системе.
Книга предлагает ряд сценариев от представительного набора предприятий и рабочих сред, подробно описывая различные типы внутренних угроз и способы их определения (и иногда смягчения). Этот анализ проблемы может пролить свет на некоторые случаи из вашей деловой практики и, возможно, предложит решения для снижения риска внутренних атак в вашей рабочей среде.
Цены: $49.95.

Напишите нам
Если вы хотите увидеть здесь обзор любимого инструмента или служебной программы, свяжитесь с автором по адресу tntools@microsoft.com.

Грег Стин (Greg Steen) – специалист по информационным технологиям, предприниматель и энтузиаст. Он постоянно находится в поиске новых инструментов и методов для облегчения ИТ-специалистам работы и процесса разработки.


 Вопросы и ответы про SQL: Кластеризация изнутри, таинственные зависания, учетная запись SA и прочее
Вопросы и ответы про SQL
Кластеризация изнутри, таинственные зависания, учетная запись SA и прочее
Под редакцией Нэнси Мичел (Nancy Michell)

В. Мне необходимо разобраться с тем, как работает кластеризация. В нашей вычислительной среде будет использоваться 64-разрядный Windows Server® 2003, под управлением которого будет работать SQL Server™ 2005, веб-ферма служб отчетов сервера SQL (SSRS) (развертывание горизонтального масштабирования сервера отчетов), сервер каталогов SSRS TempDB и сервер SQLServer, получающий данные из базы данных сторонней компании через связанный сервер и предназначенный для хранения данных для SSRS.
Нам требуется состоящий из 3 узлов кластер типа активный/активный/пассивный. Узел 1 будет активным, и на нем будут храниться данные, полученные из базы данных сторонней компании. Узел 2 будет активным, и на нем будет храниться каталог SSRS. Узел 3 будет пассивным и станет выполнять роль резервного для узла 1 или узла 2. Не могли бы вы помочь?

О. К сожалению, когда речь идет о кластеризации SQL Server, слишком многих вводят в заблуждение термины активный/активный и активный/пассивный. Они полагают, что кластеризация SQL может поддерживать «горизонтальное масштабирование» одной базы данных или экземпляра SQL на нескольких серверах. Это совсем не так. Для SQL Server не существует такого понятия, как активная/активная база данных или экземпляр. «Экземпляр» представляет собой установку SQL Server с соответствующими базами данных. Наша кластеризация для экземпляра SQL Server всегда определяется взаимоотношением активный (1) к пассивному (n) (отметим, что значение n лежит в интервале от 1 до 7, в зависимости от версии SQL Server). По этой причине она называется отказоустойчивой кластеризацией.
Поняв это, можно начинать обдумывать установку нескольких экземпляров в отказоустойчивом кластере на наборе узлов. Например, три физических сервера, использующие вместе общие диски, могут иметь один экземпляр, являющийся активным по умолчанию на узле 1, и второй экземпляр, активный по умолчанию на узле 2, и оба могут при сбое переходить на узел 3. Эти экземпляры полностью самостоятельные, они не используют совместно данные и не являются парой активный/активный. Они оба используют схему активный/пассивный и оба совместно используют один и тот же резервный экземпляр. Если оба экземпляра переходят при сбое на узел 3, тогда со временем возникает задача, состоящая в определении того, выдержит ли он нагрузку. Предполагается, что при переходе на другой ресурс будет использоваться резервный ресурс, равный по вычислительной мощности исходному. Если при пиковой нагрузке в нормальных рабочих условиях для обработки требуются два узла, маловероятно, что узел 3 выдержит пиковую нагрузку, обычно назначаемую двум узлам.
Таким образом, при данных относительных затратах на оборудование, которое в состоянии поддерживать работу кластера, можно понять тех, кто оценивает вероятность того, что произойдет одновременный сбой обоих основных узлов, приводящий к переносу всей нагрузки на один узел. Имея в виду это соображение, можно принять бизнес-решение, допускающее такой риск, вместо решения о приобретении оборудования, обеспечивающего отказоустойчивость на 100 процентов.
К счастью, есть хорошие новости: SQL Server 2005 предлагает больше возможностей для обеспечения высокой доступности (HA), включая варианты, позволяющие перейти на другой ресурс быстрее, чем с использованием кластера, и даже обеспечивающие дублирование копий данных (кластеризация опирается на единственную сеть SAN). К этим возможностям относятся зеркалирование данных, одноранговая репликация и другие. С учетом этих новых альтернатив появляется много новых вариантов для удовлетворения всех типов потребностей, включая такие варианты, в которых могут сочетаться разные функции высокой доступности.
Средство Microsoft® Cluster Configuration Validation Wizard (ClusPrep), которое теперь доступно для загрузки, заменяет предыдущее средство тестирования HCL (Hardware Certification List — список сертифицированного оборудования), использование которого для проверки полной конфигурации, гарантирующей поддержку ею кластеризации, могло бы занять месяцы. Теперь в руках администратора базы данных имеется средство проверки оборудования, дополнительно снижающее затраты (как финансовые, так и временные), требуемые для установки сертифицированного оборудования. Это средство дает возможность проверять и развертывать в пределах одного набора узлов кластера даже разнородное оборудование.

В. После 12 часов на одном из моих компьютеров оказывается зависшей процедура удаления. Она не заблокирована. При просмотре плана самого медленного запроса выясняется, что некоторый триггер выполняется в течение 87 327 секунд, из чего я делаю вывод, что зависание данной процедуры вызывается этим триггером. Как можно выяснить, на каком именно операторе происходит зависание?

О. Очень вероятно, что цикл в триггере не завершается по целому ряду причин. Если зависание длится долго, и требуется выяснить, какой оператор выполняется, запустите код, приведенный на рис. 1. С его помощью вы узнаете, какой оператор выполняется в текущий момент, и это будет тот оператор, который приводит к зависанию компьютера.
Figure 1 Поиск оператора, выполняющегося в текущий момент (Close Figure 1)
-- Look at the current statement being run:
-- Put results to text (Ctrl + T)
DECLARE @Handle binary(20),
        @start int,
        @end int,
        @SPID int

SET    @SPID = spid

SELECT @Handle = sql_handle,
        @start = stmt_start,
        @end = stmt_end
FROM Master..sysProcesses(NOLOCK)
WHERE SPID = @SPID

IF NOT EXISTS (SELECT * FROM ::fn_get_sql(@Handle))PRINT ‘Handle not found in cache’
ELSE
   SELECT ‘Current Statement’= substring(text, (@start + 2)/2, CASE @end WHEN -1 THEN (datalength(text))
       ELSE (@end -@start + 2)/2 END)
       FROM ::fn_get_sql(@Handle)

В. Требуется поддерживать транзакционную репликацию через брандмауэр. Издатель и распространитель находятся с внешней стороны брандмауэра, а подписчик — с внутренней. Подписчик настроен на прослушивание 1433, а компьютеры имеют следующие имена: Издатель: PUBMACHINE, распределитель: DISTMACHINE, подписчик: SUBMACHINE. Какие требуется открыть порты, чтобы успешно выполнить исходный моментальный снимок и доставку публикации?

О. Если используется подписка на доставку, открытия порта SQL Server (в вашем случае порта 1433) должно быть достаточно, поскольку агент распространения будет выполняться на компьютере распространителя (со внешней стороны брандмауэра), и у него скорее всего будет локальный доступ к файлам моментальных снимков, созданных агентом моментальных снимков. Но если используется подписка на извлечение, агенту распределителя, выполняющемуся на компьютере подписчика, потребуется каким-нибудь образом получить доступ к файлам моментальных снимков через брандмауэр. Ниже приведен список возможных вариантов для рассмотрения.
Исходя из предположения, что файлы моментальных снимков уже доступны из общего файлового ресурса с внешней стороны брандмауэра, можно открыть порты Windows® для использования общего файлового ресурса через брандмауэр, чтобы агент распространителя, выполняющийся с внутренней стороны брандмауэра, мог получать доступ к файлам моментальных снимков, находящимся с внешней стороны (однако следует учитывать возможные влияния на безопасность прочих компонентов вашей инфраструктуры). Отметим, что если местоположение по умолчанию для моментальных снимков (умолчание SSMS) настроено в виде локального пути, может потребоваться использование параметра /AltSnapshotFolder агента распространителя, чтобы переопределить место извлечения файлов моментальных снимков.
Можно также с помощью FTP настроить репликацию для передачи файлов моментальных снимков (и для этого потребовалось бы открыть порт 21).

В. Существуют ли какие-нибудь недостатки отключения учетной записи SA в SQL Server 2005, и повышает ли в действительности безопасность отключение учетной записи SA? Существуют ли документы по этому вопросу?

О. На новой установке SQL Server 2005, если включен смешанный режим, учетная запись SA отключена по умолчанию, и для нее создается случайный пароль. Ее можно отключать также по собственному усмотрению. Не существует специальных документов, относящихся к этому вопросу, но отключение и переименование учетных записей обсуждается в документе по практическому опыту.
Для защиты от попыток взлома учетной записи SA ее можно также переименовать. Но следует помнить, что при включении отключенной учетной записи необходимо установить для нее новый пароль.
Чтобы ответить на ваш вопрос о том, повышает ли это реальную безопасность, напомним, что повышение безопасности за счет отключения учетной записи проистекает из того факта, что бесполезно угадывать пароль, если учетная запись отключена. Не важно, каким временем располагает взломщик или вирус, атака грубой силой против заблокированной учетной записи не может увенчаться успехом. Переименование или отключение SA нарушает работу приложений, зависящих от использования учетной записи SA при установке подключений. В любом случае приоритет следует отдавать поиску и исправлению или удалению таких приложений. Как уже было упомянуто, пока учетная запись не будет снова включена, ее невозможно использовать для подключения к базе данных. Кроме этого, поскольку процесс проверки подлинности завершается сбоем раньше, неудачная попытка требует меньшего расхода ресурсов со стороны атакуемой системы.

В. Файл журнала одной из моих больших сетевых баз данных обработки транзакций (OLTP) в два раза превышает размер файла данных. Была выполнена попытка снизить размер файла журнала до разумных размеров с помощью следующих команд, но есть необходимость в дальнейшем его сокращении:
backup database syslogs to backupfile
DBCC SHRINKFILE (syslogs_log)

О. Вам необходимо заменить команду backup database командой backup log. В качестве альтернативы базу данных можно перевести в простой режим восстановления и выполнить команду shrinkfile. По окончании сжатия журнала верните базу данных к предыдущей модели восстановления и восстановите базу данных. Если сжатие все еще недостаточно, убедитесь в том, что нет открытых транзакций (воспользуйтесь инструкцией dbcc opentran). Дополнительную информацию по этому вопросу можно найти в следующей статье базы знаний support.microsoft.com/kb/907511.

В. Если переход на другой ресурс происходит во время выполнения планового задания агента SQL Server, что будет с этим заданием после перехода на другой ресурс? Требуется ли перезапустить его вручную?

О. Да, если не предусмотрена другая процедура, необходимо запустить его вручную. Если хочется избежать перезапуска заданий вручную, можно написать сценарий, обновляющий таблицу после завершения задания. Если значение = 1, задание было выполнено; любые другие значения указывают на то, что задание не было завершено, и через некоторое время поступит второе задание и выдаст команду запуска. Поэтому, хотя задание необходимо перезапустить, если переход на другой ресурс происходит во время его выполнения, можно, написав сценарий, частично сократить заботы, связанные с этими важными ночными заданиями, которые обязательно должны быть завершены к началу следующего рабочего дня.
Совет: Обновление и DBCC UPDATEUSAGE
Вы выполняете обновление SQL Server 2000 до SQL Server 2005?
Если да, обязательно выполните DBCC UPDATEUSAGE сразу же после обновления баз данных.
DBCC UPDATEUSAGE формирует отчеты и исправляет неточности в страницах и счетчиках строк в представлениях каталога. Эти неточности необходимо исправлять, поскольку они могут привести к неправильным отчетам об использовании пространства, возвращаемым системной хранимой процедурой sp_spaceused. В SQL Server 2005 эти значения всегда поддерживаются правильно, поэтому такие базы данных никогда не сталкиваются с неправильными данными счетчиков. Однако, в базе данных, обновленной до уровня SQL Server 2005, могут содержаться неверные данные счетчиков, поэтому после обновления необходимо выполнить DBCC UPDATEUSAGE.
Команда DBCC UPDATEUSAGE работает следующим образом. Выполняется исправление строк, использованных страниц, зарезервированных страниц, конечных страниц и счетчиков страниц данных для каждого раздела в таблице или индексе. Если в системных таблицах нет неточностей, DBCC UPDATEUSAGE не возвращает данных. Если неточности обнаруживаются и исправляются и не используется выражение WITH NO_INFOMSGS, DBCC UPDATEUSAGE возвращает строки и столбцы, обновленные в системных таблицах.
DBCC UPDATEUSAGE можно также использовать для синхронизации счетчиков использования пространства. Поскольку для работы инструкции DBCC UPDATEUSAGE с большими таблицами или базами данных может потребоваться заметное время, ее следует, как правило, использовать только в тех случаях, когда возникает подозрение, что процедура sp_spaceused возвратила неправильные значения. Отметим, что процедура sp_spaceused принимает необязательный параметр для запуска DBCC UPDATEUSAGE до возвращения информации о пространстве для таблицы или индекса.
В SQL Server 2005 команда DBCC CHECKDB была усовершенствована с целью определения момента возникновения отрицательных значений счетчиков страниц или строк. При обнаружении отрицательных значений DBCC CHECKDB выдает предупреждение и рекомендует запустить DBCC UPDATEUSAGE для разрешения этой проблемы. Хотя может сложиться впечатление, что эта проблема порождена обновлением до SQL Server 2005, можете быть уверены, что неправильные значения счетчиков существовали до процедуры обновления.
В качестве примера рассмотрим, как обновляются счетчики страниц или строк, или оба, для всех объектов в текущей базе данных. В следующей команде в качестве имени базы данных указано значение 0, и DBCC UPDATEUSAGE выдает отчет с информацией о текущей базе данных:
DBCC UPDATEUSAGE (0);
GO
Для обновления счетчиков страниц или строк, или обоих, допустим для AdventureWorks, а также для подавления информационных сообщений, запускается команда, аналогичная следующей, в которой в качестве имени базы данных указывается AdventureWorks, а затем подавляются все информационные сообщения:
USE AdventureWorks;
GO
DBCC UPDATEUSAGE (‘AdventureWorks’) WITH NO_INFOMSGS; GO
Для получения дополнительных сведений осуществите поиск DBCC UpdateUsage в электронной документации по SQL Server.

Thanks to the following Microsoft IT pros for their technical expertise: Ken Adamson, Sunil Agarwal, Siggi Bjarnason, Shaun Cox, Laurentiu Cristofor, Ernie DeVore, Michael Epprecht, Lucien Kleijkers, Raymond Mak, Chat Mishra (MSLI), Niraj Nagrani, Rick Salkind, Jacco Schalkwijk, Vijay Sirohi, Vijay Tandra Sistla, Matthew Stephen, and Buck Woody. Thanks to Saleem Hakani for this month's tip.


 Обзор служебных программ: SMSMap
Обзор служебных программ
SMSMap
Джефф Тондт (Jeff Tondt)
Загрузить исходный код для этой статьи: UtilitySpotlight2007_07.exe (2477KB)

Изображение стоит тысячи слов. Эта известная пословица отражает идею, что сложные истории можно рассказать всего одним изображением, а также что одно изображение может быть более важным, чем текст большого объема. Она также точно характеризует цели визуализации при необходимости быстрого восприятия большого объема данных.
Для такого фаната System Management Server (SMS), как я, взгляд на всю иерархию SMS на одном изображении помогает понять расположение инфраструктуры. Возможно, вы сможете использовать такое изображение для показа управленцам состояния до и после осуществления плана перехода на SMS. В некоторых случаях при устранении неполадок такая диаграмма может быть очень полезной, поскольку помогает найти решение или, по крайней мере, получить помощь от других лиц. И конечно же, как ответственному администратору SMS вам необходимо документировать иерархию системы по множеству других причин.

Получение изображения
Вы, конечно, можете нарисовать такую диаграмму и сами. Вы, несомненно, можете засучить рукава, нарисовать иерархию SMS вручную и задокументировать параметры узла от руки. Если вы работаете с Microsoft® Operations Manager (MOM) для наблюдения за серверами SMS, вы можете использовать его для создания диаграммы иерархии, хотя я должен заметить, что диспетчер MOM не предназначен для создания изображений и точно не документирует параметры узла. Могут существовать другие методы и удобные средства, но я еще не встречал способов адекватного создания изображений и документирования параметров узла, по крайней мере, удовлетворительных для меня способов.
Поэтому я решил заняться этим самостоятельно. Так была создана программа SMSMap 1.0. SMSMap – это приложение Visual Basic® .NET, использующее управляемые библиотеки SMS в комплекте SDK SMS и автоматиризирующее Microsoft Visio® через COM. Служебная программа запрашивает нужный сервер узла SMS, а затем создает внешне привлекательную диаграмму Visio и экспортирует параметры узла в файл формата XML. Формат XML был выбран потому, что он является наиболее совместимым способом документирования параметров узла. Я также выбрал отображение ролей SMS, а не только физических серверов, относящихся к другим серверам SMS. Это позволяет создать диаграмму через слои Visio для просмотра иерархии SMS с нескольких точек зрения.
Рис. 1 Круговой формат
Рис. 1 Круговой формат
В настоящий момент программа позволяет выбрать для диаграммы Visio один из шести форматов. Например, на рис. 1 показана очень простая иерархия SMS в круговом формате, а на рис. 2 показана эта же иерархия в формате блок-схемы. Эта программа довольно успешно работает с иерархиями большего размера, но в данной статье я хотел рассмотреть простые ситуации.
Рис. 2 Формат блок-схемы
Рис. 2 Формат блок-схемы
Возможно будущие версии программы SMSMap будут документировать все параметры узла. В настоящий момент программа документирует только роли узла SMS и все границы. При небольших усилиях в файл XML можно экспортировать множество других параметров узла.

Использование SMSMap
Исходный код и файлы установки SMSMap доступны на веб-узле TechNet Magazine. Для установки программы просто запустите файл SMSMapSetup.msi, который выполнит установку. Не забывайте, что SMSMap использует программу Visio, поэтому последняя должна быть уже установлена. После установки запустите файл C:\Program Files\Microsoft\smsmap\smsmap.exe (если вы не установили его в другую папку, отличную от папки по умолчанию).
Программу SMSMap можно запустить на любом компьютере; ее не обязательно запускать с сервера узла (маловероятно, что на многих серверах узла SMS установлена Visio). Введите имя сервера сайта SMS источника запроса. Это может быть центральный сайт, если необходимо выполнить запрос всей иерархии, или это может быть любой дочерний основной сервер сайта, но в этом случае будет получена только иерархия дочернего основного сайта. Далее, введите учетную запись с разрешением на запрос SMS в формате домен\имя пользователя и пароль для этой учетной записи. (Пароль не будет отображаться, поэтому его можно вводить в присутствии других лиц.)
Шесть переключателей позволяют выбрать компоновку; также можно выбрать отображение или отсутствие ролей SMS на рисунке. Эти флажки расположены на вкладке «Options» (Параметры). При нажатии кнопки «Draw» (Рисование) запускается служебная программа. Сначала она проверяет наличие Visio, затем запрашивает указанный основной сервер узла SMS и добавляет объекты в диаграмму Visio. При загрузке программой SMSMap объектов диаграмма Visio может выглядеть некрасиво, но в конце процесса программа систематизирует объекты в указанном формате.
Погружение глубже
Теперь вы знакомы с процессом документирования иерархии SMS с помощью SMSMap и с причинами необходимости этого. Для тех, кто хочет расслабить мышцы, отвечающие за разработку, давайте подробно рассмотрим работу служебной программы.
SMSMap использует управляемые интерфейсы сервера узла SMS для сбора информации SMS и основные сборки взаимодействия Visio для создания диаграммы Visio со всеми необходимыми фигурами. Комплект SDK для SMS 2003 версии 3.1 содержит последний выпуск управляемых интерфейсов сервера сайта SMS. Этот набор управляемых интерфейсов позволяет настраивать и подключаться к серверу сайта SMS с помощью любого приложения или языка с поддержкой Microsoft .NET.
Эти интерфейсы используют пространство имен System.Management для взаимодейстия с поставщиком SMS через инструментарий Windows® Management Instrumentation (WMI). Для использования интерфейсов необходимо разработать приложение на языке, совместимом с .NET (например, C#, Visual Basic .NET и т.д.), и сослаться на библиотеку Microsoft.SystemsManagementServer.Automation.dll, входящую в сборку .NET в комплекте SDK для SMS.
Классы управления .NET стирают множество вызывающих раздражение особенностей объектной модели WMI для создания последовательной объектно-ориентированной модели. Основные задачи подключения WMI, перечисления объектов, выполнения метода, удаления объекта, получения объекта и записи событий могут быть осуществлены с помощью классов управления .NET.

Основные сборки взаимодействия Visio
Основная сборка взаимодействия позволяет использовать управляемый код для программного управления приложениями COM, такими как Visio. Основные сборки взаимодействия Visio позволяют объединить и расширить функции Visio в управляемые приложения.
Если на компьютере уже установлена платформа .NET Framework, при последующей установке Visio программа установки добавит основные сборки взаимодействия Visio в глобальный кэш сборок (GAC) на вашем компьютере. Можно добавить ссылку на основные сборки взаимодействия Visio из управляемых приложений.
После добавления ссылки на проект можно начать работу с объектами Visio из управляемого приложения. Visio имеет обширную объектную модель, предоставляющую набор классов, интерфейсов и перечислений для программного создания диаграмм.

Работа программы
Теперь, после описания интерфейсов основных компонентов для Visio и SMS, я объясню систему работы самой программы.
Первым шагом при использовании управляемых интерфейсов является подключение к поставщику SMS. Это может быть выполнено с помощью создания нового экземпляра класса SMSProvider. Этот класс выполняет внутренний поиск поставщика SMS для указанного сервера сайта и подключается к нему с определенным набором учетных данных. Если поставщик находится на локальном компьютере, при подключении к поставщику вместо предоставленных учетных данных будут использоваться текущие зарегистрированные в системе учетные данные. Хотя можно запустить программу SMSMap на сервере SMS, я рекомендую запускать ее на отдельной рабочей станции с установленной Visio. На большинстве серверов SMS программа Visio не установлена по очевидным причинам.
При доступе к данным на узле SMS через класс SMSProvider права доступа толкуются так же, как и при использовании административной консоли SMS. Это означает, например, что при попытке настройки параметров для сервера сайта с помощью SMSProvider подключенная к поставщику учетная запись должна иметь такой же набор прав, как и при использовании консоли администратора.
Класс SMSProvider предоставляет метод GetSiteSettings, позволяющий получить параметры для текущего сайта (которому принадлежит поставщик) или для любого сайта с определенным кодом сайта. Фрагмент кода на рис. 3 показывает подключение SMSMap к поставщику для необходимого сервера сайта. Учетные данные пользователя должны быть переданы в формате Domain\User. Также можно указать "." для обозначения текущего компьютера. На рис. 3 также показан код для отображения результатов в пользовательском интерфейсе и для ведения журнала.
Figure 3 Фрагмент GetSiteSettings (Close Figure 3)
Imports System.Management
Imports Microsoft.SystemsManagementServer.Automation

 oProvider = New SMSProvider(txtServer.Text, txtUser.Text, txtPassword.Text)
 oSite = oProvider.GetSiteSettings()
 Trace.WriteLine(“Connected to “ & txtServer.Text & “: “ & My.Computer.Clock.LocalTime)
 ListBox1.Items.Add(“Connected to “ & txtServer.Text & “: “ & My.Computer.Clock.LocalTime)
 Application.DoEvents()
...
Следующим шагом является настройка файла XML для сбора и записи информации SMS для нужного сервера сайта, как показано на рис. 4.
Figure 4 Создание файла XML (Close Figure 4)
‘ First, Create the XML File
 oWriter = New XmlTextWriter(m_sXmlFile, System.Text.Encoding.UTF8)
 oWriter.WriteStartDocument()
 oWriter.WriteStartElement(“Hierarchy”)

 ‘ Export Target Site to XML
 oWriter.WriteStartElement(“Site”)
 oWriter.WriteAttributeString(“Code”, oSite.SiteCode.ToString.ToUpper)
 oWriter.WriteStartElement(“SiteServer”)
 oWriter.WriteAttributeString(“Name”, oSite.SiteServer.ToString.ToUpper)
 oWriter.WriteEndElement()
 oWriter.WriteStartElement(“ParentSiteCode”)
 oWriter.WriteAttributeString(“SiteCode”, “THIS_IS_THE_TOP”)
 oWriter.WriteEndElement()

...
Далее, на схеме Visio должен быть нарисован целевой сайт, а пользовательский интерфейс и журнал должны быть обновлены, как показано на рис. 5.
Figure 5 Рисование сайта в Visio (Close Figure 5)
 ‘Draw Central Site
 dblXLocation = 4.25
 dblYLocation = 8.5
 vApp = New Visio.Application()
 vDoc = vApp.Documents.Add(“”)
 vStencil = vApp.Documents.OpenEx(TEMPLATEPATH, 4)
 ‘ Add Layers
 vExistingLayers = CType(vDoc.Pages(1).Layers, Visio.Layers)
 vLayer = CType(vExistingLayers.Add(“Site”), Microsoft.Office.Interop.Visio.Layer)

...

 If oSite.SiteType = SiteTypes.PrimarySite Then
 vFlowChartMaster = vStencil.Masters(“Primary Site”)
 ElseIf oSite.SiteType = SiteTypes.SecondarySite Then
 vFlowChartMaster = vStencil.Masters(“Secondary Site”)
 End If
 vToShape = vApp.ActivePage.Drop(vFlowChartMaster, dblXLocation, dblYLocation)
 vLayer.Add(vToShape, preserveMembers)

...
Для обработки всей иерархии целевого сайта выполняется простой описанный выше код для запроса SMS и рисования в Visio. Это функция с именем Level, рекурсивно вызываемая для проверки запроса всех дочерних сайтов независимо от размера иерархии. Функция Level собирает информацию сайта SMS и записывает ее в файл XML, пользовательский интерфейс и журнал для всех дочерних сайтов целевого сайта. Наконец, на рис. 6 показана схема Visio в выбранном при запуске программы формате. Затем файл XML и файл журнала закрываются.
Figure 6 Завершение (Close Figure 6)
 vDoc.Pages(1).Layout()
 vDoc.Pages(1).ResizeToFitContents()

 ‘Calculate the page width and height with a 5% boundary
 visCell = vDoc.Pages(1).PageSheet.Cells(“PageHeight”)
 dHeight = visCell.Result(“in”)
 visCell = vDoc.Pages(1).PageSheet.Cells(“PageWidth”)
 dWidth = visCell.Result(“in”)
 dHeight = dHeight + 1
 dWidth = dWidth + 1
 vDoc.Pages(1).PageSheet.Cells(“PageHeight”).Result(“in”) = dHeight
 vDoc.Pages(1).PageSheet.Cells(“PageWidth”).Result(“in”) = dWidth
 vDoc.Pages(1).CenterDrawing()
 Trace.WriteLine(“Arranged Sites “ & oSite.SiteServer & “: “ & My.Computer.Clock.LocalTime)
 ListBox1.Items.Add(“Arranged Sites “ & oSite.SiteServer & “: “ & My.Computer.Clock.LocalTime)
 vFlowChartMaster = vStencil.Masters(“Background world”)
 vApp.ActivePage.Drop(vFlowChartMaster, 0, 0)

 ‘Finish up
 vDoc.SaveAs(SAVENEWFILE)
 vDoc.Close()
 vApp.Quit()
 vDoc = Nothing
 vApp = Nothing
 GC.Collect()

...

Только начало
Конечно это только начала и много возможностей можно улучшить. Необходимо исследовать точки управления устройством, поскольку я не вижу их в SDK. Для полного документирования сайта необходимо добавить ряд дополнительных параметров сайта. Возможно, необходимо выполнить некоторую другую работу для добавления различных параметров макета Visio для улучшения представления небольших и больших иерархий. Каждый тип макета создает собственные трудности при попытке создания эффективного отображения. И, конечно же, очень важным следующим этапом является добавление поддержки диспетчера System Center Configuration Manager 2007. Но даже первая версия SMSMap может помочь администраторам SMS в представлении большого изображения и проверке некоторых ситуаций «что, если» со слоями и прозрачностью Visio.
С помощью загрузки данного кода вы можете расширить возможности программы в соответствии с вашими требованиями. Я протестировал SMSMap в операционной системе Windows XP с пакетом обновления (SP2) с Visio 2003 и Windows Vista™ Enterprise с Visio 2007. Если у вас есть предложения по улучшению программы, отправьте их по адресу jeff.tondt@microsoft.com.

Джефф Тондт (Jeff Tondt) - старший консультант II класса в консультационной службе корпорации Майкрософт. Он занимается управлением системами, автоматизацией и управлением исправлениями. Он является экспертом по SMS, с ним можно связаться по адресу jeff.tondt@microsoft.com.


 Принцип работы: Устранение ошибок удаленного вызова процедур
Принцип работы
Устранение ошибок удаленного вызова процедур
Зубаир Александр

Если вы работали с серверными платформами Windows в течение нескольких лет, то, вероятно, время от времени встречали ошибки удаленного вызова процедур. Ошибки связаны с недоступностью сервера RPC, отсутствием доступных конечных точек или с иными непонятными предупреждениями. Если подобные сообщения приводят вас в замешательство, прочитайте статью. Я
рассмотрю некоторые общие ошибки, различные методы для определения возникших ошибок RPC, а также покажу некоторые решения для разрешения определенных проблем. До начала рассмотрения определенных ошибок RPC и решений давайте разберемся с терминологией RPC.

Что такое RPC?
RPC – это метод межпроцессного взаимодействия (IPC), используемый клиентами и серверами для связи. Проще говоря, RPC используется программами, обычно на клиентском компьютере, для выполнения программы на серверном компьютере. Например, клиенты Microsoft® Outlook® связываются с Microsoft Exchange Server с помощью RPC. Клиентский компьютер отправляет сообщение серверу с определенными аргументами. Сервер отвечает клиенту сообщением с результатами выполненной программы.
Неотъемлемой частью этого процесса является конечная точка – имя, порт или группа портов на компьютере, который отслеживается сервером на предмет входящих клиентских запросов. Если более точно, это зависящий от сети адрес серверного процесса, используемого для вызовов RPC.
Система отображения конечных точек, которая является частью подсистемы RPC, ответственна за ответы на запросы клиентов на разрешение динамических конечных точек. В некоторых ситуациях система отображения конечных точек также ответственна за динамическое назначение конечных точек серверам.
Другим важным компонентом RPC является служба локатора. Она поддерживает список серверов и служб RPC в сети. Клиент Windows® подключается к контроллеру домена через порты протокола SMB (TCP 139 и 445) и выполняет поиск серверов или служб RPC с помощью службы локатора.
Большинство встроенных служб Windows связываются друг с другом с помощью RPC. Например, службы сертификации, DCOM, FRS, MSMQ, MAPI и служба репликации Active Directory® используют RPC для связи между собой. Поэтому при неправильной работе службы RPC в сети может возникнуть неопределенное количество проблем связи.

Ошибки RPC
Теперь рассмотрим некоторые из ошибок, которые могут произойти при сбое службы RPC. (Это ни в коем случае не исчерпывающий список.)
При сбое службы репликации файлов может возникнуть ужасная ошибка «RPC Unavailable». При подключении диска может появиться ошибка «Отказано в доступе». При использовании оснастки «Active Directory – пользователи и компьютеры» может появиться ошибка «Указанный домен не существует или с ним невозможно связаться». При входе в домен может появиться ошибка «The system cannot log you on to this domain because the system’s computer account in its primary domain is missing or the password on that account is incorrect».
При попытке клиента Microsoft Outlook связаться с Exchange Server сбой RPC может привести к появлению вводящих в заблуждение ошибок, таких как «Your logon information is incorrect» или «Outlook could not log on».
Кроме этих ошибок, при недоступности службы RPC могут возникнуть другие проблемы. Например, просмотр домена в сетевом окружении может быть невозможен или может быть невозможно открыть оснастку «Групповая политика».
Это только несколько примеров, в которых не ожидается возникновение проблем от вызовов RPC. Примеров гораздо больше, и при каждом использовании удаленных процессов проблемы с RPC могут быть исходной причиной ваших трудностей. Итак, как точно узнать и, что более важно, как обнаружить конкретную ошибку? Давайте выясним.

Устранение неполадок
Если возникают подозрения на наличие проблем со службой RPC, можно использовать несколько инструментов для диагностики проблем.
Можно использовать средство Repadmin. Эта программа обычно используется для наблюдения и устранения проблем репликации Active Directory, но она также может использоваться для устранения проблем системы отображения конечных точек RPC. Для запуска средства в командной строке введите repadmin /bind. При возникновении проблем RPC может появиться, например, следующее сообщение: «В системе отображения конечных точек не осталось доступных конечных точек». Это первое указание на то, что проблема связана с RPC.
Другой возможностью является использование средства диагностики контроллера домена (DCDiag), программы командной строки для диагностики проблем контроллеров домена. При появлении ошибки «Status is 1722: The RPC server is unavailable» (Состояние 1722: сервер RPC недоступен) вы знаете о наличии проблемы с RPC, которую только что обнаружило средство диагностики контроллера домена.
Иногда при использовании средства Ntdsutil (средство командной строки для управления Active Directory и выполнения различных задач обслуживания) могут появляться ошибки RPC при попытке подключения к серверу. Вероятнее всего вы увидите одну из наиболее часто встречающихся ошибок, например «В системе отображения конечных точек не осталось доступных конечных точек». И вновь это свидетельствует о возможных проблемах службы RPC. Средство Gpotool, проверяющее согласованность объектов групповой политики на контроллерах доменов, также выдаст похожие ошибки, если их причиной является RPC.
В журнале Dcpromo.log, созданный при повышении роли сервера Windows 2000 Server или Windows Server® 2003 до контроллера домена с помощью средства Dcpromo, также могут регистрироваться проблемы RPC. Например, при сбое повышения роли просмотрите журнал. Он находится в папке %windir%\debug. Перечисленные ошибки укажут на причину сборя службы каталогов при репликации раздела или создании объекта. В конце сообщения будет указан код ошибки. Ниже приведен пример типа сообщений об ошибках, которые регистрируются в журнале Dcpromo.log:

08/14 10:35:04 [INFO] Error - The Directory Service failed to replicate
 the partition CN=Schema,CN=Configuration,DC=.. (1722) 08/14 10:35:04 [INFO]
  NtdsInstall for dc.contoso.com. returned 1722 08/14 10:35:04 [INFO]
   DsRolepInstallDs returned 1722 08/14 10:35:04 [ERROR] Failed to install
    the directory service (1722)
Обратите внимание на код ошибки 1722, который четыре раза встречается в этом сообщении и обозначает недоступность сервера RPC. На рис. 1 приведены некоторые коды ошибок и их описания, но множество других кодов ошибок приведено на веб-узле msdn2.microsoft.com/ms681386.
Figure 1 Коды ошибок и их описания (Close Figure 1)

Код ошибки | Описание
58 | Указанный сервер не может выполнить запрашиваемую операцию.
1721 | Недостаточно ресурсов для выполнения операции.
1722 | Сервер RPC недоступен.
1723 | Сервер RPC слишком занят для выполнения операции.
1727 | Сбой удаленного вызова процедур, он не выполнен.
1753 | Для системы отображения конечных точек отсутствуют свободные конечные точки.

Разрешение ошибок RPC
Теперь, после того как вы узнали об определении некоторых ошибок RPC, давайте рассмотрим некоторые решения.
Клиенты Microsoft подключаются к системе отображения конечных точек RPC через порт 135. Затем система отображения конечных точек сообщает клиенту порт, прослушиваемый запрошенной службой. Номера портов назначаются динамически и могут находиться в диапазоне от 1024 до 65 535. Появление ошибок, таких как 1753, означает, что для системы отображения конечных точек отсутствуют доступные конечные точки, что свидетельствует о том, что система отображения конечных точек RPC не смогла использовать для служб порт с номером более 1024. Я более подробнее рассмотрю это позже.
Прежде всего необходимо проверить состояние службы RPC на сервере. В зависимости от типа роли сервера служба RPC и служба локатора RPC должны иметь состояние, указанное на рис. 2. Если одна из двух служб не настроена так, как показано на рисунке, попробуйте настроить состояние, перезагрузите сервер и проверьте наличие проблемы.
Figure 2 Состояние службы RPC (Close Figure 2)

Роль сервера | Служба RPC | Служба локатора RPC
Windows Server 2003 — контроллер домена | Запущена, автоматически | Остановлена, вручную
Windows Server 2003 — рядовой сервер | Запущена, автоматически | Остановлена, вручную
Windows Server 2003 — изолированный сервер | Запущена, автоматически | Остановлена, вручную
Windows 2000 Server — контроллер домена | Запущена, автоматически | Остановлена, автоматически
Windows 2000 Server — рядовой сервер | Запущена, автоматически | Запущена, вручную
Windows 2000 Server — изолированный сервер | Запущена, автоматически | Остановлена, вручную
Убедитесь, что клиент может успешно проверить связь с сервером с проблемами подключения. Например, при наличии проблем связи с сервером DC1 с IP-адресом 192.168.1.200 используйте следующую команду командной строки, чтобы убедиться, что DNS верно разрешает узел DC1:
Ping –a 192.168.1.200
С ключом –a необходимо использовать IP-адрес, а не имя узла.
Если все работает, вы должны получить ответ от DC1, который выглядит как ответ проверки связи, показанный на рис. 3. Обратите внимание, что вместо простого разрешения IP-адреса 192.168.1.200 проверка связи также разрешает имя узла dc1.contoso.com. Это подтверждает, что разрешение имен с помощью DNS работает правильно, и разрешение узла dc1.contoso.com выполняется так, как ожидалось.
Figure 3 Ответ команды ping (Close Figure 3)
C:\WINDOWS>ping -a 192.168.1.200

Pinging dc1.contoso.com [192.168.1.200] with 32 bytes of data:

Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.1.200:
  Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
  Minimum = 0ms, Maximum = 0ms, Average = 0ms
Кроме того, необходимо убедиться, что реестр клиента Windows XP или Windows 2000 содержит как минимум четыре протокола ClientProtocols, указанных на правой панели на рис. 4.
Рис. 4 Перечисленные в реестре протоколы ClientProtocols RPC
Рис. 4 Перечисленные в реестре протоколы ClientProtocols RPC
Если какие-либо записи отсутствуют, добавьте новый строковый параметр с именем и типом, показанными на рис. 4. По умолчанию существует пятая запись с именем ncacn_nb_tcp, которая используется для определения NetBIOS по TCP как семейства протоколов для конечной точки. В зависимости от настройки эта запись среди протоколов ClientProtocol может отсутствовать, в этом случае ее можно добавить вручную и посмотреть, поможет ли это разрешению проблем с RPC.
Обратите внимание на параметры в папке Rpc в левой панели рисунка, а именно ClientProtocols, NameService, NetBios и SecurityService. Если присутствует параметр Internet без значения, удалите его и перезагрузите компьютер. Это может разрешить проблему. Как обычно, необходимо быть осторожным при изменении реестра Windows.
Как упоминалось ранее, RPC может использовать порты от 1024 до 65 535, поэтому необходимо убедиться, что эти порты не заблокированы брандмауэром. Самым простым способом определения того, что порт открыт, является использование средства Port Query. Существует две версии этого средства: версия для командной строки (PortQry) и версия с графическим интерфейсом (PortQueryUI).
Средство PortQry доступно для загрузки в центре загрузки Microsoft. Для получения дополнительных сведений ознакомьтесь со статьей «Description of the Portqry.exe Command-Line Utility» (Описание программы командной строки Portqry.exe). В статье приведены краткие описания отчетов PortQry о состоянии и примеры команды для разрешения проблем. Имейте в виду, что также можно использовать версию с графическим интерфейсом, которая намного проще и которую можно загрузить с веб-узла go.microsoft.com/fwlink/?LinkId=73740.
Средство Port Query должно быть запущено на компьютере без ошибок RPC, а затем запущено на компьютере с проблемами с RPC. Например, что проверить, что порт 135, который используется системой отображения конечных точек RPC, открыт, используйте средство PortQry в командной строке следующим образом:
portqry -n [servername] -e 135
Как при использовании PortQuery, так и при использовании PortQueryUI вы получите результаты наподобие следующих:
Starting portqry.exe -n 192.168.1.200 -e 135 -p TCP ...
Querying target system called:
 192.168.1.200
Attempting to resolve IP address to a name...
IP address resolved to dc1.contoso.com
querying...

TCP port 135 (epmap service): LISTENING
Последняя строка показывает, что порт 135 открыт. В противном случае в последней строке содержалось бы NOT LISTENING.
Для проверки диапазона портов введите номера портов диапазона, разделенные запятыми, например «135,1024-5000»".

Дополнительные решения
Если вы использовали все указанные приемы, но проблему разрешить не удается, существует несколько дополнительных решений. В зависимости от определенных проблем в вашей среде вы можете выполнить одно из следующих изменений реестра. (Подождите. Перед изменением реестра необходимо сделать резервную копию системы, в особенности реестра, чтобы в случае сбоя можно было восстановить предыдущее состояние компьютера.)
Первым способом является изменение параметра MaxUserPort, чтобы в нем указывалось наибольший номер порта, который может назначить TCP при запросе приложением доступного порта пользователя. По умолчанию Windows Server 2003 устанавливает для параметра MaxUserPort значение 5000, что означает, что наибольший номер порта – 5000, даже если такого параметра не существует. В зависимости от настройки эта запись может отсутствовать в реестре; в этом случае можно добавить эту запись в местоположение, показанное на рис. 5.
Рис. 5 Параметр MaxUserPort в реестре
Рис. 5 Параметр MaxUserPort в реестре
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Port range = 5000 – 65534
Default = 5000
При изменении реестра необходимо помнить о возможных побочных эффектах, что не всегда просто. Изменение этой записи может повлиять на Microsoft Exchange Server, если установлено значение ниже 50 000. Если анализатор соответствия рекомендациям для Exchange Server обнаруживает, что значение раздела реестра MaxUserPort менее 50 000, отображается предупреждение. Корпорация Майкрософт рекомендует установить значение 60 000; в противном случае могут появиться предупреждения прокси NSPI, например событие 9040. Для получения дополнительных сведений см документе «MaxUserPort Value is Too Low» (Значение параметра MaxUserPort слишком низкое) корпорации Майкрософт.
Кроме того, можно изменить значение TcpMaxDataRetransmissions. Для пакетов TCP необходимо подтверждение принимающей стороны. При отсутствии подтверждения до истечения времени передача пакетов повторяется количество раз, определенное параметром TcpMaxDataRetransmissions. Значение этого параметра по умолчанию – 5, но вы можете изменить значение на 4 или даже 3. Но нельзя использовать значение меньше 3.
Если параметр реестра TcpMaxDataRetransmissions не существует, его можно добавить в следующее место реестра:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Valid range = 0 - 0xFFFFFFFF (hexadecimal)
Default = 5
Для получения дополнительных сведений о разделе TcpMaxDataRetransmissions ознакомьтесь со статьей 170359 «How to Modify the TCP/IP Maximum Retransmission Timeout» (Изменение тайм-аута максимального количества повторных передач TCP/IP) базы знаний Майкрософт.
Другое значение, которое можно попробовать изменить, – TcpTimedWaitDelay. Если клиент использует большое количество портов, порты могут закончиться до того, как TCP/IP освободит закрытые подключения. Это происходит из-за того, что TCP/IP не освобождает подключение до истечения двух максимальных сроков жизни сегментов (MSL) (это называется состоянием времени ожидания). Более того, поскольку каждый MSL определен как 120 секунд, TCP/IP не освобождает подключение до истечения двух MSL; освобождение TCP/IP закрытого подключения занимает 240 секунд (4 минуты). Это было известной проблемой Windows NT®, которая были исправлена в пакете обновления; в результате появление этой проблемы сегодня маловероятно. Однако корпорация Майкрософт рекомендует изменить этот параметр как одно из возможных решений для разрешения ошибок системы отображения конечных точек RPC, как было объяснено в статье базы знаний Майкрософт «How to Troubleshoot RPC Endpoint Mapper Errors» (Устранение ошибок системы отображения конечных точек RPC).
Параметр TcpTimedWaitDelay добавляется в следующее местоположение в реестре:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Range: 30 - 300 (decimal)
Default: 0xF0 (240 decimal)
Для получения дополнительных сведений о параметре TcpTimedWaitDelay ознакомьтесь со статьей базы знаний «Windows NT Clients Run Out of Ports» (Порты клиентов Windows NT заканчиваются). Хотя в статье отсутствуют какие-либо рекомендованные конкретные значения, можно попробовать уменьшить значение TcpTimedWaitDelay до 60 (секунд) в десятичном выражение, что составляет 3c в шестнадцатеричном выражении.

Заключение
Ошибки RPC могут являться исходной причиной различных ошибок связи в сети. К счастью, существует несколько изобретательных способов устранения этих трудных проблем. Некоторые предложенные средства являются встроенными, другие имнются в комплекте Windows Server Resource Kit. Многие из них приведены на рис. 6. Эти средства можно использовать для определения причины и месторасположения ошибок RPC и последующего использования одного из описанных в данной статье метода для устранения ошибок.
Figure 6 Средства устранения неполадок RPC (Close Figure 6)

Средство | Описание
DCDiag | Анализ состояния контроллеров домена.
Просмотр событий | Отображение зарегистрированных событий.
Gpotool | Определение верности и согласованности политик.
NetDiag | Проверка работоспособности сети.
Сетевой монитор | Отслеживание и запись сетевого трафика.
Ntdsutil | Предоставляет средства управления для Active Directory.
PortQry, PortQueryUI | Используется для проверки подключения TCP/IP.
Repadmin | Диагностика проблем репликации контроллеров домена Windows.
RPCDump | Обычно используется вместе с сетевым монитором.
RPCPing | Используется для подтверждения подключения RPC.

Зубаир Александр, обладатель званий MCSE, MCT и Microsoft MVP, является владельцем компании SeattlePro Enterprises, занимающейся обучением и консультациями в области информационных технологий. Его опыт работы охватывает различные сферы обучения информационным технологиям: автор, преподаватель в колледже, консультант, сетевой инженер, докладчик, архитектор безопасности, системный администратор, технический редактор и преподаватель. С ним можно связаться по адресу alexander@techgalaxy.net.


 Кабельщик: Трафик IPv6 через подключения VPN
Кабельщик
Трафик IPv6 через подключения VPN
Джозеф Дэвис (Joseph Davies)

При оценке роли связи по протоколу Интернета 6-й версии (IPv6) интрасети и начале планирования его развертывания, необходимо понять способ поддержки трафика IPv6 через подключения виртуальной частной сети (VPN) в Windows. Подключения VPN позволяют расширять сеть, чтобы включать связь через такие общедоступные
сети, как Интернет. Подключения VPN защищены надежными протоколами проверки подлинности для проверки учетных данных подключающегося пользователя и методами шифрования для обеспечения конфиденциальности данных.
В состав Windows® XP и Windows Server® 2003 входит стек протокола IPv6, но многие основные службы и сетевые компоненты не поддерживают IPv6. Windows Vista™ и Windows Server 2008, прежнее кодовое имя «Longhorn», имеют полнофункциональную поддержку IPv6, установленную и включенную по умолчанию. На самом деле, почти все сетевые приложения и службы, включенные в Windows Vista и Windows Server 2008, поддерживают IPv6. В этом месяце я проверял поддержку в Windows Vista, Windows Server 2008, Windows XP, и Windows Server 2003 трафика IPv6, отправленного через подключения VPN, созданные через протоколы Интернета 4-й версии (IPv4) и 6-й версии (IPv6).

Подключения VPN через протокол Интернета IPv4
Для большинства современных интрасетей подключения VPN создаются через протокол Интернета IPv4. Нарис. 1 показаны компоненты Windows для этого типа подключений VPN. Эти компоненты состоят из:
Рис. 1 Компонентов Windows для подключений VPN через протокол Интернета IPv4
Рис. 1 Компонентов Windows для подключений VPN через протокол Интернета IPv4
VPN-клиент Это компьютер, который запускает подключение VPN удаленного доступа к серверу VPN и связывается с ресурсами интрасети. Подключения VPN удаленного доступа позволяет клиенту VPN действовать так, как если бы он бы подключен к интрасети напрямую. Клиент VPN может запускать как клиентскую версию Windows, так и версию Windows Server.
VPN-сервер Данный компьютер находится в ожидании попыток подключений VPN удаленного доступа, поддерживает проверку подлинности и требования подключения, и передает пакеты между клиентом VPN и ресурсами интрасети. Обычно сервер VPN запускает версию Windows Server со службой маршрутизации и удаленного доступа.
VPN-маршрутизатор Маршрутизатор VPN является компьютером, запускающим или ожидающим попытки подключений VPN типа "сеть-сеть". Подключение VPN типа "сеть-сеть" соединяет вместе две части интрасети. Маршрутизатор VPN запускает версию Windows Server и службу маршрутизации и удаленного доступа.
Подключение VPN Подкючение VPN является логической связью между клиентом VPN и сервером VPN или между маршрутизаторами VPN, как определено инкапсуляцией протокола VPN.
Интрасеть с поддержкой IPv6 Эта интрасеть может пересылать трафик IPv6, либо непосредственно, либо с помощью пакетов IPv4.
Узел IPv6/IPv4 Узел интрасети отправляет и принимает трафик IPv6, либо непосредственно, либо с помощью пакетов IPv4.
Для инкапсуляции пакетов, отправленных через подключения VPN, клиенты VPN на основе Windows, серверы и маршрутизаторы могут использовать следующие протоколы VPN: Протоколы PPTP, L2TP через IPsec и SSTP. SSTP поддерживается только Windows Vista с пакетом обновления 1 (SP1, сейчас проходит этап предварительного тестирования) и Windows Server 2008.
Для подключений VPN через протокол Интернета IPv4 существуют два метода отправки IPv6: пакеты IPv6 передаются с помощью пакетов IPv4 (и далее называются трафиком IPv6 через IPv4), и непосредственно трафиком IPv6.
В этой статье поддержка трафика IPv6 через подключения VPN сформулирована в терминах протоколов VPN и версий Windows. Для подключений VPN удаленного доступа данное сочетание протокола VPN и версии Windows означает поддержку компонентов клиента и сервера удаленного доступа Windows.

Трафик IPv6 через IPv4
В этом методе клиент удаленного доступа или узел IPv6/IPv4 интрасети инкапсулирует пакеты IPv6 с заголовком IPv4 и отправляет полученное как пакеты IPv4. Для интрасетей технология перехода по протоколу IPv6 ISATAP (IntraSite Automatic Tunnel Addressing Protocol) (RFC 4214) позволяет узлам IPv6/IPv4 обмениваться трафиком IPv6 через интрасеть IPv4. ISATAP обеспечивает возможность подключения IPv6 к интрасети IPv4 без необходимости настройки или обновления имеющихся маршрутизаторов для поддержки исходной адресации и переадресации IPv6. Для получения дополнительных сведений о ISATAP см. в «Технологии перехода IPv6» на microsoft.com/technet/network/ipv6/ipv6coexist.mspx.
Нарис. 2 показана общая структура пакетов для трафика VPN при отправке пакетов IPv4 с помощью подключения VPN через протокол Интернета IPv4. Пакет IPv4 инкапсулирован протоколом VPN с заголовком и, в зависимости от этого протокола, эпилогом. Результирующий пакет инкапсулирован с заголовком IPv4, допускающим переадресацию через протокол Интернета IPv4.
Рис. 2 Пакеты IPv4 используют VPN-подключения через протокол Интернета IPv4
Рис. 2 Пакеты IPv4 используют VPN-подключения через протокол Интернета IPv4
Для трафика IPv6 через IPv4 полезные данные пакета IPv4, отправленные через подключение VPN, являются пакетом IPv6. Нарис. 3 показана общая структура пакетов для трафика VPN при отправке пакетов IPv6 через IPv4 с помощью подключения VPN через протокол Интернета IPv4.
Рис. 3 Пакеты IPv6 через IPv4 используют подключения через протокол Интернета IPv4
Рис. 3 Пакеты IPv6 через IPv4 используют подключения через протокол Интернета IPv4
Для подключений VPN удаленного доступа трафик IPv6 через IPv4 через протокол Интернета IPv4 поддерживается PPTP и L2TP/IPsec в Windows Vista, Windows Server 2008, Windows XP SP1 или выше и Windows Server 2003 и с помощью SSTP в Windows Vista SP1 и Windows Server 2008. Для подключений VPN типа "сеть-сеть" трафик IPv6 через IPv4 через протокол Интернета IPv4 поддерживается PPTP и L2TP/IPsec в Windows Server 2008 и Windows Server 2003.

Исходный трафик IPv6
Для исходного трафика IPv6 клиент VPN, сервер или маршрутизатор посылает пакеты IPv6 через подключения VPN без первоначальной инкапсуляции IPv4. Это подходит для интерсетей, изначально имеющих возможности подключения IPv6, для которых требуются, чтобы клиенты VPN, серверы и маршрутизаторы поддерживали протокол управления IPv6 (IPV6CP), RFC 2472, определяющий способы согласования узлами IPv6 параметров настройки для подключений протокола PPP. Windows Vista и Windows Server 2008 поддерживают IPV6CP, а Windows XP и Windows Server 2003 нет. Нарис. 4 показана общая структура пакетов для трафика VPN при отправке исходных пакетов IPv6 с помощью подключения VPN через протокол Интернета IPv4.
Рис. 4 Пакеты IPv6 используют подключение VPN через протокол Интернета IPv4
Рис. 4 Пакеты IPv6 используют подключение VPN через протокол Интернета IPv4
Для подключений VPN удаленного доступа исходный трафик IPv6 через протокол Интернета IPv4 поддерживается PPTP и L2TP/IPsec в Windows Vista и Windows Server 2008 и с помощью SSTP в Windows Vista SP1 и Windows Server 2008. Для подключений VPN типа "сеть-сеть" исходный трафик IPv6, передаваемый через протокол Интернета IPv4, поддерживается PPTP и L2TP/IPsec в Windows Server 2008.

Подключения VPN через протокол Интернета IPv6
Возможно создание подключений VPN через протокол Интернета IPv6. Такие подключения VPN в настоящий момент не распространены широко, но будут распространяться по мере развития предложения поставщиками услуг Интернета IPv6 своим клиентам, а также с увеличением использования протокола Интернета IPv6 организациями в своих сетях.
Для поддержки подключений VPN через протокол Интернета IPv6 используемые протоколы VPN должны поддерживать подключения через IPv6. В Windows Vista и Windows Server 2008 протоколы L2TP/IPsec и SSTP VPN поддерживают подключения VPN удаленного доступа через IPv6. В Windows Server 2008, L2TP/IPsec поддерживает подключения типа «сеть-сеть» через IPv6. Подключения VPN через протокол Интернета IPv6 используют тот же набор компонентов, что и те, которые используются для подключений VPN через протокол Интернета IPv4 как для подключений VPN удаленного доступа, так и для подключений VPN типа «сеть-сеть».
Имеется два способа отправки пакетов IPv6 через протокол Интернета IPv6: трафик IPv6 через IPv4 и исходный трафик IPv6. На рис. 5 показана общая структура пакетов IPv6 через IPv4, отправленных с помощью подключения VPN через протокол Интернета IPv6.
Рис. 5 Пакеты IPv6 через IPv4 используют подключение VPN через протокол Интернета IPv6
Рис. 5 Пакеты IPv6 через IPv4 используют подключение VPN через протокол Интернета IPv6
Для подключений VPN удаленного доступа трафик IPv6 через IPv4 через протокол Интернета IPv6 поддерживается L2TP/IPsec в Windows Vista и Windows Server 2008 и с помощью SSTP в Windows Vista SP1 и Windows Server 2008. Для подключений VPN типа «сеть-сеть» трафик IPv6 через IPv4 через протокол Интернета IPv6 поддерживается L2TP/IPsec в Windows Server 2008. Что касается трафика IPv6 через IPv4 через протокол Интернета IPv4, трафик IPv6 через IPv4 через протокол Интернета IPv6 требует разворачивания в интрасети технологии перехода IPv6, как, например, ISATAP.
Нарис. 6 показана общая структура исходных пакетов IPv6, отправленных с помощью подключения VPN через протокол Интернета IPv6. Так же как и исходный трафик IPv6 через протокол Интернета IPv4, исходный трафик IPv6 через протокол Интернета IPv6 требует поддержки IPV6CP и разворачивания в интрасети исходной связи IPv6.
Рис. 6 Исходные пакеты IPv6 используют подключения VPN через протокол Интернета IPv6
Рис. 6 Исходные пакеты IPv6 используют подключения VPN через протокол Интернета IPv6
Для подключений VPN удаленного доступа исходный трафик IPv6 через протокол Интернета IPv6 поддерживается L2TP/IPsec в Windows Vista и Windows Server 2008, и при помощи SSTP в Windows Vista SP1 и Windows Server 2008. Для подключений VPN типа "сеть-сеть" исходный трафик IPv6 через протокол Интернета IPv6 поддерживается L2TP/IPsec в Windows Server 2008.

Краткое заключение
Нарис. 7 показаны четыре метода отправки трафика IPv6 через подключения VPN и поддержка в Windows двух различных типов подключений VPN. В двух словах, при использовании в интрасети технологии перехода IPv6, например, ISATAP, трафик IPv6 через IPv4 можно отправлять через подключения VPN как по протоколу Интернета IPv4, так и по IPv6. Если интрасеть поддерживает связь по исходному IPv6, возможна отправка трафика IPv6 через подключения VPN по обоим протоколам Интернета IPv4 и IPv6 в Windows Vista и Windows Server 2008.
Figure 7 Поддержка трафика IPv6 через подключения VPN в Windows (Close Figure 7)

Метод отправки трафика IPv6 | Подключения VPN удаленного доступа | Подключения VPN типа «сеть-сеть»
Трафик IPv6 через IPv4 по протоколу Интернета IPv4 | PPTP и L2TP/IPsec в Windows Vista, Windows Server 2008, Windows XP SP1 или выше, и Windows Server 2003 SSTP в Windows Vista SP1 и Windows Server 2008 | PPTP и L2TP/IPsec в Windows Server 2008 и Windows Server 2003
Исходный трафик IPv6 по протоколу Интернета IPv4 | PPTP и L2TP/IPsec в Windows Vista и Windows Server 2008, SSTP в Windows Vista SP1 и Windows Server 2008 | PPTP и L2TP/IPsec в Windows Server 2008
Трафик IPv6 через IPv4 по протоколу Интернета IPv6 | L2TP/IPsec в Windows Vista и Windows Server 2008, SSTP в Windows Vista SP1 и Windows Server 2008 | L2TP/IPsec в Windows Server 2008
Исходный трафик IPv6 по протоколу Интернета IPv6 | L2TP/IPsec в Windows Vista и Windows Server 2008, SSTP в Windows Vista SP1 и Windows Server 2008 | L2TP/IPsec в Windows Server 2008

Джозеф Дэвис (Joseph Davies) работает разработчиком технической документации в корпорации Майкрософт. С 1992 года занимается преподаванием и пишет о сетях Windows. Джозеф Дэвис написал пять книг, опубликованных издательством Microsoft Press, и ведет ежемесячную рубрику TechNet «Кабельщик» .


 Windows PowerShell: Пересмотр понятия конвейера
Windows PowerShell
Пересмотр понятия конвейера
Дон Джонс (Don Jones)

О том, насколько необычной, новой и захватывающей является Windows PowerShell, было сказано много, несмотря на то, что эта среда основана на концепциях интерфейса командной строки, известных в течение десятилетий в основном в операционных системах на базе UNIX и Linux. Но распространенная терминология, которой совместно со своими потомками пользуется Windows PowerShell, может легко
отвлечь от подлинной гибкости и уникальности среды Windows PowerShell™ и ее выдающейся приспособленности к среде Windows®.
Одним из наиболее часто обсуждаемых компонентов Windows PowerShell является ее конвейер, но, к сожалению, он является также одним из самых неправильно понимаемых компонентов. Это объясняется тем, что он основан на терминологии, определения для которой были созданы в начале 1970-х гг. и которая в то время представляла совершенно другие, менее мощные функции.

Происхождение каналов
Первой из когда-либо созданных оболочек UNIX была оболочка shell Томпсона, которая была крайне примитивна и отличалась только наличием базовых элементов языка написания сценариев, не имевшего никаких переменных. У shell была преднамеренно скромная структура, поскольку ее единственная реальная цель заключалась в выполнении программ. Однако она ввела в обиход ключевую концепцию, оказавшую положительное влияние на другие оболочки того времени: концепцию конвейеров. Используя символы < и >, оболочке можно было передать инструкцию по направлению входных и выходных данных в другие команды и из них. Теперь пользователь мог, например, направить результат работы команды в файл.
Позднее этот синтаксис был расширен с тем, чтобы выходные данные одной команды можно было передавать с помощью конвейера на вход другой команды, что дает возможность при выполнении сложных задач объединять в цепочку длинные последовательности команд. К 4-й версии shell символ вертикальной черты «|» был принят для обозначения передачи по конвейеру и вследствие этого стал известен как символ конвейера. Даже в самых ранних версиях MS-DOS® были реализованы базовые операции с конвейером с использованием этих символов, что позволяло пользователю, например, передавать с помощью конвейера выходные данные команды type на вход команды more, обеспечивая постраничное отображение длинных текстовых файлов.
Хотя к моменту выпуска 6 версии UNIX в 1975 году было широко распространено мнение, что оболочка shell Томпсона не отвечает предъявляемым к ней требованиям, концепция конвейеров прочно внедрилась в сознание разработчиков оболочек и пользователей и была перенесена в ряд технологий, используемых до сегодняшнего дня.

Передача текста через конвейер
Почти все оболочки по сути ограничены своей текстовой природой. В операционных системах на базе UNIX это, фактически, является не ограничением, а отражением того, как работает сама операционная система. Почти все ресурсы в UNIX можно представить в виде некоторого типа файла, что означает, что способность передавать текст с помощью конвейера от одной команды к другой обеспечивает значительную мощность и гибкость.
Однако, когда доходит до управленческой информации, текст является очевидным ограничением. Например, если бы я представил вам список служб, выполняющихся на компьютере с операционной системой Windows, вы почти наверняка смогли бы его понять. Возможно, я поместил бы имя службы в первом столбце, а режим ее запуска — во втором. Мощный человеческий мозг незаметно и мгновенно анализирует или переводит изображенный текст в значащую информацию, с которой можно работать. Компьютеры, однако, не настолько сообразительны: чтобы компьютер сделал что-нибудь осмысленное с этим списком, потребовалось бы сообщить ему, возможно, что в первом столбце содержатся символы с 1-го по 20-й, а что символы от 22-го до 40-го образуют второй столбец и т.д..
Годами такой тип анализа текстового файла являлся единственным способом, которым администраторы могли объединять несколько команд в цепочку. Фактически, языки написания сценариев, такие как VBScript и Perl, превосходно справляются с манипуляцией строками главным образом по той причине, что им необходима способность принимать текстовый вывод от одной программы или команды, затем реструктурировать эти выходные данные в некоторый вид данных, удобный для использования в какой-либо последующей задаче. Например, я писал задания VBScript, которые принимают текстовый вывод команды Dir, анализируют в этом выводе имена и даты, затем перемещают старые, неиспользуемые файлы в архив. Анализ строк крайне сложен, поскольку исключения (вариации во входных данных) встречаются почти всегда, что требует повторного выполнения логики сценария, чтобы обработать все возможные перестановки.
Для написания административных сценариев или автоматизации в среде Windows анализ строк пригоден в меньшей степени. Это объясняется тем, что Windows сама по себе не хранит большие объемы информации в удобном для доступа текстовом формате. Вместо этого в ней используются ориентированные на данные хранилища, например, Active Directory®, реестр Windows и хранилище сертификатов, поэтому авторы сценариев должны использовать сначала одно средство для создания некоторого вида текстового вывода, а затем — сценарий для анализа этого текста и каких-либо операций над ним.

С объектами работать проще
Разработчики программного обеспечения Windows всегда поступали несколько проще. Исходно Майкрософт разработала COM специально для представления сложных внутренних рабочих компонентов Windows в удобном для использования виде. Сегодня Microsoft® .NET Framework продолжает выполнять эту же задачу — представляет внутренние рабочие компоненты программного обеспечения в стандартизованном виде.
В общем, как COM, так и .NET представляют элементы в виде объектов. (Разработчик программного обеспечения мог бы возразить против этого упрощения, но для нашего обсуждения такого упрощения вполне достаточно.) Все эти объекты имеют разные типы членов. Для наших целей наиболее интересны свойства и методы объектов. Свойство, по существу, некоторым способом описывает объект или изменяет объект или его поведение. Например, объект-служба мог бы иметь свойство, содержащее имя службы, и другое свойство, содержащее режим запуска службы. Методы вызывают выполнение объектом некоторого действия. Объект-служба мог бы иметь, например, методы с именами Stop, Start, Pause и Resume, представляющие различные действия, которые можно проделать со службой.
При программировании (или написании сценариев) ссылки на члены объекта выполняются с использованием точки. Объекты часто присваиваются переменным, что дает возможность манипулировать объектом физически. Например, если имеется служба, присвоенная переменной $service, эту службу можно остановить с помощью синтаксиса $service.Stop. Или можно извлечь отображаемое имя службы, отобразив $service.Name.

Объекты в конвейере
Поскольку Windows является большой и сложной операционной системой, и поскольку ее данные управления не хранятся в представлениях текстового стиля, старые приемы оболочек не очень-то для нее подходят. Например, предположим, что имеется средство командной строки с название SvcList.exe, создающее отформатированный список служб и их режимов запуска. В оболочке командной строки Windows — оболочке, которая корнями уходит глубоко в оболочку MS-DOS, которой несколько десятков лет — можно было бы выполнить, например, такую команду:
SvcList.exe | MyScript.vbs
Эта инструкция извлекает список служб и передает по каналу этот список в файл VBScript. Следовало бы написать файл VBScript для анализа форматированного списка и выполнить то, что от него требуется — может быть, вывести все службы, режимом запуска которых является Disabled. Для выполнения этой задачи потребуется время. В конечном счете, проблема заключается в уникальности вывода SvcList.exe — эта команда не использует некоторый общий формат, который позволил бы другим командам без труда воспринять ее выходные данные с пользой для себя.
Объекты, однако, предоставляют этот общий формат, и именно поэтому конвейер Windows PowerShell работает с объектами в целом, не только с текстом. При выполнении командлета типа Get-WMIObject выполняется создание группы (или коллекции, в программистских терминах) объектов. Каждый объект поступает в полном составе, со свойствами и методами, позволяющими им манипулировать. Если объекты передаются по конвейеру в командлет Where-Object, их можно отфильтровывать, чтобы отображались только требуемые объекты. Командлету Where-Object не требуется анализировать никакой текст, потому что он не получает никакого текста — он получает объекты. Пример:
Get-WMIObject Win32_Service | Where-Object {$_.StartMode -eq “Disabled” }
Или, если предпочтительнее краткий синтаксис, обеспечиваемый псевдонимами:
gwmi Win32_Service | where {$_.StartMode -eq “Disabled” }
Что интересно, так это то, что Windows PowerShell всегда передает объекты по конвейеру. И только в конце конвейера, когда больше некому передавать объекты, оболочка создает текстовое представление объектов с помощью встроенных правил форматирования. Рассмотрим следующий пример:
Gwmi Win32_Service | where {$_.StartName –eq “LocalSystem” } | select Name,StartMode
Этот набор из трех командлетов получает все службы из моего локального компьютера, отфильтровывает все те, которые не используют для входа в систему учетную запись LocalSystem, а затем передает остаток командлету Select-Object, который выводит только два свойства — Name и StartMode, которые были запрошены. Результатом является простой отчет, содержащий службы, входящие в систему в качестве LocalSystem (возможно, с целью проверки безопасности).
Поскольку все командлеты совместно используют общий формат данных — объекты, они обмениваются данными друг с другом без выполнения сложного анализа строк. А так как у Windows PowerShell имеется встроенная способность создавать текстовое представление объекта, на выходе этого канала наверняка будет текстовый вывод, доступный для чтения человеку. На рис. 1 приведен пример результирующего вывода.
Рис. 1 Текстовый вывод, созданный набором объединенных конвейером командлетов, передающих объекты
Рис. 1 Текстовый вывод, созданный набором объединенных конвейером командлетов, передающих объекты

Конвейеры – это здорово
Причина того, что передача по конвейерам в Windows PowerShell настолько изумительна, заключается в том, что все элементы в Windows PowerShell являются объектами, укомплектованными свойствами и методами, которые можно использовать. С технической точки зрения даже текстовый файл — это набор объектов-строк; каждая строка в файле выступает в качестве уникального и независимого объекта. Например, создадим текстовый файл (с помощью «Блокнота») с названием C:\Computers.txt. Заполним этот файл текстом и запустим в Windows PowerShell следующую команду:
Get-Content C:\Computers.txt | Select-Object Length | Format-List
Или снова, если желателен меньший объем ввода, можно использовать псевдонимы:
gc C:\Computers.txt | select Length | fl
Этот код обеспечивает получение списка, в котором длина каждой строки текста в файле указана количеством символов. Get-Content извлекает объекты-строки из файла, Select-Object получает свойство Length каждого из них, затем Format-List создает хорошо оформленный, доступный для чтения текст. Хотя приведенный пример не является практичным средством для использования администраторами, он иллюстрирует, что даже такой простой элемент, как строка текста, в Windows PowerShell является объектом.
Возможность передавать объекты по конвейеру от командлета к командлету — или даже от командлета в сценарий — обеспечивает создание невероятно мощных «средств из одной строки». Это простые строки командлетов, соединенные в длинный конвейер, изменяющий набор объектов, чтобы в конце предоставить то, что вам требуется. Практически без какого-либо написания сценария или программирования командлеты Windows PowerShell, образующие соответствующий конвейер, могут обеспечить замечательные результаты.

Поддержка будущих поколений
Тот факт, что будущие серверные продукты Майкрософт также создаются на базе Windows PowerShell, еще больше расширяет эти функциональные возможности. При внедрении нового компьютера для Exchange Server 2007, например, можно использовать Windows PowerShell для извлечения всех почтовых ящиков, отфильтровывания всех тех, которые не относятся к офису, в котором будет расположен новый почтовый сервер, и последующем перемещении оставшихся почтовых ящиков на новый сервер — все это выполняется посредством одной строки текста без написания сценария. Группа Exchange Server 2007 опубликовала длинный список мощных средств из одной строки. Они реально демонстрируют мощь конвейера и административные задачи, которые можно выполнить с его помощью.
Тонкость, связанная с Windows PowerShell, состоит в необходимости осознания того, что, несмотря на то, что оболочка построена на давно сформулированных принципах и философии из мира UNIX, это новое средство уникальным образом соответствует потребностям администрирования в Windows. Не дайте ввести себя в заблуждение общности терминологии и не думайте, что Windows PowerShell всего лишь переделка оболочки UNIX для Windows. Оболочка Windows PowerShell содержит самые современные новые концепции, в которых используются преимущества платформы Windows, и тесно связана с принципами работы операционной системы Windows.

Дон Джонс (Don Jones) обладает званием MVP по Windows PowerShell и является автором Windows PowerShell 101 (ScriptingTraining.com). Связаться с Доном можно через его веб-узел www.ScriptingAnswers.com.


 Эй, автор сценариев!: В сценариях, как и в жизни, внешний вид очень важен
Эй, автор сценариев!
В сценариях, как и в жизни, внешний вид очень важен
Сотрудники группы Microsoft Scripting Guys

В течение сотен и даже тысяч лет философы и мудрецы говорили нам, что мнение о ком-либо или чем-либо не должно основываться только на внешнем виде. (Не то, чтобы мы должны судить людей по своему мнению; как-никак красота – это глаз наблюдателя.) Вы знаете, что они говорят: «Настоящая красота внутри, а не снаружи, и то, что вы собой представляете, гораздо важнее внешнего вида».
К этом программисты могут добавить только одно: вздор.
Верно, вздор. Авторы сценариев из группы Scripting Guys первыми признали, что в идеальном мире внешний вид не имеет значения. Однако мы живем не в идеальном мире. В противном случае картофель фри и мороженое с горячим шоколадом стали бы двумя главными продуктами питания. Нравится вам это или нет, но внешний вид важен. И это особенно верно для сценариев.
Программисты, пишущие сценарии, знают, что немногие прослезятся при виде абсолютной красоты сценария VBScript, запущенного в командной строке. (Может быть, автор сценариев Дин Цальтас, но он единственный, кто приходит на ум.)
С другой стороны также верно, что в нашем высокотехнологичном мире программисты больше не ограничены написанием сценариев, запускаемых в программной строке. Благодаря приложениям HTML (HTA) программисты могут использовать возможности DHTML для создания графических интерфейсов для своих сценариев. Те же самые навыки работы с HTML могут использоваться для создания мини-приложений Windows Vista™, новой области, которое обладает потенциалом для революционного изменения всей области сценариев для системных администраторов, как она нам известна. Заметили? Как только начинается разговор о графических интерфейсах, все старые избитые идеи о красоте как о поверхностном понятии пропадают. Для сценариев, работающих в графической среде, внешний вид настолько же важен, насколько функции и производительность.
И это проблема. В конце концов, что мы, авторы сценариев, знаем о создании графических интерфейсов? Похоже, нам не везет, не так ли?
Возможно. Но опять же, может быть и нет. Только что ведь кто-то сказал: «К счастью, существуют авторы сценариев из группы Scripting Guys»?
На самом деле нет. Мы разве не слышали, как только что кто-то это сказал? Может быть кто-то пробормотал это или что-нибудь еще...
Это неважно. Кто-то обязательно должен быть сказать подобное, потому что авторы сценариев из группы Scripting Guys призваны оказывать поддержку (нужна она вам или нет).
Для начала работы с прекрасным миром графических интерфейсов давайте взглянем на начало небольшого простого приложения HTA. (Для получения дополнительных сведений о создании HTA посетите HTA Developers Center (Центр разработчиков HTA).)
На рис. 1 показана первая часть новой настольной информационной системы. Как вы видите, я начал с добавления небольшой графики в правом верхнем углу окна HTA. Идея заключалась в том, что при первой загрузке HTA выполняется получение имени вошедшего пользователя, а затем его имя и имя компьютера отображаются на этом изображении. Позднее мы добавим в HTA еще много интересного, но, как бы они сказали, начнем с начала.
Рис. 1 Начало вашего довольно привлекательного графического интерфейса HTA
Рис. 1 Начало вашего довольно привлекательного графического интерфейса HTA
Однако мы не знаем, кто такие «они». Возможно, кто-то из философов. Вероятно, Вольтер. Это очень похоже на то, что мог сказать Вольтер.
Разумеется, это довольно привлекательное небольшое приложение и его...красота...никогда не заставит прослезиться автора сценариев Дина. Но оно служит в качестве полезного демонстрационного средства, основной принцип которого применим к множеству других ситуаций. Как-никак, множество подобных напыщенных мини-приложений Windows Vista работает на сходном принципе; они просто отображают причудливую графику (например, средство измерений или наборный диск), а затем помещают на эту графику текст. Это выглядит как небольшая привлекательная фишка для обозначения свободного места на диске, и если оно заканчивается, на общую графику накладывается динамический текст.
Скажем вам правду, ни то, ни другое, особо ничего для нас не значат. Но все должно выясниться немного позже в этой статье.
Существует одна проблема с тем, что сначала отображается графика, а затем на ней – текст: это не работает. Вместо этого с помощью простой разметки HTML получим то, что показано на рис. 2. Не совсем то, что мы задумывали. Возможно, Ницше, который сказал, что «люди никогда не смогут поместить текст на графику, по крайней мере не в HTA», был прав.
Рис. 2 Первая попытка наложения текста
Рис. 2 Первая попытка наложения текста
Или, возможно, Ницше ошибался: разве кто-то только что не сказал – ладно, неважно. Как выяснилось, мы не может сделать то, что необходимо, с помощью обычного кода HTML; он просто не работает подобным образом. Конечно, теоретически мы можем сделать графику фоном, а затем использовать таблицы, неразрывные пробелы и всевозможные хитрости, чтобы попробовать наложить на нее текст. Но есть веская причина сказать «теоретически»; за исключением самых простых случаев эта стратегия никогда не работает.
Как выяснилось, существует гораздо лучший способ создания привлекательных макетов в HTA или мини-приложениях Windows Vista: таблицы стилей, лучше известные как CSS.
CSS используются для определения шрифтов, полей и выравниваний, цветов и других аспектов отображения документа. (В частности, это применяется к веб-страницам. Однако, поскольку HTA и мини-приложения по своей сути являются исключительно веб-страницами, CSS могут использоваться так же успешно и для них.) Мы даже не можем начать рассмотрение всех возможностей CSS, поэтому, если вам нужно, ознакомьтесь с дополнительными сведениями на веб-узле CSS reference documentation (Справочная документация CSS) в библиотеке MSDN®. Сейчас достаточно сказать, что можно использовать CSS для точного управления макетом приложения HTA, включая возможность наложения одного элемента (текста) на другой (графика).
Мы объясним, как все это выполняется. Но прежде чем мы начнем объяснение, давайте взглянем на код очень простого приложения HTA, показанного на рис. 3.
Figure 3 Наконец, у нас есть сценарий... (Close Figure 3)
<SCRIPT LANGUAGE=”VBScript”>

Sub Window_OnLoad
 Set objNetwork = CreateObject(“Wscript.Network”)

 strUser = objNetwork.UserDomain & “\” & objNetwork.UserName
 strComputer= objNetwork.ComputerName

 UserData.InnerHTML = “<p align = ‘center’> “ & _
 “<font style=’font-size:18pt;color:white’>” & _
 strUser & “<br>” & strComputer & “</font></p>”
End Sub

</SCRIPT>

<img src=“test2.jpg“ align=“right“>
<span id=UserData style=“position:absolute;left:770px;top:150px“></span>
Как вы видите, здесь все совсем другое. Подпрограмма Window_OnLoad (на основе имени) автоматически выполняется при каждом запуске или обновлении HTA. Мы обсудим эту подпрограмму через минуту. Кроме того, имеются два элемента HTML: графика и диапазон. Как вы, несомненно, знаете, мы использовали эту разметку для вставки графики, используя атрибут выравнивания для размещения графики в правой части окна:
<img src=”test2.jpg” align=”right”>
Это приводит нас к разметке HTML для диапазона:
<span id=UserData style=”position:absolute;
left:770px;top:150px”></span>
Итак, здесь мы использовали тег диапазона. Что же такое тег диапазона? По существу, диапазон – это простая область HTA с названием; это «отмеченная» часть окна HTA, которую можно определить программно (во основном, потому, что диапазону был дан идентификатор UserData). После настройки диапазона можно написать подпрограмму назначения диапазону текста или кода HTML. Фактически, мы не просто можем это сделать, в нашем HTA мы сделали именно это.
Но, как мы сказали, мы рассмотрим это позднее. Сначала нам необходимо рассмотреть добавленный к тегу диапазона параметр стиля:
style=”position:absolute;left:770px;top:150px”
Этот параметр, как вы, вероятно, подозреваете, является ключевым фактором для успешного размещения динамического текста поверх графики. Здесь мы фактически указываем три различных атрибута стиля.
Position Мы указываем HTA, чтобы диапазон размещался абсолютно. Это в действительности значит, что диапазон должен всегда находиться в одном месте, даже если это означает, как в этом случае, что текст размещается на другом элементе (как, например, графике).
Left Указывается расположение диапазона относительно левого края окна HTA. В данном случае диапазон начинается в 770 пикселах (770px) от левого края.
Top Этот параметр сходен с атрибутом Left, за исключением того, что положение диапазона указывается относительно верхнего края окна HTA. В данном случае для начала размещения диапазона мы хотим начать с верхнего края окна и отсчитать 150 пикселов вниз (150px).
Как мы узнали, что необходимо установить левую сторону диапазона на расстоянии 770 пикселов, а правую – на расстоянии 150 пикселов? Если сказать правду, мы не выясняли это. Вместо этого мы сделали предположение; мы разместили графику на странице и присвоили значения атрибутам Left и Top диапазона. Затем мы открыли HTA и посмотрели на результаты. Как вы могли ожидать, мы немного ошиблись, поэтому мы изменили значения, обновили HTA и снова посмотрели результаты. Мы повторили это несколько раз, как Маша из сказки про трех медведей, и нашли верные значения.
Примечание. Вы знаете сказку о Маше и медведях, об их стульях, кроватях и ложках, которые были слишком большими или слишком маленькими и т.д. Нет, мы не уверены, может ли эта девочка считаться великим философом или нет. Но вы можете сказать, что то, как она беспрепятственно проникла в дом медведей, ела их похлебку, сидела на их стульях и спала в их кроватях, определенно свидетельствует о наличии собственной уникальной философии.
В любом случае, на рис. 4 показан вид HTA на данный момент. Разумеется, это, возможно, и не произведение искусства, но опять же, я бы посмотрел на Пикассо, программными методами выполняющего размещение информации на графике.
Рис. 4 Посмотрите на силу стиля
Рис. 4 Посмотрите на силу стиля
Кстати, говоря о стиле, как же мы программно разместили информацию на графике? У нас есть хорошие новости: наконец настал момент поговорить о подпрограмме Window_OnLoad, которая показана на рис. 5.
Figure 5 Подпрограмма Window_OnLoad (Close Figure 5)
Sub Window_OnLoad
 Set objNetwork = CreateObject(“Wscript.Network”)

 strUser = objNetwork.UserDomain & “\” & objNetwork.UserName
 strComputer= objNetwork.ComputerName

 UserData.InnerHTML = “<p align = ‘center’> “ & _
  “<font style=’font-size:18pt;color:white’>” & _
  strUser & “<br>” & strComputer & “</font></p>”
End Sub
Что же, если мы рассмотрим эту подпрограмму более подробно, то поймем, что обсуждать нужно не так уж много. Сначала мы создали экземпляр объекта Wscript.Network. Затем мы использовали следующие строки кода для получения имени пользователя, домена и имени компьютера:
strUser = objNetwork.UserDomain & “\” & _
  objNetwork.UserName
strComputer= objNetwork.ComputerName
Это, конечно, информация, которую нужно разместить в окне HTA. Для этого необходимо просто совместить переменные strUser и strComputer с небольшой разметкой HTML, затем присвоить полученную строку свойству InnerHTML нашего диапазона:
UserData.InnerHTML = _
  “<p align = ‘center’> “ & _
  “<font style=’font-size:18pt;color:white’>” _
  & strUser & “<br>” & strComputer & _
  “</font></p>”
Да, мы знаем, что этот код выглядит довольно сложным. Но на самом деле не все так плохо. Он такой только из-за того, что мы совмещаем несколько элементов в одной строке. Мы начали с открывающего тега paragraph, который указывает, что необходимо расположение текста в параграфе по центру.
“<p align = ‘center’> “
Далее идет открывающий тег font для шрифта, который указывает, что используется текст белого цвета размером 18 точек:
“<font style=’font-size:18pt;color:white’>”
strUser – это переменная для имени пользователя в формате Domain\UserName. с помощью "<br>" вставляется перенос строки. Перенос строки используется для того, чтобы имя пользователя размещалось на одной строке, а имя компьютера на другой. strComputer – это переменная для имени компьютера. Наконец, мы добавили закрывающие теги шрифта и параграфа:
“</font></p>”
Если посмотреть на все эти элементы по отдельности, вы увидите, что код ничуть не настолько сложный, как можно было бы подумать.
Кстати, вы можете размещать столько элементов HTML, сколько вам необходимо. Например, предположим, что в центре графики необходимо разместить кнопку. Для этого просто добавьте в код HTA следующее:
<input type=”button” value=”Test Button” style=”position:absolute;left:820px;top:300px”>
Благодаря этому HTA должно выглядеть так, как показано на рис. 6.
Рис. 6 Замечательная кнопка
Рис. 6 Замечательная кнопка
И снова, для верного размещения кнопки необходимо попробовать несколько вариантов, но это не должно занять много времени. На самом деле, если вы хотите заниматься математическими расчетами, вероятно, вы сможете определить верное расположение быстрее. Необходимо знать только ширину и высоту всех объектов, чтобы указать эти данные с помощью параметра стиля, а также ширину и высоту окна HTA. По умолчанию, по крайней мере на тестовом компьютере одного автора сценариев, HTA приблизительно 1020 пикселов в ширину и около 685 пикселов в высоту (конечно, результаты могут различаться). В подобной ситуации вы можете начать с этих цифр, а затем изменить их в соответствии с вашими требованиями.
Это слишком короткое введение в CSS, но оно должно послужить для вас начальной точкой к созданию привлекательного внешнего вида ваших сценариев. Философы могут усмехнуться, глядя на эти усилия, и сказать, что настоящая красота сценария заключена в его сути, а не во внешнем виде. Но посмотрите на это с другой стороны. Кто величайшие философы всех времен? Правильно: Платон, Сократ, Аристотель – эти ребята. Имея это в виду, хочу задать вопрос: видели ли вы когда-нибудь фотографию кого-либо из них? Не кажется ли вам интересным, что нет фотографий людей, которые говорят, что красота не имеет значения? Не кажется ли это странным? Есть над чем задуматься.

Сотрудники группы Microsoft Scripting Guys работают... ну, хорошо, получают зарплату в корпорации Майкрософт. Когда они не играют в бейсбол, не тренируют бейсбольную команду, не смотрят бейсбол и не занимаются другими делами, они ведут проект Script Center в журнале TechNet. Веб-узел проекта находится по адресу www.scriptingguys.com.


 Exchange Queue — очередь за ответами: Роли пограничного транспортного сервера и транспортного сервера-концентратора, виртуальные машины и многое другое
Exchange Queue — очередь за ответами
Роли пограничного транспортного сервера и транспортного сервера-концентратора, виртуальные машины и многое другое
Кей Си Лемсон (KC Lemson) and Нино Билич (Nino Bilic)

В выпуске «Exchange Queue – очередь за ответами» в мае 2007 г. мы говорили о проблемах сохранения файлов PST на сетевых ресурсах. Группа производительности Windows Server недавно завела блог, в котором обсуждалась
эта тема во всей ее сложности и технические данные, поэтому мы хотим привести ссылку на него. Теперь давайте перейдем к вопросам.

В. Необходимо ли мне разворачивать роль пограничного транспортного сервера при развертывании Microsoft Exchange Server 2007?

О. Нет, для развертывания Exchange Server 2007 не требуется развертывание пограничного сервера. На одном компьютере могут быть развернуты базовые роли сервера (такие как почтовый ящик, клиентский доступ и транспортный сервер-концентратор), может приниматься электронная почта для домена и работать антивирусные программы и программы защиты от нежелательной почты.

В. В чем отличия роли пограничного транспортного сервера от роли транспортного сервера-концентратора? Каких возможностей я буду лишен, если не буду развертывать пограничный транспортный сервер?

О. Основное назначение роли сервера-концентратора заключается в маршрутизации почты внутри организации и применении к этим сообщениям бизнес-политик. При помощи роли транспортного сервера-концентратора правила транспорта основываются на объектах Active Directory® — пользователях, списках рассылки и т.д. Роль сервера-концентратора также позволяет добавлять заявления об отказе от ответственности к сообщениям или регистрировать сообщения, отправленные группам пользователей, поскольку вам, вероятно, будет необходимо, чтобы эти правила были основаны на членстве в Active Directory. Например, необходима регистрация всех сообщений, отправленных для DLOfUsersOnLitigationHold, или добавление заявлений от отказе от ответственности, отправленных для DLOfMembersOfLegalTeam. Хотя запуск агентов защиты от нежелательной почты на сервере-концентраторе возможен, они не включены по умолчанию, поэтому необходимо установить их вручную, запустив сценарий установки агентов защиты от нежелательной почты, доступный в папке \scripts на сервере.
Основная цель роли пограничного сервера заключается в маршрутизации почты, отправляемой и получаемой организацией, а также выполнение санации сообщений (защита от нежелательной почты, антивирусная защита, фильтрация содержания или вложений и т.д.). Функция защиты от нежелательной почты включается при установке пограничного сервера. Одной из уникальных функций роли пограничного сервера является отсутствие требования на присоединение к домену Windows®; он может быть запущен в отдельной установке Windows Server®, не являющейся частью домена Windows, но пограничный сервер может управляться как часть организации Exchange 2007 в корпоративном лесу.
Это особенно выгодно в демилитаризованной зоне, где может быть необходимо, чтобы сервер находился в рабочей группе, или может существовать отдельный лес для компьютеров в демилитаризованной зоне. Пограничные серверы, разворачиваемые в этой ситуации, могут выполнить всю санацию сообщений и маршрутизацию почты между корпоративной сетью и Интернетом, если управляются тем способом, способом, который удобен для остальных системных администраторов Exchange 2007.
Правила транспорта пограничного сервера основаны на адресах SMTP, а не на объектах Active Directory, но, конечно же, можно использовать адреса SMTP списков рассылки или пользователей Active Directory. В основном правила пограничного транспортного сервера являются подмножеством набора правил транспортного сервера-концентратора, за исключением действия карантина, которое доступно только на пограничных серверах.
Пограничные серверы также предоставляют некоторые дополнительные функции через агентов, которые недоступны на транспортном сервере-концентраторе: удаление вложений и переписывание адресов. Удаление вложений – это возможность выборочного удаления потенциально опасных вложений с такими расширениями, как .exe и .com. Агент перезаписи адреса позволяет переписывать заголовки электронной почты, например, хотя адреса домена и прокси SMTP по умолчанию для учетных записей пользователей могут быть @contoso.com, в отправляемых сообщениях будет указан адрес @northwindtraders.com. Кроме того, пограничные серверы выполняют маршрутизацию только на основе домена или адресного пространства, поэтому при использовании одного адресного пространства SMTP для Exchange и другой системы электронной почты необходимо выполнять маршрутизацию на сервере-концентраторе или осуществлять это вместе с агентом перезаписи адресов на пограничном сервере.
Другим существенным моментом является наличие непосредственного выхода сервера Exchange 2007 в Интернет (как для роли пограничного сервера, так и для сервера-концентратора). Другими словами, являются ли подключения к порту 25 записи MX домена в каком-либо смысле подключениями к Exchange 2007? Могут уже иметься шлюз SMTP, антивирусный экран или другое решение для получения почты для вашего домена и ее последующей пересылки серверу Exchange в корпоративной сети. При развертывании пограничного сервера или сервера-концентратора для выхода в Интернет можно воспользоваться преимуществом одной из самых привлекательных функций Exchange 2007: объединение списков надежных отправителей. С помощью объединения списков надежных отправителей можно безопасно распространить составляемый пользователями в Microsoft Outlook® список надежных отправителей (который обычно создается для рассылок новостей или писем от розничных продавцов) на роли пограничного сервера или сервера-концентратора, чтобы сообщения от этих отправителей обходили фильтрацию содержимого. Естественно, бюллетень новостей, который один пользователь считает нежелательной почтой, другой читает с удовольствием, поэтому объединение списков надежных пользователей выполняется для каждого пользователя индивидуально. Более подробно об этом можно прочитать в документации Exchange 2007.
После выполнения развертывания, в котором сервер, работающий в роли сервера-концентратора, принимает электронную почту Интернета для вашего домена, необходимо помнить о нескольких моментах. Конечно, прежде всего необходимо убедиться, что установлен надежный брандмауэр или решение для фильтрации портов, чтобы сервер принимал подключения только к необходимым портам, например 25. Также необходимо помнить, что следует установить агенты защиты от нежелательной почты, поскольку они не установлены или не включены по умолчанию. Поскольку наиболее распространенной ситуацией развертывания сервера-концентратора является развертывание в корпоративной сети, он не допускает анонимные подключения по умолчанию — необходимо проверить группу разрешений AnonymousUsers на соединителе приема порта 25. Также потребуется убедиться, что объединение списков надежных отправителей включено и установлено расписание регулярного запуска, чтобы при обновлении пользователями списков надежных отправителей для их почтовых ящиков почта для пользователей от отправителей, находящихся в списках надежных отправителей, обходила фильтрацию содержимого. Дополнительные сведения имеются в нашем блоге.
В следующем фрагменте кода показана команда AT, ежедневно обновляющая почтовые ящики на всех серверах в 23:00, используя пакетный файл SafeList.bat:
at 23:00 /every:M,T,W,Th,F,S,Su cmd /c
“D:\SafeList.bat”
В данном коде показано содержимое файла SafeList.bat:
“d:\Program Files\Microsoft Command Shell\v1.0\Powershell.exe”
-psconsolefile “d:\Program Files\Microsoft\Exchange Server\bin\exshell.psc1” -command
“get-mailbox | where {$_.RecipientType
-eq [Microsoft.Exchange.Data.Directory.Recipient.RecipientType]::UserMailbox } | update-safelist”
При необходимости проверки правильности работы параметров дополнительные сведения можно найти в документации по Exchange 2007.

В. После загрузки образа Virtual PC с сервером Exchange возникли проблемы, связанные с обращением к папке или серверу LDAP. Подключение к серверу по Telnet на порт 389 возможно, и все службы работают. Почему это происходит?

О. Эта проблема возникла у меня в прошлом году на конференции Tech•Ed. На моем переносном компьютере была копия Virtual PC, которую я скопировал с рабочего компьютера, и я планировал использовать ее для демонстрации участникам конференции, публикующим статьи, касающиеся выпуска Exchange 2007 бета-версии 2 в следующем месяце.
Я уже выполнил миллионы демонстраций этого продукта и знал о надежности сборки, поэтому я не стал тщательно готовиться. Вы можете представить, как я занервничал, когда в понедельник утром я загрузил Virtual PC, всего за несколько часов до встречи, и ни одна из частей моей сборки не могла обратиться к контроллеру домена. Благодаря высокой концентрации невероятно умных людей в одном здании мы смогли быстро об этом забыть.
Проблема моих бедствий на конференции Tech•Ed произошла из-за запуска Virtual PC на моем невероятно медленном переносном компьютере. Корень проблемы заключался в условии конкуренции DNS и Active Directory. Сервер DNS в образе был настроен на интеграцию с Active Directory, но из-за последовательности загрузки служб на образе (и, надо сказать, из-за неторопливости переносного компьютера) запуск необходимых служб каталогов не произошел на момент обращения сервера DNS к Active Directory.
Эта ситуация может произойти на любом сервере с установленными контроллером домена и Exchange (который не обязательно должен быть виртуализованным образом), но более вероятно ее возникновение в виртуализованной среде с дополнительной задержкой, в особенности на не слишком мощном переносном компьютере наподобие моего.
Я также встречал подобную проблему с образами Virtual PC, скопированными с одного компьютера на другой, особенно если компьютеры находятся в различных сетях. При возникновении подобной проблемы проверьте IP-адрес операционной системы образа; он может быть устаревшим IP-адресом из старой сети. Обновите его на IP-адрес из новой сети и просмотрите результаты.
Чтобы избежать возникновения подобных проблем в будущем, необходимо, чтобы сервер DNS на компьютере размещения не был интегрирован с Active Directory, или можно установить сервер DNS как на компьютере размещения, так и на гостевом компьютере. Гостевой компьютер должен обращаться к компьютеру размещения за неизвестными записями, а компьютер размещения должен в свою очередь обращаться к соответствующему серверу DNS за неизвестными записями. При загрузке образа и обновлении записей DNS он будет менее подвержен сбоям.

В. Складывается впечатление, что установка Exchange 2007 значительно отличается от установки более ранних версий Exchange. Как осуществляется эта установка?

О. Да, действительно, существует несколько этапов установки Exchange 2007. Ниже приведен общий обзор всего процесса.

При первом запуске файла setup.exe запускается процесс, который предоставляет ссылки на большинство необходимых компонентов, которые должны быть установлены до начала установки фактических ролей сервера. После установки всех необходимых компонентов становится доступной ссылка на установку Microsoft Exchange (см. рис. 1).
Рис. 1 Ссылка на установку, доступная после установки всех необходимых компонентов
Рис. 1 Ссылка на установку, доступная после установки всех необходимых компонентов
При запуске файла setup.exe из сети и переходе по ссылке на установку основные файлы установки будут скопированы в папку %TEMP%\ExchangeServerSetup\ на локальном компьютере. Затем будет запущен мастер установки.
Мастер установки проведет через все этапы установки, такие как лицензионное соглашение, отчеты об ошибках и тип установки (где необходимо выбрать роли сервера для установки). Страницы мастера будут изменяться в зависимости от наличия и состояния текущей организации Exchange (если таковая имеется).
После выполнения этих этапов программа установки запустит проверку готовности – специально настроенную версию анализатора соответствия рекомендациям для Microsoft Exchange Server, который по умолчанию выполнит подключение к Интернету для загрузки последнего необходимого компонента – XML-файла. Это предоставляет возможность регулярно обновлять необходимые компоненты или разрешать проблемы, ставшие известными группе Exchange после выпуска продукта. После выполнения проверки необходимых компонентов можно просмотреть результаты и продолжить; в противном случае появится список действий, которые необходимо выполнить для продолжения установки. При возникновении ошибки при проверке необходимых компонентов в большинстве случаев мастер позволит повторить проверку.
После выполнения проверки необходимых компонентов появится кнопка установки, которая позволяет начать установку ранее выбранных ролей. Будут скопированы и установлены только файлы для выбранных ролей.
В самом конце установки можно запустить консоль управления Exchange, а также установить доступные обновления Exchange 2007.

Кей Си Лемсон (KC Lemson) - менеджер по пользовательской среде для Exchange Server. Ее банковский счет в Интернете временно заблокирован.
Нино Билич (Nino Bilic) - руководитель программы поддержки Exchange Server. Недавно он добавил к своей кредитной карте дополнительный адрес электронной почты.


 На страже безопасности: Средства управления списками ACL
На страже безопасности
Средства управления списками ACL
Йеспер Йохансон (Jesper M. Johansson)

В Windows списки управления доступом (списки ACL) позволяют довольно точно управлять способностью пользователей и процессов использовать ресурсы, такие как файлы и папки. Управление списками ACL — одна из самых сложных задач обеспечения безопасности операционных систем пользователей. К счастью, существует несколько полезных служебных программ,
помогающих автоматизировать и упростить выполнение задач, связанных с разрешениями и списками ACL.
Большинство читателей знакомо с замечательным средством cacls.exe — оно было в каждой версии Windows NT® с самого момента ее появления. Если запустить cacls.exe в Windows Vista™, вы увидите следующее сообщение:
Microsoft Windows [Version 6.0.5744]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.

C:\Windows\system32>cacls

 NOTE: Cacls is now deprecated, please use Icacls.
Специалисты корпорации Майкрософт обновили не только списки ACL в Windows Vista (об этом рассказывалось в выпуске журнала TechNet Magazine за июнь 2007 г. — см. technetmagazine.com/issues/ 2007/06), но и некоторые средства управления ими. Что интересно, самые значительные изменения коснулись средств с интерфейсом командной строки.
Средство Icacls.exe появилось в Windows Vista (как средство нижнего уровня оно присутствует в Windows Server® 2003 с пакетом обновления 2 (SP2)). В конечном итоге оно заменит средство cacls.exe, в котором — как вы, наверное, знаете — так и не была реализована поддержка более детализированных разрешений, введенных в Windows® 2000. Подобное обновление следовало бы выпустить еще лет семь назад.
Странно, но хотя средство cacls.exe представляется как устаревшее, в нем появились новые функции. Во-первых, оно воспринимает и точки соединения, и символические ссылки, и знает, как их просматривать. Во-вторых, оно умеет и печатать, и настраивать списки ACL с использованием строки SDDL.
Но несмотря на все обновления cacls.exe, нельзя не оценить функции, предоставляемые средством icacls.exe.

Сохранение и восстановление списков ACL
Все последние 10 лет возникало желание — по крайней мере, у меня — иметь возможность сохранять списки ACL, чтобы потом их можно было восстанавливать. Как оказалось, это одна из самых сложных операций при работе со списками ACL. Лишь в редких случаях удается вернуться к тому же точно состоянию, не уничтожив первым делом списки ACL. Тем не менее, эти функции могут быть довольно полезны.
Прежде чем рассказывать, как сохранять и восстанавливать списки ACL, я попытаюсь объяснить, почему это так сложно сделать. Допустим, у вас есть иерархия с данными пользователей — студентов местного колледжа. 1 февраля вы сохраняете список ACL. 17 апреля вы обнаруживаете, что он каким-то образом поврежден, и хотите восстановить его из сохраненной копии. Какие трудности могут возникнуть при этом?
Во-первых, 2 апреля начинается новый триместр. Около 15 процентов студентов ушло из колледжа, поэтому их каталоги больше не существуют. Значит, в резервной копии есть недействительные списки ACL. Некоторое количество студентов — еще 15 процентов — поступило в этом триместре. У них уже есть домашние каталоги, а списков ACL в резервной копии нет. Как должны выглядеть списки ACL для них? И, разумеется, есть еще те 70 процентов пользователей, которые никуда не уходили — но они создавали одни файлы и папки и удаляли другие. На удаленные папки можно не обращать внимания, а вот как настроить созданные? А если один из студентов 4 марта сделал свою папку общей, чтобы использовать ее совместно с друзьями? Уничтожите ли вы эту функцию, восстановив списки ACL?
Сохранить и восстановить списки ACL не так просто, как многие пытаются вас убедить. Тут нужно действовать очень осторожно. В результате вы можете столкнуться с неожиданным поведением — даже, скорее всего, так и будет. Восстанавливать списки ACL, конечно, нужно только в крайнем случае. И чем больше времени прошло с момента создания копии, тем выше вероятность что-то испортить при восстановлении.
Если же, несмотря на все вышесказанное, хотите попробовать эти функции в действии, запустите icacls.exe с параметром /save.
icacls <target> /save acls.bin /t
Списки ACL будут сохранены в файл acls.bin. В файле будет по одной строке на каждый объект. За ACL будет следовать строка, определяющая ACL в SDDL. Если использовать в команде параметр /t, она применяется к указанному объекту и ко всем объектам и контейнерам, расположенным ниже по иерархии.
Функция сохранения — удачное дополнение к средству, но у нее есть несколько изъянов. Например, сохранять можно только списки управления доступом на уровне пользователя (списки DACL) — системные списки (SACL) сохранять нельзя. В действительности в случае с SACL сохраняется некое подставное значение, показывающее, что это системный список доступа, но сам список SACL по сути дела не сохраняется.
Еще одна любопытная проблема связана с тем, каким образом сохраняются списки ACL. Прежде чем открыть сохраненный ACL в любимом текстовом редакторе, запомните:
Никогда не вносите изменения в сохраненные списки ACL!
Если вдруг вам доведется открыть файл с сохраненным ACL в текстовом редакторе, вы увидите, что он, на первый взгляд, представляет собой форматированный текстовый файл в кодировке Юникод (UTF-16). Это почти правда. И исходя из этого вы можете подумать, что файл можно изменить и сохранить в текстовом редакторе. Этого делать не стоит.
Если вы откроете файл с сохраненным ACL в текстовом редакторе, а затем сохраните его, восстановить список ACL из этого файла не удастся. Все дело в том, что это не просто текст в кодировке Юникод. Каждый такой файл должен начинаться с двух байтов 0xfffe. Когда вы сохраняете файл в текстовом редакторе, он как раз помещает в первые 2 байта этот флаг. Но вот средство icacls.exe ожидает, что данные ACL начинаются с нулевого байта в файле. Следовательно, ему не удастся разбить файл на отдельные ACL, поскольку первые два байта будут восприниматься как часть строки, соответствующей обрабатываемому объекту. Резервный файл станет непригодным для использования.
Специалисты корпорации Майкрософт знают об этой проблеме, но она была выявлена уже на стадии завершения бета-тестирования Windows Vista, поэтому до выпуска системы она исправлена не была. Пока неизвестно, когда она будет устранена и будет ли устранена вообще. Так что сейчас можно только посоветовать не вносить изменения в сохраненные списки ACL. Если все-таки это необходимо, сохраните файл с расширением BIN и используйте шестнадцатеричный редактор — например свою любимую среду разработки.
Список ACL, сохраненный при помощи параметра /save, можно восстановить, используя команду icacls.exe с параметром /restore. Команда восстановления в простейшей ее форме выглядит следующим образом:
icacls <directory> /restore acls.bin
Процедура восстановления применяется не к файлам. Чтобы это понять, посмотрите на последовательность команд, приведенных на рис. 1. Я создал сохраненный файл, применив команду icacls.exe к файлу. Затем я попытался восстановить его, попросту заменив /save на /restore. Это не сработало, поскольку команда восстановления применяется только к каталогам. Файлы, которые должны быть изменены в ходе ее работы, уже указаны в файле acls.bin. Чтобы восстановить список ACL, нужно указать каталог, а не файл. Именно это я и делаю, когда указываю "." в качестве обрабатываемого объекта.
Figure 1 Сохранение и восстановление списков ACL (Close Figure 1)
C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt /restore acls.bin
test.txt\test.txt: The system cannot find the path specified
Successfully processed 0 files; Failed processing 1 files

C:\Users\Jesper>icacls . /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files
Обратите внимание, что команда восстановления должна выполняться под учетной записью с повышенными правами. Команду сохранения можно выполнить в командной строке под учетной записью администратора с ограниченными правами, даже под учетной записью простого пользователя, если в ней есть право считывать ACL. А вот для восстановления списка ACL необходима учетная запись администратора с полным набором прав, без ограничений.

Замена идентификаторов SID
Еще одна очень полезная функция icacls.exe — это возможность заменять разрешения одного пользователя разрешениями другого. Это делается при восстановлении при помощи параметра /substitute. В документации по параметру говорится, что для его использования необходим идентификатор SID, но чуть ниже разъясняется, что можно взять просто имя пользователя. То есть последовательность команд, приведенная на рис. 2, работает.
Figure 2 Замена идентификаторов безопасности при восстановлении (Close Figure 2)
C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\foo:(R,W)
    VistaRC2-Test\Jesper:(I)(F)
    NT AUTHORITY\SYSTEM:(I)(F)
    BUILTIN\Administrators:(I)(F)

Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls. /substitute foo bar /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\bar:(R,W)
    VistaRC2-Test\Jesper:(I)(F)
    NT AUTHORITY\SYSTEM:(I)(F)
    BUILTIN\Administrators:(I)(F)

Successfully processed 1 files; Failed processing 0 files
Как вы видите, я пришел к тому же списку ACL, с которого и начал, но элемент ACE, который определял разрешения для пользователя foo, теперь определяет разрешения для пользователя bar.

Смена владельца
Средство chown долгие годы существовало исключительно в системах UNIX. В Windows изначально не было встроенного средства для изменения владельца объектов. Затем в комплекте Resource Kit появилось средство setowner. За ним последовало средство takeown.exe в Windows NT 4.0, но эта служебная программа позволяло только присвоить объекты себе. Чтобы передать объекты другому пользователю, нужно было знать его пароль. В средстве icacls.exe есть встроенные возможности установить владельца для тех объектов, для которых у вас есть разрешение на установку владельца.
C:\>icacls c:\test /setowner foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
К сожалению, средство icacls.exe не показывает владельца объекта. В командной строке невозможно увидеть, кому же на самом деле объект принадлежит. Кроме того, когда вы сохраняете список ACL для объекта, владелец его не сохраняется.
В средстве icacls.exe есть еще одна ошибка: оно не вызывает SeTakeOwnershipPrivilege при изменении владельца. Если вы имеете право изменять владельца объекта на основании ACL, средство icacls.exe работает правильно. Если же вы являетесь администратором, но не имеете разрешения на изменение владельца на основании ACL данного объекта, изменить его при помощи средства icacls.exe не удастся — как раз из-за этой ошибки. В таком случае необходимо использовать средство takeown.exe — оно вызывает SeTakeOwnershipPrivilege, но может установить в качестве владельца не любую учетную запись, а только вашу учетную запись или группу администраторов.
C:\>takeown /f c:\test

SUCCESS: The file (or folder): “c:\test” now owned by user “JJ-VistaRTMTst\Jesper”.
Конечно, нужно отметить, что средство subinacl, которое можно загрузить из центра загрузки корпорации Майкрософт, также использует ключ setowner. Во многих случаях средство subinacl понятнее, чем icacls, но также верно, что его гораздо сложнее использовать.

Поиск файлов определенного пользователя
В средстве icacls есть еще одна полезная функция: оно позволяет найти файлы, у которых есть разрешения для определенных пользователей. Пример:
C:\windows\system32>icacls “c:\program files” /findsid jesper /t

SID Found: c:\program files\Passgen\
passgen.exe.
Successfully processed 1808 files; Failed processing 0 files
Это может пригодиться, если нужно будет выяснить, к каким элементам имеет доступ некий пользователь.

Сброс и изменение списков ACL
Средство icacls.exe позволяет сбросить поврежденный или разрушенный список ACL путем наследования от родительского. Эта функция очень бы пригодилась осенью 2006 года, когда обнаружилась проблема с безопасностью «нулевого дня». Одним из методов, использованных для ослабления ее негативных последствий в Windows, был запрет доступа группы Everyone к объекту. Это было несложно. А вот удалить элементы управления доступом (ACE) встроенными средствами Windows XP и Windows Server 2003 оказалось практически невозможно. В Windows Vista нужно было бы просто выполнить вот такую команду:
C:\windows\system32>icacls “c:\program files\passgen\passgen.exe” /reset

processed file: c:\program files\passgen\passgen.exe
Successfully processed 1 files; Failed processing 0 files
В средстве icacls.exe, разумеется, есть и все стандартные операции grant/deny/remove. Единственный действительно новый элемент в этом списке — remove. При помощи этого параметра можно удалить все разрешающие элементы ACE для данного пользователя от данного объекта или иерархии, все запрещающие элементы ACE или и то, и другое. На рис. 3 приведены примеры различных операций grant, remove и deny.
Figure 3 Операции grant, deny и remove (Close Figure 3)
C:\>icacls c:\test /grant foo:(F)
processed file: c:\test

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(F)
    BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /remove:g foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /deny foo:(F)
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(N)
    BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /remove:d foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files
Возможностью удалять только запрещающие элементы ACE удобно пользоваться, чтобы открывать доступ к объекту для определенной группы или пользователя.

Настройка уровней целостности
Кроме того, средство icacls.exe позволяет посмотреть и установить уровни целостности. В системе Windows Vista поддерживается нанесение меток целостности на объекты. Делается это в командной строке при помощи средства icacls.exe следующим образом:
C:\>icacls c:\test /setintegritylevel high

processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
    Mandatory Label\High Mandatory Level:(NW)

Successfully processed 1 files; Failed processing 0 files
Обратите внимание, что icacls.exe показывает метку целостности объекта, только если она была установлена явным образом. Для большинства файлов это не так, поэтому метки видны редко.
Наконец, средство icacls.exe позволяет проверить, является ли список ACL для того или иного объекта каноническим. Как говорилось ранее, средства сторонних разработчиков могут располагать элементы ACE в списках ACL в неверном порядке. Средство icacls.exe может проверить наличие подобных проблем и исправить их следующим образом:
C:\>icacls c:\test /verify
processed file: c:\test

Successfully processed 1 files; Failed processing 0 files

Пользовательский интерфейс ACL
ACL UI, или пользовательский интерфейс ACL, несколько отличается от используемого в Windows XP. На рис. 4 и рис. 5 показано диалоговое окно пользовательского интерфейса ACL в Windows XP и Windows Vista соответственно.
Рис. 4 Диалоговое окно ACL UI в Windows XP
Рис. 4 Диалоговое окно ACL UI в Windows XP
Рис. 5 Диалоговое окно ACL UI в Windows Vista
Рис. 5 Диалоговое окно ACL UI в Windows Vista
Как можно заметить, кое-что изменилось. Во-первых, в диалоговом окне наконец-то довольно четко отображен обрабатываемый объект — это может быть удобным при работе с несколькими объектами одновременно. Во-вторых, в нижней части есть ссылка на справку. Однако самое заметное изменение — это то, что кнопки «Добавить» и «Удалить» исчезли, а вместо них появилась кнопка «Изменить» — она часто встречается в модулях управления доступом на уровне пользователей (UAC) в Windows Vista. На кнопке стоит значок щита: у пользователя, запустившего диалоговое окно, нет разрешения на изменение списка ACL, ему нужно будет получить повышенные права, прежде чем он сможет редактировать разрешения. Обратите внимание, что эта настройка не будет использоваться по умолчанию, если вы создаете папку в корне диска C: и сразу же проверяете ее свойства. Поскольку вы являетесь владельцем папки, у вас есть неявные разрешения на изменение ACL, поэтому щит не появится. Щит означает специальное имя COM — механизм, при помощи которого выдается запрос на необходимость иметь повышенные права для выполнения части текущего процесса. Если вы нажмете кнопку «Изменить», вы увидите знакомое диалоговое окно повышения. Если в нем нажать кнопку «Далее», появится диалоговое окно, практически совпадающее с тем, что появляется в Windows XP при нажатии кнопки «Добавить». В пользовательском интерфейсе ACL такая двухоконная процедура используется в нескольких местах. Пока не повышены права, появляется одно окно, а когда права повышены, появляется другое — уже знакомое по предыдущим версиям Windows.
Если нажать кнопку «Дополнительно» и перейти на вкладку «Аудит», вы в любом случае увидите кнопку повышения (см. рис. 6). Для изменения аудита обязательно требуются повышенные права, даже если вы имеете полный контроль над объектом и являетесь его владельцем. Это связано с тем, что способность изменять объекты SACL управляется привилегией SE_SECURITY_NAME — в средствах с графическим интерфейсом она называется «Управление аудитом и журналом безопасности». По умолчанию это право есть только у администраторов. Однако в режиме одобрения администратором (когда включено UAC) это право у администраторов отбирается, поэтому даже им необходимо повышение.
Рис. 6 Изменение параметров аудита в Windows Vista всегда требует повышения прав
Рис. 6 Изменение параметров аудита в Windows Vista всегда требует повышения прав
Наконец, вот что нужно упомянуть про изменение списков ACL: все вышесказанное верно, только если UAC не отключен. Если UAC отключить, поведение будет соответствовать тому, что было в Windows XP — разве что диалоговые окна будут выглядеть по-другому. Если вы войдете под учетной записью администратора, повышения нигде не потребуется, поскольку у вашего маркера все время будет идентификатор безопасности администратора.

Другие средства
Средство icacls.exe весьма полезно — и является большим шагом вперед по сравнению с cacls.exe — но и у него есть недостатки. Пожалуй, самый серьезный из них — это способность управлять доступом только к файлам и каталогам. Списки ACL других объектов в Windows Vista мало отличаются от списков в Windows XP, однако в некоторых случаях возникает необходимость управлять списками ACL для служб, разделов реестра, даже объектов Active Directory®.
Ярые приверженцы командной строки используют для этого средство subinacl.exe. Subinacl.exe есть в средствах поддержки. Его также можно загрузить здесь.
Должен вас предупредить, что средство subinacl.exe использовать непросто. Временами оно демонстрирует просто непробиваемое упрямство. И все же оно дает широчайшие возможности управления доступом. Любому уважающему себя администратору это средство необходимо.

Списки ACL для реестра
Списки ACL для реестра, равно как и системные ACL, претерпели некоторые изменения. Впрочем, они не так значимы, как изменения для файловой системы. Самое очевидное отличие от предыдущих версий Windows состоит в том, что из-за устранения группы «опытные пользователи» пропали практически все элементы ACE для опытных пользователей. Теперь считается, что опытные пользователи в действительности не опытнее всех остальных. Это свидетельствует лишь о том, насколько сложны списки ACL. Пропали, конечно, не все элементы ACE для опытных пользователей, но некоторых, к сожалению, действительно не хватает.
Среди списков ACL в реестре вам встретится элемента ACE для идентификатора безопасности с именем RESTRICTED. Он появился не в Windows Vista, но идентификатор этот стоит упомянуть. Не все хорошо понимают, для чего он нужен. Идентификатором безопасности RESTRICTED обозначается любой процесс, представляющий маркер ограничения. Маркер ограничения создается специальной функцией интерфейса API CreateRestrictedToken. Маркер может иметь один или несколько ограничивающих идентификаторов безопасности, используемых в разделенной проверке доступа. Допустим, у нас есть процесс, выполняемый с маркером ограничения. Если такой процесс попытается получить доступ к объекту с элементом ACE для идентификатора безопасности RESTRICTED, Windows на самом деле выполнит две проверки. Первая — это обычная проверка доступа. Вторая же проверка полностью идентична первой, но проверяются только ограничивающие идентификаторы безопасности в маркере. Обе проверки доступа должны пройти успешно.
Сейчас существует несколько списков ACL, использующих идентификатор безопасности RESTRICTED — в частности, в реестре. Снимок экрана, иллюстрирующий такой список ACL, приведен на рис. 7.
Рис. 7 Списки ACL для реестра содержат несколько элементов ACE для идентификатора RESTRICTED
Рис. 7 Списки ACL для реестра содержат несколько элементов ACE для идентификатора RESTRICTED
На данный момент немногие процессы используют маркеры ограничения, тем более с ограничивающими идентификаторами безопасности. В качестве примера можно привести процесс службы, который размещает брандмауэр Windows, базовый механизм фильтрации и службу политики диагностики. Он также использует маркер ограничения записи. Насколько я знаю, только девять служб в Windows Vista используют идентификатор RESTRICTED и маркеры ограничения записи.
Как и в предыдущих версиях Windows, с разрешениями реестра нужно быть очень аккуратным. Изменять их следует только в самых исключительных случаях и для решения строго определенных проблем. Учитывая сложность модели наследования и деликатность операций, выполняемых с реестром, вероятность серьезного сбоя при неосторожном изменении списков ACL в реестре недопустимо высока.

Заключение
Как и в большинстве версий Windows, в Windows Vista были внесены незначительные изменения в управление доступом. Но — в отличие от предыдущих версий — большое количество незначительных изменений довольно серьезно изменило поведение. UAC, в частности, потребовал нескольких корректив: меток целостности и модификации пользовательского интерфейса ACL. Кроме того, произошла первая в истории крупная очистка списков ACL.
Со многих точек зрения стандартные списки ACL в Windows Vista стали проще — такого не было еще никогда. Однако, как и в предыдущих версиях, работая со списками доступа, следует соблюдать осторожность и хорошо понимать происходящее. Это особенно важно в новых версиях ОС. К счастью, средства, описанные в данной статье, помогут вам с меньшими потерями исследовать списки ACL.

Йеспер Йохансон (Jesper M. Johansson) является главным инженером группы безопасности программного обеспечения и пишущим редактором журнала TechNet Magazine. Он защитил диссертацию по информационным системам управления и более 20 лет работает в области обеспечения компьютерной безопасности. Эта статья составлена на основе материалов новой книги Роджера Граймса (Roger Grimes) и Йеспера Йохансона Безопасность в Windows Vista. Защита системы от вредоносных атак (Издательство Wiley, 2007 г.)


 Материалы о рабочей среде: Пакет оптимизации рабочей среды Майкрософт
Материалы о рабочей среде
Пакет оптимизации рабочей среды Майкрософт
Уэс Миллер
Эта статья основана на предварительной версии элементов пакета оптимизации рабочей среды Майкрософт. Любая информация, содержащаяся в ней, может быть изменена.

С самого запуска программы лицензирования Software Assurance (SA) несколько лет тому назад корпорация Майкрософт постоянно стремилась добавить к ней новые функции, чтобы потребители со временем продолжали пользоваться этой программой. Дополнительно к обновлениям продукции Майкрософт, включенным в лицензию, компания стремилась предоставить
продукты и технологии (одним из первых, например, была среда Windows® PE), которые могут оказать помощь организации в улучшении работы с Windows, Office и другими программами Майкрософт.
Основной задачей большинства из этих средств и программ для корпорации Майкрософт было предоставление дополнительных свойств для снижения совокупной стоимости владения Windows, Office и других приложений Майкрософт, включенных в набор SA организации.
В 2006 году корпорация Майкрософт приобрела несколько компаний со схожими целями: сокращение стоимости владения и сложности, связанной с управлением и восстановлением Windows и приложений, основанных на Windows. Корпорация Майкрософт соединила новоприобретенные технологии в один новый вид продукции, доступный в качестве дополнения для клиентов с SA. Технологии от Softricity, DesktopStandard, AssetMetrix и Winternals Software будут доступны в следующем году в качестве компонентов пакета Майкрософт® для оптимизации рабочей среды (MDOP). Кроме того, в состав MDOP будет входить встроенный компонент Майкрософт, называемый компонентом наблюдения за ошибками рабочей среды в составе системного центра Майкрософт (Microsoft System Center Desktop Error Monitoring).
Что касается экономии, то в корпорации Майкрософт было рассчитано, что MDOP может помочь вашей организации экономить от 100 до 500 долларов США ежегодно на каждый настольный компьютер в зависимости от практических рекомендаций, которые вы реализуете при использовании MDOP. Подробные сведения о MDOP можно найти на веб-узле windowsvista.com/optimizeddesktop.

Цели пакета оптимизации рабочей среды Майкрософт
В двух словах, основной целью MDOP является обеспечение корпорации Майкрософт возможности предоставлять новые управленческие технологии по более гибкому графику и не привязывать их к выпуску новых версий операционных систем. Разумеется, Майкрософт хочет избежать повторения разрыва во времени, существовавшего между выпуском Windows XP и Windows Vista™. Предоставляя инструменты в предсказуемые временные интервалы между выпусками новых версий, MDOP позволит корпорации Майкрософт гибко реагировать на потребности пользователей, что поможет корпоративным клиентам извлечь максимальную пользу из затрат на программное обеспечение.
Для придания предприятиям дополнительной гибкости в корпорации Майкрософт разработана стратегия, которая может помочь клиентам перейти к более динамичной инфраструктуре – динамичной в том смысле, который вкладывается корпорацией Майкрософт в термин «инициатива по динамичной системе» (DSI). Дополнительные сведения о DSI можно найти на веб-узле microsoft.com/business/dsi.
Но достаточно высокоуровневой стратегии. Давайте рассмотрим каждую из пяти технологий, включенных в состав MDOP:
  • Виртуализация приложений SoftGrid
  • Служба инвентаризации программного обеспечения
  • Набор средств для диагностики и восстановления
  • Улучшенное управление групповой политикой
  • Компонент наблюдения за ошибками рабочей среды в составе системного центра

Виртуализация приложений SoftGrid
Виртуализация приложений SoftGrid, технология, приобретенная у Softricity, обеспечивает, как явствует из названия, виртуализацию приложений. Когда я начал изучать SoftGrid, я понял, что это то, чем должна была стать публикация приложений для Windows 2000 IntelliMirror®. Почему? Потому, что приложения не публикуются для клиентов, они полностью виртуализируются. Это позволяет получать быстрый доступ к приложениям на клиентских системах или серверах терминалов. Также не менее важно, что приложения могут управляться централизованно и даже вызываться или обновляться при необходимости. В сравнении с традиционной моделью файлов MSI и преобразований модель SoftGrid делает развертывание приложения значительно менее болезненным и менее рискованным.
Работу SoftGrid можно, с одной точки зрения, охарактеризовать как создание виртуального образа. Возможно, вы знакомы с концепцией образа диска, который используется для развертывания Windows (и зачастую приложений внутри нее) на системы. SoftGrid, по сути, берет приложение и упаковывает его в образ приложения, а не в образ всей ОС.
Виртуализация приложений SoftGrid состоит из трех основных компонентов: виртуализация приложения, доставка приложения и центральная консоль управления.
Виртуализация приложения, в свою очередь, состоит из виртуальных представлений файловой системы Windows (включая системные файлы), реестра Windows, шрифтов, INI-файлов, объектов COM/DCOM, служб, объектов ядра (семафоры, взаимные исключения), именованных объектов и пространств имен для всех компонентов.
Важно не путать виртуализацию SoftGrid с тем, как UAC в Windows Vista проводит переадресацию. При использовании UAC, когда приложение пытается сделать запись или изменить защищенные области реестра или системного файла, оно перенаправляется для просмотра реестра и файловой системы отдельного пользователя. SoftGrid, с другой стороны, использует концепцию реальной виртуализации приложения в операционной системе – включая все компоненты реестра и файловой системы, которые его составляют. Изящество SoftGrid состоит в том, что приложение определяется не одним массивом двоичных данных. Напротив, программа состоит из:
  • SFT-файла размером до 4 ГБ. Он состоит из одного или более приложений и всех их зависимостей, за исключением зависимостей Windows, которые должны быть в системе назначения.
  • OSD-файла размером приблизительно 2 КБ. Он содержит определение того, как вызывать и выполнять приложение. Можно считать файл OSD аналогом файла EXE.
  • ICO-файла размером приблизительно 24 КБ. Это фактически ярлык для запуска приложения.
  • SPRJ-файла размером приблизительно 13 КБ. Он используется секвенсером (сердцем SoftGrid) для публикации, открытия, обновления и восстановления существующих пакетов.
Чертеж с изображением полной схемы работы виртуализации приложений SoftGrid находится на веб-узле softricity.com/ products/architecture.asp.
Огромным преимуществом решения SoftGrid является то, что центральная консоль управления (см. рис. 1) может использоваться для определения того, какие приложения доступны для определенного пользователя или ряда пользователей Active Directory®. Эти приложения могут быть быстро направлены пользователям по требованию при помощи стандартного потокового протокола. После установки приложения ведут себя так, будто они были изначально установлены в системе, они не нарушают пользовательские настройки (даже через перемещаемые профили пользователей) и функционируют даже тогда, когда клиентов отключают от сети. Администраторы даже могут отключать доступ к этим приложениям – динамически или автоматически (через определенное время, например).
Рис. 1 Консоль управления SoftGrid
Рис. 1 Консоль управления SoftGrid
Что немаловажно – вследствие того, как развертываются приложения, нет необходимости получать доступ ко всему приложению. Вместо этого загружаются лишь те фрагменты, которые необходимы пользователю для запуска приложения. Представьте себе ситуацию, в которой весь Microsoft Office доступен как один пакет. Если пользователь запускает только Word, загружаются только необходимые для него компоненты, а не компоненты для запуска Excel®, PowerPoint® и так далее. Как только пользователь выбирает для работы одно из этих приложений, например Excel, загружаются все необходимые для него компоненты.
Что находится в ERD?
  • Командная строка
  • Проводник
  • Поиск
  • Блокнот
  • Мастер решений
  • Административные инструменты: автозапуск, диспетчер дисков, просмотр событий, редактор реестра, службы и драйверы, системная информация
  • Средства работы с сетью: общий доступ к файлам, подключение сетевых дисков, настройка TCP/IP
  • Системные средства: Анализатор сбоев, Disk Commander, DiskWipe, FileRestore, удаление исправлений, Locksmith, восстановление системных файлов, восстановление системы

Еще один компонент SoftGrid – это способность автоматического измерения и проверки лицензии. Эта способность помогает вам регулировать вопросы лицензирования программного обеспечения без дополнительных программ.
Практически любое приложение можно сделать виртуальным. Основными исключениями являются Internet Explorer® и другие компоненты Windows (за исключением исправлений и пакетов обновлений), антивирусные программы и драйверы устройств. Если вам необходима дополнительная информация о работе и возможностях SoftGrid, вы можете ознакомиться с документацией на веб-узле Softricity.com.

Улучшенное управление групповой политикой
DesktopStandard создал себе имя разработкой средств, которые соединили некоторые слабые звенья групповой политики. Предлагая в MDOP средство, ранее известное как GPOVault, а теперь получившее название «Улучшенное управление групповой политикой», корпорация Майкрософт обеспечила пользователей отличным средством, которое может превратить GPO из мощного (но иногда опасного) средства в процесс более усовершенствованный и контролируемый.
Если вы знакомы с основами программ управления версиями исходных текстов, представьте себе Улучшенное управление групповой политикой как управление версиями групповых политик Active Directory. (На рис. 2 показана консоль улучшенного управления групповой политикой.) Администраторы проверяют существующие исправления политики, вносят изменения и возвращают их обратно, проверяют результаты, используя консольные отчеты управления групповой политикой. Как только администратор убеждается в том, что желаемое состояние политики достигнуто, он может закончить изменения и ввести их в действие. Как и при работе с любой программой управления версиями, если что-то происходит не так, изменения можно быстро и безопасно отменить, вернувшись к более ранней версии без каких-либо догадок, обычно имеющих место в таком процессе.
Рис. 2 Консоль улучшенного управления групповой политикой
Рис. 2 Консоль улучшенного управления групповой политикой
Другим важным аспектом этого процесса является способность редактировать политики в автономном режиме вместо внесения изменений во все активные системы в оперативном режиме. Это позволяет проводить изолированное тестирование изменений прежде, чем они будут применены к домену или подразделению.
И наконец, при помощи модели на основе ролей улучшенное управление групповой политикой позволяет вносить изменения через спроектированный рабочий процесс. Создавая роли (такие как редактор, проверяющий и рецензент), администратор может обеспечить внедрение процесса, который позволит вносить изменения управляемым образом. Когда он убедится в том, что изменение можно реализовать, он может применить механизм управления изменениями, предотвращающий непредвиденные изменения GPO без соответствующего одобрения.

Служба инвентаризации программного обеспечения
Служба инвентаризации программного обеспечения (AIS), построенная на основе технологии, которую Майкрософт приобрел вместе с AssetMetrix, является очень мощной программой инвентаризации и управления программным обеспечением. В отличие от других компонентов MDOP, AIS использует веб-модель, размещенную в сети. AIS использует агент очень небольшого объема и с низкой пропускной способностью, который может запускать однократно или с периодическими интервалами, позволяя администратору производить поиск приложений в расширенной базе данных, размещенных у Майкрософт и содержащей более 400 000 приложений, для определения того, какие приложения установлены на клиентских системах. AIS затем может взять полученные данные и согласовать их с имеющимися у вас лицензиями для обеспечения соответствия и уменьшения проблем при покупке лишних лицензий.
Некоторые администраторы могут поначалу с неохотой использовать AIS, поскольку эта модель не защищена брандмауэром и проводит инвентаризацию внутренних систем на предмет установленного программного обеспечения. Однако необходимо понимать, что Майкрософт проводит большую работу по обеспечению организационной конфиденциальности, начиная с переписывания основных компонентов приложения, составляющего AIS. Нет никакой привязки данных индивидуального компьютера к любым организационным данным. Майкрософт также намерен сертифицировать технологию передачи данных третьей стороне, чтобы клиентам было удобнее работать с моделью, использующейся AIS.

Набор средств для диагностики и восстановления
Как вы, возможно, знаете (если вы когда-нибудь читали биографические данные в моих статьях за последние несколько месяцев), я работал в компании Winternals в то время, когда она была приобретена Майкрософт. В период моей работы в этой компании я был менеджером по продукции и занимался практически всеми программами Winternals, включая Winternals Administrator’s Pak. Эта программа была предшественником набора средств для диагностики и восстановления (DaRT) корпорации Майкрософт. Несмотря на то, что некоторые средства, существовавшие в Administrator’s Pak, не были включены в DaRT, основные компоненты, составляющие ERD Commander, все еще используются.
Целью DaRT является обеспечение набора средств, которые помогут вам в диагностике системных проблем – даже если система неправильно загружается. И часто можно исправлять эти проблемы в автономном режиме.
ERD Commander использует Windows PE для загрузки системы, которая не загружается или загружается неправильно. Набор средств доступен в пользовательском интерфейсе, похожем на окно проводника Windows. Два из этих средств, Crash Analyzer и FileRestore, доступны также в оперативном режиме. Однако они должны быть установлены на каждой системе, в которой нужно с ними работать, если вы не используете ERD Commander для автономной диагностики или восстановления.
Версия ERD Commander, входящая в состав DaRT, показана на рис. 3. Список средств, входящих в компонент ERD Commander, находится на боковой панели. За исключением средства «проводник», первые пять перечисленных средств – это те же самые приложения, которые вы используете при обычной установке Windows. Проводник, а также приложение Главного меню, из которого он запускается, это специализированная (уменьшенная) версия, разработанная для работы под Windows PE.
Рис. 3 ERD Commander
Рис. 3 ERD Commander
Автозапуск – это средство, разработанное на основе средства Sysinternals с тем же названием, которое позволяет видеть все приложения, которые предназначены для запуска при загрузке системы или входе пользователя в сеть. Диспетчер дисков, просмотр событий, службы и драйверы, а также системная информация – это инструменты, которые находятся в обычном пользовательском интерфейсе и предоставляют функции, аналогичные инструментам Windows с таким же названием. Службы и драйверы - особенно полезный инструмент, который помогает вам загружать систему, когда она дает сбой вследствие драйвера устройства или службы, который работает неверно. И наконец редактор реестра Windows включен, чтобы вы могли управлять реестром в автономном режиме.
ERD Commander также предоставляет возможность сетевой работы. Хотя система автоматически настроена через DHCP, можно установить статический IP-адрес, используя программу настройки TCP/IP. Вне зависимости от того, используете вы DHCP или статическую IP-адресацию, вы можете либо подключить сетевой диск и скопировать файлы в отказавшую систему или из отказавшей системы или использовать программу предоставления доступа к файлам, чтобы превратить вашу систему в файловый сервер и, таким образом, использовать работающую систему для копирования файлов с отказавшей системы.
Кроме того, в программу включен целый ряд других средств. Анализатор сбоев использует средства отладки для Windows (которые необходимо загрузить и установить отдельно – да, они бесплатны, но часто обновляются) для диагностики причины сбоя. Их можно запускать их либо в автономном режиме при помощи ERD Commander, если система не загружается, или скопировать файл DMP на рабочую систему с установленной программой DaRT и провести диагностику там. После обнаружения проблемы, если она заключается в новой службе или драйвере, можно использовать средство «Службы и драйверы», чтобы отключить ее и посмотреть, будет ли система работать нормально.
Disk Commander поможет восстановить раздел, который был случайно удален или поврежден, а также группу файлов или каталог, который был удален. С другой стороны, DiskWipe позволит произвести процедуру стирания информации с диска или тома, соответствующую требованиям министерства обороны США. FileRestore позволяет (в автономном или оперативном режиме) восстановить файл, который был случайно удален. Не забывайте, что на возможность восстановления влияет тип файла и время/активность диска с момента удаления, вне зависимости от того, какое средство используется.
В случае, если исправления или пакет обновлений Windows мешает системе загружаться нормально, можете использовать средство удаления исправлений для выборочного удаления одного или нескольких исправлений или пакетов обновления. Для завершения процесса необходима перезагрузка, поскольку Windows не поддерживает полное автономное удаление приложений. Но это зачастую может помочь восстановить возможность загрузки системы.
Locksmith был одним из самых популярных средств, включенных в набор ERD Commander во времена Winternals. Он позволяет сбросить любой пароль локального пользователя. Он не работает с доменными контроллерами и не может сбросить пароль доменного пользователя; обычно он используется для сброса пароля локального администратора, если тот забыл его, или если пользователь больше не работает в организации. Средство восстановления системных файлов просматривает все защищенные системные файлы на предмет повреждений и восстанавливает их при необходимости. Средство восстановления системы, как ясно из названия, позволяет вернуться к любой точке восстановления системы Windows в Windows XP. (Для того, чтобы воспользоваться этой функцией, необходим Windows XP с уже существующими точками восстановления.) Я вхожу в число множества пользователей, которых не раз спасала эта уникальная функция.
Средства в ERD Commander и DaRT могут показаться несколько случайным набором, но они являются мощным сочетанием служебных программ, разработанных в свое время компанией Winternals. Я уверен, что вы сможете оценить их по достоинству и использовать при решении проблем и восстановлении системы.

Компонент наблюдения за ошибками рабочей среды системного центра
Компонент наблюдения за ошибками рабочей среды системного центра (DEM) предлагает любой организации быстрый и простой способ централизовать и обнаружить сбои Windows и зависания приложений. Вместо отправки отчетов о сбоях и зависаниях в Майкрософт DEM использует групповую политику и встроенный в Windows средство создания отчетов об ошибках для отправки отчетов на сервер вашей организации, отвечающий за диагностику (при этом он не требует дополнительного программного агента). Все данные сервера DEM хранятся в базе данных SQL Server, так что можно легко сделать запрос к собранным данным для внутренних нужд и создания отчетов. Это позволяет заранее обнаруживать проблемы в организации. Используя эти сведения, можно сделать отчет об этих случаях обязательным, обнаружить наиболее частые причины сбоев и зависаний, а также гарантировать, чтобы исправления для Windows и приложений были в основном направлены на сведение к минимуму или полное исключение нерабочего состояния системы.
Кроме того, можно настроить свой сервер DEM так, чтобы он передавал результаты в Майкрософт и автоматически загружал последние данные по исправлению ошибок для приложений Майкрософт и других компаний. В случае сбоя или ошибки можно получать с клиентов дополнительные данные .

Лицензирование MDOP
Первым требованием для пользователя, желающего лицензировать MDOP, это наличие соглашения SA с Майкрософт. При наличии этого соглашения лицензия будет стоить от 7 до 10 долларов США для каждого настольного компьютера. Возможны скидки в зависимости от объемов закупки и специальные цены для учебных целей.
MDOP нельзя приобрести без наличия договора SA, за одним исключением: пользователи, желающие использовать технологии SoftGrid на своих серверах терминалов (см. softricity.com/solutions/sbc.asp) или SMS (см. softricity.com/products/softgrid-sms.asp), могут это сделать, а технологии AssetMetrix будут доступны в следующих версиях программ для SMS и компонента управления конфигурацией системного центра.

Доступность и обновления
Основные компоненты MDOP доступны уже сегодня. Доступны следующие компоненты:
  • SoftGrid доступен в Майкрософт с начала 2007 года.
  • Microsoft DaRT доступен с мая 2007 года.
  • Технологии GPOVault будут доступны с июля 2007 года.
  • Компонент наблюдения за ошибками рабочей среды будет доступен в MDOP с июля 2007 года.
  • Технологии AssetMetrix будут доступны в бета-версии с июля 2007 года, а в окончательном варианте – с августа.
  • Обновление компонентов DaRT планируется на конец 2007 года, с упором на совместимость с Windows Vista.
Планы на будущий выпуск версий MDOP с целью улучшений, обновлений и добавления новых функций – дважды в год.

Направление развития MDOP
Как уже упоминалось, основные компоненты технологий AssetMetrix будут интегрированы в будущие версии компонента управления конфигурацией системного центра. Через некоторое время, по мере развития корпорацией Майкрософт функциональности MDOP, можно ожидать, что некоторая часть этих технологий перейдет в основные технологии Майкрософт по развитию, управлению и настройке. Новые технологии (некоторые из которых будут разработаны Майкрософт, а некоторые приобретены у других компаний) станут доступны в будущих версиях MDOP. По сути, MDOP станет развивающимся набором технологий по современному управлению и настройке.

Уэс Миллер — менеджер по разработкам в компании Pluck в г.Остин, шт.Техас. Ранее он работал в компании Winternals Software в том же городе, а также в должности руководителя программы и менеджера по продукту Windows в корпорации Майкрософт. Связаться с Уэсом можно по адресу technet@getwired.com.
Я хотел бы выразить благодарность Чаду Джонсу и Гавриелле Шустер, менеджерам по продуктам, работающим с пакетом оптимизации рабочей среды Майкрософт, за помощь при написании этой статьи.


 Конфиденциальная информация Windows: Преимущества безопасного режима
Конфиденциальная информация Windows
Преимущества безопасного режима
Рэймонд Чен (Raymond Chen)

Когда безопасный режим для операционной системы Windows® 95 (также известный как режим "о, Господи, все пропало, пожалуйста, верните!") был разработан впервые, предполагалось, что он будет обладать большим набором функций, а не только отключать драйверы. Также предполагалось, что с его помощью можно будет исправлять те проблемы, которые могут быть исправлены автоматически.
Например, при начале работы в безопасном режиме проводник Windows проверяет расположение всех значков на рабочем столе, чтобы они все были видны, так как возможно создать такое состояние, при котором значки будут расположены за пределами экрана.
Чтобы понять, о чем идет речь, расположите два значка на рабочем столе - один вплотную к левому краю, второй - к правому. С помощью сочетания клавиш Ctrl+Click выделите оба значка, затем возьмите тот, что расположен слева, и переместите в правую часть экрана. При этом второй значок также переместится, сохраняя свое прежнее расположение относительно перемещаемого вами значка. Таким образом, второй значок переместится вправо за пределы экрана.
Безопасный режим позволяет пользователям устранять проблемы, возникающие в Windows
Безопасный режим позволяет пользователям устранять проблемы, возникающие в Windows
В том случае, если проводник Windows в безопасном режиме не исправил расположение значков, инструкции по устранению неполадок скорее запутают, чем помогут:
  1. Запустите компьютер в безопасном режиме. (OК.)
  2. Дважды щелкните значок «Мой Компьютер». (Хм, а у меня значок «Мой Компьютер» куда-то пропал.)
  3. ...
Ой, значок «Мой Компьютер» находится за пределами экрана или по каким-то другим причинам недоступен. Вы даже не сможете вернуться на второй шаг устранения неполадок.
От некоторых людей поступали жалобы такого характера: «не следует исправлять расположение значков автоматически. Когда пользователь обращается в техническую поддержку со своей проблемой, инженер технической поддержки может просто посоветовать пользователю щелкнуть рабочий стол правой кнопкой мыши и выбрать пункт «Упорядочить значки автоматически». Задание выполнено, и никакой безопасный режим не нужен, чтобы разобраться со значками.»
Во-первых, сказав «когда пользователь обращается в службу технической поддержки со своей проблемой», вы уже проиграли. Если пользователь поднимает телефонную трубку, это означает, что вы со своей задачей не справились.
Кроме того, это предложение не учитывает особенностей безопасного режима. Пользователи запускают компьютер в безопасном режиме, когда что-то идет не так, хотя они не обязательно знают, что они будут при этом делать. Что они на самом деле делают, так это просто смотрят, что же получится. «Что-то не так, нужно запустить безопасный режим». В операционной системе Windows 95 мы пользовались преимуществом ее особенностей, применяя в безопасном режиме различные типы автоматических исправлений. Это вполне неплохо работало.
Что еще нужно, если пользователи вам звонят, и вы им говорите «загрузитесь в безопасном режиме, это поможет», они думают про себя: «ну что, это же просто. Мне следовало над этим подумать.»
Но если вы предоставите им более обширный набор указаний, сказав: «запустите компьютер в безопасном режиме, щелкните правой кнопкой мыши здесь, выберите этот пункт меню, а потом установите этот флажок», пользователи выполнят инструкции, и проблема будет решена, но это совсем не прибавит им уверенности в обращении с компьютерами. Вместо этого они будут чувствовать себя слабыми и обескураженными. Вместо того чтобы получить возможность самостоятельно разобраться с проблемой, пользователи чувствуют себя беспомощными. «Я никогда не смогу с этим управляться. Компьютеры - это для меня слишком сложно.»

Рэймонд Чен (Raymond Chen) на своем веб-узле The Old New Thing (Хорошо забытое старое) и в книге с таким же названием (издательство Addison-Wesley, 2007 г.) рассказывает об истории развития Windows и касается вопросов программирования в среде Win32. Он предпочитает убегать до того, как предохранитель сгорел.