SharePoint изнутри: Управление учетными данными безопасности

Частые изменения учетных данных фермы и паролей учетных данных безопасности являются важными мерами поддержания фермы Microsoft Office SharePoint Server (MOSS) в безопасном состоянии. Однако для администраторов это выливается в регулярное выполнение утомительных задач. Инструменты трудны в использовании, лежащие в основе процедуры сложны, хорошую документацию трудно отыскать, и имеется определенная опасность повреждения фермы серверов даже в случае аккуратного выполнения всех соответствующих процедур.

Ко всему этому добавляется проблематичная техническая помощь от службы поддержки корпорации Майкрософт (PSS - Product Support Services). С одной стороны, существуют полезные статьи базы знаний (KB - Knowledge Base), например «How to Change Service Accounts and Service Account Passwords in SharePoint Server 2007 and in Windows SharePoint Services 3.0» (Изменение учетных записей службы и паролей учетных записей службы в SharePoint Server 2007 и Windows SharePoint Services 3.0). А с другой стороны, существуют такие ужасы, как «Error Message When You Try to Use the SharePoint Products and Technologies Wizard: 'Exception: System.ArgumentException: Error during Encryption or Decryption» (Сообщение об ошибке при попытке использовать мастера настройки продуктов и технологий SharePoint: 'Исключение: System.ArgumentException: ошибка при шифровании или дешифровке).

В указанной статье утверждается, что если учетные данные веб-приложения больше не поддаются расшифровке, необходимо создать новую базу данных конфигурации. Это может произойти, если важный параметр команды используется в неподходящий момент времени или процесс обновления учетных данных фермы по какой-то причине завершается аварийно. Данная статья KB прекрасно справляется с задачей внушения администраторам страха перед тем, что изменение учетных данных фермы может непоправимо повредить ферму серверов. Можно ли рассчитывать на то, что перед лицом такой опасности пользователи будут поддерживать безопасность в средах SharePoint, часто изменяя пароли фермы и учетных записей безопасности?

Пользователи не уничтожают Active Directory с целью сброса учетных записей пользователей, и не следует их вынуждать уничтожать базы данных конфигурации только по той причине, что пароль веб-приложения утрачен. Нет необходимости в создании новой базы данных конфигурации. В большинстве случаев для того, чтобы перезаписать поврежденные учетные данные, достаточно использовать стандартное средство Stsadm.exe. А во всех других случаях можно сбросить пароли и сохранить базу данных конфигурации, воспользовавшись инструментами, включенными в сопровождающий материал, доступный в разделе Февраль 2008. Загрузка кода. Для сброса паролей в средах Windows SharePoint Services (WSS) 3.0 и MOSS 2007 не требуется ни доступа к старым ключам учетных данных, ни новой базы данных конфигурации. Но для выполнения этой задачи требуются улучшенные инструменты поддержки от корпорации Майкрософт и хорошая документация по лежащим в основе процедурам, которые облегчают процедуру изменения паролей.

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

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

Изменения паролей в среде SharePoint

Изменение пароля учетной записи безопасности SharePoint или учетной записи конфигурации фермы является на редкость сложным предприятием. Помимо прочего, вам необходимо применить изменения в Active Directory и в локальной базе данных SAM (Security Account Manager – диспетчер учетных записей безопасности) сервера SharePoint, базе данных SCM (Service Control Manager – диспетчер управления службами), в метабазе IIS, в SQL Server и, безусловно, в базах данных содержимого и конфигурации SharePoint.

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

Увеличить

Рис. 1 Изменение пароля учетной записи безопасности SharePoint

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

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

При перезапуске IIS и другие службы не смогут войти в систему с использованием старого пароля, и затронутый пул приложений или службы больше никогда не смогут подключиться. В этой ситуации IIS записывает предупреждение в серверный журнал событий (см. рис. 2). Поэтому после того, как изменен пароль в Active Directory, не стоит слишком долго тянуть с обновлением пароля в SharePoint.

Увеличить

Рис. 2 IIS предупреждает о том, что учетные данные пула приложений устарели

Для обновления пароля учетной записи пула приложений необходимо использовать центр администрирования SharePoint 3.0 (_admin/FarmCredentialManagement.aspx) или следующую команду Stsadm.exe.

stsadm -o updateaccountpassword -userlogin <DOMAIN\USER>
  -password <PASSWORD> -noadmin

В ответ SharePoint шифрует новый пароль с использованиме ключа учетных данных фермы и заменяет старый зашифрованный пароль в базе данных конфигурации. Затем SharePoint обновляет данные учетной записи в метабазе IIS и всех других требуемых местах. После выполнения этих операций SharePoint генерирует задание таймера типа SPContentAppPoolCredentialDeploymentJobDefinition для развертывания новых учетных данных на оставшихся серверах фермы, которые оно помещает в базу данных конфигурации.

Как видно из рис. 1, для применения административных установок ко всем серверам фермы SharePoint опирается на задания таймера. Службы времение SharePoint на оставшихся серверах фермы выбирают задание и соответствующим образом обновляют локальные настройки безопасности на своих серверах с помощью службы WSS Administration (SPAdmin), чтоб вернуть ферму в согласованное состояние.

Эта процедура служит для применения учетных записей пула, но существует много других типов служб SharePoint, использующих учетные записи безопасности, например сама служба времени SharePoint, служба WSS Help Search и, возможно, поставщики общих служб (SSP — Shared Services Providers), служба поиска Office SharePoint Server и служба единого входа (SSO). В зависимости от решений, установленных на ферме, служб может быть даже больше, и служба каждого типа предъявляет свои требования к обновлению пароля. В статье по адресу support.microsoft.com/kb/934838 приведен список команд, которые необходимо использовать для учетных записей служб в WSS 3.0 и MOSS 2007. За информацией о других инструментах, командах и процедурах обновления обратитесь к документации по используемым дополнительным решениям.

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

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

stsadm -o updatefarmcredentials -userlogin <DOMAIN\USER>
  -password <PASSWORD>

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

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

Рис. 3 Задание развертывания учетных данных застряло в очереди вследствие того, что служба времени SharePoint работает не на всех серверах фермы

В другой ситуации может случиться, что вы обновите пароли учетных записей пула приложений до того, как новые учетные данные фермы попадут на все серверы фермы. Это приведет к тому, что серверы с устаревшим ключом учетных данных прекратят работу, поскольку они не смогут расшифровать обновленный пароль в базе данных конфигурации, как показано на рис. 4. Это интересный случай, и он является основанием для применения параметра -noadmin в команде updateaccountpassword. Если учетная запись фермы используется также в качестве учетной записи пула приложений (чего делать не рекомендуется), тогда сначала следует обновить учетные данные фермы, дождаться, пока все серверы фермы обработают задание таймера, а затем обновить пулы приложений.

Увеличить

Рис. 4 Задержка обновлений в пуле приложений до окончания обработки задания управления развертыванием учетных данных пула приложений

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

Устранение неполадок учетных данных фермы

Присмотримся к команде updatefarmcredentials. У нее есть опасный параметр, который может принести много неприятностей, в особенности, если его использовать так, как описано в статье «Error Message When You Try to Use the SharePoint Products and Technologies Wizard: 'Exception: System.ArgumentException: Error during Encryption or Decryption» (Сообщение об ошибке при попытке использовать мастера настройки продуктов и технологий SharePoint: 'Исключение: System.ArgumentException: ошибка при шифровании или дешифровке). Я имею в виду параметр с именем -local. Разработчики SharePoint ввели этот параметр для выполнения локальных обновлений учетных данных фермы вручную. Идея состоит в том, что задание таймера можно удалить из очереди в центре администрирования (_admin/ServiceJobDefinitions.aspx), если задание повреждено или по какой-то причине не обрабатывается, а затем выполнить необходимый этап обновления напрямую с помощью команды.

stsadm -o updatefarmcredentials -userlogin <DOMAIN\USER>
  -password <PASSWORD> -local

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

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

Взгляните на рис. 5. Команду updatefarmcredentials больше невозможно запустить без параметра -local, поскольку для этого требуется повторное шифрование паролей, которые больше невозможно расшифровать. После аварийного завершения команды в журнале событий Application появляются записи следующего содержания: «Error re-encrypting credential Id 022e607e-b49e-40e4-bd3f-f56a3c69f94d with owner Id 431b6897-16eb-4b9a-be65-60f1f603008d during deploying of administration application pool credentials, please recreate credential manually. Operation is not valid due to the current state of the object.» (Ошибка при повторном шифровании идентификатора учетных данных 022e607e-b49e-40e4-bd3f-f56a3c69f94d с идентификатором владельца 431b6897-16eb-4b9a-be65-60f1f603008d во время развертывания учетных данных пула приложений администрирования. Повторно создайте учетные данные вручную.)

Увеличить

Рис. 5 Невозможно повторно зашифровать пароли пула приложений в связи с тем, что пароли больше невозможно расшифровать

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

В поисках справочной информации вы можете натолкнуться на статью «Error Message When You Try to Use the SharePoint Products and Technologies Wizard: 'Exception: System.ArgumentException: Error during Encryption or Decryption» (Сообщение об ошибке при попытке использовать мастера настройки продуктов и технологий SharePoint: 'Исключение: System.ArgumentException: ошибка при шифровании или дешифровке), уже упоминавшуюся мной ранее, и, в отсутствие дополнительных познаний, ваши неприятности возрастут, поскольку теперь вы узнаете, что необходимо создать новую базу данных конфигурации, чтобы избавиться от тех паролей, которые невозможно больше расшифровать. Это невообразимое стечение несчастливых обстоятельств. Во-первых, вы должны быть лишены возможности запускать команду updatefarmcredentials с параметром -local, либо команда должна создавать резервную копию старого ключа учетных данных, чтобы вы могли впоследствии перешифровать пароли. Либо она должна попросту обнаруживать то, что пароли еще не перешифрованы и в этот момент выполнять их повторное шифрование.

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

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

Интересно, что учетная запись Network Service могла бы быть связана с данными пароля в базе данных конфигурации. Новые пулы приложений, использующие Network Service, не имеют паролей, но если вы все-таки измените пул приложений так, чтобы использовать учетную запись домена, и затем вернетесь к исходной ситуации, Network Service унаследует ссылку на пароль учетной записи. SharePoint не предусматривает установку пароля со значением null (порочная практика написания кода), и в результате «мусорные» данные приводят к осложнениям.

Складывается нелепая ситуация, потому что предполагается, что пользователи должны отказаться от своих баз данных конфигурации, потому что больше невозможно расшифровать «мусорные» и абсолютно бесполезные данные! Если вам повезет, вы можете изменить конфигурацию пула приложений в центре администрирования (_admin/FarmCredentialManagement.aspx) и указать учетчную запись домена. Если вам не повезет, вы столкнетесь с ошибкой шифрования/дешифровки, отображенной на рис. 6. Вы не сможете изменить учетную запись в центре администрирования, вы не сможете воспользоваться командой updateaccountpassword, вы не сможете запустить мастера настройки продуктов и технологий SharePoint и вы не сможете обновить учетные данные фермы с помощью команды updatefarmcredentials. Что же вы теперь будете делать?

Увеличить

Рис. 6 Осложнения, вызываемые остатками пароля Network Service, присутствующими в базе данных конфигурации

Для разрешения этой проблемы необходим инструмент, работающий непосредственно в базе данных конфигурации и удаляющий эти остатки, например средство сброса пароля AppPool, показанное на рис. 7 и включенное вместе с исходным кодом в сопровождающий материал. Этот инструмент крайне прост. Оно извлекает данные пулов приложений, использующих учетные записи с соответствующими зашифрованными паролями, непосредственно из базы данных конфигурации, а затем использует объектную модель SharePoint для выяснения возможности расшифровки пароля пула приложения.

Увеличить

Рис. 7 Установка значения null для поврежденных паролей

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

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

Заключение.

Несмотря на тот факт, что изменение учетных данных фермы и паролей учетных записей безопасности является утомительной и подверженной ошибкам процедурой, не следует бояться того, что такое изменение учетных данных фермы непоправимо повредит ферму серверов. Базу данных конфигурации можно восстановить даже если вы потеряете текущий ключ учетных данных. Вам просто необходимо сбросить затронутые пароли, а это возможно при помощи стандартного инструмента Stsadm.exe или инструмента базы данных низкого уровня, например Reset AppPool Password. Поэтому следует часто менять учетные данные фермы и учетные записи безопасности, использовать надежные пароли, и не следует использовать Network Service в качестве учетной записи безопасности, поскольку это усложняет конфигурацию фермы и устранение неполадок. Следует использовать специальные учетные записи домена.

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

В любом случае административные издержки высоки вследствие возникающих сложностей, и в общем случае уровень безопасности низок вследствие того, что график не предусматривает частых изменений и вследствие ненадежных паролей и сценариев, работающих с паролями в открытом тексте. В моей следующей статье будет показано, как подступиться к этим проблемам и устранить их — для служб всех типов, включая те, которые еще не разработаны, и каковы бы ни были их требования к обновлению паролей. Более никаких изменений паролей вручную!