IIS 5.0 и IIS 4.0: скрытые различия

Секреты безопасного перехода на новую версию сервера Internet

Новая версия сервера существенно отличается от предыдущей. Многие отличия уже достаточно хорошо известны: новые методы аутентификации, более высокая производительность, возможность запускать приложения в режиме объединенных изолированных процессов (pooled-out-of-process). Другие особенности известны не так широко, но тем не менее и они важны.

[Прим. редакции: Out-of-process сервер - это компонент, который реализован в виде отдельной программы, содержащей объекты. Этот тип сервера всегда работает в собственном пространстве процессов и поэтому практически не зависит от каких-либо программ клиента.]

Установка

При установке IIS 4.0 пользователь должен указать, где разместить корневые каталоги Web- и FTP-сервера. Из соображений безопасности и оптимизации администраторы систем предпочитают не располагать корень Web-сервера на томе С.

Однако в процессе обычной установки Windows 2000 корневой Web-каталог IIS 5.0 размещается на С: без каких-либо указаний со стороны администратора. Единственный способ установить информационный сервер IIS 5.0 в другое место - это выполнить автоматическую (unattended) установку. Чтобы запустить такую установку, можно воспользоваться утилитой Sysocmgr, поставляемой вместе с Windows 2000, и указать место для корневого каталога Web, FTP и inetsrv (последний по умолчанию находится в каталоге c:winnt). Если после установки IIS 5.0 обнаружится, что все относящиеся к информационному серверу продукты располагаются на диске С, следует немедленно переустановить IIS 5.0 в автоматическом режиме с указанием правильного размещения корневых каталогов. Информацию об особенностях автоматической установки можно найти в одном из следующих источников:

• в статье Microsoft «How to Change the Default Installation Paths for FTP and the Web» (http://support.microsoft.com/ support/kb/articles/q259/6/71.asp);
• в материалах Windows 2000 Resource Kit Deployment Planning Guide;
• в документе «Microsoft Windows 2000 Guide to Unattended Setup» (unattend.doc), в файле support oolsdeploy.cab на компакт-диске Windows 2000.

Изменения в структуре файлов и каталогов

Каталог IISHelp. Справочный каталог IIS 5.0 - IISHelp - находится в каталоге \%systemroot%winnthelpiishelp. Help-файлы предыдущей версии, IIS 4.0, расположились там же, только каталог назывался раньше iis, а не iishelp. Справочные файлы зачастую «завязаны» со всевозможными административными инструментами, мастерами (wizard) и программами, доступ к которым должен быть ограничен. По этой причине в IIS 4.0 изначально заложена некоторая угроза безопасности, поскольку общедоступным объявляется весь справочный каталог целиком, включая файлы NT Help, что отображается в виде некоторого виртуального каталога на сайте Default Web. В IIS 5.0 виртуальный каталог Help отображается на сайте Default Web в каталог iishelp, а не в родительский каталог help.

Каталог Adminscripts. Примеры административных сценариев IIS 5.0 содержатся в файлах .vbs. Они демонстрируют возможности Microsoft Active Directory Service Interfaces (ADSI), связанные с обслуживанием Web-сервера. Найти каталог сценариев Adminscripts можно в inetpub. Для IIS 4.0 аналогичные данные были размещены в каталоге Adminsam-ples по адресу: \%systemroot%system32inetsrv.

Default-документы. В процессе установки IIS 4.0 создавались сайты Default Web и Administrative Web. На сайте Default располагался документ, который отображался всякий раз при обращении к «новоиспеченному» серверу. IIS 5.0 не создает подобный документ, вместо этого формируется активная серверная страница IIS-Start.asp. Когда происходит обращение к IISStart.asp, система проверяет, локальное это обращение или удаленное. Если локальное, то IISStart.asp запускает localstart.asp. Если запрос удаленный, то выдается сообщение Under Construction. Приложение IIS-Start.asp выполняется только в том случае, когда нет ни файла de-fault.asp, ни файла default.htm. Если создать такой default-документ, то он будет использоваться вместо IIS-Start.asp в процессе запуска IIS 5.0.

Каталог IISADMPWD. Сайт Default Web IIS 4.0 содержал виртуальный каталог IISADMPWD, где хранились файлы, с помощью которых пользователи могли менять пароли своих учетных записей через Web-браузер. Если выполняется «чистая» установка IIS 5.0 (т. е. не обновление IIS 4.0, а установка «с нуля»), то выясняется, что сайт Default Web больше не содержит виртуальный каталог IISADMPWD. Однако, несмотря на это, все необходимые файлы для изменения паролей через Web-браузер на сервере присутствуют. Чтобы предоставить пользователям доступ к этим файлам, нужно следовать рекомендациям, изложенным в статье Microsoft «IISADMPWD Virtual Directory Is Not Created During Clean Install of IIS 5.0» (http://support.microsoft.com/ support/kb/articles/q269/0/82.asp). Предоставление пользователям права менять пароль через обычный Web-браузер сопряжено с определенным риском. Об этом подробнее рассказано в других статьях Microsoft - «Malformed HTR Request Returns Source Code for ASP Scripting Files» (http://support.microsoft.com/ support/kb/articles/q260/0/69.asp) и «GET on HTR File Can Cause a `Denial of Service` or Enable Directory Browsing» (http://support.microsoft.com/ support/kb/articles/q267/5/59.asp). Кроме того, в первом номере нашего журнала за 2001 г. этому посвящена статья Кена Спенсера «Изменение паролей через Internet».

Отличия в работе

Неудаляемый анонимный пользователь. Во время установки IIS 5.0 и IIS 4.0 создается учетная запись IUSR_servername. С ее помощью регистрируются анонимные соединения с Web-сервером. Из соображений безопасности администраторы IIS 4.0 зачастую удаляют или переименовывают учетную запись IUSR_servername. При попытке удалить или переименовать аналогичную запись IUSR в IIS 5.0 программа воссоздаст ее при перезагрузке сервера. Единственный «обходной маневр» - создать и использовать аналог учетной записи IUSR без префикса IUSR в ее названии. Более подробно об этом рассказано в статье Microsoft «Correction and Addendum to Internet Information Services 5.0 Release Notes» (http://support.microsoft.com/ support/kb/articles/q254/2/60.asp).

Меньшая зависимость от реестра. Одно из наиболее серьезных скрытых отличий IIS 5.0 состоит в практически полной зависимости настроек сервера от метабазы данных, а не от реестра системы. Метабаза IIS 5.0 содержит множество параметров, которые в версии IIS 4.0 хранились в разделах реестра. Этот факт не так очевиден, поскольку раздел HKEY_LOCAL_MAC-HINESystem CurrentControlSetServicesInetinfo по-прежнему присутствует в реестре и отражает определенную информацию для новой версии IIS точно так же, как это было в предыдущей версии. На самом деле такой раздел нужен только для обеспечения обратной совместимости с IIS Microsoft Management Console (MMC).

WWW Distributed Authoring and Versioning (WebDAV). WebDAV - это разработанный с целью расширения возможностей протокола HTTP функциями файлового ввода/вывода. RFC 2518 описывает стандарт WebDAV, который позволяет открывать, сохранять, переименовывать, осуществлять поиск, создавать, изменять и удалять файлы на сервере IIS 5.0 непосредственно из приложений Microsoft Office, рабочего стола Windows 2000 и браузера Microsoft Internet Explorer (IE) 5.0.

WebDAV автоматически активизируется в версии IIS 5.0, и отключить его невозможно. Сервер IIS 5.0 выполняет постоянный мониторинг всего HTTP-трафика на предмет присутствия Web-DAV-команд, в том числе связанных с собственным изобретением Microsoft - Translate header. Когда сервер распознает команду WebDAV, Web-сервер обращается к расширению Internet Server API (ISAPI) - библиотеке httpext.dll - для обработки WebDAV-запроса. Web-DAV не зависит от расширений файлового API, поэтому нельзя найти httpext.dll в ссылках приложений, запущенных на IIS 5.0. Хотя httpext.dll - это расширение ISAPI, избавиться от него не удастся.

Контроль операций файлового ввода/вывода на Web-сервер - основа системы безопасности Web, а стандарт WebDAV разрешает пользователям выполнять файловые операции; таким образом, применение Web-DAV создает потенциальную угрозу безопасности. Для предотвращения доступа к файлу с использованием стандарта WebDAV обычная фильтрация на уровне порта не помогает, поскольку обращение к файлу осуществляется через HTTP-порт (порт 80).

Для того чтобы записать файлы на сервер через WebDAV, необходимо разрешение на запись для IIS 5.0 (IIS 5.0 Write). Это разрешение не привязано к определенному пользователю, и его активизация предоставляет всем пользователям право записывать файлы на Web-сервер. Так что, разрешая использовать WebDAV, администратор вынужден полностью полагаться на систему прав NTFS, чтобы проконтролировать доступ к файлам. Но право записи IIS 5.0 тем не менее не дает пользователям возможности модифицировать Active Server Pages (ASP) или другие файлы сценариев.

Экран 1. Предоставление доступа к тексту сценария.

Чтобы редактировать файлы сценариев, следует установить флажок Script source access, единственное свойство WebDAV, которое можно настраивать в IIS 5.0. На Экране 1 показана вкладка Home Directory в окне Default Web Site Properties. Когда устанавливаются флажки Script source access и Write и используется WebDAV-приложение, открывающее ASP или иной связанный с ним файл сценария, IIS 5.0 передает исходный текст ASP, вместо того чтобы выполнять код ASP, и посылает результат HTML. Флажок Script source access можно установить как на уровне всего Web-сайта, так и для отдельных страниц.

С применением WebDAV также связаны такие проблемы, как отказ в обслуживании (Denial of Service (DoS), блокировка файлов и нелегальный доступ к исходным текстам. В ответ на проявившиеся проблемы после внедрения WebDAV-программирования (в частности, команды Translate:f) Microsoft выпустила бюллетень безопасности Security Bulletin MS00-058, «Patch Available for `Specialized Header` Vul-nerability» (http://www.microsoft.com/technet/ security/bulletin/ms00-058.asp). Некоторые вопросы на ту же тему рассматриваются в статьях Microsoft «Internet Information Service May Re-turn Source of Active Server Pages File» (http://support.microsoft.com/ support/kb/articles/q256/8/88.asp) и «The Translate:f Security Hole» (http://www.4guysfromrolla.com/ webtech/0815001.shtml). Дополнительную информацию об остальных настройках системы безопасности можно найти в документации WebDAV, включенной в состав IIS 5.0.

Application mappings. Сервер IIS использует отображение приложений (application mappings) для привязки файлов с различными расширениями к тем или иным исполняемым программам. К примеру, в соответствии с алгоритмом application mappings файлы с расширением ASP перенаправляются для обработки asp.dll. При желании можно добавить новое отображение, чтобы позволить IIS воспользоваться файлами сценариев практически любого типа (Perl, Rexx или PHP).

Чтобы добраться до вкладки App Mappings в IIS 5.0 или IIS 4.0, нужно выбрать вкладку Home Directory в окне Default Web Site Properties, щелкнуть Configuration и затем App Mappings. Того же результата можно добиться путем установки произвольного виртуального каталога в качестве приложения.

Экран 2. Закладка IIS 5.0 App Mappings с разрешенными командами.

Экран 2 иллюстрирует вкладку App Mappings для IIS 5.0, а Экран 3 - для версии IIS 4.0. Стрелки, указывающие на правые колонки на том и другом экране, подчеркивают существенное различие между IIS 5.0 и IIS 4.0. Колонки озаглавлены по-разному: для IIS 5.0 - это Verbs, а для IIS 4.0 - Exclusions. По умолчанию, IIS 5.0 не разрешает использовать новые команды (verbs) в спецификации HTTP. Устанавливая связь приложение-исполняемый модуль, нужно указать команды, разрешенные системой для работы с HTTP. Сервер IIS 4.0, наоборот, по умолчанию разрешает использовать новые команды. Поэтому для IIS 4.0 нужно указать команды, запрещенные системой (исключения).

Экран 3. Закладка IIS 4.0 App Mappings с запрещенными командами.

Если проигнорировать сказанное или не заметить разницу в заголовках колонок App Mappings и указать исключенные команды (к примеру, DE-LETE и PUT), вместо разрешенных (к примеру, GET и POST) сервер возвратит сообщение об ошибке 403.1 Execute Access Forbidden («Исполнение запрещено»), сопроводив его маловразумительным дополнением: «You have attempted to execute a CGI, ISAPI or other executable program from a directory that does not allow programs to be executed.» («Попытка выполнить CGI, ISAPI или другую программу из каталога, который не предназначен для выполнения программ».) Поддавшись на это провокационное сообщение, можно никогда не отыскать причину ошибки. Система аудита здесь не поможет, так же как ничего не удастся добиться ни с помощью программы Filemon (выполняет мониторинг используемых в системе файлов, доступна по адресу: http://www.sysinternals.com), ни с помощью иной техники мониторинга, основанной на анализе разрешений NTFS (разрешения исполнять программы в данном случае). Предоставление группе Everyone права Full Control на исполняемые файлы тоже проблемы не решит.

Организация пула сокетов (Socket pooling). Когда для создания Web-сайта используется IIS 4.0, Web-сервер выделяет TCP-сокеты специально для Web-сайта. Например, если создано 20 Web-сайтов, каждый со своим IP-адресом, IIS 4.0 назначает сокет-соединение для каждого из этих 20 сайтов, и каждый из них «прослушивает» 80-й порт. В этом случае ограничиваются масштабируемость и производительность, поскольку ресурсы, занимаемые незадействованными сокетами, не могут использоваться другими сайтами.

В противоположность этому, IIS 5.0 использует пул сокетов, которые Web-сервер по умолчанию подключает ко всем сайтам, имеющим различные IP-адреса, при условии, что пул работает на один и тот же порт. При таком подходе ресурсы сервера распределяются оптимально.

Если Web-сервер имеет только один IP-адрес, то, вероятнее всего, для создания нескольких Web-сайтов на одном адресе IP используются заголовки хоста (host headers). Пул сокетов не поддерживает сайты такого типа, организация связного пула доступна только для Web-сайтов с различными IP-адресами. В оперативной документации по сайтам второго типа (основанные на анализе заголовка хоста) этот нюанс в работе IIS 5.0 описан недостаточно внятно.

В файле Readme из состава IIS 5.0 (см. статью Microsoft «Contents of Internet Information Server 5.0 Release Notes» по адресу: http://support.microsoft.com/ support/kb/articles/q250/9/79.asp) показаны скрытые различия в организации пула сокетов. Если для повышения производительности системы выполняется тонкая настройка одного из Web-сайтов, работающих на пул, это неизбежно оказывает воздействие и на все остальные Web-сайты в пуле сокетов. Отрегулировать параметры производительности Web-сайта можно на вкладке Performance в окне Default Web Site Properties, как показано на Экране 4.

Экран 4. Настройка производительности Web-узла.

Можно отключить функцию организации связного пула для IIS 5.0 для отдельно взятого сайта или сервера. Для отключения связного пула на сервере нужно набрать команду

cscript c:inetpubadminscripts
 adsutil.vbs 
set w3svc/
 disablesocketpooling true.

Затем следует перезапустить IIS 5.0. Для отключения пула на индивидуальном сайте нужно набрать

cscript c:inetpubadminscripts
 adsutil.vbs 
set w3svc/x/
 disablesocketpooling true

где х - это номер Web-сайта. IIS 5.0 использует нумерацию, а не имена Web-сайтов, для того чтобы идентифицировать различные Web-сайты. IIS 5.0 назначает номера в той последовательности, в которой сайты создавались. С помощью программы MetaEdit 2.1 (ее можно загрузить по адресу: http://support.microsoft.com/ support/kb/articles/q232/0/68.asp) можно выяснить номера Web-сайтов, о которых идет речь. Номер Web-сайта также определяется с помощью следующей команды:

cscript c:inetpubadminscripts
 findweb.vbs
«websitename»

где websitename - это имя данного сайта, которое показывает Internet Service Manager (ISM). Важное замечание: команда чувствительна к регистру.

Протоколирование работы. Если в журналах IIS 5.0 или IIS 4.0 отображается неверное время, проблема может заключаться в том, что вместо локального времени сервера используется время по Гринвичу (Greenwich Mean Time, GMT). В соответствии со стандартом консорциума World Wide Web Consortium (W3C) в работе сервера IIS применяется GMT, поэтому программа, отвечающая за журнал событий, должна выполнять конвертацию GMT в локальное время. Для этого можно воспользоваться утилитой Convlog из состава Microsoft Windows Internet Information Server Resource Kit или же пакетом Windows 2000 Resource Kit.

В обеих версиях IIS время GMT используется для установки времени перехода даты и, в некоторых случаях, для именования журнальных файлов, что может оказать влияние на результаты анализа оценки трафика Web-сайта. К примеру, если сервер IIS расположен в Калифорнии в Тихоокеанской временной зоне, с восьмичасовой разницей по отношению к Гринвичу. Если сервер регистрирует записи с ежедневной дискретностью, можно сделать неверный вывод, что он закроет журнальный файл текущего дня и приступит к сбору данных следующего дня в полночь по Тихоокеанскому времени. Но поскольку IIS использует настройки GMT, журнальный файл сервера будет закрыт в четыре часа дня по Тихоокеанскому времени, и IIS присвоит ему имя, как если бы оно соответствовало трафику, накопленному за весь день. Так и есть на самом деле - дневной трафик содержится в диапазоне с четырех часов дня до следующих четырех часов дня, а не с полуночи до полуночи.

IIS 5.0 обладает новым свойством, разрешающим проблему перехода даты. В окне Properties Web-сайта нужно последовательно выбрать вкладку Web Site, Enable Logging, W3C Extended Logging Format как Active Log Format и щелкнуть Properties. На вкладке General Properties в окне Extended Logging Properties (см. Экран 5) можно установить флажок Use local time for file naming and rollover, чтобы журнальные файлы формировались с учетом перехода даты в локальной временной зоне. Но вот датировка самих записей внутри файлов по-прежнему соответствует Гринвичу. Напоминаю, что сказанное относится к IIS 5.0.

Экран 5. Настройка IIS 5.0 для использования локального времени при создании журналов.

Для версии IIS 4.0 также можно настроить использование локального времени при определении перехода даты и именовании журнальных файлов, хотя технически это несколько сложнее, чем для IIS 5.0. В соответствии с рекомендациями, изложенными в статье Microsoft «Log Files Rolled Over According to GMT, Not Local Time Zone» (http://support.microsoft.com/ support/kb/articles/q193/6/12.asp), нужно набрать следующую команду для установки ключа метабазы в соответствии с локальным временем сервера:

mdutil.exe SET -svc w3svc -i x
 -utype UT_SERVER -dtype DWORD
 -attrib INHERIT -prop 4015 -value 1

В этой команде w3svc - это название раздела метабазы Web-сервера, а х - номер Web-сайта, для которого устанавливается локальное время регистрации журналов. Это решение можно использовать для любого сервера NT 4.0 с установленным Service Pack 5 (SP5) или SP4. В пакете исправлений SP6 описанная проблема с переходом даты решена.

Сквозная аутентификация (pass-through authentication). При создании виртуального каталога, который отображается на сетевой диск (remote share), требуется указать имя и пароль, чтобы система предоставила доступ к сетевому диску. Каждое очередное обращение к виртуальному диску будет происходить в контексте безопасности указанного имени и пароля, если только специально не указать в настройках сервера (справедливо и для IIS 4.0, и для IIS 5.0), что можно учитывать данные зарегистрированного пользователя. Такое использование учетных данных для аутентификации при обращении к сетевому диску называется pass-through authentication («сквозная аутентификация»).

Если требуется подключить сквозную аутентификацию для сервера IIS 5.0, нужно воспользоваться методом, который, с одной стороны, поддерживает сквозную аутентификацию, а с другой - создает в метабазе соответствующую запись. Сквозными называются следующие методы аутентификации: Anonymous (пароль не указывается), Basic и Integrated Windows. При использовании метода Integrated Windows в системе, настроенной на работу по протоколу Kerberos, сквозная аутентификация также поддерживается. Но для работы по протоколу Kerberos должны выполняться определенные требования:

• клиент: Windows 2000 + IE 5.0 или старше;
• сервер: Windows 2000 + IIS 5.0;
• клиент и сервер принадлежат одному домену или находятся в доменах, связанных доверительными отношениями;
• сервер IIS 5.0 сконфигурирован для использования метода Integrated Windows;
• и, наконец, сервер Windows 2000 и ресурс Web, к которому происходит обращение, должны иметь одинаковые имена или же нужно использовать программу Setspn (входит в состав Windows 2000 Resource Kit) для регистрации имени Web в качестве нового имени Service Principal Name.

Для редактирования метабазы можно воспользоваться файлом сценария или программой MetaEdit 2.1. Приведенный ниже ASP-код активизирует сквозную аутентификацию на IIS 5.0 для виртуального каталога Protected на сайте Default. При этом нужно указать номер Web-сайта вместо единицы (1), а также имя виртуального каталога, названного в нашем случае Protected.

<%
Dim oVDr
Set oVD = GetObject(«IIS://» & _
 «localhost/W3SVC/1/Root/» & _
 «Protected»)
oVD.UNCAuthenticationPassThrough = True
oVD.SetIfno
Set oVD = Nothing
%>

Команда IISReset. Остановка и запуск IIS 4.0 - процесс весьма сложный, но перезапускать Web-сервер из-за всевозможных «подвисаний» приходится часто. Многие администраторы IIS 4.0 в штатном режиме перезапускают серверы в ночное время либо используют командные файлы для перезапуска остановленных служб.

Для решения этой проблемы разработчики Microsoft добавили в Windows 2000 команду IISReset.exe. Это утилита командной строки, которая позволяет останавливать и запускать IIS 5.0 и зависимые службы. Чтобы остановить службы Internet, следует вместо значка Services в панели управления воспользоваться командой IISReset. В документации отмечается: «You should use the (IISReset) method, and not the Windows 2000 Services snap-in, for restarting Internet services. Because several Internet services run in one process, Internet services shut down and restart differently from other Windows services.» («Для перезапуска служб Internet следует использовать метод IISReset, а не оснастку Windows 2000 Services. Поскольку некоторые службы Internet функционируют как единый процесс, остановка и перезапуск служб сервера Internet протекают иначе, чем те же операции с другими службами Windows 2000».)

IISReset имеет несколько дополнительных параметров, которые позволяют управлять процессом перезапуска сервера и указывать некоторые особые действия. Например, чтобы заставить сервер перезагрузиться, если IIS 5.0 не отвечает в течение заданного времени, нужно набрать:

IISreset /restart /rebootonerror /
          timeout:seconds

где seconds - время в секундах.

Экран 6. Настройка Windows 2000 для запуска IISReset.

Если IIS 5.0 не отвечает, можно запустить IISReset через Windows 2000 Service Control Manager (SCM). Для активизации этой возможности следует открыть контекстное меню IIS Admin Service приложения IIS 5.0 Services, выбрать Properties и щелкнуть на вкладке Recovery (см. Экран 6). На экране приведены установки по умолчанию, но при необходимости можно описать процедуру восстановления и задать необходимые временные параметры. На Экране 6 указано, что при любом сбое (первом, втором и всех последующих) будет вызываться программа IISReset. В поле Run file описывается файл, запускаемый после каждого сбоя (в данном случае указан C:WINNTSystem32iisreset.exe). Администратор может задать различные действия после первого, второго и всех последующих сбоев, а также вызвать специально разработанную программу, которая перезапустит остальные процессы, запишет нужные сообщения в журналы событий или оповестит обслуживающий персонал. Для вывода всех параметров, перечисленных в документации на IIS 5.0 для команды IISReset, достаточно просто набрать в командной строке:

iisreset

SSL-соединения и Client Access Licenses

В дискуссионной статье, затрагивающей вопросы реализации сервера IIS 5.0 («Deploying Windows 2000 with IIS 5.0 for Dot Coms: Best Practices», http://www.microsoft.com/ technet/iis/iisdtcom.asp), отмечается, что .COM-бизнес должен иметь достаточное количество клиентских лицензий (Client Access Licenses, CAL) для использования всех доступных соединений Secure Sockets Layer (SSL).

При работе с Windows 2000 необходимо, чтобы каждый зарегистрированный пользователь обладал своей лицензией (CAL), а система, в свою очередь, ограничивает число одновременно подключенных пользователей количеством лицензий, приобретенных при покупке системы. Служба Windows 2000 License Logging Service отслеживает соблюдение этих правил. Если попытаться отключить эту службу, то Windows 2000 установит максимальное число одновременных соединений равным 10.

Неизвестный для большинства администраторов систем второй счетчик - счетчик SSL-соединений - существует отдельно от счетчика пользователей, прошедших аутентификацию. Windows 2000 + SP1 ограничивает число SSL-соединений, включая анонимные, количеством клиентских лицензий - CAL. Другими словами, имея 10 CAL, можно установить 10 зарегистрированных и 10 анонимных соединений одновременно. Т. е. лимит SSL-соединений существует, и если он превышен, то выводится сообщение:

HTTP 403.15 - Forbidden: Client
 Access 
Licenses exceeded
Internet Information Services
The number of authenticated users has
 exceeded the number of Client Access
 Licenses (CAL).
HTTP 403.15 - Запрещено: превышен
 лимит 
Client Access Licenses 
Internet Information Services
Число пользователей, прошедших
 аутентификацию, превышает лимит
 Client Access Licenses (CAL).

Поскольку не имеет смысла ограничивать число анонимных SSL-соединений количеством закупленных клиентских лицензий, Microsoft Product Support Services (PSS) выпустила специальную заплатку. Дополнительную информацию о поведении IIS 5.0 при превышении лимита CAL можно найти в статье Microsoft «Error Message: HTTP 403.15 - Forbidden: Client Access Licenses Exceeded» (http://support.microsoft.com/ support/kb/articles/q264/9/08.asp). Можно модифицировать реестр, чтобы помешать IIS 5.0 и службе License Logging Service препятствовать созданию SSL-сессий. В раздел реестра HKEY_LOCAL_MACHINESYSTEM CurrentControlSetServicesW3SVCParameters нужно добавить параметр EnableCAL (тип REG_DWORD) и установить его значение равным 0. В статье Microsoft «What`s New in the Windows 2000 Server Licensing Model» (http://www.microsoft.com/windows2000/ guide/server/pricing/changes.asp) объясняется, что нарушения лицензионного соглашения с Microsoft не происходит, если число имеющихся лицензий CAL меньше числа анонимных SSL-соединений.

SSL и групповые символы (wildcards)

В IIS 4.0 если несколько сайтов размещаются на одном хосте или используется множество серверов одного домена (например, mysite.com), то в сертификате можно использовать групповой символ (например, *.mysite.com) для описания Common Name (CN) и присвоить этот сертификат всем сайтам или серверам. Работать с групповыми символами можно в том случае, если лицензия допускает многократное использование. К сожалению, IIS 5.0 уже не поддерживает групповые символы для описания CN. Если же Common Name сервера IIS 5.0 не соответствует DNS-имени, браузер пользователя выведет сообщение о том, что сертификат не соответствует запрашиваемому сайту. Пользователь должен будет подтвердить, что с сайтом установлены доверительные отношения.

Через некоторое время планируется выпустить заплатку для исправления этой ошибки (Windows 2000 SP1 проблему не решил). Подробнее о групповых символах CN рассказано в статье Microsoft «Accepted Wildcards Used by Server Certificates for Server Authentication» (http://support.microsoft.com/ support/kb/articles/q258/8/58.asp).

Переход к IIS 5.0

Существует еще ряд отличий между версиями IIS 4.0 и IIS 5.0, включая изменения в ASP, использование ODBC, COM+, MetaEdit, появление новых мастеров и шаблонов безопасности, изменения в настройках реестра. Большая часть изменений в IIS 5.0 существенно облегчает работу и демонстрирует способность Micro-soft извлекать уроки из неудач в реализации IIS 4.0. Я полагаю, что на версию IIS 5.0 следует перейти, как только представится такая возможность.

Но когда это произойдет, важно помнить, что существенные и не всегда явные отличия IIS 5.0 от предыдущей версии Web-сервера могут сказаться на системе безопасности, тонкой настройке и программировании сервера.

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