Какие методы аутентификации подсоединяемого компьютера предлагаются в windows 7

Аутентификация и авторизация

В операционной системе Windows 7 реализовано новое поколение технологий безопасности для рабочего стола и одна из них аутентификация и авторизация. Часть технологий направлена на укрепление общей инфраструктуры Windows, а остальные на оказание помощи в управлении системой и пользовательскими данными.

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

Что такое аутентификация и авторизация?

Аутентификация — это процесс, используемый для подтверждения личности пользователя, при обращении его к компьютерной системе или дополнительным системным ресурсам. В частных и государственных компьютерных сетях (включая Интернет) наиболее часто для аутентификации предполагается проверка учетных данных пользователя; то есть, имя пользователя и пароль. Однако для типов критических транзакций, например обработка платежей, проверки подлинности имени пользователя и пароля не достаточно, так как пароли могут быть украдены или взломаны. По этой причине, основная часть интернет-бизнеса, а также многие другие сделки теперь используют цифровые сертификаты, которые выдаются и проверяются центром сертификации.

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

Есть два варианта авторизации:

• Изменения системных ресурсов первоначально разрешены системным администратором.
• При попытке пользователя получить доступ или обновить системный ресурс разрешение на действие оценивается системой или приложением.

Последний вариант позволяет пользователю получить доступ без аутентификации и авторизации. Он используется в случае, когда требуется предоставить доступ для анонимных не проходящих аутентификацию пользователей. Такой доступ, как правило, весьма ограничен.

Процесс авторизации и аутентификации.

Для получения доступа к файлам в сети пользователи для проверки их личности должны проходить аутентификацию. Это делается во время процесса входа в сеть. Операционная система Windows 7 для входа в сеть имеет следующие методы аутентификации:

• Протокол Kerberos версии 5: Основной метод аутентификации клиентов и серверов под управлением операционных систем Microsoft Windows. Он используется для проверки подлинности учетных записей пользователей и учетных записей компьютеров.
• Windows NT LAN Manager (NTLM): используется для обратной совместимости с операционными системами более старыми, чем Windows 2000 и некоторых приложений. Он менее гибок, эффективен и безопасен, чем протокол Kerberos версии 5.
• Сопоставление сертификатов: обычно используется для проверки подлинности при входе в сочетании со смарт-картой. Сертификат, записанный на смарт-карте, связан с учетной записью пользователя. Для чтения смарт-карт и аутентификации пользователя используется считыватель смарт-карт.

Новые функции аутентификации в Windows 7.

Целый ряд улучшений, связанных с процессами входа и проверки подлинности пользователя был добавлен еще в Windows Vista ®. Эти усовершенствования увеличили базовый набор функции проверки подлинности, чтобы помогло обеспечить лучшую безопасность и управляемость. В Windows 7 Microsoft продолжает начатые в Windows Vista усовершенствования, предоставляя следующие новые функции аутентификации:

• Смарт-карты
• Биометрия
• Интеграция личности в Интернете.

Смарт-карты.

Использование смарт-карт самый распространенный метод аутентификации. Для поощрения применения организациями и пользователями смарт-карт, Windows 7 предлагает новые возможности, облегчающие их использование и развертывание. Эти новые возможности позволяют использовать смарт-карты для выполнения разнообразных задач, включая:

• Смарт-карты Plug and Play
• Личные удостоверения проверки (PIV), стандарт национального института стандартов и технологий США (NIST)
• Поддержка для входа смарт-карты Kerberos.
• Шифрование дисков  BitLocker
• Документы и электронная почта
• Использование с бизнес-приложениями.

Биометрия.

Биометрия — все более популярная технология, обеспечивающая удобный доступ к системам, услугам и ресурсам. Биометрия для однозначного определения человека использует измерение его неизменных физических характеристик. Одна из наиболее часто используемых биометрических характеристик — отпечатки пальцев.

До сих пор в Windows не было стандартной поддержки биометрических устройств. Чтобы решить эту проблему, Windows 7 вводит Windows Biometric Framework (WBF). WBF предоставляет новый набор компонентов, поддерживающий снятие отпечатка пальца с помощью биометрические устройства. Эти компоненты увеличивают безопасность пользователей.

Windows Biometric Framework упрощает пользователям и администраторам настройку и управление биометрическими устройствами на локальном компьютере или в домене.

Интеграция личности в Интернете.

Управление аккаунтом — стратегия обеспечения безопасности. Для разрешения или запрета проверки подлинности определенных компьютеров или всех компьютеров, которыми вы управляете онлайн, используется Групповая политика.

В Windows 7 пользователи в небольшой сети могут выбрать обмен данными между определенными компьютерам на отдельной пользовательской основе. Эта функция в Windows 7 дополняет функцию домашней группы с помощью сетевых удостоверений для идентификации лиц в сети.

Для того, чтобы разрешить эту идентификацию пользователи должны связать свою учетную запись пользователя Windows ID онлайн. Включение в Windows протокола Public Key Cryptography Based User-to-User (PKU2U) разрешает проходить идентификацию при помощи свидетельств.

Интеграцией онлайн идентификации можно управлять политикой группы. Политика, настроенная как: “Сетевая безопасность: Позволить этому компьютеру при запросе идентификации PKU2U использовать ID онлайн”, управляет возможностью ID онлайн подтвердить подлинность этого компьютера при помощи протокола PKU2U. Этот параметр политики не влияет на способность учетных записей доменов или локальных учетных записей пользователей входить на этот компьютер.

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

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

Для начала внесем ясность в термины. Многие путают понятия аутентификации и авторизации, хотя это различные процедуры.

• Аутентификация — происходит от английского слова authentication, которое можно перевести как идентификация или проверка подлинности. Это полностью отражает суть процесса — проверка подлинности пользователя, т.е. мы должны удостовериться, что пользователь, пытающийся получить доступ к системе именно тот, за кого себя выдает.
• Авторизация — перевод слова authorization означает разрешение, т.е. проверка прав доступа к какому-либо объекту. Процесс авторизации может быть применен только к аутентифицированному пользователю, так как перед тем, как проверять права доступа, мы должны выяснить личность объекта, которому мы собираемся предоставить какие-либо права.

Чтобы проще представить себе этот процесс проведем простую аналогию. Вы находитесь за границей и вас останавливает полицейский, вы предъявляете свой паспорт. Полицейский проверяет данные в паспорте и сверяет фотографию — это процесс аутентификации. Убедившись, что вы это вы, полицейский просит показать визу — это процесс авторизации, т.е. вашего права здесь находиться.

Точно также, сотрудник полиции, остановив трудового мигранта и проверив его паспорт, просит разрешение на работу, если разрешения нет, то зарубежный гость успешно прошел аутентификацию, но провалил авторизацию. Если аутентификация не пройдена, то до авторизации дело не дойдет.

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

Локальная аутентификация

Прежде всего начнем с локальной аутентификации, когда пользователь хочет войти непосредственно на рабочую станцию, не входящую в домен. Что происходит после того, как пользователь ввел свой логин и пароль? Сразу после этого введенные данные передаются подсистеме локальной безопасности (LSA), которая сразу преобразует пароль в хэш, хэширование — это одностороннее криптографическое преобразование, делающее восстановление исходной последовательности невозможным. В открытом виде пароль нигде в системе не хранится и не фигурирует, пользователь — единственный кто его знает.

Затем служба LSA обращается к диспетчеру учетных записей безопасности (SAM) и сообщает ему имя пользователя. Диспетчер обращается в базу SAM и извлекает оттуда хэш пароля указанного пользователя, сгенерированный при создании учетной записи (или в процессе смены пароля).

Затем LSA сравнивает хэш введенного пароля и хэш из базы SAM, в случае их совпадения аутентификация считается успешной, а хэш введенного пароля помещается в хранилище службы LSA и находится там до окончания сеанса пользователя.

В случае входа пользователя в домен, для аутентификации используются иные механизмы, прежде всего протокол Kerberos, однако, если одна из сторон не может его использовать, по согласованию могут быть использованы протоколы NTLM и даже устаревший LM. Работу этих протоколов мы будем рассматривать ниже.

LAN Manager (LM)

Протокол LAN Manager возник на заре зарождения локальных сетей под управлением Windows и впервые был представлен в Windows 3.11 для рабочих групп, откуда перекочевал в семейство Windows 9.х. Мы не будем рассматривать этот протокол, так как в естественной среде он уже давно не встречается, однако его поддержка, в целях совместимости, присутствует до сих пор. И если современной системе поступит запрос на аутентификацию по протоколу LM, то, при наличии соответствующих разрешений, он будет обработан.

Что в этом плохого? Попробуем разобраться. Прежде всего разберемся, каким образом создается хэш пароля для работы с протоколом LM, не вдаваясь в подробности обратим ваше внимание на основные ограничения:

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

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

А теперь самое интересное, LM-хэш, в целях совместимости, создается при вводе пароля и хранится в системах по Windows XP включительно. Это делает возможной атаку, когда системе целенаправленно присылают LM-запрос и она его обрабатывает. Избежать создания LM-хэша можно изменив политику безопасности или используя пароли длиннее 14 символов. В системах, начиная с Windows Vista и Server 2008, LM-хэш по умолчанию не создается.

NT LAN Manager (NTLM)

Новый протокол аутентификации появился в Windows NT и благополучно, с некоторыми изменениями, дожил до наших дней. А до появления Kerberos в Windows 2000 был единственным протоколом аутентификации в домене NT.

Сегодня протокол NTLM, точнее его более современная версия NTLMv2, применяются для аутентификации компьютеров рабочих групп, в доменных сетях Active Directory по умолчанию применяется Kerberos, однако если одна из сторон не может применить этот протокол, то по согласованию могут быть использованы NTLMv2, NTLM и даже LM.

Принцип работы NTLM имеет много общего с LM и эти протоколы обратно совместимы, но есть и существенные отличия. NT-хэш формируется на основе пароля длиной до 128 символов по алгоритму MD4, пароль регистрозависимый и может содержать не только ACSII символы, но и Unicode, что существенно повышает его стойкость по сравнению с LM.

Как происходит работа по протоколу NTLM? Рассмотрим следующую схему:

Допустим локальный компьютер хочет получить доступ к некоторому файловому ресурсу на другом ПК, который мы будем считать сервером, при этом совсем не обязательно наличие на этом ПК северной ОС или серверных ролей. С точки зрения протокола NTLM клиент это тот, кто обращается, сервер — к кому обращаются.

Чтобы получить доступ к ресурсу клиент направляет серверу запрос с именем пользователя. В ответ сервер передает ему случайное число, называемое запросом сервера. Клиент в свою очередь шифрует данный запрос по алгоритму DES, используя в качестве ключа NT-хэш пароля, однако, несмотря на то, что NT-хэш 128-битный, в силу технических ограничений используется 40 или 56 битный ключ (хеш делится на три части и каждая часть шифрует запрос сервера отдельно).

Зашифрованный хэшем пароля запрос сервера называется ответом NTLM и передается обратно серверу, сервер извлекает из хранилища SAM хэш пароля того пользователя, чье имя было ему передано и выполняет аналогичные действия с запросом сервера, после чего сравнивает полученный результат с ответом NTLM. Если результаты совпадают, значит пользователь клиента действительно тот, за кого себя выдает, и аутентификация считается успешной.

В случае доменной аутентификации процесс протекает несколько иначе. В отличие от локальных пользователей, хэши паролей которых хранятся в локальных базах SAM, хэши паролей доменных пользователей хранятся на контроллерах доменов. При входе в систему LSA отправляет доступному контроллеру домена запрос с указанием имени пользователя и имени домена и дальнейший процесс происходит как показано выше.

В случае получения доступа к третьим ресурсам схема также немного изменяется:

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

Как видим, хэш пароля ни при каких обстоятельствах по сети не передается. Хэш введенного пароля хранит служба LSA, хэши паролей пользователей хранятся либо в локальных хранилищах SAM, либо в хранилищах контроллера домена.

Но несмотря на это, протокол NTLM на сегодняшний день считаться защищенным не может. Слабое шифрование делает возможным достаточно быстро восстановить хэш пароля, а если использовался не только NTLM, а еще и LM-ответ, то и восстановить пароль.

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

NTLMv2

Осознавая, что протокол NTLM не соответствует современным требованиям безопасности, с выходом Windows 2000 Microsoft представила вторую версию протокола NTLMv2, который был серьезно доработан в плане улучшений криптографической стойкости и противодействия распространенным типам атак. Начиная с Windows 7 / Server 2008 R2 использование протоколов NTLM и LM по умолчанию выключено.

Сразу рассмотрим схему с контроллером домена, в случае его отсутствия схема взаимодействия не меняется, только вычисления, производимые контроллером домена, выполняются непосредственно на сервере.

Как и в NTLM, клиент при обращении к серверу сообщает ему имя пользователя и имя домена, в ответ сервер передает ему случайное число — запрос сервера. В ответ клиент генерирует также случайное число, куда, кроме прочего, добавляется метка времени, которое называется запрос клиента. Наличие метки времени позволяет избежать ситуации, когда атакующий первоначально накапливает перехваченные данные, а потом с их помощью осуществляет атаку.

Запрос сервера объединяется с запросом клиента и от этой последовательности вычисляется HMAC-MD5 хэш. После чего от данного хэша берется еще один HMAC-MD5 хэш, ключом в котором выступает NT-хэш пароля пользователя. Получившийся результат называется NTLMv2-ответом и вместе с запросом клиента пересылается серверу.

Криптостойкость данного алгоритма является актуальной и на сегодняшний день, известно только два случая взлома данного хэша, один из них произведен компанией Symantec в исследовательских целях. Можно с уверенностью сказать, что в настоящий момент нет массовых инструментов для атак на NTLMv2, в отличие от NTLM, взломать который может любой вдумчиво прочитавший инструкцию школьник.

Сервер, получив NTLMv2-ответ и запрос клиента, объединяет последний с запросом сервера и также вычисляет HMAC-MD5 хэш, затем передает его вместе с ответом контроллеру домена. Тот извлекает из хранилища сохраненный хэш пароля пользователя и производит вычисления над HMAC-MD5 хешем запросов сервера и клиента, сравнивая получившийся результат с переданным ему NTLMv2-ответом. В случае совпадения серверу возвращается ответ об успешной аутентификации.

При этом, как вы могли заметить, NTLMv2, также, как и его предшественник, не осуществляет взаимную проверку подлинности, хотя в некоторых материалах в сети это указывается.

Настройки безопасности

Теперь, когда вы имеете представление о работе протоколов аутентификации самое время поговорить о настройках безопасности. NTLMv2 вполне безопасный протокол, но если система настроена неправильно, то злоумышленник может послать NTLM или LM запрос и получить соответствующий ответ, который позволит успешно осуществить атаку.

За выбор протокола аутентификации отвечает локальная или групповая политика. Откроем редактор политик и перейдем в Конфигурация компьютера — Конфигурация Windows — Политики безопасности — Локальные политики — Параметры безопасности, в этом разделе найдем политику Сетевая безопасность: уровень проверки подлинности LAN Manager.

В этом же разделе находится политика Сетевая безопасность: не хранить хэш-значения LAN Manager при следующей смене пароля, которая запрещает создание LM-хэша, по умолчанию активна начиная с Vista / Server 2008.

В нашей же политике мы видим широкий выбор значений, очевидно, что сегодня безопасными могут считаться политики начиная с Отправлять только NTLMv2-ответ и ниже по списку.

Эти же значения можно задать через реестр, что удобно в сетях уровня рабочей группы, для этого в разделе HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLsa нужно создать параметр DWORD с именем LmCompatibilityLevel, который может принимать значения от 0 до 5. Рассмотрим их подробнее:

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

После того, как клиент пройдет аутентификацию формируется ключ сеанса, который используется для подтверждения подлинности при дальнейшем взаимодействии. Ключ сеанса NTLM основан только на NT-хэше и будет одинаковым до тех пор, пока клиент не поменяет пароль пользователя. Какие угрозы безопасности это несет пояснять, нам кажется, не надо. Сеансовая безопасность NTLMv2 подразумевает вычисление ключа сеанса с использованием не только NT-хэша, но и запросов сервера и клиента, что делает ключ уникальным и гораздо более стойким к возможным атакам. При этом данная возможность может быть использована совместно с NTLM или LM аутентификацией.

Мы надеемся, что данный материал поможет вам глубже понять процессы аутентификации в системах Windows. В следующей части мы подробно остановимся на устройстве и работе протокола Kerberos.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Разработчики Microsoft впервые реализовали протокол Kerberos в системе Windows 2000. Протокол NTLM вошел в употребление гораздо раньше, во времена Windows NT. Kerberos представляет собой протокол аутентификации, базирующийся на концепции доверенной третьей стороны trusted third party (TTP), тогда как в основу протокола NTLM положен механизм «запрос-ответ» (challenge/response). Более подробно различия между двумя протоколами описаны в таблице.

При обмене данными в ходе аутентификации с использованием протокола NTLM серверный ресурс (например, файл-сервер) генерирует запрос, который направляется клиенту. Клиент формирует NTLM-ответ, включающий хеш пароля пользователя, а сервер проверяет правильность этого ответа. Если клиент использует локальную учетную запись, сервер проверяет ответ пользователя с помощью хеша пароля пользователя, который хранится в локальной базе данных диспетчера учетных записей безопасности Security Account Manager (SAM). Если же клиент применяет доменную учетную запись, сервер передает ответ для проверки контроллеру домена, ибо только контроллеры доменов хранят в своих базах данных Active Directory (AD) копии хешей пользовательских паролей.

В системе Windows Kerberos доверенной третьей стороной является контроллер домена Windows 2000 или более поздней версии, на котором размещается служба центра распространения ключей Kerberos Key Distribution Center (KDC). Центр KDC облегчает процедуру аутентификации между оснащенным средствами Kerberos клиентом и сервером. Служба KDC автоматически устанавливается как компонент системы AD и состоит из двух подсистем: службы аутентификации Authentication Service (AS) и службы предоставления билетов Ticket-Granting Service (TGS).

Когда пользователь регистрируется в домене Windows с использованием протокола Kerberos, клиент Windows первым делом проверяет подлинность пользователя на контроллере домена с помощью пользовательского пароля. В то же время клиент запрашивает билет на выдачу билета Ticket Grant Ticket (TGT) в службу аутентификации. TGT можно рассматривать как временный пароль (по умолчанию время его жизни составляет 8 часов), который будет заменять пароль пользователя в последующих запросах на аутентификацию. Когда пользователю нужно будет обратиться к серверному ресурсу, клиент представит TGT на выдачу TGT для проверки подлинности на серверном ресурсе. Имейте в виду, что, в отличие от NTLM, протокол Kerberos не используется для локальной аутентификации в диспетчере учетных записей безопасности Windows; его сфера применения ограничивается доменной аутентификацией на контроллере домена.

Kerberos — стандартный протокол аутентификации в системе Windows 2000 и в более новых версиях Microsoft. В этих операционных системах протокол аутентификации определяется с использованием механизма согласования. Если предлагаемый по умолчанию протокол Kerberos не подходит или не поддерживается одним из клиентских либо серверных компонентов, принимающих участие в аутентификации, Windows переходит на использование NTLM.

Почему Kerberos?

Kerberos более эффективен, нежели NTLM, и тому есть несколько причин. При использовании протокола Kerberos хеш пользовательского пароля экспонируется намного реже, чем в случае применения NTLM. Хеш пароля экспонируется только в том случае, когда пользователь запрашивает TGT — в сущности, один раз каждые восемь часов. С другой стороны, в случае применения NTLM хеш пароля экспонируется всякий раз, когда клиент использует NTLM для аутентификации на сервере. В этом состоит важное преимущество протокола Kerberos перед протоколом NTLM; дело в том, что существуют специальные инструменты, проверяющие сетевой трафик на наличие хешей паролей. Эти инструменты захватывают обнаруженные хеши и методом подбора восстанавливают на их основе пароли пользователей.

Еще одно достоинство Kerberos состоит в том, что этот протокол предусматривает использование отметок времени для защиты от атак с повторной передачей пакетов. Вот почему так важно наличие службы синхронизации времени, безупречно функционирующей в Kerberos-центрической среде Windows. В Windows 2000 и более новых версиях системы службы времени работают без предварительной настройки. Если компьютерные часы на разных компьютерах не синхронизированы, это может обернуться дополнительным трафиком в процессе аутентификации по стандарту Kerberos или же — в худшем случае — такая ситуация может вызвать ошибку в процессе аутентификации.

В дополнение к сказанному протокол Kerberos реализует такие усовершенствованные функции аутентификации, как взаимная аутентификация и делегирование аутентификации. Взаимная аутентификация означает, что пользователь и служба проверяют подлинность друг друга, тогда как возможности NTLM ограничиваются проверкой подлинности пользователя. Без этой функции могут возникать ситуации, когда пользователи предоставляют свои учетные данные фиктивному серверу.

Служба может обращаться к удаленным ресурсам от имени пользователя с помощью механизма делегирования аутентификации. Иными словами, пользователь может предоставлять системе-посреднику право подтвердить от своего имени свою (пользователя) подлинность на сервере приложений. В результате сервер приложений получает возможность принимать решения по авторизации не на базе идентичности системы-посредника, а основываясь на идентичности пользователя. Функция делегирования проверки подлинности весьма полезна в многоуровневых приложениях, таких как доступ к базам данных с помощью внешнего интерфейса на базе Web.

Наконец, надо сказать, что, хотя специалисты Microsoft проделали большую работу по модернизации протокола NTLM, а именно создали версию NTLMv2, которая поддерживается в среде NT4 SP4 и более новых версиях, в продукте Microsoft Kerberos реализовано большее число современных алгоритмов шифрования. Я расскажу об этом подробнее в разделе, посвященном средствам шифрования протокола Kerberos

Ограничения протокола NTLM

Преимущества аутентификации средствами протокола Kerberos сомнения не вызывают. Но даже в среде AD Server 2008 Windows часто использует протокол NTLM, например, когда вы подключаетесь к системе Windows, выпущенной до появления Windows 2000, или при подключении к общедоступному ресурсу с помощью команды net use и IP-адреса (а не имени NetBIOS). Кроме того, приложения, у которых имена участников службы service principal names (SPN) не настроены должным образом, будут по-прежнему использовать протокол NTLM.

Чтобы узнать, каким протоколом — NTLM или Kerberos — вы пользуетесь в данный момент, можете визуализировать трафик NTLM с помощью утилиты netmon или другого трассировщика сети; альтернативный вариант — проверить содержимое кэша билетов Kerberos с помощью инструмента klist (который входит в комплекты поставки Windows 7 и Server 2008). В системах Windows 7 и Server 2008 специалисты Microsoft реализовали новые групповые политики, с помощью которых можно отслеживать, а также блокировать использование протокола NTLM вашими пользователями и приложениями. Всего таких политик три: одна для входящего трафика NTLM (для отслеживания и блокировки на уровне сервера), другая для исходящего трафика NTLM (для отслеживания и блокировки на уровне клиента) и третья для доменного трафика (для отслеживания и блокировки на уровне контроллера домена). Они размещаются в контейнере Security Options Group Policy Object (CPO), попасть в который можно, последовательно выбирая пункты Computer Configuration, Windows Settings, Security Settings, Local Policies (см. экран 1). Все они начинаются с элемента Network security: Restrict NTLM:.

Каждая настройка политики имеет параметры audit и block. Когда вы включаете функцию аудита NTLM, программа создает записи журнала событий с исходными данными NTLM и числами 8001, 8002, 8003 и 8004. Журнальные записи хранятся в контейнере Operational с путем доступа Event Viewer (Local), Applications And Services Logs, Microsoft, Windows, NTLM. Я рекомендую для начала провести аудит NTLM в тестовой среде и позаботиться о том, чтобы там были должным образом представлены все ваши приложения. Если начать произвольно блокировать использование протокола, скорее всего, некоторые приложения функционировать не будут. Чтобы не допустить потери событий, следует перед началом тестирования средств аудита NTLM установить решение для сбора событий аудита; можете воспользоваться встроенной службой Windows Event Collector, средствами Event Subscriptions или решением от независимого поставщика. Кроме того, я рекомендую первым делом начать мониторинг NTLM на серверах. Вы можете подключить клиенты для проведения детального анализа, после того как станет очевидно, что сервер использует протокол NTLM. Уяснив, какие приложения используют NTLM, вы можете разработать стратегию блокировки NTLM. Эта стратегия может включать в себя стратегию исключений для устаревших приложений, которые не могут быть переписаны или перенастроены и которые всегда будут требовать применения NTLM.

К сожалению, упомянутые настройки NTLM нельзя применять на старых системах Windows. Однако эти системы допускают возможность управления версиями протокола NTLM. Вы можете, например, отключить фрагмент LM протокола аутентификации NTLM (поскольку этот фрагмент слаб по самой своей природе) или задать принудительное применение протокола NTLMv2. Для этого следует воспользоваться настройкой Network Security: LAN Manager Authentication Level GPO, которая размещается в контейнере Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesSecurity Options GPO (см. экран 2).

Средства шифрования Kerberos

Криптографические протоколы, используемые протоколами аутентификации, играют важную роль в обеспечении безопасности последних. Как я уже отмечал, в этой области показатели Kerberos выше, чем у протокола NTLM. Алгоритм шифрования RC4 был впервые реализован в протоколе Windows Kerberos в версии Windows 2000 и по сей день поддерживается в системах Server 2008, а также Windows 7 (точнее говоря, поддерживается его версия RC4_HMAC_MD5). В системах Server 2008, Windows Vista и более новых версиях разработчики Microsoft добавили средства поддержки шифрования по стандарту Advanced Encryption Standard, AES, а системы Windows 7 и Server 2008 R2 поддерживают типы шифрования Kerberos AES (AES128_HMAC_SHA1 и AES256_HMAC_SHA1) без предварительной настройки. AES — более новый и мощный алгоритм шифрования, нежели DES. Логика Kerberos на контроллерах доменов перейдет на стандарт шифрования AES, когда вы модернизируете домен AD до уровня Windows 2008 Domain Functional Level (DFL).

В системах Windows 7 и Server 2008 R2 типы шифрования DES для протокола аутентификации Kerberos по умолчанию отключены. Из-за этого могут возникнуть проблемы совместимости, если одно из устаревших приложений жестко закодировано на шифрование только по стандарту DES или если учетная запись Windows, выполняющая ту или иную службу (учетная запись этой службы), настроена на использование только DES-шифрования. Эти службы или приложения выйдут из строя, если вы не сможете перенастроить соответствующую службу либо приложение на поддержку другого типа шифрования (RC4 или AES) либо не восстановите поддержку стандарта DES.

Чтобы выяснить, имеются ли у вас приложения либо службы, закодированные на шифрование исключительно по стандарту DES, можно запустить сетевой трассировщик при старте соответствующего приложения или службы и проверить содержимое полей Etype в заголовках аутентификации Kerberos. Чтобы определить, настроена ли учетная запись пользователя либо компьютера AD или учетная запись компьютера для применения исключительно типов шифрования DES, нужно проверить, выбран ли на вкладке Account свойств объекта параметр Use Kerberos DES encryption types for this account. К этим свойствам можно обратиться из оснастки AD Users and Computers консоли MMC.

Если вы выполните упомянутые выше проверки и окажется, что у вас возникла эта проблема, можете активировать DES-шифрование для аутентификации с помощью Kerberos на компьютерах, функционирующих под Windows 7 или Server 2008 R2, с помощью GPO настройки Network security: настройте типы шифрования, совместимые со стандартом Kerberos; эти настройки расположены в контейнере Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options GPO.

Итак, из двух протоколов аутентификации Windows предпочтительным является протокол Kerberos. Администраторам следует всегда настаивать на том, чтобы пользователи и приложения применяли именно Kerberos, а не NTLM. Новые ограничения по использованию NTLM, реализованные в системах Windows 7 и Server 2008 R2, открывают перед нами отличную возможность для достижения этой цели.

Жан де Клерк (jan.declercq@hp.com) — сотрудник Security Office компании HP. Специализируется на управлении идентификационными параметрами и безопасностью в продуктах Microsoft

11

Лекция №4

Вопросы:

1. Этапы
идентификации и аутентификации
пользователя, реализуемые ОС Windows.

2. Протоколы
аутентификации Windows.

1.Этапы идентификации и аутентификации пользователя, реализуемые ос Windows

Аутентификация
представляет собой один из компонентов
любой компьютерной системы
управления доступом.
Как показано на рисунке 1, системы
управления доступом обеспечивают
идентификацию, аутентификацию, авторизацию
и отчетность.

Рисунок 1. Механизмы
управления доступом и аутентификация
в Windows

1. Идентификация

Это первый этап
входа в КС. Как известно, на этом этапе
вводится имя пользователя КС (логин).

При этом ОС (а
именно, процесс Winlogon, отвечающий за вход
в КС и выход из неё) создает уникальный
идентификатор пользователя (SID),
представляющий собой набор данных,
который уникально идентифицирует объект
безопасности (пользователя, группу,
компьютер, учетную запись службы).

Пример.

S-1-5-21-1463437245-1224812800-863842198-1128

1 — №версии;

5 – код агента ОС
(назначающей SID);

Четыре кода
субагентов-попечителей;

1128 – RID или средство
создания уникальных SID.

SID назначается
компьютеру при установке ОС. Далее
Winlogon назначает SID локальным учетным
записям на данном компьюторе.

SID(ЛУЗ) = SID (К) + RID
пользователя.

RID = 500 – администратор;

RID = 501 – гость;

RID = 1000, 1001….. –
пользователи.

Процесс Winlogon
создает уникальный локальный SID для
пользователя. Если вход пользователя
прошел успешно, этот SID будет включен в
маркер доступа.

Маркер доступа
(МД) –
идентификатор контекста защиты процесса
или потока. Он наследуется всеми
процессами, запущенными от имени
пользователя.

Для защиты от НСД
используются два элемента МД:

1. SID пользователя
   и SIDы групп, в которые входит пользователь;

2. Список привилегий
   (прав), сопоставленных с маркером.

2. Аутентификация

После того как
субъект безопасности вводит с клавиатуры
необходимую для идентификации информацию
(например, имя пользователя), он должен
ввести с клавиатуры или представить
частную информацию для аутентификации
(например, пароль или PIN-код).

В Windows субъект
безопасности вводит эту информацию на
экране регистрации с помощью программ
Microsoft Graphical Identification and Authentication DLL
(msgina.dll) и Winlogon.exe. Протокол аутентификации
и механизм системы шифруют представленную
информацию на персональном компьютере
и передают запрос аутентификации.

Службой аутентификации
Windows может быть база данных SAM или Active
Directory.

База данных SAM
обслуживает локальные
процедуры регистрации и регистрацию
на контроллерах домена Windows NT 4.0. Эта
база обязательно имеется на каждом
компьютере с операционной системой
Windows. В ней хранится вся информация,
используемая для аутентификации
пользователей Windows при интерактивном
входе в систему и при удаленном доступе
к ней по компьютерной сети.

База
данных SAM представляет собой один из
кустов (hive) системного реестра (registry)
Windows. Этот куст принадлежит ветви
(subtree) HKEY_LOCAL_MACHINE и называется SAM. Физически
база данных SAM располагается в каталоге
wmnt_rootSystem32ConfIg (winnt_root — условное
обозначение каталога с системными
файлами Windows) в отдельном файле, который
тоже называется SAM.

Информация в базе
данных SAM хранится в основном в двоичном
виде. Доступ к ней обычно осуществляется
через диспетчер учетных записей. Изменять
записи, находящиеся в базе данных SAM,
при помощи программ, позволяющих напрямую
редактировать реестр Windows (REGEDT или
REGEDT32), не рекомендуется. По умолчанию
этого и нельзя делать, т. к. доступ к базе
данных SAM запрещен для всех без исключения
категорий пользователей операционной
системы Windows.

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

Active
Directory
аутентифицирует запросы в Windows
2000/XP/Vista
или доменах более поздних версий этой
операционной системы. Протокол
аутентификации используется для
транспортировки запросов аутентификации
и последующих транзакций между экраном
регистрации и службой аутентификации.
Чуть ниже каждый протокол аутентификации
будет рассмотрен отдельно.

Рис.2.
Компоненты, участвующие в процессе
аутентификации.

При
интерактивном входе в систему (в отличие
от входа через сеть) происходит
взаимодействие с процессами Winlogon,
Lsass,
одним или несколькими пакетами
аутентификации, а также SAM
или Active
Directory.
Пакеты
аутентификации
(authentication
packages)
— это DLL-модули,
выполняющие
проверки, связанные с аутентификацией.

Windows использует
два стандартных пакета аутентификации
при интерактивном входе: Kerberos и MSV1_0.

Пакетом
аутентификации Windows
для интерактивного входа в домен
является
Kerberos.

Пакет
MSV1_0
используется для
интерактивного входа на локальные
компьютеры.

Таким
образом, пакетом аутентификации по
умолчанию в автономной
системе
Windows является пакет — MSV1_0
(WindowsSystem32Msvl_0.dll).

Пакет
аутентификации MSV1_0 принимает имя
пользователя и хешированную версию
пароля и посылает базе SAM запрос на
получение информации из учетной записи,
включая пароль, группы, в которые входит
пользователь, и список ограничений по
данной учетной записи. Сначала MSV1_0
проверяет ограничения, например
разрешенное время или типы доступа.
Если ограничения из базы данных SAM
запрещают регистрацию пользователя в
это время суток, MSV1_0 возвращает LSA статус
отказа.

Далее
MSV1_0 сравнивает хешированный пароль и
имя пользователя с теми, которые хранятся
в SAM.

Winlogon — процесс,
отвечающий за взаимодействие с
пользователем.

Он координирует
вход, запускает первый процесс при входе
в систему данного пользователя,
обрабатывает выход из системы и управляет
множеством других операций, имеющих
отношение к защите, — вводом паролей
при регистрации, сменой паролей,
блокированием и разблокированием
рабочих станций и т. д. Процесс Winlogon
должен обеспечить невидимость операций,
связанных с защитой, для других активных
процессов. Так, Winlogon гарантирует, что в
ходе этих операций недоверяемый процесс
не сможет перехватить управление рабочим
столом и таким образом получить доступ
к паролю.

Winlogon получает имя
и пароль пользователя через Graphical
Identification and Authentication (GINA) DLL Стандартная
GINA — WindowsSystem32 Msgina.dll. Msgina выводит
диалоговое окно для входа в систему.

Позволяя заменять
Msgina другими GINA-библиотеками, Windows дает
возможность менять механизмы идентификации
пользователей. Например, сторонний
разработчик может создать GINA для
поддержки устройства распознавания
отпечатков пальцев и т.д.

Winlogon — единственный
процесс, который перехватывает запросы
на регистрацию с клавиатуры. Получив
имя и пароль пользователя от GINA, Winlogon
вызывает LSASS для аутентификации этого
пользователя. Если аутентификация
прошла успешно, процесс Winlogon активизирует
оболочку. Схема взаимодействия между
компонентами, участвующими в процессе
регистрации, показана на слайде.

Соседние файлы в папке лк

• #

  02.02.2021530.94 Кб28Л9.ppt

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Background

With the emergence of Web 2.0, identity management is becoming a core focus. Security in online transactions is gaining attention from all technology vendors including Microsoft. Microsoft’s recent release of .NET Framework 3.0 includes Windows CardSpace which provides a solid foundation for identity management of future. Also, the recent announcement from Microsoft to tie-up with OpenID, takes the CardSpace initiative to the next level. The current article gives an overview of various authentication mechanisms on Microsoft Windows platform.

Introduction

A digital identity is a set of characteristics associated with an individual or a device which allows us to address it distinctly from the rest of the world.

Before granting access to a valuable resource, a digital identity is checked to confirm the source of the request. This mechanism is termed as authentication.

Various popular authentication mechanisms are:

1. User name and password
2. Digital certificates
3. Biometrics – fingerprints, Iris/retina scan
4. Dynamic biometrics – signature, voice recognition

Microsoft Windows Server 2003 has adopted Kerberos 5 as the default protocol for network authentication. Active Directory is merely the directory that holds all the information. Kerberos protocol implementation is used to protect it and make it function.

Microsoft Windows Server 2000 and beyond use the following as default authentication mechanism:

All the authentication protocols are exposed via SSPI (Security Support Provider Interface).

Windows authentication process using Kerberos KDC (Key Distribution Center) is shown below.

Authentication in .NET Applications

The .NET Framework has a model for managing user or automated agent based on the notion of an Identity. The identity object encapsulates information about the user or entity being validated.

Basic identity objects contain a name and an authentication type. The name can either be a user’s name or the name of a Windows account, while the authentication type can be either a supported logon protocol, such as Kerberos V5, or a custom value.

namespace System.Security.Principal
{
    public interface IIdentity
    {
        bool IsAuthenticated { get; }
        string AuthenticationType { get; }
        string Name { get; }
    }
}

IIdentity interface shown above abstracts the authentication part of security context.

The .NET Framework defines a GenericIdentity object that can be used for most custom logon scenarios and a more specialized WindowsIdentity object that can be used when the application relies on Windows authentication. Additionally, own identity class can be defined that encapsulates custom user information.

Web Application Authentication

ASP.NET implements authentication via authentication providers. Providers are basically Classes that contain Public Static methods to help in authenticating requests from Clients.

An ASP.NET application can be configured to use one of the following Authentication Providers:

1. Windows Authentication

The WindowsAuthenticationModule provider relies on IIS to provide authenticated users. The provider module constructs a Windows Identity object. The default implementation constructs a WindowsPrincipal object and attaches it to the application context. One of the major advantages of Windows Authentication is to allow implementation of an impersonation scheme.

2. Forms Authentication

Forms authentication is recommended if the application needs to collect its own user credentials at logon time through HTML forms. All the unauthorized requests are redirected to the logon page using HTTP client-side redirection. Forms authentication provider may implement custom logic for validating username and password against identity store. If the application authenticates the request, the system issues a ticket that contains a key for reestablishing the identity for subsequent requests.

3. Passport Authentication

Passport authentication is Microsoft’s centralized authentication service that offers a single logon and core profile services for member sites. Passport uses the Triple DES encryption scheme. When member sites register with Passport, they are granted a site-specific key. The Passport logon server uses this to encrypt and decrypt the query strings passed between sites. Authentication ticket is preserved by client in a cookie and is used for all future requests to the application till the cookie expires.

Web Services Authentication

Authentication of Web Services can be classified into two models as follows:

1. Direct Authentication

In direct authentication model, the client and the service establish a direct trust. Client application sends the credentials directly to the service along with the service request. Service maintains the catalog of the authorized clients and authentication mechanism is built into the service components. This model can be considered similar to the Forms authentication for web applications as both mechanisms do not require any intermediary to build the trust.

2. Brokered Authentication

Brokered authentication has an intermediary called as ‘broker’ to perform authentication when client and service do not share trust relationship. Credentials are used to authenticate with the broker, which issues a security token. The security token is then used to authenticate with services.

WSE (Web Services Enhancement) provides 3 main security tokens which support brokered authentication.

I. X.509

This requires support for a PKI (Public Key Infrastructure). In cases where a limited number of certificates are needed, an external CA (Certificate Authority) can be used. Most X.509 implementations, such as SSL, exchange a symmetric session key that is used for encryption.

II. KerberosToken

This requires an identity provider that supports the Kerberos protocol, such as Active Directory. Service tickets are session-based tokens that can be used for confidentiality and integrity.

III. STS (Security Token Service)

This requires an STS implementation that issues and manages security tokens. Custom security tokens can be used for session based operations.

CardSpace Authentication

Windows CardSpace is a technology designed to help eliminate the need for usernames and passwords. Instead, it will provide Windows users with digital identities in the form of Cards that users can access in a secure and familiar manner.

CardSpace provides an identity selector and a self-issued identity provider, both of which run on a client machine. CardSpace is a new way of doing strong authentication across trust boundaries. Internet Explorer 7 uses Windows CardSpace, if installed.

Windows CardSpace uses the following interoperable protocols — WS-Security, WS-SecurityPolicy, WS-Trust and WS-MetadataExchange.

Identity Provider provides the card (.crd file) which contains the metadata information. This card is used to obtain the security token from the Identity provider for sending the claim to the relying party.

OpenID Authentication

OpenID uses XRI (eXtensible Resource Identifier) to verify the digital identity. CardSpace can play a role to supplement the OpenID authentication process by establishing a relationship between client and OP using WS-Trust and WS-MetadataExchange. This may help eliminate steps 4 and 5 from the overall authentication process. Also, Card can additionally carry the XRI along with OP token.

Conclusion

SSO (Single sign-on) is a form of software authentication that enables a user to authenticate once with one software system and in turn gain access to multiple software systems. Windows OS authentication being a primary authentication, it is ideal to base the SSO on the same to gain access to all the applications accessed in that Windows session without a need for (re-)entering the credentials. Internet has opened the doors for a very large number of applications accessible to the users typically in B2C scenario with each application requiring user to undergo its own registration and authentication process. Along with the SSO, a demand for secure and reliable as well as generic mechanism to establish a trust persists. With the evolution of technology and the open standards being widely accepted, the vision of ‘Trustworthy SSO’ across the web will not be too far from getting into reality.

References

1. Web Service Security — guide from Microsoft Patterns & Practices
2. OpenID Authentication 2.0 — Draft 11
3. Microsoft Windows Server 2003 Authentication: Under the hood by Richard Ward

License

This article has no explicit license attached to it, but may contain usage terms in the article text or the download files themselves. If in doubt, please contact the author via the discussion board below.

A list of licenses authors might use can be found here.

Background

With the emergence of Web 2.0, identity management is becoming a core focus. Security in online transactions is gaining attention from all technology vendors including Microsoft. Microsoft’s recent release of .NET Framework 3.0 includes Windows CardSpace which provides a solid foundation for identity management of future. Also, the recent announcement from Microsoft to tie-up with OpenID, takes the CardSpace initiative to the next level. The current article gives an overview of various authentication mechanisms on Microsoft Windows platform.

Introduction

A digital identity is a set of characteristics associated with an individual or a device which allows us to address it distinctly from the rest of the world.

Before granting access to a valuable resource, a digital identity is checked to confirm the source of the request. This mechanism is termed as authentication.

Various popular authentication mechanisms are:

1. User name and password
2. Digital certificates
3. Biometrics – fingerprints, Iris/retina scan
4. Dynamic biometrics – signature, voice recognition

Microsoft Windows Server 2003 has adopted Kerberos 5 as the default protocol for network authentication. Active Directory is merely the directory that holds all the information. Kerberos protocol implementation is used to protect it and make it function.

Microsoft Windows Server 2000 and beyond use the following as default authentication mechanism:

All the authentication protocols are exposed via SSPI (Security Support Provider Interface).

Windows authentication process using Kerberos KDC (Key Distribution Center) is shown below.

Authentication in .NET Applications

The .NET Framework has a model for managing user or automated agent based on the notion of an Identity. The identity object encapsulates information about the user or entity being validated.

Basic identity objects contain a name and an authentication type. The name can either be a user’s name or the name of a Windows account, while the authentication type can be either a supported logon protocol, such as Kerberos V5, or a custom value.

namespace System.Security.Principal
{
    public interface IIdentity
    {
        bool IsAuthenticated { get; }
        string AuthenticationType { get; }
        string Name { get; }
    }
}

IIdentity interface shown above abstracts the authentication part of security context.

The .NET Framework defines a GenericIdentity object that can be used for most custom logon scenarios and a more specialized WindowsIdentity object that can be used when the application relies on Windows authentication. Additionally, own identity class can be defined that encapsulates custom user information.

Web Application Authentication

ASP.NET implements authentication via authentication providers. Providers are basically Classes that contain Public Static methods to help in authenticating requests from Clients.

An ASP.NET application can be configured to use one of the following Authentication Providers:

1. Windows Authentication

The WindowsAuthenticationModule provider relies on IIS to provide authenticated users. The provider module constructs a Windows Identity object. The default implementation constructs a WindowsPrincipal object and attaches it to the application context. One of the major advantages of Windows Authentication is to allow implementation of an impersonation scheme.

2. Forms Authentication

Forms authentication is recommended if the application needs to collect its own user credentials at logon time through HTML forms. All the unauthorized requests are redirected to the logon page using HTTP client-side redirection. Forms authentication provider may implement custom logic for validating username and password against identity store. If the application authenticates the request, the system issues a ticket that contains a key for reestablishing the identity for subsequent requests.

3. Passport Authentication

Passport authentication is Microsoft’s centralized authentication service that offers a single logon and core profile services for member sites. Passport uses the Triple DES encryption scheme. When member sites register with Passport, they are granted a site-specific key. The Passport logon server uses this to encrypt and decrypt the query strings passed between sites. Authentication ticket is preserved by client in a cookie and is used for all future requests to the application till the cookie expires.

Web Services Authentication

Authentication of Web Services can be classified into two models as follows:

1. Direct Authentication

In direct authentication model, the client and the service establish a direct trust. Client application sends the credentials directly to the service along with the service request. Service maintains the catalog of the authorized clients and authentication mechanism is built into the service components. This model can be considered similar to the Forms authentication for web applications as both mechanisms do not require any intermediary to build the trust.

2. Brokered Authentication

Brokered authentication has an intermediary called as ‘broker’ to perform authentication when client and service do not share trust relationship. Credentials are used to authenticate with the broker, which issues a security token. The security token is then used to authenticate with services.

WSE (Web Services Enhancement) provides 3 main security tokens which support brokered authentication.

I. X.509

This requires support for a PKI (Public Key Infrastructure). In cases where a limited number of certificates are needed, an external CA (Certificate Authority) can be used. Most X.509 implementations, such as SSL, exchange a symmetric session key that is used for encryption.

II. KerberosToken

This requires an identity provider that supports the Kerberos protocol, such as Active Directory. Service tickets are session-based tokens that can be used for confidentiality and integrity.

III. STS (Security Token Service)

This requires an STS implementation that issues and manages security tokens. Custom security tokens can be used for session based operations.

CardSpace Authentication

Windows CardSpace is a technology designed to help eliminate the need for usernames and passwords. Instead, it will provide Windows users with digital identities in the form of Cards that users can access in a secure and familiar manner.

CardSpace provides an identity selector and a self-issued identity provider, both of which run on a client machine. CardSpace is a new way of doing strong authentication across trust boundaries. Internet Explorer 7 uses Windows CardSpace, if installed.

Windows CardSpace uses the following interoperable protocols — WS-Security, WS-SecurityPolicy, WS-Trust and WS-MetadataExchange.

Identity Provider provides the card (.crd file) which contains the metadata information. This card is used to obtain the security token from the Identity provider for sending the claim to the relying party.

OpenID Authentication

OpenID uses XRI (eXtensible Resource Identifier) to verify the digital identity. CardSpace can play a role to supplement the OpenID authentication process by establishing a relationship between client and OP using WS-Trust and WS-MetadataExchange. This may help eliminate steps 4 and 5 from the overall authentication process. Also, Card can additionally carry the XRI along with OP token.

Conclusion

SSO (Single sign-on) is a form of software authentication that enables a user to authenticate once with one software system and in turn gain access to multiple software systems. Windows OS authentication being a primary authentication, it is ideal to base the SSO on the same to gain access to all the applications accessed in that Windows session without a need for (re-)entering the credentials. Internet has opened the doors for a very large number of applications accessible to the users typically in B2C scenario with each application requiring user to undergo its own registration and authentication process. Along with the SSO, a demand for secure and reliable as well as generic mechanism to establish a trust persists. With the evolution of technology and the open standards being widely accepted, the vision of ‘Trustworthy SSO’ across the web will not be too far from getting into reality.

References

1. Web Service Security — guide from Microsoft Patterns & Practices
2. OpenID Authentication 2.0 — Draft 11
3. Microsoft Windows Server 2003 Authentication: Under the hood by Richard Ward

License

This article has no explicit license attached to it, but may contain usage terms in the article text or the download files themselves. If in doubt, please contact the author via the discussion board below.

A list of licenses authors might use can be found here.