Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

1.

Create the file in Notepad and enter the following information:

[version]
Signature= "$Windows NT$"[Certsrv_Server]
RenewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=20
[CRLDistributionPoint]
[AuthorityInformationAccess]

2.

Save the file to the %systemroot% of the computer on which the CA will be installed.

1.

Log on as a local administrator of the server.

2.

Open Start, Settings, Control Panel, Add or Remove Programs, Add/Remove Windows Components.

3.

Select the Windows Certificate Services check box.

4.

Click Yes when prompted, as shown in Figure 13-1, and then click Next. Once a computer takes on the role of CA, you cannot change its name or domain membership. Because this computer will be kept separate from the network anyway, it should not be a domain member, and its name should be established before certificate services are installed.

5.

Click Details and view the components Certificate Services CA and Certificate Services Web Enrollment Support (see Figure 13-2). Click OK, and then click Next. Although IIS will not be installed on this computer, and web services won't be used for certificate enrollment, you cannot delete the Web Enrollment Support component. This component creates the file structure necessary to support web-based certificate requests and meets the needs of default locations for CDP and AIA.

6.

Click OK and then click Next.

7.

Select stand-alone root CA. (While an Enterprise Root CA could be implemented on a member server, it would then be integrated with Active Directory. It would not be advisable to then remove that computer from the network. Removing such a computer permanently from the network would mean excess processing and errors as the member server keeps trying to find its domain controller.)

8.

Select the Use Custom Settings To Generate The Key Pair And CA Certificate check box and click Next.

9.

Leave the default Cryptographic Service Provider(CSP)Microsoft Strong Cryptographic Provider. Vendors provide special CSPs so that their devices will work with certificate services. By default, three third-party CSPs (Schlumberger cryptographic service provider, Infinean SICRYPT Base Smart Card CSP, and Gemplus GemSAFE card CSP v1.0) are available, but vendor CSPs can be added as needed.

10.

Leave the default integrity algorithm as the SHA-1 hash algorithm.

11.

Select a 4096-bit key, as shown in Figure 13-3. The default key size is 2049, but a longer key length is advised. In general, you must weigh the increased security of a larger key with the longer time that will be taken when the key is used for encryption or signature. The root CA will only issue subordinate CA certificates, and the time difference taken by a 4096-bit key versus that of a 2049-bit key is insignificant when it is used only a few times.

12.

Note that there is an option to use an existing key pair, and then click Next. If you need to recover or rebuild a CA, you can install the CA and import an existing key pair.

13.

Enter a common name for the certification authority; the name rootA is used here for ease of identification in later exercises. In a production environment, use a name that identifies the certificate. The common name is the name that will be visible, for example, in the Trusted Root Certification Authorities store. The CA common name does not have to be the same as the computer name. However, the common name, validity period, location of the certificate database, log, and shared folder cannot be changed after setup.

14.

Enter 20 years for the validity period, as shown in Figure 13-4, and click Next. The default time period is 5 years. The time period is made longer simply for convenience. If there is some reason to renew the certificate and generate new keys before that time period, it can easily be done. Certificates issued by CAs in the hierarchy cannot have a longer validity period than the CA certificate.

15.

After the keys are generated, the storage location for the database can be changed. Accept the default location for the storage locations and click Next. On a production system, it is a good idea to have at least two hard disk drives and place the database log on a different drive than the database. This may improve performance.

16.

Wait while the system configures the CA components, and then click OK at the IIS warning message. A message will note that IIS is not installed and that Certificate Services Web Enrollment will not be available until IIS is installed. IIS is not needed on the root CA. There will not be many requests for subordinate CAs, and those can be managed manually from the Certification Authority console. (The CA will not be online; therefore, any web-based requests would be local, and the extra service is just not necessary.)

17.

If prompted, enter or browse to the path for the Windows Server 2003 installation disk.

18.

When installation is finished, click Finish.

19.

Go to Start, Administrative Tools, Certification Authority and note that the CA service has started, as evidenced by a green check mark on the CA.

20.

Select File, Exit to close the Certification Authority console.

1.

Open an MMC console.

2.

Click the File menu and select Add/Remove Snap-in.

3.

Click Add, and then select Certificates from the Add Standalone Snap-in dialog.

4.

Click Add, select Computer Account, click Next, click Finish, Close, and then click OK.

5.

Expand the Certificates (Local Computer), Personal folder and then select the Certificates folder.

6.

In the detail pane, right-click the CA certificate and select All Tasks, Export.

7.

Click Next on the Welcome to the Certificate Export Wizard page.

8.

Select Yes, export the private key, as shown in Figure 13-6, and then click Next.

9.

Do not change the Export File Format page, as shown in Figure 13-7; instead, click Next.

10.

Enter and confirm a password. This password helps protect the keys. It must be entered before the keys can be imported into a certificate store. A maximum 32-character password can be used. The CA will be compromised if unauthorized individuals obtain the keys. The media should also be protected, and a strong password should be used. Because you may never have to use the password, it is unlikely that you will remember it, and you might not be present when it's needed. To ensure key recoverability, write down the password and store it in a safe place, separate from the media on which the key file exists.

11.

Browse to the location for file storage, enter a file name, and click Next, and then click Finish.

12.

If the export is successful, click the OK button.

1.

Open the Certification Authority console.

2.

Right-click the CA and select Properties.

3.

Click the View Certificate button on the General page.

4.

Click the Details page of the certificate. Scroll down through the details, as shown in Figure 13-8, and confirm that the certificate does not include the CRL Distribution Points or Authority Information Access fields.

5.

Click OK to close the certificate.

1.

If the property pages for the CA are not open, open the Certification Authority console and select the certification authority by clicking the CA.

2.

Select Properties from the Action menu.

3.

Click the Extension tab, click the Select Extension drop-down box, and then click Authority Information Access (AIA). AIA specifies the location where clients may download a copy of the CA certificate. The AIA default location is on the CA computer. Because this CA will be offline, you must change the publication location of the AIA to the network so that it is accessible by clients. This must be done before certificates are issued because the AIA location is published on the certificate.

4.

Note the syntax of the configured AIA extension locations. Click Add and enter the new web location. The following location (also shown in Figure 13-9) is where the certificate only (not the certificate and related private key) will be stored on a chicago.local server. In the URL, the enclosed variables <CaName> and <CertificateName> will be interpreted as rootA: http://chicago.local/CertEnroll/regalin_<CaName><CertificateName>.crt

5.

When complete, click OK.

6.

On the Extensions page, which is shown in Figure 3-10, make sure the new URL is selected and click the Include in the AIA extension of issued certificates check box. Do the same for the new file location if it is created. Don't forget this step! The location of the AIA must be available, and for it to be used, the information must be published on the certificate.

7.

Click the default URL for the location of the AIA, the one pointing to a local IIS server, and click Remove.

8.

Note the default location where you can find a copy of the CA certificate to copy to this location on the IIS server on the CA computer. The default location is <systemroot>\System32\ CertSrv\CertEnroll\motorin_rootA.crt.

9.

If desired, note the syntax for the file location for AIA and create a file location where the root CA certificate may be located. The following syntax is used for Tailspin Toys:

File://\regalin.chicago.local\CertSrv\CertEnroll\<CAName><CertificateName>.crt

10.

Click the Add button to add an LDAP location. The root CA certificate should be made available in the Active Directory. Don't forget to publish the certificate in the Active Directory. Use this syntax:

ldap:///CN=rootA,CN=AIA,CN=Public Key Services,CN=Services, CN=Configuration,DC=chicago
,DC=local?cACertificate?base?objectclass=certificationAuthority

11.

Select the new LDAP entry and check the box Include in the AIA extension of issued certificates.

12.

Select the default LDAP location and ensure that the Include in the AIA extension of issued certificates check box is not selected. The default LDAP location on a standalone server that is not a member server will not have this item checked, as it makes no sense for that server. (The root CA will not be available to the network, so publishing the local file location for the root certificate is unnecessary.)

13.

In the Select extension drop-down box, select the extension CRL Distribution Point (CDP).

14.

Select the LDAP location and make sure no boxes are checked. Again, no LDAP directory is available to a standalone server.

15.

Click the Add button and add a new LDAP path for the chicago.local domain. Later, you'll publish this information to the directory. The syntax for the ldap entry is as follows:

ldap:///CN=roota,CN=regalinn,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration
,DC=chicago,DC=local?certificateRevocatinoalLilst?base?objectlass=cRLDistributionPoint

16.

Select the new LDAP location and check the boxes Include in all CRLs, Specifies where to publish in the Active Directory when publishing manually, and Include in the CDP Extension of Issued Certificates.

17.

Select the file location and click Include in the CDP cxtension of issued certificates to deselect it. The root CA will not be accessible to computers, so publishing the file location in the CDP extension of certificates is useless. The Publish CRLs to this location check box should remain checked. The published CRL must be retrieved from this location in order to publish it on the network where it can be located.

18.

Click Add and enter a new http location. A new http CDP location must be added because the CA will not be online. The new CDP must be at an online location. Use this syntax: http://chicago.local/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

19.

Click OK to return to the Extensions page.

20.

With the new http entry selected, click the Include in the CDP extension of issued certificates check box, and then click OK.

21.

Select the default http CRL location, click Remove, and then click OK.

22.

Note that the default location for the publication of the CRL is the same as that for the root certificate. You need to copy both of these files to removable media so that you can make them available for publication to Active Directory and the web site of the CA.

23.

Click Apply to save settings. Click No when asked if you want to stop and restart certificate services at this point.

24.

Click the Policy Module tab and then click Properties.

25.

Note, as shown in Figure 13-11, that Set the certificate request status to pending is checked. Requests for CA certificates should always be manually approved. Standalone CAs cannot use the Active Directory to authenticate the user and determine if it's OK to issue certificates to users or computers. When certificate requests are marked as "pending," the CA administrator has to approve them.

26.

Click Cancel to close the Policy Module property pages, and then click OK to close the root CA property pages.

27.

Right-click the Revoked Certificates node and select Properties.

28.

In the CRL Publication Interval box, enter 6, use the drop-down box to select Months, and then click OK (see Figure 13-12). The CRL will be published to the file system of the rootA CA. After each publication, you need to copy it and manually ensure it is published to the Active Directory and the network-accessible locations, in this case, on the computer2 web server. The first CRL, an empty CRL, is published to the file system. You can manually publish a CRL at any time and manually locate it at the proper locations. Setting the timeframe at six months means you must manually retrieve each new root CA CRL and manually publish it to the network locations.

29.

Click the View CRLs tab to see that the CRL has been published, as shown in Figure 13-13. Then, click the View CRL button and click the Revocation List tab. Note, as shown in Figure 13-14, that a CRL has been published and is empty, as you would expect.

30.

Click OK twice to close the Property pages.

31.

Stop and start the certificate service.

32.

The current CRL does not contain the new http and ldap enTRies that you have created. Publish a new CRL manually by right-clicking the Revoked Certificates node, selecting All Tasks, and then click Publish.

33.

Click File, Exit to close the Certification Authority console.

34.

Open Windows Explorer, browse to <windir>\system32\CertEnroll, and copy the CRL and certificate files (rootA.crl and motorin_rootA.crt files in this example) to removable media.

1.

Log on to regalinn as a member of the Domain Admins group.

2.

Publish the CA certificate to Active Directory by using the certutil command. This adds the standalone root CA certificate to the Active Directory. It must be accessible to the certificate verifiers:

Certutil dspublish f motorin_rootA.crt

3.

Publish the CRL to the Active Directory by using the certutil command:

Certutil dspublish f rootA.crl

1.

Log on as a member of the Domain Admins group.

2.

Open a GPO linked to the domain.

3.

Select the Computer Configuration, Windows Settings, Security Settings, Public Key Policies node.

4.

In the details pane, right-click the Trusted Root Certification Authorities policy, click Import, and then click Next.

5.

Browse to the root CA certificate file (a copy is in <systemroot>\system32\certsrv\certenroll).

6.

Select the file, click Open, and then click Next.

7.

Click Place All Certificates in the Following Store, select the Trusted Root Certification Authorities store, and then click Next.

8.

Review the summary and click Finish.

9.

In the GPO, note that the certificate is now listed.

1.

Log on to the root CA computer Administrative Tools, Local Security Policy console. On a standalone computer, object auditing must be enabled locally. Computer accounts for CAs that are member servers should be in their own OU, and a GPO can be used to turn on object auditing for all Enterprise CAs.

2.

Browse to Local Policies, Audit Policy.

3.

Double-click on Audit Account Logon Events and click the Failure box to select it. (The Success box is already selected.) Click OK.

4.

Repeat for the Audit Logon Events category.

5.

Open Audit Account Management, select Success and Failure, and then click OK.

6.

Repeat for Audit Object Access, Audit Policy Change, Audit Privilege Use, and Audit System Events. It is critical to monitor all CA operations. Changes also need to be made to the event log policy to accommodate the collection of events and ensure the retention of logs.

7.

Close the Local Security Policy.

8.

Open the Start, Administrative Tools, Event Viewer console.

9.

Right-click the Security node and select Properties.

10.

Note the default log size and select the Do Not Overwrite Events (Clear Log Manually) button to select it. Establish requirements for the security log file. No audit policy is complete without specifying parameters for the management of the security log file. Even though the initial project is small, auditing settings will collect extensive information. The size of the log should be set large and monitored for growth. Before the project is expanded, size history should be evaluated and a larger file designated to ensure adequate space.

11.

Click OK to close the property pages and then close the Event Viewer console.

1.

Open the Certification Authority console, right-click the CA, and then select Properties.

2.

Select the Auditing page.

3.

Select all the audit events by checking all the event boxes (see Figure 3-16). Note the message when the Start and Stop Certificate Services selection is made. It indicates that a cryptographic hash is made of the database when the service is stopped or started and warns of a time delay. This could become a performance issue for issuing CAs; however, the database will not be large on the root CA, and the root CA will not often be stopped and started again.

4.

Click OK.