This section describes two different procedures for restoring the source CA database backup on the destination server. If you are migrating to a Server Core installation, you must use the procedure "To restore the CA database by using Certutil. If you are migrating to a failover cluster, ensure that shared storage is online and restore the CA database on only one cluster node.
On the Items to Restore page, select Certificate database and certificate database log. Click Browse. Navigate to the parent folder that holds the Database folder the folder that contains the CA database files created during the CA database backup. Include the force flag because an empty CA database will already be present after you perform the steps in Adding the CA role service by using Server Manager. Type certutil. Before importing the registry settings from the source CA to the target CA, create a backup of the default target CA registry configuration by using the procedure Backing up CA registry settings.
Some registry parameters should be migrated without changes from the source CA computer, and some should not be migrated. If they are migrated, they should be updated in the target system after migration because some values are associated with the CA itself, whereas others are associated with the domain environment, the physical host, the Windows version, or other factors that may be different in the target system.
A suggested way of performing the registry configuration import is first to open the registry file you exported from the source CA in a text editor and analyze it for settings that may need to be changed or removed.
The following table shows the configuration parameters that should be transferred from the source CA to the target CA. If the target CA's computer name is different from the source CA's computer name, search the file for the host name of the source CA computer. For each instance of the host name found, ensure that it is the appropriate value for the target environment. Change the host name, if necessary.
Update the CAServerName value. If the host name is located in the. The CA name must not be changed as part of the migration. Check any registry values that indicate local file paths, such as the following, to ensure drive letter names and paths are correct for the target CA. If there is a mismatch between the source and the target CA, either update the values in the file or remove them from the file so that the default settings are preserved on the target CA.
These storage location settings are elected during CA setup. They exist under the Configuration registry key:. Alternatively, you can update these values after importing them by using the Certification Authority snap-in. The values are located on the CA properties Extensions tab.
Some registry values are associated with the CA, while others are associated with the domain environment, the physical host computer, the Windows version, or even other role services. Consequently, some registry parameters should be migrated without changes from the source CA computer and others should not. Any value that is not listed in the. Remove any registry values that you do not want to import into the target CA. Once the. By importing the source server registry settings backup into the destination server, the source CA configuration is migrated to the destination server.
Click Start , type regedit. Click Hexadecimal. In Value data , type 64 , and then click OK. Verify the locations specified in the following settings are correct for your destination server, and change them as needed to indicate the location of the CA database and log files.
Complete steps 6 through 8 only if the name of your destination server is different from the name of your source server. In the console tree of the registry editor, expand Configuration , and click your CA name.
Modify the values of the following registry settings by replacing the source server name with the destination server name. If these two settings are not displayed, you can proceed to the next step. The steps described for importing the source CA registry settings and editing the registry in case of a server name change are intended to retain the network locations that were used by the source CA to publish CRLs and CA certificates.
Because many administrators configure extensions that are customized for their network environment, it is not possible to provide exact instructions for configuring CRL distribution point and authority information access extensions. Carefully review the configured locations and publishing options, and ensure that the extensions are correct according to your organization's requirements. The following procedure is required only for an enterprise CA.
A standalone CA does not have certificate templates. Review the list of templates created during Backing up a CA templates list. Complete the following procedure in the case of a server name change.
Log on as a member of the Enterprise Admins group to a computer on which the Active Directory Sites and Services snap-in is installed.
Open Active Directory Sites and Services dssite. In the Allow column, click Full Control , and click Apply. The previous CA computer object is displayed as Account Unknown with a security identifier following it in Group or user names.
You can remove that account. To do so, select it and then click Remove. A certification authority CA is responsible for attesting to the identity of users, computers, and organizations. The CA authenticates an entity and vouches for that identity by issuing a digitally signed certificate. The CA can also manage, revoke, and renew certificates. You should determine how many CAs you will install and in what configuration before you install any CA. An HSM is a dedicated hardware device that is managed separately from the operating system.
These modules provide a secure hardware store for CA keys, in addition to a dedicated cryptographic processor to accelerate signing and encrypting operations.
The CAPolicy. The settings that you include in the CAPolicy. The following sections describe the configuration options that you will select after installing the CA binary installation files.
Enterprise CAs use information that is stored in AD DS, including user accounts and security groups, to approve or deny certificate requests. Enterprise CAs use certificate templates. When a certificate is issued, the Enterprise CA uses information in the certificate template to generate a certificate with the appropriate attributes for that certificate type.
If you want to enable automated certificate approval and automatic user certificate enrollment, use Enterprise CAs to issue certificates.
These features are available only when the CA infrastructure is integrated with Active Directory. Additionally, only Enterprise CAs can issue certificates that enable smart card sign-in, because this process requires that smart card certificates are mapped automatically to the user accounts in Active Directory.
By default, you must be a member of the Enterprise Admins group to install and configure an Enterprise CA. If you want a low-privileged domain administrator to install and configure an Enterprise CA, see Delegated Installation for an Enterprise Certification Authority.
If you use stand-alone CAs, all information about the requested certificate type must be included in the certificate request. By default, all certificate requests that are submitted to stand-alone CAs are held in a pending queue until a CA administrator approves them. You can configure stand-alone CAs to issue certificates automatically upon request, but this is less secure, and it is usually not recommended because the requests are not authenticated. From a performance perspective, using stand-alone CAs with automatic issuance enables you to issue certificates at a faster rate than you can by using enterprise CAs.
However, unless you are using automatic issuance, using stand-alone CAs to issue large volumes of certificates usually comes at a high administrative cost because an administrator must manually review and then approve or deny each certificate request.
For this reason, stand-alone CAs are best used with public key security applications on extranets and on the Internet, when users do not have user accounts and when the volume of certificates to be issued and managed is relatively low.
You must use stand-alone CAs to issue certificates when you are using a non-Microsoft directory service or when AD DS is not available. You can use both enterprise and stand-alone certification authorities in your organization, as explained in the following table. A root CA is the CA that is at the top of a certification hierarchy. It must be trusted unconditionally by clients in your organization. All certificate chains terminate at a root CA. Whether you use enterprise or stand-alone CAs, you need to designate a root CA.
Since the root CA is the top CA in the certification hierarchy, the Subject field of the certificate that is issued by a root CA has the same value as the Issuer field of the certificate. Likewise, because the certificate chain terminates when it reaches a self-signed CA, all self-signed CAs are root CAs. The decision to designate a CA as a trusted root CA can be made at the enterprise level or locally by the individual IT administrator. By sharing your experience you can help other community members facing similar problems.
Thanks for your understanding and efforts. Best Regards Kevin. Office Office Exchange Server. Not an IT pro? Script Center. Sign in. United States English. Ask a question. Quick access. Search related threads. Answered by:. Archived Forums. Directory Services. Sign in to vote. Wednesday, December 29, PM. Check the below link, its explained beautifully. Hi, Active Directory Certificate Services is an Identity and Access Control security technology that provides customizable services for creating and managing public key certificates used in software security systems that employ public key technologies.
0コメント