MSDN TechTalk – Januar 2001 COM(+) Security 1 Christof Sprenger Partner Group Microsoft GmbH chrispre@microsoft.com

Agenda Security Grundlagen Windows Security Architektur COM+ Security Architektur Do’s & Don’ts

Abschnitt 1 Security Grundlagen

MSDN TechTalk – Januar 2001 COM(+) Security 4 „Definition“ MSDN TechTalk – Januar 2001 COM(+) Security 4 Security ist: „Definieren und Durchsetzen von Grenzen des Vertrauens “ (defining and enforcing boundaries of trust)

MSDN TechTalk – Januar 2001 COM(+) Security 5 „Definition“ MSDN TechTalk – Januar 2001 COM(+) Security 5 Kurze Definition von Security: wer (identity  Authentifizierung) tut was (Zweck/Absicht) mit wem oder was (Privilege  Authorisation)

Security Grundlagen: Begriffe MSDN TechTalk – Januar 2001 COM(+) Security 6 „Principal“  Eine Identität (Sie oder Ihr PC) „Credentials“  Daten um Identität zu beweisen „Trust“  Den Credentials vertrauten „Authority“  Der, der für Principals bürgt „Privilege“  Das Recht etwas zu tun

Security Grundlage: Abkürzungen SID  Security Identifier SD  Security Descriptor ACL  Access Control List ACE  Access Control Entry SSP  Security Support Provider NTLM  Windows NT LAN-Manager

Abschnitt 2 Windows Security Architektur

Windows Security Architektur MSDN TechTalk – Januar 2001 COM(+) Security 9 Authentifizierung Access Token Security Identifier Logon Session Authorisation Privileges / User Rights Access Control List (ACL) Security Descriptors (SD)

MSDN TechTalk – Januar 2001 COM(+) Security 10 Authentifizierung 1/2 MSDN TechTalk – Januar 2001 COM(+) Security 10 Die Frage ist: “Wer bist du?” „Credentials“ werden beim Logon überprüft Credentials sind: User/Password oder Smartcard Erfolgreiches Logon erzeugt ein eine Logon Session und ein Access-Token Access Token dient als Zutrittsausweis

MSDN TechTalk – Januar 2001 COM(+) Security 11 Authentifizierung 2/2 MSDN TechTalk – Januar 2001 COM(+) Security 11 Logging on... Logon Process (winlogon.exe) Win32 Subsystem (system) Create process With access token CTRL-ALT-DEL Create Access token Security Subsystem (LSA) (lsass.exe) Check Credentials (USER/PASS) Validate user Add group info Run Shell (explorer.exe) Authentication package Security Account Manager DB (SAM)

Access Token Bestandteile MSDN TechTalk – Januar 2001 COM(+) Security 12 User SID Group SIDs Privileges Default für neue Objekte (z.B. Dateien, Pipes, Shared Memory ....) Logon Session ID ...

MSDN TechTalk – Januar 2001 COM(+) Security 13 Security Identifier MSDN TechTalk – Januar 2001 COM(+) Security 13 Eindeutig (etwa so wie UUID) S-1-5-21-36789224-869469349-550402555 Variabel in der Länge Revision (1) Identifier - Authority (5) Sub-authorities (21, 36789224, ...) Verschiedene Arten von SID User SID Group SID Well known SID’s

MSDN TechTalk – Januar 2001 COM(+) Security 14 Logon-Sessions MSDN TechTalk – Januar 2001 COM(+) Security 14 5 Arten von logon-session SYSTEM Enthält alle Prozesse, die Teil des OS sind INTERACTIVE Für den interaktiv angemeldeten Benutzer NETWORK Entsteht durch authentifizierten Zugriff auf den Rechner über das Netzwerk SERVICE Für NT Dienste, die mit einem bestimmten Benutzerkonto konfiguriert wurden BATCH Für Prozesse die durch die COM Runtime getartet wurden

Logon-Sessions INTERACTIVE NETWORK BATCH & SERVICE credentials cached nein profile loaded ja token primary impersonation

Logon Sessions Beispiel JoesMachine AlicesMachine Bob‘s Service logon session Bob‘s network logon session Teds‘s network logon session Alice‘s network logon session Alice‘s interactive logon session TedsMachine Teds‘s interactive logon session

Impersonation Ein (Server-)Prozess verrichtet oft Arbeit für verschiedene Benutzer Daher kann jedem Thread eine eigenes Access Token zugeordnet werden Es gibt also zwei Arten von Access Token Primary Token (für Prozesse) Impersonation Token (für Threads)

Impersonation im Bild server.exe Joe client.exe Alice Alice client.exe Bob

MSDN TechTalk – Januar 2001 COM(+) Security 19 Authorization MSDN TechTalk – Januar 2001 COM(+) Security 19 Frage ist: “Was darfst du tun?” Auch: Access Check oder Access Control Wird bestimmt durch: Art des gewünschten Zugriffs Access-Token (des aktuellen Threads) Access Control List (ACL) aus dem Security Descriptor des Objekts

MSDN TechTalk – Januar 2001 COM(+) Security 20 Access Control Lists MSDN TechTalk – Januar 2001 COM(+) Security 20 DACL ACE Everyone Read ACE „chrispre“Full Control ACE SYSTEM Full Control Administrators Full Control ACE

MSDN TechTalk – Januar 2001 COM(+) Security 21 Security Descriptor MSDN TechTalk – Januar 2001 COM(+) Security 21 Owner SID Group SID (POSIX) SACL DACL Permitted users Permissions

MSDN TechTalk – Januar 2001 COM(+) Security 22 Authorisation im Bild MSDN TechTalk – Januar 2001 COM(+) Security 22 SomeObject Security-Descriptor Check! Process/Thread OpenSomeObject() Access-Token SRM (Security- Reference- Monitor) Access? User SID „chrispre” Group SIDs Privileges Token DACL SD ACE „chrispre“: Full OK!

Netzwerk Authentifizierung Wie entsteht auf einem entfernten Rechner eine Logon Session, die den Benutzer repräsentiert, der über das Netzwerk zugreift? Das Kennwort darf nicht einfach über das Netzwerk versendet werden Die Bits und Bytes, die das Access Token bilden dürfen ebenfalls nicht versendet werden

NTLM mit Local Accounts MSDN TechTalk – Januar 2001 COM(+) Security 24 Client Server lsass.exe 4. 5. 1. Negotiate client.exe server.exe 2. Challenge 3. Response

NTLM mit Domain Accounts MSDN TechTalk – Januar 2001 COM(+) Security 25 Authority 0. 5. 6. Client Server lsass.exe 4. 7. 1-3 client.exe server.exe

NTLM über Domänengrenzen MSDN TechTalk – Januar 2001 COM(+) Security 26 Domain A Domain B Authority A Authority B Client Server lsass.exe client.exe server.exe

MSDN TechTalk – Januar 2001 COM(+) Security 27 Kerberos MSDN TechTalk – Januar 2001 COM(+) Security 27 Authority 1. 2. Server Client 3.

Abschnitt 3 COM(+) und Security

COM Security Konzepte Authentifizierung: Wer ist der Client? RPC und damit COM erlaubt dem Client den Grad der Authentifizierung einzustellen Access Control: Darf dieser Client dies tun? Programmatisch vs. Deklarativ Identity: Welche Identity nimmt der Client an? Mit welcher Identity läuft der Server? COM erlaubt es dem Client eine Identity auszuwählen COM startet die Server automatisch und erlaubt es die Identity des Servers auszuwählen

Abschnitt 3.1 Authentifizerung

MSDN TechTalk – Januar 2001 COM(+) Security 31 Auswahl des SSP in COM MSDN TechTalk – Januar 2001 COM(+) Security 31 Jeder Server-Prozess registriert Security Support Provider (SSP) mit Hilfe von CoInitializeSecurity Runtime sorgt dafür, daß Proxies automatisch den passenden SSP verwenden COM ruft CoInitializeSecurity implizit auf falls “vergessen” Beim ersten Marshal oder Unmarshal Wählt default SSPs des Rechners Defaultwerte sagen: Security ist an

CoInitializeSecurity MSDN TechTalk – Januar 2001 COM(+) Security 32 HRESULT CoInitializeSecurity( SECURITY_DESCRIPTOR* pSD, DWORD cAuthSvc, SOLE_AUTHENTICATION_SERVICE* prgAuthSvc, void* pvReserved1, DWORD dwAuthnLevel, DWORD dwImpLevel, void* pvReserved2, DWORD dwCapabilities, void* pvReserved3 );

MSDN TechTalk – Januar 2001 COM(+) Security 33 Authentication Level MSDN TechTalk – Januar 2001 COM(+) Security 33 Mit CoInitializeSecurity wird ein „Authentication Level“ gewählt Dies legt fest wann und/oder wie oft Authentifiziert wird und ob die Daten verschlüsselt werden

RPC_C_AUTHN_LEVEL RPC_C_AUTHN_LEVEL_NONE Keine Authentifizierung RPC_C_AUTHN_LEVEL_CONNECT Authentifizierung beim ersten “Kontakt” RPC_C_AUTHN_LEVEL_CALL Authentifizierung für das erste Packet eines jeden Aufrufs RPC_C_AUTHN_LEVEL_PACKET Authentifizierung für jedes Packet RPC_C_AUTHN_LEVEL_PKT_INTEGRITY PACKET + Signatur RPC_C_AUTHN_LEVEL_PKT_PRIVACY INTEGRITY + Verschlüsselung

MSDN TechTalk – Januar 2001 COM(+) Security 35 Authentication Level MSDN TechTalk – Januar 2001 COM(+) Security 35 Für den Server ist dies die „low watermark“ für eingehende Aufrufe Unterhalb dieses Levels werden Aufrufe abgelehnt Alle exportierten Interface Pointer bekommen diese „low watermark“ als Hinweis mit COM Runtime wählt dann den höchsten von „low watermark“ des Servers Level der bei Aufruf von CoInitializeSecurity im Client angegeben wurde

MSDN TechTalk – Januar 2001 COM(+) Security 36 Proxy und Security MSDN TechTalk – Januar 2001 COM(+) Security 36 CoInitializeSecurity legt nur den „default authentication level“ für jeden Proxy fest Die Einstellungen können dann für jeden Proxy angepasst werden. Dies geht bei dem Standard-Proxy über IClientSecurity IClientSecurity wird vom „proxy manager“ implementiert

Proxy & Stubs (Interceptors) Client Server IClientSecurity ProxyManager Proxy IFoo IBaz Object IFoo IBaz Stub Stub

MSDN TechTalk – Januar 2001 COM(+) Security 38 IClientSecurity MSDN TechTalk – Januar 2001 COM(+) Security 38 interface IClientSecurity : Iunknown { HRESULT QueryBlanket( IUnknown* pProxy, DWORD* pAuthnSvc,DWORD* pAuthzSvc, OLECHAR** pServerPrincName, DWORD* pAuthnLevel, DWORD* pImpLevel, void** ppAuthInfo, DWORD* pdwCapabilites ); HRESULT SetBlanket( IUnknown* pProxy, DWORD AuthnSvc, DWORD AuthzSvc, OLECHAR* pServerPrincName, DWORD AuthnLevel, DWORD ImpLevel, void* pAuthInfo, DWORD dwCapabilities ); HRESULT CopyProxy( IUnknown* pProxy, IUnknown** ppCopy ); }

Anpassen des Authn Level MSDN TechTalk – Januar 2001 COM(+) Security 39 HRESULT MakePrivateCall( IBank* pib ) { IClientSecurity* pics = 0; pib->QueryInterface( IID_IClientSecurity, (void**)&pics ); DWORD nAuthnSvc, nImpLevel; pics->QueryBlanket( pib, &nAuthnSvc, 0, 0, 0, &nImpLevel, 0, 0 ); pics->SetBlanket( pib, nAuthnSvc, 0, 0, RPC_C_AUTHN_LEVEL_PKT_PRIVACY, nImpLevel, 0, 0 ); pics->Release(); pib->SetCreditCardInfo( g_pszCardNum ); pib->Release(); }

Authn Level bei Aktivierung MSDN TechTalk – Januar 2001 COM(+) Security 40 In COM gibt es einige Aufrufe zur Aktivierung von COM Objekten CoCreateInstance(Ex) CoGetClassObject CoGetInstanceFromFile Der Default Authn Level wird durch CoInitializeSecurity bestimmt Wie kann der Client den Authn Level festlegen? (Es gibt noch kein IClientSecurity) Hierzu dient COSERVERINFO und COAUTHINFO

MSDN TechTalk – Januar 2001 COM(+) Security 41 COAUTHINFO MSDN TechTalk – Januar 2001 COM(+) Security 41 struct COSERVERINFO { DWORD dwReserved1; // mbz WCHAR* pszHostName; COAUTHINFO* pAuthInfo; DWORD dwReserved2; // mbz }; struct COAUTHINFO { DWORD dwAuthnSvc; DWORD dwAuthzSvc; WCHAR* pszServerPrincipalName; DWORD dwAuthnLevel; DWORD dwImpLevel; COAUTHIDENTITY* pAuthIdentityData; DWORD dwCapabilities;

MSDN TechTalk – Januar 2001 COM(+) Security 42 „Normales“ Vorgehen MSDN TechTalk – Januar 2001 COM(+) Security 42 Server setzt die „low watermark“ auf CONNECT or NONE (Effizienz) Ein Servers, der den Client identifizieren muss, setzt mindestens CONNECT Z.B. muss ein Server, der nur bestimmte Clients zulässt diese auch unterscheiden können Server, die anonymen Zugriff erlauben müssen NONE verwenden. Clients setzen den Authn Level für bestimmte Operationen rauf.

Überprüfen des Authn Level MSDN TechTalk – Januar 2001 COM(+) Security 43 Ein Server fordert manchmal einen höheren Authentication Level als sonst Z.B. um eine PIN oder Kreditkartennummer zu übetragen Clients können den Level erhöhen Server können dies dann überprüfen IServerSecurity bietet die Möglichkeit den Kontext des Aufrufs nach dem Authn Level zu fragen Hierzu ist auch CoGetCallContext nötig

MSDN TechTalk – Januar 2001 COM(+) Security 44 IServerSecurity MSDN TechTalk – Januar 2001 COM(+) Security 44 HRESULT CoGetCallContext( REFIID iid, void** ppv ); interface IServerSecurity : IUnknown { HRESULT QueryBlanket( DWORD* pAuthnSvc, DWORD* pAuthzSvc, OLECHAR** pServerPrincName, DWORD* pAuthnLevel, DWORD* pImpLevel, void** pPrivs, DWORD* pCapabilites ); // weitere Methoden ... }

Beispiel QueryBlanket MSDN TechTalk – Januar 2001 COM(+) Security 45 HRESULT CoBank::SetCreditCardInfo( BSTR pszCardNum ) { // verlange PRIVACY DWORD nAuthnLevel HRESULT hr = CoQueryClientBlanket( 0, 0, 0, &nAuthnLevel, 0, 0, 0 ); // nicht authentifiziert if ( FAILED( hr ) ) return E_ACCESSDENIED; if ( nAuthnLevel < RPC_C_AUTHN_LEVEL_PRIVACY ) // ... }

Abschnitt 3.2 Access Control

Zwei Arten von Authorisation MSDN TechTalk – Januar 2001 COM(+) Security 47 COM bietet zwei Arten von Zugriffskontrolle Beide arbeiten auf Prozessebene Access Permissions Welcher Benutzer darf in den Server Aufrufe absetzen Launch Permissions Welcher Benutzer kann den Prozess in Folge eines Aktivierungsaufrufes starten Es ist möglich, dies feiner abgestuft im Programmcode zu machen

MSDN TechTalk – Januar 2001 COM(+) Security 48 Access Permissions MSDN TechTalk – Januar 2001 COM(+) Security 48 Werden über CoInitializeSecurity gesetzt Der erste Parameter kann in verschiedenen Arten verwendet werden. NULL für unbeschränkten Zugriff Ein Interface Pointer vom Typ IAccessControl Ein Security Descriptor Eine AppID dwCapabilities (8. Parameter) bestimmt was im Ersten steht

CoInitializeSecurity MSDN TechTalk – Januar 2001 COM(+) Security 49 HRESULT CoInitializeSecurity( SECURITY_DESCRIPTOR* pSD, DWORD cAuthSvc, SOLE_AUTHENTICATION_SERVICE* prgAuthSvc, void* pvReserved1, DWORD dwAuthnLevel, DWORD dwImpLevel, void* pvReserved2, DWORD dwCapabilities, void* pvReserved3 );

MSDN TechTalk – Januar 2001 COM(+) Security 50 Registry MSDN TechTalk – Januar 2001 COM(+) Security 50 Wenn in CoInitializeSecurity eine AppID verwendet wird, wird die Registry verwendet. Pro Applikation bzw. AppID HKCR/AppID/{appid} AccessPermission=“01 00 04 80 ..." Falls dieser Key fehlt HCLM/Software/Microsoft/Ole DefaultAccessPermission=“01 00 04 80 ..." DCOMCNFG kann die Einträge setzen

MSDN TechTalk – Januar 2001 COM(+) Security 51 Launch Permissions MSDN TechTalk – Januar 2001 COM(+) Security 51 Wer darf einen COM Server starten? CoInitializeSecurity kann nicht verwendet werden, da der Prozess ja noch nicht läuft Hierfür ist die Registry da HKCR/AppID/{appid} LaunchPermission=“01 00 04 80 ...” Falls dieser Key nicht existiert wird ein Default benutzt HCLM/Software/Microsoft/Ole DefaultLaunchPermission=“01 00 04 80 ...” Mit Hilfe von DCOMCNFG können diese Werte editiert werden

Abschnitt 3.3 Role based security

Access Control in COM ist grob Launch Permissions pro Applikation Access Permissions pro Prozess Was, wenn man es genauer/feiner haben möchte? Access Control pro Klasse Access Control pro Interface Access Control pro Methode Ist möglich, erfordert jedoch viel Code

Feinere Zugriffscontrolle MSDN TechTalk – Januar 2001 COM(+) Security 54 Wie kann dies programmatisch gemacht werden? Authn Level ausreichend wählen Jede Methode macht folgendes Lade das aktuelle Access Token Dies geht in COM über IServerSecurity::ImpersonateClient() und IServerSecurity::RevertToSelf() Lade einen Security Descriptor für diese spezielle Methode aus einer DB Rufe die API AccessCheck auf und gib einen Fehler zurück das Ergebnis False ist

MSDN TechTalk – Januar 2001 COM(+) Security 55 Impersonation Aufruf MSDN TechTalk – Januar 2001 COM(+) Security 55 interface IServerSecurity : IUnknown { HRESULT QueryBlanket( ... ); HRESULT ImpersonateClient(); HRESULT RevertToSelf(); BOOL IsImpersonating(); } HRESULT CoGetCallContext( REFIID iid, void** ppv ); oder HRESULT CoImpersonateClient(); HRESULT CoRevertToSelf();

Deklarative Access Control Das gleiche kann in COM+ deklarativ gemacht werden Der Code dazu ist im sogenannten Interceptor Die nötige Information (DACL) dazu steht im COM Catalog Problem: Zur Designzeit stehen die Benutzer nicht fest Der Administrator kennt zur Installationszeit die Semantik der Methoden nicht. Wer soll also den COM Catalog „füllen“? Lösung: eine zusätzliche Indirektionsstufe

MSDN TechTalk – Januar 2001 COM(+) Security 57 COM+ Roles MSDN TechTalk – Januar 2001 COM(+) Security 57

Abschnitt 3.4 Identity

MSDN TechTalk – Januar 2001 COM(+) Security 59 Client Identity MSDN TechTalk – Januar 2001 COM(+) Security 59 Per Default benutzt der Client das Token des Prozesses für alle ausgehenden Aufrufe. Thread (impersonation) Tokens werden nicht verwendet Aber das Verhalten kann man ändern.

Impersonation im Bild server.exe Joe client.exe Alice Alice client.exe Bob

Per-Proxy Client Identity MSDN TechTalk – Januar 2001 COM(+) Security 61 Die Identity kann für jeden Proxy verändert werden interface IClientSecurity : Iunknown { HRESULT QueryBlanket( ... ); HRESULT SetBlanket( IUnknown* pProxy, ..., void* pAuthInfo, DWORD dwCapabilities ); HRESULT CopyProxy( ... ); }

MSDN TechTalk – Januar 2001 COM(+) Security 62 Explizit MSDN TechTalk – Januar 2001 COM(+) Security 62 Die Identity kann explizit gesetzt werden Für NTLM und Kerberos ist die folgende Struktur zu verwenden (für pAuthInfo in SetBlanket) struct SEC_WINNT_AUTH_IDENTITY_W { unsigned short* User; unsigned long UserLength; unsigned short* Domain; unsigned long DomainLength; unsigned short* Password; unsigned long PasswordLength; unsigned long Flags; };

MSDN TechTalk – Januar 2001 COM(+) Security 63 Cloaking (W2K) MSDN TechTalk – Januar 2001 COM(+) Security 63 Eine andere Art ist das sogenannte Cloaking Cloaking inspiziert das aktuelle Thread Token und kopiert die Daten in den Proxy Aufrufen von IClientSecurity::SetBlanket mit entsprechendem Parameter für dwCapabilities EOAC_STATIC_CLOAKING EOAC_DYNAMIC_CLOAKING

MSDN TechTalk – Januar 2001 COM(+) Security 64 Aktivierung MSDN TechTalk – Januar 2001 COM(+) Security 64 Was tun die Aktivierungs-Aufrufe CoCreateInstanceEx CoGetClassObject CoGetInstanceFromFile Der COM SCM erzeugt die Objekte stellvertretend für den Aufrufer Impersoniert den Client Nutzt ebenfalls das Process Token Clients habe die Möglichkeit dies mit Hilfe von COAUTHINFO zu überschreiben

MSDN TechTalk – Januar 2001 COM(+) Security 65 COAUTHINFO MSDN TechTalk – Januar 2001 COM(+) Security 65 struct COAUTHINFO { DWORD dwAuthnSvc; DWORD dwAuthzSvc; WCHAR* pszServerPrincipalName; DWORD dwAuthnLevel; DWORD dwImpLevel; COAUTHIDENTITY* pAuthIdentityData; DWORD dwCapabilities; };

Client Identity Zusammenfassung MSDN TechTalk – Januar 2001 COM(+) Security 66 Jeder COM Aufruf nutzt das Process Token als Identität des Aufrufers Einzelne Interface Proxies können dies überschreiben Explizit durch Angabe der Credentials Über Cloaking (NT5) Aktivierung von COM Objekten ebenfalls mit expliziter Angabe einer anderen Identity möglich COM SCM impersoniert

MSDN TechTalk – Januar 2001 COM(+) Security 67 Server Identity MSDN TechTalk – Januar 2001 COM(+) Security 67 COM SCM startet den COM Server Prozess via CreateProcessAsUser CreateProcessAsUser verlangt ein Token Drei Möglichkeiten für dieses Token Welche Möglichkeit verwendet wird steht in der Registry HKCR/AppID/{appid} RunAs=“…”

MSDN TechTalk – Januar 2001 COM(+) Security 68 “As Activator” MSDN TechTalk – Januar 2001 COM(+) Security 68 RunAs-Key ist nicht vorhanden COM SCM startet den Prozess mit dem Client Token Client muss dazu authentifiziert werden Jeder Client bekommt einen eigenen Server Prozess Schlecht für die Performance Nur sehr schwer möglich Resourcen gemeinsam zu nutzen Falls es sich um einen Remote Client handelt, hat der Server keine „network credentials“ Kann mit Delegation in W2K umgangen werden Wird allgemein als schlecht angesehen

MSDN TechTalk – Januar 2001 COM(+) Security 69 “Interactive User” MSDN TechTalk – Januar 2001 COM(+) Security 69 RunAs=“Interactive User” COM SCM startet den Prozess mit dem Token des momentan angemeldeten Benutzers Sehr nützlich fürs Debuggen Server hat „network credentials“ Ein Server Prozess für alle Clients Server ist in der Lage Fenster zu erzeugen Z.B. für ASSERT oder MsgBox Nicht besonders nützlich für Release Version Ohne einen angemeldeten Benutzer schlagen alle Aktivierungsaufrufe fehl. Server Prozess muss mit allen möglichen Benutzern rechnen

“Distinguished Principal” MSDN TechTalk – Januar 2001 COM(+) Security 70 RunAs=“Authority\Principal „ COM SCM ruft LogonUser auf um ein Token zu erzeugen. Ideal für Release Version Server hat „network credentials“ des ausgewählten Benutzers Ein Serverprozess für alle Clients Eindeutiger Account erlaubt es die Rechte/Privilegien genau zu kontrollieren Läuft auch im Hintergrund Nicht unbedingt für Debugging geeignet CoRegisterClassObject macht evtl. Probleme Password wird als „LSA secret“ gespeichert Dies muss von Hand aktualisiert werden

MSDN TechTalk – Januar 2001 COM(+) Security 71 Impersonation Level MSDN TechTalk – Januar 2001 COM(+) Security 71 Es ist möglich die Benutzung des so erhaltenen Tokens einzuschränken Anonymous wird nicht unterstützt Delegate geht nur mit Kerberos RPC_C_IMP_LEVEL_ANONYMOUS RPC_C_IMP_LEVEL_IDENTIFY RPC_C_IMP_LEVEL_IMPERSONATE RPC_C_IMP_LEVEL_DELEGATE

CoInitializeSecurity MSDN TechTalk – Januar 2001 COM(+) Security 72 Der Client setzt den Default Impersonation Level mit CoInitializeSecurity HRESULT CoInitializeSecurity( SECURITY_DESCRIPTOR* pSD, DWORD cAuthSvc, SOLE_AUTHENTICATION_SERVICE *prgAuthSvc, void* pvReserved1, DWORD dwAuthnLevel, DWORD dwImpLevel, void* pvReserved2, DWORD dwCapabilities, void* pvReserved3 );

IClientSecurity & Imp. Level MSDN TechTalk – Januar 2001 COM(+) Security 73 Der Client kann die Einstellung für jeden Proxy ändern interface IClientSecurity : IUnknown { HRESULT QueryBlanket( IUnknown* pProxy, DWORD* pAuthnSvc, DWORD* pAuthzSvc, OLECHAR** pServerPrincName, DWORD* pAuthnLevel, DWORD* pImpLevel, void** ppAuthInfo, DWORD* pCapabilites ); HRESULT SetBlanket( IUnknown* pProxy, DWORD AuthnSvc, DWORD AuthzSvc, OLECHAR* pServerPrincName, DWORD AuthnLevel, DWORD ImpLevel, void* pAuthInfo, DWORD Capabilities ); HRESULT CopyProxy( IUnknown* pProxy, IUnknown** ppCopy ); }

Abschnitt 4

Do’s and Don’ts 1/3 Do Sichern Sie Ihre Server ;-) Security während (vor) des Designs bedenken „Configure Security“ Role Based Security spart Arbeit ‚Interactive user‘ fürs Debugging ‚This user‘ fürs Deployment

Do’s and Don’ts 2/3 Don´t Erfinden Sie kein eigenes “security system” Vergessen Sie nicht CoInitializeSecurity() aufzurufen Vorsicht bei der Verwendung von Impersonation Skalierbarkeit Versuchen Sie CoInitializeSecurity() >= CONNECT zu vermeiden Die Authentifizierung des Servers schlägt evtl. fehl

MSDN TechTalk – Januar 2001 COM(+) Security 77 Do’s and Don’ts 3/3 MSDN TechTalk – Januar 2001 COM(+) Security 77 Don´t Versuchen Sie “callbacks” zum Client zu vermeiden (falls möglich) Falls nötig: CoInitializeSecurity() mit Authn Level NONE ist die beste Wahl

Fragen? Fragen & Antworten Presentation Layer

Wo gibt’s weitere Info’s? MSDN TechTalk – Januar 2001 COM(+) Security 79 MSDN online http://www.microsoft.com/germany/msdn MSDN TechTalk-Newsgroup msnews.microsoft.com microsoft.public.de.german.techtalk Web Seiten COM Security in Practice http://msdn.microsoft.com/library/techart/msdn_practicom.htm KeithBrown COM Security FAQ http://www.develop.com/kbrown COM Security FAQ http://support.microsoft.com/ support/kb/articles/Q158/5/08.asp

Wo gibt’s weitere Info’s? MSDN TechTalk – Januar 2001 COM(+) Security 80 Bücher Keith Brown: Programming Windows Security http://www.develop.com/kbrown Don Box: Essential COM Solomon, Russinovich: Inside Windows 2000 http://www.sysinternals.com Kaufman, Perlman, Spencier: Network Security