DirectAccess-DA Benefits

DirectAccess provides the following benefits:
• Seamless connectivity. DirectAccess is on whenever the user has an Internet
connection, giving users access to intranet resources whether they are traveling, at the local
coffee shop, or at home.
• Remote management. IT administrators can connect directly to DirectAccess client
computers to monitor them, manage them, and deploy updates, even when the user is not
logged on. This can reduce the cost of managing remote computers by keeping them up-to-date with critical updates and configuration changes.
• Improved security. DirectAccess uses IPsec for authentication and encryption.
Optionally, you can require smart cards for user authentication. DirectAccess integrates with
NAP to require that DirectAccess clients must be compliant with system health requirements
before allowing a connection to the DirectAccess server. IT administrators can configure the
DirectAccess server to restrict the servers that users and individual applications can access.
DirectAccess also enables users to get more out of other Windows 7 networking improvements,
such as:
• Federated Search. With Federated Search, desktop searches can include files and Web
pages on your intranet whenever the user is connected to your intranet. Because
DirectAccess connects users to the intranet when then connect to the Internet, Federated
Search works automatically any time the user has an Internet connection.
• Folder Redirection. With Folder Redirection, folders can automatically synchronize
between multiple computers across the network. If you enable DirectAccess, users with both
mobile and desktop computers can stay synchronized automatically whenever they connect
to the Internet.
• Replaceable computer scenario. In this scenario, a user’s applications, documents,
and settings are stored on the network and available from any computer. If a computer is lost
or corrupted, the replacement computer does not require user-specific configuration.
With DirectAccess, client computers are always connected, better protected, and easier to
manage.

References

Active Directory http://go.microsoft.com/fwlink/?LinkID=147288
DirectAccess http://go.microsoft.com/fwlink/?LinkId=151854
DNS http://go.microsoft.com/fwlink/?LinkId=147013
Group Policy http://go.microsoft.com/fwlink/?LinkId=100760
IPv6 http://go.microsoft.com/fwlink/?LinkId=17074
IPsec http://go.microsoft.com/fwlink/?LinkId=50170
NAP http://go.microsoft.com/fwlink/?LinkId=56443
PKI http://go.microsoft.com/fwlink/?LinkId=83694
UAG http://go.microsoft.com/fwlink/?LinkId=159955

DirectAccess Requirements

DirectAccess requires the following:
• One or more DirectAccess servers running Windows Server 2008 R2 (with or without
UAG) with two network adapters: one that is connected directly to the Internet and one that is
connected to the intranet (or to the DMZ). DirectAccess servers must be a member of an AD DS domain.
• On the DirectAccess server, at least two consecutive, public IPv4 addresses assigned to
the network adapter that is connected to the Internet.

(Why 2 consecutive IPv4 addresses ?

1: Teredo; is a bridging mechanism, designed to allow IPv6 traffic to be sent over an IPv4 network.And Teredo needs to detect the type of NAT used on client side, because it can not work with all types. (We will talk about Teredo deeply later also).

2: IPSec; DA uses 2 IPSec tunnels.And a IPSec tunnel needs to bind to a dedicated IP address.)

• DirectAccess client computers that are running Windows 7 Enterprise or Windows 7
Ultimate. DirectAccess clients must be members of an AD DS domain.

• At least one domain controller and DNS server that is running Windows Server 2008 SP2
or Windows Server 2008 R2. When UAG is used, DirectAccess can be deployed in some
scenarios with DNS servers and domain controllers that are running Windows
Server 2003 R2.

• A public key infrastructure (PKI) to issue computer certificates, and optionally, smart card
certificates for smart card authentication and health certificates for NAP. For more
information, see Public Key Infrastructure on the Microsoft Web site.

• Without UAG, an optional NAT64 device to provide access to IPv4-only resources for
DirectAccess clients. DirectAccess with UAG provides a built-in NAT64.

10 things you should know about DirectAccess by Debra Littlejohn Shinder

DirectAccess is promising to take remote access to a new level. Here’s a look at what it offers and how it works.
DirectAccess is a new remote access technology that’s available with the combination of Windows Server 2008 R2 and Windows 7 Enterprise or Ultimate editions. DirectAccess promises to revolutionize the entire remote access experience so that employees can be productive from anywhere at any time, without the constraints of traditional remote access technologies, such as network-level VPNs, SSL VPN gateways, and reverse proxies. It provides a seamless experience for users and advanced management capabilities for IT. DirectAccess enables access from anywhere, even when the DirectAccess client system is behind a restrictive firewall.
Note: This article is also available as a PDF download.

1: You can extend your corporate network to any Internet-connected client

The goal of DirectAccess is to extend your corporate network’s reach to any DirectAccess client computer that’s connected to the Internet. A DirectAccess computer is a domain member, a managed computer that is subject to the same change management and control mechanisms as computers that never leave the physical boundaries of the corporate network. In addition to extending IT’s control over all managed computers, regardless of location, DirectAccess provides a seamless network access experience for users. They don’t have to remember one name for when they are on the corpnet and another name when they’re off the corpnet; that’s because they’re always on the corpnet.
When a DirectAccess client computer starts, it establishes the “infrastructure” tunnel. This tunnel allows the DirectAccess client computer to connect to management and domain resources, such as domain controllers, DNS servers, and management servers. This tunnel is also bidirectional, so IT can initiate “manage out” connections to the DirectAccess clients on the Internet, in the same way they can when connecting to hosts on the intranet.
After the user logs on, a second tunnel, called the “intranet tunnel,” enables users to connect to corporate resources in the same way an intranet host connects to those resources. They can use FQDNs or single label names to connect to file servers, Web servers, database servers, mail servers, or any other kind of server, and they never need to reconfigure their applications when they’re off the network. The DirectAccess user is always on the corporate network, regardless of location.

2: You’ll need to meet these DirectAccess requirements

You must meet several requirements before starting a DirectAccess deployment. For starters, you need:

• At least one domain controller running Windows Server 2003 or above.
• An internal PKI to assign machine certificates to DirectAccess clients and the DirectAccess server.
• A private or public PKI to assign Web site certificates to the IP-HTTPS listener and the Network Location Server (discussed later).

And you’ll need to meet these additional requirements:

• The DirectAccess server must be Windows Server 2008 R2 Standard or Enterprise or higher.
• IPv6 must be enabled, and IPv6 transition technologies must also not be disabled.
• DirectAccess clients must run Windows 7 Enterprise or Ultimate edition.
• DirectAccess clients must be members of an Active Directory domain.
• A highly available Network Location Server (Web server) must be on the corpnet.
• If there are firewalls in front of or behind the DirectAccess server, packet filters must be enabled to allow the required traffic.
• The DirectAccess server must have two network interface adapters.

3: IPv6 is the cornerstone of DirectAccess communications

The DirectAccess client always uses IPv6 to communicate with the DirectAccess server. The DirectAccess server will then forward these connections to IPv6-enabled hosts on the corpnet. The corpnet can use native IPv6 infrastructure (where the routers, switches, operating systems, and applications are all IPv6 capable) or it can use IPv6 transition technologies to connect to IPv6 resources on the corpnet.
The DirectAccess server can use ISATAP (Intra-site Automatic Tunnel Addressing Protocol) to tunnel IPv6 packets inside IPv4 headers, which can then take advantage of your IPv4 routing infrastructure to move IPv6 packets throughout your network. DirectAccess clients connected to the IPv4 Internet can use a number of IPv6 transition technologies to connect to the DirectAccess server, including 6to4, Teredo, and IP-HTTPS.

4: IPSec secures communications from end to edge and end to end

Since corpnet communications between the DirectAccess client and server are moving over a public Internet, it’s important that the communications be secured from interception and tampering. DirectAccess uses IPsec to secure the communications between the DirectAccess client and server. IPsec tunnel mode is used to establish both the infrastructure and intranet tunnels. In addition, you can configure DirectAccess to require end-to-end encryption between the DirectAccess client and destination server on the corpnet to use IPsec transport mode, so that the connection is encrypted from the client to its destination. DirectAccess also takes advantage of the new AuthIP feature that was initially introduced with Vista and Windows Server 2008, so that connections can be authenticated via user or computer credentials instead of just computer certificates.

5: Client applications must be IPv6 aware

While the goal is to provide a computing experience that is the same as the corpnet-connected client, there is one major difference between the corpnet client and the DirectAccess client: The DirectAccess client must use and always uses IPv6 to connect to the DirectAccess server. That means that the client application on the DirectAccess client must be IPv6 aware. If the client application is not IPv6 aware (for example, the current OCS client), the connection will fail. This is true even if you use an IPv6 to IPv4 translator, which enables DirectAccess clients to connect to IPv4 servers on the corpnet.

6: Active Directory and Group Policy make it work

A number of configuration changes are made to the DirectAccess server and DirectAccess client to make the solution work. To make these changes in the most efficient manner, the DirectAccess solution takes advantage of Active Directory and Active Directory Group Policy objects. The GPO is assigned to the DirectAccess server and DirectAccess clients. In addition, Active Directory is required for authentication. The infrastructure tunnel uses NTLMv2 authentication for the computer account connecting to the DirectAccess server, and that computer account must be part of an Active Directory domain. The intranet tunnel uses Kerberos authentication for the logged-on user to create the second tunnel.
Although Active Directory and GPOs are required, the DirectAccess server does not need to be a member of the resource domain. As long as there is a two-way trust between the DirectAccess server domain and the resource domains/forests, the solution will work.

7: Network Location Servers let DirectAccess clients know when they’re on the corpnet

DirectAccess is designed to work automatically and in the background. The user should never have to do anything to “turn on” the DirectAccess connection. All the user needs to do is turn on the computer. In fact, the user doesn’t even need to log on! Before the user logs on, the infrastructure tunnel is automatically established, and the DirectAccess client’s agents can connect to their management servers to obtain updates, desired configuration information, security configuration settings, and anything else that IT needs to do to make sure that the DirectAccess client remains in compliance with network configuration and security policies.
To make this process transparent, there must be a mechanism where the DirectAccess client components know when to turn themselves off and on. This is where the Network Location Server comes in. The Network Location Server (NLS) is a Web server that allows incoming SSL connections. You can allow anonymous or integrated authentication to the NLS server. When the DirectAccess client connects to the NLS, it knows it’s on the corpnet, and it turns off the DirectAccess client components. If the DirectAccess client can’t contact the NLS server, it knows that it’s off the corpnet, and it automatically turns on the DirectAccess client components to establish the IPsec tunnels to the DirectAccess server over the Internet. The DirectAccess client does do a check on the Certificate Revocation List for the NLS Web server certificate, so the CRL must be available. Otherwise, the connection to the NLS SSL Web site will fail, and the intranet detection process will fail.

8: Certificates, certificates, certificates!

Certificates are used in a number of places in the DirectAccess client/server solution. Places where you’ll see certificates include:

• DirectAccess client computers. Each DirectAccess client needs a computer certificate to establish the IPsec connections to the DirectAccess server. These are used to create the IPsec connections and are also used by IP-HTTPS, where the DirectAccess server will perform a certificate validation of the computer certificate before allowing the IP-HTTPS connection over the Internet. Computer certificates are best assigned using Microsoft Certificate Server and Group Policy based computer certificate auto-enrollment.
• The IP-HTTPS listener on the DirectAccess Server. IP-HTTPS is an IPv6 transition technology used to tunnel IPv6 packets over the IPv4 Internet. This protocol was designed by Microsoft to enable the DirectAccess client to connect to the DirectAccess server, even if the DirectAccess client is located behind a firewall that allows only outbound HTTP/HTTPS connections or it’s behind a Web proxy server. The IP-HTTPS listener requires a Web site certificate, and the DirectAccess client must be able to contact the server hosting the CRL for the certificate. If the CRL check fails, the IP-HTTPS connection will fail. Commercial certificates are best for the IP-HTTPS listener, since their CRLs are globally available.
• DirectAccess servers. The DirectAccess server hosts the IP-HTTPS Web site certificate, but it also requires a computer certificate to establish the IPsec connections with the DirectAccess clients.

9: Name Resolution Policy Table provides policy-based DNS queries

The DirectAccess client uses the Name Resolution Policy Table (NRPT) to determine which DNS server to use to resolve names. When the DirectAccess client is on the corpnet, the NRPT is turned off. When the DirectAccess client detects that it is on the Internet, the DirectAccess client turns on the NRPT and checks its entries to see which DNS server it should use to connect to a resource. You put your internal domain names and possible servers on the NRPT and configure it to use an internal DNS server to resolve names.
When the DirectAccess client on the Internet needs to connect to a resource using a FQDN, it checks the NRPT. If the name is on it, the query is sent to an intranet DNS server. If the name is not on the NRPT, the DirectAccess client sends the query to the DNS server configured on its NIC, which is an Internet DNS server. The name of the NLS server is also placed on the NRPT, but it’s included as an exemption — meaning that the DirectAccess client should never use an intranet server to resolve the name of the NLS server. So the DirectAccess client on the Internet will never be able to resolve the name of the NLS server and thus will know that it is on the Internet and will turn on its DirectAccess client components. Even more important, when it connects to the corpnet over the DirectAccess connection, it doesn’t think that it’s connected to the corpnet by resolving the name of the NLS server.

10: DirectAccess enables “manage out” capabilities

As already mentioned, IT can take advantage of the “manage out” capabilities enabled by the infrastructure tunnel to connect to DirectAccess clients on the Internet. However, you will need to configure Firewall Rules in the Windows Firewall with Advanced Security (WFAS) to allow these connections for Teredo clients. When you create these rules, make sure that they have Edge Traversal turned on for the Firewall Rule. DirectAccess clients are Teredo clients when they are located behind a NAT device to connect to the Internet and the DirectAccess server, and the NAT device allows UDP port 3544 outbound.

Common Types of Network Attacks    

Without security measures and controls in place, your data might be subjected to an attack. Some attacks are passive, meaning information is monitored; others are active, meaning the information is altered with intent to corrupt or destroy the data or the network itself.

Your networks and data are vulnerable to any of the following types of attacks if you do not have a security plan in place.

Eavesdropping

In general, the majority of network communications occur in an unsecured or "cleartext" format, which allows an attacker who has gained access to data paths in your network to "listen in" or interpret (read) the traffic. When an attacker is eavesdropping on your communications, it is referred to as sniffing or snooping. The ability of an eavesdropper to monitor the network is generally the biggest security problem that administrators face in an enterprise. Without strong encryption services that are based on cryptography, your data can be read by others as it traverses the network.

  Data Modification

After an attacker has read your data, the next logical step is to alter it. An attacker can modify the data in the packet without the knowledge of the sender or receiver. Even if you do not require confidentiality for all communications, you do not want any of your messages to be modified in transit. For example, if you are exchanging purchase requisitions, you do not want the items, amounts, or billing information to be modified.

  Identity Spoofing (IP Address Spoofing)

Most networks and operating systems use the IP address of a computer to identify a valid entity. In certain cases, it is possible for an IP address to be falsely assumed— identity spoofing. An attacker might also use special programs to construct IP packets that appear to originate from valid addresses inside the corporate intranet.

After gaining access to the network with a valid IP address, the attacker can modify, reroute, or delete your data. The attacker can also conduct other types of attacks, as described in the following sections.  

Password-Based Attacks

A common denominator of most operating system and network security plans is password-based access control. This means your access rights to a computer and network resources are determined by who you are, that is, your user name and your password.

Older applications do not always protect identity information as it is passed through the network for validation. This might allow an eavesdropper to gain access to the network by posing as a valid user.

When an attacker finds a valid user account, the attacker has the same rights as the real user. Therefore, if the user has administrator-level rights, the attacker also can create accounts for subsequent access at a later time.

After gaining access to your network with a valid account, an attacker can do any of the following:

• Obtain lists of valid user and computer names and network information.
  
• Modify server and network configurations, including access controls and routing tables.
  
• Modify, reroute, or delete your data.
  

Denial-of-Service Attack

Unlike a password-based attack, the denial-of-service attack prevents normal use of your computer or network by valid users.

After gaining access to your network, the attacker can do any of the following:

• Randomize the attention of your internal Information Systems staff so that they do not see the intrusion immediately, which allows the attacker to make more attacks during the diversion.
  
• Send invalid data to applications or network services, which causes abnormal termination or behavior of the applications or services.
  
• Flood a computer or the entire network with traffic until a shutdown occurs because of the overload.
  
• Block traffic, which results in a loss of access to network resources by authorized users.

   

Man-in-the-Middle Attack

As the name indicates, a man-in-the-middle attack occurs when someone between you and the person with whom you are communicating is actively monitoring, capturing, and controlling your communication transparently. For example, the attacker can re-route a data exchange. When computers are communicating at low levels of the network layer, the computers might not be able to determine with whom they are exchanging data.

Man-in-the-middle attacks are like someone assuming your identity in order to read your message. The person on the other end might believe it is you because the attacker might be actively replying as you to keep the exchange going and gain more information. This attack is capable of the same damage as an application-layer attack, described later in this section.

 

Compromised-Key Attack

A key is a secret code or number necessary to interpret secured information. Although obtaining a key is a difficult and resource-intensive process for an attacker, it is possible. After an attacker obtains a key, that key is referred to as a compromised key.

An attacker uses the compromised key to gain access to a secured communication without the sender or receiver being aware of the attack.With the compromised key, the attacker can decrypt or modify data, and try to use the compromised key to compute additional keys, which might allow the attacker access to other secured communications.

 Sniffer Attack

A sniffer is an application or device that can read, monitor, and capture network data exchanges and read network packets. If the packets are not encrypted, a sniffer provides a full view of the data inside the packet. Even encapsulated (tunneled) packets can be broken open and read unless they are encrypted and the attacker does not have access to the key.

Using a sniffer, an attacker can do any of the following:

• Analyze your network and gain information to eventually cause your network to crash or to become corrupted.
  
• Read your communications.
  

  Application-Layer Attack

An application-layer attack targets application servers by deliberately causing a fault in a server's operating system or applications. This results in the attacker gaining the ability to bypass normal access controls. The attacker takes advantage of this situation, gaining control of your application, system, or network, and can do any of the following:

• Read, add, delete, or modify your data or operating system.
  
• Introduce a virus program that uses your computers and software applications to copy viruses throughout your network.
  
• Introduce a sniffer program to analyze your network and gain information that can eventually be used to crash or to corrupt your systems and network.
  
• Abnormally terminate your data applications or operating systems.
  
• Disable other security controls to enable future attacks.

Understanding Digital Certificates

To verify the identity of people and organizations on the Web and to ensure content integrity, Internet Explorer uses industry-standard X.509 v3 digital certificates. Certificates are electronic credentials that bind the identity of the certificate owner to a pair (public and private) of electronic keys that can be used to encrypt and sign information digitally. These electronic credentials assure that the keys actually belong to the person or organization specified. Messages can be encrypted with either the public or the private key and then decrypted with the other key.
Each certificate contains at least the following information:

• Owner's public key
• Owner's name or alias
• Expiration date of the certificate
• Serial number of the certificate
• Name of the organization that issued the certificate
• Digital signature of the organization that issued the certificate

Certificates can also contain other user-supplied information, including a postal address, an e-mail address, and basic registration information, such as the country or region, postal code, age, and gender of the user.
Certificates form the basis for secure communication and client and server authentication on the Web. You can use certificates to do the following:

• Verify the identity of clients and servers on the Web.
• Encrypt channels to provide secure communication between clients and servers.
• Encrypt messages for secure Internet e-mail communication.
• Verify the sender's identity for Internet e-mail messages.
• Put your digital signature on executable code that users can download from the Web.
• Verify the source and integrity of signed executable code that users can download from the Web.
• For more details visit MS technet web site

What Is TLS/SSL ?

One problem when you administer a network is securing data that is being sent between applications across an untrusted network. You can use TLS/SSL to authenticate servers and clients and then use it to encrypt messages between the authenticated parties.
The Transport Layer Security (TLS) protocol, Secure Sockets Layer (SSL) protocol, versions 2.0 and 3.0, and the Private Communications Transport (PCT) protocol are based on public key cryptography. The Security Channel (Schannel) authentication protocol suite provides these protocols. All Schannel protocols use a client/server model.
In the authentication process, a TLS/SSL client sends a message to a TLS/SSL server, and the server responds with the information that the server needs to authenticate itself. The client and server perform an additional exchange of session keys, and the authentication dialog ends. When authentication is completed, SSL-secured communication can begin between the server and the client using the symmetric encryption keys that are established during the authentication process.
For servers to authenticate to clients, TLS/SSL does not require server keys to be stored on domain controllers or in a database, such as the Microsoft Active Directory directory service. Clients confirm the validity of a server’s credentials with a trusted root certification authority’s (CA’s) certificates, which are loaded when you install Microsoft Windows Server 2003. Therefore, unless user authentication is required by the server, users do not need to establish accounts before they create a secure connection with a server.

History and Standards for TLS and SSL

SSL was developed by Netscape Communications Corporation in 1994 to secure transactions over the World Wide Web. Soon after, the Internet Engineering Task Force (IETF) began work to develop a standard protocol that provided the same functionality. They used SSL 3.0 as the basis for that work, which became the TLS protocol. The implementation of the TLS protocol in Windows Server 2003 closely follows the specification defined in Request for Comments (RFC) 2246, The TLS Protocol Version 1.0. For more information about TLS, see RFC 2246 in the IETF RFC database.
TLS and SSL are most widely recognized as the protocols that provide secure HTTP (HTTPS) for Internet transactions between Web browsers and Web servers. TLS/SSL can also be used for other application level protocols, such as File Transfer Protocol (FTP), Lightweight Directory Access Protocol (LDAP), and Simple Mail Transfer Protocol (SMTP). TLS/SSL enables server authentication, client authentication, data encryption, and data integrity over networks such as the World Wide Web.

Differences between TLS and SSL

Although there are some slight differences between SSL 3.0 and TLS 1.0, this reference refers to the protocol as TLS/SSL.

Note

• Although their differences are minor, TLS 1.0 and SSL 3.0 are not interchangeable. If the same protocol is not supported by both parties, the parties must negotiate a common protocol to communicate successfully.

TLS Enhancements to SSL

• The keyed-Hashing for Message Authentication Code (HMAC) algorithm replaces the SSL Message Authentication Code (MAC) algorithm.
  
  HMAC produces more secure hashes than the MAC algorithm. The HMAC produces an integrity check value as the MAC does, but with a hash function construction that makes the hash much harder to break. For more information about the HMAC, see “Hash Algorithms in The Handshake Layer in TLS/SSL Architecture” in How TLS/SSL Works.
  
• TLS is standardized in RFC 2246.
  
• Many new alert messages are added.
  
• In TLS, it is not always necessary to include certificates all the way back to the root CA. You can use an intermediary authority.
  
• TLS specifies padding block values that are used with block cipher algorithms. RC4, which is used by Microsoft, is a streaming cipher, so this modification is not relevant.
  
• Fortezza algorithms are not included in the TLS RFC, because they are not open for public review. (This is Internet Engineering Task Force (IETF) policy.)
  
• Minor differences exist in some message fields.

Benefits of TLS/SSL

TLS/SSL provides numerous benefits to clients and servers over other methods of authentication, including:

• Strong authentication, message privacy, and integrity
  
• Interoperability
  
• Algorithm flexibility
  
• Ease of deployment
  
• Ease of use

Strong authentication, message privacy, and integrity

TLS/SSL can help to secure transmitted data using encryption. TLS/SSL also authenticates servers and, optionally, authenticates clients to prove the identities of parties engaged in secure communication. It also provides data integrity through an integrity check value. In addition to protecting against data disclosure, the TLS/SSL security protocol can be used to help protect against masquerade attacks, man-in-the-middle or bucket brigade attacks, rollback attacks, and replay attacks.

Interoperability

TLS/SSL works with most Web browsers, including Microsoft Internet Explorer and Netscape Navigator, and on most operating systems and Web servers, including the Microsoft Windows operating system, UNIX, Novell, Apache (version 1.3 and later), Netscape Enterprise Server, and Sun Solaris. It is often integrated in news readers, LDAP servers, and a variety of other applications.

Algorithm flexibility

TLS/SSL provides options for the authentication mechanisms, encryption algorithms, and hashing algorithms that are used during the secure session.
Note

• Data can be encrypted and decrypted, but you cannot reverse engineer a hash. Hashing is a one-way process. Running the process backward will not create the original data. This is why a new hash is computed and then compared to the sent hash.

Ease of deployment

Many applications use TLS/SSL transparently on a Windows Server 2003 operating system. You can use TLS for more secure browsing when you are using Internet Explorer and Internet Information Services (IIS) and, if the server already has a server certificate installed, you only have to select the check box.

Ease of use

Because you implement TLS/SSL beneath the application layer, most of its operations are completely invisible to the client. This allows the client to have little or no knowledge of the security of communications and still be protected from attackers.

Limitations of TLS/SSL

There are a few limitations to using TLS/SSL, including:

Increased processor load

This is the most significant limitation to implementing TLS/SSL. Cryptography, specifically public key operations, is CPU-intensive. As a result, performance varies when you are using SSL. Unfortunately, there is no way to know how much performance you will lose. The performance varies, depending on how often connections are established and how long they last. TLS uses the greatest resources while it is setting up connections.

Administrative overhead

A TLS/SSL environment is complex and requires maintenance; the system administrator must configure the system and manage certificates.

Common TLS/SSL Scenarios

Many people think of TLS and SSL as protocols that are used with Web browsers to browse the Internet more securely. However, they are also general purpose protocols that can be used whenever authentication and data protection are necessary. For example, you can use TLS/SSL for:

• SSL-secured transactions with an e-commerce Web site
  
• Authenticated client access to an SSL-secured Web site
  
• Remote access
  
• SQL access
  
• E-mail

This is not an exhaustive list. In fact, the ability to access these protocols through Security Service Provider Interface (SSPI) means that you can use them for just about any application. Many applications are being modified to take advantage of the features of TLS/SSL.

SSL-secured transactions with an e-commerce Web site

This situation is a typical use of SSL between a browser and a Web server. An example is an e-commerce shopping site where clients need to provide their credit card numbers. The protocol first confirms that the certificate of the Web site is valid, and then sends the client’s credit card information as cipher text. For this type of transaction, where the server’s certificate comes from a trusted source, authentication only occurs for the server. TLS/SSL must be enabled for the Web page, such as an order form, where the data transactions occur.

Authenticated client access to an SSL-secured Web site

Both the client and server need certificates from a mutually-trusted certification authority (CA). With Schannel, client certificates can be mapped on a one-to-one or many-to-one basis to their Windows Server 2003 user or computer accounts, and they can be managed by Active Directory Users and Computers. Users can then be authenticated to a Web site without needing to supply a password.
Many-to-one mapping has several uses. For example, if you want to give several users access to confidential material, you can create a group, map the users’ certificates to the group, and give the group the necessary permissions to the material.
In one-to-one mapping, the server has a copy of the client’s certificate; whenever the client logs in; the server verifies that they are identical. This one-to-one mapping is typically used for private material, such as a banking Web site where only one individual has the right to view a personal account.

Remote access

In this situation, telecommuting is a common use for Schannel. You can use this technology to provide authentication and data protection when users remotely log in to Windows-based systems or networks. Users can more securely access their e-mail or enterprise applications from home or while traveling, reducing the risk of exposure of the information to anyone on the Internet.

SQL access

With Microsoft SQL Server, you can require authentication of the client when connecting to the server running SQL Server. Either the client or server can be configured to require encryption of the data that is transferred between them. Very sensitive information, such as financial or medical databases, can be protected to prevent unauthorized access and disclosure of information about the network.

E-mail

When using Exchange servers, you can use Schannel to help protect data as it moves from server to server on the intranet or Internet. Full end-to-end security might require the use of Secure/Multipurpose Internet Mail Extensions (S/MIME); however, helping to protect data in a server-to-server exchange allows companies to use the Internet to securely transfer e-mail among divisions within the same company, subsidiaries, and partners. This can be done regardless of whether S/MIME is used.

What Is IPSec?

Internet Protocol security (IPSec) is a framework of open standards for helping to ensure private, secure communications over Internet Protocol (IP) networks through the use of cryptographic security services. IPSec supports network-level data integrity, data confidentiality, data origin authentication, and replay protection. Because IPSec is integrated at the Internet layer (layer 3), it provides security for almost all protocols in the TCP/IP suite, and because IPSec is applied transparently to applications, there is no need to configure separate security for each application that uses TCP/IP.
IPSec helps provide defense-in-depth against:

• Network-based attacks from untrusted computers, attacks that can result in the denial-of-service of applications, services, or the network
  
• Data corruption
  
• Data theft
  
• User-credential theft
  
• Administrative control of servers, other computers, and the network.
  

You can use IPSec to defend against network-based attacks through a combination of host-based IPSec packet filtering and the enforcement of trusted communications.
IPSec is integrated with the Windows Server 2003 operating system and it can use the Active Directory directory service as a trust model. You can use Group Policy to configure Active Directory domains, sites, and organizational units (OUs), and then assign IPSec policies as required to Group Policy objects (GPOs). In this way, IPSec policies can be implemented to meet the security requirements of many different types of organizations

From: Microsoft Technet Technical Documents

What is the PKI and its technologies ?

PKI Technologies

Organizations need enhanced security for data and strong credentials for identity management. You can use certificates to secure data and manage identification credentials from users and computers both within and outside your organization.
A public key infrastructure (PKI) is the combination of software, encryption technologies, processes, and services that enable an organization to secure its communications and business transactions. The ability of a PKI to secure communications and business transactions is based on the exchange of digital certificates between authenticated users and trusted resources.
You can design a PKI solution to meet the following security and technical requirements of your organization:

• Confidentiality. You use a PKI to encrypt data that is stored or transmitted.
  
• Integrity. You use a PKI to digitally sign data. A digital signature helps you identify whether another user or process modified the data.
  
• Authenticity. A PKI provides several authenticity mechanisms. Authentication data passes through hash algorithms, such as Shivest Hash Algorithm 1 (SHA1), to produce a message digest. The message digest is then digitally signed by using the sender’s private key to prove that the message digest was produced by the sender.
  
• Nonrepudiation. When data is digitally signed, the digital signature provides proof of the integrity of the signed data and proof of the origin of the data. A third party can verify the integrity and origin of the data at any time. This verification cannot be refuted by the owner of the certificate that digitally signed the data.
  

PKI Technologies Architecture

The architecture of a PKI involves implementing various interdependent technologies and processes to make it possible to issue, validate, renew, and revoke certificates. These technologies include:

• One of more servers running Certificate Services and that provide certificate enrollment, revocation and other certificate management services.
  
• Active Directory directory service or another directory service that provides account management, policy distribution, and certificate publication services.
  
• Domain controllers that can authenticate end users and computers when they request certificates.
  
• Domain client computers and users, who request, receive, and use certificates for specific purposes. Although certificates can also be used by services and by non-domain clients, in most Windows PKI environments, domain users and computers are the primary recipients and users of certificates. In some cases, the domain client can be a subordinate CA that requests and receives a certificate authorizing it to issue certificates of its own.

from: Microsoft Technet technical Documents