В.: Я установил на новый сервер Windows 2000 Service Pack 2 (SP2) со 128-разрядным шифрованием и теперь пытаюсь наладить режим изменения паролей с помощью Microsoft Internet Information Services (IIS) 5.0. Сервер Windows 2000 является членом домена Windows NT 4.0. На установленный сервер, помимо всего прочего, было скопировано содержимое другого сервера Internet Information Server (IIS) 4.0. Для копирования содержимого использовалась утилита Robocopy, для репликации учетных записей пользователей применяется Addusers. Я добавил виртуальный каталог Iisadmpwd в качестве Default Web Site, разрешил базовую и интегрированную аутентификацию соединения SSL со 128-разрядным шифрованием. При обращении к сайту происходит запрос имени и пароля пользователя, и все вроде бы работает. Но при этом для учетной записи устанавливается флажок «Изменить пароль при следующей регистрации», так что сервер выводит пользователю соответствующее диалоговое окно. Однако при изменении пароля окно появляется снова и снова. Почему пароль не меняется?

О.: Миграция с IIS 4.0 на IIS 5.0 представляет собой непростую задачу, но вы воспользовались методом, который я всегда рекомендовал. Данный способ миграции и 128-разрядное шифрование не должны создавать проблем. Все же, прежде чем ответить на заданный вопрос, хочу заметить, что я не советую разрешать пользователям менять пароли учетных записей Windows 2000 и Windows NT 4.0 через Internet (кроме тех случаев, когда вы работаете через виртуальную частную сеть - VPN). Есть целый ряд оснований для того, чтобы избегать использования Internet с целью изменения паролей. Во-первых, оставлять такую лазейку слишком рискованно с точки зрения безопасности. Во-вторых, единственная возможность использовать браузер для эффективной аутентификации через Internet - это установить режим аутентификации Basic, что требует применения SSL для обеспечения безопасности. В этом режиме сервер подтверждает свои полномочия для аутентификации каждого файлового запроса. Если вы проводили «чистую» установку IIS 5.0, то могли заметить отсутствие виртуального каталога Iisadmpwd, предназначенного для изменения пользовательских паролей.

Тем не менее необходимые файлы при установке IIS 5.0 копируются автоматически, так что вы можете вручную создать виртуальный каталог Iisadmpwd и отобразить его на \%systemroot%winntsystem32iisadmpwd. В этом виртуальном каталоге вы обнаружите печально известные файлы .htr, позволяющие менять пароли пользовательских учетных записей через Internet. Я употребил выражение «печально известные» применительно к файлам .htr, так как они стали темой слишком многих бюллетеней безопасности, выпускаемых Microsoft. Я думаю, если какая-либо возможность повторно проявляет себя как недостаток в системе безопасности, то с большой вероятностью эта возможность будет вызывать проблемы и в дальнейшем.

Если виртуальный каталог Iisadmpwd не был создан вручную, файлы .htr будут присутствовать на сервере и, возможно, станут мишенью для злоумышленника. Я рекомендую удалить файлы .htr и отключить в IIS 5.0 возможность Application Mapping, которая связывает их с приложением C:winntsystem32inetsrvism.dll.

Помимо создания вручную виртуального каталога Iisadmpwd (или обеспечения доступа к нему любым другим способом) вы должны также внести изменения в метабазу. Установите в метабазе для флажка w3svc//passwordchangeflags ( указывает номер экземпляра сайта) одно из следующих значений:

  • 0 - изменение пароля требует соединения SSL;
  • 1 - изменение пароля не требует соединения SSL;
  • 2 - уведомление об изменении пароля не производится;
  • 4 - подробное уведомление о запрете изменения пароля.

Для установки значения этого параметра можно воспользоваться утилитой MetaEdit или сценариями Microsoft Active Directory Service Interfaces (ADSI).

Если даже не принимать во внимание проблемы безопасности информационной системы, возникающие при разрешении смены пароля через Internet, в IIS 5.0 существует еще одно затруднение, с которым вы, видимо, и столкнулись. Дело в том, что IIS 5.0 обрабатывает смену пароля иначе, чем IIS 4.0, и, если к виртуальному каталогу IISADMPWD анонимный доступ запрещен, при попытке смены пароля пользователь попадает в бесконечный цикл (очевидно, что предоставлять анонимный доступ к файлам, имеющим отношение к смене пароля, не следует). К счастью, для этой ошибки уже есть исправление, которое можно получить через службу поддержки продуктов Microsoft на сайте компании http://support.microsoft.com/ directory/overview.asp.

В.: Как определить пароль для создаваемых при установке Microsoft IIS учетных записей IUSR_computername и IWAM_computername?

О.: Пароли для этих учетных записей хранятся в базе данных учетных записей пользователей (SAM) - для Windows 2000 без поддержки AD и Windows NT 4.0, или же в AD на контроллерах доменов Windows 2000. Отсюда следует, что определение паролей для подобных учетных записей пробивает брешь в системе безопасности. Конечно, используя специализированные (хакерские) инструменты, эти пароли можно узнать, но существует и альтернативный способ определения паролей. Дело в том, что они хранятся в метабазе, откуда их можно извлечь с помощью сценария, приведенного в Листинге 1 (назовем его getpass.vbs). Наберите приведенный сценарий в редакторе Notepad, выполните его, и вы узнаете пароли для учетных записей IUSR_computername и IWAM_computername.

В.: Мой сайт весь построен на SSL. Я хочу определить предъявляемые в связи с этим требования к ресурсам сервера. Интересно также узнать, сколько времени с момента создания поддерживается сеанс SSL. Если пользователь перемещается с защищенной страницы на обычную, а затем возвращается на защищенную, то сеанс возобновляется. Насколько долго сеанс остается действительным, когда он не используется?

О.: Хотя SSL очень эффективен для обеспечения безопасности, его применение с точки зрения ресурсов сервера обходится достаточно дорого. Я советую использовать SSL только в тех случаях, когда это действительно требуется (степень необходимости применения SSL может варьироваться в диапазоне от «совсем не нужно» для обычных сайтов до «необходим постоянно» для электронных бирж и брокерских контор). Если сайт содержит значительный объем информации, важно определить, доступ к каким сведениям должен быть организован через SSL.

Продолжительность времени, в течение которого сеанс остается активным, является важным параметром. Вы хотите, чтобы ресурсы сервера высвобождались так быстро, как только возможно, но, если ресурсы высвобождаются преждевременно, придется слишком часто восстанавливать заново сеансы SSL, что только увеличит нагрузку на сервер. Разработчики Microsoft изменили значение по умолчанию для тайм-аута сеансов SSL с 2 мин в Windows NT 4.0 до 5 мин в Windows 2000. Если вы считаете, что сеансы SSL должны быть более продолжительными, я советую увеличить значение тайм-аута SSL с помощью параметра реестра ServerCacheTime. Если выставить флаг HTTP 1.1 KeepAlives, сервер будет игнорировать тайм-ауты и не станет прерывать сеансы до тех пор, пока браузер явно не завершит сеанс или не закончится сеанс TCP/IP (KeepAlives включен по умолчанию).

По умолчанию этот элемент в реестре не присутствует. Для добавления параметра необходимо в разделе HKEY_LOCAL_MACHINE SYSTEMCurrentControlSet ControlSecurityProvidersSCHANNEL создать элемент ServerCacheTime типа REG_DWORD (не забывайте о необходимости резервирования метабазы перед редактированием). После того как указанный элемент будет создан, установите желаемое значение тайм-аута (в миллисекундах). Для IIS 5.0 значением по умолчанию является 300 000 мс - 5 мин. Более подробно об этом и о других советах по настройке IIS 5.0 можно узнать на сайте компании - http://www.microsoft.com/technet/ iis/iis5tune.asp.

В.: При исполнении на Internet Information Server (IIS) 4.0 приложения, использующего для очистки областей данных при завершении событие Session_onEnd, я обнаружил, что указанное событие иногда при завершении сеанса не возникает. Из различных статей и конференций я узнал, что это известная ошибка, и, хотя я не могу найти сейчас эти статьи, очевидно, что в IIS 4.0 событие Session_onEnd работает не так, как должно. Я провел испытания IIS 5.0 и убедился, что данная ошибка в этой версии исправлена. Расскажите, пожалуйста, о подобной ошибке в IIS 4.0.

О.: Строго говоря, это не ошибка IIS, проблема заключается в организации потоков исполнения COM. Необходимо разобраться в функционировании компонентов COM в различных моделях организации потоков. Это слишком серьезный вопрос, выходящий за рамки данной статьи, но администраторам IIS непременно следует проявлять к нему интерес. Дело в том, что используемые системой объекты COM (включая поставляемые Microsoft) могут оказывать огромное влияние на производительность и масштабируемость системы.

При создании объекта COM для него указывается одна из трех существующих моделей организации потоков исполнения.

  • Apartment threading (раздельные потоки исполнения) - только один поток объекта может осуществлять соединение с сервером. При этом вы можете иметь несколько экземпляров объектов, каждый из которых будет иметь свой поток исполнения. Именно эту модель потоков исполнения использует ядро базы данных Microsoft Access, и именно поэтому предпочтительной базой данных для IIS является Microsoft SQL Server.
  • Free threading (свободные потоки исполнения) - объект может использовать (запускать) произвольное число потоков исполнения.
  • Both threading (двойственные потоки исполнения) - к объекту можно обращаться как Apartment threading, так и Free threading.

Почему событие Session_onEnd не возникает на IIS 4.0, но исправно работает в IIS 5.0? По умолчанию, ADO помечается в системном реестре как Apartment threading, что означает использование только одного потока при обработке обращений к базе данных. В этом режиме поток исполнения, создавший объект ADO, должен впоследствии его уничтожить. Рассмотрим в качестве примера ситуацию, когда пользователь обращается к базе данных, а та оказалась недоступной, скажем, на 15 мин. Устав ждать непонятно чего, пользователь переключается на другую деятельность (отправляется в чат, начинает скачивать файлы .mp3 и т. д.). Пользовательский сеанс завершен, однако поток исполнения, который должен уничтожить объект ADO, недоступен, поскольку он все еще ожидает ответа от базы данных. Событие Session_onEnd возникает, но не может быть отработано, так как единственный поток исполнения, способный уничтожить объект ADO, занят ожиданием. При этом может сложиться впечатление, что событие Session_OnEnd вообще не имело места.

Подобный сценарий может возникнуть при использовании в Session_onEnd внутренних объектов Active Server Pages (ASP). Например, вы не можете использовать объект Response для передачи информации браузеру, когда сеанс завершен. Это кажется очевидным, но подобным образом заблуждается больше программистов, чем вы думаете.

Что же предприняли в Microsoft для изменения ситуации в IIS 5.0? IIS 4.0 доверяет настройкам реестра, где указывается, что ADO использует Apartment threading. IIS 5.0 поступает иначе - для определения модели потоков исполнения он посылает запрос самому компоненту. В действительности ADO поддерживает режим Both threading, так что IIS 5.0 может создавать объекты ADO в одном потоке исполнения, а уничтожать в другом. При этом наблюдателю может показаться, что в IIS 5.0 ошибка Session_onEnd исправлена.

Вы имеете возможность вручную исправить настройку ADO, указав режим Both threading в реестре Windows NT 4.0 (редактируя реестр, никогда не забывайте, что необходимо быть предельно осторожным). Для облегчения настройки Microsoft предлагает соответствующий файл конфигурации, для использования которого необходимо выполнить следующие шаги.

  1. Найдите файл adofre15.reg. Если установка IIS производилась в предлагаемый по умолчанию каталог, этот файл должен располагаться в каталоге C:program filescommon filessystemado.
  2. Сделайте текущим каталог, в котором содержится данный файл. Затем выполните команду regedit adof-re15.reg и перезапустите сервер.
  3. Если вы решите восстановить для ADO режим Apartment threading, выполните приведенные выше шаги для файла adoapt15.reg.

Брет Хилл - автор, инструктор и консультант по Microsoft IIS. Ведет сайт www.IISAnswers.com. Имеет сертификаты MCSE, MCT, MCP+Internet и A+/Network+. С ним можно связаться по адресу: brett@iisanswers.com.