| Windows Server 2003, when combined with a Windows XP Professional client computer in a Windows Server 2003 Active Directory “based network, features several enhancements and improvements to Certificate Services. -
Version 2 certificate templates ” Version 2 templates extend the range of properties that you can configure from those provided in Version 1 templates. You now can create new certificate templates (an option sorely lacking from Windows 2000), copy existing certificate templates, and supercede certificate templates that are already in use. You need a Window Advanced Server 2003 functioning as the Enterprise Root CA. -
Integrated and enhanced key recovery ” Windows 2000 Server relied on a Data Recovery Agent (DRA) to decrypt files following the loss or damage of an encryption key. Additionally, the Exchange 2000 Server Key Management Service (KMS) ran on top of Windows 2000 Certificate Services and did not fully integrate. Windows Server 2003 allows the archival and recovery of private keys and allows the administrator to access data encrypted with a lost or damaged private key. Now Key Recovery Agents (KRAs) are used to recover lost or damaged private keys across Windows Server 2003 and Exchange Server 2003. -
Delta Certificate Revocation Lists ” Windows Server 2003 supports RFC 2459 “compliant Delta Certificate Revocation Lists (CRLs) that contain only the certificates whose status has changed since the last full (base) CRL was compiled. This results in a much smaller CRL, which can be more frequently published with no adverse effects on the network or client computers. Additionally, this provides more accurate CRLs due to reduced latency periods. In Windows 2000, CRLs were typically published once per week (the default setting). Delta CRLs allow you to publish one or more times daily as required. -
CA qualified subordination ” Another part of RFC 2459, qualified subordination allows a parent CA to granularly configure what a subordinate CA is allowed to do. Examples include preventing the subordinate CA from signing a certificate for another subordinate CA. -
Common Criteria role separation ” By separating common CA- related tasks between several different levels of administration, you can meet Common Criteria requirements and enhance task delegation. Because roles are separated, no one individual should possess the ability to compromise the services or operation of the CA. -
Enhanced auditing ” Windows Server 2003 provides for more detailed auditing of Certificate Services by adding two new types of events: access check and system events. System events come from seven critical areas: CA service, backup and restoration, certificate requests , certificate revocations, CA security, key archival and key recovery, and CA configuration. A Windows Server 2003 Enterprise CA has five key characteristics: -
The CA server may run on any Windows Server 2003 server in the domain. You should plan for activity, network load, and physical placement of the server for best implementation. -
Because the CA name is integrated into the certificates it assigns , the name of the server should be determined before implementing CA services. -
The Enterprise CA Authority is integrated into the Active Directory. -
When you've installed an Enterprise CA, a policy module is created. An administrator can edit the policy. -
Because the CA is crucial for the successful implementation of the PKI, it must have a fault-tolerance scheme and a schedule of regular secure backups . A typical Standalone CA has these key characteristics: -
It doesn't require Active Directory interaction. -
It can be used with extranets. -
It doesn't verify the requests for certificates. (All requests are pending until an administrator approves them.) -
Users requesting a certificate from a Standalone CA must supply all user account information. This information is not required within an Enterprise CA because the user is recognized by the logon account in the Active Directory. -
No certificate templates are used. -
Windows Sever 2003 logon credential certificates are not stored on smart cards. Other certificates can be, however. -
An administrator must distribute the Standalone CA certificate to the Trusted Root Certificate Store. If Active Directory exists on the network and a Standalone CA can access it, additional options are available: -
If a domain administrator with write access to Active Directory installs the Standalone CA, the standalone is added to the Trusted Root Certification Authorities Certificate Store. In this situation, you must make certain that the default action of pending requests isn't changed to allow the Standalone CA to automatically approve all requests for certificates. Do not change the default action of pending certificate requests on a Standalone CA. -
If a domain administrator group member of the parent domain (or an administrator with write access to Active Directory) installs the Standalone CA, the Standalone CA will publish the certificate and the Certificate Revocation list to Active Directory. Windows Server 2003 PKI allows for and encourages a dispersed hierarchy of CAs. Building a tree of CAs allows for scalability with other organizations, internal and external resources, and compatibility with third-party CA implementations . Ideally (for ease of administration), an enterprise would have one CA; this is not usually a reality, however. Each CA hierarchy begins with the Root CA, and multiple CAs branch from this Root CA in a parent-child relationship. The child CAs are certified by the parent CA all the way back to the Root CA. The parent CAs bind a CA public key to the child CA's identity. In this parent-child relationship, child CAs are trusted by the parent. That parent is, in turn , trusted by its parent CA, all the way back to the originating Root CA. Also in this model, when an organization trusts a CA by adding its certificate in the Trusted Root Certification Authorities Certificate Store, the organization therefore trusts every Subordinate CA in the hierarchy. Should a Subordinate CA have its certificate revoked by the issuing CA, the revoked CA is no longer trustworthy. CAs are responsible not only for issuing and signing digital certificates, but they are also responsible for maintaining an accurate and up-to-date listing of those certificates that are no longer valid and thus should not be trusted. This listing of invalid certificates is known as a Certificate Revocation List (CRL) and is itself digitally signed by the issuing CA to verify its authenticity. When a certificate is issued, it has a set validity period attached to it, typically one year by default. Under normal circumstances, the certificate can be used for this period of time and will cease to be valid automatically should it not be renewed before the expiration date has been reached. Thus, it is only necessary to place certificates that have been revoked early for some reason on the CRL; certificates that have expired (that is, have passed their expiration date) are automatically considered invalid and do not need to be placed on a CRL. In a parent-child relationship between CAs, the parent CA issues a certificate as part of the relationship to designate the child CA. Just like the certificate to a client, the certificate to a Subordinate CA includes a validity period. When the validity period expires for a CA, its own certificate must be renewed before it can grant any certification requests from client computers. When organizing your PKI, take into account the time a certification in a parent-child relationship should last. As a safety and security measure, Windows Server 2003 PKI is set up so that a CA cannot issue certificates to requestors that will last beyond its own certificate's expiration date. This measure is handy because it ensures, for example, that a CA scheduled to expire this October cannot issue a certificate that may expire later than October. Even the Root CA's own certificate will eventually expire. Therefore, certificates that it issues to subordinates will be staggered from its own expiration date. In other words, when the Root CA expires, all Subordinate CAs will have expired as well. No Subordinate CAs are valid beyond the date of the originating CA. Depending on the configuration of your network, you can choose from four different certificate enrollment options: -
Certificate autoenrollment and renewal ” A Windows Server 2003 Active Directory domain with Windows XP Professional clients provides the most robust Certificate Services model. This is certainly the case when discussing certificate autoenrollment and renewal. Using these features, you can automatically issue certificates that enable PKI-based applications, such as smart card logon, EFS, SSL, and S/MIME to users and computers within your Active Directory environment. Through a combination of certificate template properties and Group Policy settings, you can opt to enroll computers when they start up and users when they log in to their domain on the network. -
Certificate Request Wizard/Certificate Renewal Wizard ” Users of Windows 2000, Windows XP, and Windows Server 2003 computers can manually request certificates through the Certificates MMC snap-in. This snap-in can be added to any custom MMC. Alternatively, you can launch the Certificates management console by entering certmgr.msc at the command prompt. -
Web Enrollment Web pages ” You can connect to a CA by entering http:// CAname /certsrv in your browser. By default, the Web Enrollment pages, which consist of ASP and ActiveX controls and thus could be considered dangerous, are installed on a CA. You can, however, install these pages on any other Windows Server 2003 computer running IIS that you want. If you're up to it, you can also customize these Web Enrollment pages to suit your specific needs. The Web Enrollment pages provide an easy way to connect clients to your CA without using the Certificates management console. Although Standalone CAs also use the Web Enrollment pages, they cannot provide certificates for smart card logon and for autoenrollment ”only Enterprise CAs. Also, when Standalone CAs are used with Web Enrollment pages, the requester must specifically specify all required information because Active Directory is not available to provide the information for the certificate template. Windows 2000, Windows XP, and Windows Server 2003 computers support the use of the Web Enrollment pages. -
Smart Card enrollment station ” This is an advanced form of the Web Enrollment pages that allows trusted administrators to request and enroll smart card logon certificates for smart card users on the network. Only Windows XP and Windows Server 2003 computers support this form of enrollment. You can choose from two basic options when you want to enroll smart card certificates: -
Use an enrollment agent ” The use of an enrollment agent allows a trusted administrator to process all smart card certificate requests and ensures that smart cards and their certificates are created and installed properly. Although this can be a good thing from a user's point of view, it can quickly become an overwhelming task if too few enrollment agents are designated. The other disadvantage to using enrollment agents becomes apparent if one of the enrollment agents is later deemed to be untrustworthy. What do you do with all the smart cards that agent previously enrolled? -
Allow self-enrollment by smart card users ” Although using enrollment agents is usually the best (and by far the most secure) method to enroll smart cards, in some cases you may need or want to have users perform this task themselves . In cases in which you cannot physically (and safely) distribute fully ready smart cards, you may want to consider issuing blank smart cards and allowing the user to self-enroll. Should you think that self-enrollment is completely insecure , recall that you can configure your CA to hold all new requests pending a manual administrative approval, thus allowing you a chance to examine and validate the request before allowing the smart card to be enrolled with its certificate. When you use smart cards for increased security of your network, you can configure several Group Policy options to further enhance the security of your smart card implementation: -
Interactive logon: Require smart card ” This option, located in the Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options node of the Group Policy Editor can be used to prevent users from logging in to the domain by using a standard Windows username and password. Although this setting provides enhanced security, it can leave users without network access if their smart cards become unavailable for any reason. You should apply this policy at the OU level, making each smart card user a member of a domain local group and placing that group within the OU. Mistakenly applying this setting to non-smart card users will have disastrous effects. -
Interactive logon: Smart card removal behavior ” This option, also located in the Security Option node, can be used to define what Windows should do when a smart card is removed from its reader with the user logged in. Possible options include No Action, Lock Workstation, and Force Logoff . This option again presents both benefits and dangers. A user who mistakenly removes her smart card with open documents may well lose any changes made since the document was last saved. On the other hand, for computers located in kiosks or other insecure areas, this setting can greatly increase the security of the computer and your network. This Group Policy setting requires training on your part to ensure that your smart card users understand the consequences of their actions. Again, this setting should be configured on a OU containing only those users who have been issued smart cards. -
Do not allow smart card device redirection ” This option, located in the Computer Configuration\Administrative Templates\Windows Components\Terminal Services\ Client/Server data redirection node of the Group Policy Editor, can be used to prevent users from logging in to a Terminal Server with a smart card. This can increase security and decrease loading on your Terminal Servers. -
Account Lockout Policy ” The Account Lockout Policy node, located at Computer Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policy in the Group Policy Editor, contains three useful Group Policy settings that you can use to enhance both smart card and standard Windows login. The Account Lockout Threshold setting can be configured to specify how many failed logon attempts should be allowed before that user account is locked out. The Account Lockout Duration setting specifies how long the account is to be locked out (barring an administrator's unlocking the account early). The Reset Account Lockout Counter After option specifies how much time must pass before failed logon attempts are no longer counted against the Account Lockout Threshold setting. These policies are typically applied at a high level in your organization, such as the root of a domain to cause them to apply to all users within the domain. Realizing that it needed to become more proactive in helping Windows network administrators understand and correct the issues associated with the various security flaws that occur in the Windows operating systems, Microsoft has provided you with several tools that you can use to identify, categorize, and correct security-related issues on your network. The choice of what tool you use really depends on how you want to go about keeping your network updated. The following options are available for you to use in identifying and installing required security updates on your network's computers: -
Microsoft Baseline Security Analyzer (MBSA) ” MBSA is an enhanced GUI version of the popular command-line HFNetChk application that can be used on Windows 2000, Windows XP, and Window Server 2003 computers to look for missing security updates, missing service packs , and weak security configurations in the supported Windows operating systems, Office, IIS, Structured Query Language (SQL) Server, and several other popular Microsoft applications. Even though MBSA cannot be run on a Windows NT 4.0 computer, it can be used remotely to scan a Windows NT 4.0 computer. MBSA does a good job of identifying and categorizing missing updates and security problems that it finds, but it does not provide any direct means to update required patches. The real strength of MBSA is that it can be used to scan many computers, even remote ones, at a time, providing a quick and easy-to-interpret graphical output. -
Windows Update ” Windows Update, which has been around since Windows 98 arrived, provides an easy-to-use (although not always accurate) Web-based tool for determining the need to install newly available updates on a local computer. Automatic Update works in conjunction with Windows Update in instances in which SUS has not been installed; it provides automatic downloading and installation of required updates. -
Software Update Services (SUS) ” Introduced for Windows 2000 and improved for Windows Server 2003, SUS allows you to provide one or more Windows Update servers that run inside your protected internal network. SUS allows an administer to exercise granular control over which updates are installed and which aren't by allowing only "approved" updates to be installed on network computers configured to use an SUS server for updating. After installing SUS, you perform all management and configuration from within your Web browser for ease of administration. -
Automatic Updates ” Automatic Updates is a new component of Windows XP SP1 and Windows 2000 SP3 that can download and install required updates from either the Windows Update Web servers or your internal SUS servers, depending on how it has been configured; the default configuration is to use the Windows Update Web servers. Automatic Updates is included in the default installation of Windows Server 2003. To configure Automatic Updates to use an internal SUS server, you must first install and configure at least one SUS server and then configure the appropriate Group Policy settings to require clients to use the designated SUS servers. -
Systems Management Server ” SMS 2.0 was in use by a large number of organizations well before the release of Windows 2000 and its IntelliMirror and Active Directory technologies ”the heart of software installation via Active Directory. SMS has been updated recently with the SMS 2.0 Software Update Services Feature Pack, which allows it to integrate into a SUS implementation without changing the configuration of the network clients. For many years , administrators have used SMS to manually push updates to clients; the feature pack allows this function to become more automatic. SMS is due for a new version in late 2003. This new version, which will be Active Directory integrated, promises many new features for software management and maintenance. SUS is actually one part of a two-part system. The other part, the Automatic Updates client, runs on the servers and client workstations that you want to download updates. Although the Automatic Updates client was included in Windows XP (pre “Service Pack 1), it was not the correct version to participate in SUS. You need to install Windows 2000 Service Pack 3 (or higher) or Windows XP Service Pack 1 (or higher) on client workstations to get the updated version that can interact with SUS. Alternatively, you can install the updated version of the Automatic Updates client. MBSA scans your computers not only for Windows security updates, but also for updates associated with other Microsoft products. MBSA 1.1.1 (the current version as of this writing) scans for security updates in the following products: -
Windows NT 4.0 -
Windows 2000 -
Windows XP -
Windows Server 2003 -
Internet Explorer 5.01 and higher -
Windows Media Player 6.4 and higher -
IIS 4.0 and higher -
SQL Server 7.0 and 2000 (including Microsoft Data Engine) -
Exchange 5.5 and 2000 (including Exchange Admin Tools Windows Server 2003 allows you to perform auditing of the following areas: -
Audit Account Logon Events ” This option configures auditing to occur for user logons and logoffs. A successful audit generates an audit entry when a user successfully logs in, and a failed audit generates an entry when a user unsuccessfully attempts to log in. -
Audit Account Management ” This option configures auditing to occur for each event of account management on a computer. Typical account management events include creating a user, creating a group, renaming a user, disabling a user account, and setting or changing a password. A success audit generates an audit entry when any account management event is successful, and a failure audit generates an entry when any account management event fails. -
Audit Directory Service Access ” This option configures auditing to occur when a user accesses an Active Directory object that has its own system access control list (SACL). This setting is only for Active Directory objects, such as GPOs, not for file system and Registry objects. A success audit generates an audit entry when a user successfully accesses an Active Directory object that has an SACL specified, and a failure audit generates an entry when an unsuccessful access attempt occurs. -
Audit Logon Events ” This option configures auditing to occur upon each instance of a user logging on to or off a computer. The audit events are generated on domain controllers for domain account activity and on local computers for local account activity. When both the Audit Logon Events and the Audit Account Logon Events options are configured, logons and logoffs that use a domain account generate logon or logoff audit events on the local computer as well as the domain controller. A success audit generates an audit entry when a logon attempt succeeds, and a failure audit generates an audit entry when a logon attempt fails. -
Audit Object Access ” This option configures auditing to occur upon each user access of an object, such as a file, folder, printer, or Registry key that has its own SACL configured. To configure auditing for object access, you also need to configure auditing specifically on each object on which you want to perform auditing. A success audit generates an audit entry when a user successfully accesses an object, and a failure audit generates an audit entry when a user unsuccessfully attempts to access an object. -
Audit Policy Change ” This option configures auditing to occur upon every occurrence of changing user rights assignment policies, audit policies, or trust policies. A success audit generates an audit entry when a change to one of these policies is successful, and a failure audit generates an audit entry when a change to one of these policies fails. -
Audit Privilege Use ” This option configures auditing to occur upon every occurrence of a user exercising a user right. A success audit generates an audit entry when the exercise of a user right succeeds, and a failure audit generates an audit entry when the exercise of a user right fails. -
Audit Process Tracking ” This option configures auditing to occur for events such as program activation, process exit, handle duplication, and indirect object access. A success audit generates an audit entry when the process being tracked succeeds, and a failure audit generates an audit entry when the process being tracked fails. -
Audit System Events ” This option configures auditing to occur when certain system events occur such as computer restarts and shutdowns. A success audit generates an audit entry when a system event is executed successfully, and a failure audit generates an audit entry when a system event is attempted unsuccessfully. |
