Прежде чем разрешить сквозную аутентификацию для IIS 5.0 или IIS 4.0, необходимо создать резервную копию метабазы.

В. На компьютере А работает Web-сервер. Нужно сделать так, чтобы страницам этого сервера была доступна для записи сетевая файловая система компьютера В. На компьютере А установлена система Win-dows NT 4.0 SP5, а в качестве WWW-сервера используется IIS 4.0. Анонимный вход на WWW-сервер запрещен. Машины А и В находятся в одном и том же домене. Я создал виртуальный каталог на сервере А, указывающий на каталог компьютера В, как и требовалось, ввел имя пользователя и пароль. Все работает прекрасно, за исключением того, что любой, кто имеет доступ к каталогу на компьютерах А или В, обладает теми же правами, что и пользователь, чье имя и пароль были введены мной при создании виртуального каталога. Вопрос: можно ли для контроля доступа использовать стандартные права NT 4.0, установленные для оригинального каталога?

О. Прежде чем ответить на Ваш вопрос, предупреждаю, что мое решение подразумевает разрешение сквозной (pass-through) опосредованной аутентификации для IIS 4.0.

Специалисты Microsoft не рекомендуют придерживаться такого подхода. Сквозная аутентификация позволяет достичь цели, но при этом Microsoft Index Server не сможет индексировать виртуальный каталог. Приятно, что данный тип аутентификации был добавлен в IIS 5.0 и, насколько мне известно, одновременно были реализованы средства ее настройки.

Прежде чем разрешить сквозную аутентификацию для IIS 5.0 или IIS 4.0, необходимо создать архив метабазы и определить номер Web-сайта, который назначен ему в метабазе. Для определения номера можно воспользоваться программой MetaEdit. Эта программа поставляется вместе с набором программ Microsoft Windows 2000 Resource Kit для IIS 5.0 и пакетом Microsoft Internet Information Server Resource Kit для IIS 4.0. Следует пользоваться самой последней версией программы MetaEdit. В настоящий момент это версия 2.1. Для того чтобы в IIS 5.0 в Default Web Site включить аутентификацию pass-through для виртуального каталога Protected, следует в командной строке ввести код, приведенный в Листинге 1. Замените в нем 1 на номер Web-сайта, а Protected — на имя виртуального каталога.

Листинг 1. Пример кода для включения сквозной аутентификации.

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

Не забудьте разрешить на Web-сайте или в виртуальном каталоге метод аутентификации, который поддерживает удаленный доступ к ресурсам. Это означает, что будет использоваться один из следующих методов: Anonymous с выключенным режимом IIS control password, Basic, Integrated Windows (этот режим устанавливают, только если все пользователи работают с IE 5.0 на системах Windows 2000), Certificate Mapping (имеется в виду версия IE 5.0, а не Windows Mapper). Метод аутентификации устанавливается в свойствах Web-сайта или виртуального каталога.

Чтобы разрешить аутентификацию типа pass-through, необходимо выполнить следующие действия.

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

2. Найти утилиту adsutil.vbs, которая обычно размещается в каталоге winntsystem32inetsrvadminsamples directory. Введите в командной строке:

adsutil set w3svc/1/root/vdir/
UNCUserName «»

где 1 — номер WWW-узла, и vdir — имя виртуального каталога.

3. Введите:

adsutil set w3svc/1/root/vdir/
UNCUserName ??

4. Введите:

adsutil set w3svc/1/root/vdir/
UNCPassword ??

5. Введите:

adsutil set 
     w3svc/1/root/vdir/
     UNCAuthenticationPassThrough
 TRUE

6. Введите:

net stop iisadmin /y

7. Введите:

net stop start w3svc

В Microsoft Management Console (MMC) будет появляться сообщение об ошибке. Это результат включения метода сквозной аутентификации для виртуального каталога в IIS 4.0. Тем не менее все будет работать. Любые изменения, сделанные для каталога при помощи MMC, обязательно переопределят настройки, выполненные ранее, т. е. как указано выше. И следует помнить, что Microsoft не только не поставляет средства поддержки для такой конфигурации, но и не рекомендует использовать ее в IIS 4.0.

В. Созданная мной страница на сервере ASP (Active Server Pages) использует объекты CDO (Collabo-ration Data Objects), чтобы отправлять результаты из формы по указанному адресу электронной почты. Все прекрасно работает, если получатель и отправитель не находятся в одном и том же домене. Например, если адрес Web-сервера: http://www.b2bcom-merce.com, а данные из формы должны быть посланы по адресу: orders@notb2bcommerce.com, то объект CDO email отправляет форму. И напротив, объект CDO email не отправляет форму по адресу: orders@b2bcommerce.com. Почему так происходит?

О. Эта проблема решается очень просто. Достаточно настроить SMTP-сервер в Microsoft IIS, как показано ниже.

Следует определить домен SMTP-адреса, на который отсылается форма, как локальный домен для сервера IIS SMTP. Например, имя сервера IIS SMTP может быть myserver.b2bcommerce.com. Обратите внимание, что сервер IIS SMTP и WWW-сервер не обязаны иметь один и тот же доменный адрес. Также важно отмечать, что имя сервера предшествует имени домена.

Теперь следует задать удаленный домен, соответствующий доменному имени SMTP-адреса (b2bcommerce.com). Для этого удаленного домена нужно указать имя или IP-адрес почтового сервера, который принимает почту для домена b2bcommerce.com. В IIS 4.0 такой сервер называется доменом маршрута (route domain), а в IIS 5.0 — Smart Host. Имеется в виду не свойство Smart Host в SMTP, а конкретный компьютер в указанном маршрутном домене. В почтовом сервере Windows 2000 SMTP это настроить несколько проще, так как можно указать DNS для поиска записи MX и отправки сообщений на адрес, указанный в данной записи. В нашем случае SMTP-сервер принимает сообщение, адресованное домену b2bcommerce.com, и пересылает его удаленному серверу.

После установки имен доменов следует указать, какой DNS-сервер должен использоваться компьютером с IIS. Из-за проблем с DNS почтовые сообщения могут не доставляться адресатам. Перед отправкой сообщений служба SMTP помещает их в виде файлов с расширениями .rtr в очередь, которая находится в каталоге Queues. Если доставка невозможна, сообщения остаются в очереди. В случае ошибки DNS те файлы .rtr, которые не были отосланы, содержат строку No path found from URL.

В. Как Вам удалось добавить собственную иконку к URL, которая появляется в адресном поле IE и в списке «Избранные» непосредственно перед URL? Я такие иконки вижу только на некоторых Web-сайтах, поэтому мне кажется, что нужно что-то настроить на самом WWW.

О. Действительно, можно сделать так, чтобы в адресном поле IE 5.x или в списке «Избранные» появлялся логотип Web-сайта. Однако такая иконка будет видна только у тех пользователей, которые включат имя Web-сайта в список «Избранные». Первое, что нужно сделать, - это найти любой редактор иконок и создать иконку с размерами точно 16 * 16 пикселов. Предварительно убедитесь, что редактор позволяет сохранять файлы с расширением .ico. Сохраните созданную иконку с именем favicon.ico в корневом каталоге Web-сайта. Также рекомендуется разместить этот файл во всех каталогах, на которые пользователи устанавливают закладки. Можно назвать файл иконки иначе, и разместить его не в корневом каталоге, а где-то еще. Но в этом случае придется указать новое имя и новое место для IE. В Листинге 2 показано, как это сделать. Указатель на файл иконки должен находиться в каждой страничке, в которой пользователь может установить закладку.

Листинг 2. Ссылка на иконку для Web-страницы.

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

Фрагмент находится по адресу: http://msdn.microsoft.com/workshop/ author/dhtml/howto/shortcuticon.asp.

В. Мой Microsoft IIS-сервер остановился и отказывается запускаться вновь. После безуспешных попыток восстановить нормальную работу я пришел к выводу, что разрушена метабаза. К сожалению, архива метабазы нет. Неужели придется устанавливать IIS-сервер с нуля?

О. Хороший вопрос. Есть одна возможность исправить положение, о которой многие администраторы IIS не знают. Каждый раз, когда обновляется метабаза, IIS создает ее временный архив. Этот архив удаляется после того, как обновление успешно завершено. Если же во время обновления произошла ошибка и база оказалась разрушена, то архив не удаляется. Файл временного архива называется metabase.bak или metabase.bin.bak, он может находиться в папке \%systemroot%system32inetsrv. Если архив оказался на месте, выполните следующие шаги для восстановления IIS.

  1. Остановите IIS и все зависимые от него службы.
  2. Переименуйте текущую метабазу (т. е. metabase.bin) в metabase.badbadbad (или нечто подобное).
  3. Переименуйте архивную метабазу (т. е. metabase.bak) в metabase.bin.
  4. Запустите IIS и все зависимые от нее службы. (Перезагрузите компьютер просто для проверки, что все службы стартуют без ошибок.)

Если после этого IIS не станет работать, придется полностью деинсталлировать IE и Microsoft Windows NT 4.0 Option Pack (IIS 4.0 входит в его состав), затем удалить файл meta-base.bin и установить все заново. Более подробную информацию можно найти в статье Microsoft «How to Manually Restore the Metabase When No Proper Backup Exists or the MMC Won?t Start» по адресу: http://support.microsoft.com/support/kb/ articles/q234/4/29.asp.

В. Можно ли сделать так, чтобы тот, кто нелегально получил доступ к ASP-файлам моего сервера, не мог их прочитать?

О. Как вы, очевидно, знаете, если кто-то получил доступ к файлам сценариев ASP, которые выполняются на сервере, то в его распоряжении оказывается вся информация сразу. Становятся доступны используемые переменные, пути к вызывающим программам, подключения к базе данных и даже встроенные пароли или схемы аутентификации. Если Microsoft IIS работает правильно, то пользователи могут наблюдать только результат выполнения сценария. Однако существуют различные «дыры», которые открывают доступ к исходному коду ASP. Два таких примера описаны в статьях Microsoft «Malformed HTR Request Returns Source Code for ASP Scripting Files» по адресу: http://support.microsoft.com/ support/kb/articles/q260/0/69.asp, и «Virtual Directory Mapped to UNC Returns ServerSide Script Code When URL Contains Additional Characters at the End of the Request» — по адресу: http://support.microsoft.com/ support/kb/articles/q249/5/99.asp.

При установке SP1 для Windows 2000 исправляется ошибка, известная под названием ServerSide Script Code bug, но не исправляется Malformed HTR Request bug. Вдобавок каждый, кому доступны для чтения файлы IIS-сервера, может прочесть исходный код с помощью любого отличного от IE средства. Из-за этой уязвимости сценариев некоторые администраторы предпочитают не использовать их на своих узлах. Они настаивают на применении компилированных кодов в форме isapi.dll или разработанных COM-объектов. Такие коды нелегко создавать, зато они быстрее выполняются и труднее поддаются взлому.

Для повышения надежности ASP-сценариев разработчиками Microsoft был выпущен шифратор сценариев Windows Script Encoder. Шифратор распространяется бесплатно как часть обновленного пакета Windows Script (WS), который доступен по адресу: http://msdn.microsoft.com/scripting. Шифратор так запутывает сценарий ASP, что изучение его при помощи обычных средств просмотра становится бессмысленным.

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

screnc sourcefile outputfile

для шифрования файла сценария, уже никто — ни вы, ни злоумышленники — не сможет получить исходный код файлов .html, .txt или scriptlet (разновидность html-файла) из файла outputfile.

Для шифрования можно использовать метасимвол *. Это позволяет одной командой зашифровать все ASP-файлы и поместить их в целевой каталог. Например, чтобы зашифровать все ASP-файлы в текущем каталоге и поместить выходные файлы в каталог c:aspencoded, введите

screnc *.asp 
   c:aspencoded.

Можно шифровать не весь файл, а только его часть. Для указания начальной точки шифрования используется специальный маркер **Start Encode** (см. Листинг 3).

Листинг 3. Шифрование ASP-сценария.

Шифруется все, что расположено после маркера. В процессе шифрования изменяется строка-ссылка на используемый язык программирования сценария. Для языка VBScript эта ссылка после шифрования выглядит примерно так: