В случае, если сервер располагается на базе Cassini, Вам необходимо нажать клавишу с логотипом Windows (флажок Microsoft) + R и ввести следующую команду в диалоговое окно: "services.msc " (без кавычек), после чего появится окно служб Windows. В нем Вы сможете найти строчку Веб-сервер ELMA , кликнуть по ней правой кнопкой мыши и выбрать в контекстном меню пункт Свойства , в котором и располагается искомая вкладка Вход в систему . Укажите учетную запись LocalSystem
Если сервер располагается на базе IIS, необходимо зайти в Диспетчер служб IIS (стандартно на сервере в Пуск - Администрирование ). В нем на вкладке Пулы приложений нажать правой кнопкой мыши на пул ELMA3-Standart и выбрать в контекстном меню пункт Дополнительные параметры . На панели Модель процесса в поле Удостоверение указать учетную запись LocalSystem либо реальную учетную запись с правами администратора, после чего следует перезапустить веб-сервер.
Создание учетных данных в среде SQL Server Management Studio
- В обозревателе объектов раскройте папку Безопасность .
- Нажмите правой кнопкой мыши на папку Учетные данные и выберите команду Создать учетные данные .
- В диалоговом окне Создание учетных данных в поле Учетное имя введите имя для учетных данных.
- В поле Удостоверение введите имя учетной записи, используемой для исходящих соединений (при выходе из контекста SQL Server). Как правило, это будет учетная запись пользователя Windows, но удостоверение может быть и учетной записью другого типа. Либо нажмите кнопку с многоточием (...), чтобы открыть диалоговое окно Выбор пользователя или группы .
- В полях Пароль и Подтверждение пароля введите пароль учетной записи, указанной в поле Удостоверение . Если в поле Удостоверение указана учетная запись пользователя Windows, то это будет пароль Windows. Поле Пароль может быть пустым, если пароль не требуется.
- Установите флажок Использовать поставщика услуг шифрования , чтобы учетные данные проверялись поставщиком расширенного управления ключами.
- Нажмите кнопку ОК .
Аутентификация в SQL Server
Как известно, в SQL Server можно выбрать один из двух типов аутинтификации: Windows Authentication (Аутентификация Windows) или SQL Server Authentication (Аутентификация SQL Server). Сменить режим аутентификации на сервере с помощью SSMS (SQL Server Management Studio) либо с помощью EM (Entreprise Manager) достаточно легко. Для этого необходимо в свойствах сервера перейти на закладку Security и установить флажок в нужное поле.
После этого обязательно необходимо перезапустить службу MSSQLSERVER.
Если установлена бесплатная редакция MSDE (2000) или Express (2005/2008) без установленных клиентских утилит, то необходимо знать, что настройки аутентификации хранятся в реестре.
С помощью недокументированной процедуры T-SQL xp_instance_regwrite , через утилиты OSQL/SQLCMD , меняем значение (Windows Authentication mode; SQL Server and Windows Authentication mode ) EXEC xp_instance_regwrite N’HKEY_LOCAL_MACHINE’, N’Software\Microsoft\MSSQLServer\MSSQLServer’, N’LoginMode’, REG_DWORD, 1 . Далее после смены типа аутентификации, необходимо перезапустить службу. Остановить её можно также с помощью T-SQL (процедура xp_servicecontrol также недокументированная): EXEC master..xp_servicecontrol ’stop’, ’MSSQLSERVER’ . А вот запустить службу через T-SQL не выйдет, так как она остановлена, но если у вас установлен второй инстанс, тогда через него достаточно выполнить: EXEC master..xp_servicecontrol ’start’, ’MSSQLSERVER’ . Службу лучше перезапускать с помощью команд net stop MSSQLSERVER/net start MSSQLSERVER .
Конечный вариант для смены аутентификации на сервере будет выглядеть так (достаточно вставить этот код в bat-файл и использовать, когда вам это потребуется):
SQLCMD -E -q "EXEC xp_instance_regwrite N’HKEY_LOCAL_MACHINE’, N’Software\Microsoft\MSSQLServer\MSSQLServer’, N’LoginMode’, REG_DWORD, 1" net stop MSSQLSERVER net start MSSQLSERVER
Создание учетных данных FireBird
Только пользователь SYSDBA может отображать, удалять, изменять и создавать любое количество учетных записей для различных категорий пользователей.
Структура учетных записей пользователей:
- UserName - имя пользователя. Максимальная длина 31 символ. Имя не чувствительно к регистру;
- Password - пароль пользователя чувствителен к регистру. Максимальное количество символов 32, однако, только первые восемь имеют значение;
- UID - целое число, задающее идентификатор пользователя;
- GID - целое число, задающее идентификатор группы;
- FirstName - имя. Может занимать до 17 символов;
- MiddleName - второе имя. Можем использовать в качестве отчества. До 17 символов;
- LastName - фамилия. До 17 символов.
Обязательными являются только имя пользователя и пароль.
Внимание! Ни в каком поле учетной записи не используйте буквы кириллицы. Такая запись не будет создана или изменена.
Запустите программу IBExpert. Нажмите левой кнопкой мыши по кнопке Tools в верхнем меню и в выпадающем меню выберите пункт User Manager . Откроется диалоговое окно User Manager. В выпадающем списке Server выберите local .
Нажмите на кнопку Connect справа от выпадающего списка Server . Откроется диалоговое окно Server Login .
В поле Login уже будет задано имя пользователя SYSDBA . Вам нужно в поле Password ввести пароль masterkey (или другой, если вы изменили значение пароля) и нажать на кнопку ОК . Появится список учетных записей, который будет содержать только одного пользователя SYSDBA.
Нажмите на кнопку Add , в открывшемся окне New User введите имя пользователя (имя пользователя вы можете вводить в любом регистре, символы все равно будут появляться в верхнем регистре) и дважды введите пароль в поля Password и Confirm Password . Нажмите на кнопку ОК . В список будет добавлена новая учетная запись пользователя.
Для изменения существующей записи (изменять можно любое поле, кроме имени пользователя) необходимо нажать на кнопку Edit или дважды нажать левой кнопкой мыши по нужной строке и в появившемся окне изменить желаемые поля.
Для удаления существующей записи щелкните по кнопке Delete и в диалоговом окне подтвердите удаление.
Чтобы изменить имя пользователя, вам нужно удалить старую запись и ввести новую, с другим именем и теми же или другими характеристиками.
Если вы одновременно работаете в IBExpert и используете утилиту gsec или другую программу для добавления или изменения учетных записей, то для того, чтобы увидеть в списке IBExpert новое состояние списка, нужно нажать на кнопку Refresh .
- Tutorial
Кто-то из вас наверняка слышал про инцидент , который был обнародован совсем недавно. Американский производитель полупроводников Allegro MicroSystem LLC подал в суд на своего бывшего IT-специалиста за саботаж. Нимеш Пател, проработавший в компании 14 лет, уничтожил важные финансовые данные в первую неделю нового фискального года.
Как это произошло?
Через две недели после своего увольнения Пател зашел на территорию штаб-квартиры компании в Вустере (штат Массачусетс, США) с целью поймать корпоративную сеть Wi-Fi. Используя учетные данные бывшего коллеги и рабочий ноутбук, Пател авторизовался в корпоративной сети. Затем он внедрил в модуль Oracle код и запрограммировал его выполнение на 1 апреля 2016 года - первую неделю нового финансового года. Код предназначался для копирования определенных заголовков или указателей в отдельную таблицу базы данных и следующего удаления их из модуля. Ровно 1 апреля данные были удалены из системы. И поскольку злоумышленник авторизовался в сети Allegro легально, его действия были замечены не сразу.
Подробности широкая общественность не знает, но скорее всего инцидент стал возможен во многом благодаря тому, что в компании для доступа в сеть использовалась парольная аутентификация. Наверняка там были и другие проблемы с безопасностью, но именно пароль можно похитить незаметно для пользователя и факт кражи пароля не будет обнаружен, в лучшем случае вплоть до момента использования похищенных учетных данных.
Применение строгой двухфакторной аутентификации и запрет на использование паролей в сочетании с грамотной политикой безопасности могли бы помочь, если не избежать описанного развития событий, то сильно затруднить реализацию такого плана.
Мы расскажем о том, как можно значительно повысить уровень безопасности вашей компании и защитить себя от подобных инцидентов. Вы узнаете, как настроить аутентификацию и подпись важных данных, используя токены и криптографию (как иностранную, так и отечественную).
В первой статье мы объясним как настроить строгую двухфакторную аутентификацию с использованием PKI при входе в доменную учетную запись в Windows.
В следующих статьях мы расскажем вам, как настроить Bitlocker, защитить электронную почту и простейший документооборот. Также мы вместе с вами настроим безопасный доступ к корпоративным ресурсам и безопасный удаленный доступ по VPN.
Двухфакторная аутентификация
Опытным системным администраторам и службам безопасности хорошо известно, что пользователи крайне не сознательны в вопросе соблюдения политик безопасности, они могут записать свои учетные данные на стикере и приклеить его рядом с компьютером, передать пароли своим коллегам и тому подобное. Особенно часто это происходит, когда пароль сложный (содержащий более 6 знаков и состоящий из букв разного регистра, цифр и специальных символов) и его трудно запомнить. А ведь такие политики администраторами задаются не просто так. Это необходимо для защиты учетной записи пользователя от простого перебора паролей по словарю. Также администраторы рекомендуют менять пароли хотя бы раз в 6 месяцев, просто из того соображения, что за это время теоретически можно отбрутфорсить даже сложный пароль.
Давайте вспомним, что такое аутентификация. В нашем случае это процесс подтверждения подлинности субъекта или объекта. Аутентификация пользователя - это процесс подтверждения подлинности пользователя.
А двухфакторная аутентификация - это такая аутентификация, в которой необходимо использовать не менее двух различных способов для подтверждения своей личности.
Простейшим примером двухфакторной аутентификации в реальной жизни является сейф с замком и кодовой комбинацией. Чтобы открыть такой сейф необходимо знать код и владеть ключом.
Токен и смарт-карта
Наверно, самым надежным и простым в реализации способом двухфакторной аутентификации является использование криптографического токена или смарт-карты. Токен - это USB-устройство, которое является и считывателем, и смарт-картой одновременно. Первым фактором в таком случае является факт владения устройством, а вторым - знание его PIN-кода.
Использовать токен или смарт-карту, тут кому, что удобнее. Но исторически так сложилось, что в России больше привыкли использовать токены, так как они не требуют использования встроенных или внешних считывателей смарт-карт. У токенов есть и свои минусы. Например, на нем не напечатаешь фотографию.
На фотографии изображена типичная смарт-карта и считыватель.
Однако вернемся к корпоративной безопасности.
А начнем мы с домена Windows, ведь в большинстве компаний в России корпоративная сеть построена именно вокруг него.
Как известно, политики Windows-домена, настройки пользователей, настройки групп в Active Directory предоставляют и разграничивают доступ к огромному количеству приложений и сетевых сервисов.
Защитив учетную запись в домене, мы можем защитить большинство, а в некоторых случаях и вообще все внутренние информационные ресурсы.
Почему двухфакторная аутентификация в домене по токену с PIN-кодом безопаснее обычной парольной схемы?
PIN-код привязан к определенному устройству, в нашем случае к токену. Знание PIN-кода само по себе ничего не дает.
Например, PIN-код от токена можно диктовать по телефону другим лицам и это ничего не даст злоумышленнику, если вы достаточно бережно относитесь к токену и не оставляете его без присмотра.
С паролем же ситуация совершенно иная, если злоумышленник подобрал, угадал, подсмотрел или еще каким-то образом завладел паролем от учетной записи в домене, то он сможет беспрепятственно зайти, как в сам домен, так и в другие сервисы компании, в которых используется эта же учетная запись.
Токен является уникальным некопируемым физическим объектом. Им обладает легитимный пользователь. Двухфакторную аутентификацию по токену можно обойти только тогда, когда администратор намеренно или по недосмотру оставил для этого «лазейки» в системе.
Преимущества входа в домен по токену
PIN-код от токена проще запомнить, так как он может быть намного проще пароля. Каждый наверняка хоть раз в жизни видел, как «опытный» пользователь мучительно не может с нескольких попыток аутентифицироваться в системе, вспоминая и вводя свой «безопасный» пароль.
PIN-код не обязательно постоянно менять, так как токены более устойчивы к перебору PIN-кодов. После некоторого числа неудачных попыток ввода, токен блокируется.
При использовании токена для пользователя вход в систему выглядит следующим образом: после загрузки компьютера, он просто подключает токен к USB-порту компьютера, вводит 4-6 цифр и нажимает кнопку Enter. Скорость ввода цифр у обычных людей выше, чем скорость ввода букв. Поэтому PIN-код вводится быстрее.
Токены позволяют решить проблему «брошенного рабочего места» - когда пользователь уходит со своего рабочего места и забывает выйти из своей учетной записи.
Политика домена может быть настроена таким образом, чтобы компьютер автоматически блокировался при извлечении токена. Также токен может быть оснащен RFID-меткой для прохода между помещениями компании, поэтому не забрав токен со своего рабочего места, сотрудник просто не сможет перемещаться по территории.
Недостатки, куда же без них
Токены или смарт-карты не бесплатные (решается бюджетом).
Их нужно учитывать, администрировать и обслуживать (решается системами управления токенами и смарт-картами).
Некоторые информационные системы могут «из коробки» не поддерживать аутентификацию по токенам (решается системами типа Single Sign-On - предназначенными для организации возможности использования единой учетной записи для доступа к любым ресурсам области).
Настройка двухфакторной аутентификации в домене Windows
Теоретическая часть:
Служба каталога Active Directory поддерживает возможность аутентификации с помощью смарт-карты и токена, начиная с Windows 2000. Она заложена в расширении PKINIT (public key initialization - инициализация открытого ключа) для протокола Kerberos RFC 4556 .
Протокол Kerberos был специально разработан для того, чтобы обеспечить надежную аутентификацию пользователей. Он может использовать централизованное хранение аутентификационных данных и является основой для построения механизмов Single Sing-On. Протокол основан на ключевой сущности Ticket (билет).
Ticket (билет) является зашифрованным пакетом данных, который выдается доверенным центром аутентификации, в терминах протокола Kerberos - Key Distribution Center (KDC, центр распределения ключей).
Когда пользователь выполняет первичную аутентификацию после успешного подтверждения его подлинности, KDC выдает первичное удостоверение пользователя для доступа к сетевым ресурсам - Ticket Granting Ticket (TGT).
В дальнейшем при обращении к отдельным ресурсам сети, пользователь, предъявляет TGT, получает от KDC удостоверение для доступа к конкретному сетевому ресурсу - Ticket Granting Service (TGS).
Одним из преимуществ протокола Kerberos, обеспечивающим высокий уровень безопасности, является то, что при любых взаимодействиях не передаются ни пароли, ни значения хеша паролей в открытом виде.
Расширение PKINIT позволяет использовать двухфакторную аутентификацию по токенам или смарт-картам на этапе предаутентификации Kerberos.
Вход в систему может быть обеспечен, как при использовании службы каталога домена, так и локальной службы каталога. TGT создается на основе электронной подписи, которая вычисляется на смарт-карте или токене.
Все контроллеры доменов должны иметь установленный сертификат Domain Controller Authentication, или Kerberos Authentication, т. к. реализуется процесс взаимной аутентификации клиента и сервера.
Практика:
Приступим к настройке.
Сделаем так, чтобы в домен под вашей учетной записью можно было зайти только по предъявлению токена и зная PIN-код.
Для демонстрации мы будем использовать Рутокен ЭЦП PKI производства компании «Актив».
1 Этап - Настройка домена Первым делом установим службы сертификации.
Дисклеймер.
Эта статья не является туториалом по внедрению корпоративного PKI. Вопросы проектирования, разворачивания и грамотного применения PKI тут не рассматриваются ввиду необъятности этой темы.
Все контроллеры доменов и все клиентские компьютеры в рамках леса, где осуществляется внедрение такого решения, обязательно должны доверять корневому Удостоверяющему Центру (Центру Сертификации).
Задача центра сертификации - подтверждать подлинность ключей шифрования с помощью сертификатов электронной подписи.
Технически центр сертификации реализован как компонент глобальной службы каталогов, отвечающий за управление криптографическими ключами пользователей. Открытые ключи и другая информация о пользователях хранится удостоверяющими центрами в виде цифровых сертификатов.
Удостоверяющий центр, выдающий сертификаты для использования смарт-карт или токенов, должен быть помещен в хранилище NT Authority.
Зайдите в Диспетчер сервера и выберите «Добавить роли и компоненты».
При добавлении ролей сервера выберите «Службы сертификации Active Directory» (Microsoft категорически рекомендует не делать это на контроллере домена, дабы не огрести проблем с производительностью). В открывшемся окне выберите «Добавить компоненты» и выберите пункт «Центр сертификации».
На странице для подтверждения установки компонентов нажмите «Установить».
2 Этап - Настройка входа в домен с помощью токена
Для входа в систему нам понадобится сертификат, который содержит идентификаторы Smart Card Logon и Client Authentication.
Сертификат для смарт-карт или токенов также должен содержать UPN пользователя (суффикс имени участника-пользователя). По умолчанию суффиксом имени участника-пользователя для учетной записи является DNS-имя домена, которое содержит учетную запись пользователя.
Сертификат и закрытый ключ должны быть помещены в соответствующие разделы смарт-карты или токена, при этом закрытый ключ должен находиться в защищенной области памяти устройства.
В сертификате должен быть указан путь к точке распространения списка отзыва сертификатов (CRL distribution point). Такой файл содержит список сертификатов с указанием серийного номера сертификата, даты отзыва и причины отзыва. Он используется для передачи сведений об отозванных сертификатах пользователям, компьютерам и приложениям, пытающимся проверить подлинность сертификата.
Настроим установленные службы сертификации. В правом верхнем углу нажмите на желтый треугольник с восклицательным знаком и щелкните «Настроить службы сертификации…».
В окне «Учетные данные» выберите необходимые учетные данные пользователя для настройки роли. Выберите «Центр сертификации».
Выберите «ЦС предприятия».
ЦС предприятия интегрированы с AD. Они публикуют сертификаты и списки отзыва сертификатов в AD.
Укажите тип «Корневой ЦС».
На следующем этапе выберите «Создать новый закрытый ключ».
Выберите период действия сертификата.
3 этап - Добавление шаблонов сертификатов
Для добавления шаблонов сертификатов откройте Панель управления, выберите пункт «Администрирование» и откройте Центр сертификации.
Щелкните по названию папки «Шаблоны сертификатов», выберите пункт «Управление».
Щелкните по названию шаблона «Пользователь со смарт-картой» и выберите пункт «Скопировать шаблон». На следующих скриншотах показано, какие параметры в окне «Свойства нового шаблона» необходимо изменить.
Если в списке поставщиков нет «Aktiv ruToken CSP v1.0», то необходимо установить комплект «Драйверы Рутокен для Windows».
Начиная с Windows Server 2008 R2 вместо специального провайдера от производителя можно использовать «Microsoft Base Smart Card Crypto Provider».
Для устройств Рутокен библиотека «минидрайвера», поддерживающая «Microsoft Base Smart Card Crypto Provider», распространяется через Windows Update.
Проверить установился ли «минидрайвер» на вашем сервере можно подключив Рутокен к нему и посмотрев в диспетчер устройств.
Если «минидрайвера» по каким-то причинам нет, его можно установить принудительно, инсталлировав комплект «Драйверы Рутокен для Windows», а после этого воспользоваться «Microsoft Base Smart Card Crypto Provider».
Комплект «Драйверы Рутокен для Windows» распространяется бесплатно с сайта Рутокен .
Добавьте два новых шаблона «Агент сертификации» и «Пользователь с Рутокен».
В окне «Оснастки диспетчера сертификатов» выберите «моей учетной записи пользователя». В окне «Добавление и удаление оснастки» подтвердите добавление сертификатов.
Выберите папку «Сертификаты».
Запросите новый сертификат. Откроется страница для регистрации сертификата. На этапе запроса сертификата выберите политику регистрации «Администратор» и нажмите «Заявка».
Таким же образом запросите сертификат для Агента регистрации.
Чтобы запросить сертификат для определенного пользователя щелкните «Сертификаты», выберите пункт «Зарегистрироваться от имени...».
В окне для запроса сертификата установите флажок «Пользователь с Рутокен».
Теперь необходимо выбрать пользователя.
В поле «Введите имена выбранных объектов» укажите имя пользователя в домене и нажмите «Проверить имя».
В окне для выбора пользователя нажмите «Заявка».
В раскрывающемся списке выберите имя токена и укажите PIN-код.
Таким же образом выберите сертификаты для других пользователей в домене.
4 этап - Настройка учетных записей пользователей
Для настройки учетных записей откройте список пользователей и компьютеров AD.
Выберите папку Users и пункт «Свойства».
Перейдите на вкладку «Учетные записи», установите флажок «Для интерактивного входа в сеть нужна смарт-карта».
Настройте политики безопасности. Для этого откройте Панель управления и выберите пункт «Администрирование». Откройте меню для управления групповой политикой.
В левой части окна «Управление групповой политикой» щелкните «Default Domain Policy» и выберите пункт «Изменить».
В левой части окна «Редактор управления групповыми политиками» выберите пункт «Параметры безопасности».
Откройте политику «Интерактивный вход в систему: требовать смарт-карту».
На вкладке «Параметры политики безопасности» установите флажки «Определить следующий параметр политики» и «Включен».
Откройте политику «Интерактивный вход в систему: поведение при извлечении смарт-карты».
На вкладке «Параметры политики безопасности» установите флажок «Определить следующий параметр политики», из раскрывающегося списка выберите «Блокировка рабочей станции».
Перезагрузите компьютер. И при следующей попытке аутентификации в домене уже можно будет использовать токен и его PIN-код.
Двухфакторная аутентификация для входа в домен настроена, а значит существенно повышен уровень безопасность для входа в Windows домен без траты безумной суммы на дополнительные средства защиты. Теперь без токена вход в систему невозможен, а пользователи могут вздохнуть спокойно и не мучиться со сложными паролями.
Следующий шаг - безопасная почта, об этом и о настройке безопасной аутентификации в других системах читайте в наших следующих статьях.
Теги:
- windows server
- PKI
- Рутокен
- аутентификация
4 ответов
Я бы сказал, что это сильно зависит от того, что будет делать ваше веб-приложение, поскольку у каждого есть свое место. Ниже приведены краткие сведения о каждом из них.
Аутентификация Windows позволяет идентифицировать пользователей без создания настраиваемой страницы. Учетные данные хранятся в локальной базе данных веб-сервера или в домене Active Directory. После идентификации вы можете использовать учетные данные пользователя для получения доступа к ресурсам, которые защищены авторизацией Windows.
Аутентификация форм позволяет идентифицировать пользователей с пользовательской базой данных, такой как база данных членства ASP.NET. В качестве альтернативы вы можете реализовать свою собственную базу данных. После аутентификации вы можете ссылаться на роли, которые пользователь должен ограничить доступом к частям вашего веб-сайта.
Аутентификация паспорта основана на централизованном сервисе, предоставляемом Microsoft. Аутентификация паспорта идентифицирует пользователя с использованием его или ее адреса электронной почты и пароля, а одна учетная запись Passport может использоваться со многими различными веб-сайтами. Аутентификация паспорта в основном используется для общедоступных веб-сайтов с тысячами пользователей.
Анонимная проверка подлинности не требует от пользователя предоставления учетных данных.
Ситуация, когда вы можете использовать что:
Аутентификация Windows: . Поскольку вы будете использовать логин и пароль, используемые в домене... Если вы используете проверку подлинности Windows, ваш webapp (как правило) должен быть развернут на сетевом сервере и все ваши пользователи должны (как правило) иметь свой логин, созданный для них в домене. Хотя возможны операции с кросс-доменами, в первую очередь вы не сможете использовать их в среде, не связанной с доменом, например, на общедоступных веб-сайтах. Это будет сложно, если вы хотите включить некоторых пользователей, которые находятся за пределами вашего домена.
Аутентификация форм: . Здесь вы решаете действовать независимо. Вы назначаете каждому пользователю отдельный userId и пароль и будете управлять ими самостоятельно. Накладные расходы здесь - вы должны предоставить и ограничить способы создания и удаления пользователей. Здесь вы не ограничены ни одним доменом. Для того, чтобы любой пользователь мог получить доступ к вашему webapp, вы должны зарегистрироваться на своем веб-сайте. Это похоже на любые почтовые сайты, которые вы видите в Интернете.
Аутентификация паспортов: . В зависимости от MS вы можете проверить своих пользователей. Это даст вам глобальный статус для вашего приложения, но если вы собираетесь развернуть его только для небольшой группы пользователей, вы будете вынуждать их создавать учетную запись паспорта (если у нее ее нет), чтобы они могли получить доступ ваше приложение.
Аутентификация Windows: поскольку вы будете использовать логин и пароль, используемые в домене... Если вы используете проверку подлинности Windows, ваш webapp (обычно) должен быть развернут на сетевом сервере, и все ваши пользователи должны (как правило) у вас есть логин, созданный для них в домене. Хотя возможны операции с кросс-доменами, в первую очередь вы не сможете использовать их в среде, не связанной с доменом, например, на общедоступных веб-сайтах. Это будет сложно, если вы хотите включить некоторых пользователей, которые находятся за пределами вашего домена.
Аутентификация форм: здесь вы решаете действовать независимо. Вы назначаете каждому пользователю отдельный userId и пароль и будете управлять ими самостоятельно. Накладные расходы здесь - вы должны предоставить и ограничить способы создания и удаления пользователей. Здесь вы не ограничены ни одним доменом. Для того, чтобы любой пользователь мог получить доступ к вашему webapp, вы должны зарегистрироваться на своем веб-сайте. Это похоже на любые почтовые сайты, которые вы видите в Интернете.
Аутентификация паспорта. В зависимости от MS вы проверяете своих пользователей. Это даст вам глобальный статус для вашего приложения, но если вы собираетесь развернуть его только для небольшой группы пользователей, вы будете вынуждать их создавать учетную запись паспорта (если у нее ее нет), чтобы они могли получить доступ ваше приложение.
Чтобы сделать его более понятным.. Какой бы метод вы ни следовали, вы все равно можете ограничить, кто может получить доступ к вашему webapp, а также определить собственные роли для каждого пользователя.
Конфигурация Windows для автоматического входа (без ввода пароля) достаточна проста, но не безопасна. Используйте приведённую ниже инструкцию только в том случае, если ваш ПК действительно персональный, либо наоборот служит «проходным двором» всем домочадцам, все знают этот пароль и ежедневный ввод оного вводит их в тоску. Не отключайте ввод пароля, если это офисный компьютер, планшет, который может быть утерян, или компьютер, содержащий конфиденциальные данные.
И так, если вы единственный пользователь вашего ПК, то авторизация без пароля не только сэкономит время при старте системы, но и позволит использовать сложный пароль для вашего аккаунта, если вы используете рекомендованный Microsoft тип авторизации с использованием Microsoft Account (Windows ID). На данный аккаунт, как правило, куплена подписка Office 365 и прочий софт из Windows Store, почта Outlook.com содержит переписку, в OneDrive хранятся документы и всё это доступно по паролю, используемому при входе в учётную запись ПК. Лично я не в состоянии держать в голове сложный пароль типа “fSJKk05#_j8=!3fHT” и при этом каждое утро вбивать его при включении ПК. Таким образом обязательный ввод пароля при старте ПК практически провоцирует пользователя на использование примитивных паролей, которые легко подобрать.
Если вы уверены в том, что действительно хотите использовать авторизацию без пароля, то следуйте приведённой ниже инструкции, и Windows больше не будет спрашивать пароль при загрузке.
Нажмите кнопку «Пуск» или кнопку «Windows» на клавиатуре для входа в Modern UI (Metro в Windows 8) и наберите «Run» («Выполнить» для русскоязычного интерфейса), запустите утилиту и в командную строку забейте «netplwiz» (без кавычек), после чего нажмите «ОК». Или откройте командную строку через «Пуск» и в неё забейте «netplwiz». В любом случае откроется окно «Учётные записи пользователей». Технически программа называется «Advanced User Accounts Control Panel
», но она не является частью Контрольной Панели и в ней вы её не найдёте.
Во вкладке «Пользователи» выберите вашу учётную запись, выше снимите галку с чекбокса «пользователи должны ввести логин и пароль для использования этого компьютера». И нажмите «Применить». Откроется ещё одно окно и в нём следует указать свои логин и пароль, чтоб применить изменения.
Важно: Если для авторизации вы используете Microsoft Account (Windows ID), то в качестве «имени пользователя» следует указать адрес вашей электронной почты, так как именно он является логином, а не ваше имя, указанное в этой строке по умолчанию.
После этого закройте все окна и перезагрузите компьютер. Учётная запись должна загрузиться без ввода пароля.
Если вместо этого у вас пытается загрузиться какая-то левая учётная запись типа «другой пользователь», а при предыдущих манипуляциях с аккаунтом в окне «Учётные записи пользователей» было два пользователя с одинаковым логином (один с правами администратора, второй – обычный пользователь), как у меня (см. скриншот), то убедитесь, что обоим им разрешён вход без пароля. Примените изменения к обеим учётным записям. Как правило, по умолчанию загружается учётная запись с правами обычного пользователя. Соответственно, её и следует выделить перед тем, как снимать галку с чекбокса.
Если всё сделано правильно, то при последующих загрузках ПК, экран с учётной записью отобразиться, но вход будет выполнен автоматически.
Задайте эту аутентификацию при использовании контроллера домена Windows для аутентификации пользователей, у которых есть учетные записи на сервере каталогов. Пользователи не могут быть аутентифицированы, если у них нет учетных записей на сервере каталогов. При аутентификации Windows можно указать границы доступа для каждой группы, зарегистрированной на сервере каталогов. Адресная книга, сохраненная непосредственно на сервере, может быть зарегистрирована на аппарате, позволяя пользователям выполнять аутентификацию без использования аппарата для регистрации индивидуальных настроек в адресной книге. Получение информации о пользователе может предотвратить использование недействительных учетных данных, поскольку системой аутентификации определяется адрес отправителя в поле (От:) при отправке отсканированных данных или полученных факсимильных сообщений по электронной почте.
При первом доступе к аппарату можно использовать функции, разрешенные для вашей группы. Если регистрация в группе не выполнена, можно использовать функции, указанные в пункте "*Группа по умолчанию". Для ограничения доступа пользователей к определенным функциям необходимо выполнить предварительные настройки в адресной книге.
Для автоматической регистрации данных о пользователях, например, номера факса и адреса электронной почты, при выполнении аутентификации Windows рекомендуется шифровать связь между устройством и контроллером доменов с помощью SSL. Для этого необходимо создать сертификат сервера для контроллера домена. Для получения подробных сведений о создании сертификата сервера см. Создание сертификата серверов .
Аутентификация Windows может быть выполнена одним из двух методов: аутентификация NTLM или Kerberos. Ниже приводятся технические требования для обоих методов:
Эксплуатационные требования для аутентификации NTLM
Для определения аутентификации NTLM должны выполняться следующие требования:
Windows Server 2003/2003 R2
Windows Server 2008/2008 R2
Windows Server 2012
Этот аппарат должен поддерживать аутентификацию NTLMv1 и NTLMv2.
Эта функция должна поддерживаться нижеперечисленными операционными системами. Чтобы получить данные пользователя при работе с активным каталогом, используйте LDAP. При использовании LDAP рекомендуется зашифровать соединение между аппаратом и LDAP сервером с помощью SSL. Шифрование SSL возможно только в том случае, если сервер LDAP поддерживает TLSv1 или SSLv3.
Эксплуатационные требования для аутентификации Kerberos
Для определения аутентификации Kerberos должны быть выполнены следующие требования:
Windows Server 2003/2003 R2
Windows Server 2008/2008 R2
Windows Server 2012
Настройте контроллер домена в нужном домене.
Операционная система должна поддерживать KDC (Key Distribution Center). Чтобы получить данные пользователя при работе с активным каталогом, используйте LDAP. При использовании LDAP рекомендуется зашифровать соединение между аппаратом и LDAP сервером с помощью SSL. Шифрование SSL возможно только в том случае, если сервер LDAP поддерживает TLSv1 или SSLv3. Ниже перечислены совместимые операционные системы.
Чтобы использовать аутентификацию Kerberos при работе с ОС Windows Server 2008, установите Service Pack 2 (SP 2) и выше.
Если включена аутентификация Kerberos, данные, передаваемые между аппаратом и сервером KDC, шифруются. Для получения сведений об установке шифрования передаваемых данных см. Настройка шифрования для аутентификации Kerberos .
Во время аутентификации Windows данные, зарегистрированные на сервере каталога, такие как адрес электронной почты пользователя, автоматически регистрируются в аппарате. Если данные пользователя на сервере изменяются, то при выполнении аутентификации данные, зарегистрированные в аппарате, могут быть стерты.
Пользователи, управляемые в других доменах, зависят от аутентификации пользователя, но они не могут получать элементы данных, такие как адреса электронной почты.
Если одновременно устанавливается аутентификация Kerberos и шифрование SSL, то получение электронной почты становится невозможным.
Если создана новая учетная запись пользователя в контроллере домена, а для конфигурации пароля выбран вариант "Пользователь должен сменить пароль при следующем входе в систему", в первую очередь войдите в систему компьютера и смените пароль.
Если при выборе на аппарате идентификации Kerberos аутентифицирующий сервер поддерживает только NTLM, метод аутентификации автоматически переключается на NTLM.
Если используется аутентификация Windows, в имени учетной записи различаются заглавные и строчные буквы. Неправильно введенное имя для входа будет добавлено в адресную книгу. В этом случае удалите добавленного пользователя.
Если на сервере Windows включена учетная запись "Guest" (Гость), то могут быть аутентифицированы даже пользователи, не зарегистрированные в контроллере домена. При включении этой учетной записи пользователи регистрируются в адресной книге и могут использовать функции, доступные в группе "*Группа по умолчанию".
Для получения сведений о символах, которые можно использовать при указании имени пользователя и пароля, см. Символы, которые можно использовать при вводе имени пользователя и пароля .
При последующем доступе к аппарату вы можете пользоваться всеми функциями, доступными для вашей группы и для вас как для отдельного пользователя.
Пользователи, зарегистрированные в нескольких группах, могут использовать все функции, доступные этим группам.
При выполнении аутентификации Windows нет необходимости создавать сертификат сервера, если не требуется автоматическая регистрация данных пользователей, таких как номера факса и адреса электронной почты, с помощью SSL.
Если во время аутентификации не удалось получить сведения о факсе, см.
