Windows 2000 Network Security

The data that will need to be strongly encrypted in Munchkin Land will be that which flows on the WAN from that remote office to headquarters. Because it leaves the communications infrastructure that is owned and controlled by the company, the data is more at risk during transport. The network will be using Windows 2000. Therefore, L2TP can be used as the VPN technology. When used in conjunction with IPSec, L2TP is the most secure tunneling technology available in Windows 2000. ESP is the IPSec mode that encrypts data but does not provide a VPN tunnel for it. Because L2TP is the most desirable technology to use in creating the VPN tunnel, IPSec in tunnel mode is not an acceptable answer.Windows 2000 Help, Search for the articles entitled: Virtual private networks; Remote access VPN design considerations; Remote access VPN security; Remote access for employees; Internet-based VPNs; Remote access VPN connection; Data encryption; Point-to-Point Tunneling Protocol; Layer Two Tunneling Protocol; Network security; How IPSec works; and Understanding Internet Protocol Security.

We know from the background information that the new subsidiary will act as a separate company from Corleon. Separate companies should have their own Forests. In addition, because of the type of business involved, security needs are paramount in the forest design. The strongest security boundary possible is two separate forests.Windows 2000 Help, Search for the articles entitled: Namespace planning for DNS; Explicit domain trusts; Understanding domain trusts; Planning your domain structure; Understanding domain trees and forests; and Planning organizational unit structure.

The following four mandatory parameters are negotiated as part of the first phase of the negotiation process: -- The encryption algorithm (DES, 3DES) -- The hash algorithm (MD5 or SHA) -- The authentication method (Certificate, pre-shared key, Kerberos v5 authentication) -- The Diffie-Hellman (DH) group to be used for the base keying material Before secure data in an IPSec environment can be exchanged, a security association (SA) must be established between the source and target computers. The mechanism for enabling this process is provided through Internet Key Exchange (IKE). To ensure successful, secure communication, IKE performs a two-phase operation. Confidentiality and authentication during each phase is ensured by the use of encryption and authentication algorithms agreed on by the two computers during security negotiations. During the first phase, a secure, authenticated communication channel is created between the two computers. In the second phase, SAs are negotiated on behalf of IPSec. During this phase, there are three elements that must be negotiated before actual secure data may be transmitted: -- The IPSec protocol (AH or ESP) -- The hash algorithm (MD5 or SHA) -- The encryption algorithm (if requested) (DES, 3DES) As you can see, there is a degree of overlap between the requirements of the first and second phase of negotiations.
The following incorrect responses are not associated with the IPSec negotiation process: The IP address is not a negotiated feature, but comes into play when you are configuring IP filters to control the application of your policies. The tunneling modes would apply to phase two of the negotiations. An Encapsulating Security Payload (ESP) tunnel encrypts the encapsulated data. An Authorization Header (AH) tunnel provides authentication and integrity, just like ESP, but not the encryption. You must specify the tunnel endpoint while using the Security Rule Wizard for an IP tunnel to be activated. Both computers must be configured for tunneling if there is to be an IP tunnel. Automatic Security Negotiation Internet Key Exchange (IKE) services dynamically negotiate a mutual set of security requirements between communicating computers, eliminating the need for both computers to have identical policies.

SSL is a standard technology that is used to encrypt information as it is transferred between a web browser and a website. It is the logical choice to use in this situation because it requires no education on the part of the user. All of the other solutions mentioned such as PPTP and L2TP would require specific operating systems and user configuration. We also know from the scenario that the company wants to use a PKI infrastructure and wishes to give each broker a certificate. These certificates will be used to authenticate brokers when they visit the website. Because the company uses Active Directory, each certificate must correspond to a user account. This is called a Directory Service mapping. Once mapped, the account and any groups it is a member of can be used to control what the broker can and cannot see on the site. It can also be used to audit their access to the site and its information.Windows 2000 Help, Search for the article entitled: Secure Socket Layer/Transport Layer Security (SSL/TLS) authentication.IIS 5.0 Documentation, Search for the articles entitled: Mapping Client Certificates to User Accounts; and About Certificates.

Windows 2000 supports four types of built-in security groups, differentiated by scope. Those groups are: -- Domain Local Groups. These groups are typically used to assign permissions to specific resources, such as printers and file systems. -- Global Groups. These groups are used to logically organize users by function or resource access needs. The preferred method to grant user access is assign global groups to the appropriate local groups that define the access. In Windows 2000, you can nest global groups to make administration simpler. -- Universal Groups. These groups are used in larger, multi-domain environments where you have users in different domains requiring similar levels of access to resources. The normal technique is to place global groups into universal groups, then add the universal group to the local group. Note: A single domain model does not support universal groups. -- Computer Local Group. This group exists for access control that is specific to one computer that is not recognized elsewhere in the domain.
In Mbutu's situation, the correct approach would be to create Domain local groups, and add the global groups. Although you can add a global group to a domain local group, you cannot add a domain local group to a global group. Trusts are created between domains, not within a single domain. Also, granting access permissions to only the Users, Power Users and Administrators groups would not give you granular enough control over domain resources.

n this case, the endpoint computers are in the same network. The appropriate strategy would be to employ IPSec policies. IPSec allows you to secure communications within the same network. To provide encryption services, use Encapsulating Security Payload (ESP). This will provide the transmitted data with authentication, integrity, and confidentiality. The Authentication Header (AH) protocol provides authentication and integrity, but not encryption, so it would not be sufficient for our scenario. A virtual private network (VPN) is the extension of a private network that incorporates links across shared or public networks like the Internet. Virtual Private Networking (VPN) is designed to connect remote clients to a private network or connect together two private networks. Since our computers are on the same network, a VPN is not indicated.

To address the issue of secure data transmission, Heather should use virtual private networking (VPN) features. By encrypting the payload, she ensures that, even if a malicious network user intercepts the transmission, the data integrity and confidentiality is assured. Creating a VPN tunnel indicates that data encryption features are enabled. For the laptop theft issue, Heather should use Encrypting File System (EFS) features on the laptop computers. This is a technology that encrypts data on Windows 2000 NTFS-configured computers. Now, even if a laptop does get stolen, the data on that laptop will remain confidential. For safety, EFS will not function if a recovery agent is not designated. This protects the administrator from the disgruntled sales representative who decides to encrypt files before exiting the building. Distributed File System (DFS) is a technology that takes parts of multiple file systems, and integrates them into a single hierarchical structure. This is primarily an ease of use issue, and does not provide encryption services as dictated by our scenario. Configuring Routing and Remote Access Service (RRAS) with callback security allows the administrator to regulate access to the dial-in server. This is a good thing to do, but does not address the issues of securing the communication channel the way a VPN does.

TCP/IP filters can be set in Routing and Remote Access (RRAS). There are two types of filters Input and Output. Input filters are applied to incoming traffic and output filters are applied to traffic that is leaving the router. Filters can be applied to block all traffic except for what is specified in the filter, or allow all traffic except what is specified in the filter.In this case, the filters should be applied to incoming traffic on the public interface of the VPN server. This is because any malicious traffic will be coming from the public network, into the VPN server. By filtering this incoming traffic carefully a stronger level of network security can be achieved.Windows 2000 Help, Search for the articles entitled: Packet filtering; To add a packet filter; Virtual private networks; Remote access VPN design considerations; Remote access VPN security; Remote access for employees; Internet-based VPNs; Remote access VPN connection; Data encryption; Point-to-Point Tunneling Protocol; Layer Two Tunneling Protocol; Network security; How IPSec works; and Understanding Internet Protocol Security.

You can use Encrypting File System (EFS) to encrypt NTFS files to provide confidentiality for the file contents. EFS uses symmetric key encryption in conjunction with public key technology to protect the file and ensure that only the owner of the file can access the file. A virtual private network (VPN) enables you to send data between two computers across a shared or public internetwork in a way that emulates a point-to-point private link. To ensure confidentiality of the data, it is encrypted by the sender and decrypted by the receiver. Point-to-Point Tunneling Protocol (PPTP) takes the existing Point-to-Point Protocol (PPP) frames, encapsulates them into an IP datagram, and provides encryption services. The Secure Sockets Layer (SSL) protocol provides communications privacy, authentication, and message integrity by using a combination of public-key and symmetric encryption. By using this protocol, clients and servers can communicate in a way that prevents eavesdropping, tampering, or message forgery.
In the case of an SSL connection between a Web browser and Web server, you must enter HTTPS rather than HTTP as the protocol type in the URL. This will instruct the Web browser to use a different port for the communication; the Web server will be listening on this port for SSL requests. By default, Web data (HTTP) uses Transmission Control Protocol (TCP) port 80, while SSL (HTTPS) uses TCP port 443. In this scenario, Juliette needs to configure EFS, PPTP, and SSL. Microsoft Point-to-Point Encryption (MPPE) is the encryption method used by PPTP. By itself, MPPE does not satisfy the requirement for secure communications. The Point-to-Point Protocol (PPP) is an industry standard method of utilizing point-to-point links to transport multi-protocol datagrams. PPP is normally used over dial-up modem connections. It does not provide the encryption capabilities required by our scenario. NT File System (NTFS) is required for EFS to work, but does not provide the required data encryption services by itself. HTTPS is the protocol you use with an SSL-enabled connection. You do not configure the browser specifically to support HTTPS, you configure the browser to enable SSL, which allows you to use the HTTPS protocol for secure Web site access.

There are two dial-up scenarios Jorge might consider in this case: RRAS and VPN. Routing Remote Access Service (RRAS) provides the ability to handle incoming calls from clients without the overhead of a Virtual Private Networking (VPN) connection. Security and encryption were not specified in our requirements, so a VPN is not indicated. There are two ways for our dial-in clients to authenticate: Windows 2000 authentication and RADIUS authentication. Since we have provided network server access to users outside our network, RADIUS is the better choice. The RADIUS server has access to user account information and can check remote access authentication credentials. If the user’s credentials are authentic and the connection attempt is authorized, the RADIUS server authorizes the user’s access based on specified conditions and logs the remote access connections as accounting events. Remote access policies provide a more powerful and flexible way to manage remote access permission.
An example is support for callback functionality. By establishing a remote access policy that expects a client to be at a certain phone number, you can guard against that type of unauthorized access attempt. In small network situations with no requirements for centralized management of remote access, the Routing and Remote Access service can be configured to use Windows authentication. However, in situations like ours, greater control and flexibility are achieved through centralized authentication using RADIUS.

When a dial-up client calls the ISP, a default route is added allowing the client to access all Internet addresses through the ISP. However, when a VPN is established, a new default route is added, pointing to the VPN server, only allowing access to the IP address of the VPN server. The original route is retained, but assigned a higher metric, rendering it unavailable. For most Internet VPN clients, this is not a problem because they are either engaged in Internet communications or intranet communications, but not both. If the user needs Internet access while the VPN connection is active, there are a couple of things the administrator must do. In all cases, configure the VPN connection NOT to create a default gateway. This leaves the default route to the ISP intact, allowing Internet access. Accomplish this by clearing the ' Use default gateway on remote network' check box in the Advanced TCP/IP Settings dialog box.
The next thing you must do depends on the network addressing scheme in use on your company's intranet. In our scenario, we are using addresses in the 172.16.0.0 range. This is a reserved private address, and is not used to assign Internet addresses. Therefore, you would add static persistent routes for the private network IDs of the intranet using the IP address of the VPN server’s virtual interface as the gateway IP address. Static routes can be added using the 'ROUTE' utility. For each route, type the following route utility syntax at a Windows 2000 command prompt: ROUTE ADD MASK.p Since we are not using RIP, we have no way of dynamically adding intranet routes.

Due to the requirement for all Operations servers to communicate securely at all times, the Secure Server (Require Security) IPSec policy should be implemented. Placing the high security servers into a separate OU allows for ease of administration, as well as enhanced security. By applying this IPSec policy to the Ops_SVR OU, all servers in the OU are affected. To ensure that client computers are properly configured to respond securely if attempting communications with Operations department servers, employ the Client (Respond Only) IPSec policy at the domain level. The policy will propagate down through the Active Directory structure to all client computers in all subordinate OUs. In this way, if changes are made to the AD structure (like adding a new OU), the security policy would not be affected.
Applying the Secure Server (Require Security) policy to the Marketing, Sales, Operations, Production, and Administration OUs would have the unfortunate effect of requiring secure communications for servers that do not need it, and not requiring them for servers that do.
Applying the Client (Respond Only) policy to those same OUs would work, but applying this policy at the domain level is better for reasons stated earlier. The Server (Request Security) IPSec policy is not strict enough. In our scenario, all communications from Operations servers must be secure. With this policy, the server can fall back to non-secure if the client cannot respond securely.

The method for providing secure internal communications with 3DES encryption is IPSec. A well-implemented public key infrastructure, in which security credentials can be presented without compromising those credentials in the process, resolves many security problems. IPSec works with your public key infrastructure to allow certificate-based authentication of computers. This is, in fact, the default authentication scheme for IPSec communications. There are two "flavors" of IPSec -- plain and encrypted. The Authentication Header protocol (AH) provides integrity and authentication, but not encryption. Encapsulating Security Payload (ESP) adds the encryption element. An alternate, and not generally recommended, involves using a pre-shared key. Pre-shared means there must be agreement on a shared, secret key that becomes part of the IPSec policy.
During security negotiation, information is encrypted before transmission using the shared key, and decrypted on the other end using the same key. If the receiver can decrypt the information, authentication is successful. The problem is that the authentication key is stored, unprotected, in the IPSec policy. This mode can be useful for troubleshooting, but it is really provided to ensure interoperability. As before, the ESP protocol is required. Kerberos authentication is not supported by IPSec.

Once you have placed your users into the appropriate groups to allow access to supported applications, you can further define security settings by applying security templates. Windows 2000 provides a collection of security templates for setting up your network security environment. Security templates can be imported into the Security Configuration and Analysis or the Group Policy snap-in modules of the Microsoft Management Console. Templates may be edited in the Security Templates snap-in, but they may not be imported. Security templates are inactive until they are imported into the Security Configuration and Analysis snap-in or the Group Policy snap-in.
There are four classes of security templates, which provide varying levels of security. These classes are Basic, Compatible, Secure, and High Secure. Within these classes are templates specifically designed for domain controllers, and templates for other computers. Note the usage of "ws" and "dc" in the filenames: "dc" indicates a template designed for use on a domain controller, and "ws" for other computers. The Basic template (which was not one of our potential answers) contains the default settings that Windows 2000 incorporates during a clean install. This template is normally used when upgrading from Windows NT 4.0 to ensure the settings are consistent. The Compatible template is designed for those situations where you have legacy applications, and you want your users to be able to run them without making your users Power Users. Be aware that a computer that incorporates this template, compatws.inf, is not considered secure. This would not work for our situation.
The Secure template modifies certain settings that would not have an impact on application functionality, but more of an impact on operating system and network behavior. For example, this template incorporates settings that enable digital signing of communications, but does not require it. The securews.inf template would not apply in our scenario. The High Secure template takes some of the settings from the Secure template, and applies their extreme values to favor security over performance, ease of use, or connectivity. With this template, digital signing of communications is mandated, and unsigned device drivers are blocked. The template file hisecws.inf is the appropriate choice for us. Hisecdc.inf is designed for domain controllers.

In Cornelius's case, server data is so sensitive that the department’s network segment is physically disconnected from the rest of the intranet. While this protects the server's data, it creates accessibility problems for those users not physically connected to the separate network segment. VPN connections allow a network segment to be physically connected to the intranet but separated by a VPN server. The VPN server does not provide a direct routed connection between the corporate intranet and the separate network segment. Authorized intranet users can establish a VPN connection with the VPN server and can gain access to the sensitive resource. Additionally, all communication across the VPN connection is encrypted for data confidentiality. For those users who do not have permissions to establish a VPN connection, the separate network segment remains hidden.
L2TP is a tunneling protocol that a VPN uses to provide the encryption services. Oddly enough, L2TP uses Internet Protocol Security (IPSec) to provide the actual encryption using Encapsulated Security Payload (ESP). However, IPSec with ESP by itself does not meet the requirements of our scenario. IPSec with AH provides authentication and integrity, but not encryption. Either way, IPSec by itself is not appropriate, given the network infrastructure. Routing Remote Access Service (RRAS) is a dial-up solution. Technically, nothing is stopping you from putting a RRAS server on the Production subnet and dialing in there, but this solution still would not supply the necessary encryption.

EFS is Windows 2000's built in file encryption technology. It is a certificate based technology that is designed to prevent data theft. Only the user that encrypted the data, and a file recovery agent (for administrative purposes), can open a file once it is encrypted. The encryption is based in part on a certificate that is unique to the user's Active Directory account. The encryption is transparent meaning that files are opened and closed normally by the user.Because the company requires centralized recovery it makes sense to locate the recovery efforts at headquarters. Likewise, because the company only has one domain, it makes sense to specify the file recovery agent at the domain level. This will be the person that is responsible for decrypting files. More than one person can perform this task if necessary. For security purposes, the root CA should always be offline and located in a secure location at headquarters. Enterprise CA's should be used any time that users need to have certificates that will be used in conjunction with Active Directory, which is obviously the case here. Stand-alone CA's are not integrated with Active Directory. Third party CA's are used to sign publicly available webservers and other accounts that require a high degree of public trust.
Windows 2000 Help, Search for the articles entitled: Certificate Services overview; Stand-alone certification authorities; Certification authorities; Enterprise certification authorities; Establishing a certification hierarchy; Encrypting File System (EFS); File encryption overview; Encrypting File System and data recovery; and Encrypting and decrypting data with Encrypting File System.

The scenario clearly calls for sales and marketing people to only encrypt their own documents. If they encrypted documents that were shared with others, no one else would be able to view them. This is because documents are encrypted by and for the user account that requests the encryption to be placed on the file. Files can only be encrypted on NTFS volumes.Windows 2000 Help, Search for the articles entitled: Encrypting File System (EFS); File encryption overview; Encrypting File System and data recovery; and Encrypting and decrypting data with Encrypting File System.

Lourdes should configure her remote access server to use callback. When you use the callback feature, the user initiates a call and connects with the remote access server. After authentication and authorization, the remote access server then drops the call and calls back a moment later to a negotiated or preassigned callback number. There are three callback options to choose from: -- No callback (the default) -- Set by caller (specified by caller) -- Always call back to (predefined by administrator) For additional security, select the 'Always call back to' option and type the number of the phone at the user's home (or whatever). When the user's call reaches the remote access server, the following events occur: -- After authentication and authorization of the connection attempt, the server sends a message announcing that the user will be called back. -- The server disconnects and calls the user back at the preset number. -- Once reconnected, the client and server continue the connection negotiation. You should set this option for stationary remote computers, such as those used by the managers in our scenario. The 'Set by caller' option is not really a security feature, because any old number can be specified by the caller. This increases your exposure to a malicious user who has appropriated the identity of an authorized user. So, for the sake of security, you would want to use the 'Always call back to' option.
A proxy server acts as an intermediary between your computer and the Internet. It is most frequently used when there is a corporate intranet and users are connected to a LAN. It can also work with a firewall to provide a security barrier between your internal network and the Internet. Neither proxy server answer would work in Lourdes's situation. Once the user authenticates with the remote access server, the proxy server is not necessary. If the user is unable to authenticate with the remote access server, the proxy server is not necessary again! Besides, proxy server would filter on IP addresses but, in all likelihood, the IP address of the client machine is going to be dynamically assigned by a DHCP server anyway.

Network administrators should carefully analyze their networks in order to assess potential security risks. Security risks manifest themselves in a variety of forms, but a thorough understanding of the different types of network attacks that may be attempted should assist the administrator in minimizing these risks. Any security plan is, by necessity, a compromise between flexibility and security. Prioritizing any perceived threats will help in determining the levels of risk, and those areas that require special attention. In Leilani's situation, the primary threat is external. Sensitive material resides on laptop computers, and sensitive communications take place originating from those computers. To combat attacks against our mobile workforce, we must perform a number of tasks. We must protect the data residing on the disk structure of the laptop, we must ensure we know the identity of the laptop users, and we must be able to transmit secure data over an unsecure channel. To do this requires the use of a couple of technologies. The encrypting file system (EFS) provides confidentiality for the sensitive client and company data on the laptop computers. Using public key technology, we can be assured that only the owner of a file has access to it. Unauthorized access attempts result in an 'Access Denied' message. For safety, recovery agents are specified in case the authorized user has technical problems rendering him or her unable to open a protected file. Virtual private networking (VPN) provides a simple answer to the problem of data integrity and confidentiality.
A VPN is the extension of a private network that encompasses links over public networks like the Internet. A VPN enables you to send data between two computers in a way that appears to be a point-to-point private link. To emulate a point-to-point link, data is encapsulated, or wrapped, with routing information allowing it to cross the public network to reach its endpoint. The data being sent is encrypted for confidentiality. Packets that are intercepted are unreadable without the encryption keys. The link in which the private data is encapsulated and encrypted is known as a virtual private network (VPN) connection. The answer suggesting RADIUS authentication and callback security is only partially viable. Routing and Remote Access (RRAS) supports Remote Authentication Dial-In User Service (RADIUS), which makes it possible to manage remote user authentication through a variety of authentication protocols. Callback security ensures that you can control the phone number the server is instructed to call, reducing the threat of an identity thief compromising a valid user account.
However, both of these techniques address only the issue of authentication. The encryption requirement for hard disk data was not addressed, nor was the necessity for confidential communications. In the absence of any amplifying data, it cannot be safely surmised that any threat to the internal network could be considered primary. Securing server-to-server communications with IPSec policies and using Kerberos to authenticate users is probably a good idea, but not warranted by our scenario. The answer suggesting a combination of factors is likewise incorrect. NTFS permissions do not go far enough in securing physical data. There are ways for a malicious user to bypass NTFS to get at the underlying (unencrypted) text. The Secure/Multipurpose Internet Mail Extensions (S/MIME) protocol ensures the integrity, origin, and confidentiality of e-mail messages. Other communications are unaffected. Secure Sockets Layer (SSL) is normally associated with providing secure access to a Web site. Applications must be SSL-enabled to benefit from SSL. Kerberos is the Windows 2000 standard user authentication mechanism. This can be used for both internal and external authentication purposes.

We know from the background information provided that both the laptops and VPN servers will be running Windows 2000. There are two different types of VPN access possible using Windows 2000. The most secure of these is L2TP in conjunction with IPSec. L2TP provides the VPN tunnel but does not have native encryption support. Because of this, it must be used in conjunction with IPSec to secure the data on the wire. Both L2TP and IPSec must be configured on both ends of the connection.L2TP is only supported as a communication link between two Windows 2000 computers. If communication is required between Windows 2000 and older clients such as Windows NT or 9x, PPTP and MPPE should be used.Windows 2000 Help, Search for the articles entitled: Virtual private networks; Remote access VPN design considerations; Remote access VPN security; Remote access for employees; Internet-based VPNs; Remote access VPN connection; Data encryption; Point-to-Point Tunneling Protocol; Layer Two Tunneling Protocol; Network security; How IPSec works; and Understanding Internet Protocol Security.

In this case, both users are on the same LAN and have different communication needs with different users. The best way for Siobhan to accomplish her objective would be for her to implement IPSec policies. This way, she can configure communications between their computers to require mutual authentication and provide encryption based on IP filters in the policy. Likewise, communications to other users would be unaffected by this policy because there would be no matching filter. A Virtual Private Network (VPN) is designed to provide secure communication for remote users, and users on different networks. In our scenario, the users are on the same physical network.
Securing resources with access control is good practice, but does not address the issues of authentication and encryption. Segmenting the users on an isolated subnet may be a good idea, but it does not address the issues of authentication and encryption either. Also, packet filtering would control the flow of communication from one side of the switch to the other, but this would not be necessary if they were both on the same side, and it might negatively affect their ability to communicate in the clear with other users.

Network and Dial-up Connections supports two types of encryption: Microsoft Point-to-Point Encryption (MPPE), which uses RSA RC4 encryption, and an implementation of Internet Protocol security (IPSec) that uses Data Encryption Standard (DES) encryption. Virtual Private Networks (VPNs) use encryption depending on the type of server they are connecting to. If the VPN connection is configured to connect to a PPTP server, then MPPE encryption is used. Strong (128-bit key) and standard (40-bit key) MPPE encryption schemes are supported. To enable MPPE-based data encryption for VPN connections, you must select the MS-CHAP, MS-CHAP v2, or EAP-TLS authentication methods.
These authentication methods generate the keys used in the encryption process. However, our scenario specifies mutual client/server verification, which eliminates MS-CHAP. If a certificate is installed either in the certificate store on your computer or on a smart card, and the Extensible Authentication Protocol (EAP) is enabled, you can use certificate-based authentication in a single network logon process. EAP-Message Digest 5 Challenge Handshake Authentication Protocol (EAP-MD5 CHAP) uses the same challenge handshake protocol as PPP-based CHAP, but the challenges and responses are sent as EAP messages. Challenge Handshake Authentication Protocol (CHAP) is an industry-standard authentication protocol used by many non-Microsoft clients. Shiva Password Authentication Protocol (SPAP) is a vendor solution for use when connected to Shiva LAN Rover hardware. It is more secure than plaintext, but less secure than CHAP. Finally, Password Authentication Protocol (PAP) uses plaintext passwords, and is the least sophisticated authentication method. Normally, PAP would only be used if the client and the remote access server were unable to negotiate anything better.

It is important to strike a balance between what needs to be audited and what does not. The most important thing when it comes to auditing is to audit only as much as your can routinely monitor. If you audit a great deal of information, but never review any of it, you might as well not be auditing it at all. New administrators need to be very careful that they do not fall into the trap of auditing too much, and thus never wind up looking at the security log.This servår is a domain controller. Because of this it may be used to manage directory service information, as well as accept user logons. It might also be called upon during routine directory access or search events. If you choose to monitor those routine events (such as Directory service access Success or Failure) it will likely generate too much information in the logs. In addition, although the information will tell you who is accessing what, it will most likely not be all that helpful. Object access relates to folder, file and printer access and is not relevant on a domain controller.
The most important things to monitor on a domain controller are logons and logoffs, policy changes, and directory management events. The corresponding access events are officially called Account logon, Account management, and Policy changes. Account management and Policy changes are administrative events that are critical to monitor as they can affect security on the network. It is important to monitor failures so that you can see who is attempting to change them but should not be. It is equally if not more important to track successes for these events so that you will have a log of who changed what. Such accountability is critical on the network and also allows for inappropriate changes to be caught.Account logon events should also be monitored to track who is coming and going on the network. They should be monitored in an effort to catch people trying to break into the network. It should be noted that seasoned administrators do not only audit failed logon events. Information about successful logons can be just as helpful. For instance, if you have a manager that only works from 9 a.m. to 5 p.m. and never logs in from home, yet you see a successful logon from them at 3 a.m. it is likely that someone has obtained their username and password and is accessing the network in an unauthorized fashion.Windows 2000 Help, Search for the articles entitled: Auditing policies; Auditing security events; Audit settings on objects; Auditing; Monitoring Windows 2000 security events; and Auditing access to objects.

You can configure a Windows 2000 DHCP server to dynamically register host (A) and pointer (PTR) resource records on behalf of DHCP clients. Using secure dynamic update with Windows 2000 DNS servers might cause problems with this configuration. Consider the following sequence of events: -- A Windows 2000 DHCP server performs a secure dynamic update on behalf of a client for a specific DNS name. -- The DHCP server becomes the owner of the name (that's the way it works). -- Now, only that DHCP server can update the DNS name. The problem comes when the DHCP server fails, and a subsequent update request from the original client will fail because the failed DHCP server owns the name. To solve this problem, a new security group called DnsProxyUpdate is provided. Any object (DNS record) created by a member of this group has no security. The first client who comes along (who is not a member of this group) and requests an update becomes the owner. Note: If you are using multiple DHCP servers, add them all to the DnsProxyUpdate group. The DnsProxyUpdate group has a couple of security issues to deal with. First off, any DNS names registered by the computer running the DHCP service are not secure. This is important if the DHCP server is on a domain controller.
Also, the DHCP server has full control over all DNS objects stored in the Active Directory because the DHCP server runs under the computer (in this case, the domain controller) account. Therefore, it is highly recommended that you not run DHCP servers on domain controllers. One of the incorrect responses says, very truthfully, that membership in the DnsProxyUpdate group enables full control over all DNS objects stored in Active Directory. The reason it is incorrect is because this is a problem, not a solution! Membership in this group DOES NOT cause the DHCP servers to emulate the interaction behavior for non-Windows 2000 clients. By default, the DHCP server does indeed send updates for clients that do not support the Client FQDN option (option 81). This allows the server to perform proxy updates in DNS for all of its non-Windows 2000 DHCP clients. This does not, however, have anything to do with the DnsProxyUpdate security group.

With a clean installation of Windows 2000, certain default access control settings are assigned to the Power Users and the Users groups on an NTFS partition. The primary difference is that the Power Users group is given sufficient access to install computer-wide applications. Specifically, this group is given the following permission structure for the relevant file system objects: -- All Users: Modify -- All Users/Documents: Modify -- All Users/Application Data: Modify The Users group is given Read access to these same objects (plus Create File for the All Users/Documents object). All that needs to be done to satisfy the conditions of our scenario is to assign Barbara to the Power Users group. Further assigning the Power Users group Full Control permissions to these objects would not be correct. This would give this group more power than is required by our scenario. Also, it would require Ignatz to make these changes, adding to the administrative burden. Barbara, and every other user, already has Full Control to the %UserProfile% object. This object represents user-specific settings that each user has complete control over (unless that control is revoked by the administrator).
The use of the '%' character represents a system variable that is interpreted at login time by the system, and applied to the appropriate user. The Server Operators group is to domain controllers what the Power Users group is to member servers. Membership in the Server Operators group would give you similar abilities at the domain level that the Power User enjoys at the local computer level. Since Ignatz's server is not a domain controller, it does not have a Server Operators group.

File permissions include Full Control, Modify, Read & Execute, Read, and Write. Each of these permissions consists of a logical group of special permissions. These permissions are summarized in the following table: (FC. Full Control, M - Modify, RX - Read & Execute, R - Read, W - Write) Special Permissions: FC M RX R W
Traverse Folder/Execute File X X X List Folder/Read Data X X X X Read Attributes X X X X Read Extended Attributes X X X X Create Files/Write Data X X X Create Folders/Append Data X X X Write Attributes X X X Write Extended Attributes X X X Delete Subfolders and Files X Delete X X Read Permissions X X X X X Change Permissions X Take Ownership X Synchronize X X X X X
In our scenario, the ResearchAdmins group requires unlimited access. This equates to Full Control. The Modify permission for this group does not give them the required degree of control. The ResearchManagers group needs to read, write and delete files, as well as execute programs. For them, the appropriate permission level is Modify. Notice that Modify does not allow for the deletion of subfolders and files. The Delete special permission allows them to delete the files in the Research folder. The permissions required for the ResearchUsers group is pretty straightforward -- Read & Execute. The Read permission itself does not include the special permission Traverse Folder/Execute File, which is necessary to allow the execution of programs.

A DNS server is required to support the use of Active Directory and for Windows 2000 computers to locate this server or other domain controllers for the domain. Once you have installed Active Directory, you have two options for storing and replicating your zones when operating the DNS server at the new domain controller: -- Standard zone storage, using a text-based file. -- Directory-integrated zone storage, using the Active Directory database. For networks deploying DNS to support Active Directory, directory-integrated primary zones are strongly recommended and provide the following benefits: -- Multi-master update and enhanced security based on the capabilities of Active Directory. -- Zones are replicated and synchronized to new domain controllers automatically whenever a new one is added to an Active Directory domain. -- By integrating storage of your DNS zone databases in Active Directory, you can streamline database replication planning for your network. -- Directory replication is faster and more efficient than standard DNS replication. Using standard zone storage on the DNS server for zone storage and replication, using text-based files is not recommended.
For example, when using standard DNS zone storage and Active Directory together, you would need to design, implement, test, and maintain two different database replication topologies. One replication topology would be needed for replicating directory data between domain controllers, and another topology would be needed for replicating zone databases between DNS servers. This can create additional administrative overhead and effort for planning and designing your network and allowing for its eventual growtH - Storing DNS zone files in .Dns files in the %SystemRoot%\System23\Dns folder is an example of using standard zone storage. In Windows 2000, DNS service provides enhanced default support for UTF-8, a Unicode transformation format. UTF-8 has no effect on integrating DNS into Active Directory.

Perfect Forward Secrecy (PFS) determines how a new key is generated. In the event of a key compromise by a determined hacker, PFS ensures that compromise of a single key permits access only to data protected by that single key. To achieve this, PFS ensures that a key used to protect a transmission cannot be used to generate any additional keys. Setting up a filter to block traffic from a known address is a viable technique only if you know the address to block. From our scenario, there was no way to determine if this was possible. A Diffie-Hellman level of Medium (2) provides keying material for creating 128-bit keys as opposed to 96-bit keys. This is more secure, but does not guarantee that this material will not be reused at a later time to create more keys. 3DES is a strong encryption algorithm, but is independent of the keys used to encrypt and decrypt the data.

Terminal Services provides access to Windows 2000 and the latest Windows-based applications for client computers.It also provides access to your desktop and installed applications anywhere, from any supported client. Because of the multi-user nature of Terminal Services, it is strongly recommended you use the Windows 2000 version of NTFS as the only file system on the server, rather than file allocation table (FAT). FAT does not offer any user and directory security, whereas with NTFS you can limit subdirectories to certain users or groups of users. Even though NTFS5 is strongly recommended, an NTFS installation from an upgraded server will still provide the level of access control you need. If the Terminal Server were in Remote Administration mode, only Administrators would have access. This mode would prevent ordinary users from accessing the file system. The 'runas' command allows you to change context without requiring you to log off first, but, since you must supply valid login credentials to use this technique, this is not a likely cause of our access problem.

Based on our scenario, Desdemona wants to use the Distributed File System (DFS). DFS consists of software residing on network servers and clients that transparently links shared folders located on different file servers into a single namespace for improved load sharing and data availability. DFS organizes these resources in a tree structure, starting with a root located on a Windows 2000 server. From the root, you can define links to shared folders distributed throughout your organization’s local or wide area networks, without regard to their physical location. And, with Network File System (NFS) for UNIX installed, a file system on a UNIX server can be a Dfs target. NetWare Core Protocol (NCP) for NetWare extends DFS to NetWare volumes, although this is not necessary in our scenario. DFS does not add an additional layer of security. The underlying permission structure remains in effect. Migrating or upgrading FAT volumes to NTFS is not required for DFS to work, but it allows a more granular approach to file system security and allows for other capabilities, such as EFS. Encrypting File System (EFS) will not do what Desdemona wants. It has no organizational capabilities. EFS will still provide file encryption on NTFS volumes within a DFS tree. Renaming resources and placing all file servers into the same OU is an unworkable solution. Disparate file systems can reside in servers throughout the enterprise, and it would not be practical or desirable to group them all together.
Also, applying security at the OU level would not give you sufficient control to regulate access to individual files and folders. Publishing the data to a Web server will not solve Desdemona's problem. Additionally, this type of publishing effort would be an administratively prohibitive procedure. Besides, you can already use your browser to access file system data with a Web-style interface. Employing DFS would make this process even more user-friendly.

IPSec (IP Security) enables encrypted network communication. IPSec uses cryptography-based protection services, security protocols, and dynamic key management to accomplish two goals: protect IP packets and provide a defense against network attacks. IPSec is based on an end-to-end security model, meaning that the sending computer encrypts the packet before it is ever placed on the wire, and the receiving computer decrypts the packet only after it has been received. The underlying assumption is that the communication media is inherently insecure. A primary benefit of IPSec is the fact that it operates at the Network Layer of the TCP/IP protocol stack, and any upper layer protocols or applications do not have to be concerned with IPSec. The SSL (Secure Sockets Layer) protocol provides communications privacy, authentication, and message integrity by using a combination of public-key and symmetric encryption. SSL requires that applications be specifically written to support SSL. Kerberos v5 and Smart Cards both have to do with authentication, but neither approach encrypts network traffic.

Windows 2000 provides a set of predefined IPSec configurations. Although these policies are intended to be used as starting points around which to build your IPSec policies, they can be used as-is in certain straightforward situations, such as defined in our scenario. The three predefined policies (and the correct answer) are: -- Client (Respond Only) -- Server (Request Security) -- Secure Server (Require Security) Client (Respond Only) is designed for computers that do not normally use secure communications, but contains what is called a Default Response rule, which enables negotiation with computers requesting IPSec. Only the requested protocol and port traffic for the communication is secured. Server (Request Security) is for computers that normally use secure communications. This policy enables the computer to accept unsecured traffic, such as would originate from a non-Windows 2000 computer, but always attempt to secure additional communications by requesting security from the original sender. This policy allows the entire communication to be unsecured, if the other computer is not IPSec-enabled. Secure Server (Require Security) is for computers that always require secure communications, such as the HighFinance servers in our example. This policy allows unsecured, incoming communications, but always secures outgoing traffic. Therefore, if you are not IPSec-enabled, negotiation will fail, and two-way traffic will not be established.

Gunter should enable IP Forwarding on FIREWALL1 Any routers or switches in the data path simply forward the encrypted IP packets to their destination. However, if your network design includes a firewall, security server, or proxy server, IP Forwarding must be enabled to prevent the packet from being rejected. IPSec uses IP packet filtering for determining whether communication is allowed, secured, or blocked, according to the IP address ranges, protocols, or specific protocol ports. But, in our scenario, FIREWALL1 is not one of our IPSec-enabled computers, reducing the likelihood of this being the problem. Also, disabling packet filtering would affect other communications that relied on it. Also, it is not necessary to enable IP Forwarding on the routers. You cannot use IPSec with a NAT. Security negotiations are not able to pass through. The IKE negotiation contains IP addresses in the encrypted messages that cannot be changed by a NAT because the integrity hash will be broken, or because the packets are encrypted. It is not necessary or desirable to match the negotiation settings exactly between the two communicating computers. The whole idea of negotiation is to allow two computers with different settings to agree on the lowest common denominator as far as secure communications go. Even if you did match up the negotiation settings, you would still not solve the IP Forwarding problem.

By linking the policy to usa.northamerica.gunderville.com, you are limiting the changes to only that domain, not the entire enterprise; therefore, the primary objective has not been met. Because you used the Account Lockout Duration - 30 minutes, Account Lockout Threshold - 5, and Reset Account Lockout counter after - 5 Minutes settings you have successfully met both secondary objectives.

In the enterprise environment, it is not cost effective to install Windows 2000 using the standard interactive setup on each computer. To greatly lower the total cost of ownership (TCO), you can perform automated installations of Windows 2000 Server or Professional on multiple computers. Before you can automate the installation of Windows 2000, you must decide whether the installation will be an upgrade from Windows NT or a clean installation. The following two items will help you determine whether to upgrade or to perform a clean installation: -- If your organization is currently running a Windows operating system and your IT department is centrally managed, you will want to perform an upgrade. If you are planning to create a managed environment but you do not currently have one, then you will want to perform a clean installation so that you can implement standard configurations as you perform your installation. -- If you plan to use existing hardware and existing software applications, perform an upgrade.
Alternatively, if you plan to purchase new hardware and install new software applications, you will need to perform a clean installation. In our scenario, an upgrade was expressly required. Of the five methods mentioned in the answers, only Systems Management Server (SMS) allows Agnetha the upgrade option she requires. All the others will only work in a clean installation environment. Additionally, Remote Operating System Installation works only with Windows 2000 Professional.

Elvis should not use the encrypted PPP connection feature. While it is possible to negotiate an encrypted PPP connection for the dial-up connection with an ISP, this is not necessary and not recommended because the private data being sent, the tunneled PPP frame, is already encrypted. The additional level of encryption is not needed and can impact performance. Even though both tunneling protocols, PPTP and L2TP over IPSec, are compatible with the encrypted PPP connection feature, you still should not use it for the reason detailed above.

The correct answer for our scenario is to put the students into the Power Users group. This is generally required to allow legacy applications to run. For a moment, let us consider the downside of this choicE.- Power Users have far more capabilities than Users, making them potentially far more dangerous. In addition to the capabilities of the Users group, Power Users can: -- Create local users and groups. -- Modify users and groups that they have created. -- Create and delete non-admin file shares. -- Create, manage, delete and share local printers. In a production environment, these may be more capabilities than you want to grant. However, even if a student with these rights failed to exercise prudence and good judgment, any damage would be limited to the local machine. Harry already contends with this issue. If you did not want the students to have Power User rights, the next step would be to use the Security Configuration Toolset to apply the compatibility security template. In effect, this technique "dumbs-down" Windows 2000 security to the equivalent level of an NT 4.0 system. What makes this an incorrect choice is that, although it keeps Harry out of trouble, it is more restrictive for the students than our correct answer.
The option of not using legacy applications would technically be perfect, but this option is not fully supported by the facts of our scenario. It would be wrong to assume that replacements are readily available, or that you could simply eliminate a given application from the curriculum. Putting the users into the Administrators group gives the students virtually unlimited access within the lab network. If one student changed the administrator's password, Harry would be effectively locked out.

Geri needs to implement the Encrypting File System (EFS). EFS protects sensitive data on disk using the NTFS5 (new Windows 2000 version of NTFS) file system. You cannot implement EFS on a non-NTFS formatted drive. EFS uses symmetric key encryption and public key technology to provide confidentiality for files. EFS runs as a system service, meaning it is easy to manage, difficult to attack, and transparent to the owner of the file and to applications the user is running. Only the owner of a protected file can access the file, just like a normal document. Other users simply receive an 'Access Denied' message. However, recovery administrators (whom you can designate) have the ability to recover protected files if that becomes necessary. This protects the user in case the user loses their key, or it becomes corrupted in some way. IP Security (IPSec), Layer Two Tunneling Protocol (L2TP), and Point-to-Point Tunneling Protocol (PPTP) are all technologies that incorporate data encryption, but they involve encrypted transmissions, not encrypted files. Windows NT Lan Manager authentication (NTLM) and Kerberos v5 are authentication technologies. They verify a user's identity, but do not encrypt their files.

Clint's biggest problem is an inadequate number of domain controllers available to facilitate logons. Based on testing, domain controllers configured as in our scenario should be able to handle up to 17,000 interactive user logons within a 10 minute period. In fact, MegaWallet should only need 8 domain controllers in the entire organization. For our scenario, adding an additional domain controller to the Bend office should do the trick. Given the large number of satellite offices (and the associated administrative overhead) it would not be prudent to place domain controllers in each satellite. The increase in replication traffic would more than offset any benefit received. Adjusting the Group Policy slow link settings would be ineffective. The true bottleneck in the system is a shortage of domain controllers. Besides, you are not able to set the 'Administrative Templates' setting to OFF. Unless purposely misconfigured, background refresh of Group Policy should not significantly affect network traffic. By default, this is done every 90 minutes with a randomized offset of up to 30 minutes.

Managing printing security can be tricky. Based on our scenario, the correct answer is: 'Remove the group 'Everyone' from the ACL of all printers. Add the group 'Domain Users' to the ACL for all printers in the printing pool. Give the group the 'Print' permission. Create a group called 'Legal Users' and add it to the ACL for all Legal printers. Give the group the 'Print' permission. Add one or more users to the 'Print Operators' group. Remove the 'Print Operators' group from all Legal printers. Add the 'Legal Admins' group to all Legal printers. Give the group the 'Manage Printers' permission.' Let's take it point by point. -- Printing is limited to authenticated users. By default, the 'Everyone' group has the 'Print' permission. We must remove this group from all printer ACLs because it includes all users, not just authenticated users. To solve this, we add the 'Domain Users' group to the printers in the printing pool and assign them the 'Print' permission. -- Furthermore, printing to the Legal printers is limited to the Legal department. For the Legal department, we must create a new group containing just those users, and give them 'Print' permission, also. -- Users are allowed to submit, delete, and purge their own print jobs. By default, any user who creates a print job has membership in the special system group 'CreatorOwner'. Membership is beyond your control, but this group has all the abilities we need by default. There is not usually any reason to change anything associated with the 'CreatorOwner' group. -- Printer management may be delegated. In a domain environment, there is a built-in group called 'Print Operators', and this group is assigned the 'Manage Printers' permission. This is just what we need for the printing pool, but not for the Legal printers. -- Printer management for Legal printers may only be delegated to the 'Legal Admins' group. For the Legal printers, we must restrict delegation of administration to a specific group.
Just remove the 'Print Operators' group from the Legal printers, and add the 'Legal Admins' group instead, assigning them the 'Manage Printers' permission. Now let's examine the incorrect answers: 'Create a group called 'Legal Users' and add it to the ACL for all Legal printers. Give the group the 'Manage Documents' permission. Add one or more users to the 'Print Operators' group. Add the 'Legal Admins' group to all Legal printers. Give the group the 'Manage Printers' permission.' First, this answer does not remove the 'Everyone' group, opening the printers up to unauthenticated users. Second, giving the 'Legal Users' group the 'Manage Documents' permission gives the members of the group undesired access to other users print jobs. Third, by not removing the 'Print Operators' group from the Legal printers, you have extended administrative capabilities beyond the desired group. 'Remove the group 'Everyone' from the ACL of all printers. Add the group 'Power Users' to the ACL for all printers in the printing pool. Create a group called 'Legal Users' and add it to the ACL for all Legal printers. Give the group the 'Print' permission. Add one or more users to the 'Print Operators' group. Remove the 'Print Operators' group from all Legal printers.'
First, domain controllers do not have a 'Power Users' group. On non-domain controllers, this group has the same permissions as the 'Print Operators' group. Second, we have not provided the required administration for the Legal printers. 'Add the group 'Domain Users' to the ACL for all printers in the printing pool. Give the group the 'Print' permission. Create a group called 'Legal Users' and add it to the ACL for all Legal printers. Give the group the 'Print' permission. Add one or more users to the 'Print Operators' group. Remove the 'Everyone' and 'Print Operators' groups from all Legal printers. Add the 'Legal Admins' group to all Legal printers. Give the group the 'Manage Printers' permission.' About the only thing wrong with this answer is that we also need to remove the 'Everyone' group from the printing pool printers to eliminate access by unauthenticated users.

Frahnz can protect the Internet-exposed interface on the VPN server from unauthorized users as follows: -- Ensure that there is not a routing protocol on the interface. The corporate network needs to be accessed through static routes. -- Have a routing protocol running on the corporate network interface. -- Use Routing and Remote Access filters (not IPSec filtering) on the Internet interface to set input and output permit filters for Layer Two Tunneling Protocol (L2TP) and the Internet Key Exchange protocol (IKE), prohibiting everything but L2TP over IPSec traffic. Then, configure packet filtering in the remote access policy profile for user groups, permitting or denying certain types of IP traffic. These filters are configured when you use the Routing and Remote Access setup wizard. No configuration by the user is required.
Do not bind a routing protocol to the Internet interface, as this will potentially allow access to internal routers that should not be visible from the Internet. Static routing would not be appropriate for Internet access. A routing protocol is required. Dynamic DNS updates allow for your DNS zone records to be updated dynamically, freeing the administrator from the overhead of trying to manually update DNS records when clients are dynamically assigned IP addresses. This does not protect an Internet-exposed VPN server interface. As stated above, you would use RRAS filters, not IPSec filtering, to secure the interface. Also, you would not be using both L2TP and PPTP. These are different tunneling protocols. L2TP provides higher security, and is the standard for Windows 2000 installations.

Administrators often need to test their IPSec policies to determine what policies are truly necessary. During lab testing of deployment scenarios, it is important to simulate normal traffic as closely as possible to the "real thing" to gain important performance and security feedback. Gordon wants to monitor his IPSec traffic during the tests, and view the packet contents with Network Monitor. To accomplish this, the security method of the policy must be set to Medium security. This setting uses the Authentication Header (AH) protocol, which provides authentication, integrity, and anti-replay for the entire packet (both the IP header and the data payload carried in the packet). Network Monitor can then view the unencrypted payload of the AH packet. The two ways to accomplish this goal are: -- Use the predefined IPSec policy Server (Request Security) -- Create a custom IPSec policy. From the Security Method tab, select 'Medium (AH)'. Using the predefined IPSec policy Secure Server (Require Security) uses Encapsulating Security Payload (ESP) which provides confidentiality (encryption) in addition to the AH services. Creating a custom policy, and setting the Security Method to High (ESP) does the same thing. In both of these situations, Network Monitor would not be able to view the payload because it would be encrypted. The security zone level setting for different browser zones is a security mechanism employed by Microsoft Internet Explorer, and does not relate directly to IPSec policy.

Traditional methods of remote user authentication have often involved the use of a centralized database to manage users, privileges, and access control. As the network scales and the users become more distributed, this method can become unwieldy and difficult to administer. Creating a public key infrastructure using certificates can help simplify these problems. Certificates have several advantages: -- They can be widely distributeD.- They can be issued by numerous parties -- They can be verified by simply examining the certificate, without having to refer to a centralized database. However, existing operating systems and account-based administration tools do not really know how to use certificates. The solution is to create a mapping between a certificate and a user account. This allows the operating system to continue using accounts while everybody else uses certificates. When a user presents a certificate, the system looks at the mapping to determine which user account should be logged on.
Mapping a certificate to a Windows 2000 user can be done in one of two ways: the mapping can be done either by the Windows 2000 Active Directory service or it can be done by Microsoft Internet Information Services (IIS). The correct approach for Clive would be to use certificates and establish one-to-one mapping through IIS. This would be appropriate since each user must access specific account information. Establishing a many-to-one mapping would not work in our scenario. If you had multiple users who needed secure access to the same information, then this would be viable. Using Smart Cards, while technologically feasible, does not meet our criteria of minimum administrative overhead and transparent user access. The ActiveX solution is wrong for two reasons: ActiveX technology only works with Microsoft browsers, and our scenario specifies browsers from various vendors. Also, we want to get away from validating an expanding user base against a database.

In this scenario, it would be both efficient and desirable to handle authentication at one source. Remote Authentication Dial-in User Service (RADIUS) is a client-server protocol, which enables remote access equipment acting as RADIUS clients to submit authentication requests to a RADIUS server. Dexter should install a RADIUS server running Internet Authentication Service (IAS) to handle all external authentication. Place this server on the public side of the router, in the Demilitarized Zone (DMZ). Copy the remote access policies from the VPN server to the IAS server. Since the VPN server will be acting as a RADIUS client, authentication will now take place at the RADIUS server.
Also, configure remote access policy on the RADIUS server to handle authentication requests from the remote access server. You would not want to place your RADIUS server on the private (intranet) side of the router to avoid unauthenticated access to the private network. By authenticating client requests outside the private network, in the DMZ, these issues are eliminated. Installing a firewall and using PPTP packet filtering is an extra security measure, but it does not address the authentication issue. You would not configure a proxy server as a Kerberos client. Kerberos is integrated within Windows 2000, and cannot be configured in this manner. Administering authentication separately does not meet our criteria of the most efficient design.

The onsite employees access the network (get their mail) through the OWA server. No other type of network access is mentioned in the scenario regarding them. OWA is a web based technology. In Windows 2000 there are only a handful of ways to authenticate someone using web based technology. Only two of those methods are mentioned here. One is basic authentication. Basic authentication sends the user's password to the webserver in clear text. Because of this SSL can be used in conjunction with it to encrypt the communication channel and protect the password. NTLM can also be used for authentication. This type of authentication does not require SSL because it automatically protects the user's password during authentication. A third type of authentication, digest, is also possible if the user is accessing OWA with Internet Explorer 5 or later. This type of authentication also protects the user's password.Windows 2000 Help, Search for the articles entitled: Secure Socket Layer/Transport Layer Security (SSL/TLS) authentication.

The best action to take that will cause you the least amount of administrative effort and not interfere with network access is to create a packet filter that discards ICMP packets.

[A: This would stop the attack, but it would also prevent incoming connections until DNS could be updated; therefore, it is not the best action.]

[B: This would have limited effect. If this was a distributed denial-of-service attack, it would come from many source IP addresses, not just a single one. Blocking each IP address would require a lot of administrative effort.]

[C: This would not have any effect. The server would come back up and continue to be attacked in this manner.]

[E: There is no way to create a packet filter that returns the ICMP packets. Even if that was possible, this would not be the best action to take because it would only cause more network traffic.]

The basic design process for Windows 2000 domains is different from the design process for Windows NT domains. In Windows NT networks, your domain structure is guided by the relationship between master user domains and resource domains. Your existing Windows NT domain model should not be the basis for your Windows 2000 domains. Instead, you should consider your company’s physical and operational structure, as well as the requirements of your network administrators. One major reason to use multiple Windows 2000 domains is to support decentralized administration. Your company's administrative units may not accept a domain design that gives them limited administrative control over their own resources. This is the case in our scenario, where the resource access limitations are clearly defined. Two account domains is the right choice for Liesl. After you establish the number of domains that is appropriate for your company, you must consider how to organize them into a useful hierarchy. As one of your essential Windows 2000 design tasks, you need to decide whether to arrange your company’s domains into a Tree or a Forest.
Some companies, such as ours, need a single Tree to support their enterprise. All domains forming a Tree or Forest can share their resources globally. After your domain design strategy, you must determine how your company will arrange its organizational units (OUs). Your company can use OUs to organize its resources in a more meaningful hierarchy. OUs form a meaningful structure for the various objects in a domain. Your primary goal in forming this structure is to make your OUs useful for users and administrators. In our scenario, it makes sense to migrate the retail resource domains into OUs under the Sales domain. This allows for efficient administration and ease of use. The same would apply for the New York resource domains. Migrating them into OUs under Headquarters would serve the same purpose. Creating a single account domain would be incorrect for our situation as outlined above. Migrating the resource domains into OUs under the Headquarters domain is an inefficient design. This is appropriate for the White Plains and Hackensack resource domains, but not the retail resource domains. Administration of the retail OUs should fall under Sales, where the resources are managed and controlled. A similar argument exists against migrating all resource domains into OUs under the Sales domain. Migrating the existing retail stores resource domains into OUs is correct, but placing them under the Headquarters domain is not.

There are four places where you can apply Group Policy: the local computer, the site, the domain, and the OU. The local Group Policy object is applied first. Then site-linked policies are applied in administrator-specified order, followed by domain-linked policies, also in specified order. Finally, OU-linked policies, starting at the top of the Active Directory hierarchy and ending with the OU actually containing the user or computer. Help Gwyneth save her job in the following way: create a single Group Policy object for all distribution centers, and apply it at the domain level. A Group Policy object applied to a domain applies to all users and computers in the domain AND, by inheritance, to all users and computers in OUs and generic Active Directory containers farther down the tree. An additional benefit of this approach is ease of maintenance. If the policy needed to be modified, you would only have to go one place to modify it, not 14. Creating a single Group Policy for all distribution centers and applying it at each distribution center is incorrect because it requires Gwyneth to link the policy 14 times instead of just once, greatly increasing the administrative burden. Creating separate Group Policy objects for each distribution center, as suggested in two of the answers, would be incorrect for the same reason -- increased administrative burden.

Confidentiality is the issue, and encryption is the answer. Since the problem involves transmission of data, an Internet Protocol Security (IPSec) policy should be employed. IPSec is the future of secure networking. The two goals of IPSec, packet security and defense against network attacks, are realized through a combination of cryptography-based protection services, security protocols, and dynamic key management. IPSec is an end-to-end security model, meaning that only the computers on the sending and receiving ends of the transmission need to be "IPSec aware." IPSec works equally well in LAN, WAN, and remote access situations. IPSec comes in two flavors -- with or without payload encryption. With encryption, as specified by the particulars of the scenario, is handled by Encapsulating Security Payload (ESP). IPSec with ESP provides confidentiality, authentication, integrity, and anti-replay. Authentication Header (AH) is essentially the same thing, only without the actual data being encrypted. You would use IPSec with AH if you required authentication, integrity, and anti-replay, but not data encryption.
Encrypting File System (EFS) encrypts files and folders on an NTFS file system. This is an incorrect choice because in does not provide for confidentiality while the data is in transit. EFS encrypts the files at the computer. Even though EFS was not the right answer for our scenario, Dewey, Cheatham, and Howe should use EFS for even greater protection. Group Policy allows you to regulate users' access control very effectively, but nothing in Group Policy allows for the encryption of network data.

Here are the descriptions of the Windows 2000 predefined policies: -- Client (Respond Only) This policy is for computers that normally do not secure communications. This policy enables John's computer to respond to requests for secured communications. It contains a Default Response rule, which enables negotiation with computers requesting IPSec. Only the requested protocol and port traffic for the communication is secured. -- Server (Request Security) This policy is for computers that normally do secure communications, such as servers that transmit sensitive data. This policy enables the computer to accept unsecured traffic, but always requests security from the sender. This policy allows the entire communication to be unsecured if the other computer is not IPSec-enabled, thus violating the rules of our scenario. -- Secure Server (Require Security) This policy is for computers that always require secure communications, such as a server that transmits highly sensitive data. This policy allows unsecured, incoming communications, but always secures outgoing traffic. This is the configuration we need for HR1. IPSec is based on an end-to-end security model, meaning that the only computers that must know about the traffic being secured are the sending and receiving computers. Each handles security at its respective end, assuming the transmission media is inherently insecure. Any computers that only route data from source to destination are not required to support IPSec. In our scenario, ROUTER1 does not need to be configured for IPSec, rendering any answer including ROUTER1 incorrect. Also, one of the questions fails to address a required configuration for John's workstation, which is also incorrect. To recap, HR1 needs Secure Server (Require Security) and John's workstation needs Client (Respond Only).

The default file extension for certificates and private keys stored in a password-protected file is PFX.

Remote Installation Service (RIS) is an efficient, cost-effective way for administrators to install Windows 2000 Professional on client computers. Using a process known as "prestaging," Active Directory objects representing the client computers are created and configured to request a specific RIS server for installation. When a RIS server receives a request from a client, it checks Active Directory for a match. If a match is found, the specified RIS server is provided to the client, even if it is a different one than answered the initial request. This process is called 'server referral' and gives the administrator the flexibility to control which server provides service to specific clients, regardless of who answered the original request. To allow additional flexibility and security, the prestaging and referral concepts can also be combined with RIS server settings that control how servers respond to clients. Given the scenario, we must "prestage" our clients in Active Directory.
Then we configure the client accounts to request a specific server to download from. We would specify Server2, Server3, Server4, or Server5 because these are the servers that will perform the installations. But we want Server1 to answer all client requests, and refer them to the appropriate server. To accomplish this, we configure Server1 with both options selected. We also configure the other servers with the option 'Do not respond to unknown client computers'. This ensures that Server1 responds to all requests, and also ensures that only prestaged clients are serviced. If the 'Do not respond to unknown client computers' option is not selected for the other RIS servers, they will reply to service requests from nonprestaged clients, offering themselves as the remote boot server. This answer: 'Configure each client computer to use Server1 to request installation. Configure Server1 with the options 'Respond to Clients Requesting Service' and 'Do Not Respond to Unknown Client Computers' selected. Configure the other RIS servers with the option 'Do Not Respond to Unknown Client Computers' selected.' is wrong for two reasons.
First, the clients need to be prestaged in Active Directory. Second, the clients must be configured to request installation from the servers containing the distribution files, not Server 1. This answer: 'Configure each client computer to use a specific RIS server (Server2, Server3, Server4, or Server5) to request installation. Configure Server1 with the option 'Do Not Respond to Unknown Client Computers' selected. Configure the other RIS servers with the options 'Respond to Clients Requesting Service' and 'Do Not Respond to Unknown Client Computers' selected.' is also wrong for two reasons. One, we did not prestage our clients. Two, Server1 needs to be configured with the 'Respond to Clients Requesting Service', not the other RIS servers. You only prestage client computers in Active Directory, not servers.

Smurfing, or a Smurf IP attack, is generally considered a DoS attack and is implemented by swamping a network with replies to ICMP echo (PING) requests sent to broadcast addresses. [B: A Manman-in-the-middle attack is performed when an attacker intercepts messages in a public key exchange and then retransmits them, substituting their own public key for the requested one. As far as the two original parties are concerned, they are still communicating directly with each other. The attacker uses a program that makes the server think it's still talking to the client and the client believes it is still talking directly to the server.] [C: Teardrop attacks are IP layer attacks that use fragmentation, where the reassembly of the packet causes the problems that can cause systems to crash, by using a reassembly bug with overlapping fragments.] [D: Buffer Overflow attacks simply send more traffic to a network address than the data buffers for the program or system process can handle.]

Secure communication requires encryption. The onsite employees in question will be accessing the OWA server. The background information provided by the company makes no mention of them being allowed VPN access to the network. Because of this, only one encryption technology is mentioned that works with web technology based access. SSL is designed to encrypt information between webservers and clients. Of the available answers, only basic authentication is an actual type of authentication possible with Windows 2000 web based technologies. Web services in Windows 2000 are made available through Internet Information Server (IIS) components.Windows 2000 Help, Search for the articles entitled: Secure Socket Layer/Transport Layer Security (SSL/TLS) authentication.IIS 5.0 Documentation: Search for the articles entitled: Enabling and Configuring Authentication About Authentication; and Authentication Overview.

In our scenario, a visitor to the Web site may or may not be an existing customer. Since each customer's data is stored securely in a SQL Server, requesting an ID and password allows a positive way to establish identity. This method requires the visitor to produce credentials to gain secure access. Cookies are stored on the user's computer, and are therefore out of the control of the Web site administrator. Since there is no way to guarantee that the user of the computer containing the cookie is the correct user, this would not do as our authentication method. In a situation where you needed to safeguard a customer's personal data, cookies would not provide you the level of positive identification required. In situations where you want remember preferences to provide a more personalized user experience, cookies give the network administrator a way of shifting the responsibility for remembering this information from the Web site database to the user's own computer.
Anonymous login treats every user in the Solar System as one specific user account in the operating system. Since we do not care who accesses the public areas of the site, but very much care who accesses the private areas, anonymous login would not be an appropriate choice. Allowing a visitor to place an order as a new or existing customer compromises the integrity of your database information. Allowing a single customer to create multiple accounts would negatively impact your primary mission of providing excellent customer service.

Legacy desktop applications that ran under a User context on Windows NT 4.0 will probably have to run under a Power User context on a Windows 2000-based system. In practice, members of the Users group will not be able to run most legacy applications because most legacy applications were not designed with operating system security in mind. Power Users are ranked between Administrators and Users in terms of system access. The default Windows 2000 security settings for Power Users are backward-compatible with the default security settings for Users in Windows NT 4.0. However, the Power Users group gives users more access than they had under NT 4.0. Specifically, members of this group can install and remove applications per computer that do not install system services, and customize system-wide resources (for example, System Time, Display Settings, Shares, Power Configuration, and Printers).
If you do not want your users to have this additional power, you can apply a security template that exists for just this purpose. The template can be applied to a system using the Security Configuration Toolset using the following syntax: secedit /configure /cfg compatws.inf /db compatws.sdb This has the effect of reducing the security posture of the system somewhat in order to allow the access required by some legacy applications. You can check to see if your applications meet the Windows 2000 criteria, and even find out what you need to do to have your application tested by going to the Web site in one of the answers, but you cannot register your legacy applications there. Running the application as a service is incorrect. Not all applications are designed to run as a service, and members of the Users or Power Users groups cannot install services. Only members of the Administrators group can do this. On machines that are upgraded from a previous operating system version, default Windows 2000 security settings are not applied. The administrator can run the 'secedit' executable to apply the Windows 2000 default security settings after the upgrade has been completed. However, this procedure does not provide the capability required by our scenario.

Any time a mainframe computer provides all processing power, you are constrained to operate within a centralized model. In our scenario, all processing and administration take place in New York, with the distribution centers doing little more than providing input. This is a classic centralized IT model. With the envisioned model, Active Directory provides the ability for higher level administrators to delegate control for specific elements within Active Directory to individuals or groups. This eliminates the need for multiple administrators to have authority over an entire domain. Do not be fooled by the relative autonomy afforded the distribution centers. IT functions remain centralized, while delegating authority to the local level. Neither one of the IT environments is an example of a decentralized model. The existing mainframe processing structure does not support a decentralized model, and the envisioned Windows 2000 model would have to be structured in such a way as to have separate IT departments in the different regions, which we do not have.

You can specify that an audit entry is written to the security event log whenever certain actions are performed or files are accessed. The audit entry shows the action performed, the user who performed it, and the date and time of the action. You can audit both successful and failed attempts at actions, so the audit trail can show who performed actions on the network and who tried to perform actions that are not permitted. You can view the security log in the Event Viewer. For Margie's situation, it would be most useful to track write access for program files and process tracking. She should run any suspect programs, then examine the security log for unexpected attempts to modify program files or create unexpected processes. While performing these audits, she should run them only when actively monitoring the system log, as our scenario specifies. Tracking privilege use would show Margie who was exercising various user rights.
User rights are different from permissions because user rights apply to user accounts and permissions are attached to objects. Examples of privilege use would be loading device drivers or taking ownership of objects. Auditing policy change events would give another indication of a possible misuse of privileges, but would not be useful in tracking a possible virus threat. Tracking logon events are most useful in fighting password attacks. This chart correlates a selection of common threats with the specific auditing events designed to help detect and counteract them: Audit Event Threat Detected Failure audit for logon/logoff. Random password hack Success audit for logon/logoff. Stolen password break-in Success audit for user rights, user and group management, security change policies, restart, shutdown, and system events. Misuse of privileges Success and failure audit for file-access and object-access events. Improper access to sensitive files Success and failure audit for file-access, printers and object-access events. Improper access to printers Success and failure write access auditing for program files (.exe and .dll extensions). Success and failure auditing for process tracking. Virus outbreak.

This scenario calls for two negotiation policies and two IP filters. One negotiation policy is designed for Research department's internal communications. This one would use a security method of Medium (AH) "Data will be authentic and unmodified, but will not be encrypted." The other negotiation policy would be for external communications, and would use a security method of High (ESP) "Data will be encrypted, authentic and unmodified". Create an IP filter for each negotiation policy. Only one filter for both inbound and outbound communication is required because both the source and destination address information is specified in the filter. When a user in Research sends data, the source and destination addresses are checked against the IP filters in the Research security policy. If there is a match, the associated negotiation policy specifies the level of IP security for the session. When creating negotiation policies, ANY is not listed as one of the protocol choices.

After you have upgraded all existing Windows NT domain controllers to Windows 2000, you can switch the domain from a mixed-mode to native-mode. The change from mixed-mode to native-mode is manually done by an administrator using the Active Directory Domains and Trusts snap-in. This is the action Moonbeam should take. Be aware that once you switch to native-mode, you cannot go back. This means that you cannot add an NT 4.0 domain controller in the future, although this is does not appear to be an issue in our scenario. In a mixed-mode environment, both Kerberos v5 and NTLM authentication protocols are in use. NTLM is provided for backwards compatibility. Once all domain controllers are running Windows 2000, you can elect to convert to native-mode. It does not happen automatically. The fact that Moonbeam still has member servers running NT 4.0 is of no consequence. Member servers are not involved in the authentication process. Kerberos v5 is integrated into Windows 2000. You cannot install it separately.

Local Group Policy does not allow you to apply security filters or to have multiple sets of Group Policy objects, unlike Active Directory-based Group Policy objects. You can, however, set Discretionary Access Control Lists (DACLs) on the GroupPolicy folder so that specified groups are either affected or are not affected by the local Group Policy object. This is useful if you have to administer computers that are used in situations such as kiosk environments, where the computer is not connected to a LAN. Local Group Policy object uses the Read attribute, which makes it possible for the local Group Policy object to affect ordinary users but not local administrators. The local administrator can first set the policy settings and then set the DACLs to the local Group Policy object folder so that administrators no longer have Read access. For the administrator to make subsequent changes to the local Group Policy object, he or she must first take ownership of the directory to give him or herself Read access, make the changes, and then remove Read access.
After you make changes to the Group Policy object, remember to remove Read access for the group in which you are a member. If you fail to remove Read access, you may not be able to gain access to the Group Policy object. Therefore, it appears that Raylene has Read access to the GroupPolicy folder. Not having Read access to this folder would have the effect of making you immune to the Group Policy settings contained within -- a good thing for an administrator. Removing the Group Policy snap-in would not be catastrophic. Simply add the snap-in back. The Administrative Templates node of the Group Policy snap-in can be extended by using custom .adm files. However, unlike other Group Policy snap-in extensions, it is not extensible by an MMC snap-in extension. The node itself would not be set to 'Not Configured'. The actual settings listed inside the .adm files would have that setting applied.

The Windows 2000 public key infrastructure supports a hierarchical certification authority (CA) trust model, called the certification hierarchy. You can deploy multiple CA hierarchies to meet your needs. The CA at the top of the hierarchy is called a root CA. This is the most trusted CA in your organization, and it is recommended that it have the highest level of security. A root CA may have one or more subordinate CAs. Subordinate CAs can be either an intermediate or an issuing CA. Intermediate CAs can also have subordinate CAs. An intermediate CA issues certificates only to subordinate CAs. An issuing CA issues certificates to users, computers, or services. In theory, there is no limit to the number of levels your certificate hierarchy can have. You might choose, as Rosebud did, to have an isolated, offline root CA for security reasons in order to protect it from possible attacks by hackers or malicious network users.
A major issue with an offline root certification authority is providing certificate verifiers with online certificate revocation checking. The root CA maintains something called the certificate revocation list (CRL). Normally, this list resides at a URL accessible to all users. In our scenario, the root CA is offline, requiring us to change the URL location of the CRL distribution point to a location that is accessible to all users. Rosebud must then physically copy the list from the location on the now isolated root CA (normally '\Systemroot\system32\CertEnroll\CAname.crl') to portable media for further distribution to the new distribution points. If this is not done, certificate revocation checking will fail. Specifying whether or not to make incoming certificate request pending or automatically approved is not directly related to the offline root CA issue. Besides, the default behavior, pending, is suitable for most situations. As stated above, there is no limit to the depth of your hierarchy.

Shared folders allow administrators to regulate access to folders over the network. There are three shared folder permissions that can be granted: Read, Change, and Full Control. It is important to note that these settings only apply if the folder is accessed from the network. If the user accesses these folders through another means (like logging on interactively), the permissions are not applied because the user did not go through the share in order to get there. Also, shared folder permissions are the only way to apply any sort of security to a FAT volume. In our scenario, it is most likely that the appropriate NTFS permissions have not been set to allow members of the Marketing Users group access.
As stated in the correct answer, shared folder permissions are sufficient to gain access to files and folders on a FAT volume, but not on an NTFS volume. If you move a shared folder to someplace else, it is no longer shared. However, we know this is not Joy's problem because she is able to attach to the share. If Joy is logged on using cached credentials, this means that a domain controller was not available to service her logon request. This results in her not having access to network resources, which she has in our scenario. Administrative shares are automatically created by Windows 2000, not the administrator. Unless Joy was an administrator, she would not be able to access administrative shares.

There are a couple of areas to keep in mind when you are creating forests and domains in a Windows 2000 environment: replication traffic and resource access. In our scenario, server security requirements have the most direct impact on our forest design. If you have servers that must communicate securely, it is generally advised to place them into their own OU, allowing you to apply the appropriate security policies at the OU level. User accounts are very flexible. You can put users where you want them for administrative purposes. For resource access considerations, use security groups to regulate access.
It does not matter where in the forest you place the security groups, and they can contain users from anywhere in the forest. Secure Web transactions involve Secure Sockets Layer (SSL) technology, and are not really dependent on placement within the forest. Typically, they can be plugged into the Active Directory structure where they are most convenient. Kerberos is the default Windows 2000 authentication mechanism. It will adapt to whatever forest structure you design.

Windows 2000 enterprise CAs and stand-alone CAs require nested validity dates for all CA certificates and all issued certificates. No child CA can issue a certificate with a date past the root CA's end date. Also, an issuing CA cannot issue a certificate beyond its own end date. In our scenario, the issuing CA would respond to the two year request by doing the best it can -- issuing a truncated two year certificate with an end date of March 27, 2005. Barney should renew his Windows 2000 CAs with new CA certificates before they are constrained by nested validity dates. To avoid the constraints of nested validity dates, deep certification hierarchies with Windows 2000 Certificate Services might require frequent renewals for issuing CAs. The one year and two year certificate answers are incorrect because they do not reflect certificates services behavior. A certificate will be issued, but in no case will its end date exceed the end date of the issuing CA.

The availability of IPSec encryption features in Windows 2000 is subject to United States export regulations, and may also be subject to local and national regulations. IPSec policies allow the choice of a strong encryption algorithm, 3DES, that uses a longer key length than DES for higher security. Windows 2000 computers must have the High Encryption Pack installed to use 3DES. If a computer receives a 3DES setting, but does not have the High Encryption Pack installed, then the 3DES setting in encryption policy is set to the weaker DES. Therefore, the statement in one of the answers that IPSec encryption services are not available without the High Encryption Pack is incorrect. Encrypting File System (EFS) is designed to provide encryption services to files and folders on local computer systems. However, EFS does not fall under IPSec policy restrictions and 3DES is not an algorithm that is available to EFS, rendering both answers that reference EFS incorrect.

Boris has two concerns: integrity and encryption. The communications must be secure, meaning they must be verified and unchanged at the destination. Also, they must be confidential (encrypted). The primary technology which assures these requirements will be met is Internet Protocol Security (IPSec). IPSec policies allow secure, end-to-end communications between two computers on an IP network. Optionally, Boris can encrypt his IPSec traffic using Encapsulating Security Payload (ESP). Authentication Header (AH) provides authentication and integrity, but not encryption. Encrypting File System (EFS) provides encryption services for file systems, ensuring only authorized users may access these files. Although EFS is certainly a technology Boris should employ, it is not warranted in our scenario because it does not encrypt transmission of data. Distributed File System (DFS) is a service that combines elements from different file systems into a single, logical tree structure. DFS has no inherent security capabilities, but will incorporate EFS to provide encryption. EFS requires an NTFS partition to work, but DFS does not. However, no file system protection is available on any part of a DFS tree that is located on a FAT volume.

A certificate trust list (CTL) allows you to control trust of the purpose and validity period of certificates issued by external CAs. A CA can issue certificates for a wide variety of purposes, such as secure e-mail or client authentication. However, you want to limit the trust of certificates issued by a particular CA, especially if the CA is external. This is where creating a certificate trust list and using it via Group Policy is useful. In our scenario, the external CA is capable of issuing certificates for e-mail, server and client authentication, and code signing. Bruce only wants to trust certificates issued for the purpose of secure e-mail. He can create a certificate trust list and limit the purpose for which he trusts certificates issued by the external CA so that they are only valid for secure e-mail. Any certificates issued for another purpose will not be accepted for use by any computer or user in the scope of the Group Policy object to which the certificate trust list is applied. Trusted root certification authority policy only applies to internal CAs, not external. The 'Using the Advanced Certificate Request' Web page option is limited to internal stand-alone CAs. If the proper guidelines are followed, there should be no reason for Bruce to worry about increased security risks due to unnecessary capabilities of the external CA.

Looking at the requirements of the Marketing department, we see that they require secure internal communications between some key players and their file server. Internet Protocol Security (IPSec) provides our solution. This scenario calls for one negotiation policy and two IP filters. The negotiation policy applies to the designated computers in the Marketing department. It would use a security method of Medium (AH) "Data will be authentic and unmodified, but will not be encrypted." Had we specified confidentiality, we would have needed to use a security method of High (ESP) "Data will be encrypted, authentic and unmodified". Buffy must then create an IP filter for the negotiation policy. Only one filter for both inbound and outbound communication is required if both the source and destination address information is specified in the filter. When one of our designated users sends data, the source and destination addresses are checked against the IP filter in the security policy. If there is a match, the associated negotiation policy specifies the level of IP security for the session. VPN features and RRAS callback security allow us to secure and authenticate communication originating from outside the LAN, which was not specified by our scenario. Plus, this answer did not address secure communication within the LAN, which was specified by our scenario. Encrypting File System (EFS) encrypts file system data, but not data transmissions. You would use IPSec for that, as detailed above.

When you implement IP Security, you must strike a balance between ease of information retrieval for legitimate users, and protecting sensitive information from unauthorized access. To help administrators do just this, three security levels have been defined to provide a general basis for a security plan. These levels are Minimal Security, Standard Security, and High Security. Minimal Security is appropriate where no exchange of sensitive data takes place. In this case, IPSec is not even enabled. Our scenario requires more security than this. Standard Security is based on two predefined IPSec policies: Client (Respond Only) and Server (Request Security). These policies secure necessary data, but do not necessarily provide the highest level of security. This security level best meets the needs of an administrator like Raoul, who needs to balance performance issues with security needs. High Security is based on the Secure Server (Require Security) IPSec policy. This policy includes strong confidentiality and integrity algorithms, Perfect Forward Secrecy, key lifetimes and limits, and strong Diffie-Hellman Groups. Unsecured communication is blocked. This level of security is too restrictive to meet Raoul's needs, and it would impose sufficient administrative overhead to negatively impact network performance. If none of the predefined policies meet your needs, you create your own custom policies. Raoul is free to create custom policies to fine-tune his needs, but, based on the scenario, the Standard Security level does conform to the guidelines presented.

When you deploy custom code over the Internet, your customers are more likely to trust your active content if it has been digitally signed by a reputable third-party CA. Using commercial CAs also removes the liability faced by your organization when you sign your code internally for external software distribution. If you distribute software on the Internet, you should normally use a commercial CA to issue digital signing certificates to your external software developers. In an internal environment, you should have your code signed by trusted developers. An enterprise CA or a stand-alone CA could provide the digital signature, and you could configure your company's internal Internet Explorer browsers to automatically download the content without any indication to users. An enterprise subordinate CA is simply a member of a certification hierarchy, and would have the same inherent capabilities as the root CA.

Active Directory allows administrators to delegate control for specific elements within Active Directory to individuals or groups. This eliminates the need for multiple administrators to have authority over an entire domain. Domain Name System (DNS) dynamic update protocol provides interoperability with existing UNIX servers. Dynamic update enables DNS client computers to register and dynamically update their resource records with a DNS server whenever changes occur. This reduces the need for manual administration of zone records, especially for clients that frequently move or change locations and use DHCP to obtain an IP address. Kerberos security, the default Windows 2000 authentication mechanism, works on both platforms. Kerberos is a multivendor standard, so it allows secure interoperability and the potential for single sign-on between Microsoft implementations and other vendor environments.
The Windows NTLM protocol was the default for authentication in Windows NT 4.0. It is retained in Windows 2000 for compatibility with clients and servers that are running Windows NT version 4.0 and earlier. It is also used to authenticate logons to stand-alone computers that are running Windows 2000. Windows 3.11, 95, 98, or Windows NT 4.0 must use the NTLM protocol for network authentication in Windows 2000 domains. Computers with Windows 2000 use NTLM when they are authenticating to servers that are running Windows NT 4.0 and when they are requesting access to resources in Windows NT 4.0 domains. NTLM is not UNIX-compatible. Domain Name System (DNS) by itself does not provide interoperability with existing UNIX servers. The dynamic update protocol is required. IntelliMirror, Remote Install Services, and Systems Management Server are client management features and automated client install and upgrade technologies. They do not address the requirements of the scenario. Internet Protocol Security (IPSec) is a Windows 2000 implementation allowing secure network communications. There is no UNIX interoperability with IPSec.

By delegating authority to administer the rights for a container, you can decentralize administrative operations and minimize overhead. This reduces the cost of ownership by distributing administration closer to the resources. You define delegation of responsibility at the level of the organizational unit, or container, where the accounts are created. An organizational unit is the smallest scope or unit to which you can assign Group Policy settings or delegate administrative authority. However, policy settings that are domain-wide and permissions that are defined at higher levels in the directory tree can apply throughout the tree by using inheritance of permissions. You can delegate administration of a domain or organizational unit by using the Delegation of Control wizard available in Active Directory Users and Computers. In Ron's case, he should restrict the delegation of permissions for the Dist-Admins group to updating just the specific property, the password property, of User objects in the OU. This way, Marlon cannot inadvertently apply unsound administrative practices during his apprenticeship. Remember, the OU is the lowest level to which you can delegate authority. This means you cannot delegate authority all the way down to User objects, as suggested by one of the answers. Giving the group permissions to create and delete User objects would give Marlon too much control. Although he can change the password property of any user he creates, he can also perform other, less desirable, activities. Giving the group permissions to change properties of the OU would extend his reach beyond mere User objects.

In Windows 2000, a common technique for the delegation of control is to create an OU and assign the appropriate permissions to create or modify objects or attributes of objects. In our scenario, by giving Zlatko (by way of his group membership) Full Control access to User, Group, and Computer objects, he can perform day-to-day administration for his OU, but at the same time, is prohibited from performing other administrative tasks such as creating OUs. It would be incorrect to assign access directly to Zlatko's user object. From our scenario, we know that his tenure at AAGARSS may soon be cut short. This would require Rufus to explicitly remove access from Zlatko and add access to his replacement. To avoid this, use security groups to provide access control. Giving Zlatko Full Control to the OU and all child objects would create the exact situation we are trying to avoid. Zlatko would become master of his OU, violating the concept of centralized control. The Power Users group does not appear by default in the Access Control List (ACL) for the AAGARSS OU. The Power Users group is associated with member servers and workstations and doesn't even appear in the list of available groups at the domain level.

As part of your OU structure plan, you create OU's for three purposes: -- Delegation of authority -- Hiding objects -- Group Policy Even if a user does not have the right to read the attributes of an object, that user can still see that the object exists by viewing the contents of the parent container. The easiest and most efficient way to hide an object or set of objects is to create an OU for those objects and limit the set of users who have the List Contents right for that OU. In this way, you only have one group of ACL settings to manage, whether you need to hide one object or one thousand. You could create a separate resource domain, but there would be significantly more administrative overhead, not to mention additional hardware requirements, to implement that option. You could (eventually) accomplish the same goal by going to each and every object you want to "hide," and individually manipulating their ACLs. In addition, this incorrect response also referenced removing the List Contents right from the Everyone group. List Contents would only apply to container objects. If one of your objects was, say, a server, there would not be a List Contents right. A Security Group is designed to simplify providing access for large numbers of users. Examples of Security Groups include Local groups, Global groups, and Universal groups. You would not be able to place other random types of objects into a Security Group. (Note that List Contents only applies to container objects, not leaf objects.)

To truly benefit from the performance enhancements available with Kerberos authentication, Kerberos v5 should be the only logon protocol in the enterprise. Windows 2000 implements the IETF standard version of Kerberos v5 authentication protocol for cross-platform interoperability. For example, users on UNIX systems can use Kerberos credentials to log on to UNIX systems and to securely connect to Windows 2000 services for applications that are Kerberos-enabled. Remember, the NetWare elements are not making the move. As described, the proposed network infrastructure can easily support 15,000 users with a single domain controller. Adding additional domain controllers will not significantly enhance logon performance. NTLM authentication is provided for backwards capability for those networks that are communicating with older versions of Windows. In our scenario, we are not retaining any NT boxes, so NTLM is not necessary. In all likelihood, the UNIX servers will be on separate subnets anyway, but this does not directly impact logon performance. A Remote Authentication Dial-in User Service (RADIUS) server performs centralized authentication, authorization, auditing, and accounting (AAAA) of connections for dial-up and virtual private network (VPN) remote access and demand-dial connections. This would not meet the requirements of the scenario.

In Windows 2000, there are two types of groups: security groups and distribution groups. Security groups are used to collect users, computers and other groups into manageable units. When assigning permissions for resources (file shares, printers, and so on), administrators should assign those permissions to a security group rather than to individual users. Distribution groups are designed to be used strictly for e-mail distribution. For Susie's situation, the appropriate response would be to create an Admins group for each OU. This allows the centralized IT staff to control who can administer each OU. Place designated users into the appropriate groups, and then assign access permissions to the group. This approach meets all of our prerequisites. Local administrators have administrative permissions only in their own OU, while the Domain Admins group (or Enterprise Admins, depending on your Active Directory structure) has administrative oversight over the entire organization. Also, if administrative privileges must be revoked from a particular user, simply remove the user from the Admins group.
Since permissions flow from the group, no ACL changes need to be made at the resource level to accommodate this change. One answer used the same approach, but added users from each OU to each Admins group. The problem here is that an administrator from the Marketing OU would have administrative privileges over the HR OU, and so on. This violates our scenario. Creating a single group in which to house all local administrators would also violate the scenario. Creating a new administrator account for each OU, then granting permissions to each new account would technically work, but this is the LEAST effective way to approach this problem. As stated earlier, it is most effective to create appropriate security groups, add users (and other groups, if necessary) to these groups, then assign permissions to groups.

You can map certificates to Windows 2000 user accounts to control access to selected Web resources. Certificate mapping provides for strong security that is based on the Web client ownership of a valid authentication certificate. When certificate mapping is enabled, Internet Information Services (IIS) authenticates users on the basis of mapped certificates, and it grants rights and permissions that are based on the mapped user account. Certificate mapping can be one-to-one or many-to-one. Swanson has three different access scenarios to manage. For the admins, it would be appropriate to apply one-to-one mapping, associating each administrator with a specific user account. This is necessary because the administrators have separate, non-overlapping areas of control. Many-to-one mapping would apply to the company employees. Since all employees require Read access to the site, it is administratively advisable to designate a single user account to match the authorized users to for access permissions. Note that the administrators would gain Read access as well. Each admin would have two certificates.
Since our contractors and business partners are limited to specific areas of the site, it would be advantageous administratively to create a many-to-one map to a different user account, one which only possessed the access required for our scenario. Creating a Web_Admins group probably makes sense from an administrative point of view, but, as far as certificate mapping, the solutions presented are incompatible with our scenario. Using many-to-one mapping to a single account would give each administrator broad control over the entire site. This is the situation we wished to eliminate by stating that each administrator was responsible for only a specific piece of the site. Conversely, using one-to-one mapping for our contractors and business partners would impose an unnecessary administrative burden on poor Swanson. There was no indication that these users had needs different from one another, so there is no reason to create and maintain separate user accounts for them. A single user account would be indicated.

There are two VPN tunneling technologies: L2TP over IPSec and PPTP. Point-to-Point Protocol (PPP) is a serial-line communication protocol commonly used to establish a dial-up connection with an Internet Service Provider (ISP). Microsoft Point-to-Point Encryption (MPPE) is the encryption engine used with PPTP. PPTP (Point-to-Point Tunneling Protocol) offers user authentication and encryption. L2TP over IPSec offers user authentication, mutual computer authentication, encryption, data authentication, and data integrity. Since Tanisha's requirements include 128-bit hashing, a data integrity feature, L2TP over IPSec is the correct answer for our scenario. Both tunneling methods support 128-bit encryption, Microsoft Challenge Handshake Authentication Protocol (MS-CHAP), and packet filtering.

If you are using smart cards for remote access authentication, you must use the EAP-TLS authentication method. With the Extensible Authentication Protocol (EAP), an arbitrary authentication mechanism validates a remote access connection. The exact authentication scheme to be used is negotiated by the remote access client and the authenticator. EAP in Windows 2000 is a set of internal components that provide architectural support in the form of a plug-in module. For successful authentication, both the remote access client and authenticator must have the same EAP authentication module installed. Windows 2000 provides two EAP types: EAP-MD5 CHAP and EAP-TLS. The components for an EAP type must be installed on every remote access client and every authenticator. EAP-Transport Level Security (EAP-TLS) is an EAP type that is used in certificate-based security environments. EAP-TLS is only supported on a remote access server running Windows 2000 that is a member of a Windows 2000 mixed-mode or native-mode domain. A remote access server running stand-alone Windows 2000 does not support EAP-TLS. EAP-TLS provides the strongest authentication and key exchange method.
The other protocols listed provide authentication services, in decreasing levels of strength. Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) is normally used in conjunction with Microsoft Point-to-Point Encryption (MPPE) to encrypt data sent via a PPP or PPTP connection. Windows 2000 adds support for MS-CHAP v2, which addresses some shortcomings in MS-CHAP. Challenge Handshake Authentication Protocol (CHAP) is an industry-standard authentication protocol used by many non-Microsoft clients. Shiva Password Authentication Protocol (SPAP) is a vendor solution for use when connected to Shiva LAN Rover hardware. It is more secure than plaintext, but less secure than CHAP. Finally, Password Authentication Protocol (PAP) uses plaintext passwords, and is the least sophisticated authentication method. Normally, PAP would only be used if the client and the remote access server were unable to negotiate anything better.

In Windows 2000, delegation of administration is more powerful and flexible than it was with it's predecessor, Windows NT 4.0. This is achieved through a combination of organizational units, per-attribute access control, and access control inheritance. Administration can be delegated arbitrarily by granting a set of users the ability to create specific objects, or modify attributes of objects. In our scenario, the appropriate choice was for Carlotta to create four groups in the 3dgraphics OU, and make ACL entries in the child OUs limiting the administrators capabilities to full control over groups, and full control over computers. This solution has several advantages. By creating the groups in the 3dgraphics OU, their span of control is limited to OUs in only this portion of the hierarchy. By creating separate groups to administer groups and computers, she is able to exercise a more granular level of control than she would easily be able to otherwise. One example creates just two groups: BG-admins and EX-admins. We've already established that this is not optimal, but let's look at the remainder of the response. It also gives those groups full control over the OU and all child objects. This is the real issue.
In addition to controlling file access with groups and creating computer accounts, these administrators would now be able to create and modify any object at all, including additional OUs. Too much control. One solution was to put all the admins in a group at the 3dgraphics level, then create ACL entries at the child OUs. This would work, but it would allow the Backgrounds admins to make changes to the Explosions OU, and vice versa. This violates our scenario. Creating the admin groups in the child OU violates our scenario also. In our situation, Carlotta makes all the administrator assignments. The guideline is, if the OU is allowed to set its administrative membership, place the OU's admins group into the OU (did you get all that?). If the OU is not allowed to set its own administrative membership, leave the group outside of the OU.

In our scenario, the only public network is the link between the restaurants and the regional offices. Virtual private networking (VPN) provides a simple answer to the problem of data integrity and confidentiality. A VPN is the extension of a private network that encompasses links over public networks like the Internet. A VPN enables you to send data between two computers in a way that appears to be a point-to-point private link. To emulate a point-to-point link, data is encapsulated, or wrapped, with routing information allowing it to cross the public network to reach its endpoint. The data being sent is encrypted for confidentiality. Packets that are intercepted are unreadable without the encryption keys. The link in which the private data is encapsulated and encrypted is known as a virtual private network (VPN) connection. Internet Protocol security (IPSec) is a framework of open standards for ensuring private, secure communications over Internet Protocol (IP) networks, through the use of cryptographic security services. IPSec is a key component to an integrated network security solution. Establishing an IPSec policy between the regional offices and Headquarters is an excellent idea, but our scenario specifically required communications security only over public networks, i.e. the Internet. Encrypting File System (EFS) is used to provide security for data on disk, but does nothing to provide communication security.

An auditing policy specifies categories of security-related events that you want to track. When Windows 2000 is first installed, auditing is disabled by default. By enabling various auditing event categories, you can implement an auditing policy that suits your security needs. If you choose to audit access to objects as part of your audit policy, you must turn on either the audit directory service access category (for auditing objects on a domain controller), or the audit object access category (for auditing objects on a member server). Once you have turned on the correct object access category, you can use each individual object's Properties to specify whether to audit successes or failures for the permissions granted to each group or user. In our scenario, Toshiro needs to audit file and folder access on his application (member) server.
So, he first needs to enable the Audit Object Access setting. To audit files and folders, you must be logged on as a member of the Administrators group or have been granted the Manage auditing and security log right in Group Policy. Since Toshiro is a member of the Administrators group, he does not need to be assigned the Manage auditing and security log right. There is no requirement that he be in the Server Operators group, especially if he is already in the Administrators group. Files and folders must be on an NTFS volume for auditing to be available. In our scenario, the Auditing tab was visible, clearly indicating that the folder was on an NTFS volume, not a FAT32 volume.

Kerberos will be used on the domain and for Buyers, major vendors, and employees at headquarters in New York. Web customers will use certificate-based authentication, not SSL (Secure Sockets Layer). Layer two protocol was specified in the recent security definition. Smart cards for authentication were not specified in the scenario. NTLM authentication may be needed if vendors are using pre-Windows 2000 machines. NTLM is the default authentication of NT systems. Digest authentication, where two share a secret that does not cross the network because it employs a hash algorithm, is not required. Web customers are using certificates. 4.5.1 Designing a Windows 2000 Security Solution. Design an authentication strategy. Select authentication methods. Methods include certificate-based authentication, Kerberos authentication, clear-text passwords, digest authentication, smart cards, NTLM, RADIUS, and SSL.

Zoltan's big problem is allowing Research and Development to communicate securely using the company's intranet as an intermediary. The best choice provided is the one which creates a VPN (Virtual Private Network) connection router-to-router. In this scenario, the two networks are connected to the common intranet with computers that can act as VPN clients or VPN servers. When the VPN connection is established, users on computers on either network can exchange sensitive data across the corporate intranet, exposing only encrypted data to anyone who should attempt a network attack on the transmission. Scheduling communication at only specific times does not address the issue of securing the data. Creating the proper level of access control is necessary, but, again, doesn't address the issue of sending secure communication. Denying access to a given resource doesn't prevent a malicious user from mounting network attacks to attempt to gain access to sensitive data flowing across the intranet. Kerberos authentication is the standard authentication mechanism for Windows 2000. Authentication only proves who you are, it does not provide the encryption services this scenario demands.

Because the system is a webserver, it needs to be extra secure. On their website, Microsoft has a series of excellent templates, documents, and tools to use for locking down an IIS server. The most important answers above are ensuring that no one can access the CD-ROM from across the network, requiring strong passwords, and renaming the administrator account. Everyone that works with Windows 2000 knows the name of the administrator account. All they need to do is guess the password to gain full control of the system. Renaming the account makes this process much harder. By requiring stronger passwords, you decrease the likelihood that passwords can be guessed. You also increase the time a dictionary type attack takes as it must go through many more combinations before successfully gaining access. Finally, there is no reason to allow CD-ROM access from across the network. If you accidentally leave a CD in the drive with utilities on it, or someone is able to get their own CD into your system, this can have disastrous consequences.There is no reason to use account lockout with the anonymous account because users are automatically logged in using it if they do not have a valid username and password. Likewise, because it is not necessary to secure the account and users never know the password, there is no reason to require password changes for it.

The company is obviously willing to try new approaches to business, otherwise they would not have attempted to start a new Internet venture. However, they also went about it in a calculating way, keeping it separate from their main company but still very much accountable to it. This suggests that the company is not willing to risk everything for growth. Because of these and other facts learned from discussions with the company, the best answer is that the company is willing to invest in new ideas that allow it to grow.

Setting the Account Lockout Duration to 0 minutes forces Administrative action, so the secondary objectives have not been met. Also, your primary objective is to perform the necessary changes so that they are universal throughout the enterprise. By linking the policy to usa.northamerica.gunderville.com, you limit the changes to only that domain, not the entire enterprise.

The Outlook Web Access server can authenticate users with one or more types of security. These choices are: Anonymous, Basic (Clear Text), Basic (Clear Text) over Secure Sockets Layer (SSL), and Windows NT Challenge/Response (NTLM). Of the available choices, Basic (Clear Text) with SSL is correct. Users must provide a valid Windows NT user account name and password to use Outlook Web Access. Both the user name and password are transmitted as encrypted information over the network to the IIS/Outlook Web Access server. This method has several advantages: -- Most browsers support Basic over SSL authentication. -- Users can access all Microsoft Exchange Server resources. -- Basic over SSL authentication is very secure. The other available choice, NTLM, is not correct. NTLM requires all resources the user wants to use reside on the same server as IIS and Outlook Web Access. NTLM authentication is not supported if IIS/Outlook Web Access and Microsoft Exchange Server are located on different computers, as they are in our scenario. Kerberos authentication, while standard with Windows 2000, is not supported with Outlook Web Access. Encrypted text is not one of the modes available through Basic authentication. SSL provides the encryption -- it would not be necessary or desirable to encrypt something that was already encrypted.

Kerberos v5 is a mature, industry-standard authentication solution, providing a high degree of interoperability between Windows 2000 and non-Windows 2000 systems. An individual Kerberos deployment is referred to as a 'realm'. A Kerberos realm is conceptually similar to a Windows domain. In a Kerberos realm, a Key Distribution Center (KDC) provides the authentication services. There are four basic authentication scenarios associated with Kerberos: -- Windows client and Windows KDC -- Windows client and non-Windows KDC -- non-Windows client and Windows KDC and -- non-Windows client and non-Windows KDC
Each of the four authentication scenarios listed above have implementation issues depending on whether you are accessing Windows 2000 resources or non-Windows 2000 resources. In our scenario, Rajneesh has a Windows client/non-Windows KDC environment. Since the principals in the Kerberos realm do not contain the group associations that are used by Windows 2000 for access control, establish a mapping between the user account in the Kerberos realm and a local user account on the Windows computer. Service accounts and one-way trusts are associated with Active Directory and Windows 2000 domains, which are not supported by our scenario. Mapping, as described above, makes it unnecessary to create new Windows 2000 accounts. Mapping allows us to use the existing Windows account as an alias for one or more realm accounts.

When you implement IP Security, you must strike a balance between ease of information retrieval for legitimate users and protecting sensitive information from unauthorized access. To help administrators do just this, three security levels have been defined to provide a general basis for a security plan. These levels are Minimal Security, Standard Security, and High Security. Minimal Security is appropriate where no exchange of sensitive data takes place. In this case, IPSec is not even enabled Our scenario requires more security than this. Standard Security is based on two predefined IPSec policies: Client (Respond Only) and Server (Request Security). These policies secure necessary data, but do not necessarily provide the highest level of security. This security level does not quite meet Raoul's security standards. High Security is based on the Secure Server (Require Security) IPSec policy. This policy includes strong confidentiality and integrity algorithms, Perfect Forward Secrecy, key lifetimes and limits, and strong Diffie-Hellman Groups. Unsecured communication is blocked. This level of security is necessary to meet Raoul's needs. Granted, it would impose additional administrative overhead and may negatively impact network performance, but security is the critical issue in this scenario. If none of the predefined policies meet your needs, you can create your own custom policies. Raoul is free to create custom policies to fine-tune his needs, but based on the scenario, the High Security level conforms to the guidelines presented.

Simple Network Management Protocol (SNMP) service provides the ability to monitor and communicate status information between a variety of hosts. SNMP performs its management services by using a distributed architecture of management systems and agents. Two components are required to use SNMP -- an SNMP management system and an SNMP agent. The SNMP management system can request a variety of information from managed computers (SNMP agents). The SNMP service provides a basic form of security through the use of community names and authentication traps. You can restrict SNMP communications for the agent and allow it to communicate with only a prescribed list of SNMP management systems. To add the security our scenario dictates, you would edit the existing IP Security policy to add two sets of filter specifications to the appropriate IP filter list (normally something like 'All IP Traffic'). For typical SNMP traffic, you would specify port 161 for both TCP and UDP protocols. SNMP uses port 161 for general messages and port 162 for trap messages. The Filter Properties dialog box does not list SNMP as an option in the drop-down list. The SNMP Service Properties dialog box is used to configure the SNMP service, not modify IP Security. IP Security does NOT encrypt the SNMP protocol by default.

NTFS provides security at the file and folder levels, which allows you to control access down to the file level. When assigning Read-level NTFS access to a user at a folder, this limits his access to files in the folder and subfolders at the Read-level via inheritance.

Windows 2000 supports disk compression, which allows you to compress folders, subfolders, and files to increase the amount of file storage on the hard drive or in certain instances, removable media, but it does cause a system performance degradation that slightly slows down access to the files in most cases.

Windows 2000 supports native encryption, which allows file owners (or those with full control access to the data) to encrypt and decrypt folders, subfolders, and files automatically by the operating system through simply accessing the data. After a file has been encrypted, a user needs only to access it, for example, by opening and editing a document, to decrypt it for use. Closing access to the file encrypts it once again.

[B: There is no way under Windows 2000 to set security at the file and folder levels that allows you to control access down to the Active Directory level because Active Directory is a different part of the Windows 2000 system structure than the file system.]

[C: Windows 2000 supports disk compression, which allows you to compress folders, subfolders, and files to increase the amount of file storage on the hard drive or in certain instances, such as removable media, but it does cause a system performance degradation that slightly slows down access to the files in most cases.]

[F: Native encryption allows all file owners (or those with Full Control access to the data) to encrypt and decrypt folders, subfolders, and files automatically by the operating system through simply accessing the data. After a file has been encrypted, a user needs only to access it, for example, by opening and editing a document, to decrypt it for use. Closing access to the file encrypts it once again.]

On a clean installation of Windows 2000 or on an upgrade of a Windows 9x system where NTFS is used and the defltwk.inf template is run, Power Users have Modify access of the HKEY_LOCAL_MACHINE\Software key and subkey in the registry, by default.

[A: Power Users have Read permission on the HKEY_LOCAL_MACHINE\System key and subkey, by default.]

[B: Power users have Read permission through the Everyone group on the HKEY_LOCAL_MACHINE\Hardware key and subkey, by default.]

[C: Power users have no permissions set for the HKEY_LOCAL_MACHINE\Security key and subkey, by default. They are implicitly denied access because no access of any type (allowed or restricted) has been set.]

[D: Power Users have the Full Control permission set for the HKEY_CURRENT_USER key, by default.]

Use only Windows 2000's version of NTFS on the upgraded terminal servers. In a multi-user environment, users can see all subdirectories, just like an interactive user on a Windows 9x system. The Basicsv.inf will put the upgraded NT 4.0 servers on a security level with a clean-install Windows 2000 server. Securews.inf security template is for workstations and servers who need incremental security templates for a more security than the basic Windows 2000 security template provides. The Hisecws.inf security template is for workstations and servers that need a highly secure configuration. However, Hisecws.inf can only be used in a native mode and OhJuice's Active Directory is in mixed mode. Avoid putting terminal server on domain controllers. Instead make them member servers. Otherwise, the terminal servers will be adversely affected when user rights policies are configured for the domain controllers of the domain. A terminal services user must have local logon rights to the terminal server that is running in Application Sharing mode. This is done with the Terminal Services Configuration tool.
The Client Connection Manager is used to specify what application(s) a user is allowed to run but does not provide stringent security measures for the servers. It is incorrect to put the UsrLogon.cmd file in the application's folder on the terminal server. The UsrLogon.cmd file is stored in the System 32 directory of the server. This batch file contains the application's scripts. It is incorrect to open the port 443 for RDP connections between client and terminal server. The port to keep open if a firewall is in use is 3389 for RDP connections. The RDP protocol provides users who have been granted access to be a member of the built-in Terminal Services Users local group. It allows them to log on to terminal services. Opening port 443 is necessary on a Proxy Server if the client's browser must pass through a firewall. 1.4 Analyzing Business Requirements. Analyze business and security requirements for the end user.

For other users in the domain to be able to view the vacation requests using URL://WebOne/Vacation, you must set up a virtual directory to the network share. The virtual directory should use the alias Vacation. You would also need to configure the appropriate NTFS permission on the folder.

Assigning Read and Directory browsing permissions allows the users read-only access and they would also be able to see contents of the folder.

Upgraded Windows 9x systems automatically receive the defltwk.inf. during installation and do not need to have it reapplied.

On Windows 9x systems, you should check that the local users from the Windows 98 system become local Administrators on the upgraded system and, in most cases, would need to make local changes to the account database.

Systems upgraded from Windows NT 4.0 to Windows 2000 maintain the settings as enabled from the Windows NT environment. You can apply the Basic template (basicwk.inf.) so that the default Windows 2000 Server security settings are applied to the upgraded NT 4 server systems. Upgraded Windows 9x systems automatically receive the defltwk.inf, which is the necessary template for this question, during installation.

The Windows NT 4.0 Compatible Security (compatws.inf) template weakens default security installed by defltwk.inf so that applications that do not properly handle the security settings running in the Windows 2000 space can function.

Ocfiles.inf deals with optional component file security on Windows 2000 systems.

To check the entire range of machines on the 192 subnet in verbose mode and output the information to a named file, you must use the following switches when running HFNetChk:

-v for verbose
-r for IP address range
-f for the output file

[B: Using this syntax, without including the -v switch, will not generate the file in verbose mode.]

[C & D: Using this syntax does not generate all of the listed messages in the example. The -s switch can suppress Note and Warning messages. The -s 1 switch suppresses Note messages only; the -s 2 switch suppresses both Note and Warning messages. The default is to show all messages.]

[E: The -s 1 switch prevents generation of Note messages. The example shows both Note and Warning messages. Without including the -v switch, the file will not be generated in verbose mode.]

The Server service, Remote Registry service, and File & Print Sharing must be installed and enabled to perform remote MBSA scans on systems.

[B: The Workstation service does not influence your ability to perform remote MBSA scans on systems.]

[C: TFTP does not influence your ability to perform remote MBSA scans on systems.]

[F: The DNS Client does not influence your ability to perform remote MBSA scans on systems.]

SUS can be used to deploy Windows Critical Updates, Windows Critical Security Updates, and Security Roll-up patches automatically to clients using Automatic Updates. It cannot be used to deploy service packs.

[A & B: SUS can be used to deploy Windows Critical Updates, Windows Critical Security Updates, and Security Roll-up patches automatically to clients using Automatic Updates. It cannot be used to deploy service packs.]

[D: SUS cannot be used to deploy service packs.]

[E: SUS can be used to deploy Windows Critical Updates, Windows Critical Security Updates, and Security Roll-up patches automatically to clients using Automatic Updates.]

The Automatic Update component is included on the systems running Windows 2000 Professional SP3 and Windows XP Professional SP1. Lower versions of those operating systems would need to have the client manually installed on them by downloading it from Microsoft.

[A: The Automatic Update component is included on the systems running Windows 2000 Professional SP3 and Windows XP Professional SP1. Lower versions of those operating systems would need to have the client manually installed on them by downloading it from Microsoft.]

[D: The Automatic Update component is included on the systems running Windows 2000 Professional SP3 and Windows XP Professional SP1.]

[E: The Automatic Update component needs to be installed manually by downloading it from Microsoft. It is not available in the Resource Kit.]

[F: The Automatic Update component is included on systems running Windows XP Professional SP1 and does not need to be installed manually.]

All local hardware and services that are not specifically required to support hosting of the e-business services on the Web servers or Software Update Services have been disabled. This includes USB ports, floppy drives, CD-ROM drives, and the like. The only way to get this update on the servers is to enable the CD-ROM drives and install the update. Once finished, the CD-ROM drives could then be disabled again.

[A: This is an option but you cannot perform it. You have delegated Server Operators rights on the IIS systems, not the SUS system; therefore, you cannot log on to the SUS system to perform this action.]

[B: There is no way to FTP into the DMZ. Even if the firewall allowed it, the servers themselves are only responding to Web requests on ports 80 and 443. They don't respond to port 20/21 calls.]

[C: All local hardware and services that are not specifically required to support hosting of the e-business services on the Web servers or Software Update Services have been disabled. This includes USB ports, floppy drives, CD-ROM drives, and the like. Because you have not specified that you would enable the ports beforehand, this update will not be possible.]

[E: There are two things wrong with this option. First, the Web servers cannot go out to the Internet. With all the ports locked, the servers cannot use high ports to allow return connections from the Internet because all local hardware and services that are not specifically required to support hosting of the e-business services on the Web servers or Software Update Services have been disabled. Also, even if for some fluke reason you could establish a connection, the maximum permissions you could log on with would be local Server Operators rights. You would need to log on as a local administrator to apply the Critical Security Update.]

The Microsoft L2TP/IPSec VPN Client allows Windows 98, Windows ME, and Windows NT Workstation 4.0 systems to use L2TP/IPSec solutions because they don't come with it by default. The Server (Request Security) policy allows systems to accept unsecured traffic after an attempt to secure additional communications by requesting security from the original sender fails. This is often used in situations where you would like to secure as much data traffic as possible but not deny connection attempts from systems that cannot use IPSec. Because it has not been explicitly stated that the Microsoft L2TP/IPSec VPN Client has been installed on the Windows 98 and NT clients, you should assume that it hasn't and to use the most secure policy for your network so that communications are always secure and always available. Therefore, this is the best answer for this question.

[B: There is no such predefined template as Server (Respond Only).]

[C: Client (Respond Only) is a policy that enables client systems to respond to requests for secured communications and is normally used one way, from the clients, with the Server (Request Security) policy in use on the server side.]

[D: The Secure Server (Require Security) is the most secure default option; however, if the Microsoft L2TP/IPSec VPN Client has not been installed on the Windows 98 and Windows NT clients, they will not be able to properly authenticate, thus threatening the "always available" part of the question.]

Secure Hash Algorithm (SHA) is a high-security authentication encryption method that uses a 160-bit key. It cannot be used to encrypt data. Message Digest 5 (MD5) is the standard authentication encryption method that uses a 128-bit key.

[C: 56-bit DES (Data Encryption Standard) uses a single 56-bit key as part of its data encryption process and is often used for smaller security concerns where system overhead is an issue.]

[D: 40-bit DES (Data Encryption Standard) uses a single 40-bit key as part of its data encryption process and is normally only utilized in certain export situations. In addition, the key is no longer considered very secure because of the high processing power of most desktop systems available today.]

[E: 3DES (Data Encryption Standard), most often referred to as Triple DES, uses three 56-bit keys and processes each data block three times, using a unique key each time as part of its data encryption process. It is used often in high security situations.]

Encapsulating Security Payload (ESP) provides security for both the IP header and the data payload carried in the packet by digitally signing the packet and it does encrypt data; however, it does not normally encrypt the entire packet unless it is being tunneled. Therefore, the IP header is not encrypted. The Microsoft L2TP/IPSec VPN Client would need to be downloaded so that computers running Windows 98, Windows Me, or Windows NT Workstation 4.0 will be able to use IPSec and L2TP.

[A: Authentication Header (AH) provides security for both the IP header and the data payload carried in the packet by digitally signing the packet but it does not provide encryption for the data.]

[B: Message Digest 5 (MD5) is the standard authentication encryption method that uses a 128-bit key. It does not encrypt IP headers and data.]

[C: 3DES (Triple Data Encryption Standard), most often referred to as Triple DES, uses three 56-bit keys and processes each data block three times, using a unique key each time as part of its data encryption process and is often used in high security situations. It does not encrypt IP headers. The Microsoft L2TP/IPSec VPN Client would need to be downloaded so that computers running Windows 98, Windows Me, or Windows NT Workstation 4.0 will be able to use IPSec and Layer Two Tunneling Protocol (L2TP).]

[E: 3DES uses three 56-bit keys and processes each data block three times, using a unique key each time as part of its data encryption process and is often used in high security situations. It does not encrypt IP headers. The Microsoft L2TP/IPSec VPN Client would need to be downloaded so that computers running Windows 98, Windows Me, or Windows NT Workstation 4.0 will be able to use IPSec and L2TP.]

[F: ESP provides security for both the IP header and the data payload carried in the packet by digitally signing the packet and it does encrypt data; however, it does not normally encrypt the entire packet unless it is being tunneled. Therefore, the IP header is not encrypted. The Microsoft L2TP/IPSec VPN Client would need to be downloaded so that computers running Windows 98, Windows Me, or Windows NT Workstation 4.0 will be able to use IPSec and L2TP.]

Public Key authentication can be used by clients from different Active Directory forests via L2TP/IPSec VPN solutions.

[A: All computers using Kerberos authentication need to be members of the same Active Directory forest.]

[C: Preshared keys can be used, but they have a high administrative overhead and are difficult to use at best. This type of solution is normally used only in very small environments.]

[D: ESP (Encapsulating Security Payload) is not an authentication method. It is used to digitally sign packets and encrypt data.]

[E: 3DES (Data Encryption Standard), most often referred to as Triple DES, uses three 56-bit keys and processes each data block three times, using a unique key each time as part of its data encryption process. It is often used in high security situations and is not an authentication method.]

Netdiag can resolve which filters and authentication protocols are in use for the IPSec Security Association.

[A: PING can be used to verify network connectivity between the two hosts; it cannot be used to resolve which filters and authentication protocols are in use.]

[B: IPSec Monitor can be used to determine whether a Security Association is established between your computer and the target computer. It can also be used to determine which protocol is protected with IPSec. It cannot be used to resolve which filters and authentication protocols are in use.]

[C: Preshared keys can be used to determine whether the filters are working correctly but cannot be used to resolve which filters are used. The keys also cannot show which authentication protocols are in use.]

[E: The SMS version of NETMON can be used to determine whether the ISAKMP process is taking place as well as allow you to look for AH and ESP protocol packets, which would verify if the ISAKMP process was successful. However, it cannot be used to resolve which filters and authentication protocols are in use.]

According to the current standards you can use 64-bit and 128-bit encryption on a wireless solution. They are often referred to as 40 bit and 104 bit, or 40/24 and 104/24, respectively, because the first 24 bits of each WEP key is an Initialization Vector (IV).

Windows XP Professional natively supports IEEE 802.1X authentication without any additional add-ons. 802.1X Authentication Client add-on installed Windows 2000 Professional does not natively support IEEE 802.1X authentication; the Microsoft 802.1X Authentication Client add-on needs to be downloaded from the Microsoft Web site and installed.

[B: Windows XP Professional natively supports IEEE 802.1X authentication without any additional add-ons.]

[C: Windows 2000 Professional does not natively support IEEE 802.1X authentication; the Microsoft 802.1X Authentication Client add-on needs to be downloaded from the Microsoft Web site and installed.]

DNS is required to install the enterprise subordinate CA.
Active Directory is required to install the enterprise subordinate CA.

WINS is not required to install the enterprise subordinate CA.
DHCP is not required to install the enterprise subordinate CA.

Web-Based Enrollment starts when a client submits a certificate via HTTP to Microsoft Certificate Services. The management piece of this is accessed through the Certificate Services Enrollment Page, which is available from the Certificate Services Administrative Tools Web Page, http:///certsrv/ default.asp, where is the name of your certificate server.
The Automated Enrollment process depends on certificate types in use and auto-enrollment objects and is integrated with the Group Policy use. This method allows settings to be defined on a given site, domain, or OU and can be set on the computer or user portion of the policy.
The Microsoft Management console can be used along with the Certificate snap-in as another way to handle Certificate Enrollments in your environment.

[D: There is no such certificate enrollment process. There is the automated enrollment process that depends on certificate types in use and auto-enrollment objects and is integrated with the Group Policy use. This method allows settings to be defined on a given site, domain, or OU and can be set on the computer or user portion of the policy.]

Rivest's Cipher v2 (RC2) is a secret-key block encryption algorithm that uses 64-bit input and output blocks. The key size can be varied up to 128 bits in length and is optimized for speed and encrypts messages with less system overhead than DES or 3DES.
Data Encryption Standard (DES) takes 64-bit blocks of plaintext and applies a 56-bit key to each block of plaintext using the recipient's public key. The encrypted package is decrypted by the recipient by using their private key.
3DES, usually refered to as Triple DES, increases the strength of (standard) DES by using an encrypt-decrypt-encrypt process that uses three keys. The 64-bit plaintext message block is first encrypted with the first key, then the encrypted result is decrypted using a second key, and then encrypted using a third key. The resulting encryption strength is 168 bits (3 x 56-bits). This process requires more system overhead than RC2 or DES.

[B: Secure Hash Algorithm (SHA) is a high-security authentication encryption method that uses a 160-bit key. It cannot be used to encrypt data.]

The private key is kept confidential on the e-commerce site, which uses the private key to view the data sent from the end user who has used the public key. The public key is freely given to all potential correspondents so they can send their credit card data over the Internet in an encrypted format.

NTLM version 2 uses 128-bit encryption, which provides enough security against brute-force attacks to make them impractical. It is the only version of the possible answer choices that allows maximum security and all of the clients to log on.

NTLM version 2 is enabled for Windows NT 4 Service Pack 4 and later and Windows 9x can use it if the Directory Services client is installed.

[A: LAN Manager is not a very secure authentication method and is generally only used when connecting to shares on Windows for Workgroups, Windows 9x, and Windows Me.]

[B: NTLM version 1 was used in versions of Windows NT 4 prior to Service Pack 3 and was replaced with NTLM version 2. NTLM version 1 is more secure than LAN Manager but it is not as secure as other methods listed here.]

[D: Kerberos is the most secure method of all those listed here because clients contact a domain controller to retrieve a session ticket, which they can then use to prove that they can log on throughout the domain. However, Kerberos authentication is restricted to Windows 2000, Windows XP, and Windows Server 2003 systems; therefore, it is an unacceptable choice because there are Windows NT 4 systems in the scenario.]

Hierarchical realm support for cross-platform trust between the Windows 2000 and MIT Kerberos realms is not available. However, you can have transitive trusts between Windows 2000 domains in the domain tree.

Unix clients and servers can use this type of authentication encryption.

[A: Hierarchical realm support for cross-platform trust between the Windows 2000 and MIT Kerberos realms is not available. You can have transitive trusts between Windows 2000 domains in the domain tree.]

[C: The Windows 2000 Key Distribution Center does not support post-dated tickets.]

Encapsulating Security Payload (ESP) encrypts packets and can run it tunnel mode where all packets from one specific location (from any client) to another specific location (to any client) are encrypted, regardless of the type (HTTP, FTP, etc). It can also run in transport mode where just that particular type of traffic is encrypted and just between two particular systems.

Host-to-host (H2H) is used between two IPSec IPSec-aware systems and is the best choice for this scenario. The remote client systems may be from any number of different partners and may be to any number of different systems in the extranet.

[B: Encapsulating Security Payload (ESP) encrypts packets and can run it tunnel mode where all packets from one specific location (from any client) to another specific location (to any client) are encrypted, regardless of the type (HTTP, FTP, etc). It can also run in transport mode where just that particular type of traffic is encrypted and just between two particular systems.]

[D: Host-to-gateway (H2G) IPSec configurations provide a secure connection between different hosts and a network gateway to a private network, but it is not a better option than Host-to-host (H2H). If there was only one way into the extranet (through one external point, which might also encompass regular DMZ traffic for instance), it might cause and unnecessary load on network systems.]

[E: A Gateway-to-gateway (G2G) setup allows for secure connections between border gateways to create a secure wide area network (WAN) connection over the Internet. This type of solution is best for two separate locations of the same business who wish to securely use the internet Internet for secure connections, not multiple clients from different companies making connections to an extranet.]

SSL encrypts the content and the data. Certificates are required for the server and client's browser to set up an SSL connection over which encrypted information can be sent. The certificate-based SSL features in IIS consist of a server certificate, an optional client certificate, and various digital keys.

Certificates are digital identification documents that allow both servers and clients to authenticate each other. Server certificates usually contain information about your company and the organization that issued the certificate, if it was an external authority.

[A: Digest authentication cannot be easily used (if at all) between partner systems and the standalone Windows 2000 IIS Server. Also, because the server is a stand-alone server, integrated logon would not be available.]

[C: Integrated Windows authentication cannot be easily used (if at all) between partner systems and the stand alone Windows 2000 IIS Server.]

[D: Enabling the Encrypting File System (EFS) is not going ensure that all information transmitted between WebOne and each business partner's computers is encrypted. EFS encrypts local data.]

[E: Configuring the new Web site folder to use the NTFS security is only going to allow you to set the proper permission levels on files and folders; it will do nothing to ensure that all information transmitted between WebOne and each business partner's computers is encrypted.]

The Microsoft Challenge Handshake Authentication Protocol version 1 (MS-CHAP v1) works a lot like CHAP does because the server sends a challenge to the remote client that consists of a session ID and an arbitrary challenge string. The remote client must return the user name and a Message Digest 4 (MD4) hash of the challenge string, the session ID, and the MD4-hashed password.

MS-CHAP v1 only requires the MD4 hash of the password to validate the challenge response. It does not need it available in plaintext as in CHAP. In Windows 2000, user passwords are stored as an MD4 hash and in a reversibly encrypted form. When CHAP is used, the remote access server decrypts the reversibly encrypted password to validate the remote access client's response.

Because there are Windows 98 systems on the network, other, higher functioning authentication protocols cannot be used; therefore, this answer is correct.

[A: Password Authentication Protocol (PAP) sends passwords as clear text and offers no security at all.]

[B: Shiva Password Authentication Protocol (SPAP) is a hardware solution, now owned by Intel, used to support Shiva LAN Rover devices. It supports some encryption of passwords; however, it is vulnerable to replay attacks (where hackers capture encrypted passwords and re-use them in encrypted form) and limited to use in the supported hardware.]

[C: Challenge Handshake Authentication Protocol (CHAP) uses the Message Digest 5 (MD5) one-way encryption scheme to hash the response to a challenge issued by the remote access server to allow authentication with encrypted passwords. The destination server sends a challenge to the client, and the client uses the data from the challenge to calculate a one-way encrypted value, or hash, from the user name and password that can be used to authenticate the user without sending the actual password across the network. This is best suited for mixed networks where there are non-Microsoft clients in use. One drawback of CHAP is that the plain text version of the password must be available to validate the challenge response.]

[E: Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2) is the Windows 2000 implementation of MS-CHAP. It does not support earlier Windows client versions such as Windows NT 4 and Windows 9x. Whereas you should use MS-CHAP v2 whenever possible, it is not the correct answer to this question because of the legacy systems in use.]

[F: Extensible Authentication Protocol (EAP) is an authentication protocol that can be extended with additional authentication methods such as smart cards, biometrics, and certificate-based authentication.]

Where NAT is used in VPN tunnels that use L2TP there are issues because IPSec can encrypt the IP header and NAT cannot perform address translation because it cannot read the source and/or the destination address to perform the translation.

[A: BAP is not the reason this has failed. VPN tunnels that use L2TP are not supported with NAT because IPSec can encrypt the IP header and NAT cannot perform address translation.]

[B: The RADIUS absence is not the issue. VPN tunnels that use L2TP are not supported with NAT because IPSec can encrypt the IP header and NAT cannot perform address translation.]

[C: CHAP uses the Message Digest 5 (MD5) one-way encryption scheme to hash the response to a challenge issued by the remote access server to allow authentication with encrypted passwords. This has nothing to do with encrypting the data. The issue here is that VPN tunnels that use L2TP are not supported with NAT because IPSec can encrypt the IP header and NAT cannot perform address translation.]

[E: PPTP using MPPE might work because the IP header is not encrypted but you cannot use MPPE with IPSec. Even if you could, you still have the issue of NAT failing because of IP address mapping issues.]

The template.inf file (.inf) is used to specify the installation information for your service profiles.

[B: The template.cms file is used to specify the configuration of the phone book and most of the other functions of your service profiles. Any additional customization required is done by editing the .cms file for that particular service profile.]

[C: The template.cmp file contains information specified by the specific user. It is not used to specify the installation information for your service profiles themselves.]

[D: The template.sed file contains instructions for building a self-extracting executable file for your service profiles.]

The main properties of L2TP are that it can be used on multiple network types, such as IP, Frame Relay, X.25, or ATM Based. It also supports header compression and tunnel authentication and uses IPSec for encryption.

Certificate Services are the core operating system service that allows businesses to act as their own CAs and to issue and manage digital certificates. The certificates can also be published on Web pages or distributed on smart cards, disks, or compact discs. Certificate revocation lists are published at URLs.

Active Directory is used as the publication service for PKI. Certificate publication makes certificates and certificate revocation lists publicly available within an organization.

PKI-enabled applications use PKI for encryption and authentication. These include Microsoft Internet Explorer, Microsoft Money, Microsoft Internet Information Services (IIS), Microsoft Outlook, Microsoft Outlook Express, and third-party applications.

[B: DNS is not one of the primary components of PKI. Although it is a requirement for Active Directory (which itself is one of the three), it is not a correct answer.]

[E: Group Policy is not one of the primary components of PKI.]

The X.509 version 3 standard defines the format and content of digital certificates.

[A: IPSec deals with encryption for network sessions using the Internet Protocol (IP).]

[B: SGC provides SSL-like security without export complications.]

[D: The PKIX standard defines the format and behavior for public-key exchange and distribution.]

[E: The CRL version 2 standard defines the format and content of Certificate Revocation Lists.]

The default key length using the Microsoft Base Cryptographic Provider is 512 bits. The recommended key length for a root CA should be at least 2048 bits.

Certification Authorities can use Active Directory, Web pages, public folders, and e-mail to publish CRLs so that the information is kept up to date.

SSL uses certificates so that systems across the internet can have secure communication. One example of this is SSL connections for e-commerce transactions.

S/MIME uses certificates to encrypt e-mail messages by using a public and private key exchange.

A digital signature is involved in the signing of Windows drivers (code). The CodeSigning template exists for this purpose.

[C: PPTP does not use a certificate-based solution for encryption. Instead it uses Microsoft Point-to-Point Encryption (MPPE).]

Machine is issued specifically to computers for client/server authentication.

Domain Controller is issued specifically to computers for client/server authentication.

[B: OfflineRouter is used for client authentication. It can be issued to computers AND routers, not just computers.]

[C: SmartcardLogon is used for client authentication only. It can be issued to a user account.]

[E: MachineEnrollmentAgent is used to request certificates, not client or client/server authentication.]

You can add a new Encrypted Data Recovery Agent as well as set up Automatic Certificate Requests in the security settings section of a GPO.

[B: You cannot set a predefined level of encryption in the security settings section of a GPO.]

[D: You cannot set publishing rules for certificates in Active Directory in the security setting section of a GPO.]

[E: You cannot set publishing rules for certificates for Third Party Trustees in the security settings section of a GPO.]

The default installation path is :\WINNT\System32\CertLog. On most systems this would be C:\WINNT\System32\CertLog.