CoInitializeSecurity function (combaseapi.h)

Registers security and sets the default security values for the process.

Syntax

Parameters

The access permissions that a server will use to receive calls. This parameter is used by COM only when a server calls CoInitializeSecurity. Its value is a pointer to one of three types: an AppID, an IAccessControl object, or a SECURITY_DESCRIPTOR, in absolute format. See the Remarks section for more information.

The count of entries in the asAuthSvc parameter. This parameter is used by COM only when a server calls CoInitializeSecurity. If this parameter is 0, no authentication services will be registered and the server cannot receive secure calls. A value of -1 tells COM to choose which authentication services to register, and if this is the case, the asAuthSvc parameter must be NULL. However, Schannel will never be chosen as an authentication service by the server if this parameter is -1.

An array of authentication services that a server is willing to use to receive a call. This parameter is used by COM only when a server calls CoInitializeSecurity. For more information, see SOLE_AUTHENTICATION_SERVICE.

This parameter is reserved and must be NULL.

The default authentication level for the process. Both servers and clients use this parameter when they call CoInitializeSecurity. COM will fail calls that arrive with a lower authentication level. By default, all proxies will use at least this authentication level. This value should contain one of the authentication level constants. By default, all calls to IUnknown are made at this level.

The default impersonation level for proxies. The value of this parameter is used only when the process is a client. It should be a value from the impersonation level constants, except for RPC_C_IMP_LEVEL_DEFAULT, which is not for use with CoInitializeSecurity.

Outgoing calls from the client always use the impersonation level as specified. (It is not negotiated.) Incoming calls to the client can be at any impersonation level. By default, all IUnknown calls are made with this impersonation level, so even security-aware applications should set this level carefully. To determine which impersonation levels each authentication service supports, see the description of the authentication services in COM and Security Packages. For more information about impersonation levels, see Impersonation.

A pointer to SOLE_AUTHENTICATION_LIST, which is an array of SOLE_AUTHENTICATION_INFO structures. This list indicates the information for each authentication service that a client can use to call a server. This parameter is used by COM only when a client calls CoInitializeSecurity.

Additional capabilities of the client or server, specified by setting one or more EOLE_AUTHENTICATION_CAPABILITIES values. Some of these value cannot be used simultaneously, and some cannot be set when particular authentication services are being used. For more information about these flags, see the Remarks section.

This parameter is reserved and must be NULL.

Return value

This function can return the standard return value E_INVALIDARG, as well as the following values.

Return code	Description
S_OK	Indicates success.
RPC_E_TOO_LATE
RPC_E_NO_GOOD_SECURITY_PACKAGES	The asAuthSvc parameter was not NULL, and none of the authentication services in the list could be registered. Check the results saved in asAuthSvc for authentication service–specific error codes.
E_OUT_OF_MEMORY	Out of memory.

Remarks

The CoInitializeSecurity function initializes the security layer and sets the specified values as the security default. If a process does not call CoInitializeSecurity, COM calls it automatically the first time an interface is marshaled or unmarshaled, registering the system default security. No default security packages are registered until then.

This function is called exactly once per process, either explicitly or implicitly. It can be called by the client, server, or both. For legacy applications and other applications that do not explicitly call CoInitializeSecurity, COM calls this function implicitly with values from the registry. If you set processwide security using the registry and then call CoInitializeSecurity, the AppID registry values will be ignored and the CoInitializeSecurity values will be used.

CoInitializeSecurity can be used to override both computer-wide access permissions and application-specific access permissions, but not to override the computer-wide restriction policy.

If pSecDesc points to an AppID, the EOAC_APPID flag must be set in dwCapabilities and, when the EOAC_APPID flag is set, all other parameters to CoInitializeSecurity are ignored. CoInitializeSecurity looks for the authentication level under the AppID key in the registry and uses it to determine the default security. For more information about how the AppID key is used to set security, see Setting Process-Wide Security Through the Registry.

If pSecDesc is a pointer to an IAccessControl object, the EOAC_ACCESS_CONTROL flag must be set and dwAuthnLevel cannot be none. The IAccessControl object is used to determine who can call the process. DCOM will AddRef the IAccessControl and will Release it when CoUninitialize is called. The state of the IAccessControl object should not be changed.

If pSecDesc is a pointer to a SECURITY_DESCRIPTOR, neither the EOAC_APPID nor the EOAC_ACCESS_CONTROL flag can be set in dwCapabilities. The owner and group of the SECURITY_DESCRIPTOR must be set, and until DCOM supports auditing, the system ACL must be NULL. The access-control entries (ACEs) in the discretionary ACL (DACL) of the SECURITY_DESCRIPTOR are used to find out which callers are permitted to connect to the process’s objects. A DACL with no ACEs allows no access, while a NULL DACL will allow calls from anyone. For more information on ACLs and ACEs, see Access Control Model. Applications should call AccessCheck (not IsValidSecurityDescriptor) to ensure that their SECURITY_DESCRIPTOR is correctly formed prior to calling CoInitializeSecurity.

Passing pSecDesc as NULL is strongly discouraged. An appropriate alternative might be to use a SECURITY_DESCRIPTOR that allows Everyone. If pSecDesc is NULL, the flags in dwCapabilities determine how CoInitializeSecurity defines the access permissions that a server will use, as follows:

• If the EOAC_APPID flag is set, CoInitializeSecurity will look up the application’s .exe name in the registry and use the AppID stored there.
• If the EOAC_ACCESS_CONTROL flag is set, CoInitializeSecurity will return an error.
• If neither the EOAC_APPID flag nor the EOAC_ACCESS_CONTROL flag is set, CoInitializeSecurity allows all callers including Local and Remote Anonymous Users.

The CoInitializeSecurity function returns an error if both the EOAC_APPID and EOAC_ACCESS_CONTROL flags are set in dwCapabilities.

Невозможно инициализировать CoInitializeSecurity после вызова CFileDialog

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

В общем как то так:
1) Создал проект с окном в VS2008 c++ DialogBased — MFC (в общем как то так)
2) Повесил 2 кнопки, одна типа открыть диалог — Вторая сделать инициализацию COM (мне нужно WMI)
Так вот, если хоть 1000 раз клацать вторую кнопку, то все ОК. Но вот если хоть раз вызвать FileDialog, то инициализация уже не проиcходит.
Куски кода прилагаю:

1) Вызов Диалога открытия файла

(MFC) После вызова CFileDialog окно выглядит неактивным
Вызываю по пункту меню диалог открытия файла таким образом: CFileDialog dlg(true); int.

Невозможно применить семейство Request.Form после вызова BinaryRead
Добрый день, подскажите, кто знает! Загружаю с помощью кода файл, после чего пытаюсь получить.

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

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

Добавлено через 3 минуты
а. пардон. это я просто про CoInitializeEx. что касается CoInitializeSecurity — а зачем страдать — вызовете ее до диалога

Добавлено через 43 секунды
кстати я всегда использую

Делал CoUnInitialize. В общем ничего не помогает.
CoInitializeSecurity возвращает (RPC_E_TOO_LATE) типа повторная инициализация, код GetLastError возвращает 1008.(ERROR_NO_TOKEN 1008 (0x3F0)
An attempt was made to reference a token that does not exist.)

Реально не могу понять что за ерунда. FileDialog это походу COM, и я так понимаю после закрытия он не делает CoUnitialize. Можно ли как то принудительно сделать анинит ФайлДиалога?

Насчет вызывать до ФайлДиалога, я так и сделал. Но это тоже как бы ерунда какая то. Там функция такая что ее можно вызвать 1 раз(WMI опрос конфигурации). Если ее вызвать еще раз, то все падает. Оно то конечно можно сделать обертку для этого в каком то глобальном классе, инициализировать все в самом начале программы, но я так понимаю то тогда я UnInit тоже не смогу сделать и тогда проблема может возникнуть с каким нибуть другим COM.
Либо действительно ФайлДиалог где то юзает WMI и не закрывает его. Попробую сейчас открыть ине закрыть свой WMI и вызвать файл Диалог.
Попробовал, файл диалог нормально открывается, значит он как то все закрывает. Мож кто знает как такое сделать.

Попробовал вызвать с Вашими параметрами:

Unable to call coinitializesecurity windows 10

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

I’m in trouble about DCOM server & client system in Vista.

When the Client try to call a procedure in a remote DCOM server,

CoInitializeSecurity(client side) is failed by «RPC_E_TOO_LATE».

By MSDN document it occurs when CoInitializeSecurity() has been

already called. But in this case it had never been called in a same process.

I have this problem only in Vista OS. It worked correctly in XP and 2003ServerR2.

If anybody have a good suggestion, please tell me.

Answers

DCOM, is not my area of expertise, but you are correct MSDN says «Security must be initialized before any interfaces are marshaled or unmarshaled. It cannot be changed once it is initialized.» Also says that its a result of » CoInitializeSecurity has already been called.»

CoInitializedSecuirty can be called on the client, the server, or both and should be OK. Just curious are you calling it on both?

MSDN also says
«For legacy applications and other applications that do not explicitly call CoInitializeSecurity, COM calls this function implicitly with values from the registry. If you set processwide security using the registry and then call CoInitializeSecurity, the AppID registry values will be ignored and the CoInitializeSecurity values will be used.»

Is it possible that CoInitialized is getting called automatically and its using registry settings? Have you tried you code with out calling CoInitializeSecurity, this would indicate that it may have already been automatically called.

One last question I have is: Do you know the permissions at which your Client and Server are running as?

I really appreciate your quick reply.

>CoInitializedSecuirty can be called on the client, the server,
>or both and should be OK. Just curious are you calling it on both?

In this system, CoInitializeSecurity is called only in a client.
The program call this API to set the authentic information which is
not depending on who execute(or logged in), to connect DCOM server.

>Is it possible that CoInitialized is getting called automatically
>and its using registry settings? Have you tried you code with out calling
>CoInitializeSecurity, this would indicate that it may have already been
>automatically called.

Your suggestion is interesting. Because before calling CoInitializeSecurity,
the program called CoCreateInstanceEx once to try to connect DCOM server
in a default security settings. The detail of this sequence is as follows.

hr = CoCreateInstanceEx(. )
if(FAILED(hr)<

. security settings for SOLE_AUTHENTICATION_INFOs .

If CoInitializeSecurity called automatically by first calling CoCreateInstanceEx(),
it would be cause of error RPC_E_TOO_LATE.
But if the cause of error is exactly this, I wonder why this program worked
in XP and 2003ServerR2 without any errors ?
Is there any changes at CoInitializeSecurity API in Vista?

>Do you know the permissions at which your Client and Server are running as?

DCOM server running as Administrator of local machine which DCOM server is installed.
Client running as Administrator of local machine.
And I tried privilege elevation for client program (by manifest and «Run as» settings in GUI),
but it appeared same error.

First I try to make debug version of this program which is without calling
CoInitializeSecurity and make sure that CoInitializeSecurity is called automatically or not.