Этапы развертывания
После описания возможных вариантов и параметров установки, рассмотрим шаги, которые надо предпринять при развертывании двухуровневой инфраструктуры центров сертификации на базе Windows Server 2008.
Вначале необходимо определить, кто будет использовать сертификаты — только сотрудники компании, клиенты или партнеры. Продумать, для каких целей и в каких приложениях будут использоваться сертификаты, каким образом сертификаты будут запрашиваться и обновляться. Каким образом будет настраиваться доверие к корневому сертификату для пользователей. Самый простой вариант — использовать групповые политики, но он подходит только для сотрудников компании, при наличии единого леса в организации. Иногда даже приходится доставлять самоподписанный сертификат на материальном носителе во все филиалы компании.
Если в итоге было принято решение о создании иерархии корпоративных ЦС, то переходим к следующим шагам.
- Проверить, что выполнены предварительные требования.
- В случае использования одного Issuing CA на весь лес, соответствующий сервер должен быть включен в группу Certpublishers в каждом домене.
- Если используются HSM-модули, они должны быть подключены до начала установки УЦ.
- Для установки требуется учетная запись Enterprise Admin или длительная настройка разрешений на объекты и контейнеры AD.
- Установить Stand-Alone Root CA, который планируется использовать в варианте Offline, с использованием файла CAPolicy.Inf, в котором отсутствуют AIA и CDP и указан увеличенный срок действия сертификата УЦ. Пример такого файла с минимальным набором параметров — в листинге. Срок действия сертификата УЦ, заданный через мастера добавления ролей будет иметь более высокий приоритет, чем срок, заданный в файле. Файл CAPolicy.Inf должен находиться в %SystemRoot%, в противном случае он не будет использован.
- Задать необходимые параметры для корневого УЦ.
- Задать расширения CDP и AIA для выдаваемых сертификатов, указав пути, которые будут доступны для пользователей при отключении корневого УЦ. Параметры задаются на вкладке Extensions в свойствах сервера в оснастке Certification Authority. И для местоположения CRL, и для местоположения корневого сертификата необходимо включить расширения в издаваемые сертификаты, отметив «Include in the CDP (AIA) extension of issued certificates» соответственно. Можно настроить CDP и AIA через командную строку с помощью certutil. После конфигурирования параметров необходимо разместить соответствующие файлы по указанным путям.
- Задать интервал публикации CRL от нескольких месяцев до года, и каждый раз по истечению заданного интервала переводить УЦ в состояние online, генерировать CRL и копировать его по путям, указанным в CDP. Настройка интервала публикации CRL производится в свойствах контейнера Revoked Certificates оснастки Certification Authority командой certutil (листинг 2) или указывается перед установкой УЦ в файле CAPolicy.Inf в разделе (листинг 3).
- Необходимо увеличить период действия выдаваемых сертификатов, так как выдаваемые сертификаты будут предназначены для УЦ.
- На сервере, который будет подчинен УЦ, настроить доверие к корневому сертификату. Впоследствии необходимо будет настроить доверие к корневому сертификату для всех пользователей.
- Установить Issuing Enterprise CA, который будет являться подчиненным для Stand-Alone Root CA. В процессе установки надо сохранить запрос на сертификат для подчиненного УЦ в файл. Файл с запросом необходимо скопировать на сервер, на котором установлен корневой УЦ, в оснастке Certification Authority выбрать Submit new request в разделе Action и открыть скопированный файл. После этого сертификат необходимо издать, так как по умолчанию он окажется в контейнере Pending Requests. Затем полученный сертификат перенести и установить на подчиненном УЦ.
Есть еще некоторые подводные камни при удалении центра сертификации из домена — недостаточно только удалить соответствующую роль, так как после этого остается еще база изданных сертификатов, сертификаты и ключи УЦ, списки отзывов и сертификаты промежуточных УЦ.
Какие существуют типы сетевого сканирования?
Существует два разных типа сетевого сканирования, и они отличаются друг от друга, поскольку каждый метод во многом зависит от того, чего пользователь хочет достичь при сканировании.
- Сканирование уязвимостей
- Сканирование портов
1]Что такое сканирование уязвимостей
Если вы хотите найти уязвимости, расположенные на вашем компьютере, то вы должны воспользоваться сканированием уязвимостей. Запустив сканирование с помощью этого метода, вы потенциально обнаружите угрозы, которые были скрыты от вашего взгляда.
Теперь мы должны добавить, что большинству организаций по всему миру требуется ИТ-отдел для запуска сканирования уязвимостей. Однако, если вы хотите получить исчерпывающую обратную связь, лучше нанять эксперта по безопасности, который не работает в компании.
Обратите внимание, что сканирование уязвимостей также может выполняться злоумышленниками, желающими найти слабые места в вашей сети. Лучший шаг — сначала найти слабые места, прежде чем эти преступники сделают свой ход
2]Что такое сканирование портов
Итак, сканирование портов очень важно, поскольку оно позволяет пользователю определить, какой открытый порт в сети может отправлять или получать данные. Таким образом, люди могут использовать этот метод для отправки пакетов, предназначенных для нескольких портов на одном устройстве
Из того, что мы собрали до сих пор, этот процесс отлично подходит для выявления лазеек в сети. Теперь, когда процедура сканирования портов будет завершена, она будет использовать собранные данные для диагностики уровней безопасности каждого устройства.
Определения
При общении с администраторами, и уж тем более — с пользователями, часто выясняется, что использовать сертификаты они уже научились, но на вопрос, что это такое, можно часто услышать неуверенный ответ «ну, это… ну, для аутентификации». Поэтому позволю себе начать статью с определений; те, кто с ними знаком, могут сразу переходить к следующему разделу.
Сертификат — это файл или объект, хранящийся в базе данных, который содержит следующие поля: номер, открытый ключ, информацию о владельце ключа и вариантах его использования, информацию об УЦ, выдавшем сертификат, и срок действия. Кроме перечисленных полей сертификат может содержать и другие данные. Формат сертификата определяется стандартом X.509, на данный момент действует третья версия стандарта. Вся информация, содержащаяся в сертификате, заверена подписью УЦ.
Инфраструктура открытых ключей (Public Key Infrastructure (PKI)) — это набор взаимосвязанных программных и аппаратных компонентов, а также административных и организационных мер для работы с криптографическими системами, использующими ассиметричные алгоритмы.
Приложения, относящиеся к PKI, можно разделить на две категории:
- приложения для работы только с сертификатами — центры регистрации, центры сертификации, каталоги сертификатов;
- пользовательские приложения — почтовые клиенты, браузеры, системы защищенного документооборота и др.
Кроме технической составляющей важную роль играют и «бюрократические» компоненты PKI, особенно когда существует потребность реализовать юридически значимый электронный документооборот. Политики сертификации (Certificate Policy) и регламент УЦ (Certificate Practice Statements) позволяют определить уровень доверия к издаваемым сертификатам.
Если политики и регламенты, состав и производители пользовательских приложений могут меняться от организации к организации, то наличие центра сертификации, пусть и от разных вендоров, остается неизменным. Удостоверяющий центр — это основа инфраструктуры открытых ключей, которая объединяет программные модули и аппаратные компоненты (например, HSM — Hardware Security Module). Прежде чем описывать функции УЦ, посмотрим на жизненный цикл ключей и сертификатов, показанный на схеме (см ниже). Не все приведенные на схеме пункты обязательно встречаются для каждого ключа или сертификата.
После этого сертификат должен быть помещен в хранилище, доступное тем, кто будет использовать этот сертификат — это может быть служба каталогов или веб-сервер. Далее сертификат используется в рабочем порядке до тех пор, пока не истечет срок действия ключа или сертификат не будут отозван. Причины отзыва могут быть связаны с изменением данных о владельце (смена фамилии или должности, изменение название сайта) или компрометацией закрытого ключа. Важная задача УЦ — поддержание актуальной информации о статусе сертификата.
Необходимо избежать ситуаций, когда злоумышленник с помощью украденного закрытого ключа подписывает договор, который впоследствии признается действительным, так как на момент подписания сертификат не был отозван. УЦ должен регулярно и максимально часто обновлять информацию о статусе сертификата, а владелец сертификата должен как можно раньше сообщать о необходимости отзыва или перевыпуска сертификата. Для предоставления информации о статусе сертификата используются списки отзыва, которые содержат информацию обо всех отозванных сертификатах, или изменениях по сравнению с предыдущим списком отзыва, или протокол OCPS (Online Certificate Status Protocol).
Списки отзыва генерируются с заданным на УЦ интервалом, в то время как с использованием компонента OCSP responder можно получить информацию о статусе сертификата в реальном времени. В том случае, если закончился срок действия закрытого ключа, то центр сертификации занимается выпуском нового сертификата для нового ключа или для этого же ключа, но с другим сроком действия (использование того же ключа оправдано, например, для сертификатов агентов восстановления ключей, чтобы избежать процедуры экспорта-перешифрования-импорта заархивированных ключей).
Алгоритмы и длина ключа
Очевидно, что чем длиннее ключ, тем надежнее защищены данные, и тем больше времени требуется на взлом. Но при этом больше ресурсов требуется и на выполнение шифрования, расшифровки и проверки подписи. Кроме ресурсов требуется поддержка конкретной длины ключа всеми приложениями, которые могут быть установлены у участников PKI. То есть при выборе длины ключа центра сертификации в 4096 бит надо быть уверенным, что все операционные системы, почтовые приложения, системы документа оборота и другие приложения, использующие сертификаты, смогут работать с ключами такой длины.
Кроме длины ключа надо выбрать криптографические алгоритмы, которые будут использоваться. Здесь все зависит не только от предпочтений администратора и возможностей ПО, но и от области деятельности компании — кроме требований к сертификации и лицензированию средств криптографической защиты, используемых при обработке персональных данных и государственной тайны, существуют отраслевые стандарты, которые регламентируют использование конкретных алгоритмов.
Кроме того, необходимо правильно выбрать алгоритм хеширования, который используется для создания хешей сертификатов, которые потом подписываются УЦ. С одной стороны, довольно популярный алгоритм SHA1 рекомендуется прекратить использовать до конца текущего года, из-за атак на него, и перейти на SHA2. С другой стороны, WinXP SP2 и Server 2003 SP2 не поддерживают SHA2 без обновлений, причем для Server 2003 SP2 требуется установка KB938397, который недоступен через стандартный Windows Update, а требует отдельного скачивания.
Настраиваем базовую безопасность TCP (параметр Memory Pressure Protection) в Windows
Данная функция предназначена для защиты от достаточно известной атаки – локального отказа в обслуживании, вызванного тем, что удалённый атакующий инициирует множество TCP-сессий к нашей системе, система выделяет под каждую сессию буферы и оперативная память, возможно, заканчивается (ну или просто забивается до степени, когда начинается свопинг и производительность ощутимо падает.
Параметр включен по умолчанию в Windows Server 2008 R2, поэтому обычно нет смысла его настраивать, но если что – Вы можете его включить вручную. Более того, Вы можете выбрать, на каких портах эту защиту включать, а на каких – нет. Это имеет смысл, если доступны снаружи лишь некоторые порты, а не все.
Как включить Memory Pressure Protection в Windows
Выключение MPP для всех портов, кроме указанного (например, кроме LDAP)
Дополнительно
На самом деле, можно включать или выключать MPP для протоколов IP разных версий отдельно, а не глобально для всех. Для этого будут два ключа реестра с предсказуемыми названиями:
Параметр EnableMPP в каждом из случаев имеет тип 32bit DWORD и ставится либо в единицу, либо в нуль.
Установка роли Network Controller
Развернуть Network Controller можно как в доменной, так и в бездоменной сети. В первом случае аутентификация пользователей и сетевых устройств производится при помощи Kerberos, во втором потребуются сертификаты. Для знакомства и тестирования можно использовать единственный физический или виртуальный сервер. В промышленной среде для обеспечения высокой доступности следует развернуть кластер из нескольких серверов. Network Controller легко масштабируется, поэтому новые серверы добавляются в кластер очень просто. Клиенты для управления Network Controller могут использовать не только серверную ОС, но и Win 8/8.1/10.
Если узлы с ролью Network Controller развернуты в разных подсетях, следует в диспетчере DNS разрешить динамические обновления DNS для зоны, установив в свойствах зоны параметр Dynamic updates в Secure only. Тип зоны должен быть установлен в Primary или Active Directory-integrated. И установить разрешения для узлов в Security -> Advanced (Безопасность -> Дополнительно). Для тестовой среды с одним сервером это не нужно.
Каждый сервер и клиент, участвующий в соединении, потребует сертификат, содержащий в поле Subject имя компьютера. Это позволяет разрешить его через DNS. Сертификаты следует импортировать/экспортировать на остальные узлы и сделать доверенными для остальных участников. Будем считать, что все это уже сделано, и на управлении сертификатами останавливаться не будем. Для тестирования можно сгенерировать самоподписанный сертификат с помощью диспетчера IIS.
Установить роль Network Controller (Сетевой контроллер) можно при помощи диспетчера сервера, выбрав его в ролях сервера и подтвердив установку инструментов управления или PowerShell. Команда здесь проста:
Установка роли «Сетевой контроллер»
Другие статьи в выпуске:
Xakep #205. Взлом Single Sign-On
- Содержание выпуска
- Подписка на «Хакер»-60%
По окончании установки в диспетчере сервера появится новая вкладка Network Controller, позволяющая просмотреть события. Управлять же основными функциями, как уже говорилось, можно при помощи командлетов PowerShell, решений SCVMM 2016 и SCOM 2016, предлагающих графический интерфейс. Последние трогать не будем, разберем PowerShell.
Модуль NetworkController содержит 45 командлетов. Получить их полный список можно при помощи
Все командлеты разбирать точно нет смысла, тем более примеры будут большие, рассмотрим основные моменты, позволяющие понять суть настроек. К сожалению, документация MS в части использования Network Controller с PowerShell пока весьма скудна, некоторые моменты приходится уточнять экспериментально, но разобраться путем проб и ошибок можно. Будем надеяться, что к окончательному релизу эта проблема будет решена.
Командлеты модуля NetworkController
Основой всего является приложение (объект) Network Controller, уже на котором строится кластер, обеспечивающий высокую доступность и масштабируемость. Причем кластер устанавливается всегда, даже в случае единственного экземпляра NetworkController.
Настраиваем использование NetDMA в Windows
NetDMA – достаточно интересная функция. Смысл её применения есть тогда, когда у Вас не поддерживается Chimney Offload и Вы хотите ускорить обработку сетевых подключений. NetDMA позволяет копировать без участия CPU данные (в общем, как и любой DMA-доступ) из приемных буферов сетевого стека сразу в буферы приложений, чем снимает с CPU данную задачу по тупому выполнению чего-то типа .
Говоря проще, если Ваша сетевая плата не может “вытащить” на себя полную обработку TCP-соединений, то NetDMA хотя бы разгрузит процессор от самой унылой части задачи по обслуживанию сетевых соединений – копированию данных между сетевой подсистемой и использующими её приложениями.
Секретный уровень
Если Вы дочитали до этого места, то дальше не читайте – опасно. Но вообще, в том же ключе – – есть параметр , тоже типа , который, что и логично, исходя из его названия, указывает минимальный размер пакета, для которого имеет смысл инициировать DMA-передачу. Параметр данный выставляется автоматически и его тюнинг имеет слабый практический смысл – т.е. в принципе можно представить ситуацию, когда система поставит слишком малый параметр, и будет слишком часто переключаться на DMA, а Вы это поправите вручную, но очень слабо могу представить себе КПД этой операции – выяснять сие путём достаточно кропотливых синтетических тестов, чтобы выиграть призрачные доли процента на единственной операции в единственной подсистеме, притом доли эти будут укладываться в погрешность измерений, весьма уныло.
Варианты использования ключа
В сертификате обязательно указывается, для каких целей будет использоваться соответствующий ключ — для создания подписи, шифрования, обмена ключами, аутентификации.
Если открытый ключ из сертификата будет использован для шифрования, то необходимо продумать и настроить возможность восстановления закрытого ключа или данных. В ситуации, когда сотрудник уволился и не расшифровал документы, над которыми он работал несколько лет, или пользователь потерял токен с закрытым ключом, компания может потерять не только время на расшифровку данных, но и выручку, и заказчиков, для которых проект не был выполнен в срок.
Данные шифруются с помощью секретного ключа симметричным алгоритмом, этот секретный ключ шифруется открытым ключом пользователя и помещается в заголовок зашифрованного файла. Секретный ключ может шифроваться не только открытым ключом пользователя, но и открытым ключом агента восстановления (data recovery agent).
В этом случае агент получает возможность расшифровать данные даже при утере пользовательского закрытого ключа. Второй путь — это архивирование и шифрование закрытого ключа пользователей с помощью открытых ключей агентов восстановления ключей (key recovery agent), и последующее восстановление пользовательского ключа в случае его утраты.
Возможности Network Controller
Network Controller — новая роль в составе Win 2016, пришедшая из Azure, обеспечивает единую точку управления и мониторинга для всех физических и виртуальных сетей домена, позволяя из одной точки настраивать IP-подсети, VLAN, маршрутизаторы и физические сетевые адаптеры Hyper-V-хостов. Используя Network Controller, мы можем управлять соединениями виртуальных машин Hyper-V, виртуальными коммутаторами, физическими сетевыми маршрутизаторами, настройками файрвола, VPN-шлюзами, в том числе и RRAS, и балансировкой нагрузки. Маршрутизацию обеспечивает использование протокола Border Gateway Protocol (BGP). Управление правилами брандмауэра позволяет контролировать трафик в любом направлении, используемом узлами кластера и отдельными VM. В качестве виртуальных сетей поддерживаются не только родные для MS NVGRE (Network Virtualization using Generic Routing Encapsulation, используется от Win 2012), но и VXLAN (Virtual Extensible LAN — VMware, Arista Networks, Cisco…). Функциональность, как мы видим, не ограничивается только виртуальными машинами, управлять можно также физическими серверами, являющимися частью кластера Windows Server. Для управления функциями Network Controller реализовано два API:
- Southbound API. Используется для взаимодействия с сетевыми устройствами, службами и прочими элементами облака. Именно с его помощью обнаруживаются конфигурации и изменения, собираются данные о сети;
- Northbound API. Представляет собой REST-интерфейс. Используется для мониторинга и управления сетью при помощи командлетов PowerShell, API REST или System Center 2016 Virtual Machine Manager (SCVMM 2016) и System Center 2016 Operations Manager (SCOM 2016). В последних двух вариантах доступен графический интерфейс.
Сетевой контроллер, используя SNMP и анализ сетевого потока, обнаруживает проблемы, связанные с задержками и потерями пакетов, и информирует о неправильно работающих устройствах в сети. Поддерживается новый инструмент Microsoft Message Analyzer, пришедший на замену Microsoft Network Monitor, он позволяет захватывать, отображать и анализировать трафик по различным протоколам, отслеживать и оценивать системные события, сообщения устройств, задержки и потери пакетов, искать и устранять неисправности. Ведется сбор SNMP-данных, определяется статус работы отдельных устройств. Есть возможность автоматического обнаружения и группирования устройств по некоторым характеристикам, с установлением зависимости между физическими и виртуальными устройствами. Например, в случае обнаружения проблем с определенными сервисами сетевой контроллер помечает все связанные серверы, VM, маршрутизаторы и прочее как неисправные. Для автоматического обнаружения физических и виртуальных серверов в сети используется механизм Data Center Bridging, реализующий несколько стандартов IEEE 802.1.
Настройка политик аудита
Очень часто можно услышать совет: «давайте включим все политики». Это, конечно, — «путь джедая», но, как показывает практика, не все джедаи добрались до финала.
Для большинства сценариев мониторинга нет острой необходимости включать всё. Это излишне. Включая все политики, вы можете получить гигантский поток событий, в котором очень легко «утонуть». В большой инфраструктуре с несколькими тысячами Windows-хостов поток событий может исчисляться десятками тысяч EPS (событий в секунду). Это порождает другую, не менее сложную задачу: как этим управлять, где это хранить, как обрабатывать.
Предлагаем рассмотреть оптимальный список политик, который может вам понадобиться
Также стоит обратить внимание на то, что фактически настроек две (и, соответственно, существуют две различные GPO). Первая — исключительно для контроллеров домена, так как часть событий (например, ID 4768: A Kerberos authentication ticket (TGT) was requested) фиксируется исключительно на них
Вторая — для рядовых серверов и АРМ пользователей.
Таблица 2. Рекомендуемые настройки аудита Windows
| Категория | Подкатегория | Включить | Хост (DC, сервер, АРМ) | Категория (успех / отказ) |
| Account Logon | Audit Credential Validation | + | DC, сервер, АРМ | Успех и отказ |
| Audit Kerberos Authentication Service | + | DC | Успех и отказ | |
| Audit Kerberos Service Ticket Operations | + | DC | Успех и отказ | |
| Audit Other Account Logon Events | — | |||
| Account Management | Audit Application Group Management | + | DC | Успех и отказ |
| Audit Computer Account Management | + | DC | Успех | |
| Audit Distribution Group Management | + | DC | Успех | |
| Audit Other Account Management Events | + | DC, сервер, АРМ | Успех | |
| Audit Security Group Management | + | DC, сервер, АРМ | Успех | |
| Audit User Account Management | + | DC, сервер, АРМ | Успех и отказ | |
| Detailed Tracking | Audit DPAPI Activity | + | DC, сервер, АРМ | Успех и отказ |
| Audit PNP Activity | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Process Creation | + | DC, сервер, АРМ | Успех | |
| Audit Process Termination | — | |||
| Audit RPC Events | — | |||
| Audit Token Right Adjusted | — | |||
| DS Access | Audit Detailed Directory Service Replication | + | DC | Успех и отказ |
| Audit Directory Service Access | + | DC | Успех и отказ | |
| Audit Directory Services Changes | + | DC | Успех и отказ | |
| Audit Directory Service Replication | + | DC | Успех и отказ | |
| Logon/Logoff | Audit Account Lockout | + | DC, сервер, АРМ | Отказ |
| Audit User / Device Claims | — | |||
| Audit IPsec Extended Mode | — | |||
| Audit IPsec Main Mode | — | |||
| Audit IPsec Quick Mode | — | |||
| Audit Logoff | + | DC, сервер, АРМ | Успех | |
| Audit Logon | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Network Policy Server | — | |||
| Audit Other Logon / Logoff Events | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Special Logon | + | DC, сервер, АРМ | Успех | |
| Object Access | Audit Application Generated | — | ||
| Audit Certification Services | — | |||
| Audit Detailed File Share | — | |||
| Audit File Share | — | |||
| Audit File System | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Filtering Platform Connection | — | |||
| Audit Filtering Platform Packet Drop | — | |||
| Audit Handle Manipulation | — | |||
| Audit Kernel Object | — | |||
| Audit Other Object Access Events | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Registry | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Removable Storage | + | DC, сервер, АРМ | Успех и отказ | |
| Audit SAM | — | |||
| Audit Central Access Policy Staging | — | |||
| Policy Change | Audit Policy Change | + | DC, сервер, АРМ | Успех |
| Audit Authentication Policy Change | + | DC, сервер, АРМ | Успех | |
| Audit Authorization Policy Change | + | DC, сервер, АРМ | Успех | |
| Audit Filtering Platform Policy Change | — | |||
| Audit MPSSVC Rule-Level Policy Change | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Other Policy Change Events | — | |||
| Privilege Use | Audit Non Sensitive Privilege Use | + | DC, сервер, АРМ | Успех и отказ |
| Audit Other Privilege Use Events | — | |||
| Audit Sensitive Privilege Use | + | DC, сервер, АРМ | Успех и отказ | |
| System | Audit IPsec Driver | — | ||
| Audit Other System Events | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Security State Change | + | DC, сервер, АРМ | Успех | |
| Audit Security System Extension | + | DC, сервер, АРМ | Успех | |
| Audit System Integrity | — | |||
| Global Object Access Auditing | File system | — | ||
| Registry | — |
После включения описанных политик у вас будут все необходимые события для мониторинга и расследования инцидентов.
Документооборот при использовании оснастки «Управление сканированием»
Ниже перечислены операции, выполняемые при сканировании документа и его доставке по сети. Предполагается, что сервер сканирования уже был установлен и настроен, а к сети подключен «корпоративный» WSD-сканер.
- С помощью оснастки «Управление сканированием» выбирается один или несколько сканеров, которыми требуется управлять.
- С помощью оснастки «Управление сканированием» создается один или несколько процессов сканирования для пользователей и групп.
- Процессы сканирования автоматически сохраняются в доменных службах Active Directory (AD DS).
- Пользователь выполняет вход на сканер и проходит проверку подлинности.
- Созданные для этого пользователя процессы сканирования загружаются из доменных служб Active Directory и отображаются на передней панели сканера.
- Пользователь выбирает требуемый процесс сканирования и запускает сканирование документа.
- Отсканированный документ и сведения о выбранном процессе сканирования отправляются на сервер сканирования.
- Сервер сканирования запускает выбранный пользователем процесс сканирования. Отсканированный документ можно отправить в сетевую папку, на веб-сайт Windows SharePoint, получателю электронной почты или в любое сочетание этих назначений.
- Сервер сканирования заносит в журнал результаты сканирования и отправляет пользователю уведомление, отображаемое на передней панели сканера.
- Если процесс сканирования запрашивал доставку документа по электронной почте, пользователь получает сообщение электронной почты с уведомлением о доставке документа.