Как происходит аутентификация в домене windows

Обновлено: 04.07.2024

В Windows задачи идентификации, аутентификации и авторизации пользователей решаются специальной подсистемой аутентификации. Подсистема аутентификации Windows делится на три уровня — верхний, средний и нижний. Средний уровень подсистемы аутентификации пользуется услугами нижнего уровня и предоставляет услуги верхнему.

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

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

При входе пользователя в систему с локального или удаленного терминала провайдер, обслуживающий данный терминал, получает от пользователя его имя и пароль. В Windows 2003 и более ранних версиях по умолчанию использовался единственный провайдер аутентификации — библиотека msgina.dll, которая осуществляет все взаимодействие между локальным пользователем и процессом аутентификации. Начиная с Windows Vista, в Windows реализован более сложный механизм взаимодействия провайдеров аутентификации и процесса Winlogon, основанный на COM-интерфейсах и позволяющий одновременно использовать несколько различных провайдеров аутентификации.

1. Провайдер аутентификации получает от пользователя идентификационную и аутентификационную информацию. В стандартной конфигурации операционной системы в качестве идентификационной информации используется текстовое имя, а в качестве аутентификационной информации — текстовый пароль. Также возможно применение для аутентификации внешних носителей ключевой информации или биометрических характеристик пользователя.
2. Провайдер аутентификации генерирует запрос на аутентификацию, передавая необходимые данные на средний уровень подсистемы аутентификации с помощью системного вызова LsaLogonUser или одной из более высокоуровневых программных оберток этого системного вызова. Если аутентификация прошла успешно, создается маркер доступа пользователя.
3. Если маркер доступа пользователя создан успешно, провайдер аутентификации осуществляет авторизацию пользователя, запуская процесс userinit.exe от имени аутентифицированного пользователя. Для этого используется системный вызов CreateProcessAs User, который отличается от вызова CreateProcess только тем, что запускаемому процессу назначается маркер доступа, отличный от маркера доступа процесса-родителя. В данном случае процессу user- init назначается только что созданный маркер доступа авторизуемого пользователя.
4. Процесс userinit загружает индивидуальные настройки пользователя из его профиля, запускает программу-оболочку пользователя (чаще всего это Проводник Windows) и после этого завершает работу.

В средний уровень подсистемы аутентификации Windows входит локальный распорядитель безопасности (local security authority, LSA) и так называемые пакеты, аутентификации — заменяемые библиотеки, реализующие большую часть низкоуровневых функций аутентификации.

Локальный распорядитель безопасности представляет собой сервисный процесс lsass.exe, выполняющийся от имени псевдопользователя SYSTEM. Аварийное завершение LSA приводит к аварийному завершению работы всей операционной системы. Так же, как и Winlogon, LSA передоверяет большинство своих функций заменяемым библиотекам. Стандартная схема аутентификации Windows NT обслуживалась пакетом аутентификации MSV 1.0 (msvl_0.dll), а начиная с Windows 2000, стандартным является пакет аутентификации Kerberos.

Пакет аутентификации осуществляет аутентификацию пользователя в процессе обработки системного вызова LsaLogonUser. Аутентификация производится следующим образом.

1. Пакет аутентификации получает от верхнего уровня подсистемы аутентификации имя и пароль пользователя и генерирует образ пароля.
2. Используя услуги нижнего уровня подсистемы аутентификации, пакет аутентификации получает информацию, необходимую для проверки пароля, и проверяет пароль. Проверка пароля может вестись как путем простого сравнения хеш-образа введенного пароля с эталонным хеш-образом (протоколы LanManager, NTLM), так и путем более сложных криптографических процедур (Kerberos).
3. Если введенный пароль признан корректным, LSA получает от нижнего уровня подсистемы аутентификации информацию о том, может ли данный пользователь начинать в данный момент работу с данной рабочей станцией (не устарел ли пароль, не заблокирован ли бюджет пользователя и т. д.).
4. В случае положительного результата проверки LSA формирует маркер доступа пользователя, получая необходимую информацию от нижнего уровня подсистемы аутентификации.
5. LSA передает сформированный маркер доступа верхнему уровню подсистемы аутентификации.

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

Аутентификация при удаленном входе в систему осуществляется в целом по той же схеме за исключением того, что на верхнем уровне вместо процесса Winlogon может выступать произвольная пара клиент + сервер. Существует специальный интерфейс SSPI (Security Support Provider Interface), обеспечивающий взаимодействие приложений Windows с LSA в ходе аутентификации. В Windows поддерживается пять стандартных провайдеров сетевой аутентификации.

NTLM (NT Lan Manager, поддерживается начиная с Windows NT 4.0)

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

1. Клиент направляет серверу имя пользователя в открытом виде (в NTLM идентификационная информация пользователя не считается секретом).
2. Сервер генерирует случайное число от 0 до 65535 и высылает его клиенту.
3. Клиент зашифровывает это число, используя в качестве ключа хеш-функцию пароля пользователя и высылает результат шифрования серверу. В качестве алгоритма шифрования используется модификация алгоритма DES.
4. Сервер проводит аналогичные вычисления и сравнивает результат с полученным от клиента. Если результаты совпали, аутентификация признается успешной, в противном случае — неуспешной. В домене Windows сервер может передоверить данный шаг алгоритма контроллеру домена.

Kerberos (поддерживается начиная с Windows 2000)

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

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

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

Negotiate (поддерживается начиная с Windows 2000)

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

Digest (поддерживается начиная с Windows ХР)

Данный протокол аутентификации специально предназначен для веб-приложений. Подробно спецификации протокола изложены в RFC 2617. Функционально Digest похож на NTLM, для криптографических преобразований в Digest может использоваться поточный шифр RC4 с длиной ключа 40, 56 или 128 бит, а также DES либо Triple DES.

Schannel (поддерживается начиная с Windows NT 4.0 SP4) Этот провайдер поддерживает протоколы сетевой аутентификации TLS 1.0 и SSL 3.0, а также устаревший протокол РСТ 1.0. К криптографическим преобразованиям, используемым Schannel, относятся RC2, RC4, DES, Triple DES, RSA, DHE, MD5, SHA.

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

Начиная с Windows 2000, Windows поддерживает специальный унифицированный интерфейс, обслуживающий внешние носители ключей аутентификации.

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

Администраторы Windows могут вводить следующие ограничения на пароли пользователей:

Механизм автоматической блокировки (lock out) пользователя при превышении максимально допустимого количества неудачных попыток входа в систему не распространяется на пользователя Administrator.

Для каждого конкретного пользователя могут быть установлены следующие флаги:

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

• время работы пользователя с операционной системой может быть ограничено, в этом случае вход пользователя в систему разрешается только в отведенные для этого часы;
• количество компьютеров, с которых пользователь может входить в домен, может быть ограничено, администратор может явно перечислить компьютеры, с которых разрешен вход пользователя в домен;
• может быть установлена автоматическая блокировка учетной записи пользователя по истечении определенного времени;
• может быть указана программа или скрипт, автоматически выполняемая при входе пользователя в систему;
• может быть ограничена продолжительность терминальных сессий пользователя (подключений к терминальному серверу с удаленных компьютеров через Remote Desktop или другую подобную программу);
• может быть включена функция удаленного контроля («подсматривания») администратора за действиями пользователя в ходе работы с терминальным сервером. В зависимости от настроек данной функции, вмешательство администратора в сессию пользователя может происходить либо только с разрешения пользователя, либо без разрешения, незаметно для пользователя. Вмешательство администратора может быть ограничено просмотром пользовательского терминала либо ничем не ограничено — в этом случае администратор может управлять клавиатурой и мышью вместе с пользователем;
• могут быть установлены особые правила использования пользователем удаленного подключения к домену через модем или VPN.

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

• входить в систему интерактивно;
• входить в систему через сеть;
• входить в систему через терминальный сервер;
• запускать сервис от своего имени;
• запускать пакетное задание (batch job) от своего имени.

То, какая «привилегия» должна проверяться, определяется провайдером при вызове функции LogonUser. Например, если четвертый параметр этой функции равен LOGON32.LOGON.SERVICE, это означает, что пользователь входит в систему в качестве сервиса, т. е. запускает сервис от своего имени, и должна быть проверена «привилегия» запускать сервисы от своего имени.

Начиная с Windows 2000, для каждой привилегии входа поддерживается два списка — белый и черный. Чтобы субъект доступа получил некоторую привилегию входа, он должен быть прямо или косвенно упомянут в соответствующем белом списке и ни прямо, ни косвенно не упомянут в соответствующем черном списке.

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

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

в этом справочном разделе описываются понятия, на основе которых основана Windowsная проверка подлинности.

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

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

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

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

Проверка подлинности и авторизация: аналоговая поездка

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

Путешествие

Когда путешественника поступает на международную границу, для него запрашиваются учетные данные, а путешественника представляет свой паспорт. Процесс состоит из двух этапов:

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

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

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

Транзитивное отношение доверия между центрами безопасности является основой проверки подлинности; тип проверки подлинности, который выполняется на международной границе, основан на доверии. Местный правительственный орган не знает путешественника, но он доверяет этому органу размещения. Когда правительственный орган узла выпустил паспорт, он не знал путешественника. Он доверяет агентству, выдавшего сертификат о рождении, или другую документацию. Агентство, которое выдавало сертификат о рождении, в свою очередь, доверенный врач, который подписал сертификат. Врач, следящий за рождением путешественникаа, записывает сертификат с прямым подтверждением подлинности, в данном случае с местом младенец. Отношения доверия, передаваемые таким образом через доверенные посредники, являются транзитивными.

транзитивное доверие является основой сетевой безопасности в Windows архитектуре клиента/сервера. Отношение доверия проходит по всему набору доменов, например доменному дереву, и формирует связь между доменом и всеми доменами, которые доверяют этому домену. Например, если домен A имеет транзитивное доверие с доменом B, а домен б доверяет домену C, то домен A доверяет домену C.

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

Аналогичным образом можно предоставить всем пользователям определенные разрешения домена для доступа к ресурсу. Любой пользователь, принадлежащий к этому домену, имеет доступ к ресурсу, как и в Канаде, и в США входит Канада. Тем не менее, граждан США пытается войти в Бразилии или Индии, чтобы они не могли ввести эти страны только с помощью цифрового паспорта, так как в обеих странах требуется, чтобы в качестве действительного Visa требовалось посетить граждан США. Поэтому проверка подлинности не гарантирует доступа к ресурсам или авторизации для использования ресурсов.

Учетные данные

Паспорт и, возможно, связанные висас — это принятые учетные данные для путешественника. Однако эти учетные данные могут не позволить путешественника ввести или получить доступ ко всем ресурсам в стране. Например, для участия в конференции требуются дополнительные учетные данные. в Windows учетные данные могут быть управляемыми, чтобы предоставить владельцам учетных записей доступ к ресурсам по сети без многократного предоставления учетных данных. Этот тип доступа позволяет системе проверять подлинность пользователей один раз, чтобы получить доступ ко всем приложениям и источникам данных, которые им разрешено использовать, не вводя другой идентификатор учетной записи или пароль. Windowsная платформа обеспечивает возможность использования единого удостоверения пользователя (обслуживаемого Active Directory) по сети путем локального кэширования учетных данных пользователя в локальном центре безопасности операционной системы (LSA). когда пользователь входит в домен, Windows пакеты проверки подлинности прозрачно используют учетные данные для предоставления единого входа при проверке подлинности учетных данных в сетевых ресурсах. дополнительные сведения об учетных данных см. в разделе процессы учетных данных в Windows проверки подлинности.

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

Субъекты безопасности и учетные записи

в Windows любой пользователь, служба, группа или компьютер, которые могут инициировать действие, являются субъектом безопасности. Субъекты безопасности имеют учетные записи, которые могут быть локальными для компьютера или быть основаны на домене. например, Windows компьютеры, присоединенные к домену, могут участвовать в сетевом домене путем взаимодействия с контроллером домена, даже если никто из пользователей не вошел в систему. Чтобы инициировать обмен данными, компьютер должен иметь активную учетную запись в домене. Прежде чем принимать подключения от компьютера, локальный центр безопасности на контроллере домена проверяет подлинность удостоверения компьютера, а затем определяет контекст безопасности компьютера так же, как и для участника безопасности. Этот контекст безопасности определяет удостоверение и возможности пользователя или службы на определенном компьютере, а также пользователя, службы, группы или компьютера в сети. Например, он определяет ресурсы, такие как файловый ресурс или принтер, к которым можно получить доступ, и действия, такие как чтение, запись или изменение, которые могут быть выполнены пользователем, службой или компьютером на этом ресурсе. Дополнительные сведения см. в разделе субъекты безопасности.

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

Встроенные учетные записи и группы безопасности, в которых они являются членами, определяются в каждой версии Windows. С помощью групп безопасности можно назначить одни и те же разрешения безопасности для многих пользователей, которые успешно прошли проверку подлинности, что упрощает администрирование доступа. Правила для выдачи паспортов могут потребовать, чтобы путешественника были назначены определенным группам, например "Бизнес", "таурист" или "правительственные учреждения". Этот процесс обеспечивает согласованность разрешений безопасности во всех членах группы. Использование групп безопасности для назначения разрешений означает, что Управление доступом к ресурсам остается постоянным, и его можно легко контролировать и подвергать аудиту. Добавляя и удаляя пользователей, которым требуется доступ из соответствующих групп безопасности по мере необходимости, можно максимально ограничить частоту изменений в списках управления доступом (ACL).

автономные управляемые учетные записи служб и виртуальные учетные записи появились в Windows Server 2008 R2 и Windows 7 для предоставления необходимых приложений, таких как Microsoft Exchange Server и службы IIS (IIS), с изоляцией своих учетных записей домена, одновременно устраняя необходимость администратора вручную администрировать имя участника-службы (SPN) и учетные данные для этих учетных записей. групповые управляемые учетные записи служб появились в Windows Server 2012 и предоставляют те же функциональные возможности в домене, но также расширяют эту функциональность на нескольких серверах. При подключении к службе, размещенной на ферме серверов, например к службе балансировки сетевой нагрузки, для протоколов взаимной проверки подлинности требуется, чтобы все экземпляры служб использовали один и тот же субъект.

Дополнительные сведения об учетных записях см. в следующих статьях:

Делегированная аутентификация

Для использования аналогового пути в странах могут выдаваться те же права доступа ко всем участникам официального правительственного делегирования, если они хорошо известны. Это делегирование позволяет одному участнику работать с полномочиями другого участника. в Windows делегированная проверка подлинности происходит, когда сетевая служба принимает запрос на проверку подлинности от пользователя и принимает идентификатор этого пользователя, чтобы инициировать новое подключение к второй сетевой службе. Для поддержки делегированной проверки подлинности необходимо установить серверы переднего плана или сервера первого уровня, например веб-серверы, которые отвечают за обработку запросов проверки подлинности клиентов, а также серверные или n-уровневые серверы, например большие базы данных, которые отвечают за хранение информации. Вы можете делегировать право на настройку делегированной проверки подлинности для пользователей в Организации, чтобы сократить административную нагрузку на администраторов.

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

Проверка подлинности в отношениях доверия между доменами

Большинство организаций, имеющих более одного домена, имеют законную потребность в доступе пользователей к общим ресурсам, расположенным в другом домене, так же как путешественника разрешается перемещать в разные регионы в стране. Управление этим доступом требует, чтобы пользователи в одном домене также могли проходить проверку подлинности и авторизованы для использования ресурсов в другом домене. Для обеспечения возможности проверки подлинности и авторизации между клиентами и серверами в разных доменах должно быть отношение доверия между двумя доменами. отношения доверия — это базовая технология, с помощью которой безопасная Active Directoryная связь возникает и является неотъемлемой частью безопасности сетевой архитектуры Windows Server.

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

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

Смена протокола

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

Дополнительные сведения о смене протокола см. в разделе Смена протокола Kerberos и ограниченное делегирование.

Ограниченное делегирование

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

Дополнительные сведения о ограниченном делегировании см. в разделе Общие сведения о ограниченном делегировании Kerberos.

Аутентификации Windows (NTLM) и LDAP могут работать независимо друг от друга. Аутентификация Windows требует ввода учетных данных пользователя в окне авторизации браузера. А аутентификация LDAP использует проверку пароля пользователя на сервере Active Directory. Аутентификации Windows (NTLM) и LDAP работают вместе, когда пользователь нажимает ссылку “Войти под доменным пользователем”, и его аккаунт синхронизирован с LDAP.

На заметку. Аутентификация Windows доступна только для on-site приложений в связи с особенностями cloud-архитектуры.

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

Выполняется проверка авторизации пользователя в домене.

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

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

Если пользователь не синхронизирован с LDAP:

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

Если по результатам проверки данные совпадают и учетная запись пользователя лицензирована, осуществляется авторизация в приложении.

Если пользователь синхронизирован с LDAP:

Браузер посылает запрос в службу Active Directory для проверки подлинности пользователя.

Запрос возвращает учетные данные текущего доменного пользователя, которые сравниваются с логином и паролем, записанными в cookie-файл.

Если данные совпадают и учетная запись пользователя лицензирована , то осуществляется авторизация в приложении.

На заметку. Проверка подлинности выполняется как среди пользователей основного приложения, так и среди пользователей портала самообслуживания. Порядок проверки настраивается в файле Web.config приложения-загрузчика. Подробнее: Настроить файл Web.config приложения-загрузчика.

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

Настройка выполняется на сервере, где развернуто приложение, и включает в себя:

Настройку сервера IIS, которая активирует аутентификацию по протоколу NTLM. Подробнее: Настроить аутентификацию Windows в IIS.

Настроить аутентификацию Windows в IIS

Для приложения-загрузчика и веб-приложения включите анонимную аутентификацию и аутентификацию форм (Рис. 1).

Рис. 1 — Настройки для приложения-загрузчика в настройках IIS

На заметку. Обратите внимание, что необходимо выключить настройку “Windows Authentication”, которая в IIS включена по умолчанию.

Для директории Login внутри приложения-загрузчика отключите аутентификацию форм и включите анонимную аутентификацию и аутентификацию Windows (Рис. 2).

Обратите внимание, что анонимная аутентификация приложения-загрузчика и рабочих приложений должна выполняться под пользователем Application Pool Identity. Для этого перейдите в окно редактирования данных входа настроек Authentication по кнопке Edit в боковом меню Actions менеджера IIS, и выберите пользователя “Application Pool Identity” (Рис. 3).

Рис. 3 — Указание пользователя для анонимной аутентификации в настройках IIS

На заметку. Подробнее о настройке аутентификации Windows читайте в справочной документации Microsoft .

Настроить файл Web.config приложения-загрузчика

InternalUserPassword — провайдер, указанный в файле Web.config по умолчанию. Если вы хотите предоставить возможность аутентификации по NTLM-протоколу только пользователям, которые не синхронизированы с LDAP, не указывайте для параметра providerNames дополнительные значения.

Ldap — добавьте к значениям параметра providerNames данный провайдер, чтобы предоставить возможность аутентификации по NTLM-протоколу пользователям приложения, которые синхронизированы с LDAP.

SSPLdapProvider — добавьте к значениям параметра providerNames данный провайдер, чтобы предоставить возможность аутентификации по NTLM-протоколу пользователям портала самообслуживания, которые синхронизированы с LDAP.

NtlmUser — добавьте к значениям параметра autoLoginProviderNames данный провайдер, чтобы предоставить возможность аутентификации по NTLM-протоколу пользователям приложения, независимо от того, синхронизированы ли они с LDAP и какой тип аутентификации установлен для данных пользователей в Creatio.

SSPNtlmUser — добавьте к значениям параметра autoLoginProviderNames данный провайдер, чтобы предоставить возможность аутентификации по NTLM-протоколу пользователям портала самообслуживания, независимо от того, синхронизированы ли они с LDAP и какой тип аутентификации установлен для данных пользователей в Creatio.

Порядок записи провайдеров параметра autoLoginProviderNames определяет, в каком порядке выполняется проверка наличия пользователя системы среди пользователей приложения (NtlmUser) или среди пользователей портала (SSPNtlmUser). Например, чтобы проверка осуществлялась в первую очередь среди пользователей основного приложения, укажите провайдер NtlmUser первым в списке значений параметра autoLoginProviderNames .

Важно. Вы можете указать в качестве значения параметра autoLoginProviderNames провайдер SSPNtlmUser , только если указан дополнительно провайдер NtlmUser . Существует возможность использовать отдельно только провайдер NtlmUser .

Для отображения страницы входа в систему с доступной ссылкой Войти под доменным пользователем укажите значение “false” для параметра UsePathThroughAuthentication . При этом сквозная аутентификация будет выполняться лишь при переходе на главную страницу приложения. Чтобы отобразить страницу входа, добавьте запись /Login/NuiLogin.aspx к адресу сайта.

Если после выполнения описанных действий при первой попытке входа в систему отображается окно доменной авторизации, то необходимо дополнительно настроить свойства обозревателя Windows.

Чтобы в дальнейшем окно доменной авторизации не отображалось:
В меню “Start” → “Settings” → “Control Panel” → “Network and Internet” выберите пункт “Internet options” (Рис. 4).

Откройте для редактирования файл Web.config приложения-загрузчика.

Укажите в файле провайдеры аутентификации Windows:

Если вы хотите активировать сквозную аутентификацию, чтобы пользователь имел возможность авторизоваться в Creatio, минуя страницу входа, укажите значение “true” для параметра UsePathThroughAuthentication элемента <appSettings>:

В открывшемся окне перейдите на вкладку “Security” и по кнопке “Custom level” перейдите к настройкам безопасности (Рис. 5).

В группе настроек “User Authentication” выберите способ авторизации “Automatic logon with current user name and password” (Рис. 6).

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

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

Аутентификация: общие принципы

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

Аутентификация или проверка подлинности (authentication). После того как субъект безопасности вводит с клавиатуры или иным способом предоставляет необходимую для идентификации информацию (например, имя пользователя, маркер безопасности), он должен ввести с клавиатуры или представить частную информацию для аутентификации (например, пароль и PIN-код). В Windows субъект безопасности вводит эту информацию на экране регистрации с помощью программ Microsoft Graphical Identification and Authentication DLL (msgina.dll) и Winlogon.exe. Протокол аутентификации и механизм системы кодируют представленную информацию на настольном компьютере и передают запрос аутентификации. Служба аутентификации Windows может быть базой данных SAM или AD. База данных SAM обслуживает локальные процедуры регистрации и регистрацию на контроллерах домена Windows NT 4.0. AD аутентифицирует запросы в Windows 2000 или доменах более поздних версий этой операционной системы. Протокол аутентификации (например, LAN Manager, NT LAN Manager, NTLM, NTLMv2, Kerberos) используется для транспортировки запросов аутентификации и последующих транзакций между экраном регистрации и службой аутентификации. Чуть ниже каждый протокол аутентификации будет рассмотрен отдельно.

Авторизация (authorization). Если служба аутентификации удостоверяет комбинацию идентификатора и «секретных» данных аутентификации, то подлинность субъекта безопасности считается успешно подтвержденной. Затем система собирает информацию о членстве субъекта безопасности (т. е. пользователя) в группах. Нередко пользователь принадлежит к нескольким точно определенным группам — локальным (local), доменным (domain local), глобальным (global) и универсальным (universal) — в результате обычных процедур назначения членства. Система сверяет локальные группы с локальной базой данных SAM и проверяет локальные и глобальные группы на контроллерах DC в домашнем домене пользователя, а также универсальные группы на DC, который содержит глобальный каталог Global Catalog. Прямо или косвенно система собирает все сведения о членстве в группах, чтобы получить информацию о разрешениях безопасности.

Сразу после аутентификации система собирает идентификаторы SID учетной записи и сведения о членстве в группах в объекте, называемом маркером доступа (access token). Возможно, пользователю придется выйти и вновь зарегистрироваться в системе, чтобы новые разрешения безопасности вступили в силу. Если пользователю нужно получить доступ к объекту (например, файлу, папке, принтеру, разделу реестра), защищенному разрешениями NTFS, то процесс (например, Windows Explorer), выступающий от имени пользователя, предоставляет свой маркер доступа. Каждый объект NTFS располагает списком элементов управления доступом (access control entry, ACE), которые, в сущности, представляют собой знакомые разрешения NTFS (например, Allow Read, Allow Write). Набор элементов ACE, назначенных пользователям и группам, составляет список управления доступом (ACL) данного объекта. Примечательно, что ACL объекта представлен разрешениями безопасности, которые можно просмотреть в Windows Explorer.

Маркер доступа, содержащий учетную запись и группы, с которыми связан пользователь, определяет эффективные разрешения пользователя. Процесс авторизации заключается в разрешении или отказе в доступе к определенному объекту на основе сравнения маркера доступа с ACL объекта. Авторизацию обеспечивает Security Reference Monitor системы Windows (экран 1). В примере, показанном на экране 1, пользователь имеет разрешения Read, Write и Modify. Однако группа Everyone, к которой принадлежит пользователь, не имеет разрешения Modify. Члены других групп располагают разрешениями Read и Modify, но разрешение Deny группы Everyone отменяет разрешение Modify. Объект также располагает списками ACL, которые отказывают в разрешении Full Control группе HR, но пользователь к этой группе не принадлежит. Таким образом, эффективные разрешения пользователя по отношению к объекту на экране 2 — Read и Write.

Отчетность (accounting). Если в Windows режим аудита активизирован, то система сохраняет событие аутентификации в журнале Security, и это последний компонент системы управления доступом — отчетность. Большинство сложных событий начальной регистрации и последующей авторизации происходят за несколько секунд и скрыты от пользователя. Все сложные операции возлагаются на протокол аутентификации.

Задачи протокола

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

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

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

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

Локальная и доменная регистрация

При регистрации пользователя одна из первых задач Windows — определить, относится ли процедура только к локальной машине или к учетной записи домена. Пользователи, регистрирующиеся от имени локальной учетной записи, имеют доступ только к ресурсам своего компьютера и только если информация об учетной записи пользователя содержится в локальной базе данных SAM. Если пользователям нужно обратиться к ресурсам на удаленном компьютере без аутентификации в домене, то их учетные записи должны быть продублированы в локальной базе данных SAM каждого доступного компьютера. Учетные записи в каждом компьютере-участнике должны быть синхронизированы (одинаковые имена регистрации, пароли и сроки действия учетных данных на всех машинах). В противном случае положение значительно усложняется. Трудно обслуживать одноранговые (P2P) сети средних размеров, в которых применяются только локальные процедуры регистрации.

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

Как отмечалось выше, в Windows применяется четыре основных протокола аутентификации: LAN Manager, NTLM, NTLMv2 и Kerberos. LAN Manager появился во времена DOS и продолжал использоваться с первыми версиями Windows. NTLM был выпущен вместе с NT. Новшеством пакета обновлений NT Server 4.0 Service Pack 4 (SP4) стал NTLMv2, а Windows 2000 привнесла Kerberos. По умолчанию все компьютеры с Windows 2000 и более новыми операционными системами совместимы со всеми четырьмя протоколами аутентификации. Передавая в эти системы соответствующие команды, другие рабочие станции и серверы могут выбирать протокол для обработки запроса аутентификации. Системы Windows 9x и более поздние с полным набором программных исправлений совместимы с LM, NTLM и NTLMv2. На платформе Microsoft Kerberos может использоваться только клиентами Windows 2000 (или более новыми) при обращениях в домены Windows 2000 (и выше). Компьютер с Windows 2000 или более новой версией операционной системы должен иметь Kerberos и по крайней мере еще один из протоколов аутентификации.

Исследования в области безопасности показали, что более старые протоколы (LM и NTLM) уязвимы в случае прослушивания и атак с разгадыванием пароля.

Поэтому, если возможно, рекомендуется использовать только Kerberos и NTLMv2. Чтобы убедиться в правильности этого совета, следует оценить возможности каждого протокола.

LAN Manager

Компания IBM разработала протокол LAN Manager, применив его в ранних версиях Windows и сетях Windows. Как все протоколы аутентификации Microsoft, LAN Manager генерирует хеш паролей (LM hash), который хранится и используется отправителем и получателем в процессе аутентификации. LAN Manager формирует LM-хеши, изменяя все буквы пароля на верхний регистр, разбивая пароль на две 7-символьные половины, а затем шифруя. В дальнейшем LM-хеш используется в нескольких последовательных операциях, аналогичных процессу запрос—ответ, описанному выше.

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

пароли могут состоять из ограниченной последовательности 128 символов ASCII;
длина пароля не превышает 14 символов;
если пароль содержит менее 14 символов, то отсутствующие символы заменяются легко угадываемой хешированной формой, что позволяет точно определить длину пароля;
перед кэшированием LAN Manager преобразует все буквенные символы пароля в верхний регистр.

Почему LAN Manager до сих пор не вышел из употребления? В целях обратной совместимости он активен по умолчанию во всех компьютерах Windows, в том числе Windows Server 2003. В новейших базах данных аутентификации Windows слабый LM-хеш хранится наряду с более надежными просто на случай, если придется выполнить транзакцию LAN Manager. Если на предприятии не используются другие приложения, требующие аутентификации LAN Manager, то можно (и нужно) LAN Manager отключить.

NTLMv2

Kerberos

Компания Microsoft приняла Kerberos в качестве выбираемого по умолчанию протокола доменной аутентификации для доменов Windows 2000, а затем и AD. Kerberos — открытый стандарт, пригодный для взаимодействия с инородными доменами (называемыми областями — realm — в UNIX и Linux). Каждый DC в доменах AD играет роль сервера распределения (Kerberos Distribution Server, KDC) и может участвовать в процедуре аутентификации. Безопасность повышается благодаря следующим характеристикам Kerberos:

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

Краткое описание работы Kerberos:

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

Следует обратить внимание, что, хотя принцип работы Kerberos напоминает инфраструктуру с частным открытым ключом (public key infrastructure, PKI), вся информация защищается с использованием симметричных ключей (в отличие от асимметричных ключей, применяемых в большинстве служб аутентификации).

Смарт-карты

Надежность паролей и других методов аутентификации на основе одного параметра быстро снижается. Электронная коммерция проникает в повседневную жизнь и возрастает как число способов кражи личных данных (спам, мошенничество с URL), так и вероятность злоупотреблений паролями. Многие специалисты считают, что аутентификация с двумя параметрами — в форме смарт-карт, USB-устройств или других криптографических устройств — в будущем станет обычным явлением для транзакций в Internet. Разработчики Microsoft встраивают в свои решения функции для работы с цифровыми сертификатами и смарт-картами. Для использования смарт-карт необходимо установить службу Certificate Services и распространить сертификаты смарт-карт. Конечно, нужны также физические смарт-карты, устройства считывания и программное обеспечение поставщика. Затем при необходимости пользователи могут вставлять свои смарт-карты в локальные устройства чтения для доступа к компьютеру Windows. При грамотном использовании смарт-карты могут существенно повысить надежность аутентификации.

Защита протокола аутентификации

В некоторых статьях ошибочно утверждается, что взломать механизм аутентификации Microsoft по-прежнему просто. В действительности из 20 существующих инструментов взлома пароля только два работают с NTLMv2 и лишь один — с Kerberos. Но, предприняв несколько простых шагов, можно отвести и эту угрозу. Для предотвращения попыток разгадывания и сброса пароля нужно принять следующие меры (большинство параметров можно настроить локально или с помощью Group Policy).

Обязанности пользователей

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

Читайте также: