Страница:
Защита COM может быть разделена на три категории: аутентификация (authentication), контроль доступа (access control) и управление маркерами (token management). Аутентификация заключается в обеспечении подлинности сообщения, а именно: отправитель действительно тот, за кого он себя выдает, а данное сообщение действительно пришло от отправителя. Контроль за доступом проверяет, кто имеет допуск к объектам сервера и кто имеет право запуска серверного процесса. Управление маркерами осуществляет контроль за тем, чьи полномочия использованы при запуске серверных процессов и при выполнении самого вызова метода. В COM предусмотрены до некоторой степени разумные установки по умолчанию по всем трем аспектам защиты, что делает теоретически возможным писать приложения COM, не учитывая вопросов безопасности. Эти установки по умолчанию основаны на принципе наименьших сюрпризов; то есть если программист не делает ничего явного по защите, то маловероятно, что этим будут внесены какие-либо «дыры» в систему безопасности NT. В то же время построение даже простейшего рассредоточенного приложения на базе COM требует, чтобы каждому аспекту обеспечения безопасности было уделено определенное внимание.
Большинство аспектов защиты COM может быть сконфигурировано путем помещения в реестр нужной информации. Программа DCOMCNFG.ЕХЕ позволяет администраторам настраивать большинство установок (но не все), относящихся к защите COM. Для большинства этих установок (но не для всех) программист приложения может предпочесть употребление явных API-функций вместо установок в реестре. В целом большинство приложений используют комбинацию установок DCOMCNFG.EXE с явными API-функциями. Первый вариант проще для отладки системными администраторами, в то время как второй предполагает большую гибкость без риска неправильного обращения с DCOMCNFG.EXE.
Защита COM использует основные средства RPC для аутентификации и заимствования прав (impersonation). Напомним, что RPC использует загружаемые транспортные модули для того, чтобы после их загрузки в систему были добавлены новые сетевые протоколы. Транспортные модули именуются при помощи последовательностей протоколов (protocol sequences) (например, «ncadg_ip_udp»), которые преобразуются в реестре в специальную транспортную библиотеку DLL. Это позволяет третьим участникам устанавливать поддержку новых транспортных протоколов без модифицирования библиотеки COM. Подобным же образом RPC поддерживает загружаемые модули защиты, позволяя добавлять в систему новые протоколы защиты. Модули защиты именуются при помощи целых чисел, которые преобразуются в реестре в специальные DLL модулей защиты. Эти DLL должны соответствовать требованиям SSPI (Security Support Provider Interface – интерфейс провайдера поддержки безопасности), который является производным от Internet Draft Standard GSSAPI.
В системных заголовочных файлах определено несколько констант для известных модулей защиты. Ниже приведен текущий список известных на момент написания этого текста модулей защиты:
enum {
RPC_C_AUTHN_NONE = 0, // no authentication package
// модуля аутентификации нет
RPC_C_AUTHN_DCE_PRIVATE = 1, // DCE private key (not used)
// закрытый ключ DCE (не используется)
RPC_C_AUTHN_DCE_PUBLIC = 2, // DCE public key (not used)
// открытый ключ DCE (не используется)
RPC_C_AUTHN_DEC_PUBLIC = 4, // Digital Equip, (not used)
// цифровое оборудование (не используется)
RPC_C_AUTHN_WINNT = 10, // NT Lan Manager
// администратор локальной сети NT
RPC_C_AUTHN_GSS_KERBEROS,
RPC_C_AUTHN_MQ = 100, // MS Message Queue package
// модуль MS Message Queue (очереди сообщений Microsoft)
RPC_C_AUTHN_DEFAULT = 0xFFFFFFFFL
};
RPC_C_AUTHN_WINNT показывает, что должен использоваться протокол аутентификации Администратора локальной сети (NT LAN (local area network) Manager – NTLM). RPC_C_AUTHN_GSS_KERBEROS показывает, что будет использован протокол аутентификации Kerberos. Под Windows NT 4.0 поддерживается только протокол NTLM, если не установлена SSP третьего участника. Windows NT 5.0 будет выпущена с поддержкой как минимум NTLM и Kerberos. По вопросам получения других модулей защиты обращайтесь к соответствующей документации.
Каждый интерфейсный заместитель может быть сконфигурирован независимо, что дает возможность использовать различные модули защиты. Если интерфейсный заместитель сконфигурирован для использования протокола защиты, в клиентский процесс загружается соответствующая SSP DLL. Для того чтобы запрос на соединение с защитой был принят, серверный процесс должен зарегистрировать и загрузить соответствующую библиотеку SSP DLL до получения от клиента первого вызова ORPC. Если соединение сконфигурировано для использования модуля защиты, то соответствующая SSP DLL работает в связке с динамическим уровнем иерархии RPC и имеет возможность видеть каждый пакет, передаваемый или получаемый в рамках конкретного соединения. Библиотеки SSP DLL могут посылать в каждом пакете дополнительную информацию, специфическую для защиты, а также модифицировать маршалированное состояние параметра в целях шифрования. DCE RPC (и COM) предусматривают шесть уровней аутентификационной защиты, которые варьируются от отсутствия защиты до полного шифрования состояния всех параметров:
enum {
RPC_C_AUTHN_LEVEL_DEFAULT, // use default level for pkg
// используем для модуля уровень, принятый по умолчанию
RPC_C_AUTHN_LEVEL_NONE, // по authentication
// без аутентификации
RPC_C_AUTHN_LEVEL_CONNECT, // only authenticate credentials
// только аутентификация мандата
RPC_C_AUTHN_LEVEL_CALL, // protect message headers
// защищаем заголовки сообщений
RPC_C_AUTHN_LEVEL_PKT, // protect packet headers
// защищаем заголовки пакетов
RPC_C_AUTHN_LEVEL_PKT_INTEGRITY, // protect parameter state
// защищаем состояние параметров
RPC_C_AUTHN_LEVEL_PKT_PRIVACY, // encrypt parameter state
// зашифровываем состояние параметров
};
Каждый последующий уровень аутентификации включает в себя функциональные возможности предыдущего уровня. Уровень RPC_C_AUTHN_LEVEL_NONE показывает, что не будет проведено никакой аутентификации. Уровень RPC_C_AUTHN_LEVEL_CONNECT показывает, что при первом вызове метода полномочия клиента должны быть аутентифицированы на сервере. Если у клиента нет необходимых полномочий, то вызов ORPC будет прерван с ошибкой E_ACCESSDENIED. Как именно проверяется достоверность этих полномочий, зависит от того, какая SSP используется. Под NTML серверный процесс выдает запрос пароля (challenge) клиентскому процессу. Этот запрос представляет собой просто непредсказуемое большое случайное число. Клиент использует закодированную версию пароля вызывающего объекта для шифрования этого запроса, который затем пересылается обратно серверу в качестве отклика (response). Затем сервер шифрует исходный запрос пароля с помощью того, что он считает закодированным паролем, и сравнивает результат с тем откликом, который он получил от клиента. Если отклик клиента совпадает с зашифрованным запросом сервера, то «личность» клиента считается установленной. NTLMSSP последовательно располагает пары квитирования (установления связи) запрос-отклик в отправных пакетах, которые посылаются исполняемой программой RPC для синхронизации порядковых номеров. Поэтому между клиентом и сервером не производится никакого дополнительного сетевого обмена данными. В зависимости от типа учетной записи (доменная, локальная) дополнительный обмен данными с контроллером домена для поддержки опосредованной аутентификации (pass-through authentication) может производиться или не производиться.
При использовании уровня аутентификации RPC_AUTHN_LEVEL_CONNECT никакого дополнительного обмена информацией, касающейся защиты, после проверки начальных полномочий не осуществляется. Это означает, что программы-злоумышленники могут перехватывать сообщения в сети и воспроизводить RPC-запросы путем простого изменения порядковых номеров DCE (среды распределенных вычислений) в заголовках пакетов. Для дополнительной защиты от воспроизведения вызова следовало бы использовать уровень аутентификации RPC_C_AUTHN_LEVEL_CALL. Он информирует библиотеки SSP DLL о необходимости защиты RPC-заголовка первого пакета каждого запроса или отклика RPC путем привязывания к передаваемому пакету однонаправленного хэш-ключа (на базе случайных чисел). Поскольку запрос или отклик RPC может быть помещен частями в более чем один сетевой пакет, то RPC API поддерживает также уровень аутентификации RPC_C_AUTHN_LEVEL_PKT. Этот уровень защищает от воспроизведения на уровне сетевых пакетов, что является большей защитой, чем уровень RPC_C_AUTHN_LEVEL_CALL, поскольку RPC-сообщение может занимать два пакета или более.
До уровня аутентификации RPC_C_AUTHN_LEVEL_PKT включительно SSP DLL в большей или меньшей мере игнорирует фактическую полезную нагрузку RPC-пакетов и защищает только целостность RPC-заголовков. Для того чтобы убедиться, что состояние маршалированного параметра не изменено вражеским агентом в сети, в RPC предусмотрен уровень аутентификации RPC_C_AUTHN_LEVEL_PKT_INTEGRITY. Этот уровень предписывает SSP DLL вычислять контрольную сумму состояния маршалированного параметра и проверять, что содержимое пакета не было изменено в процессе передачи. Поскольку при этом уровне аутентификации каждый передаваемый байт должен обрабатываться с помощью SSP DLL, она проходит значительно медленнее, чем при уровне RPC_C_AUTHN_LEVEL_PKT, и его следует использовать только в ситуациях, требующих особой защиты.
До уровня аутентификации RPC_C_AUTHN_LEVEL_PKT_INTEGRITY включительно фактическое содержание RPC-пакетов пересылается как открытый текст (например, незашифрованный). Для обеспечения невидимости состояния маршалированного параметра для вражеских агентов сети в RPC предусмотрен уровень аутентификации RPC_C_AUTHN_LEVEL_PKT_PRIVACY. Данный уровень аутентификации предписывает SSP DLL зашифровывать состояние маршалированного параметра до передачи. Подобно всем прочим уровням аутентификации уровень RPC_C_AUTHN_LEVEL_PKT_PRIVACY включает в себя защиту всех уровней ниже себя. Как и в случае RPC_C_AUTHN_LEVEL_PKT_INTEGRITY, каждый передаваемый байт должен обрабатываться SSP DLL, поэтому во избежание излишних издержек этот уровень аутентификации следует использовать только в особых с точки зрения безопасности ситуациях.
Наиболее важной API-функцией в службе безопасности COM является CoInitializeSecurity. Каждый процесс, использующий COM, вызывает CoInitializeSecurity ровно один раз, явно или неявно. Функция CoInitializeSecurity вводит автоматические установки по защите. Эти установки применяются ко всем импортируемым и экспортируемым ссылкам на объекты, за исключением явно переопределенных с использованием дополнительных вызовов API-функций. Чтобы использовать один или нескольких модулей защиты, CoInitializeSecurity конфигурирует используемый исполняемый слой RPC, а также устанавливает уровень аутентификации, принимаемый по умолчанию для процесса. Кроме того, CoInitializeSecurity позволяет вызывающей программе указать, каким пользователям разрешено делать ORPC-запросы на объекты, экспортируемые из текущего процесса. CoInitia1izeSecurity имеет довольно большое число параметров:
HRESULT CoInitializeSecurity(
[in] PSECURITY_DESCRIPTOR pSecDesc, // access control
// контроль за доступом
[in] LONG cAuthSvc, // # of sec pkgs (-1 == use defaults)
// количество модулей защиты (-1 == используем по умолчанию)
[in] SOLE_AUTHENTICATION_SERVICE *rgsAuthSvc, // SSP array
// массив SSP
[in] void *pReserved1, // reserved MBZ
// зарезервировано, должен быть О
[in] DWORD dwAuthnLevel, // auto, AUTHN_LEVEL
// аутентификация AUTHN_LEVEL
[in] DWORD dwImpLevel, // auto. IMP_LEVEL
// аутентификация IMP_LEVEL
[in] void *pReserved2, // reserved MBZ
// зарезервировано, должен быть О
[in] DWORD dwCapabilities, // misc flags
// различные флаги
[in] void *pReserved3 // reserved MBZ
// зарезервировано, должен быть О
);
Некоторые из этих параметров применяются только в тех случаях, когда процесс выступает как экспортер/сервер. Другие – только если процесс действует как импортер/клиент. Остальные применяются в обоих случаях.
Первый параметр функции CoInitializeSecurity, pSecDesc, применим только в случае, когда процесс выступает как экспортер. Этот параметр используется для контроля того, каким принципалам – пользователям или процессам, имеющим учетную запись (principals) – разрешен доступ к объектам, экспортируемым из данного процесса. В деталях этот параметр будет обсужден позже в данной главе. Второй и третий параметры функции CoInitializeSecurity, соответственно cAuthSvc и rgsAuthSvc, используются при работе процесса в качестве экспортера для регистрации одного или нескольких модулей защиты с помощью библиотеки COM. Эти два параметра ссылаются на массив описаний модулей защиты:
typedef struct tagSOLE_AUTHENTICATION_SERVICE {
DWORD dwAuthnSvc; // which authentication package?
// какой модуль защиты?
DWORD dwAuthzSvc; // which authorization service?
// какая служба авторизации?
OLECHAR *pPrincipalName; // server principal name?
// имя серверного принципала?
HRESULT hr; // result of registration
// результат регистрации
} SOLE_AUTHENTICATION_SERVICE;
В Windows NT 4.0 единственной установленной службой аутентификации является RPC_C_AUTHN_WINNT (NTLM). При использовании аутентификации NTLM служба авторизации (authorization service – сервис контроля доступа, определяющий права клиента) должна быть указана как RPC_C_AUTHZ_NONE, а имя серверного принципала не используется и должно быть нулевым[1]. Для тех процессов, которые просто хотят использовать пакет (пакеты) защиты по умолчанию на отдельной машине, следует использовать значения: cAuthSvc, равное -1, и rgsAuthSvc, равное нулю.
Пятый параметр функции CoInitializeSecurity, dwAuthnLevel, применим как к экспортируемым, так и к импортируемым объектным ссылкам. Величина, заданная для этого параметра, устанавливает предельно низкий уровень аутентификации для объектных ссылок, экспортируемых из этого процесса. Это означает, что поступающие ORPC-запросы должны иметь по крайней мере такой уровень аутентификации; в противном случае этот вызов будет отклонен. Эта величина определяет также минимальный уровень аутентификации, используемый новыми интерфейсными заместителями, которые возвращаются API-функциями или методами COM. Создавая новый интерфейсный заместитель во время демаршалинга, COM рассматривает число, обозначающее нижний уровень аутентификации, заданный экспортером, как часть разрешения OXID. Затем COM устанавливает уровень аутентификации нового заместителя равным или нижнему уровню экспортера, или нижнему уровню текущего процесса – в зависимости от того, какой из них выше. Если процесс, импортирующий объектную ссылку, имеет уровень аутентификации ниже, чем экспортирующий процесс, то для установки уровня аутентификации используется нижний уровень экспортера. Такой способ гарантирует, что любые ORPC-запросы, посылаемые интерфейсным заместителем, пройдут через нижний уровень экспортера. Далее в этой главе будет рассмотрено, как с целью более детального контроля можно явным образом изменить уровень аутентификации для отдельного интерфейсного заместителя[2].
Шестой параметр функции CoInitializeSecurity, dwImpLevel применяется для импортируемых объектных ссылок. Величина, определенная для этого параметра, устанавливает уровень заимствования прав (impersonation level), используемый для всех объектных ссылок, которые возвращаются функцией CoUnmarshalInterface. Уровень заимствования прав позволяет одному процессу заимствовать атрибуты защиты у другого процесса и отражает степень доверия, которое клиент испытывает к серверу. Этот параметр должен принимать одно из следующих четырех значений, характеризующих уровень заимствования прав:
enum {
// hide credentials of caller from object
// скрываем от объекта полномочия вызывающей программы
RPC_C_IMP_LEVEL_ANONYMOUS = 1,
// allow object to query credentials of caller
// разрешаем объекту запрашивать полномочия вызывающей программы
RPC_C_IMP_LEVEL_IDENTIFY = 2,
// allow use of caller's credentials up to one-hop away
// разрешаем использовать полномочия вызывающей
// программы не далее одной сетевой передачи
RPC_C_IMP_LEVEL_IMPERSONATE = 3,
// allow use of caller's credentials across multiple hops
// разрешаем использовать полномочия вызывающей
// программы в течение нескольких сетевых передач
RPC_C_IMP_LEVEL_DELEGATE = 4
};
Уровень RPC_C_IMP_LEVEL_ANONYMOUS не позволяет реализации объекта обнаружить идентификатор безопасности вызывающей программы[3]. Уровень доверия RPC_C_IMP_LEVEL_IDENTIFY указывает, что реализация объекта может программно определить идентификатор защиты вызывающей программы. Уровень доверия RPC_C_IMP_LEVEL_IMPERSONATE указывает, что сервер может не только определить идентификатор защиты вызывающей программы, но также выполнить операции на уровне операционной системы с использованием полномочий вызывающей программы. На этом уровне доверия объекты могут использовать полномочия вызывающей программы, но имеют доступ только к локальным ресурсам[4]. В противоположность этому, уровень доверия RPC_C_IMP_LEVEL_DELEGATE разрешает серверу доступ как к локальным, так и к удаленным ресурсам с использованием полномочий вызывающей программы. Этот уровень доверия не поддерживается протоколом аутентификации NTLM, но поддерживается протоколом аутентификации Kerberos.
Восьмой параметр функции CoInitializeSecurity, dwCapabilities применим к импортируемым и к экспортируемым объектным ссылкам. Этот параметр является битовой маской, которая может состоять из нуля или более следующих битов:
typedef enum tagEOLE_AUTHENTICATION_CAPABILITIES {
EOAC_NONE = 0х0,
EOAC_MUTUAL_AUTH = 0х1,
// These are only valid for CoInitializeSecurity
// только эти допустимы для CoInitializeSecurity
EOAC_SECURE_REFS = 0х2,
EOAC_ACCESS_CONTROL = 0х4,
EOAC_APPID = 0х8
} EOLE_AUTHENTICATION_CAPABILITIES;
Взаимная аутентификация (EOAC_MUTUAL_AUTH) под NTLM не поддерживается. Она используется для проверки того, что сервер исполняется как ожидаемый принципал. Ссылки защиты (EOAC_MUTUAL_AUTH) указывают, что распределенные вызовы подсчета ссылок COM будут аутентифицироваться для гарантии того, что никакие вражеские агенты не могут испортить счетчик ссылок, используемый OR и администраторами заглушек для управления жизненным циклом. EOAC_ACCESS_CONTROL и EOAC_APPID используются для управления семантикой первого параметра функции CoInitializeSecurity и будут обсуждаться далее в этой главе.
Как было установлено ранее в этом разделе, CoInitializeSecurity вызывается один раз на процесс, явно или неявно. Приложения, желающие вызвать CoInitializeSecurity явно, должны делать это после первого вызова CoInitializeEx, но перед «первым интересным вызовом COM» (first interesting COM call). Фраза «первый интересный вызов COM» относится к любой API-функции, которой может понадобиться OXID. Сюда относятся CoMarshalInterface и CoUnmarshalInterface, а также любые API-вызовы, неявно вызывающие эти функции. Поскольку вызовы CoRegisterClassObject связывают объекты класса с апартаментами, то CoInitializeSecurity должна быть вызвана до регистрации объектов класса. API-функции активации (например, CoCreateInstanceEx) являются любопытным исключением. Активация API-функций для определенных внутренних классов, которые являются частью COM API (например, глобальная интерфейсная таблица, COM-объект контроля доступа по умолчанию) может быть произведена до вызова CoInitializeSecurity. Тем не менее, функция CoInitializeSecurity должна быть вызвана раньше, чем любые активационные вызовы, которые фактически консультируются с реестром и загружают другие DLL или контактируют с другими серверами. Если приложение не вызывает функцию CoInitializeSecurity явно, то COM вызовет ее неявно в качестве первого интересного вызова COM.
Когда COM вызывает функцию CoInitializeSecurity неявно, она читает значения большинства параметров из реестра. Некоторые из этих параметров содержатся в реестровом ключе, общем для всей машины, в то время как остальные записаны под специфическим AppID данного приложения. Чтобы извлечь AppID приложения, COM ищет имя файла процесса приложения под ключом реестра
HKEY_CLASSES_ROOT\AppID
Если COM находит здесь имя файла, она извлекает AppID из именованной величины AppID:
[HKCR\AppID\ServerOfTheApes.exe]
AppID="{27EE6A4D-DF65-11d0-8C5F-0080C73925BA}"
Если никакого соответствия не существует, то COM считает, что приложение не имеет в реестре специфических установок по защите.
Неявные вызовы CoInitializeSecurity находят первый параметр, pSecDesc, путем поиска сериализованного (приведенного в последовательную форму) дескриптора защиты NT SECURITY_DESCRIPTOR в следующей именованной величине:
[HKCR\AppID\{27EE6A4D-DF65-11d0-8C5F-0080C73925BA}]
AccessPermission=<serialized NT security descriptor>
Если эта именованная величина не найдена, то COM ищет общий для всей машины элемент:
[HKEY_LOCAL_MACHINE\Software\Microsoft\OLE]
DefaultAccessPermission=<serialized NT security descriptor>
Оба этих элемента реестра могут быть легко изменены при помощи DCOMCNFG.ЕХЕ. Если не найден ни один из этих элементов реестра, то COM создаст дескриптор защиты (security descriptor), предоставляющий доступ принципалу только вызывающей программы и встроенной учетной записи SYSTEM. COM использует этот дескриптор защиты, чтобы при помощи Win32 API-функции AccessCheck предоставить или запретить доступ к объектам, экспортированным из данного процесса.
Неявные вызовы CoInitializeSecurity используют для второго и третьего параметров (cAuthSvc и rgsAuthSvc) значения -1 и нуль соответственно, указывая тем самым, что должны использоваться модули защиты, принятые по умолчанию. Неявные вызовы CoInitializeSecurity находят значения для пятого и шестого параметров (dwAuthnLevel и dwImpLevel) в следующем элементе реестра всей машины:
[HKEY_LOCAL_MACHINE\Software\Microsoft\OLE]
LegacyAuthenticationLevel = 0x5
LegacyImpersonationLevel = 0x3
RPC_C_AUTHN_LEVEL_PKT_INTEGRITY и RPC_C_AUTHN_LEVEL_IMPERSONATE принимают числовые значения 5 и 3 соответственно. Если эти именованные величины отсутствуют, то используются значения RPC_C_AUTHN_LEVEL_CONNECT и RPC_C_IMP_LEVEL_IDENTIFY. Из флагов, используемых в восьмом параметре функций CoInitializeSecurity, dwCapabilities, в настоящее время читается из элемента реестра всей машины только флаг EOAC_SECURE_REFS:
[HKEY_LOCAL_MACHINE\Software\Microsoft\OLE]
LegacySecureRefs = "Y"
Если эта именованная величина в наличии и содержит "Y" или "y", то COM будет использовать флаг EOAC_SECURE_REFS; в противном случае используется флаг EOAC_NONE. Каждая из этих традиционных установок аутентификации может быть легко изменена при помощи DCOMCNFG.ЕХЕ.
Программируемая защита
Большинство аспектов защиты COM может быть сконфигурировано путем помещения в реестр нужной информации. Программа DCOMCNFG.ЕХЕ позволяет администраторам настраивать большинство установок (но не все), относящихся к защите COM. Для большинства этих установок (но не для всех) программист приложения может предпочесть употребление явных API-функций вместо установок в реестре. В целом большинство приложений используют комбинацию установок DCOMCNFG.EXE с явными API-функциями. Первый вариант проще для отладки системными администраторами, в то время как второй предполагает большую гибкость без риска неправильного обращения с DCOMCNFG.EXE.
Защита COM использует основные средства RPC для аутентификации и заимствования прав (impersonation). Напомним, что RPC использует загружаемые транспортные модули для того, чтобы после их загрузки в систему были добавлены новые сетевые протоколы. Транспортные модули именуются при помощи последовательностей протоколов (protocol sequences) (например, «ncadg_ip_udp»), которые преобразуются в реестре в специальную транспортную библиотеку DLL. Это позволяет третьим участникам устанавливать поддержку новых транспортных протоколов без модифицирования библиотеки COM. Подобным же образом RPC поддерживает загружаемые модули защиты, позволяя добавлять в систему новые протоколы защиты. Модули защиты именуются при помощи целых чисел, которые преобразуются в реестре в специальные DLL модулей защиты. Эти DLL должны соответствовать требованиям SSPI (Security Support Provider Interface – интерфейс провайдера поддержки безопасности), который является производным от Internet Draft Standard GSSAPI.
В системных заголовочных файлах определено несколько констант для известных модулей защиты. Ниже приведен текущий список известных на момент написания этого текста модулей защиты:
enum {
RPC_C_AUTHN_NONE = 0, // no authentication package
// модуля аутентификации нет
RPC_C_AUTHN_DCE_PRIVATE = 1, // DCE private key (not used)
// закрытый ключ DCE (не используется)
RPC_C_AUTHN_DCE_PUBLIC = 2, // DCE public key (not used)
// открытый ключ DCE (не используется)
RPC_C_AUTHN_DEC_PUBLIC = 4, // Digital Equip, (not used)
// цифровое оборудование (не используется)
RPC_C_AUTHN_WINNT = 10, // NT Lan Manager
// администратор локальной сети NT
RPC_C_AUTHN_GSS_KERBEROS,
RPC_C_AUTHN_MQ = 100, // MS Message Queue package
// модуль MS Message Queue (очереди сообщений Microsoft)
RPC_C_AUTHN_DEFAULT = 0xFFFFFFFFL
};
RPC_C_AUTHN_WINNT показывает, что должен использоваться протокол аутентификации Администратора локальной сети (NT LAN (local area network) Manager – NTLM). RPC_C_AUTHN_GSS_KERBEROS показывает, что будет использован протокол аутентификации Kerberos. Под Windows NT 4.0 поддерживается только протокол NTLM, если не установлена SSP третьего участника. Windows NT 5.0 будет выпущена с поддержкой как минимум NTLM и Kerberos. По вопросам получения других модулей защиты обращайтесь к соответствующей документации.
Каждый интерфейсный заместитель может быть сконфигурирован независимо, что дает возможность использовать различные модули защиты. Если интерфейсный заместитель сконфигурирован для использования протокола защиты, в клиентский процесс загружается соответствующая SSP DLL. Для того чтобы запрос на соединение с защитой был принят, серверный процесс должен зарегистрировать и загрузить соответствующую библиотеку SSP DLL до получения от клиента первого вызова ORPC. Если соединение сконфигурировано для использования модуля защиты, то соответствующая SSP DLL работает в связке с динамическим уровнем иерархии RPC и имеет возможность видеть каждый пакет, передаваемый или получаемый в рамках конкретного соединения. Библиотеки SSP DLL могут посылать в каждом пакете дополнительную информацию, специфическую для защиты, а также модифицировать маршалированное состояние параметра в целях шифрования. DCE RPC (и COM) предусматривают шесть уровней аутентификационной защиты, которые варьируются от отсутствия защиты до полного шифрования состояния всех параметров:
enum {
RPC_C_AUTHN_LEVEL_DEFAULT, // use default level for pkg
// используем для модуля уровень, принятый по умолчанию
RPC_C_AUTHN_LEVEL_NONE, // по authentication
// без аутентификации
RPC_C_AUTHN_LEVEL_CONNECT, // only authenticate credentials
// только аутентификация мандата
RPC_C_AUTHN_LEVEL_CALL, // protect message headers
// защищаем заголовки сообщений
RPC_C_AUTHN_LEVEL_PKT, // protect packet headers
// защищаем заголовки пакетов
RPC_C_AUTHN_LEVEL_PKT_INTEGRITY, // protect parameter state
// защищаем состояние параметров
RPC_C_AUTHN_LEVEL_PKT_PRIVACY, // encrypt parameter state
// зашифровываем состояние параметров
};
Каждый последующий уровень аутентификации включает в себя функциональные возможности предыдущего уровня. Уровень RPC_C_AUTHN_LEVEL_NONE показывает, что не будет проведено никакой аутентификации. Уровень RPC_C_AUTHN_LEVEL_CONNECT показывает, что при первом вызове метода полномочия клиента должны быть аутентифицированы на сервере. Если у клиента нет необходимых полномочий, то вызов ORPC будет прерван с ошибкой E_ACCESSDENIED. Как именно проверяется достоверность этих полномочий, зависит от того, какая SSP используется. Под NTML серверный процесс выдает запрос пароля (challenge) клиентскому процессу. Этот запрос представляет собой просто непредсказуемое большое случайное число. Клиент использует закодированную версию пароля вызывающего объекта для шифрования этого запроса, который затем пересылается обратно серверу в качестве отклика (response). Затем сервер шифрует исходный запрос пароля с помощью того, что он считает закодированным паролем, и сравнивает результат с тем откликом, который он получил от клиента. Если отклик клиента совпадает с зашифрованным запросом сервера, то «личность» клиента считается установленной. NTLMSSP последовательно располагает пары квитирования (установления связи) запрос-отклик в отправных пакетах, которые посылаются исполняемой программой RPC для синхронизации порядковых номеров. Поэтому между клиентом и сервером не производится никакого дополнительного сетевого обмена данными. В зависимости от типа учетной записи (доменная, локальная) дополнительный обмен данными с контроллером домена для поддержки опосредованной аутентификации (pass-through authentication) может производиться или не производиться.
При использовании уровня аутентификации RPC_AUTHN_LEVEL_CONNECT никакого дополнительного обмена информацией, касающейся защиты, после проверки начальных полномочий не осуществляется. Это означает, что программы-злоумышленники могут перехватывать сообщения в сети и воспроизводить RPC-запросы путем простого изменения порядковых номеров DCE (среды распределенных вычислений) в заголовках пакетов. Для дополнительной защиты от воспроизведения вызова следовало бы использовать уровень аутентификации RPC_C_AUTHN_LEVEL_CALL. Он информирует библиотеки SSP DLL о необходимости защиты RPC-заголовка первого пакета каждого запроса или отклика RPC путем привязывания к передаваемому пакету однонаправленного хэш-ключа (на базе случайных чисел). Поскольку запрос или отклик RPC может быть помещен частями в более чем один сетевой пакет, то RPC API поддерживает также уровень аутентификации RPC_C_AUTHN_LEVEL_PKT. Этот уровень защищает от воспроизведения на уровне сетевых пакетов, что является большей защитой, чем уровень RPC_C_AUTHN_LEVEL_CALL, поскольку RPC-сообщение может занимать два пакета или более.
До уровня аутентификации RPC_C_AUTHN_LEVEL_PKT включительно SSP DLL в большей или меньшей мере игнорирует фактическую полезную нагрузку RPC-пакетов и защищает только целостность RPC-заголовков. Для того чтобы убедиться, что состояние маршалированного параметра не изменено вражеским агентом в сети, в RPC предусмотрен уровень аутентификации RPC_C_AUTHN_LEVEL_PKT_INTEGRITY. Этот уровень предписывает SSP DLL вычислять контрольную сумму состояния маршалированного параметра и проверять, что содержимое пакета не было изменено в процессе передачи. Поскольку при этом уровне аутентификации каждый передаваемый байт должен обрабатываться с помощью SSP DLL, она проходит значительно медленнее, чем при уровне RPC_C_AUTHN_LEVEL_PKT, и его следует использовать только в ситуациях, требующих особой защиты.
До уровня аутентификации RPC_C_AUTHN_LEVEL_PKT_INTEGRITY включительно фактическое содержание RPC-пакетов пересылается как открытый текст (например, незашифрованный). Для обеспечения невидимости состояния маршалированного параметра для вражеских агентов сети в RPC предусмотрен уровень аутентификации RPC_C_AUTHN_LEVEL_PKT_PRIVACY. Данный уровень аутентификации предписывает SSP DLL зашифровывать состояние маршалированного параметра до передачи. Подобно всем прочим уровням аутентификации уровень RPC_C_AUTHN_LEVEL_PKT_PRIVACY включает в себя защиту всех уровней ниже себя. Как и в случае RPC_C_AUTHN_LEVEL_PKT_INTEGRITY, каждый передаваемый байт должен обрабатываться SSP DLL, поэтому во избежание излишних издержек этот уровень аутентификации следует использовать только в особых с точки зрения безопасности ситуациях.
Наиболее важной API-функцией в службе безопасности COM является CoInitializeSecurity. Каждый процесс, использующий COM, вызывает CoInitializeSecurity ровно один раз, явно или неявно. Функция CoInitializeSecurity вводит автоматические установки по защите. Эти установки применяются ко всем импортируемым и экспортируемым ссылкам на объекты, за исключением явно переопределенных с использованием дополнительных вызовов API-функций. Чтобы использовать один или нескольких модулей защиты, CoInitializeSecurity конфигурирует используемый исполняемый слой RPC, а также устанавливает уровень аутентификации, принимаемый по умолчанию для процесса. Кроме того, CoInitializeSecurity позволяет вызывающей программе указать, каким пользователям разрешено делать ORPC-запросы на объекты, экспортируемые из текущего процесса. CoInitia1izeSecurity имеет довольно большое число параметров:
HRESULT CoInitializeSecurity(
[in] PSECURITY_DESCRIPTOR pSecDesc, // access control
// контроль за доступом
[in] LONG cAuthSvc, // # of sec pkgs (-1 == use defaults)
// количество модулей защиты (-1 == используем по умолчанию)
[in] SOLE_AUTHENTICATION_SERVICE *rgsAuthSvc, // SSP array
// массив SSP
[in] void *pReserved1, // reserved MBZ
// зарезервировано, должен быть О
[in] DWORD dwAuthnLevel, // auto, AUTHN_LEVEL
// аутентификация AUTHN_LEVEL
[in] DWORD dwImpLevel, // auto. IMP_LEVEL
// аутентификация IMP_LEVEL
[in] void *pReserved2, // reserved MBZ
// зарезервировано, должен быть О
[in] DWORD dwCapabilities, // misc flags
// различные флаги
[in] void *pReserved3 // reserved MBZ
// зарезервировано, должен быть О
);
Некоторые из этих параметров применяются только в тех случаях, когда процесс выступает как экспортер/сервер. Другие – только если процесс действует как импортер/клиент. Остальные применяются в обоих случаях.
Первый параметр функции CoInitializeSecurity, pSecDesc, применим только в случае, когда процесс выступает как экспортер. Этот параметр используется для контроля того, каким принципалам – пользователям или процессам, имеющим учетную запись (principals) – разрешен доступ к объектам, экспортируемым из данного процесса. В деталях этот параметр будет обсужден позже в данной главе. Второй и третий параметры функции CoInitializeSecurity, соответственно cAuthSvc и rgsAuthSvc, используются при работе процесса в качестве экспортера для регистрации одного или нескольких модулей защиты с помощью библиотеки COM. Эти два параметра ссылаются на массив описаний модулей защиты:
typedef struct tagSOLE_AUTHENTICATION_SERVICE {
DWORD dwAuthnSvc; // which authentication package?
// какой модуль защиты?
DWORD dwAuthzSvc; // which authorization service?
// какая служба авторизации?
OLECHAR *pPrincipalName; // server principal name?
// имя серверного принципала?
HRESULT hr; // result of registration
// результат регистрации
} SOLE_AUTHENTICATION_SERVICE;
В Windows NT 4.0 единственной установленной службой аутентификации является RPC_C_AUTHN_WINNT (NTLM). При использовании аутентификации NTLM служба авторизации (authorization service – сервис контроля доступа, определяющий права клиента) должна быть указана как RPC_C_AUTHZ_NONE, а имя серверного принципала не используется и должно быть нулевым[1]. Для тех процессов, которые просто хотят использовать пакет (пакеты) защиты по умолчанию на отдельной машине, следует использовать значения: cAuthSvc, равное -1, и rgsAuthSvc, равное нулю.
Пятый параметр функции CoInitializeSecurity, dwAuthnLevel, применим как к экспортируемым, так и к импортируемым объектным ссылкам. Величина, заданная для этого параметра, устанавливает предельно низкий уровень аутентификации для объектных ссылок, экспортируемых из этого процесса. Это означает, что поступающие ORPC-запросы должны иметь по крайней мере такой уровень аутентификации; в противном случае этот вызов будет отклонен. Эта величина определяет также минимальный уровень аутентификации, используемый новыми интерфейсными заместителями, которые возвращаются API-функциями или методами COM. Создавая новый интерфейсный заместитель во время демаршалинга, COM рассматривает число, обозначающее нижний уровень аутентификации, заданный экспортером, как часть разрешения OXID. Затем COM устанавливает уровень аутентификации нового заместителя равным или нижнему уровню экспортера, или нижнему уровню текущего процесса – в зависимости от того, какой из них выше. Если процесс, импортирующий объектную ссылку, имеет уровень аутентификации ниже, чем экспортирующий процесс, то для установки уровня аутентификации используется нижний уровень экспортера. Такой способ гарантирует, что любые ORPC-запросы, посылаемые интерфейсным заместителем, пройдут через нижний уровень экспортера. Далее в этой главе будет рассмотрено, как с целью более детального контроля можно явным образом изменить уровень аутентификации для отдельного интерфейсного заместителя[2].
Шестой параметр функции CoInitializeSecurity, dwImpLevel применяется для импортируемых объектных ссылок. Величина, определенная для этого параметра, устанавливает уровень заимствования прав (impersonation level), используемый для всех объектных ссылок, которые возвращаются функцией CoUnmarshalInterface. Уровень заимствования прав позволяет одному процессу заимствовать атрибуты защиты у другого процесса и отражает степень доверия, которое клиент испытывает к серверу. Этот параметр должен принимать одно из следующих четырех значений, характеризующих уровень заимствования прав:
enum {
// hide credentials of caller from object
// скрываем от объекта полномочия вызывающей программы
RPC_C_IMP_LEVEL_ANONYMOUS = 1,
// allow object to query credentials of caller
// разрешаем объекту запрашивать полномочия вызывающей программы
RPC_C_IMP_LEVEL_IDENTIFY = 2,
// allow use of caller's credentials up to one-hop away
// разрешаем использовать полномочия вызывающей
// программы не далее одной сетевой передачи
RPC_C_IMP_LEVEL_IMPERSONATE = 3,
// allow use of caller's credentials across multiple hops
// разрешаем использовать полномочия вызывающей
// программы в течение нескольких сетевых передач
RPC_C_IMP_LEVEL_DELEGATE = 4
};
Уровень RPC_C_IMP_LEVEL_ANONYMOUS не позволяет реализации объекта обнаружить идентификатор безопасности вызывающей программы[3]. Уровень доверия RPC_C_IMP_LEVEL_IDENTIFY указывает, что реализация объекта может программно определить идентификатор защиты вызывающей программы. Уровень доверия RPC_C_IMP_LEVEL_IMPERSONATE указывает, что сервер может не только определить идентификатор защиты вызывающей программы, но также выполнить операции на уровне операционной системы с использованием полномочий вызывающей программы. На этом уровне доверия объекты могут использовать полномочия вызывающей программы, но имеют доступ только к локальным ресурсам[4]. В противоположность этому, уровень доверия RPC_C_IMP_LEVEL_DELEGATE разрешает серверу доступ как к локальным, так и к удаленным ресурсам с использованием полномочий вызывающей программы. Этот уровень доверия не поддерживается протоколом аутентификации NTLM, но поддерживается протоколом аутентификации Kerberos.
Восьмой параметр функции CoInitializeSecurity, dwCapabilities применим к импортируемым и к экспортируемым объектным ссылкам. Этот параметр является битовой маской, которая может состоять из нуля или более следующих битов:
typedef enum tagEOLE_AUTHENTICATION_CAPABILITIES {
EOAC_NONE = 0х0,
EOAC_MUTUAL_AUTH = 0х1,
// These are only valid for CoInitializeSecurity
// только эти допустимы для CoInitializeSecurity
EOAC_SECURE_REFS = 0х2,
EOAC_ACCESS_CONTROL = 0х4,
EOAC_APPID = 0х8
} EOLE_AUTHENTICATION_CAPABILITIES;
Взаимная аутентификация (EOAC_MUTUAL_AUTH) под NTLM не поддерживается. Она используется для проверки того, что сервер исполняется как ожидаемый принципал. Ссылки защиты (EOAC_MUTUAL_AUTH) указывают, что распределенные вызовы подсчета ссылок COM будут аутентифицироваться для гарантии того, что никакие вражеские агенты не могут испортить счетчик ссылок, используемый OR и администраторами заглушек для управления жизненным циклом. EOAC_ACCESS_CONTROL и EOAC_APPID используются для управления семантикой первого параметра функции CoInitializeSecurity и будут обсуждаться далее в этой главе.
Как было установлено ранее в этом разделе, CoInitializeSecurity вызывается один раз на процесс, явно или неявно. Приложения, желающие вызвать CoInitializeSecurity явно, должны делать это после первого вызова CoInitializeEx, но перед «первым интересным вызовом COM» (first interesting COM call). Фраза «первый интересный вызов COM» относится к любой API-функции, которой может понадобиться OXID. Сюда относятся CoMarshalInterface и CoUnmarshalInterface, а также любые API-вызовы, неявно вызывающие эти функции. Поскольку вызовы CoRegisterClassObject связывают объекты класса с апартаментами, то CoInitializeSecurity должна быть вызвана до регистрации объектов класса. API-функции активации (например, CoCreateInstanceEx) являются любопытным исключением. Активация API-функций для определенных внутренних классов, которые являются частью COM API (например, глобальная интерфейсная таблица, COM-объект контроля доступа по умолчанию) может быть произведена до вызова CoInitializeSecurity. Тем не менее, функция CoInitializeSecurity должна быть вызвана раньше, чем любые активационные вызовы, которые фактически консультируются с реестром и загружают другие DLL или контактируют с другими серверами. Если приложение не вызывает функцию CoInitializeSecurity явно, то COM вызовет ее неявно в качестве первого интересного вызова COM.
Когда COM вызывает функцию CoInitializeSecurity неявно, она читает значения большинства параметров из реестра. Некоторые из этих параметров содержатся в реестровом ключе, общем для всей машины, в то время как остальные записаны под специфическим AppID данного приложения. Чтобы извлечь AppID приложения, COM ищет имя файла процесса приложения под ключом реестра
HKEY_CLASSES_ROOT\AppID
Если COM находит здесь имя файла, она извлекает AppID из именованной величины AppID:
[HKCR\AppID\ServerOfTheApes.exe]
AppID="{27EE6A4D-DF65-11d0-8C5F-0080C73925BA}"
Если никакого соответствия не существует, то COM считает, что приложение не имеет в реестре специфических установок по защите.
Неявные вызовы CoInitializeSecurity находят первый параметр, pSecDesc, путем поиска сериализованного (приведенного в последовательную форму) дескриптора защиты NT SECURITY_DESCRIPTOR в следующей именованной величине:
[HKCR\AppID\{27EE6A4D-DF65-11d0-8C5F-0080C73925BA}]
AccessPermission=<serialized NT security descriptor>
Если эта именованная величина не найдена, то COM ищет общий для всей машины элемент:
[HKEY_LOCAL_MACHINE\Software\Microsoft\OLE]
DefaultAccessPermission=<serialized NT security descriptor>
Оба этих элемента реестра могут быть легко изменены при помощи DCOMCNFG.ЕХЕ. Если не найден ни один из этих элементов реестра, то COM создаст дескриптор защиты (security descriptor), предоставляющий доступ принципалу только вызывающей программы и встроенной учетной записи SYSTEM. COM использует этот дескриптор защиты, чтобы при помощи Win32 API-функции AccessCheck предоставить или запретить доступ к объектам, экспортированным из данного процесса.
Неявные вызовы CoInitializeSecurity используют для второго и третьего параметров (cAuthSvc и rgsAuthSvc) значения -1 и нуль соответственно, указывая тем самым, что должны использоваться модули защиты, принятые по умолчанию. Неявные вызовы CoInitializeSecurity находят значения для пятого и шестого параметров (dwAuthnLevel и dwImpLevel) в следующем элементе реестра всей машины:
[HKEY_LOCAL_MACHINE\Software\Microsoft\OLE]
LegacyAuthenticationLevel = 0x5
LegacyImpersonationLevel = 0x3
RPC_C_AUTHN_LEVEL_PKT_INTEGRITY и RPC_C_AUTHN_LEVEL_IMPERSONATE принимают числовые значения 5 и 3 соответственно. Если эти именованные величины отсутствуют, то используются значения RPC_C_AUTHN_LEVEL_CONNECT и RPC_C_IMP_LEVEL_IDENTIFY. Из флагов, используемых в восьмом параметре функций CoInitializeSecurity, dwCapabilities, в настоящее время читается из элемента реестра всей машины только флаг EOAC_SECURE_REFS:
[HKEY_LOCAL_MACHINE\Software\Microsoft\OLE]
LegacySecureRefs = "Y"
Если эта именованная величина в наличии и содержит "Y" или "y", то COM будет использовать флаг EOAC_SECURE_REFS; в противном случае используется флаг EOAC_NONE. Каждая из этих традиционных установок аутентификации может быть легко изменена при помощи DCOMCNFG.ЕХЕ.
Программируемая защита
Установки, сделанные при помощи CoInitializeSecurity , называются автоматическими установками защиты, поскольку они автоматически применяются ко всем маршалированным объектным ссылкам. Часто бывает, что небольшому числу объектных ссылок необходимо использовать установки защиты, которые отличаются от установок по умолчанию для всего процесса. Наиболее часто встречающийся сценарий таков: для повышения производительности используется довольно низкий уровень аутентификации, но необходимо зашифровать один определенный интерфейс. Вместо того чтобы принудительно использовать шифрование во всем процессе, предпочтительно применить его к тем объектным ссылкам, для которых это необходимо.
Чтобы позволить разработчикам игнорировать автоматические установки защиты на базе интерфейсных заместителей, администратор заместителей выставляет интерфейс IClientSecurity:
[local, object, uuid(0000013D-0000-0000-C000-000000000046)]
interface IClientSecurity : IUnknown {
// get security settings for interface proxy pProxy
// получаем установки защиты для интерфейсного заместителя
pProxy HRESULT* QueryBlanket([in] IUnknown *pProxy, [out] DWORD *pAuthnSvc, [out] DWORD *pAuthzSvc, [out] OLECHAR **pServerPrincName, [out] DWORD *pAuthnLevel, [out] DWORD *pImpLevel, [out] void **pAuthInfo, [out] DWORD *pCapabilities );
// change security settings for interface proxy pProxy
// изменяем установки защиты для интерфейсного заместителя
pProxy HRESULT SetBlanket([in] IUnknown *pProxy, [in] DWORD AuthnSvc, [in] DWORD AuthzSvc, [in] OLECHAR *pServerPrincName, [in] DWORD AuthnLevel, [in] DWORD ImpLevel, [in] void *pAuthInfo, [in] DWORD Capabilities );
// duplicate an interface proxy
// дублируем интерфейсный заместитель
HRESULT CopyProxy([in] IUnknown *pProxy, [out] IUnknown **ppCopy );
}
Второй, третий и четвертый параметры методов SetBlanket и QueryBlanket соответствуют трем членам структуры данных SOLE_AUTHENTICATION_SERVICE. Под Windows NT 4.0 единственными допустимыми величинами являются соответственно RPC_C_AUTHN_WINNT, RPC_C_AUTHN_NONE и нуль.
Как показано на рис. 6.1, каждый отдельный интерфейсный заместитель имеет свои собственные установки защиты. Метод IClientSecurity::SetBlanket позволяет вызывающей программе изменять эти установки для каждого интерфейсного заместителя по отдельности.
Метод IClientSecurity::QueryBlanket позволяет вызывающей программе прочитать эти установки для отдельного интерфейсного заместителя. В качестве параметров, о которых вызывающая программа не беспокоится, могут быть переданы нулевые указатели. Метод IClientSecurity::СоруРгоху позволяет вызывающей программе копировать интерфейсный заместитель. Это дает возможность делать изменения в копии интерфейса, которая не будет возвращаться при последующих запросах QueryInterface об администраторе заместителей. В идеале установки защиты следовало бы делать только в скопированных интерфейсных заместителях, чтобы изолировать измененный заместитель от нормальной реализации администратора заместителей в QueryInterface ; это также позволило бы нескольким потокам независимо друг от друга изменять полные установки защиты между вызовами метода.
Все параметры методов IClientSecurity::SetBlanket и IClientSecurity::QueryBlanket соответствуют параметрам CoInitializeSecurity с одним значительным исключением. Седьмой параметр (pAuthInfo ) указывает на набор полномочий клиента. Точная форма этих полномочий специфична для каждого модуля безопасности. Для модуля безопасности NTLM этот параметр может указывать на структуру COAUTHIDENTITY:
Чтобы позволить разработчикам игнорировать автоматические установки защиты на базе интерфейсных заместителей, администратор заместителей выставляет интерфейс IClientSecurity:
[local, object, uuid(0000013D-0000-0000-C000-000000000046)]
interface IClientSecurity : IUnknown {
// get security settings for interface proxy pProxy
// получаем установки защиты для интерфейсного заместителя
pProxy HRESULT* QueryBlanket([in] IUnknown *pProxy, [out] DWORD *pAuthnSvc, [out] DWORD *pAuthzSvc, [out] OLECHAR **pServerPrincName, [out] DWORD *pAuthnLevel, [out] DWORD *pImpLevel, [out] void **pAuthInfo, [out] DWORD *pCapabilities );
// change security settings for interface proxy pProxy
// изменяем установки защиты для интерфейсного заместителя
pProxy HRESULT SetBlanket([in] IUnknown *pProxy, [in] DWORD AuthnSvc, [in] DWORD AuthzSvc, [in] OLECHAR *pServerPrincName, [in] DWORD AuthnLevel, [in] DWORD ImpLevel, [in] void *pAuthInfo, [in] DWORD Capabilities );
// duplicate an interface proxy
// дублируем интерфейсный заместитель
HRESULT CopyProxy([in] IUnknown *pProxy, [out] IUnknown **ppCopy );
}
Второй, третий и четвертый параметры методов SetBlanket и QueryBlanket соответствуют трем членам структуры данных SOLE_AUTHENTICATION_SERVICE. Под Windows NT 4.0 единственными допустимыми величинами являются соответственно RPC_C_AUTHN_WINNT, RPC_C_AUTHN_NONE и нуль.
Как показано на рис. 6.1, каждый отдельный интерфейсный заместитель имеет свои собственные установки защиты. Метод IClientSecurity::SetBlanket позволяет вызывающей программе изменять эти установки для каждого интерфейсного заместителя по отдельности.
Метод IClientSecurity::QueryBlanket позволяет вызывающей программе прочитать эти установки для отдельного интерфейсного заместителя. В качестве параметров, о которых вызывающая программа не беспокоится, могут быть переданы нулевые указатели. Метод IClientSecurity::СоруРгоху позволяет вызывающей программе копировать интерфейсный заместитель. Это дает возможность делать изменения в копии интерфейса, которая не будет возвращаться при последующих запросах QueryInterface об администраторе заместителей. В идеале установки защиты следовало бы делать только в скопированных интерфейсных заместителях, чтобы изолировать измененный заместитель от нормальной реализации администратора заместителей в QueryInterface ; это также позволило бы нескольким потокам независимо друг от друга изменять полные установки защиты между вызовами метода.
Все параметры методов IClientSecurity::SetBlanket и IClientSecurity::QueryBlanket соответствуют параметрам CoInitializeSecurity с одним значительным исключением. Седьмой параметр (pAuthInfo ) указывает на набор полномочий клиента. Точная форма этих полномочий специфична для каждого модуля безопасности. Для модуля безопасности NTLM этот параметр может указывать на структуру COAUTHIDENTITY: