Источник http://technet.microsoft.com

 Хотя SharePoint предлагает несколько вариантов проверки подлинности и зон аутентификации, двумя общепринятыми вариантами выбора для корпоративной реализации в сценариях интрасети являются протокол NTLM и Kerberos. Оба эти протокола используются совместно со встроенной проверкой подлинности Windows по классической схеме Запрос/Ответ. Протокол NTLM использует метабазу IIS, генерирующую маркер с вызовом, который она отправляет клиенту, клиент отвечает маркером, а контроллер домена проверяет подлинность данного ответа. В протоколе NTLM необходимо шифрование имен пользователей и паролей перед их передачей, а также повторная проверка подлинности (новый маркер) при получении доступа к новому сетевому ресурсу. Протокол Kerberos, с другой стороны, основывается на системе билетов, когда клиент и сервер получают доступ к доверенному центру авторизации под названием Центр распределения ключей (Key Distribution Center, KDC), который отвечает на запросы клиента и выдает билеты, которые могут использоваться клиентом для подключения к сетевым ресурсам. Для протокола Kerberos не требуется повторная проверка подлинности для получения доступа к нескольким ресурсам.


В большинстве документов советуют использовать протокол NTLM, если только нет необходимости, например, для узлов с соглашениями о высоком уровне безопасности служб. Даже в этом случае, если как следует разобраться, имеется смысл использовать протокол NTLM: его легче внедрять, он требует дополнительных этапов проверки, а также уменьшает проблемы, связанные с технической поддержкой. Например, в базе знаний 832769 сказано: "… или если вы не можете настроить имя участника-службы (SPN), выбрать проверку подлинности с помощью протокола NTLM. Если вы выбираете проверку подлинности с помощью протокола Kerberos и не можете настроить SPN, только администраторы сервера смогут произвести проверку подлинности узла SharePoint". Инструкции являются технически точными, но это не означает, что настройка имен SPN является чрезмерно сложной, или что вы должны избегать использования протокола Kerberos, пока кто-то вас не заставит внедрить его. Но в действительности, если вы понимаете принципы, внедрение протокола Kerberos не является таким уж сложным занятием.
 

Существует множество веских причин, почему вы должны перейти на Kerberos, или использовать протокол Kerberos с самого начала в новой реализации, но в большинстве случаев все сводится к вопросам производительности или безопасности. При возникновении дополнительных сложностей с нагрузкой пользователей или топологией, протокол NTLM может вызвать проблемы с производительностью, потому что проверка подлинности на основе протокола NTLM, по сути своей, требует несколько циклов передачи данных между метабазой IIS и контроллером домена во многих случаях использования SharePoint, например, при получении доступа веб-приложения к веб-компоненту SharePoint или пользовательской веб-службе. Возможность возникновения проблем с производительностью особенно высока, если доступ к контроллеру домена осуществляется через медленное подключение или связь с большими задержками. С точки зрения безопасности, система на основе билетов (Kerberos) с прямым делегированием сетевых ресурсов является более безопасной, нежели системы, использующие шифрование пользовательских учетных данных. Она также быстрее, потому что использует один билет для получения доступа к нескольким сетевых ресурсов.

Множество установок запускаются с протоколом NTLM вместо протокола Kerberos, потому что использование топологий планирования, распределения размеров серверов, поставщиков поддержки безопасности (SSP) и других деталей уже кажется страшной задачей, а дополнительные сложности вообще покажутся чрезмерными. Данное утверждение имеет смысл. В конце концов, реализации на основе протокола Kerberos имеют свои проблемы. Взгляните на статьи 871179, 962943 и 832769, имеющиеся в базе знаний для получения информации о некоторых проблемах, которые могут быть настолько серьезными, например, как синий экран с ошибкой STOP. Даже существующая документация, например, подробное руководство Microsoft по реализации протокола Kerberos, не содержит информации о метабазе IIS версии 7 и более поздних версий, в которых используется функция проверки подлинности в режиме ядра и изменен способ обработки имен SPN. Но не волнуйтесь, если вы понимаете фундаментальные концепции использования протокола Kerberos приложением SharePoint, то реализация и настройка вам покажется сравнительно несложной. В данной статье рассматриваются важные компоненты архитектуры и содержатся некоторые детали настройки, которые помогут вам начать работу. Корпорация Microsoft уже опубликовала документацию с поэтапными инструкциями, а также статьи 832769 и 953130 в базе знаний KB, которые вы можете использовать в качестве дополнительной информации.
 

Компоненты и зависимости проверки подлинности

Начнем с обзора зависимостей в архитектуре SharePoint, использующей встроенную проверку подлинности Windows. На самом базовом уровне, с протоколом NTLM или Kerberos, имеется клиент, выполняющий запросы веб-страницы SharePoint.aspx, использующей метабазы .NET и IIS в фоновом режиме. В свою очередь, страница использует данные настроек сервера SQL Server и базы данные содержимого. Способ обработки запросов службами IIS в контексте SharePoint 2007 относительно проверки подлинности показан на рис. 1. Если браузер клиента выполняет веб-запрос, запускается поток в метабазе IIS, а объекты, относящиеся к запросу, например, маркер, содержащийся в объекте IIdentity, который находится в объекте IPrincipal, прикреплены к потоку. Программными средствами доступ к объектам IIdentity и IPrincipal осуществляется через свойство HttpContext.User, а оба объекта и свойство настраиваются модулями проверки подлинности, которые являются частью конвейера .NET, как показано на рис. 1.
 

Рис. 1. Общие компоненты проверки подлинности и поток данных в SharePoint

Ниже приведено описание потока данных:

1. Браузер клиента инициирует подключение к серверу переднего плана SharePoint (обрабатывается метабазой IIS через конвейер .NET) с помощью анонимного запроса HTTP GET.
2. Если зона настроена на анонимный доступ (например, для сценариев Интернет), метабаза IIS продолжает обработку запроса. В противном случае метабаза IIS выдаст ошибку 401.2 и сделает запрос на проверку подлинности у браузера клиента.
3. Браузер клиента получит запрос и в зависимости от зоны и соответствующих условий, проверит подлинность клиента. Основным способом является выполнение команды AcquireCredentialsHandle и ввод имени пользователя/пароля, затем маркер проверки подлинности передается обратно в SharePoint через IIS.
4. Метабаза IIS ожидает ответа в диалоге с HTTP и принимает маркер проверки подлинности, а затем разрешает или запрещает доступ. На этом этапе IIS передает запрос в SharePoint через конвейер .NET.
5. Если на запрашиваемой странице имеется веб-компонент, для которого необходим доступ к серверным базам данных SQL, SharePoint проходит проверку подлинности с помощью сервера SQL Server и получает доступ к базам данных. Характер проверки подлинности SQL варьируется в соответствии с вариантами настройки. Например, вы можете настроить проверку подлинности сервера SQL Server или встроенную проверку подлинности Windows с помощью протокола NTLM или Kerberos. Я расскажу о специфике протоколов Kerberos и NTLM в этой статье далее.
6.  

Ключевая мысль о механизмах проверки подлинности в SharePoint заключается в том, что здесь играют роль три слоя: браузер клиента, метабаза IIS с конвейером .NET и сервер SQL Server. Для возвращения скомпилированной страницы .aspx, производится проверка подлинности и авторизация между клиентом, метабазой IIS и сервером SQL Server. Иногда процесс упрощается, например, при использовании протокола NTLM в случае, если сервер SQL Server находится на том же физическом сервере, что и метабаза IIS. В этом случае существует только один прыжок из клиента в метабазу IIS. Для получения дополнительных сведений о проверке подлинности в .NET, просмотрите статью Инструкции: проверка подлинности Windows в ASP.NET 2.0.
 

NTLM и Kerberos

Теперь, после того как мы рассмотрели базовый механизм, используемый Windows Server, IIS и .NET при проверке подлинности и авторизации пользователей, давайте посмотрим, как он подходит в контексте встроенной проверки подлинности Windows с протоколами NTLM и Kerberos. Как уже упоминалось, основное отличие протокола NTLM от Kerberos заключается в том, что протокол NTLM использует механизм Запрос/Ответ, требующий проверки подлинности и авторизации для получения доступа к любому сетевому ресурсу. А протокол Kerberos использует систему билетов, которая выполняет проверку подлинности один раз и затем производит авторизацию с помощью делегирования. Не пугайтесь, если это различие покажется непонятным, далее я все разъясню. На рис. 2 показано, каким образом SharePoint обрабатывает запросы при использовании протокола NTLM.
 

Рис. 2. Проверка подлинности NTLM в SharePoint

Как видно из рис. 2, использование протокола NTLM требует наличия контроллера домена с возможностью проверки подлинности пользователей. Если домен работает в стандартном режиме, по умолчанию на контроллере домена или другом сервере потребуется наличие глобального каталога. Вот вам и еще одна потенциальная проблема с производительностью в дополнение к проблеме двойного прыжка, потому что после установления связи с контроллером домена, запросы проверки подлинности перенаправляются на сервер глобального каталога, если глобальный каталог не доступен локально. С медленными сетевыми каналами может использоваться много ресурсов и большая часть пропускной способности. Вы можете попытаться выжать дополнительные уровни производительности с помощью проверки подлинности с протоколом NTLM, например, заменив значение записи реестра MaxConcurrentApi, но это не объясняет фундаментальной необходимости в протоколе NTLM для использования схемы Вызов/Ответ, а также не решает соответствующие проблемы с производительностью при работе с большими нагрузками.

Ниже представлены детали проверки подлинности с протоколом NTLM для учетных записей в одном домене:

1. Процесс начинается, как упоминалось выше, когда браузер клиента инициирует подключение к серверу SharePoint с метабазой IIS и конвейером .NET с помощью запроса HTTP GET и пытается произвести анонимную проверку подлинности.
2. Метабаза IIS отклоняет анонимный запрос с ошибкой 401.2 и отправляет запрос обратно для проверки подлинности с помощью протокола NTLM (WWW-Authenticate: NTLM).
3. Браузер клиента получает запрос и вызывает компонент InitializeSecurityContext для создания маркера проверки подлинности, в который входит имя домена и компьютера, и затем отправляет маркер проверки подлинности в метабазу IIS.
4. Метабаза IIS принимает детали и отправляет клиенту запрос NTLM.
5. Клиент отправляет ответ на запрос (опять используется маркер проверки подлинности), зашифрованный паролем пользователя.
6. На данном этапе метабазе IIS необходимо совершить диалог с контроллером домена. Она отправляет имя пользователя клиента, запрос и ответ на запрос.
7. Контролер домена получает хэш пароля пользователя и сравнивает его с ответом на запрос, который был зашифрован с помощью учетных данных пользователя. Если они совпадают, контроллер домена выдает сообщение об успешной проверке метабазе IIS, и метабаза IIS может начать диалог с браузером клиента.
8. После чего веб-приложение проверяется сервером SQL Server и может получить доступ к базе данных содержимого, в которой сохранены данные для страницы .aspx.
9.  

Если вы когда-нибудь пытались настроить протокол Kerberos на веб-странице центра администрирования для базовой установки, вы должны знать, что после выбора протокола Kerberos вместо NTLM, появится сообщение, в котором будет говориться о том, что вы должны настроить учетную запись пула приложений для разрешения работы протокола Kerberos, если только пул приложений не работает в контексте сетевой службы. Это может быть вызвано способом выполнения проверки подлинности на основе протокола Kerberos с использованием необходимых имен SPN. Как в WSS, так и в MOSS, веб-приложение является веб-узлом IIS, назначенным для пула приложений, который работает в контексте встроенной учетной записи или учетной записи пользователя. Имеется возможность, но не рекомендуется, назначить несколько веб-узлов для одного пула приложений. Если вы не внесете изменения, метабаза IIS использует учетную запись сетевой службы для пулов приложений, а не уникальную учетную запись домена. Однако чтобы протокол Kerberos работал в среде SharePoint, вы должны установить уникальное имя SPN в учетной записи пула приложений.

На практике связь на основе протокола Kerberos основана на использовании клиентов и сервера с поддержкой Kerberos, Центра распределения ключей, который выступает в роли промежуточного звена проверки подлинности, и имен SPN. Технические детали немного сложнее. Например, для протокола Kerberos требуется интеграция DNS с Active Directory или BIND с записями SRV, TCP/IP и служба времени. Скорее всего, если вы используете Windows Server 2003 или 2008 с интегрированной системой DNS, у вас уже имеются необходимые компоненты, и вам просто нужно их настроить. На рис. 3 показаны различные компоненты и поток данных при проверке подлинности на основе протокола Kerberos в среде SharePoint.
 

Рис. 3. Проверка подлинности на основе протокола Kerberos

1. Как и в случае с протоколом NTLM, браузер клиента выполняет анонимный запрос HTTP GET, используя имя компьютера (FQDN или псевдоним).
2. Сервер переднего плана выдает ошибку 401.2 и сообщение — WWW-Authenticate: Согласуйте заголовок и/или параметр WWW-Authenticate. Заголовок Kerberos означает, что имеется поддержка проверки подлинности на основе протокола Kerberos. Вы должны настроить его для серверов переднего плана в центре администрирования, о чем я писал выше.
3. Клиент связывается с Центром распределения ключей в контроллере домена и запрашивает билет для SPN, который основан на информации, отправленной браузером клиента, представляющей собой имя компьютера.
4. Если Центр распределения ключей обнаруживает совпадающее имя SPN, он зашифровывает билет и возвращает его.
5. Браузер клиента создает средство проверки подлинности и отправляет его с билетом службы в IIS-сервер, который, в свою очередь, дешифрует билет, определяет достоверность и проверяет полномочия (список контроля доступа) на запрашиваемый ресурс.
6. Если доступ разрешен, метабаза IIS, через службу веб-приложений, связывается с сервером SQL, а служба запрашивает билет для сервера SQL Server от Центра распределения ключей.
7. Если имя SPN найдено, Центр распределения ключей возвращает билет, используемый веб- приложением для запроса базы данных содержимого, и с помощью делегирования персонифицирует пользователя.
8. Сервер SQL Server проверяет билет, полученный от веб-приложения, и подтверждает его подлинность. При успешном выполнении сервер SQL Server отправляет данные обратно на сервер, а конвейер .NET компилирует страницу .aspx и отправляет ее браузеру.

Понимание имен SPN

Имена SPN представляют собой один из самых сложных аспектов настройки протокола Kerberos, потому что они зарегистрированы Центром распределения ключей как уникальные идентификаторы для клиентских ресурсов, которые авторизированны для получения доступа к определенным серверным ресурсам. Как клиенты, так и серверы, а также и контроллер домена, при встроенной проверке подлинности Windows доверяют Центру распределения ключей, потому что в большинстве случаев Центру распределения ключей необходим способ для определения того, предоставлять билет на запрос или нет — эти функция возложена на SPN. Как уже было упомянуто, если вы настраиваете учетную запись пользователя домена для пула приложений, вы также должны настроить SPN для него, чтобы любой пользователь мог получить доступ к веб-приложению, относящемуся к пулу приложений.

Имя SPN является строкой уникального идентификатора для службы, которая работает на сервере. Оно хранится в Active Directory в виде атрибута с множественными значениями учетной записи пользователя под названием Service-Principal-Name (имя участника-службы). Множество служб на компьютере или большое количество компьютеров различаются при помощи их уникальных имен SPN. Возможно, я переоцениваю важность имен SPN, но тому есть причина. Некорректно настроенные имена SPN приводят к нарушению проверки подлинности на основе протокола Kerberos. Если вы установите два идентичных имени SPN, или забудете установить имя SPN, или неправильно зададите часть имени SPN, проверка подлинности не заработает.

Рассмотрим пример имен SPN и то, каким образом протокол Kerberos использует их. Имя SPN состоит из трех частей: класс службы, определяющий тип службы, имя компьютера, на котором запущена служба, и порт. Сведя все компоненты вместе, получаем следующий синтаксис service class/host: port. Для среды SharePoint двумя подходящими именами являются HTTP и MSSqlSvc. Имена службы не являются произвольными и определяются как специальные псевдонимы для службы. Имя компьютера — имя FQDN или NetBIOS, дополнительно включающие порт. При регистрации имен SPN, рекомендуется регистрировать SPN как для имен компьютера NetBIOS, так и FQDN, потому что, несмотря на используемый клиентом способ, они могут получить доступ к ресурсам на целевом компьютере.

Ранее я говорил, что пока вы не запустите пул приложений под учетной записью сетевой службы, вам придется регистрировать имена SPN. Это объясняется тем, что когда компьютер входит в домен Active Directory, имена SPN создаются автоматически для учетной записи компьютера в формате HOST/<NetBIOSname> и HOST/<FQDN>. Ввиду того, что учетная запись сетевой службы выступает как компьютер в сети, имена SPN действительны и для нее. Однако не рекомендуется использовать локальную учетную запись сетевой службы из-за вопросов безопасности, и потому, что это может привести к нарушениям в работе некоторых сценариев. Например, если вы восстанавливаете или подключаете базу данных содержимого, настроенную под учетной записью сетевой службы, вы должны добавить учетную запись в локальную группу "Администраторы" сервера SQL Server, а затем удалить ее после подключения базы данных. В большинстве существующей документации рекомендуется использовать учетные записи домена.
 

Настройка серверной части

Сначала вы должны настроить проверку подлинности на основе протокола Kerberos на сервере SQL Server, переносите ли вы существующую ферму или устанавливаете новую. Сервер SQL Server должен соответствовать выше упомянутым требованиям, например, должен быть подключен к домену, иметь доступ к контроллеру домена, который также является и Центром распределения ключей, и т.д. В большинстве сред эти требования выполнены по умолчанию при использовании Active Directory с интегрированной системой DNS. Вам не нужно детально настраивать протокол Kerberos, если в вашей среде используются только серверы SharePoint переднего плана, а серверы приложений не используются, например, на которых работают службы Excel или службы отчетов SQL. Стандартного имени SPN, созданного при подключении сервера SQL Server к домену, достаточно для основного подключения переднего плана или фонового подключения.

Настройка протокола Kerberos на сервере SQL Server является сравнительно несложной задачей. Сначала вы устанавливаете соответствующие имена SPN, проверяете факт того, что используется протокол Kerberos, а не стандартный протокол NTLM. Вы должны задать имя NetBIOS и FQDN в формате MSSQLSvc/<NetBIOS_Name>:1433 и MSSQLSvc//<FQDN-hostname.domain.local>:1433, предполагая, что ваш экземпляр будет использовать стандартный порт — 1433. Хотя вы можете использовать средство setspn или ADSIEdit для установки SPN, setspn обычно является лучшим вариантом, потому что оно проверяет синтаксис. При использовании ADSIEdit, напротив, вы вписываете имена SPN непосредственно в атрибут servicePrincipalName. Для создания двух имен SPN выполните команду setspn-A MSSQLSvc/<NetBIOS_Name>:1433 <domain>\<username> and setspn-A MSSQLSvc/<FQDNe>:1433 <domain>\<username>, где именем пользователя является учетная запись службы SQL.

Для подтверждения факта того, что трафик сервера SQL Server использует Kerberos, вы можете отследить трафик с помощью анализатора пакетов, например, Wireshark, воспользоваться средством Kerbtray.exe или проверить журналы событий. Если вы подключаетесь к экземпляру SQL с помощью SQL Server Management Studio, в журнале событий безопасности должна появиться запись Event ID 540, в которой будет отмечено, что в процессе входа и проверке подлинности использовался протокол Kerberos. Дополнительные сведения по этой процедуре приведены в статье Настройка проверки подлинности с помощью протокола Kerberos для SQL.
 

Настройка сервера переднего плана и сервера приложений

Обеспечив то, что протокол Kerberos работает на сервере SQL Server, вы можете переходить к настройке среды SharePoint, установив имена SPN для пулов приложений, активировав протокол Kerberos для поставщиков поддержки безопасности (SSP) и веб-приложений, и приступить к выполнению заключительных шагов. Настройка SPN аналогична тому, что вы делали в учетной записи службы сервера SQL Server, но для настройки представлено гораздо больше имен SPN. Вспомните имена SPN, созданные на основании того, что может ввести пользователь в адресную строку браузера клиента, поэтому мы должны задать имена SPN для каждой записи, которую пользователь может ввести в адресную строку для входа на узел. Сюда входят имена FQDN, NetBIOS и псевдонимы в виде заголовков узла. На рис. 4 отображен пример типов ресурсов и имена SPN, которые необходимо зарегистрировать для каждого ресурса.
 

Рис. 4. Имена SPN для базовой фермы MOSS

Необходимо помнить о нескольких вещах при настройке имен SPN. Во-первых, имена SPN регистрируются для веб-узла с поддержкой SharePoint аналогичным образом, что и для веб-узла IIS. Важно указать правильное имя компьютера и учетную запись, под которой работает пул приложений для каждого узла. Если вы используете несколько заголовков узла, убедитесь в том, что имена SPN заданы для них всех. Во-вторых, необязательно указывать порты для HTTP и HTTPS, но вы должны указать любой пользовательский порт. И в-третьих, вам придется настроить несколько дополнительных зависимостей, например, изменение реестра для метабазы IIS для обеспечения формирования имен SPN с пользовательскими портами и обновление для поддержки SSP. Дополнительные сведения об этом можно найти в статье Настройка проверки подлинности на основе протокола Kerberos (Office SharePoint Server).

Имеется еще два основных этапа, которые вы должны выполнить для того, чтобы протокол Kerberos заработал в вашей среде. Вы должны настроить учетные записи компьютера и некоторые учетные записи служб для поддержки делегирования, а также вы должны настроить свою ферму для поддержки протокола Kerberos в центре администрирования. Идея делегирования в протоколе Kerberos заключается в том, что если пользователь отправляет запрос на конечный ресурс, а некоторые промежуточные учетные записи должны обработать данный запрос, то эти промежуточные учетные записи должны иметь доверие для делегирования от имени пользователя. Вы можете настроить учетную запись для выполнения делегирования с помощью оснастки "Пользователи и компьютеры Active Directory" под администратором домена. Выберите пункт Trust this user/computer (Доверять этому пользователю/компьютеру) для делегирования любой службы (Kerberos) во вкладке Delegation (Делегирование) учетной записи пользователя или компьютера. Вы должны активировать функцию делегирования для учетных записей компьютеров серверов переднего плана, серверов приложений и SQL Server, для пулов приложений (SSPAdmin, MySite, различных веб-приложений) и для учетной записи служб фермы.

Кроме того, вы должны установить разрешения в Component Services (Службы компонентов). В стандартных настройках установите параметр Impersonation Level = Delegate. В IIS WAMREG Admin Service, перейдите на вкладку Security и назначьте разрешения Local Activation учетным записям пула приложений. Дополнительные сведения приведены в статьях KB 917409 и 920783 базы знаний.

После активации функции делегирования пришло время заключительного этапа — установке Kerberos в качестве предпочтительного протокола для SSP и веб-приложений. Для новой установки вы можете сделать это на узле центра администрирования SharePoint в мастере настройки продуктов и технологий SharePoint. В противном случае, перейдите на вкладку Authentication Providers в пункт Application Management, находящийся в центре администрирования, щелкните Default и установите метод Negotiate (Kerberos). Не забываем выполнить команду iisreset /noforce для того, чтобы изменения вступили в силу в пуле приложений, и протокол Kerberos был активирован для SSP.
 

Изменения в IIS 7 и Windows Server 2008

До сих пор я ограничивался средой SharePoint 2007 на Windows Server 2003 и IIS 6. Если вы переходите на Windows Server 2008 и IIS 7, то придется выполнить некоторые изменения в настройках. Возможно, наиболее заметное изменение заключается в том, что IIS 7 поддерживает проверки подлинности Kerberos в режиме ядра. Во время проверки подлинности в режиме ядра, учетная запись сетевой службы (на самом деле это вышеупомянутая учетная запись компьютера) дешифрует билеты, если вы только не указали иного. Проверка подлинности в режиме ядра активируется по умолчанию при переходе на IIS 7 или при установке новой фермы. Напомним, что учетная запись сетевой службы является локальной. Если вы запускаете один сервер, начинается дешифрование. На ферме, однако, происходит сбой, потому что вы должны использовать учетные записи домена, которые могут проверяться Центром распределения ключей. Это изменение также означает, что вы можете выполнить переход протокола (клиенты используют проверку подлинности в метабазе не на основе протокола Kerberos и IIS, а IIS использует протокол Kerberos для связи с сервером, используя учетную запись сетевой службы, так как она уже имеет привилегии LocalSystem).

Для настройки протокола Kerberos в вашей ферме SharePoint, на которой работает метабаза IIS 7, вы должны вручную изменить файл %WinDir%\System32\inetsrv\config\ApplicationHost.config (на данный момент графический интерфейс недоступен). Соответствующая запись показана ниже.

<system.webServer>
<security>
<authentication>
<windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true" />
</authentication>
</security>
</system.webServer>

Не забываем выполнить команду iisreset /noforce для того, чтобы изменения вступили в силу, и проверяем наличие последних обновлений решения такой проблемы, как синий экран, подробно описанной в статье 962943 базы знаний.

Также нужно вспомнить еще об одной детали; если в вашей конфигурации используется олицетворение подлинности (<identity impersonate="true" /> в web.config) а также конвейер в интегрированном режиме, вы должны установить значение атрибута validateIntegratedModeConfiguration в "false" или запустить страницы .aspx на конвейере в классическом режиме.
 

Заключение

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

1.  

Обновление до SharePoint 2010 будет непохоже на другие обновления, которые вы выполняли. Но еще перед началом планирования необходимо ознакомиться с системными требованиями для SharePoint 2010. В отличие от предыдущих версий SharePoint 2010 выпускается только в 64-разрядной версии. Там образом, необходимо устанавливать SharePoint 2010 на 64-рязрядной версии Windows Server 2008 или Windows Server 2008 R2.

SharePoint требуется база данных SQL Server, но она не обязательно должна находиться на том же сервере, что и SharePoint. SharePoint 2010 по-прежнему требует SQL Server, но корпорация Майкрософт внесла несколько важных изменений. SharePoint 2010 требует, чтобы базы данных работала с 64-разрядной версией SQL Server 2005 или 2008. Это справедливо вне зависимости от того, установлена ли база данных локально на сервере SharePoint.

Необходимо также задуматься об используемом веб-браузере, хотя это и не техническое требование. SharePoint2010 создан для того, чтобы оптимизировать использование веб-стандартов. Это означает, что пользователи смогут работать без перебоев независимо от используемого браузера: Explorer или Firefox (3.x или боле поздняя версия). Единственная тонкость заключается в том, что SharePoint 2010 обеспечивает ограниченную поддержку Internet Explorer 6. Пользователи IE6 не должны испытывать проблем с просмотром содержимого SharePoint, однако для создания содержимого потребуется IE7 или более поздняя версия (или Firefox 3.x или более поздняя версия).

Обновления поверх существующей системы

Как вы уже, наверное, слышали, SharePoint 2010 позволяет выполнять обновления поверх существующей системы Microsoft Office SharePoint Server (MOSS) 2007. Однако, поскольку SharePoint 2010 является 64-разрядной, можно выполнить обновление поверх существующей системы только в том случае, если MOSS 2007 запущен поверх 64-разрядной версии Windows Server 2008. Если ваши серверы SharePoint соответствуют необходимым системным требованиям, можно выполнить обновление поверх существующей системы на каждом сервере фермы SharePoint.

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

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

Проверка перед обновлением

Независимо от того, что вы выполняете – обновление поверх существующей системы или перенос, необходимо перед этим все спланировать и подготовиться. Одним из наиболее важных шагов в подготовке к обновлению до SharePoint 2010 является запуск программы предварительного анализа. Перед выпуском MOSS 2007 корпорация Майкрософт представила служебную программу Prescan.exe, которая поможет проверить состояние развертывания SharePoint перед обновлением до MOSS 2007.

Программа Prescan.exe в свое время была отличным средством, однако она не очень хорошо подходит для предварительного анализа SharePoint 2010. Вот почему корпорация Майкрософт выпустила программу предварительного анализа Pre-Upgrade Checker. Она намного совершеннее программы Prescan.exe. Начнем с того, что программа предварительного анализа Pre-Upgrade Checker предназначена только для чтения, поэтому не придется волноваться о внесении каких-либо изменений на серверы SharePoint.

Однако наиболее удобна Pre-Upgrade Checker именно тем, что выполняет куда более тщательную работу по поиску проблем, нежели Prescan.exe. Кроме того, она является расширенной. Она выпускается с набором правил, которые использует при анализе серверов SharePoint. Это правила в формате XML, следовательно, можно создавать свои правила, если это потребуется. Кроме того, использование правил на основе XML упрощает работу корпорации Майкрософт по обновлению программы предварительного анализа, если их рекомендации когда-нибудь изменятся.

Считается, что лучшее в этой программе – это информация, которую она собирает, но это утверждение спорно. Несмотря на том, что корпорация Майкрософт создавала ее как средство для подготовки к обновлению до SharePoint 2010, некоторые организации используют ее для других целей. Одна компания использует ее в рамках своего плана по восстановлению после сбоев. Программа предварительного анализа никоим образом не поможет спасти сервер SharePoint после сбоя, однако собранная ею информация может оказаться бесценной, если вам придется повторно собирать развертывание SharePoint (только обязательно запустите ее перед сбоем).

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

Так где же можно найти эту программу? Есть вероятность, что она у вас уже есть. Корпорация Майкрософт включила ее в MOSS 2007 с пакетом обновления 2 (SP2). Но, возможно, вопреки вашим ожиданиям, программа предварительного анализа не является изолированным средством. Корпорация Майкрософт встроила ее в служебную программу STSADM.EXE. Так уж получилось, что после применения пакета обновления 2 (SP2) мне пришлось перезагружать тестовый сервер несколько раз, пока Windows не позволила мне получить доступ к новым функциям STSADM.EXE.

Учитывая все вышесказанное, я хочу показать, как работает программа предварительного анализа. Как я уже говорил, она работает, анализируя файл правила на основе XML, а затем используя эти правила как основу для анализа развертывания SharePoint. Программа поставляется со встроенным набором правил. Эти правила, основанные на анализаторе соответствия рекомендациям, находятся в файле OssPreUpgradeCheck.xml. На него можно посмотреть на рис. 1.


Рис. 1. Программа предварительного анализа использует файл правил на основе XML.

При запуске этой программы не нужно явно вызывать этот файл правил. Программа вызывает его по умолчанию. Можно использовать свои файлы правил. Полный синтаксис программы предварительного анализа следующий:

STSADM.EXE –O PreUpgradeCheck
[[-RuleFiles “”] [-ListRuleFiles]] [-LocalOnly]

Как можно видеть, существуют два обязательных параметра –O и слова PreUpgradeCheck. Параметр –RuleFiles является необязательным и используется только при необходимости указать файл правил вручную. Также можно использовать параметр –ListRuleFiles для отображения файлов правил, которые доступны. И, наконец, можно использовать параметр –LocalOnly для запуска этих правил только для местного сервера SharePoint.

Взгляните на рис. 2, который поможет представить, как работает программа предварительного анализа. Как видно на рисунке, я начинаю с того, что открываю окно командной строки и перехожу по адресу C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN. Оттуда я запускаю следующую команду:

STSADMIN.EXE –O PreUpgradeCheck]

Рис. 2 Проверка программой предварительного анализа развертывания SharePoint.

Как можно видеть на рис. 2, программа предварительного анализа выполняет ряд различных тестов в развертывании SharePoint. Результаты каждой проверки имеют свой цвет. Красный указывает на сбой, зеленый – на то, что сервер прошел проверку. Информационные пункты обозначены желтым.

Выводные данные программы предварительного анализа, конечно же, не являются очень подробными. Снимок экрана на рис. 2 сообщает только о том, пройдена ли проверка; подробных сведений не выводится. Тем не менее, если взглянуть на нижнюю часть снимка экрана, можно заметить сообщение, в котором сказано, что можно просмотреть результаты в файле HTML, расположенном по адресу C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Logs.

Программа предварительного анализа создает три отдельных файла журнала при каждом запуске. Один из них – это файл HTML, адрес которого указан в конце проверки, два других – это файлы LOG и XML. Можно использовать любой из них, но файл HTML удобнее читать.

Как уже было сказано, программа предварительного анализа собирает множество информации. Следовательно, нет ничего странного в том, что окончательные файлы журнала слишком длинные для того, чтобы приводить их полностью. Можно, однако, получит общее представление о том, как выглядят файлы журнала в формате HTML, взглянув на рис. 3.


Рис. 3 Результаты работы программы предварительного анализа можно просмотреть с помощью веб-браузера.

Определение пользовательских настроек

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

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

Есть способ определить настройки – методика под названием поиск различий. Идея заключает в том, что можно установить резервный сервер MOSS 2007 (убедитесь в том, что на нем запущены те же исправления, что и на рабочих серверах) и воспользоваться программой для поиска различий, чтобы увидеть, какие файлы на рабочих серверах отличаются от файлов на неизмененном сервере SharePoint.

Корпорация Майкрософт рекомендует использовать, однако существуют и другие программы, многие из них имеют более обширные функции, нежели WinDiff.

Проверка процесса обновления

При подготовке к переходу на SharePoint 2010 неизбежно настанет момент, когда вы разработаете план выполнения обновления. Предположим, что вы решили все проблемы, найденные программой предварительного анализа. Значит, процесс обновления должен проходить относительно гладко. Тем не менее, его нужно тщательно контролировать.

Разверните MOSS 2007 в изолированной лабораторной среде и попробуйте реализовать план обновления в ней, прежде чем выполнять обновление на рабочих серверах. Лабораторная среда поможет ознакомиться с процессом обновления, а также определить проблемы, которые могут возникнуть в ходе настоящего обновления.

Лучший подход для предприятий малого и среднего бизнеса – установить несколько виртуальных серверов, а затем восстановить резервные копии рабочих серверов на серверах лабораторной среды. Это позволит вам проверить план обновления в среде, которая практически идентична производственной.

В более крупных организациях создавать точную копию производственного развертывания SharePoint, возможно, будет непрактично. В подобных ситуациях можно установить небольшую среду, настроенную так же, как и производственная среда. Можно также попробовать восстановить в лабораторной среде резервные копии — но не все — серверов SharePoint. В то время как этот подход может казаться очень перспективным, не забывайте о том, что вы, скорее всего, не будете переносить все развертывание в SharePoint 2010 за раз; вам потребуется сконцентрировать развертывание постепенно.

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

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

Еще в Microsoft Office SharePoint Server 2007 (MOSS) компания Microsoft пыталась решить эту задачу с помощью рабочих процессов SharePoint, которые по существу являются механизмами маршрутизации для проставления «виз». Допустим, кто-то из отдела маркетинга придумал новое рекламное объявление. Оно не сразу попадет в рекламное агентство для немедленного распространения. Существует целая процедура последовательных согласований внутри компании.

Объявлению придется пройти через редактора, юридический отдел компании и, возможно, через высшее руководство — только после этого оно может быть отправлено внешним организациям. Проблема такой процедуры в том, что люди не сидят сложа руки. Такие задачи обычно страдают от недостатка внимания. Любая человеческая ошибка может сорвать процесс согласования.

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

Рабочие процессы играют важную роль в MOSS 2007, но какими бы они не были замечательными, они не обладают достаточной гибкостью. По большей части при создании рабочих процессов администраторы вынуждены работать в рамках графического интерфейса SharePoint.

Компания Microsoft сделала процедуру создания рабочих процессов в SharePoint 2010 более гибкой. Хотя все еще сохраняется возможность использовать графический интерфейс SharePoint для связывания рабочего процесса со списком или библиотекой, тем не менее рабочие процессы должны создаваться вне SharePoint (если только вы не используете один из встроенных рабочих процессов).

Поэтому Microsoft предлагает несколько инструментов для создания рабочих процессов. Говоря в целом, средством для разработки рабочих процессов SharePoint будет SharePoint Designer 2010. Профессиональные разработчики могут создавать дальнейшие настройки с помощью Visual Studio 2010, изменяя код, созданный SharePoint Designer 2010, или же создавать настройки с нуля.
Вперед под флагом Visio!
Создание рабочего процесса

Чтобы создать рабочий процесс, откройте Visio 2010 и выберите вкладку File. Программа предложит выбрать тип создаваемой диаграммы — Выберите папку Flowchart, затем выберите шаблон рабочего процесса Microsoft SharePoint и нажмите кнопку «Create», как показано на рис. 1.

На первый взгляд идея использования Visio Premium 2010 для создания рабочих процессов SharePoint кажется как минимум странной. Visio широко используется для конструирования сетевых диаграмм, но большинство пользователей не рассматривает его в качестве инструмента разработки. Тем не менее, одной из главных функций Visio является создание блок-схем, так что такое использование вполне логично. Любой, кто изучал основы программирования, знает, что первые же занятия отводятся созданию блок-схем. Это связано с тем, что разработка блок-схемы часто является первым шагом в написании программы. Рабочие процессы SharePoint по сути своей не более, чем простые программы, но облегчит ли использование приложения, предназначенного для разработки блок-схем, создание рабочих процессов SharePoint?

Есть две важные вещи, которые нужно знать, прежде чем пытаться использовать Visio 2010 для создания рабочих процессов SharePoint. Во-первых, Visio 2010 не позволяет создавать рабочие процессы в их окончательной форме, а используется для создания повторно используемого шаблона, который должен далее импортироваться в SharePoint Designer, где завершается создание рабочего процесса. Во-вторых, все это работает только в редакции Visio 2010 Premium. Редакции Standard и Professional программы Visio 2010 не содержат функций для работы с SharePoint.
Авторизация рабочего процесса

Чтобы создать рабочий процесс, откройте Visio 2010 и выберите вкладку File. Программа предложит выбрать тип создаваемой диаграммы — Выберите папку Flowchart, затем выберите шаблон рабочего процесса Microsoft SharePoint и нажмите кнопку «Create», как показано на рис. 1.

Рис. 1 Использование Visio 2010 для создания блок-схемы рабочего процесса SharePoint

С этого момента вы попадете в основной экран Visio. Теперь можно приступить к разработке рабочего процесса. Если вы никогда не использовали Visio, придется привыкать. В левой части экрана находится несколько наборов (или “stencils) графических значков (или “master shapes”). В число шаблонов рабочих процессов SharePoint Workflow входят следующие из них: Action, Conditions и Workflow Terminator. Перетащите изображения значков на диаграмму Visio и расположите их таким образом, чтобы образовался рабочий процесс.

Наглядный пример диаграммы Visio показан на рис. 2. Диаграмма содержит шаблон простого рабочего процесса SharePoint, который начинается оконечной фигурой Start (зеленый треугольник). Затем следует условие, проверяющее, содержит ли определенное поле ключевые слова. Сейчас имя поля или список ключевых слов для нас не важны. Мы сможем задать конкретные ключевые слова или имена полей позднее. Сейчас нужно только создать логику рабочего процесса.

Рис. 2 Рис. 2 Созданный в Visio простой рабочий процесс SharePoint.

На рисунке видно, что ветвление по условию зависит от наличия ключевых слов. Visio требует создавать обе ветви каждого условия – «Да» и «Нет», которое есть в рабочем процессе. Данный процесс заканчивается объектом Terminate, если ключевые слова не обнаружены (ветвь «Нет»). Если ключевые слова есть, элемент удаляется, а рабочий процесс завершается.

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

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

Чтобы выполнить проверку рабочего процесса, перейдите на вкладку Process и щелкните кнопку Check Diagram. Надеюсь, Visio не найдет каких-либо проблем в вашей диаграмме. Если проблемы есть, они будут открыты в специальном окне, расположенном в нижней части рабочего пространства Visio. Большинство неполадок, как правило, довольно легко разрешаются: просто дважды щелкните список с сообщениями о неполадках и Visio выделит проблемный объект.

Последний шаг в этом процессе – экспорт диаграммы Visio. Перейдите на вкладку Process и щелкните расположенную на ленте кнопку Export. Теперь должно открыться диалоговое окно, в котором можно указать имя файла экспортируемой диаграммы. Введите имя и задайте путь для сохранения экспортируемого файла. Убедитесь, что вы экспортируете файл в формате Visio Workflow Interchange (*.VWI) и щелкните кнопку Save.

Знакомство с SharePoint Designer

Теперь, имея шаблон рабочего процесса, мы готовы ко второй части создания рабочего процесса. Импортируйте шаблон в SharePoint Designer и преобразуйте его в рабочий процесс SharePoint.

SharePoint Designer 2010 – средство пользовательской настройки сайтов, источников данных, рабочих процессов и т.д. Можно вносить изменения в интерфейсе пользователя SharePoint gui, однако, поскольку интерфейс пользователя SharePoint некоторым образом ограничен, SharePoint Designer переносит настройку сайтов SharePoint на новый уровень.

SharePoint Designer распространяется бесплатно. Вы можете загрузить его по следующим адресам:
Для 32-разрядных систем:
Для 64-разрядных систем:

Использование SharePoint Designer
После того, как вы загрузили и установили SharePoint Designer 2010, откройте его и подключите его к сайту SharePoint, который нужно изменить. Для этого запустите SharePoint Designer 2010, а затем щелкните кнопку Open Site.

Программа предложит указать имя открываемого сайта. Введите URL сайта SharePoint и щелкните кнопку Open. Или на сайте выберите Site Actions и внесите исправления из SharePoint Designer. После этого откроется главное окно SharePoint Designer (рис. 3).

Рис. 3 Главное окно SharePoint Designer.

Обратите внимание, что список Site Objects в левой части экрана, содержит объект Workflows (т.е «рабочие процессы»). Если щелкнуть этот объект, вы увидите список встроенных рабочих процессов.

Нам нужно импортировать шаблон рабочего процесса, созданный в Visio 2010. Для этого щелкните кнопку Import на ленте Workflows. Программа предложит выбрать импортируемую диаграмму Visio. Щелкните кнопку Browse, а затем выберите созданную ранее диаграмму и щелкните кнопку Open, а затем – кнопку Next.

Должно открыться окно с запросом имени импортируемого рабочего процесса. Там же вы сможете выбрать импорт процесса в виде списка рабочих процессов или повторно используемого рабочего процесса (рис. 4). Разница в том, что список рабочих процессов связан с конкретным списком или библиотекой, а повторно используемый рабочий процесс связан с типом содержимого и может быть применен к любому списку или библиотеке.

Рис. 4 Выбор варианта импорта рабочего процесса: в виде списка или повторно используемого рабочего процесса.


Щелкните кнопку Finish, чтобы начать процесс импорта рабочего процесса. По завершении процесса импорта откроется окно редактора рабочих процессов Workflow Editor (рис. 5).

Рис. 5 Редактор позволяет вносить изменения в рабочий процесс.


Заключительные операции подготовительного этапа
Прежде чем использовать только что созданный рабочий процесс, придется выполнить небольшую настройку SharePoint Server. В частности, необходимо убедиться, что включены функции Visio Web Access и Visio Graphics Service.

Для этого откройте сайт SharePoint и выберите команду Site Settings в меню Site Actions. После загрузки страницы Site Settings, щелкните ссылку Manage Site Collection Features. Убедитесь в том, что включена функция SharePoint Server Enterprise Site Collection. Если это не так, щелкните соответствующую кнопку Activate.

Рис. 6 Выберите свой рабочий процесс из списка шаблонов рабочих процессов.

Затем откройте основную консоль администрирования SharePoint 2010 (SharePoint 2010 Central Administration) и щелкните ссылку Manage Services on Server в разделе System Settings. Убедитесь, что служба Visio Graphics Service активна. Если это не так, щелкните соответствующую кнопку Start.

Последний шаг процедуры – связывание созданного рабочего процесса со списком или библиотекой (мы исходим из того, что вы создали повторно используемый рабочий процесс). Для этого просто откройте веб-браузер, перейдите к своей библиотеке документов SharePoint и щелкните вкладку Library. Появится соответствующая библиотеке документов лента. Щелкните кнопку Workflow Settings, а затем – ссылку Add a Workflow. Теперь есть возможность добавить рабочий процесс в библиотеку документов (рис. 6).

Новый рабочий процесс сохранен и готов к использованию самостоятельно или совместно с вашими коллегами.