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

Интегрированная аутентификация Windows

Интегрированная аутентификация Windows является наиболее безопасным методом аутентификации, однако она доступна только в Internet Explorer. Этот тип аутентификации раньше был известен как аутентификация NTLM и аутентификация Windows NT вопрос/ответ. При интегрированной аутентификации Windows браузер клиента проверяет сам себя на сервере посредством криптографического обмена данными..

Интегрированная аутентификация Windows поддерживает как протокол Kerberos v5, так и протокол NTLM (NT LAN Manager) для аутентификации посредством пакета Negotiate. При наличии Active Directory и соответствующей поддержке браузером (IE 5 или выше на платформе Windows 2000) используется протокол Kerberos, иначе – протокол NTLM. Как Kerberos, так и NTLM имеют некоторые ограничения. Интересен тот факт, что преимущества одного соответствуют слабым местам другого. Kerberos, как правило, работает с прокси-серверами, но с межсетевыми экранами его функционирование не столь эффективно. NTLM обычно работает через межсетевые экраны, но достаточно посредственно взаимодействует с прокси-серверами.

Несколько слов о Microsoft Negotiate

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

Аутентификация NTLM

NTLM представляет собой расширенную версию старого протокола аутентификации LM (LAN Manager). NTLM работает посредством вопросов/ответов между сервером и клиентом без передачи пароля пользователя через сеть в открытом виде. Клиент должен подтвердить то, что он знает пароль пользователя, посредством отправки зашифрованного хэша.

NTLM функционирует следующим образом.

1. Пользователь указывает имя пользователя, пароль и имя домена при входе на компьютер-клиент.
2. Клиент создает хэш данного пароля и удаляет оригинал.
3. Клиент отправляет серверу имя пользователя в открытом виде.
4. Сервер отправляет клиенту 16-битный фрагмент случайных данных.
5. Клиент шифрует этот фрагмент, а также хэш пароля пользователя и передает их на сервер.
6. Сервер передает имя пользователя, случайный фрагмент данных и ответ клиента на контроллер домена.
7. Контроллер домена шифрует отрезок случайных данных вместе со своим собственным хэшем пароля пользователя, после чего сравнивает их с элементами, присланными сервером.
8. Если значения совпадают, контроллер домена уведомляет сервер об успешном завершении аутентификации.
9. Если значения или имя пользователя не совпадают, контроллер домена уведомляет об этом сервер, который передает клиенту соответствующее сообщение. После этого браузер клиента запрашивает у пользователя аутентификационные данные.

Аутентификация Kerberos

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

Работа Kerberos основывается на центральном сервере, называемом Key Distribution Center (KDC) (Центр распределения ключей), который предоставляет все необходимые ключи. KDC выпускает так называемые билеты TGT (Ticket-Granting Tickets) ("Билеты для получения билетов") и предоставляет их клиентам, запрашивающим доступ к ресурсу на сервере.

Ниже показан процесс получения клиентом начального билета TGT.

1. Пользователь осуществляет вход на компьютер-клиент с указанием имени пользователя и пароля.
2. Клиент шифрует пароль и сохраняет его.
3. Клиент отправляет KDC сообщение с запросом на аутентификационные данные для службы TGT, а также зашифрованный пароль пользователя.
4. KDC сравнивает зашифрованный пароль со своей эталонной копией для проверки их идентичности. Также осуществляется проверка временного штампа, приложенного клиентом к запросу, для подтверждения того, что указанное в штампе время находится в пределах пяти минут собственного времени KDC.
5. В случае полного соответствия KDC создает запрошенные аутентификационные данные для службы TGT посредством генерации сеансового ключа входа и шифрования его на пользовательском ключе.
6. KDC создает другой фрагмент аутентификационных данных посредством шифрования сеансового ключа входа и TGT пользователя своим собственным эталонным ключом.
7. KDC отправляет оба фрагмента аутентификационных данных клиенту.
8. Клиент расшифровывает сеансовый ключ входа из первого отрезка аутентификационных данных с помощью зашифрованного пароля и сохраняет этот сеансовый ключ входа в кэше своего билета.
9. Клиент также сохраняет TGT в своем кэше билета.

Теперь у клиента есть TGT, и он может использовать его для получения билетов на доступ к ресурсам. Вот как это происходит.

1. Клиент запрашивает у KDC билет на доступ к ресурсам на сервере. Клиент предоставляет свой TGT центру KDC вместе с именем нужного ресурса и аутентификационным сообщением, зашифрованным на сеансовом ключе входа.
2. KDC расшифровывает TGT с помощью эталонного ключа, извлекает сеансовый ключ входа и использует его для расшифровки аутентификационного сообщения. Если оно совпадает с эталоном, подлинность клиента подтверждается.
3. KDC создает сеансовый ключ службы для клиента, предназначенный для представления серверу при подаче запросов на ресурсы, и шифрует сеансовый ключ службы на сеансовом ключе входа клиента.
4. KDC шифрует сеансовый ключ входа с использование эталонного ключа сервера, в результате чего создается билет.
5. KDC передает клиенту оба фрагмента аутентификационных данных клиенту, который расшифровывает сеансовый ключ с помощью своего сеансового ключа входа и сохраняет сеансовый ключ службы и билет в своем кэше.

Теперь у клиента есть билет, с помощью которого он получает доступ к ресурсам на сервере.

1. Клиент передает серверу сеансовый билет и аутентификационное сообщение, зашифрованное на сеансовом ключе службы.
2. Сервер расшифровывает сеансовый билет и проверяет временной штамп клиента на запросе (значение штампа должно находиться в пятиминутном интервале собственного времени сервера). Затем сервер получает из данного билета сеансовый ключ.
3. Сервер шифрует временной штамп сеансового билета на сеансовом ключе, после чего отправляет его клиенту.
4. Клиент расшифровывает сообщение и сравнивает временной штамп с оригиналом. Если все совпадает, процесс аутентификации считается успешно завершенным.

Это очень сложный процесс, но он обеспечивает подлинность каждого лица, устанавливающего соединение. Очевидно, что KDC играет важную роль в данном процессе, поэтому необходимо обеспечить безопасность центра KDC.