2010-01-03 23 views
43

Próbuję osiągnąć dwie rzeczy z DCOM (na zewnątrz procesu)Użyj domyślnego uwierzytelniania i oddzielny maskowanie/personifikacji w DCOM rozmowy

  1. Ustaw szeroki uwierzytelniania proces wykorzystujący CoInitializeSecurity i jego parametrów pAuthList.
  2. Korzystanie maskowanie zmienić tożsamość dzwoniącego w szczególnych sytuacjach (połączenia COM)

myśli moje

  1. AFAIK struktury informacji uwierzytelniania zawiera informacje uwierzytelniania domyślne (jak nazwa użytkownika i hasło RPC_C_AUTHN_WINNT) dla wszystkich nowych połączeń COM. Dlatego zamiast tokena procesu informacje w strukturze uwierzytelnienia powinny być używane przez COM. Jednak wszystkie wywołania/połączenia COM zawsze używają tożsamości procesu zamiast zastosowanej wartości domyślnej.

  2. Zazwyczaj można użyć CoSetProxyBlanket do zmiany informacji o autorze dla proxy. To działa dla mnie. Moje pytanie dotyczy tego, czy musi działać, czy nie, jeśli podaję się samemu tokenowi i wzywam funkcję COM. Czytałem w różnych artykułach MSDN, że zastosowanie EOAC_DYNAMIC_CLOAKING do CoInitializeSecurity powinno go uruchomić. Jednak moje ręcznie „wcieliła COM wywołuje zawsze pokazuje tożsamość procesu po stronie serwera.

Klient wygląda następująco (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; 

Serwer posiada również ustawić flagę EOAC_DYNAMIC_CLOAKING. It używa CoImpersonateClient, aby uzyskać token wątku i nazwę użytkownika, a także używa CoQueryClientBlanket do uzyskania struktury authInfo (jako struktury SEC_WINNT_AUTH_IDENTITY_W), jednak oba wywołania zawsze zwracają tożsamość procesu klienta:

Podszywanie się ręczne nie działa (2.):

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

Pytania ponownie:

  1. Mylę lub dlaczego jest struktura informacji domyślnego auth (WinNT się podając nazwę użytkownika i hasło) nie jest używany jako domyślny w uwierzytelnianiu każde połączenie/połączenie COM?

  2. Czy jestem w błędzie lub dlaczego nie działa podszywanie się pod osoby fizyczne? Pamiętaj, że testowałem numer 2. oddzielnie, więc numer 1. nie może przeszkadzać.

Jest to podstawowa praca dla biblioteki kodu bezpieczeństwa systemu Windows JEDI, którą rozszerzam o obsługę zabezpieczeń COM. Więc twoja pomoc przejdzie na GPL/MPL.

Odniesienia:

zasłaniające:

  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 i pAuthInfo

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

Pierwsze koc bezpieczeństwa (po stronie serwera)

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

Rozwiązany numer # 2. Stała wartość EOAC_DYNAMIC_CLOAKING została błędnie zdefiniowana. * stupidme * – ChristianWimmer

+0

W przypadku 1. powinien używać bieżącej tożsamości, ale tylko wtedy, gdy jest w stanie ją delegować, co jest tylko w środowisku domenowym Kerberos. Również tożsamość procesu musi być "zaufana dla delegacji". Jeśli istnieje zdalny klient i próbujesz nawiązać połączenie z innym serwerem (2 przeskoki), starsze uwierzytelnianie NTLM na to nie pozwoli. – Ben

Odpowiedz

1

Czy próbowałeś dzwoniąc CoInitializeSecurity() z RPC_C_AUTHN_LEVEL_CALL zamiast RPC_C_AUTHN_LEVEL_CONNECT?

Zwykle podczas tworzenia klientów DCOM tworzę COSERVERINFO i przekazuję do CoCreateInstanceEx() z poświadczeniami bezpieczeństwa, pamiętając o wywołaniu CoSetProxyBlanket() na wszystkich interfejsach.

Powiązane problemy