Utilisation de l'authentification par défaut et de les séparer de camouflage/usurpation d'identité en appel DCOM

Question

Je suis en train de réaliser deux choses avec DCOM (de processus)

1. Définir le processus d'authentification à l'échelle à l'aide de CoInitializeSecurity et son paramètre pAuthList.
2. À l'aide de la dissimulation de changer l'identité de l'appelant dans des situations particulières (appels COM)

Mes pensées:

1. Autant que je sache, la auth info structure contient par défaut les informations d'authentification (comme le nom d'utilisateur et le mot de passe pour RPC_C_AUTHN_WINNT) pour tous les nouveaux appels COM. Ainsi, au lieu de le jeton de processus l'information dans l'auth structure doit être utilisé par COM. Cependant, tous les appels COM/connexions sont toujours à l'aide de l'identité du processus au lieu de l'appliquer par défaut.

2. Généralement, on peut utiliser CoSetProxyBlanket pour changer la auth info pour un proxy. Cela fonctionne pour moi. Ma question ici est de savoir si elle doit ou ne doit pas travailler si je emprunter l'identité de l'jeton de moi et d'appeler la fonction COM. J'ai lu dans divers articles MSDN que l'application de EOAC_DYNAMIC_CLOAKING à CoInitializeSecurity devrait le faire fonctionner. Cependant, mon manuellement "avec emprunt d'identité appels COM affiche toujours l'identité de processus sur le côté serveur.

Le client ressemble à ceci (Delphi)

var
authList : SOLE_AUTHENTICATION_LIST;
authidentity : SEC_WINNT_AUTH_IDENTITY_W;
authInfo : array[0..1] of SOLE_AUTHENTICATION_INFO;

pcAuthSvc : DWORD;
asAuthSvc : array[0..0] of SOLE_AUTHENTICATION_SERVICE;
Token : TJwSecurityToken;

begin
ZeroMemory( @authidentity, sizeof(authidentity) );

authidentity.User := 'Testbenutzer';
authidentity.UserLength := Length('Testbenutzer');
authidentity.Domain := '';
authidentity.DomainLength := 0;
authidentity.Password := 'test';
authidentity.PasswordLength := 4;
authidentity.Flags := SEC_WINNT_AUTH_IDENTITY_UNICODE;


ZeroMemory( @authInfo, sizeof( authInfo ) );

// NTLM Settings
authInfo[0].dwAuthnSvc := RPC_C_AUTHN_WINNT;
authInfo[0].dwAuthzSvc := RPC_C_AUTHZ_NONE;
authInfo[0].pAuthInfo := @authidentity;



authList.cAuthInfo := 1;
authList.aAuthInfo := @authInfo;

OleCheck(CoInitializeSecurity(
  NULL,                            // Security descriptor
  -1,                              // Count of entries in asAuthSvc
  NULL,                            // asAuthSvc array
  NULL,                            // Reserved for future use
  RPC_C_AUTHN_LEVEL_CONNECT,       // Authentication level
  RPC_C_IMP_LEVEL_IMPERSONATE,     // Impersonation level
  @authList,                       // Authentication Information
  DWORd(EOAC_DYNAMIC_CLOAKING),                       // Additional capabilities
  NULL                             // Reserved
  ));
//create COM object
int := CoSecurityTestObj.Create;
int.TestCall;

Par ailleurs, le serveur a mis le drapeau EOAC_DYNAMIC_CLOAKING. Il utilise CoImpersonateClient pour obtenir le jeton de thread et le nom d'utilisateur. Il utilise également CoQueryClientBlanket pour obtenir le authInfo (comme SEC_WINNT_AUTH_IDENTITY_W structure). Cependant, les deux appels de toujours ramener le processus de l'identité du client.

Aussi usurpation de l'identité d'manuellement ne fonctionne pas (2.):

Token := TJwSecurityToken.CreateLogonUser(authidentity.User, '', authidentity.Password, LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT);
 Token.ImpersonateLoggedOnUser;
 int := CoSecurityTestObj.Create;
 int.TestCall;

Questions:

1. Suis-je tort ou raison est la valeur par défaut auth info de la structure (WinNT avec le nom d'utilisateur et mot de passe) de ne pas utiliser l'authentification par défaut dans chaque connexion COM/appel ?

2. Suis-je tort ou raison n'a pas de manuel d'emprunt d'identité de travail? Sachez que j'ai testé numéro 2. séparément afin de numéro 1. ne peut pas interférer.

C'est la base de travail pour les JEDI Windows Code de Sécurité de la Bibliothèque, que j'étends à l'appui de la sécurité COM. Donc votre aide ira à GPL/MPL.

Références:

Cloaking:

1. http://msdn.microsoft.com/en-us/library/ms683778%28VS.85%29.aspx
2. http://msdn.microsoft.com/en-us/library/cc246058%28PROT.10%29.aspx
3. http://alt.pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsCoInitializeSecurity.html

CoInitializeSecurity et pAuthInfo

1. http://www.codeguru.cn/vc&mfc/apracticalguideusingvisualcandatl/93.htm

L'obtention de couverture de sécurité (côté serveur)

1. http://www.codeguru.cn/vc&mfc/apracticalguideusingvisualcandatl/92.htm

Answer 1

Avez-vous essayé d'appeler CoInitializeSecurity() avec RPC_C_AUTHN_LEVEL_CALL au lieu de RPC_C_AUTHN_LEVEL_CONNECT?

Habituellement, lorsque je créer des clients DCOM-je créer COSERVERINFO et passer à CoCreateInstanceEx() avec les informations d'identification de sécurité, en se souvenant de l'appel CoSetProxyBlanket() sur toutes les interfaces.