Próbuję osiągnąć dwie rzeczy z DCOM (na zewnątrz procesu)Użyj domyślnego uwierzytelniania i oddzielny maskowanie/personifikacji w DCOM rozmowy
- Ustaw szeroki uwierzytelniania proces wykorzystujący CoInitializeSecurity i jego parametrów pAuthList.
- Korzystanie maskowanie zmienić tożsamość dzwoniącego w szczególnych sytuacjach (połączenia COM)
myśli moje
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.
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:
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?
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:
- http://msdn.microsoft.com/en-us/library/ms683778%28VS.85%29.aspx
- http://msdn.microsoft.com/en-us/library/cc246058%28PROT.10%29.aspx
- http://alt.pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsCoInitializeSecurity.html
CoInitializeSecurity i pAuthInfo
Pierwsze koc bezpieczeństwa (po stronie serwera)
Rozwiązany numer # 2. Stała wartość EOAC_DYNAMIC_CLOAKING została błędnie zdefiniowana. * stupidme * – ChristianWimmer
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