Tài liệu Module 8: Making Applications Secure ppt

Contents
Overview 1
Overview of Windows 2000 Security 2
Declarative Security 24
Lab 8.1: Implementing Declarative
Security 40
Programmatic Security 44
Lab 8.2: Implementing Programmatic
Security 52
Setting the Identity of a Server
Application 55
Lab 8.3: Assigning a COM+ Application
Identity 65
Best Practices 68
Review 70

Module 8: Making
Applications Secure


Information in this document is subject to change without notice. The names of companies,
products, people, characters, and/or data mentioned herein are fictitious and are in no way intended
to represent any real individual, company, product, or event, unless otherwise noted. Complying
with all applicable copyright laws is the responsibility of the user. No part of this document may
be reproduced or transmitted in any form or by any means, electronic or mechanical, for any

purpose, without the express written permission of Microsoft Corporation. If, however, your only
means of access is electronic, permission to print one copy is hereby granted.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property.

 2000 Microsoft Corporation. All rights reserved.

Microsoft, BackOffice, MS-DOS, Windows, Windows NT, Active Directory, PowerPoint, and
Visual Basic are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A.
and/or other countries.

The names of companies, products, people, characters, and/or data mentioned herein are fictitious
and are in no way intended to represent any real individual, company, product, or event, unless
otherwise noted.

Other product and company names mentioned herein may be the trademarks of their respective
owners.


Module 8: Making Applications Secure i


Instructor Notes
This module provides students with an overview of the security features
available in Microsoft
®
Windows

®
2000. Students will learn how to use roles to
secure COM+ applications both declaratively and programmatically. Students
will also learn how to establish the identity of their COM+ server and select the
appropriate level of authentication for their application.
After completing this module, students will be able to:
!
Describe the major security features and security models provided by the
Windows 2000 platform.
!
Explain how authentication and authorization works.
!
Describe the authentication options available to Internet solutions based on
COM+ and Internet Information Services (IIS).
!
Implement declarative security by using COM+ roles.
!
Implement programmatic security by using security context information.
!
Assign an identity to a COM+ application.

In the labs, students will secure the Purchase Order Online application
declaratively by using COM+ roles. They will also implement programmatic
security to determine whether a caller is a member of a particular role. Finally,
they will assign an identity to a COM+ application and observe the effect of the
new identity.
Materials and Preparation
This section provides you with the required materials and preparation tasks that
are needed to teach this module.
Required Materials

To teach this module, you need the following materials:
!
Microsoft PowerPoint
®
file 1907A_08.ppt
!
Module 8: Making Applications Secure
!
Lab 8.1: Implementing Declarative Security
!
Lab 8.2: Implementing Programmatic Security
!
Lab 8.3: Assigning a COM+ Application Identity

Preparation Tasks
To prepare for this module, you should:
!
Read all of the materials for this module.
!
Complete the labs.
!
Read the instructor notes and margin notes for the module.

Presentation:
90 Minutes

Labs:
75 Minutes
ii Module 8: Making Applications Secure

Demonstration
This section provides demonstration procedures that will not fit in the margin
notes or that are not appropriate for the student notes.
Creating and Assigning a Role
This demonstration shows how to create COM+ roles and to assign them to
specific components, interfaces, and methods. It also shows how to add
Windows 2000 group and user accounts to COM+ roles.
!
To perform the demonstration
1. Open the Component Services tool and select the Purchase Order
application.
2. Expand the Purchase Order application and select the Roles folder, which
will initially be empty.
3. Right-click, point to New, and then select Role.
4. Enter the role name Senior Manager. Point out that role names tend to be
singular, as opposed to Windows 2000 group accounts, which tend to be
plural.
5. Click OK to dismiss the Role dialog box.
6. Repeat steps 2 to 5 to add a second role named Junior Manager.
7. Point out that the roles are currently defined at the application level.
8. To assign a role at the component level, select the POBusiness.bus_Order
component within the Components folder. Right-click and select
Properties.
9. Select the Security tab of the Properties dialog box and explain that the
roles list initially displays all of the roles defined within the application (in
this case, Senior Manager and Junior Manager).
10. To apply the Senior Manager role to this component, place a check mark
next to the Senior Manager role. Explain that this check mark means that the
caller must be a member of the Senior Manager role to access the

POBusiness.bus_Order component.
11. Click OK to dismiss the Properties dialog box.
12. Now expand the Interfaces folder beneath POBusiness.bus_Order.
13. Select and then right-click the _bus_Order interface and select Properties.
14. Select the Security tab of the Properties dialog box.
15. Explain that the Senior Manager role applied at the component level has
been inherited implicitly by the interface. Also explain that additional
specific roles may be applied to this particular interface.
Module 8: Making Applications Secure iii


16. Place a check mark next to the Junior Manager role to grant junior managers
access to the _bus_Order interface.
17. Click OK to dismiss the Properties dialog box.
18. Now expand the _bus_Order interface and then expand the Methods folder.
19. Select and then right-click the Raise method and select Properties.
20. Select the Security tab of the Properties dialog box and explain that roles
can be applied at the method level. In this case, because all of the roles have
been granted access to the _bus_Order interface, all roles will implicitly be
granted access to the Raise method.
21. Click OK to dismiss the Properties dialog box.
22. Explain that roles allow you to apply authorization policies without
worrying about precisely which accounts will be a member of a particular
role. An administrator typically establishes which accounts will be a
member of a particular role at deployment time.
23. Select and expand the Senior Manager role within the Roles folder.
24. Select the Users folder, which will initially be empty.
25. Right-click and point to New, and then select User.
26. From the displayed dialog box, select the Senior Managers group and click
Add.

27. Click OK to dismiss the dialog box.
28. Explain that you have associated the Senior Managers Windows 2000 group
with the Senior Manager role. Explain that assigning Windows 2000 groups
to roles is the recommended approach and as a result one tool—the Active
Directory Users and Computers tool—can be used to administer both
Windows 2000 and COM+ security.

Assigning a COM+ Application Identity
This demonstration shows how to configure a COM+ application to run by
using a specific Windows 2000 user account, as opposed to using the
interactively logged-on user.
!
To perform the demonstration
1. Open the Component Services tool and select the Vendor Processing
application.
2. Right-click and select Properties.
3. Select the Identity tab on the Properties dialog box.
4. Explain that the Interactive User is the default setting for a new application,
but it should generally only be used for debugging purposes. Select the This
user option and then click Browse.
5. Select VendorApp from the Select User or Group dialog box and click
OK.
6. Click OK to dismiss the Properties dialog box and explain that when the
application is next launched, it will run using the VendorApp user account.
Explain that the access rights and permissions established for this account
will affect the capabilities of the COM+ application.
iv Module 8: Making Applications Secure

Module Strategy
Use the following strategy to present this module:
!
Overview of Windows 2000 Security
Discuss the Windows 2000 security model and features. While Windows
2000 is fully compatible with previous versions of Windows NT, Windows
98, and Windows 95, the security model has been enhanced considerably,
notably by the introduction of the Kerberos authentication protocol and the
increased emphasis on Internet-based security technologies. Review the
terminology defined in the “Security Terminology and Concepts” topic,
including Public Key Cryptography.

Discuss how the distributed security model has been designed to support
enterprise applications. Explain that security groups can be managed
centrally in Active Directory to provide control over access to resources.
Explain that Windows 2000 supports multiple security providers for
distributed applications. Explain that Windows 2000 also provides a variety
of techniques to secure an Internet-enabled COM+ application.

Introduce the concepts of authentication and authorization. Explain how
these concepts help to answer the two most basic security-related questions:
how to prove that a user is who she claims and how to determine which
users are allowed to perform particular operations.

!
Declarative Security
Discuss how to use roles in COM+ applications to implement an
authorization policy that controls access to applications, components,
interfaces, and methods. Show students how to define roles declaratively by
using the Component Services tool. Let them see how COM+ manages

much of the authorization process automatically.
The demonstration allows you to show students how to use the Component
Services tool to define roles and assign them to components and interfaces.
It is also used to show how to add Windows 2000 group and user accounts
to roles.

!
Programmatic Security
Explain that students can implement security programmatically in COM+
solutions. By using programmatic security, they can apply additional
business logic to the authorization process in circumstances that demand it.
!
Setting the Identity of a Server Application
Explain that COM+ applications use a default application identity that
matches the security settings of the currently logged-on user. The identity
determines the user account under which the application will run. The
identity affects the privileges and access rights that the application will
possess and is also important when the application needs to access a
database that cares about the identity of its users. Discuss the advantages of
establishing a specific user account for running a COM+ application, rather
than relying on the interactive user account.
Module 8: Making Applications Secure v


Discuss that it is possible to assign a different application identity to a
COM+ application to meet specific security requirements. Explain how to
set the identity of a COM+ application and refer to Lab 8.3 as an example of
how changing the identity will affect an application. Explain that the
identity of a COM+ application plays a pivotal role in the various security
models.

The demonstration allows you to show students how to set the identity of a
COM+ application.

There is a known problem when assigning an identity to an
application that contains a component making a call to a queued component
in another application. This scenario results in an error being logged in the
Windows Event log with a source of the MSMQ Cryptography API and the
queued method will not be called. The issue is currently unresolved.

!
Best Practices
Summarize the best practices for securing COM+ applications and mention
that the practical implementation for most of these practices has been
covered in the module.
Note

THIS PAGE INTENTIONALLY LEFT BLANK
THIS PAGE INTENTIONALLY LEFT BLANK
Module 8: Making Applications Secure 1


#
##
#

Overview
!
Overview of Windows 2000 Security
!
Declarative Security

!
Lab 8.1: Implementing Declarative Security
!
Programmatic Security
!
Lab 8.2: Implementing Programmatic Security
!
Setting the Identity of a Server Application
!
Lab 8.3: Assigning a COM+ Application Identity
!
Best Practices
!
Review


In this module, you will learn how to implement security in an enterprise
solution. You will learn about the security features provided by Microsoft
Windows 2000. You will also learn about the fundamental security concepts of
authentication and authorization and how authorization policies are established
for COM+ applications These policies govern which users should be permitted
access to the various parts of the application and are defined by using roles.
First, you will review the security features provided by Windows 2000 and will
learn about the authentication options available for intranet- and Internet-based
solutions. These policies govern which users should be permitted access to the
various parts of the application. You will then learn how to implement role-
based security and how you can assign roles declaratively and
programmatically. You will also learn about the various security models that
you can apply to multitier systems. Finally, you will learn about best practices
that you should follow when managing security in enterprise solutions.

Objectives
After completing this module, you will be able to:
!
Describe the major security features and security models provided by the
Windows 2000 platform.
!
Explain how authentication and authorization works.
!
Describe the authentication options available to Internet solutions based on
COM+ and Internet Information Services (IIS).
!
Implement declarative security by using COM+ roles.
!
Implement programmatic security by using security context information.
!
Assign an identity to a COM+ application.

Slide Objective
To provide an overview of
the module topics and
objectives.

Lead-in
In this module, you will learn
how to implement security in
COM+ both declaratively
and programmatically.
2 Module 8: Making Applications Secure

#
##
#

Overview of Windows 2000 Security
!
Distributed Security Model
!
Public Key Cryptography
!
Centralized Access Control
!
Security Providers
!
Authentication and Authorization
!
Securing an Internet-Based Solution


In this section, you will learn about the security features provided by Windows
2000. While Windows 2000 is fully compatible with previous versions of
Windows NT
®
, Windows 98, and Windows 95, the security model has been
enhanced considerably, notably by the introduction of the Kerberos
authentication protocol and the increased emphasis on Internet-based security
technologies.
You will learn about the distributed security model that is designed to support
enterprise applications. You will then learn some of the key terminology and
concepts of Windows 2000 security, including the concept of public key

cryptography. You will learn how you can manage security groups centrally in
Active Directory
™
to provide control over access to resources. You will also
learn how Windows 2000 supports multiple security providers to support
distributed applications.
Finally, you will learn about the concepts of authentication and authorization.
You will learn how these concepts help to answer the two most basic security-
related questions: how to prove that a user is who she claims and how to
determine which users are allowed to perform particular operations.
This section includes the following topics:
!
Distributed Security Model
!
Public Key Cryptography
!
Centralized Access Control
!
Security Providers
!
Authentication and Authorization
!
Securing an Internet-Based Solution

Module 8: Making Applications Secure 3


Distributed Security Model
!
Windows 2000 Distributed Security Features

Single Sign-OnSecure Channels
Smart CardsKerberos Authentication
Public Key InfrastructureActive Directory Integration


Security is a vital element in any distributed application. Specifically,
applications must use authentication to validate users and prove that they are
whom they claim. Applications must also implement authorization to ensure
that users can only perform tasks for which they have been given permission.
Typically, different groups of users have different privileges when using an
application. For example, in a company procurement system, employees can
use the application to order goods and only system administrators can amend
product catalogs.
As enterprise systems open to the Internet, businesses need to interact with
partners, suppliers, and customers by using Internet-based technologies. The
issue of authenticating Internet users (proving that they are whom they claim)
and securing sensitive data as it crosses public networks presents challenges in
addition to providing security in a domain environment. Windows 2000
addresses many of the issues relating to Internet security by using a public key
infrastructure (PKI) based on public key cryptography. For information about
public key cryptography, see Public Key Cryptography in this module.
Windows 2000 Distributed Security Features
Windows 2000 has many new features to simplify domain administration,
improve performance, and integrate Internet security technology. These features
include:
!
Integration with Active Directory
Active Directory provides the store for all domain security policy and
account information. Using Active Directory provides significant
improvement over the registry-based implementation in previous versions of

Windows NT, both in performance and scalability. Active Directory
supports a hierarchical namespace for user, group, and computer account
information.
Delivery Tip
Mention that there is
glossary of security terms in
the student notes so
students can review as
needed to prepare for this
module.
4 Module 8: Making Applications Secure



Active Directory allows accounts to be grouped by organizational units
rather than a flat domain account namespace. This feature allows you to
organize the namespace for account information to represent the
departments and organizational structures found within your company.
Active Directory also allows account updates at any domain controller, not
just the Primary Domain Controller (PDC). Multiple master replicas of
Active Directory at other domain controllers are updated and synchronized
automatically.
Windows 2000 domains can be organized into a hierarchical domain tree.
The implicit domain relationships between domains allow users with
accounts in one domain to be authenticated by resource servers in another
domain. Management of domain trusts is simplified under Windows 2000
because Active Directory supports two-way transitive trusts between
domains that are part of the same Windows 2000 domain tree. For example,
if Domain A trusts Domain B, and Domain B trusts Domain C, then Domain
A also implicitly trusts Domain C. This transitive trust contrasts with the

one-way explicit trust model available under previous versions of Windows
NT.
!
Kerberos authentication protocol
The Kerberos authentication protocol is used as the primary security
protocol for access to resources within or across Windows 2000 domains.
Kerberos is a mature industry standard and includes features such as mutual
authentication and support for authorization delegation from clients to
servers.
!
Secure channel protocols providing data integrity and privacy across public
networks
Using secure channel security protocols including Secure Sockets Layer
(SSL 3.0) supports client authentication by mapping user credentials in the
form of public key certificates to existing Windows 2000 accounts. Internet
browsers and servers use these protocols for mutual authentication, message
integrity, and confidentiality.
!
Public key infrastructure
Windows 2000 introduces a comprehensive public key infrastructure to the
Windows platform. This feature allows developers to take advantage of
shared-secret or public-key security mechanisms in their applications.
Public key cryptography can be used in a number of areas, primarily
authentication, message integrity, and confidentiality.
Windows 2000 provides Microsoft Certificate Server for organizations to
issue X.509 version 3 certificates to employees or business partners. In
Internet scenarios with clients outside of the Windows 2000 domain
environment, or in disconnected situations involving Microsoft Message
Queue (MSMQ), certificates can be used to convey client credentials for
authentication purposes. Windows 2000 provides the Crypto API to handle

certificate management.
!
Smart cards for interactive log on
Windows 2000 supports the optional use of smart cards for interactive log
on, in addition to passwords. Smart cards support cryptography and secure
storage for private keys and certificates.
Module 8: Making Applications Secure 5



!
Single Sign On
The primary goal of Single Sign On (SSO) is to ensure that users only have
to enter their user name and password (or use a Smart Card) once in a
session. After users are logged on to their local computer, they should be
able to access whatever resources to which they are entitled on whatever
computer or network those resources reside, without any further requests for
authentication information. Authentication is taking place, of course, but it
is invisible to the user and requires no further manual intervention on their
part. SSO is provided natively by Windows 2000 through both Kerberos and
the Secure Sockets Layer (SSL) protocol.
SSO also supports logging on to mainframe systems. Systems Network
Architecture (SNA) Server allows a user logged on to Windows 2000 to
access resources hosted on mainframes (running MVS, OS/400, and other
operating systems). Authentication can take place by using mainframe-
hosted security packages such as RACF, ACF2, and Top Secret.


Windows 2000 Terminology and Concepts
Computer security encompasses a diverse body of knowledge covering many

different concepts. The following table defines some of the key security terms
and concepts discussed in this module.
Term Definition

Access Control Entry (ACE) Used to either grant or deny a particular permission to
a given user or group. Contained with Discretionary
Access Control Lists (DACLs) and System Access
Control Lists (SACLs) and attached to a Security
Descriptor.
Access token Contains information identifying a user, the user’s
group membership, and the user’s privileges. Attached
to processes running under Windows 2000, identifying
the account under which the process is running.
Authentication The process of verifying that a user is whom he or she
claims.
Authorization The process of determining which users are allowed
access to which resources.
Certificate A tamper-proof packet of data issued by a certificate
authority (CA) and comprising the owner’s name and
their public key. The CA vouches that the person
named in the certificate owns that key.
Certificate authority) A body responsible for issuing certificates. At the
highest level, a recognized national or international
organization.
Credentials Data used by a principal to establish its identity.
Credentials usually include the domain name, user
name, and password. In the Kerberos authentication
protocol, tickets represent the client’s credentials.
Delegation One server, while impersonating a client, calls another
server as if it were that client.

6 Module 8: Making Applications Secure


Term Definition

Digital signature Encrypted data added to a message to represent the
sender’s identity and to ensure the message is not
modified in transit.
Discretionary Access Control
List (DACL)
List of Access Control Entries (ACEs) that control
access permissions to a secured resource. Attached to
security descriptors.
System Access Control List
(SACL)
List of Access Control Entries (ACEs) specifying
which operations on a secured object should generate
audit messages.
Impersonation A server thread accessing local resources by using the
security context of a client process.
Kerberos The default security support provider or authentication
mechanism used in Windows 2000.
Mutual authentication The server authenticates the client and vice versa.
Principal An entity recognized by the security system.
Generally, a user or service that requires
authentication.
Public/private key pairs A pair of numbers used for encrypting and decrypting
data. Data encrypted with the public key can only be
decrypted by using the private key and vice versa.
Security context The set of security attributes and rules that are in effect

during a communication session.
Security descriptor Attached to securable system objects. Contains a
DACL identifying who is and who is not permitted
access to the secured resource.
Security identifier (SID) An identifier used to uniquely identify Windows 2000
user and group accounts.
Single Sign-On A user need log on only once per network access and
will still be able to access resources distributed across
multiple computers (perhaps running different
operating systems) and potentially multiple networks.
Ticket An encrypted data packet issued by a trusted authority.
Used by Kerberos to vouch for a user's identity.


Module 8: Making Applications Secure 7


Public Key Cryptography
!
Encryption and Decryption
$
Shared secret encryption
$
Public key encryption
!
Digital Signatures
$
Used for authentication and to guarantee message integrity.
$
Only someone with the private key could have created the digital

signature.
$
Anyone with access to the corresponding public key can validate the
signature.
$
Any modification of the signed data invalidates the signature.
!
Certificates
$
Public key delivery mechanism
!
Certificate Authorities


With the increasing focus on Internet-enabled enterprise applications, it is
important to understand the concept of public key cryptography.
One of the first problems that security has to address is data being altered while
traveling on a network between two computers. This alteration could be due to
a network problem or result from someone deliberately changing the data (for
example, modifying bank records to debit someone else's account). The
simplest way to detect changes is to use hashing, in which a mathematical
function that always produces a consistently unique result is applied to the
message before it is sent. This result, or hash, is either appended to the message
or transmitted shortly thereafter. The receiving computer performs the same
hashing function on the message and compares its result with the received hash
value. If they differ, the message has been changed in transit.
Encryption and Decryption
Hashing does not prevent messages from being read. Encryption can be used
for this purpose by using one or more keys to perform encryption and
decryption. Encryption and decryption are mathematical transforms applied to

the data. The two forms generally used today are shared secret and public key
encryption.
!
Shared secret encryption
This form relies on using the same key for both encryption and decryption
and is also known as symmetric encryption. Shared secret encryption suffers
from a number of limitations. While the data can now be transferred
securely, there remains the problem of keeping keys secure. Shared secret
encryption typically relies on only two computers knowing the key. If a
third computer uses the same key, neither of the other computers will realize
that the messages are coming from a third party as long as they believe the
key is secret. This problem makes such keys vulnerable and raises the issue
of identifying where messages and keys originate.

8 Module 8: Making Applications Secure



!
Public key encryption

Public Key cryptography relies on mathematically generated key pairs and
an encryption algorithm that allows data encrypted with one of the keys to
be decrypted only by using the other key. Its owner is the only identity to
have the private key, while the public key is made publicly available (hence
the names of the two keys). This public/private key pair serves two
purposes:
•
To confirm that the originator of the message is the owner of the private
key, given the public key and an encrypted message.

• To ensure that only the owner of the private key can decrypt a message.
Note that anyone can encrypt a message by using the public key.

Digital Signatures
Public key cryptography allows you to create and validate digital signatures,
which can be attached to messages. A digital signature is similar to a person’s
handwritten signature. It can be used to authenticate a sender’s identity and
ensure that a message is not modified in transit. It is based on a mathematical
transform that combines the private key with the data to be signed in such a
way that:
!
Only someone with the private key could have created the digital signature.
!
Anyone with access to the corresponding public key can validate the
signature.
!
Any modification of the signed data invalidates the signature.

Certificates
Certificates form the basis of secure authenticated communication and access
control on the Internet. They exist primarily as a simple way of delivering a
public key with a guarantee that it came from the person whose name (and
possibly other personal details) is also included within the certificate. The
public key can then be used knowing that the only person who can decrypt the
associated messages is the person whose name and other details are in the
certificate.

The digest (or hash) of each certificate is encrypted by the private key of the
issuer, and as a result, it can only be decrypted by using the issuer's public key.

This key confirms that the issuer of the certificate is the source of the
certificate. Windows 2000 certificates are compliant with the international
X.509 standards.
With certificates, client can be assured of a server’s identity. The server proves
its identity by presenting a certificate. A user who connects to a Web site that
has a certificate signed by a trusted authority can be confident that the server is
actually operated by the company identified in the certificate. Similarly,
certificates enable server applications to be confident of a client’s identity.
When a user connects to a Web site, the server can be assured of the client’s
identity if the server receives the client’s certificate.
Module 8: Making Applications Secure 9



Certificate Authorities
The purpose of CAs is to issue certificates used to convey an individual’s or an
organization’s public key. CAs guarantee that the public key contained within a
certificate actually belongs to the person or organization whose name is on the
certificate.
Consider the problem that CAs aim to resolve. If you were presented with a
certificate supposedly containing your bank’s public key, how would you know
that the public key actually belongs to your bank and not an imposter? To
answer this question, you would need to carefully consider who told you that
this key was your bank’s public key. More specifically, do you trust the person
(or agency) who told you? If you do trust this person or agency (the CA), then
you can accept that the public key legitimately belong to your bank. If you trust
the CA, you implicitly trust the keys bound into the certificates they issue.
Without CAs, someone could create certificates that include public keys
claiming to be from someone other than their actual identity. Certificates are
themselves digitally signed by the CA to prove they originate from the

certifying authority.
Ultimately, the success of CAs is entirely dependent on whether the party
receiving the certificate trusts the authority who issued it and that the authority
properly verified the certificate owner’s identity. Beyond this trust, certificates
do not provide conclusive proof about the identity or trustworthiness of the
user. When applying for certificates, individuals must typically provide proof of
identity including names, addresses, birth dates, passport numbers, and national
insurance numbers.
10 Module 8: Making Applications Secure


Centralized Access Control


Within the enterprise, security groups are used to control access to resources.
These groups are listed in access control lists (ACLs), which define permissions
on resources and objects. Across the Internet, a user’s access may be based on
their identity being proven by a private key signature operation and the
corresponding public key certificate. Windows 2000 provides features that
allow a certificate presented by a remote user to be mapped to a Windows 2000
account. The access rights granted to the particular account then determine what
resources the user is allowed to access.
Security Identifiers
The security identifier (SID) identifies the user or security group object when a
user or group is used for security purposes. The SID is stored as a property of
user objects and security group objects in Active Directory. Active Directory
automatically generates the SID when the user or group is created. The system
ensures that SIDs are unique across a forest. If a user or group is moved to
another domain outside of the forest, the SID will change. However, the
globally unique identifier (GUID) associated with the Active Directory object

will remain the same.

Access Control Entries
An access control entry (ACE) grants or denies specific access rights to a
resource for individual users and groups. If a security group is given access
permission for a resource, the security group SID will be added to the ACE that
defines the granted permission.

Module 8: Making Applications Secure 11



Discretionary Access Control List
Resources maintain a discretionary access control list (DACL) that consists of a
list of ACEs that specify which users and groups are allowed to do what to that
resource. For example, when a security group is granted access permission to a
resource, the ACE that holds the group's SID will be part of the DACL
belonging to that resource.

DACLs may have many ACEs granting and denying permission to various
individuals and groups. The list may also be empty, meaning that no one has
any access rights to that resource. The list may be missing completely so that
everyone has full permissions on that resource.
In Active Directory, each object has a security descriptor property that stores a
DACL defining the access to that particular object or properties on that object.
Other securable objects such as folders and files also have associated security
descriptors containing access control lists.

Access Tokens
When a user logs on to a Windows 2000 domain, an access token is

automatically generated. This token is used when determining which resources
the user may access. An access token includes:

!
The user’s SID.
!
All of the SIDs of the security groups to which the user belongs.

Every process executed on behalf of a user has a copy of the user's access
token. This copy includes any servers that impersonate the user or that delegate
calls to other servers on the user's behalf.

When a user attempts to access any resource, the service that performs the
access impersonates the user. It creates a new access token based on the token
belonging to the user, but the new token also contains SIDs for all domain
groups to which the user belongs and SIDs that apply to the domain in which
the requested resource resides. This new token is then used by the service to
attempt to access the resource.
When performing an access check, the system walks the list of ACEs in the
DACL associated with the secured object to determine whether access should
be granted or denied. When a user is being granted access, this process also
determines the exact access rights granted to the user. These rights may or may
not be the same as the requested access rights. The above illustration shows
how the access tokens are used to check security access.
12 Module 8: Making Applications Secure



Groups in Active Directory
Security (and distribution) groups have scope. There are three different kinds of

groups, each with a different scope.
Group type Description

Universal Contains users and groups from any domain and can be used for
access control in any domain.
Global Contains only users and groups from a single domain and can be
used for access control on any domain.
Domain Local Contains users and groups from any domain and can only be used
for access control on a single domain.

If there are multiple forests, users from one forest cannot be placed in groups
belonging to another forest, and groups from one forest cannot be given
permission in another.
For more information about security groups, see Networking Services/Active
Directory/Active Directory Programmers Guide/Managing Groups in the
Windows 2000 Platform SDK.
Module 8: Making Applications Secure 13


Security Providers

SSPI
Authenticated RPC
DCOM
COM+
NTLMSSP Kerberos Snego
LDAP
Directory
enabled APPs
using ADSI

HTTP
Internet Explorer,
Internet
Information

Server
SSPs


The security requirements for applications running in an enterprise environment
vary greatly, some with Internet integration and some without. To support these
varied requirements, Windows 2000 supports multiple security providers and
authentication protocols.
The Security Support Provider Interface
The Security Support Provider Interface (SSPI) API serves to insulate
applications from the underlying protocol details. This API is a standard
designed to support the security needs of applications running in a distributed
environment.
The SSPI is conceptually similar to Open Database Connectivity (ODBC).
ODBC insulates applications from a specific database server by offering drivers
that implement the standard ODBC API for client-side developers, while
communicating with the database by using a proprietary interface. In a similar
way, security providers can implement the SSPI API in a DLL called a Security
Support Provider (SSP). Applications written to work with one SSP require
few, if any, modifications to work with another SSP.
The primary SSPs available to COM+ applications are:
!
NTLMSSP (NT LAN Manager SSP)
!
Kerberos

!
Snego (Simple Negotiation)

14 Module 8: Making Applications Secure



NT LAN Manager Security Support Provider
Prior to Windows 2000, the Microsoft Windows NT LAN Manager Security
Support Provider (NTLMSSP) was the only SSP available. This security
package is based on the NTLM challenge-response protocol for authentication.
In the challenge-response model, the server issues a challenge to the client by
sending some data. The client then uses an encoded version of the user’s
password to encrypt the data provided by the server. The encrypted response is
then returned to the server, where it is decrypted and compared with the original
data sent to the client. If the data is the same, the user is authenticated.
Kerberos
The Kerberos version 5 authentication protocol replaces NTLM as the primary
security protocol in Windows 2000. Kerberos is a more sophisticated
authentication protocol than NTLM and supports additional features, including
mutual authentication and delegation of security information from one machine
to another. With Kerberos, clients obtain tickets from the Kerberos Key
Distribution Center (KDC) and they present these tickets to servers when
establishing connections. Kerberos tickets represent the client’s security
credentials.
Simple Negotiation Mechanism
While NTLMSSP and Kerberos are real authentication protocols, Snego
(Simple Negotiation Mechanism) is a pseudo-SSP used to negotiate between
real SSPs. COM+ uses Snego to decide which authentication service to use. For
Windows 2000 to Windows 2000 communication, Kerberos is the chosen SSP,

while for Windows 2000 to Windows NT 4 communication, NTLMSSP is
chosen as the lowest common denominator.
SSPI and COM+
Although the SSP is a programmable interface, it is rarely called directly.
Instead, most applications will use other intermediate layers that wrap the SSPI
and make it easier to use security providers. For example, application interfaces
provided by an authenticated remote procedure call (RPC) and the Distributed
Component Object Model (DCOM) provide higher-level abstractions.
COM+ serves to further insulate the enterprise developer from the security
details. COM+ handles the authentication process automatically, although you
can determine authentication level requirements by using the administrative
tool. For more information about authentication, see Authentication and
Authorization in this module. The above illustration shows the relationship
between COM+ security, DCOM, and authenticated RPC.

Module 8: Making Applications Secure 15


Authentication and Authorization
!
Authentication
$
Determining user’s identity
!
Authentication Levels
Authenticates, verifies and encrypts all data
packets
Packet Privacy
Authenticates every packet and verifies data
integrity

Packet Integrity
Authenticates every packetPacket
Authenticates at the beginning of each method
call
Call
Authenticates only when client first connects to
server
Connect
No authentication; anonymous accessNone


The fundamental goal of any security system is to control access to protected
resources. The security system must determine, based on the identity of the
user, exactly what the user is allowed to do and what resources the user is
allowed to access.
Clearly, any form of access control policy is totally reliant on the security
system being certain of the user’s identity. The process of ascertaining that the
user is actually who she claims and not an imposter is called authentication. The
process of determining which users are allowed to access which resources is
called authorization. An authorization policy represents this information.
Authentication
COM+ handles the issue of authentication transparently by using the underlying
COM services and the operating system’s SSP. This approach allows the
application developer to focus on the issue of authorization. As described
earlier, Windows 2000 offers a number of authentication packages in the form
of SSPs. Windows 2000 prefers to use Kerberos, and depending on the
capabilities of the client, this method will be chosen when possible. Kerberos
provides the client with some added protection because it supports mutual
authentication. This feature allows the client to authenticate the server and
guard against spoof servers, in addition to allowing the server to authenticate

the client. As mentioned previously, it is imperative for the server to
authenticate the client to support any form of authorization policy.
To use the operating system’s authentication service, both client and server
specify their desired authentication levels. These authentication levels provide
varying degrees of security, ranging from none to the encryption of every
packet of data sent between client and server. The following table lists the
various authentication levels.
16 Module 8: Making Applications Secure


Authentication level Meaning

None No authentication (that is, anonymous access).
Connect Authenticates the client only when the client first connects to
the server.
Call Authenticates the client at the beginning of each method call.
Packet Authenticates that every packet of data is from the expected
client.
Packet integrity Authenticates data integrity and verifies that it has not been
modified during the transfer between client and server.
Packet privacy Authenticates, verifies, and encrypts all data packets. This
authentication level prevents anyone from spying on the data
when it is being transferred between client and server.

The degree of security increases as you move through the levels toward packet
privacy. However, increased security comes at the cost of performance. If
encryption is being used frequently, you should consider using a network card
that supports encryption because hardware encryption is considerably faster.
Setting the Authentication Level
Both client and server must specify their desired authentication levels. You can

configure the authentication level of a COM+ server application by using the
Component Services tool.
Module 8: Making Applications Secure 17



!
To configure the authentication level of a COM+ server application
!
From the application's Properties dialog box, click the Security tab to
display the authorization and authentication options as shown in the
following illustration.

The client sets its own authentication level by calling the COM API
CoInitializeSecurity when it first starts. For clients written in Microsoft
Visual Basic
®
, this function is automatically called when the client
application is started.
If the client and server specify different authentication levels, the higher of
the two levels is chosen.

For COM+ library applications that run in the address space of the client
process, the authentication level is inherited from the client process. The library
application has no way of choosing its authentication level. The
Authentication level for calls combo box on the Security page of the
application’s Properties dialog box is replaced by an Enable authentication
check box for library applications. This check box simply allows you to specify
whether the client process should perform client authentication on calls into the
library application.

Note