Soru DCOM çağrısı için varsayılan kimlik doğrulaması ve ayrı gizleme / kimliğe bürünme kullanma


DCOM ile (işlem dışı) iki şey başarmaya çalışıyorum

  1. CoInitializeSecurity ve pAuthList parametresini kullanarak işlem genişliğini doğrulayın.
  2. Özel durumlarda arayanın kimliğini değiştirmek için gizleme kullanma (COM çağrıları)

Düşüncelerim:

  1. AFAIK kimlik bilgisi yapısı tüm yeni COM çağrıları için varsayılan kimlik doğrulama bilgilerini (RPC_C_AUTHN_WINNT için kullanıcı adı ve şifre gibi) içerir. Bu nedenle, auth yapısındaki bilgileri belirtmek yerine COM tarafından kullanılmalıdır. Ancak, tüm COM çağrıları / bağlantıları her zaman uygulanan varsayılanın yerine 'kimlik' işlemini kullanır.

  2. Genellikle, bir proxy için kimlik bilgisini değiştirmek için CoSetProxyBlanket'i kullanabilir. Bu benim için çalışıyor. Buradaki sorum, belirtimi kendim belirlediğimde ve COM işlevini çağırırsam çalışmamın veya çalışmamam gerekip gerekmediğidir. Çeşitli MSDN makalelerinde, CoInitializeSecurity için EOAC_DYNAMIC_CLOAKING uygulanmasının çalışmasını sağlamalı. Ancak, el ile "kimliğine bürünmüş COM çağrılarım her zaman sunucu tarafında işlem kimliğini gösterir.

Müşteri buna benziyor (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;

Sunucu ayrıca EOAC_DYNAMIC_CLOAKING bayrağını da ayarladı. Iş parçacığı belirteci ve kullanıcı adı almak için CoImpersonateClient kullanır. Ayrıca authInfo (SEC_WINNT_AUTH_IDENTITY_W yapısı) almak için CoQueryClientBlanket kullanır. Ancak her iki çağrı da daima müşterinin süreç kimliğini döndürür.

Ayrıca el ile kimliğine bürünme çalışmaz (2):

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

Tekrar sorular:

  1. Yanlış mıyım yoksa neden varsayılan auth bilgi yapısı (kullanıcı adı ve parola ile WinNT) her COM bağlantısında / çağrısında varsayılan kimlik doğrulama olarak kullanılmıyor?

  2. Yanlış mıyım yoksa manuel kimliğe bürünme neden çalışmıyor? Sayı 2'yi test ettiğimin farkında olun, böylece 1. sayıya müdahale edemezsiniz.

Bu, COM güvenliğini desteklemek için genişletdiğim JEDI Windows Güvenlik Kodu Kitaplığı için temel çalışmadır. Böylece yardımınız GPL / MPL'ye gidecek.

Referanslar:

Gizleme:

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

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

Güvenlik battaniyesi alma (sunucu tarafı)

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

43
2018-01-03 01:55


Menşei


Çözülen sayı # 2. Sabit EOAC_DYNAMIC_CLOAKING yanlış tanımlandı. aptal ben - ChristianWimmer
Durum 1'de geçerli kimliğini kullanmalıdır, ancak yalnızca bir Kerberos ve diğer bir deyişle etki alanı ortamında bu yetki verilebilirse. Ayrıca süreç kimliği "delegasyon için güvenilir" olmalıdır. Uzak bir istemci varsa ve başka bir sunucuya (2 atlama) çağırmaya çalışıyorsanız, eski NTLM kimlik doğrulaması buna izin vermez. - Ben


Cevaplar:


RPC_C_AUTHN_LEVEL_CONNECT yerine RPC_C_AUTHN_LEVEL_CALL ile CoInitializeSecurity () aramayı denediniz mi?

Genellikle DCOM istemcileri oluşturduğumda, COSERVERINFO oluşturur ve tüm arabirimlerdeki CoSetProxyBlanket () öğesini çağırmayı hatırlayarak güvenlik kimlik bilgileriyle CoCreateInstanceEx () öğesine geçiririm.


1
2018-01-31 16:27