MCP 70-299 : Deploying andTroubleshooting IPSec

Lesson 1: Deploying IPSec

Deploying IPSec by Using Active Directory :

If your organization has an Active Directory domain, you should almost always use Active Directory to deploy IPSec. The primary tool for building IPSec policies is the graphical user interface provided by the IP Security Policy Management snap-in. You can use the IP Security Policy Management snap-in to create, modify, and activate IPSec policies, and then assign them to a domain, site, or organizational unit (OU) in Active Directory by using the Group Policy Object Editor snap-in.

If you decide to deploy IPSec policies by using GPOs, you must understand how IPSec policies differ from other types of security settings. Most settings in a security template can be combined by importing them into a single GPO. If multiple GPOs with overlapping settings are assigned to a single computer, the computer will automatically resolve any conflicting settings. Because multiple security templates and sets of Group Policy settings can be applied to a single computer, role-based security templates work perfectly when a computer serves multiple roles.

Only one IPSec policy can be applied to any single computer. If multiple GPOs assign multiple IP security policies to a computer, only the GPO with the highest precedence will be applied. IPSec policy uses the same precedence sequence as other Group Policy settings, which is from lowest to highest: Local GPO, site, domain, OU.

Deploying IPSec Using Scripts :

If a computer is not a member of a Windows 2000 domain or a Windows Server 2003 domain, it cannot retrieve IPSec policy from Active Directory. However, as Chapter 8 described, you can use the Netsh, Ipseccmd.exe, and Ipsecpol.exe command-line tools to create IPSec scripts. You can then include these scripts as startup scripts for each computer on your network. You can use Ipsecpol.exe only on computers running Windows 2000, Ipseccmd.exe only on computers running Windows XP, and the Netsh commands for IPSec only on computers running Windows Server 2003.

Although having three separate scripting tools for the three operating systems makes managing a typical network challenging, the three tools are similar in functionality. Although the exact parameters vary, each tool provides separate static and dynamic configuration modes and the ability to display existing IPSec configuration information. For each tool, the dynamic configuration mode changes the currently running IPSec settings, although static configuration mode changes the persistent configuration. In other words, dynamic configuration changes are lost after you restart your computer,but static configuration changes will remain.

Deploying Certificate Services for IPSec :

Although Kerberos is the simplest way to authenticate IPSec peers, certificates provide greater flexibility for authenticating non-Windows IPSec peers and other computers that are not members of an Active Directory domain. In Windows 2000 and Windows Server 2003, you can use Certificate Services to automatically manage computer certificates for IPSec authentication. IPSec also supports the use of a variety of non-Microsoft X.509 public key infrastructure (PKI) systems. Windows Server 2003 IKE has basic compatibility with several certificate systems, including those offered by Microsoft, Entrust, VeriSign, and Netscape. If you are using a non-Microsoft PKI system, the PKI
system must be able to issue certificates to computers and store their certificates in the Windows Cryptographic Application Programming Interface (CryptoAPI) computer certificate store.

IPSec’s use of certificate authentication is compatible with many different PKI architectures, and IKE places relatively few requirements on the contents of a certificate. Typically, computers that have a common trusted root, or whose certificates can chain through a cross-certification trust relationship, can successfully use certificatebased authentication for IPSec. To use certificates for IPSec authentication, you define an ordered list of acceptable root certification authority (CA) names in the
authentication method.

MCP 70-299 : 8 - Planning and Configuring IPSec

Lesson 2: Planning an IPSec Infrastructure

Active Directory Considerations :

For organizations with large numbers of computers that must be managed in a consistent way, it is best to distribute IPSec policies by using Group Policy objects (GPOs). Although you can assign local IPSec policies to computers that are not members of a trusted domain, distributing IPSec policies and managing IPSec policy configuration and trust relationships is much more time-consuming for computers that are not domain members. Another advantage of using Active Directory–based IPSec policy is that you can delegate permissions on the IP Security Policies On Active Directory container to enable specific administrators to manage IPSec throughout your organization.

These administrators do not necessarily need permissions to directly manage the individual computers
that will receive the IPSec policy, however. This capability is vital to organizations that divide responsibility for security tasks between various groups. To delegate permissions on the IP Security Policies container, you must use an Active Directory editing tool, such as ADSI Edit. ADSI Edit is a Windows support tool that uses the Active Directory Service Interfaces (ADSI). The Windows support tools can be installed from the \Support\Tools folder on the Windows 2000 and Windows Server
2003 operating system CDs.

Authentication for IPSec :

Peer authentication is the process of ensuring that an IPSec peer is the computer it claims to be. By using peer authentication, IPSec can determine whether to allow communications with another computer before the communication begins. You can choose from three authentication methods: Kerberos v5, public key certificates, and preshared keys.
If you have deployed a Windows 2000 or Windows Server 2003 Active Directory environment, and all hosts that will be using IPSec are part of that domain (or a member of a trusted domain), then you should use Kerberos. If you are communicating with outside organizations, and your partners use a Web-based CA, you can use public key certificates. If neither of these methods is available, you can use a preshared key.

Public key certificates authentication :

A public key infrastructure (PKI) can be used to authenticate and encrypt communications for a wide variety of applications, including Web applications, e-mail, and IPSec.
Although using public key certificates is not as convenient as using Kerberos, there are specific circumstances for which certificates are the logical choice for authentication in IPSec. Specifically, you should use public key certificates when you need to communicate privately with external business partners or other computers that do not support the Kerberos v5 authentication protocol.
IPSec’s use of certificate authentication is compatible with many different PKI architectures, and IPSec places relatively few requirements on the contents of a certificate. Typically, computers that have a common trusted root, or whose certificates can chain through a cross-certification trust relationship, can successfully use IPSec authentication. To use certificates for IPSec authentication, you define an ordered list of acceptable root CA names in the authentication method. This list controls the certificates that IPSec can select and the certificates that IPSec will select.

Preshared key authentication :

If both IPSec peers are not in the same domain and do not have access to a CA, a preshared key can be used. For example, a standalone computer on a network that does not connect to the Internet might need to use a preshared key, because neither Kerberos authentication through the computer’s domain account nor access to a CA on the Internet is available. A preshared key is a shared secret key (basically a password) that has been agreed upon by administrators who want to secure the computers’ communications by using IPSec. Administrators must manually configure their systems to use the same preshared key.
The preshared key authentication method uses symmetrical encryption to authenticate the hosts, which itself is very secure, but which requires that any two hosts communicating have been configured with a predefined password. Unfortunately, this key is not stored securely on the IPSec hosts. The authentication key is stored in plaintext format in the system registry and hex-encoded in Active Directory–based IPSec policy. If attackers can access your registry, they can find your preshared key, which would allow them to decrypt your traffic or impersonate one of the hosts. Use preshared key authentication only when no stronger method can be used.

Testing IPSec

As a rule, you should perform extensive testing before making any changes to your infrastructure. This rule certainly holds true when planning to use IPSec. IPSec has the potential to interfere with all network communications and, as a result, can break any network applications that your organization uses.
Begin testing IPSec in a lab environment. Configure computers with the client- and server-side of your critical applications, and verify that the lab is functional and accurately simulating the production environment. Your lab environment should have computers with each of the potential IPSec client operating systems, because different operating systems support different IPSec functionality. Develop performance metrics for each of your applications, and gather baseline performance data that you can use for comparison after IPSec has been implemented. Then implement IPSec policies on the lab computers.
Not all network equipment provides the same IPSec capabilities, and you should use the testing phase to determine which network devices need configuration changes or upgrades. Add firewalls, proxy servers, and routers to the lab environment to simulate the potential for those devices to interfere with IPSec communications in the production environment. If you plan to use IPSec for remote access, be sure to include a remote access client in your lab environment, and have that client connect from a typical remote network. If employees will use IPSec to connect to your internal network from home, test IPSec across a variety of commonly used home routing equipment. Test non-IPSec-enabled clients with IPSec-enabled servers. Even if you plan to deploy IPSec to every computer, there will be a transition period during which some computers will not yet have received the IPSec configuration.
After IPSec clients and network equipment have been configured in the lab environment, test the application functionality. If you identify problems, document the problems and solutions so that they can be quickly resolved if they appear in the production environment. Besides verifying that applications function, verify IPSec functionality. If you allow IPSec clients to use unsecured communications if IPSec negotiations fail, it is possible for applications to appear to be compatible with IPSec when the computers were unable to establish an IPSec session.

Module 2 : 70-290

Procédure de création d'un compte d'utilisateur de domaine :


Pour créer un compte d'utilisateur de domaine :

1. Cliquez sur Démarrer, pointez sur Outils d'administration, puis cliquez sur Utilisateurs et ordinateurs Directory.
2. Dans l'arborescence de la console, double-cliquez sur le noeud de domaine.
3. Dans le volet d'informations, cliquez avec le bouton droit sur l'unité d'organisation dans laquelle vous voulez ajouter l'utilisateur, pointez sur Nouveau, puis cliquez sur Utilisateur.
4. Dans la boîte de dialogue Nouvel objet - Utilisateur, tapez le prénom de l'utilisateur dans la zone Prénom.
5. Tapez les initiales de l'utilisateur dans la zone Initiales.
6. Tapez le nom de l'utilisateur dans la zone Nom.
7. Dans la zone Nom d'ouverture de session de l'utilisateur, tapez le nom avec lequel l'utilisateur ouvrira des sessions.
8. Dans la liste déroulante, cliquez sur le suffixe UPN qui doit être ajouté au nom d'ouverture de session de l'utilisateur après l'arobase (@).
9. Cliquez sur Suivant.
10. Dans les zones Mot de passe et Confirmer le mot de passe, tapez le mot de passe de l'utilisateur.
11. Sélectionnez les options de mot de passe appropriées.
12. Cliquez sur Suivant, puis sur Terminer.



Procédure de création d'un compte d'utilisateur local :

Pour créer un compte d'utilisateur local :

1. Cliquez sur Démarrer, pointez sur Outils d'administration, puis cliquez sur Gestion de l'ordinateur.
2. Dans l'arborescence de la console, développez Utilisateurs et groupes locaux, puis cliquez sur Utilisateurs.
3. Dans le menu Action, cliquez sur Nouvel utilisateur.
4. Dans la zone Nom d'utilisateur de la boîte de dialogue Nouvel utilisateur, tapez le nom avec lequel l'utilisateur ouvrira des sessions.
5. Modifiez le nom de manière appropriée.
6. Dans les zones Mot de passe et Confirmer le mot de passe, tapez le mot de passe de l'utilisateur.
7. Sélectionnez les options de mot de passe appropriées.
8. Cliquez sur Créer, puis sur Fermer.


Procédure de création d'un compte d'ordinateur :


Pour créer un compte d'ordinateur, procédez comme suit :

1. Dans l'arborescence de la console Utilisateurs et ordinateurs Active Directory, cliquez avec le bouton droit sur Computers ou sur le conteneur dans lequel vous voulez ajouter l'ordinateur, pointez sur Nouveau, puis cliquez sur Ordinateur.
2. Dans la boîte de dialogue Nouvel objet-Ordinateur, tapez le nom de l'ordinateur dans la zone Nom de l'ordinateur.
3. Sélectionnez les options appropriées, puis cliquez sur Suivant.
4. Dans la boîte de dialogue Prise en charge, cliquez sur Suivant.
5. Cliquez sur Terminer.