Iis iusrs что это

Сервис оправдательных документов (ОД) устанавливается на сервере IIS. Применяется для прикрепления к документам сканов и т.п. файлов (так называемых оправдательных документов), а так же для применения режима «Сохраненные отчеты».

Обращается (подключается) к сервису ОД:

•	при прикреплении ОД — клиентское приложение, установленное на компьютере пользователя.

•	при проверке электронной подписи (ЭП) — SQL сервер (через модуль xpks.dll). Таймаут ожидания ответа сервиса ОД составляет 15 секунд, это не настраивается.

В случае SSL соединения соответствие сертификата проверяется, если задана настрйока «Проверять хост сертификата в https соединениях».

Версию сервиса можно определить в браузере, набрав адрес https:///uploadservice.ashx . Откроется стрница сервиса с отображением его версии. Например: https://10.20.30.40/UploadService/uploadservice.ashx , результат: Кейсистемс Сервис оправдательных документов, версия: 3.3.7250 .

С версии комплекса «Бюджет-СМАРТ» 19.2 требуемая версия Сервиса ОД — не ниже 3.3.

После установки сервиса необходимо убедиться, что даны полные права для пользователя IIS, от имени которого выполняется пул UploadService, на папку хранилища файлов ( см в файле конфигурации параметр «Storage.Location» ) и папку APP_DATA\ со всеми подпапками (независимо от места хранения файлов). Пользователь Windows по умолчанию IIS_IUSRS — это встроенная группа, используемая службами IIS ( с Windows 7, ранее IIS_WPG ).

В дополнительных параметрах пула приложений сервиса ОД (если у него персональный пул приложений) следует указать учетную запись LocalSystem , иначе сервис не сможет сохранять ОД из-за отсутствия прав записи на диск по любому локальному пути.

smart_service_pul

Для обновления сервисов предпочтительно использовать утилиту Server Manager .

В случае применения нескольких каналов (адресов) подключения к IIS (основной и резервный), рекомендуем применять параметр UseAppServiceHost в файле конфигурации сервиса приложений.

Лог сервиса находится по пути . \wwwroot\\App_Data\LOGS\ ( — имя папки, куда установлен сервис ОД ).

Рекомендуем создать свой отдельный пул приложений для сервиса ОД.

1)	Развернуть сервис на IIS (см руководство по установке сервисов в папке manual\ дистрибутива комплекса).

2)	В файле конфигурации — UploadService.config — рекомендуем указать следующие значения:

•	способ хранения файлов ОД: FileSystem » /> рекомендуемое значение «FileSystem».

•

физический путь к хранилищу относительно самого сервиса ОД: App_Data » />
Это значение по умолчанию — хранилище в папке сервиса ( . \wwwroot\\App_Data\UPLOADS\ ), папка \UPLOADS добавляется (и создается) к пути автоматически.
Пример: если в файле конфигурации задать папку хранения , то реально будет сохранять по пути E:\BKS\OD\UPLOADS .
Если значение не задавать — — то хранилище будет в незащищенной папке . \wwwroot\\UPLOADS\ .

•	учетные данные для входа в хранилище (прова доступа по физическому пути к хранилищу в ОС Windows): Эти параметры задаются, если в качестве хранилища указан сетевой путь вида \\Server\path . Пример значения .

•	учетные данные для подключения к сервису ОД (сервис ashx):

o	использование Basic авторизации:

o	логин и пароль обращения к сервису:

эти же значения следует прописать в настройке «Меню Настройки: НАСТРОЙКИ \ Первичные документы \ Хранилище первичных документов — настройка», соответственно: Тип аутентификации, Учетные данные (имя:пароль).

Не рекомендуем оставлять пустыми эти учетные данные. Данные параметры являются произвольными, кроме настройки и файла конфигурации нигде не прописываются, и используются для защиты ashx сервиса ОД от постороннего вмешательства.

•	максимальный размер загружаемого файла в КБайт:

3)	Настроить применение сервиса.

Ограничение на размер прикрепляемого файла.

Задается в настройке «Меню Настройки: НАСТРОЙКИ \ Первичные документы \ Хранилище первичных документов — настройка — Максимальный размер файла». Для комплекса «Бюджет-НЕКСТ» задается в файле конфигурации сервиса ОД.

Путь (структура) хранения файлов на сервисе оправдательных документов.

НАСТРОЙКИ \ Первичные документы \ Шаблон пути первичного документа.

Настройка определяет структуру подкаталогов папки Uploads\ сервиса ОД. Доступны следующие маски назначения пути к хранилищу первычных документов:

•	— имя пользователя,

•	— текущая дата в заданном формате, содержит в любой комбинации буквы ‘y’, ‘m’, ‘d’ и символ ‘.’ (точка).

Здесь формат: yyyy — 4 цифры года, mm — 2 цифры месяца, dd — 2 цифры числа. Другой вариант использования: или . Данные маски при нахождении в строке шаблона подменяются на соответствующие значения. Остальной текст шаблона не меняется. Регистр символов в масках при поиске в шаблоне не учитывается. Если настройка пустая (не задана), то используется имя пользователя (логин) . Полный путь к файлам ОД формируется так: uploads\\\ .

1. Нет связи с сервисом первичных документов.

Detail: connect failed in tcp_connect()

Стандартная ошибка подключения по сети. Возникает в случаях:

1.	Клиент не может соединится с сервисом :

•	неправильно прописан адрес в настройке на пользователя,

•	файрволлы, прокси, антивирусы запрещают подключение по определенному протоколу,

•	неправильно настроена маршрутизация .

2.	Сервис не может скачать первичку с сетевого диска. Причины те же что в п.1, плюс еще возможная причина: ОС компьютера, где реально лежат файлы ОД, не серверная и имеет ограничение на 10 одновременных подключений.

2. Файлы ОД не открываются на просмотр.

Иногда возникают случаи, когда отдельные первичные файлы успешно прикрепляются к документам, но не могут открыться на просмотр пользователями. Рекомендуется убедиться, что в настройках IIS расширения этих файлов входят в список типов MIME.

Поннятие об анонимной идентификации и учетной записи IUSR

Dreamweaver UltraDev больше не поддерживается, а центр поддержки Dreamweaver UltraDev больше не обновляется. Функция, предоставлявшаяся в Dreamweaver UltraDev, теперь доступна в Dreamweaver, начиная с Dreamweaver MX.

Анонимный доступ, самый популярный способ управления доступом к сайтам, позволяет любому пользователю посещать открытые разделы сайта, но при этом неавторизованные пользователи не получат доступа к функциям администрирования и конфиденциальным данным на веб-сервере. Анонимная идентификация предоставляет пользователям доступ на сайт без запроса имени пользователя или пароля. Когда пользователь пытается подключиться к сайту, веб-сервер назначает такому пользователю учетную запись Windows под названием IUSR_название-компьютера, где «название-компьютера» – это имя имя сервера, на котором работает IIS.

По умолчанию учетная запись IUSR_название-компьютера включена в группу пользователей Windows «Гости» при установленном на сервере IIS. Эта группа имеет ограничения по правам, соответствующие разрешениям NTFS, которые задают уровень доступа и тип содержимого, доступного для обычных пользователей Интернета. Изменения можно внести в учетную запись, используемую для анонимной идентификации, в диспетчере служб Интернета на уровне веб-сервера или для отдельных виртуальных каталогов и файлов. Права доступа для учетной записи IUSR_название-компьютера можно изменить с помощью диспетчера пользователей для Windows NT и раздела «Локальные пользователи и группы» на консоли управления сервером для Windows 2000.

IIS использует учетную запись вида IUSR_название-компьютера следующим образом:

Учетная запись IUSR_название-компьютера добавляется к группе «Гости» на компьютере.

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

Перед возвратом страницы браузеру IIS проверяет права NTFS для файлов и каталогов, чтобы установить, разрешен ли доступ к файлу для учетной записи IUSR_название-компьютера.

Если доступ разрешен, завершается проверка подлинности и ресурсы становятся доступны пользователю.

Если доступ не разрешен, то IIS будет пытаться использовать другой метод аутентификации. Если ничего не выбрано, то IIS возвращает браузеру сообщение об ошибке «HTTP 403 доступ запрещен».

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

Дополнительная информация

Более подробную информацию об анонимной идентификации и учетной записи IUSR см. в технической документации по IIS. Если установлен IIS, то вы можете посмотреть по нему документацию, набрав http://localhost/iishelp/ в адресной строке своего браузера и нажав клавишу Enter.

Для получения дополнительной информации см. раздел «Настройка доступа для сервера IIS».

Прекрасным источником информации по проблемам доступа в IIS является Центр информационной безопасности Microsoft.

Права доступа на загружаемые файлы в Windows (IIS 7.5)

Кофигурация: Windows Web Server 2008 R2 (IIS 7.5), php 5.2.13 (VC6 x86 Non Thread Safe), drupal 6.15.
В IIS все по-умолчанию — веб-узлы работают под пользователем IUSR.

При загрузке файла на сервер через сайт, на файле имеются следующие права доступа:
Владелец файла — IUSR
Пользователю IUSR — полный доступ.
Группе IIS_IUSRS — особые разрешения (стоит только одна галочка «содержание папки/чтение данных»).

При попытке обращения к файлу через сайт — ошибка (500 — внутренняя ошибка сервера, ресурс не может быть отображен).
Чтобы файл стал виден, надо или добавить прав группе IIS_IUSRS или вообще убрать эту группу из этого файла.

IUSR и IIS_IUSRS — являются встроенными и, насколько я понимаю, пользователь IUSR является членом группы IIS_IUSR.
Получается, когда права на файл даны и самому пользователю и группе в которую он входит — берутся минимальные права (пробовал пользователя IUSR добавлять в группу Администраторы — результат тот же).

Такие права на файл даются независимо от того, какие права указаны в вышестоящей папке «files».
Перепробовал разные варианты, в том числе и:
1. Оставляю все по-умолчанию (т.е. ни IUSR ни IIS_IUSRS не указаны)
2. Даю и IUSR и IIS_IUSRS полный доступ на папку.
На выходе: пользователю IUSR — полный доступ, а права на файл для группы IIS_IUSRS или даются или переопределяются и имеются только «особые разрешения» в виде прав на «содержание папки/чтение данных».

Подскажите, на чьей стороне (drupal, php, iis) происходит указанное наделение правами?
Задача вроде простая — сделать так чтобы загружаемые файлы были доступны — но решить ее не получается.

Drupal6
Есть вопрос
Решение проблем

Блог
Войдите или зарегистрируйтесь, чтобы отправлять комментарии

Windows 10, IIS 10: доступ к файлам, часть 3 (IUSR и IIS_IUSRS)

В сервере IIS (начиная с версии 7) есть встроенная учетная запись пользователя, которая называется IUSR, и есть встроенная группа, которая называется IIS_IUSRS. Кое-что (но далеко не всё) про эти встроенные учетную запись и группу рассказано в статье «Understanding Built-In User and Group Accounts in IIS 7» документации на сайте компании «Microsoft».

Кроме того, как уже упоминалось в предыдущем посте, в сервере IIS есть встроенная учетная запись пользователя для каждого пула приложений с именем, совпадающим с именем пула приложений. Например, для пула приложений, созданного автоматически по умолчанию при включении сервера IIS, эта учетная запись называется «DefaultAppPool». Подробнее об этом можно прочитать в статье «Understanding identities in IIS», а также в статье «Application Pool Identities» документации на сайте компании «Microsoft».

Путаница IUSR и IIS_IUSRS

Из-за сходства названий встроенной учетной записи пользователя IUSR и встроенной группы IIS_IUSRS их часто путают. Во-первых, некоторые люди их путают, считая одним и тем же. Очевидно, что это не так.

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

Название пользователя «IUSR» расшифровывается как «Internet User» (по-русски «пользователь интернета»). В качестве пользователя IUSR подразумевается любой пользователь, использующий браузер и обратившийся из браузера с помощью ввода URL-адреса к веб-серверу IIS.

В группу же IIS_IUSRS входят все встроенные учетные записи пулов приложений сервера IIS. То есть изначально в нее по умолчанию у меня входит только встроенная учетная запись пользователя «DefaultAppPool». При добавлении новых пулов приложений их встроенные учетные записи будут добавлены в группу IIS_IUSRS автоматически, то есть вручную их добавлять в эту группу не требуется (так настроено по умолчанию, но это можно изменить, сделав так, чтобы встроенные учетные записи новых пулов приложений нужно было добавлять в эту группу вручную).

Следует иметь в виду, что в программе (в сохраненной консоли программы «mmc.exe») «Управление компьютером» в списке пользователей учетная запись IUSR не отображается, несмотря на то, что она существует.

Группа IIS_IUSRS в программе «Управление компьютером» отображается, но, если попытаться просмотреть, кто в нее входит, то там ничего отображено не будет, несмотря на то, что в этой группе на самом деле есть содержимое. Вот как это выглядит у меня:

Как я понимаю, нет смысла заполнять эту группу вручную, если она пополняется автоматически.

Как используется встроенная учетная запись IUSR

Для пользователей, входящих из своих браузеров на наш сайт, который находится под управлением веб-сервера IIS, можно настроить аутентификацию (проверку подлинности личности). Устройство веб-сервера IIS не позволяет настроить вход на сайт пользователей вообще без аутентификации. В самом простом случае, который настроен автоматически по умолчанию при включении веб-сервера IIS в операционной системе, пользователи проходят на сайт в качестве анонимных пользователей. При этом от пользователей не требуется никаких действий по подтверждению своей личности. Для этого при аутентификации в веб-сервере IIS используется модуль «Анонимная проверка подлинности» (по-английски «Anonymous authentication»).

Если требуется настроить более сложную аутентификацию, этот умолчательный модуль «Анонимная проверка подлинности» нужно будет отключить и включить модуль другого способа аутентификации. Но мы это делать не будем и посмотрим, как настроена умолчательная аутентификация.

В программе «Диспетчер служб IIS» аутентификацию можно настроить на уровне сервера, на уровне сайта, на уровне папки и так далее. Для этого следует в левом меню «Подключения» выбрать нужный уровень (например, уровень сервера). После этого в средней части окна программы следует открыть пункт «Проверка подлинности» (по-английски «Authentication»):

В результате будет показан список готовых к использованию модулей, которые можно использовать для аутентификации пользователей:

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

Также на иллюстрации выше видно, что включен только модуль «Анонимная проверка подлинности», а второй модуль отключен. Заглянем в настройки включенного модуля. Для этого следует выделить его в списке в средней части окна программы, а затем выбрать пункт «Изменить. » в меню «Действия» справа:

Как видно на иллюстрации выше, при работе модуля «Анонимная проверка подлинности» каждый пользователь, входящий на наш сайт из своего браузера, в рамках нашего сервера считается пользователем встроенной учетной записи IUSR (при настройках по умолчанию; как видно из настроек выше, это можно изменить).

В главном файле настроек веб-сервера IIS «applicationHost.config» вышеописанная настройка выглядит так:

В коде выше многоточиями я показал код, который мне в данный момент не интересен. Видно, как внутри XML-элемента «authentication» описан включенный модуль и прописано имя пользователя. Из этого кода видно, какие виды аутентификации могут быть включены вместо анонимной аутентификации. Также следует иметь в виду, что показанного выше кода недостаточно для полного определения того, что я описал выше, для анонимной аутентификации. В других местах этого XML-файла прописаны еще дополнительные настройки, в частности, местонахождение включенного модуля (модуль представляет собой файл динамически подключемой библиотеки, то есть файл с расширением «.dll»).

Под какой учетной записью происходит доступ к файлам сайта

Когда я стал изучать работу веб-сервера IIS, у меня сразу возник следующий вопрос. В прошлом посте я описывал архитектуру веб-сервера IIS, то, как он работает на уровне процессов. Там я описал, что пул приложений «DefaultAppPool» сайта «Default Web Site» запускается в виде рабочего процесса от имени встроенной учетной записи пользователя «DefaultAppPool». Теперь при изучении настроек веб-сервера IIS по умолчанию мы видим, что пользователь сайта числится под учетной записью IUSR. Тогда от имени какой из этих двух учетных записей происходит доступ к файлам сайта?

Веб-сервер IIS может быть настроен по-разному. Но, если говорить о рассмотренных выше умолчательных настройках веб-сервера IIS, то, насколько я понимаю, рабочий процесс веб-сервера IIS, осуществляющий доступ к файлам сайта, имеет первичный токен доступа от учетной записи «DefaultAppPool» и в качестве токена имперсонации (олицетворения) — токен доступа от учетной записи IUSR. Таким образом, доступ к файлам при рассмотренных выше настройках происходит от имени учетной записи IUSR.

То есть, по идее, в зависимости от вышеописанной настройки, мы можем настроить либо доступ к файлам от имени встроенной учетной записи IUSR, либо от имени встроенной учетной записи «DefaultAppPool».

Итак, по умолчанию доступ к папке нашего сайта регулируется следующим списком доступа:

Шесть позиций, перечисленных в списке доступа на вышеприведенной иллюстрации, совпадают с теми, которые описаны для папки «\inetpub\wwwroot\» в статье «Default permissions and user rights for IIS 7.0 and later» документации на сайте компании «Microsoft». Из них меня сейчас в первую очередь интересуют две группы: «IIS_IUSRS» и «Пользователи».

Насколько я понимаю, встроенная учетная запись «DefaultAppPool» по умолчанию входит в группу «IIS_IUSRS» и в группу «Пользователи» компьютера, а встроенная учетная запись «IUSR» входит только в группу «Пользователи». (Эти факты не видны из программы «Управление компьютером».)

Обеим этим группам, как видно из иллюстрации выше, назначен ограниченный доступ к файлам: разрешены только чтение и выполнение, но не изменение файлов, не создание новых файлов, не удаление файлов и так далее. Последнее не важно для статических сайтов, так как на статических сайтах пользователь только читает файлы, но важно для динамических сайтов (вроде веб-приложения «WordPress»), на которых пользователь должен иметь право изменять файлы, создавать новые файлы и так далее. Таким образом, понятно, что для статических сайтов дополнительных настроек в плане доступа к файлам не требуется, а вот для динамических сайтов дополнительные настройки доступа к файлам могут потребоваться.

Я думаю, что для дополнительной настройки доступа к файлам сайта не стоит менять настройки доступа для групп, так как это может затронуть других пользователей, входящих в эти группы. Думаю, что для расширения прав доступа к файлам динамического сайта следует добавить в список доступа на вышеприведенной иллюстрации либо пользователя «IUSR», либо пользователя «DefaultAppPool» (в зависимости от того, кто из этих пользователей выбран при настройке анонимной аутентификации, описанной выше), назначив им необходимые права доступа.

Iis iusrs что это