Module 13. Extending the Network to Partner Organizations
Download
Report
Transcript Module 13. Extending the Network to Partner Organizations
Module 13:Extending
the Network to Partner
Organizations
Overview
Providing Access to Partner Organizations
Securing Applications Used by Partners
Securing Connections Used by Remote Partners
Structuring Active Directory to Manage Partner
Accounts
Authenticating Partners from Trusted Domains
Most organizations establish business partner
relationships with customers, vendors, allied
companies, suppliers, consultants, regulators, and
others who require access to the organization's data
and applications. Before providing your business
partners with access to your network, you must have a
solution for secure access. By using Microsoft®
Windows® 2000, you can provide secure network
access to your partners.
At the end of this module, you will be able to:
Describe the connection methods that can be used to provide
access to partner organizations.
Describe the ways to provide secure access to data, applications,
and communications shared with trusted partners.
Design a secure framework for partners to use tunnel connections,
dial-up connections, and Terminal Services to access the private
network.
Design an Active Directory™ directory service structure for
partners.
Design a secure framework for authenticating partners from trusted
domains.
Providing Access to Partner Organizations
Exchanging Information with Partners
Using an Extranet to Provide Network Access
Using Dial-Up Methods to Provide Network Access
Business relationships with partners require a constant
exchange of information between the partner and the
organization. To effectively exchange information with
your partners, provide them with direct network access
to your organization's data and applications.
When providing direct access to your network, consider
methods to:
Secure the exchange of information between your
customers and your organization, and between partner
organizations.
Establish an extranet to provide partners with access to
selected resources.
Grant dial-up access to partners that do not have access
to the Internet, or dedicated communication lines to your
organization.
Exchanging Information with Partners
Exchanging Information Between Organizations
Data integrity
Non-repudiation
Exchanging Information with Customers
Secure transactions
Privacy
Secure access
When you extend your network to other organizations,
or provide network access to your customers, you need
to ensure the integrity, security, and privacy of the
information that is exchanged.
Exchanging Information Between Organizations
The type of information that you need to transmit
between business partners determines the security
options that you must select to secure your network.
Security options for communications between partner
organizations include;
Data integrity. You must provide a method to ensure that
data is reliably and securely exchanged, and that it
cannot be intercepted and viewed or modified during
transit.
Non-repudiation. You must provide digital signatures to
guarantee that important documents and e-mail
transmissions originated from the sender.
Exchanging Information with Customers
You can extend the network to customers who use an ecommerce server so that they can purchase items
directly from your organization over the Internet.
Consider the following in planning an e-commerce
design that includes customer access to your network:
Secure transactions. Ensure that confidential information
that customers enter, such as credit-card information, is
protected during transmission between the client and the
e-commerce server.
Privacy. Ensure that the content or purpose of a
transaction is not revealed to the public.
Secure access. Ensure that access is restricted to
confidential data, such as the customer's transaction
history.
Using an Extranet to Provide Network Access
Corporate Office
Customer
Vendor
Internet
Contractor/
Consultant
Client
For individuals and organizations that have access to
the Internet, you can create an Internet-based extranet
to provide an extension of your organization. Because
an extranet is Internet based, you can provide partner
access to your network without having to maintain
modems and communication devices.
Protecting access to an extranet involves the same security
features that you use to protect access to your private network. To
secure your extranet, consider including:
Secure Sockets Layer (SSL) protocol, which provides secure Webbased transactions.
Tunnel connections, which are secure data exchanges between a
remote client and a network, or between two networks.
Certificate-based authentication, which provides for non-repudiation
and integrity of transmitted data.
Internet Protocol Security (IPSec), which provides integrity and
encryption of all data transmissions between two computers.
Multiple firewalls, which create a screened subnet where partneraccessible resources are separated from internal network
resources.
Using Dial-Up Methods to Provide Network Access
Corporate
Office
Router-to-router
dial-up access
Secure data not on
public networks
Operating systems
do not support VPNs
Single-computer
dial-up access
Partner Network
When your organization is not connected to the Internet,
you can provide dial-up access for business partners.
Dial-up access can be used when:
The partner's current operating systems and devices do not
support the required security for transmitting data over the Internet.
The data transmitted must be secured. With dial-up access, data
does not pass through a public network, which decreases the
chance of unauthorized access to the content.
Users require guaranteed data-transmission performance. A routerto-router dial-up connection ensures devoted bandwidth between
two networks.
Internet access is not required. Dial-up access will be used as the
sole means of communication between the partner and your
network.
Securing Applications Used by Partners
Securing E-mail
Securing Web Communications
Ensuring the Integrity of Downloaded Software
Securing Access to Shared Resources
Before you design network access for your business
partners, you need to determine which applications your
partners need to access and what is required to secure
the applications and the information contained in the
applications. The applications that an organization may
share with its partners include e-mail, Web pages,
downloaded software, and shared files. Appropriate
security must be defined for all applications and
information that are exchanged with partners.
In this lesson you will learn about the following topics:
Securing e-mail
Securing web communications
Ensuring the integrity of downloaded software
Securing access to shared resources
Securing E-mail
Sending Messages Without Security
Plaintext
Message
Privacy
Impersonation
Viruses
Sending Messages Using S/MIME
S/MIME
Message
Authentication, Data
Integrity, and Nonrepudiation
Encryption
When you exchange e-mail with your partners over
nonsecure portions of an intranet, or over the Internet,
you risk exposing proprietary and confidential business
information. You can use the industry-standard Secure
Multipurpose Internet Mail Extension (S/MIME) protocol
for securing e-mail communication within your
organization and between partners.
Note: Alternative e-mail encryption technologies such
as Pretty Good Privacy (PGP) can also be used to
secure e-mail communications with partners. You select
PGP or S/MIME based on the encryption support of your
e-mail system and your partner's e-mail system.
Sending E-mail Messages Without Security
Most e-mail messages are sent as plaintext over open
networks without any type of security. Plaintext
messages are subject to:
Privacy violators.
Impersonators.
Viruses.
Securing E-mail Messages Using the S/MIME Standard
The S/MIME standard enables the digital signing and
encryption of confidential mail. Secure e-mail messages
can be exchanged between S/MIME clients and servers
that run on any platform or operating system.
You can secure e-mail messages by using S/MIME for:
Authenticity, data integrity, and non-repudiation. S/MIME clients can
use certificates to digitally sign messages with the sender's private
key before sending the messages. The recipients then use the
sender's public key to verify the message by checking the digital
signature.
Encryption. Clients can generate symmetric encryption keys to
encrypt messages for confidentiality. The client encrypts the
symmetric encryption key by using the public key of each recipient,
and then sends the encrypted key, along with the encrypted
message, to the recipient. Recipients use their private keys to
decrypt the symmetric encryption key, and then use the symmetric
key to decrypt the message.
Securing Web Communications
Nonsecure Web Communication
Web
Client
Plaintext
Message
Privacy
Impersonation
Viruses
Web
Server
Secure Web Communication
Web
Client
SSL, TLS, SGC,
and Certificates
Authentication
Data Integrity
Non-Repudiation
Encryption
Certificate Mapping
Web
Server
When you use Web services to exchange information
with your partners, you risk the exposure of proprietary
and confidential business information. You can use SSL
and Transport Layer Security (TLS) protocols to keep
Web traffic confidential and secure.
Web Communications Without Security
Hypertext Transfer Protocol (HTTP), the standard Web protocol,
provides no security for Web communications because all
communications are sent as plaintext. Plaintext leaves Web
communications subject to attacks such as:
Privacy violation. Confidential or sensitive information that is
transmitted by using HTTP can easily be intercepted and read by
eavesdroppers, unless the information is protected by an encryption
technology.
Impersonation. Unauthorized Web servers can impersonate
authorized Web servers. Impersonation of authorized Web servers
can make Web clients easy targets for security breaches.
Unauthorized Web servers can contain virus-laden software,
malicious scripts, and programs that can be downloaded by users
who think they are using an authorized Web server.
Viruses. Components, such as scripts and executable files, that are
downloaded from the Web can contain viruses. Virus-scanning
software will scan all downloaded components for viruses.
Securing Web Communications
Secure Web communication protocols provide a way to
authenticate clients and servers on the Web, and to
protect the confidentiality of communication between
clients and servers.
To secure Web sites and communications, you can implement:
Authentication, data integrity, and non-repudiation. You can use
the SSL and TLS protocols to authenticate users and establish
secure channels for confidential, encrypted communications.
Encryption. You can use the Server Gated Cryptography (SGC)
protocol to authenticate users and establish secure channels for
confidential, encrypted financial transactions.
Certificate Mapping. You can map user certificates to network user
accounts to authenticate users and control user rights and
permissions for Web resources. Users must have valid certificates
issued by a trusted certification authority (CA).
Ensuring the Integrity of Downloaded Software
Partner’s Web Server
or FTP Server
Digitally Signed
Software
Web Client
Viruses
Trojan Horses
When you exchange applications and data with your
partners over the Internet, you are at risk of
downloading software infected with viruses and Trojan
horses. Software infected with viruses can cause
damage to your network, and Trojan horses can provide
unauthorized access to confidential information and
resources on your network.
To ensure the integrity of downloaded software, you can:
Configure Group Policy settings so that users in your
organization can download only digitally signed
software. Digitally signed software verifies the origin of
the software and confirms that no one has tampered
with it.
Configure security settings for Microsoft Internet
Explorer to prevent the downloading of unsigned
software from defined security zones. Depending on the
Internet Explorer zone from which the software
originates, you can specify an appropriate security
level.
Securing Access to Shared Resources
NTFS Permissions
Share Permissions
FolderA
Print Permissions
You may need to share the same types of information
with both your internal users and your partners.
However, you may want to provide different types of
access to this information. For example, you can allow
both internal users and your partners to read the
contents of a file, but allow only the internal users to
modify the files.
You can use security groups to simplify the
management of access permissions for different types
of users. You can grant specific security groups the
NTFS file system permissions to files that are accessed
by using shared folders, Web pages, or File Transfer
Protocol (FTP).
Securing Connections Used by Remote Partners
Securing Tunnel Connections
Securing Dial-Up Connections
Securing Access for Terminal Services Users
Discussion: Providing Secure Access to Business
Partners
When you provide your partners with remote access connections to
your organization, you must ensure that the connection is secure.
To secure remote access connections, you can:
Secure tunnel connections to the network.
You can connect partner organizations over public networks, such
as the Internet, by creating tunnels between the two partner
organizations. All network traffic between the partner organizations
will be encrypted within the tunnel.
Secure dial-up connections to the network.
You can allow select partners to access the network by using dial-up
connections. Dial-up connections must be configured to ensure that
only approved partners are allowed to connect.
Secure Terminal Services sessions.
You can provide Terminal Services for a partner to run a session on
your Terminal server, which will allow the partner to access your
organization's data. The Terminal Services session can be secured
to allow only required access to partners.
Securing Tunnel Connections
Remote
User
Authentication and
Encryption
Corporate
Office
L2TP over IPSec
PPTP
IPSec Tunnel Mode
Internet
Partner
Network
Tunnel connections provide a secure method for your
partners to connect to your network over the Internet.
All data that is transferred between the two networks is
encrypted within a secure tunnel as it passes over the
Internet. To create a secure tunnel solution, you must
choose the appropriate tunneling protocol.
L2TP over IPSec Connections
Layer Two Tunneling Protocol over IPSec (L2TP/IPSec)
connections provide the most secure authentication and
encryption method. For L2TP/IPSec connections, you
must install a computer certificate on both the virtual
private network (VPN) client and the VPN server. Both
computer certificates must either be from the same CA,
or the root certificate of each computer's CA must be
installed as a trusted root certification authority in each
other's trusted root certificate store.
L2TP/IPSec tunnels require that the two endpoint tunnel
servers not be located behind a network address
translation (NAT) server. L2TP will not work through a
NAT server.
PPTP Connections
Point-to-Point Tunneling Protocol (PPTP) connections
are used when data transmissions must pass through a
NAT server, or when the partner computers do not
support L2TP/IPSec. For PPTP connections, Extensible
Authentication Protocol-Transport Level Security (EAPTLS), by using either smart cards or Microsoft
Challenge Handshake Authentication Protocol version 2
(MS-CHAP v2), is highly recommended. EAP-TLS
provides mutual authentication and provides the most
secure method of exchanging credentials.
IPSec Tunnel Mode Connections
IPSec tunnel mode connections are used when data transmitted
between two networks must be encrypted as it passes over the
public network. Whereas PPTP and L2TP/IPSec provide user
authentication, IPSec tunnel mode only requires computer
authentication. The IPSec tunnel can be restricted to two defined
endpoints that are authenticated by using either a shared secret or
certificates.
IPSec tunnel mode is often deployed in cases in which Windows
2000 is required to interoperate with hardware routers, such as
Cisco routers, that support IPSec tunnel mode. IPSec tunnel mode
requires that the two endpoints of the tunnel not be located behind
a NAT server.
Note: Both L2TP/IPSec and IPSec tunnel mode can be implemented
at a NAT server because the IPSec-encrypted traffic is decrypted
before any address information is translated.
Securing Dial-Up Connections
Remote Access
Server
Dial-Up Business
Partner
Callback Security
Caller ID
Mutual Authentication
Data Encryption
Corporate Network
By providing dial-up access to your network, you
introduce security risks because anyone with a modem
and the telephone number can attempt to connect to
your network, whether or not they are authorized to do
so.
Windows 2000 provides a number of methods to ensure security for dial-up
connections, including:
Callback security. A remote access server hangs up a connection initiated
by a remote user and then calls back the remote user on a pre-assigned
callback number. Using a pre-assigned callback number ensures that the
user is calling from a pre-approved location.
Caller ID. A remote access user must call from a specific telephone number
that the network administrator specifies. If the user does not call from that
specific telephone number, the remote access server rejects the connection
attempt.
Mutual authentication. A remote access server is authenticated by a
remote user and the remote user is authenticated by the remote access
server. Mutual authentication ensures that unauthorized servers are unable
to obtain user information.
Data encryption. Data is transmitted in a form that is unrecognizable to
unauthorized users who try to access the information. You can use the
EAP-TLS or MS-CHAP v 2 authentication protocols to encrypt data as it is
transmitted by using Microsoft Point-to-Point Encryption (MPPE).
Alternatively, data can be encrypted by using IPSec Encapsulating Security
Payloads (ESPs).
Securing Access for Terminal Services Users
Terminal
Server
Session Limits
Changing the User Shell
Connection Permissions
File Permissions
Data Encryption
Security Limitations
Terminal Client
By running Terminal Services on Windows 2000 Server,
you can enable all client application execution, data
processing, and data storage to occur on the Terminal
server. Terminal Services is an effective and reliable
way to distribute your Windows-based programs to your
partners.
Consider the following when designing a secure solution for users of
Terminal Services:
Session limits. Limit the amount of time that active sessions, disconnected
sessions, and idle sessions (those without client activity) remain on the
server.
Changing the user shell. Terminal Services sessions can be configured to
run a specific application as the user shell. This configuration limits the
user to running only the desired application. If the application is closed,
the Terminal Services session is terminated.
Connection permissions. Manage connection permissions to secure server
access. The Transmission Control Protocol/Internet Protocol (TCP/IP)
connection that is automatically installed with Terminal Services includes a
set of default permissions. You can modify these default permissions by
setting different permissions for different users or groups, thereby
adjusting the permissions to meet the requirements of your organization.
File permissions. In a multi-user environment, limit users' access to folders
and files. To apply permissions to subdirectories and files at the user level,
you need to have NTFS on all volumes. Without the security that NTFS
provides, any user has access to every directory and file on the server
running Terminal Services.
Data encryption. Secure transmitted data between the
Terminal Services client and server. You can assign data
transfers between the Terminal Services client and
server at one of three different levels of encryption
Low-level encryption. Encrypts only the traffic from the
client to the server.
Medium-level encryption. Encrypts traffic as it is
transmitted in both directions.
High-level encryption. Encrypts the traffic by using 128bit encryption (if available at your location) in both
directions.
Security limitations. Terminal Services does not allow
all security configurations that can be used during the
interactive logon process. For example, when using
Terminal Services, you need to disable anonymous FTP
to prevent unsecured access to the file system. When
planning security for Terminal Services, consider the
following security limitations:
Smart cards and other hardware-based authentication
mechanisms cannot be used with Terminal Services
users.
Remote access does not limit access to Terminal
Services users. Therefore, if one user establishes a
modem or VPN link to the Internet or another system,
every user on Terminal Services has access to that link.
Discussion: Providing Secure Access to Business
Partners
Corporate
Office
Customer
Router-to-router
dial-up access
Partner
Network
Internet
Contractor/
Consultant
Authentication
Encryption
Access Control
Business
Partners
Before you provide partners access to your network,
you need to determine the security strategies that will
ensure that partners have the appropriate level of
access to information.
Scenario
You are part of a cross-functional team that includes
members from Information Services (IS), and from the
legal, marketing, human resources, and security
departments. Your organization has decided to extend
its network to partners to share information from its
databases, to process orders, and to provide customer
service and documentation. Your team plans to create
an extranet to extend the network to partners. In
addition, some partners in remote offices will continue
to communicate with the organization by using a dial-up
connection. You need to consider how to implement
authentication, encryption, and access control to
protect resources on your network.
Structuring Active Directory to Manage Partner
Accounts
Creating Domains for Partners
Creating Organizational Units for Partners
Creating User and Group Accounts for Partners
You can use the hierarchical structure of Active
Directory to simplify security management. You can
group partner objects-such as user, group, and
computer accounts-into domains, organizational units
(OUs), and security groups.
In this lesson you will learn about the following topics:
Creating domains for partners
Creating organizational units for partners
Creating user and group accounts for partners
Creating Domains for Partners
OU
Domain
OU
Partner Domain
OU
OU
OU
Domain
You can use a domain within Active Directory to separate user,
group, and computer accounts for partners. Separating partner
accounts in a separate domain may be useful when:
The account policy requirements for external users are absolutely
different from the security policies for internal users. By creating
separate domains, administrators can set unique password policies,
account lockout policies, and Kerberos version 5 policies for the users
in the domain.
For business reasons, you want partners to manage their own
accounts (or it is required that they do so).
The partner is located in a different geographical location from the
organization, and the organization's network and the partner's network
are separated by slow links. Creating an additional domain may be
necessary to reduce replication traffic.
Note: For slow links that can still handle replication traffic on a less
frequent schedule, you can configure a single domain and use
multiple sites.
Creating Organizational Units for Partners
OU
Temporary
Workers
OU
OU
Contractors
OU
OU
Domain
Vendors
OU
Groups
and Users
OUs are useful when you want to delegate
administration of user, group, and computer accounts to
your partners, but still want to centralize the
management of domain-wide security.
Delegating administrative authority by using OUs has
the following benefits:
You can eliminate the need to have people regularly log
on to accounts that have administrative authority over
an entire domain.
The amount of administrative control that you grant can
be complete (such as creating users and changing
passwords) or limited (such as maintaining print
queues).
OUs can be created to allow delegation of
administration to a single administrator. If multiple
administrators are defined, create a separate OU for
each administrator.
Creating User and Group Accounts for Partners
Groups and Users
OU
Controlled Access
Internal and External
Business Partners
When you want to control access to resources on your
organization's network, you can create specific group
accounts for partners. User accounts are created for
external users and then added to these group accounts.
You can use these group accounts to assign
permissions to objects such as files, folders, and
printers.
Group accounts are also useful for external partners
and contractors who work in the facility provided by the
organization but are only allowed restricted access to
the network.
Authenticating Partners from Trusted Domains
Authenticating Partners in a Windows 2000 Domain
Authenticating Partners in a Windows NT Domain
Authenticating Partners in a Kerberos Realm
A trusted domain is a trust relationship established
between two domains to enable users in one domain to
be authenticated for resource access in another domain.
You can establish an external trusted domain outside
your organization's forest to authenticate user accounts
from partner organizations. You can combine two oneway trusts so that the partner's domain authenticates
user accounts from your domain. Users from your
domain can then access resources located on the
partner's network. A trusted domain can also be
established between your domain and a Kerberos V5
realm.
In this lesson you will learn about the following topics:
Authenticating partners in a Windows 2000 domain
Authenticating partners in a Windows NT domain
Authenticating partners in a Kerberos realm
Authenticating Partners in a Windows 2000 Domain
Partner Domain
One-Way Trust
Kerboros V5
Authentication Protocol
Windows
2000
Domain
Domain
Resource Access
Resources
To grant access to resources in a domain in your
organization's forest, you can establish a one-way trust
relationship between your Windows 2000 domain and a
partner's Windows 2000 domain. After the trust
relationship is established, your domain can
authenticate users in the partner's network and grant
the users rights and permissions to access resources in
your organization's domain.
You create a one-way trust relationship by creating an
explicit trust to the external domain. Explicit trusts are
trust relationships that you create, as opposed to trust
relationships that are automatically created when a
domain controller is installed in the same forest as an
existing domain.
Windows 2000 domains use the Kerberos V5
authentication protocol for logon authentication when
all of the following conditions are met:
The user who is logging on uses a security account in a
Windows 2000 domain.
The computer to which the user is logging on is a
Windows 2000-based computer.
The computer to which the user is logging on is joined to
a Windows 2000 domain.
A Kerberos trust path must exist between user account
domain and computer account domain.
Authenticating Partners in a Windows NT Domain
One-Way Trust
NTLM
Authentication Protocol
Partner Domain
Windows NT
Domain
Domain
Resource Access
Resources
You can establish a one-way trust relationship between
a domain in your forest and a partner's Microsoft
Windows NT® version 4.0 domain. After the trust
relationship is established, your Windows 2000 domain
can grant access to users in the partner's network. Your
organization's domain can then grant authenticated
users rights and permissions to access resources.
The NTLM protocol, a challenge/response
authentication protocol, is always used for
authentication between a Windows 2000 domain and a
Windows NT 4.0 domain.
Note: The NTLM authentication protocol is the default
protocol in Windows NT 4.0 and earlier versions of
Windows. The NTLM authentication protocol is included
in Windows 2000 to support clients that use earlier
versions of Windows.
Authenticating Partners in a Kerberos V5 Realm
Windows 2000–
based
KDC
Windows 2000
Client
Windows 2000
Domain
Authentication
Trust
Relationship
Authentication
Kerberos
Realm
Unix-based
Computers
Kerberos
Realm
Unix-based
KDC
Kerberos
Realm
When your partner's network contains non-Windowsbased computers, but supports a Kerberos V5
implementation for authentication, you can establish a
Kerberos V5 realm.
A Kerberos V5 realm in a non-Windows-based network
is analogous to a Windows 2000 domain. The realm
consists of a Key Distribution Center (KDC), and
applications and services that use Kerberos V5
authentication protocols.
To use Kerberos V5 to authenticate partners, you select one of the
following:
Configure a Windows 2000 Server domain controller to serve as the
Kerberos V5 KDC server for Kerberos V5-based client and host
systems.
Configure a Windows 2000 Professional client to use a Kerberos V5
realm for authentication. Using the realm for authentication will
provide single sign-on to the realm and to the Windows 2000
domain.
Create a one-way or two-way trust relationship between a Windows
2000 domain and a Kerberos V5 realm. These trust relationships will
ensure that resources in the domain will recognize and accept
service tickets and ticket-granting tickets generated in the realm.
The tickets are used to gain access to an application server that
uses Kerberos authentication.
Lab A: Planning Partner Connectivity
Objectives
After completing this lab, you will be able to:
Analyze business partner requirements for access to a
corporate network.
Determine methods for partner connectivity.
Prerequisites
Before working on this lab, you must have:
Knowledge of methods used for securing partner
connectivity
Exercise 1: Determining Network Transport Security
Goal
Rogue Cellars, a small but well-funded high-technology
firm in Vancouver, develops computer games. The
company recently purchased Northwind Traders in an
effort to expand its customer base. The security
administrator has the task of designing a secure
network solution for Rogue Cellars and Northwind
Traders. The solution must provide secure access for
business partners who access information within the
combined network.
Scenario
Rogue Cellars is completing the final legal arrangements for its
purchase of Northwind Traders.
Northwind Traders develops computer games and is currently
working on a new adventure game. Northwind Traders releases a
direct-sales summer catalog every year to promote game sales and
hires contingent staff to handle the extra volume of telephone
traffic.
Multimedia content in an adventure game currently under
development has been outsourced to Contoso, Ltd., a multimedia
developer in Melbourne, Australia.
As part of its media release program, Northwind Traders provides
detailed game information to editors of computer gaming
magazines.
Rogue Cellars uses a customized game development package that
is maintained by a partner organization based in Munich, Germany.
The package runs on a computer running Windows 2000 Advanced
Server.
Design Criteria
The plan for secure partner access must meet the following criteria:
Rogue Cellars must be able to secure network communications
with its law firm regarding the purchase of Northwind Traders.
Northwind Traders's outsourcing manager requires that contingent
staff be able to log on to computers on the Northwind Traders
network. The outsourcing manager wants to manage network
access permissions for contingent staff separately from permanent
staff.
The project manager of the new adventure game requires that game
data files be made available to Contoso, Ltd. Users on Northwind
Trader's software development team will also require access to data
on the Contoso, Ltd. network.
The editors of the computer gaming magazines require secure
access to confidential game specifications from their offices.
A problem has occurred with the game development package. To
solve the problem, a software engineer from the Munich office
requires access to the desktop of the server running the package.
Review
Providing Access to Partner Organizations
Securing Applications Used by Partners
Securing Connections Used by Remote Partners
Structuring Active Directory to Manage Partner
Accounts
Authenticating Partners from Trusted Domains