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.


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 e-commerce 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

InternetInternet

Contractor/ Consultant

Customer

Vendor

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 Web-based 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 partner-accessible resources are separated from internal network resources.

Using Dial-Up Methods to Provide Network Access

Partner Network

Single-computer dial-up access

Router-to-router dial-up access

CorporateOffice

Operating systems do not support VPNs

Secure data not on public networks

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 router-to-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 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

Plaintext Message

PrivacyImpersonationViruses

Sending Messages Without Security

Sending Messages Using S/MIME

Authentication, Data Integrity, and Non-repudiationEncryption

S/MIME Message

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 SecurityMost 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 StandardThe 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.


PrivacyImpersonationViruses

Plaintext Message

Web Client

Web Server

Authentication Data IntegrityNon-RepudiationEncryption Certificate Mapping

SSL, TLS, SGC,

and Certificates

Web ServerWeb

Client

Secure Web Communication

Nonsecure Web Communication

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.


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

VirusesTrojan Horses

Partner’s Web Server or FTP Server

Web Client

Digitally SignedSoftware

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

Share PermissionsFolderA

Print Permissions

NTFS 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 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.

InternetInternet

Securing Tunnel Connections

L2TP over IPSec

PPTP

IPSec Tunnel Mode

Partner Network

Remote User

Authentication andEncryption

CorporateOffice

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 (EAP-TLS), 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

Callback Security

Caller ID

Mutual Authentication

Data Encryption

Remote Access Server

Corporate Network

Dial-Up Business Partner

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

Session Limits

Changing the User Shell

Connection Permissions

File Permissions

Data Encryption

Security Limitations

Terminal Server

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 128-bit 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

Authentication

Encryption

Access Control

CorporateOffice

InternetInternet

BusinessPartners

Customer

Partner Network

Router-to-router dial-up access

Contractor/ Consultant

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.

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.


Creating domains for partners

Creating organizational units for partners

Creating user and group accounts for partners

Creating Domains for Partners

OUOU

OUOUOUOU

DomainDomainOUOU OUOU

Partner Domain

DomainDomain

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

OUOU

Groups and Users

OUOU

OUOUOUOU

DomainDomainOUOU OUOU

TemporaryWorkers

Contractors Vendors

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

OUOU

Groups and Users

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 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 one-way 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.


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

DomainDomain

Windows 2000

Domain

Resources

One-Way Trust Kerboros V5

Authentication Protocol

Resource Access

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

DomainDomain

Resources

Windows NTWindows NTDomainDomain

Resource Access

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

KerberosRealm

Unix-based Computers

Authentication

KerberosRealm

Windows 2000 Client

KerberosRealm

Unix-based KDC

TrustRelationship

Windows 2000–based KDC

Authentication

Windows 2000 Domain

When your partner's network contains non-Windows-based 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






module 13:extending the network to partner organizations

Documents

network access slide

secure network access

direct network access

partner organizations

business partners

direct access

trusted partners

authenticating partners