What You Will Learn

COM+ Security 33

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.

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

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

What You Will Learn

COM+ Security

Overview

What You Will Learn

Related Topics Covered in This Lesson

Recommended Reading

Introducing Security

Introducing Security

Real-Life Example

Introducing Security

Security 1/2

Introducing Security

Security 2/2

Windows Security Architecture

Windows Security Architecture

Privileges/User Rights

Windows Security Architecture

Authentication 1/2

Windows Security Architecture

Authentication 2/2

For Those Interested in Programming Security:

Windows Security Architecture

Access Token 1/2

Identity and Authorization

Defaults for New Objects

Windows Security Architecture

Access Token 2/2

For Those Interested in Programming Security

Windows Security Architecture

Logon Sessions

Windows Security Architecture

Security Identifier 1/2

For Those Interested in Programming Security

Windows Security Architecture

Security Identifier 2/2

List of Well-known SIDS

Authorization 1/2

Windows Security Architecture

For Those Interested in Programming Security

For Those Interested in Programming Security

For Those Interested in Programming Security