Внедрение пользовательского пакета проверки подлинности Windows — LsaApUserLogonEx

Я работал над пакетом аутентификации LSA для внедрения моего пользовательского механизма входа в Windows 10. До сих пор мне удалось зарегистрировать пакет аутентификации и получить метод LsaLogonUserEx, вызываемый LSA. Теперь я застрял на том, как подготовить параметры OUT метода LsaApLogOnUser.

NTSTATUS NTAPI
LsaApLogonUserEx(
IN PLSA_CLIENT_REQUEST ClientRequest,
IN SECURITY_LOGON_TYPE LogonType,
IN PVOID ProtocolSubmitBuffer,
IN PVOID ClientBufferBase,
IN ULONG SubmitBufferSize,
OUT PVOID *ProfileBuffer,
OUT PULONG ProfileBufferSize,
OUT PLUID LogonId,
OUT PNTSTATUS SubStatus,
OUT PLSA_TOKEN_INFORMATION_TYPE TokenInformationType,
OUT PVOID *TokenInformation,
OUT PUNICODE_STRING *AccountName,
OUT PUNICODE_STRING *AuthenticatingAuthority,
OUT PUNICODE_STRING *MachineName
);

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


c windows-authentication winapi winlogon local-security-authority
person Manan    schedule 18.06.2018    source источник
comment
Вы не читали описания параметров в MSDN? Буфер профиля - это все, что вы хотите, а токен должен быть структурой, которую вы видите в MSDN.   -  person Anders    schedule 19.06.2018
comment
@ Андерс Я читал документацию MSDN, но она дает только краткое описание этих параметров и не дает никакой информации о содержании этих структур. Например, каким будет содержимое этих буферов, которые должен заполнить пакет аутентификации. Это то, что я отстой.   -  person Manan    schedule 19.06.2018

Ответы (1)


arrow_upward
0
arrow_downward

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

  • TokenInformation. Тип возвращаемой структуры определяется параметром TokenInformationType, который вы также задаете самостоятельно. Итак, в конце концов вы определяете, какой тип структуры вы возвращаете. Вот список возможных типов и связанных структур. По сути, это либо LSA_TOKEN_INFORMATION_V1, либо LSA_TOKEN_INFORMATION_NULL.

  • ProfileBuffer: обратите внимание на документацию «Содержимое этого буфера определяется пакетом проверки подлинности». Таким образом, вы добавляете туда все, что считаете полезным для вашего провайдера/аутентификации. Просто убедитесь, что (цитата из документации) «Пакет проверки подлинности отвечает за выделение буфера ProfileBuffer в клиентском процессе путем вызова функции AllocateClientBuffer».

В общем, документация для LsaApLogonUserEx говорит некоторые вещи о том, когда вам (как пакету) нужно выделить (или освободить!) аргументы/память и когда LSA сделает это за вас. Он также делает это для параметров, которые вас особенно беспокоят.

Последний пункт также является причиной, по которой вам нужно использовать функцию AllocateClientBuffer для аргумента ProfileBuffer: чтобы LSA мог использовать соответствующую «свободную» функцию и не повредить память.

person Christian.K    schedule 20.06.2018