COM+ Security



COM+ Security

Overview

What You Will Learn

After completing this lesson you will be able to:

• Understand how COM+ uses the underlying Microsoft® Windows® 2000 security architecture.

• Understand the security concepts of remote computing, such as authorization and authentication.

• Explain the security enhancements in Windows 2000 and COM+ such as Kerberos, delegation, and cloaking.

• Configure security in a three-tier application using the COM+ MMC snap-in or DCOMCNFG.

• Explain the important aspects of configuring security in a three-tier application.

Related Topics Covered in This Lesson

• Kerberos, Windows NT® LAN-Manager (NTLM), Security Support Provider Interface (SSPI) and Remote Procedure Call (RPC)

Recommended Reading

• COM 211 – DCOM and Object Security in Windows NT and Windows 2000 Environments (a Microsoft Learning Solutions Group course). See information at ()

• Programming COM+ Security

()

• MSDN Library ( Platform SDK ( Security ( Access Control

• MSDN Library ( Platform SDK ( Security ( Logon Authentication

Introducing Security

Introducing Security

Real-Life Example

Principal: Mr. Miller

Credentials: Mr. Miller’s Passport

Trust: Believing that Mr. Miller is Mr. Miller

because his passport says so (and of course because the passport isn’t a fake)

Authority: The government issuing the passport

Privilege: To live in the country or to travel abroad

Introducing Security

Security 1/2

This page intended to serve as a reference for those less familiar with the acronyms.

Introducing Security

Security 2/2

Security roughly breaks down into two parts:

• Authentication ( I see …. You are Mr. X )

• Authorization ( Mr. X is allowed to do this )

So client tells server that this has to be done on that by someone

Because security relies mostly on a “shared secret,” the trust factor is very important. Both parties have to rely on each other, as well as the authority, to not give away the secret.

The following pages will show how:

• Definition and

• Enforcement

are implemented.

Windows Security Architecture

Windows Security Architecture

The Windows 2000 security architecture provides means for both authentication (who you are) and authorization what are you allowed to do).

The means that are provided by Windows 2000 and that will be discussed during this part of the lesson are:

Authentication means:

• Access Token

• Security Identifier

• Logon and Logon Session

Authorization means:

Privileges/User Rights

• Access Control List (ACL)

• Security Descriptors (SD)

• (Access Token)

Windows Security Architecture

Authentication 1/2

The basic question answered during the process of authentication is the following one:

“Who are you?”

In order for the system to be able to authenticate and thereby identify a given user, the user has to pass in some “credentials.” Usually these are his or her username and password—or, in modern systems the insertion of a smart card.

In response to the user entering the correct credentials, the system will issue an access token.

The access token can then later on be used like a disco-stamp that says: “The system already verified that I’m ok.”

The access token thereby is a means not only to identify you to the system, but also a means to allow you to browse around without having to enter your credentials every time you access a new resource.

Windows Security Architecture

Authentication 2/2

During logon the logon process (with the help of the GINA) will present a user with the well-known logon dialog where, after pressing CTRL+ALT+DEL, the credentials (username and password) can be entered.

After the credentials are collected, the logon process contacts the Local Security Authority (LSA), which is able to verify whether the credentials are correct and whether the user has the right to log on to the system.

The LSA then uses the Security Account Management database (SAM) (some hidden part of the registry) to look up the appropriate account information and to verify the credentials the user has passed in.

If all goes well, the LSA create an access token, which contains the user’s identity and some additional information (such as which groups the user belongs to, and so on).

The access token is then passed up to the logon process, which in turn will create a logon session object (a Windows 2000 kernel object) and start the shell.

For Those Interested in Programming Security:

• LogonUser()

create a logon process for a given user

• CreateProcessAsUser()

create a process for the logged-on user

Windows Security Architecture

Access Token 1/2

An access token is an entity that describes the security context of a process or thread. It contains information about a given user’s identity, his privileges and some defaults used for the creation of new objects:

Identity and Authorization

• User Security Identifier (SID)

for example, “mikeku”

• Group SIDS

for example, “Administrators”

• Privileges

for example, “Backup Files”

Defaults for New Objects

• Owner SID

• Primary Group SID (POSIX only)

• Default Discretionary Access Control Lists (DACL) (such as “Everyone allowed access“)

The system uses an access token to identify the user when a thread interacts with a securable object or tries to perform a system task that requires privileges.

Access tokens come in two flavors: primary tokens and impersonation tokens. Note that these types of tokens don’t mix and match: primary tokens can only be used for processes and impersonation tokens can only be used for threads. Use DuplicateTokenEx() to convert between the two.

Windows Security Architecture

Access Token 2/2

For Those Interested in Programming Security

• OpenProcessToken()

get hold of a processes token

• OpenThreadToken()

get hold of a thread‘s token

• GetTokenInformation()

peek into the token

• AdjustTokenPrivileges()

enable privileges (must already be assigned!)

• DuplicateTokenEx()

convert between primary-/impersonation token

• SetThreadToken()

used for impersonation

Windows Security Architecture

Logon Sessions

There are four different types of logon sessions:

• INTERACTIVE

• NETWORK

• BATCH

• SERVICE

Not all of these logon sessions have access to a copy of the password-hash (sort of a “key” derived from the user’s password).

This becomes important during impersonation scenarios under NTLM authentication: if the password-hash is not present, then the challenge cannot be responded to.

More information on NTLM network authentication and on impersonation will be presented later on in the lesson.

Windows Security Architecture

Security Identifier 1/2

A security identifier (SID) is a unique (that is, never to be reused) entity that stores information about a user’s identity as well as about the authorities that handed out the SID.

Internally, a SID contains (among other things) a 48-bit authority value, which is a unique value comprised of a revision level, an identifier-authority value, and a sub-authority value.

The revision number is always “1” (at least at present).

Other and more detailed information about authorities and their values can be looked up in the MSDN library; for example, “5” stands for the LSA.

For Those Interested in Programming Security

• LookupAccountName()

lookup an account by name

• LookupAccountSID()

lookup an account by SID

Windows Security Architecture

Security Identifier 2/2

There are various different types of SIDs, the most important ones of which are:

• Owner SIDs

declares who is owning an object

• Primary Group SID

this one is used only for POSIX compliance

Under Win2000 it is only used during inheritance

of ACLs and then only if CREATOR_GROUP

was specified.

Mostly you can simply forget about it…

• Well known SIDs

stand for accounts, groups, or logon sessions

List of Well-known SIDS

•INTERACTIVE S-1-5-4 ( interactive session

•NETWORK S-1-5-2 ( network session

•BATCH S-1-5-3 ( batch session

•SERVICE S-1-5-6 ( service session

•Null SID S-1–0–0 ( empty group

•World S-1–1–0 ( all users

•Local S-1–2–0 ( phys. connected user

•Creator Owner S-1–3–0 ( replaced by user SID

•Creator Group S-1–3–1 ( repl. by pri.-grp SID

•Interactive User S-1-5-4 ( logged-on user

•Local System S-1-5-0x12 ( SYSTEM account

•BUILTIN Domain S-1-5-0x20 ( BUILTIN\Domain

Windows Security Architecture

Authorization 1/2

The primary question during authorization is:

“What are you allowed to do?”

The question is answered using two means:

• The access token that resulted from the logon

• The access-control list (ACL) on the object

You can think of an access token as your key, and the ACL as the lock: if the key fits the lock, then you are granted access.

Windows Security Architecture

Authorization 2/2

In Windows 2000 (as well as in Windows NT) authorization depends on two security means:

• The user’s privileges:

”Log on locally,” “Backup Files,” etc.

• The user’s rights (on the object):

”Deny read,” “Allow write,” and so on.

Privileges

• Are centered around users, not objects

• Are based on the access token

Rights

• Are associated with an object and a user

• Are based on the combination of the ACL and the access token (especially the user’s SID and the group SIDs).

For Those Interested in Programming Security

• LookupPrivilegeName()

retrieve privilege name corresponding to LUID

• LookupPrivilegeValue()

retrieve LUID representing the privilege name

Windows Security Architecture

Access Control List 1/2

An access-control list is an entity which contains a list of access-control entries (ACEs) which function as a list of rights or restrictions placed on a user or group for a given object (or group of objects) in order to secure an object.

The ACEs specify who is allowed and/or denied access to a given object.

There are two flavors of ACLs:

• System Access Control Lists (SACLs) and

used by Windows 2000 to control monitoring

• Discretionary Access Control Lists (DACLs)

used to control object access, that is, to secure objects

There are three states a DACL can be in:

• Existing DACL

the DACL has a list of ACEs

”these users/groups are allowed/denied access“

• NULL DACL

no DACL at all

”everyone full control“

• Empty DACL

DACL exists but is empty (no list of ACEs)

”nobody any control“

Windows Security Architecture

Access Control List 2/2

For Those Interested in Programming Security

• BuildExplicitAccessWithName()

construct an ACE

• SetEntriesInAcl()

constructs an ACL

• GetExplicitEntriesFromAcl()

returns array of structs describing the ACEs

Windows Security Architecture

Security Descriptor 1/2

A security descriptor (SD) is an entity combining other security-related entities. The total information inside the SD together exactly specifies the owner, permitted users and groups and the permissions granted (or denied) to a particular user (or groups of users) of that object.

An SD comprises the following entities:

• The owner’s SID ( who owns this object

• A primary group SID ( POSIX only (forget…)

• A SACL ( which actions are audited?

• A DACL ( who is granted access?

For those interested in programming security:

• GetSecurityInfo()

read SD using a handle to the object

• SetSecurityInfo()

write SD using a handle to the object

• InitializeSecurityDescriptor()

low-level, use together with the one below

• SetSecurityDescriptorDacl()

low-level, build SD w/ DACL but w/o SACL

• BuildSecurityDescriptor()

high-level, build SD with DACL and SACL

Windows Security Architecture

Security Descriptor 2/2

Page intentionally left blank.

Windows Security Architecture

Authorization revisited

How it all works together:

When a process, thread, or object wants to access a resource (another process, thread, or object), the security-reference monitor (SRM) will use the associated access token in order to find out whether the identity (user, group) and privileges match the security assigned to a given object.

In order to do so, the SD is “opened” and the DACL is walked through. If the DACL doesn’t contain any ACE that specifically denies the user access and if the DACL additionally contains (an) ACE(s), which implicitly or explicitly allow the user access, then the user is granted access to the resource.

Access-checks are done implicitly by most of the Win32-APIs such as:

• RegOpenKeyEx

• OpenMutex

• OpenFile, and so on

However, access-checks can also be programmatically enforced using function AccessCheck().

For those interested in programming security:

• AccessCheck()

check access given an access-token and a SD

Windows Security Architecture

Network Authentication and SSPI

When using COM+ over a network connection, the client making the call must first be authenticated to the server.

Under Windows 2000 several Security Support Providers (SSPs) are available that allow for authentication.

In order to allow the client and server to choose the SSP they want to use, an abstraction layer is introduced, called Security Support Provider Interface (SSPI).

Using the SSPI the client can easily choose between NTLM and Kerberos for authentication (as well as others) without having to know about all the gory details.

Windows Security Architecture

SSPI and RPC

COM+ relies on secure RPC, which makes use of the underlying SSPI. Thus, a COM+ can authenticate a client to a server without requiring the developer to write a single line of code.

Since both the SSPI and RPC implement a “handshake” between client and server in order to do authentication, the SSPI handshake is piggy-backed on top of the RPC ‘WAY’ handshake (‘WAY’ = “Who Are You?”).

This way, the handshake can be optimized

• Ease of use: clients don’t have to care about details

• No overhead due to additional network roundtrips

Windows Security Architecture

SSPI: Negotiation

Security package negotiation is a process in which the client and server agree upon the characteristics and capabilities that a security package needs to have in order to be applicable.

Security package characteristics are, for example:

• SECPKG_FLAG_PRIVACY

• SECPKG_FLAG_DATAGRAM (UDP)

• SECPKG_FLAG_CONNECTION (IP)

• SECPKG_FLAG_IMPERSONATION and others...

For Those Interested in Programming Security

• LoadLibrary (TEXT("secur32.dll"))

load SSPI DLL

• GetProcAddress (

DllHandle, TEXT("InitSecurityInterfaceW"))

get func-ptr to security-interface“

• InitSecurityInterface()

initialize security-interface“

• EnumerateSecurityPackages()

enumerate available security packages

• QuerySecurityPackageInfo()

inquire details about security package

Windows Security Architecture

SSPI : Context Establishment

If a Security package (a security support provider) has been agreed upon by client and server, a security-context for the session between the two has to be established.

In order to do so, the SSPI provides various functions that are listed here just for completeness: bear in mind, that you most probably will never need to call one of these on your own, since they are wrapped into the secure RPC protocol used by COM+.

For Those Interested in Programming Security

• AccquireCredentialHandle()

obtain token from existing logon session

• InitializeSecurityContext()

client: SSP copy token into buffer

send token to server

on 2nd time: send response to server

• AcceptSecurityContext()

server: read client token and compose response

on 2nd time: either server ready or repeat

Windows Security Architecture

NTLM: Context Establishment

This figure is intended to show what happens during SSPI context establishment if the SSP is NTLM.

1. Client tells server that it wants to be authenticated

2. Server sends computed challenge blob to client

3. Client uses its password (see pages “A sidebar—Logon sessions” and “Access Token 2/2”) to compute a hash of the challenge and sends result to server

4. Server contacts PDC and passes it the following

info: challenge client identity

5. The PDC (knowing the secret of the client) then also computes a hash of the challenge.

6. The server compares both hashes. If they match, the server grants the client access and a session-key is exchanged (which in further calls to the server is used to verify the client’s identity and/or for encryption).

Windows Security Architecture

Kerberos : Context Establishment

This figure is intended to show what happens during SSPI context establishment if the SSP is Kerberos V 5.

1. Locate the Key Distribution Center (KDC) by doing a domain name system (DNS) lookup

2. Request a ticket-granting ticket (TGT)

3. KDC adds group membership to TGT auth data

4. Request T for session to server passing TGT

5. Send T to client (session-key included)

6. Request access to server

7. Server sends “OK” (session established)

COM+ Security Architecture

COM+ Applications

A COM+ application is an entity comprised of one or more COM+ objects that are configured to work as a unit.

A COM+ application functions as:

• Container for components

• Deployment unit

• Security boundary

• Failure boundary

COM+ Security Architecture

COM+ Security 1/2

The greatest benefits of a COM+ application, at least from a security-standpoint, is that the majority of security-related code no longer has to be programmed by the application developer; although it still can be.

Everything needed to authenticate and authorize a user can be handled by the COM+ kernel, which does so by intercepting calls to the application (or parts of it)—and the way the kernel handles calls to the application can be configured (as we will see).

COM+ Security Architecture

COM+ Security 2/2

COM+ Security mainly is about three different sub-topics:

• Authentication

Functions and Interfaces

• Authorization

Permissions and Roles

• Identity

Configuration and Scenarios

In addition to that there also is some miscellaneous information about COM+ security related topics, such as:

• Firewalls

• COM Internet Services

COM+ Security Architecture

COM+ Authentication Levels

As with Windows 2000 authentication in general, COM+ authentication deals with the question “Who are you?“ Additionally, the authentication level can be used to secure and encrypt data sent between client and server.

There are seven levels of authentication with COM+, which are:

• RPC_C_AUTHN_LEVEL_DEFAULT

let the COM+ run time choose

• RPC_C_AUTHN_LEVEL_NONE

no authentication (user stays anonymous)

• RPC_C_AUTHN_LEVEL_CONNECT

one-time authentication while client connects server

• RPC_C_AUTHN_LEVEL_CALL

authenticate during every call from client to server

• RPC_C_AUTHN_LEVEL_PKT

authenticate during every RPC packet sent

• RPC_C_AUTHN_LEVEL_PKT_INTEGRITY

same as _PKT plus packet is hashed

in order to detect manipulations

• RPC_C_AUTHN_LEVEL_PKT_PRIVACY

same as _INTEGRITY plus packet is encrypted

COM+ Security Architecture

COM+ Authentication

The level of authentication is specified during a call to the COM+ function CoInitializeSecurity().

Both client and server call this function whereas:

The server uses it:

• To register supported SSPs

(where the server’s setting determines the SSP!)

• To set a “low-water mark“ for authentication

(calls below that mark will be rejected by server!)

The client uses it:

• To specify a desired SSP

(if server doesn’t support: bad thing—try again!)

• To specify a “low-water mark” for authentication

(if below mark of server: bad thing—try again!)

Note After the first call the client makes to the server, the client’s proxy will be initialized to a level equal to:

( max(client, server) used

COM+ Security Architecture

For the forgetful

Always remember that COM+ calls CoInitializeSecurity() during first “interesting“ call (that is, marshalling), just in case you should ever forget...

This means that COM+ will use:

• The default SSPs for the server (and client)

• The authentication defaults from the registry

(see following pages)

SUMMARY

Security is ALWAYS “ON“ – whether you forgot it, or not!

COM+ Security Architecture

COM+ Authentication Settings

There are two ways to specify the authentication settings for a given COM+ application: Using the COM+ MMC Snap-in, or (for the old-fashioned folks) good old DCOMCNFG.

COM+ Snap-in

• {application}

• Properties

• Security

• Authentication level for calls

DCOMCNFG.EXE

• Applications

• General

• Authentication level

Registry

The settings will be stored in the Registry under:

• HKCR/AppID/{appid}/AuthenticationLevel

COM+ Security Architecture

COM+ Authentication—Defaults

For applications that didn’t specify authentication settings (only old ones), COM+ authentication defaults are used.

There are two ways to specify the authentication defaults: using the COM+ MMC Snapin, or DCOMCNFG.

COM+ Snap-In

• My Computer

• Properties

• Default Properties

• Default Authentication Level

DCOMCNFG.EXE

• Default Properties

• Default Authentication Level

Registry

The settings will be stored in the Registry under:

• HKLM/Software/Microsoft/OLE

LegacyAuthenticationLevel

If none of the settings are found, COM+ will use a level of

• RPC_C_AUTHN_LEVEL_CONNECT

COM+ Security Architecture

COM+ Authorization

The next area of COM+ security is that of authorization. As with Windows 2000 authorization in general, COM+ authorization deals with the question “Who is allowed to do what?”

However, COM+ authorization has to be viewed from two different aspects:

• Access Permissions

who is allowed access to a COM+ application

can be set programmatically during CoCreateInstance() — not discussed here

can be set manually

• Launch Permissions

who is allowed to start a COM+ application

can‘t be set programmatically since there is

no parameter in CoInitializeSecurity()

can be set manually

For Those Interested in Programming Security

• CoCreateInstance(CLSID_DCOMAccessControl,...,&pAC)

• pAC->SetAccessRights()

• CoInitializeSecurity(pAC, ...)

COM+ Security Architecture

COM+ Access Permissions

As with the authentication level, access permissions can be configured using the COM+ Snap-in, or DCOMCNFG.

COM+ Snap-In

• COM+ Applications

• {application}

• Properties

• Security

• “Enforce Access Checks ...“ (use together with roles)

DCOMCNFG

• Applications

• {application}

• Properties

• Security

• “Use custom access permissions“

Registry

Settings stored as persisted SD in:

• HKCR/AppID/{appid}

AccessPermission=„10 00 04 80...“

COM+ Security Architecture

COM+ Access Permissions—Defaults

COM+ Snap-In

• My computer

• Properties

• Default Security

• Default Access Permissions

DCOMCNFG

• Default Security

• Default Access Permissions

Registry

Defaults stored as persisted SD in:

• HCLM/Software/Microsoft/OLE

DefaultAccessPermission=„10 00 04 80...“

COM+ Security Architecture

COM+ Launch Permissions

COM+ Snap-In

Launch permissions can’t be specified using snap-in.

As an equivalent, use:

• {application}

• Properties

• Security

• “Enforce Access Checks ...“ (together with roles)

DCOMCNFG

• Applications

• {application}

• Properties

• Security

• “Use custom launch permissions“

Registry

Settings stored as persisted SD in:

• HKCR/AppID/{appid}

LaunchPermission=„10 00 04 80...“

COM+ Security Architecture

COM+ Launch Permissions—Defaults

COM+ Snap-In

• My computer

• Properties

• Default Security

• Default Launch Permissions (use together with roles)

DCOMCNFG

• Default Security

• Default Launch Permissions

Registry

Defaults stored as persisted SD in:

• HCLM/Software/Microsoft/OLE

DefaultLaunchPermission=„10 00 04 80...“

COM+ Security Architecture

Authorization and Roles

COM+ applications control access with roles.

A role can best be compared to an NT local group, which also can contain single users, or other groups.

Roles are defined at application level and are about granting (and/or denying) access to a given COM+ application.

In order to enforce a role, in the applications property tab, check the “enforce access checks” option. From then on only assigned roles will be allowed to access the server.

Roles (like SDs) contain the SIDs of the users and/or groups in question.

COM+ Security Architecture

Roles

Consider the following COM+ application, which comprises two COM+ objects, ‘Jobs’ and ‘Salary’ and defines two roles, ‘Bosses’ and ‘Workers’.

The COM+ objects in turn publish various interfaces to the public. In our case, we look at the ‘Jobs’ object, which has two interfaces, namely ‘Employment’ and ‘Positions’.

Each COM+ interface in turn can have 0 or more methods. In our case it’s the ‘Employment’ interface, the methods of which are ‘Hire()’ and ‘Fire()’.

Roles can be used to control access to a COM+ application at a very fine-grained level:

Server

• Applications ( {app} ( Properties

• Security ( ‘enforce access checks’

Component

• Applications ( {app} ( {obj} ( Properties

• Security ( ‘enforce component level access checks’ +

• ‘Roles explicitly set…”

Interface

• Applications ( {app} ( {obj} ( {if} ( Properties

• ‘Roles explicitly set…”

Method

• Applications({app}({obj}({if}({meth}(Properties

• ‘Roles explicitly set…”

COM+ Security Architecture

Role Programming

As we have seen, roles can be used to administratively configure security.

However, roles can also be used in programming COM+ security. This is most useful, if finer grained access is needed even within a method call.

Within a method call it is possible to check which role(s) the caller is in. This information can then be used to refine access.

For this purpose, there is a COM+ kernel interface, called the SecurityCallContext. The SecurityCallContext stores all security-related information for a given call into a COM+ application, such as the caller’s identity and also the role a caller belongs to.

In order to find out programmatically, whether a caller is in a particular role, program the following sequence:

Dim objCallCtx As SecurityCallContext

‘ Get the security call context

Set objCallCtx = GetSecurityCallContext()

‘ Perform the role check

Allowed = objCallCtx.IsCallerInRole(“Manager”)

‘ Act according to the result

If(Allowed) Then

‘...

End If

COM+ Security Architecture

COM+ Identity 1/2

COM+ Identity deals with the assertion “It’s me!,” or with other words, about how a COM+ application is conceived by the “world outside.”

Hopefully, you remember the question of authentication, which was “Who are you?” the answer to that question is given by the COM+ application’s identity: “It’s me!”

COM+ Identity has to facets: client and server identity.

Server identity

• Who does the (intermediate) server say he is

when accessing resources (or other servers)?

Client identity

• Who does the client say he is

when accessing the server

COM+ Security Architecture

COM+ Identity 2/2

With COM+ the server’s identity can be configured for each individual COM+ application. One possibility is, to configure it so that the server takes on a distinct identity as well as to configure and program it to take on the identity of the client.

The client’s identity by default (without you ‘fumbling around’) is the identity of the enveloping process, which in most cases is the identity of the currently logged-on user.

However, the default identity can also be overridden.

COM+ Security Architecture

COM+ Server Identity

As with authentication, and permissions, a COM+ server’s identity can be configured using the COM+ Snap-in, or DCOMCNFG.

COM+ Snap-In

• COM+ Applications

• {application}

• Properties

• Identity

o Interactive user (use for debugging)

o This user (use for deployment)

DCOMCNFG

• Applications

• {application}

• Properties

• Identity

• “Use custom launch permissions“

o “The interactive user” (use for debugging)

o “This user” (use for deployment)

o “The system account” (use for services)

o “The launching user”(NEVER USE!)

Registry

Settings are stored as persisted SD in:

• HKCR/AppID/{appid}

RunAs=„Interactive User“ (etc.)

COM+ Security Architecture

COM+ Client Identity

A COM+ client’s identity by default is the identity of the enveloping process.

Calling CoInitializeSecurity() makes it possible to specify defaults (such as impersonation level and cloaking, and so on) that will then affect the identity of all proxies that the client uses.

These setting, however, are adjustable for individual proxies using IClientSecurity, an interface that is published by the proxy-manager.

Note Since the proxy manager aggregates all proxies, this interface can be queried for through every interface-pointer to a proxy, which basically means: through every interface pointer to a COM+ server object.

Using IClientSecurity, a client can specify either a distinct identity to be used in calls to the server, or specify a flag, which enables cloaking on the client proxy, which will then result in the proxy taking on the identity of the first or current calling thread.

COM+ Security Architecture

IClientSecurity

The IClientSecurity interface can be used to do three things: query the proxy blanket’s current settings, copy a proxy, or annotate the (copied) proxy with an identity different from the original one.

Note A proxy blanket is an entity, which comprises all of the security information relevant to the client (proxy).

IClientSecurity features three methods. For all three of these there exist COM+ shortcuts that save you some typing:

IClientSecurity::QueryBlanket()

• CoQueryProxyBlanket()

• Retrieves the proxy’s security-information

IClientSecurity::SetBlanket()

• CoSetProxyBlanket()

• Sets the proxy’s security-information

IClientSecurity::CopyProxy()

• CoCopyProxy()

• Copies an individual proxy

Note Copied proxies are not visible during calls to a server’s implementation of QueryInterface()!

COM+ Security Architecture

IClientSecurity—Behind the Scenes

Usually, what you may want to do when annotating a client’s proxy with a new identity is:

1. Create an instance of the server object. This leaves you with a default-proxy that takes on the identity as specified during CoInitializeSecurity()

2. Copy the proxy. This leaves you with an exact copy of the default-proxy you already have.

3. Query the copied proxy’s security blanket. This will leave you with all the security-related information of the proxy in question, including the current identity.

4. Modify the identity of the proxy by modifying the parameter “pAuthInfo” that was returned by the call to CoQueryProxyBlanket(). You may want to use the structure “SEC_WINNT_AUTH_IDENTITY” and pass it the domain, username password of the identity to be taken on.

5. Then call CoSetProxyBlanket() passing in all the parameters returned by CoQueryProxyBlanket() – including the modified “pAuthInfo” parameter.

That’s all!

COM+ Security Architecture

Cloaking

Another feature of COM+ that can be used to manipulate the identity of “client” (s.o. making calls to a server or resource) is that of “cloaking” the client’s identity.

Instead of using the process identity (the default) or specifying a distinct identity (using IClientSecurity) cloaking will lead to the client using the identity of the calling thread.

Cloaking can be turned on for all client proxies by calling CoInitializeSecurity(), or for an individual client proxy by either calling IClientSecurity::SetBlanket() or by calling CoSetProxyBlanket(). All functions take a parameter named “dwCapabilities” which can be used to specify the type of cloaking. There are two types of cloaking available:

Static Cloaking

• Set “dwCapabilities” to EOAC_STATIC_CLOAKING

• The client will use the identity of the first thread calling the server through the proxy. This identity is cached for further calls through the proxy

Dynamic Cloaking

• Set “dwCapabilities” to EOAC_DYNAMIC_CLOAKING

• The client will use the identity of the current calling thread. The identity is newly evaluated for every call through the proxy, which makes dynamic cloaking quite an expensive feature.

COM+ Security Architecture

IServerSecurity

In order for the server to see which identity a particular client has taken on, it can query for the information stored in the client’s security blanket.

This information is passed to the server through the COM+ “call context” and is exposed through the call context’s IServerSecurity interface.

So in order to get hold of the IServerSecurity interface you first will have to issue a call to CoGetCallContext().

The IServerSecurity interface features three methods that the server can use to do three different things with the information passed in (COM+ again provides some shortcuts to save you some typing):

IServerSecurity::QueryBlanket()

• CoQueryClientBlanket()

• retrieves the client proxy’s security-information

IServerSecurity::ImpersonateClient()

• CoImpersonateClient()

• take on the identity of the client

IServerSecurity::RevertToSelf()

• CoRevertToSelf()

• take on the former (old, original) identity

COM+ Security Architecture

COM+ Impersonation

Impersonation is the process of taking on some one else’s identity in order to “act as some one else.”

There are five impersonation settings available:

• Anonymous

The server can impersonate the client but the impersonation token does not contain any information about the client. (Not currently supported)

• Identify

The server can obtain the client's identity. The server can only impersonate the client to do ACL checks. (System-wide default)

• Impersonate

The server can obtain the client's identity. The server can act on behalf of the client. If the server is local, it can also access network resources as the client. If the server is remote, it can only access resources that are on the same machine as the server.

• Delegate

Allows the server to create new remote objects while impersonating the client. (Windows 2000 only)

• Default

Level of CoInitializeSecurity(). (Windows 2000 only)

COM+ Security Architecture

COM+ Impersonation—Configuration

As with the authentication level, impersonation levels can be configured using the COM+ Snap-in, but in this case not by using DCOMCNFG.

COM+ Snap-in

• COM+ Applications

• {application}

• Properties

• Security

• “Impersonation level“

DCOMCNFG

• Not available

COM+ Security Architecture

COM+ Impersonation—Defaults

COM+ Snap-in

• My computer

• Properties

• Default Properties

• “Default Impersonation Level“

DCOMCNFG

• Default Properties

• “Default Impersonation Level“

Registry

The settings will be stored in the Registry under:

• HKLM/Software/Microsoft/OLE

LegacyImpersonationLevel

COM+ Security Architecture

Identity—Scenarios

There are three possible server-identity scenarios:

Trusted Server

• The COM+ application server uses a fixed identity

• Connections to resources can be pooled

• Very scalable

• Very good performance

Trusted Server/SQL Server 7.0

• The COM+ application server uses a fixed identity

• The COM+ application uses IsCallerInRole() in conjunction with the SQL server SP “set_approle” in order to get finer grained security

• Connections to resources can be pooled for each role

• Still very scalable

• Still very good performance

Impersonation/Delegation

• The COM+ application always impersonates the client

• Connections to resources cannot be pooled

• Poor scalability due to missing resource pooling

• Poor performance due to identity switching

COM+ Security Architecture

Trusted Server/SQL Server™ 7.0

As already shown in the previous page:

• The COM+ application server uses a fixed identity

• The COM+ application uses IsCallerInRole() in conjunction with the SQL server SP “set_approle” in order to get finer grained security

• Connections to resources can be pooled for each role

• Still very scalable

• Still very good performance

COM+ Security Architecture

Impersonation

As already shown on the other page:

Impersonation/Delegation

• The COM+ application always impersonates the client

• Connections to resources cannot be pooled

• Poor scalability due to missing resource pooling

• Poor performance due to identity switching

COM+ Security Architecture

Impersonation—Auditing

When using impersonation it might be required to write audit-trails that don’t reveal the current identity the COM+ application has taken on, but also the identity of the original caller that invoked a certain method.

In order to do so, the original caller can be determined using the security context, which contains all security-relevant information on the client (as already discussed before, see page on IServerSecurity).

In order to find out the original caller programmatically, program the following sequence:

Dim objCallCtx As SecurityCallContext

‘ Get the security call context

Set objCallCtx = GetSecurityCallContext()

‘ Obtain the base client identity

baseClientName =

objCallCtx(“OriginalCaller”)(“AccountName”)

‘Obtain the direct caller’s identity

baseClientName =

objCallCtx(“DirectCaller”)(“AccountName”)

‘ Log for audit

COM+ Security Architecture

COM+ and Firewalls

Sometimes there may be a need to have COM+ applications talk to each other over a firewall.

Because COM+ relies on secure RPC, as noted earlier, and because, moreover, secure RPC uses the ports 1024–65535, a correctly configured firewall will block all communication between client and server.

In order to work around this, the “COM+ Internet Services” (a.k.a. “DCOM over HTTP”) were invented.

When using “COM+ Internet Services,” all RCP traffic will be wrapped into HTTP and tunneled through port 80, the only port that is open on nearly every firewall in the world.

COM+ Snap-In

• My computer

• Properties

• Default Properties

• “Enable COM+ Internet Services on this computer”

COM+ Security Architecture

COM+ Internet Services

Requirements to use the “COM+ Internet Services” are:

• Server

IIS 4 or higher on Windows NT Server 4 (SP4) or Windows 2000 Server

DCOMCNFG on NTS 4 or COM+ Snap-in

• Client

Windows® 95 DCOM 1.2 or higher

Windows® 98 DCOM 1.3 or higher

Windows® CISCNFG tcp_http

COM+ Snap-in

• My computer

• Default Protocols

• Connection-oriented TCP/IP

• Properties

DCOMCNFG

• Default Protocols

• Connection-oriented TCP/IP

• Properties

There are two very good white papers on the MSDN, which talk about COM+ and firewalls, called “COM Internet Services” and “Using Distributed COM with Firewalls.”

COM+ Security Architecture

What to Use

Locally

• Kerberos for domain authentication

• Leverages pre-existing trust model

Remote Internet

• PKI for crossing the trust boundary

• SSL/TLS Client Auth mapping

Do´s and Don´ts

Do’s and Don’ts 1/3

Do

• Secure your servers (…)

• Think of security before architecting

• Configure security

o Use roles

o Use “Interactive user” for debugging

o Use “This user” for deployment

Do´s and Don´ts

Do’s and Don’ts 2/3

Don’t

• Invent your own security system

• Forget to call CoInitializeSecurity()

• Use Impersonation heavily

o Performance!

o Scalability!

• CoInitializeSecurity() >= CONNECT

o Server may fail to authenticate

Do´s and Don´ts

Do’s and Don’t’s 3/3

Don’t

• Callback to client (if avoidable)

o If not avoidable, call CoInitiateSecurity() with a level of NONE on Client to avoid administrative mess.

Note Client needs to authenticate server principal and server can‘t easily impersonate the client to callback (cloaking/delegation required!)

Summary

Summary

• Windows 2000 provides the means to

o Authenticate and

o Authorize

Details are handled by COM+ run time, however, so you don‘t have to handle them

• Security has become configurable

o Again: details are handled by COM+ run time

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download